Patrick Stakem

This book covers the topic of mainframe computers, Big Iron, the room-sized units that dominated and defined computing in the 1950's and 1960's. The coverage is of efforts mainly in the United States, although significant efforts in the U.K., Germany, and others were also involved. Coverage is given for IBM and the 7 dwarfs, Burroughs, Control Data, General Electric, Hineywell, NCR, RCA, and Univac. There is also coverage of machines from Bendix, DEC, Philco, Sperry-Rand, and Sylvania.The predecessor architectures of Charles Babbage and his Differential Engine and Analytical Engine are discussed, as well as the mostly one-off predecessors Colossus, Eniac, Edvac, Whirlwind, ASCC, Sage, and Illiac-IV, How did we get where we are? Initially computers were big, unique, heavy mainframes with a dedicated priesthood of programmers and system engineers to keep them running. They were enshrined in specially air conditioned rooms with raised floor and access control. They ran one job at a time, taking punched cards as input, and producing reams of wide green-striped paper output. Data were collected on reels of magnetic tape, or large trays of punched cards. Access to these very expensive resources was necessarily limited. Computing was hard, but the advantages were obvious - we could collect and crunch data like never before, and compute things that would have worn out our slide rules. The book is focused mostly on computers that the author had experience with, although it does cover some of the one-off predecessors that lead to the mainframe industry of the 1960's. Thus, this book is not comprehensive. It probably missed your favorite. Not every machine from every manufacturer is discussed.Computers were built for one of two purposes, business accounting, or scientific calculations. There was also research in the fledging area of Computer Science, an area not yet well defined. The computers used peripherals from the Unit Record equipment, designed for business data processing. Data were typed on cards, sorted, and printed mechanically. This was a major improvements over the manual method. Herman Hollerith figured this out, and improved the processing of the U. S. Census in 1890. This took 1 year, as opposed to 8 years for the previous census. Hollerith set up a company based in Georgetown (part of the District of Columbia) on 29th street to manufacturing punched card equipment. There is a plaque on the building which housed the Tabulating Machine Company, later know as IBM. At the same time, business and science were both using mechanical calculators to handle computations. These were little changed over a hundred years or so. The technology base changed from mechanical to relay to tube, and things got faster. The arithmetic system changed from decimal to binary, because the switching elements in electronics was two-state. The next step was to put a "computer" between the card reader and the printer, and actually crunch the data.Then, a better idea evolved. Most of the time, the "big iron" was not computing, it was waiting. So, if we could devise a way to profitably use the idle time, we would increase the efficiency of the facility. This lead to the concept of time-sharing. There was a control program whose job it was to juggle the resources so that a useful program was always running. This came along about the time that remote terminals were hooked to the mainframe, to allow access from multiple, different locations. In a sense, the computer facility was virtualized; each user saw his very own machine (well, for limited periods of time, anyway). If the overhead of switching among users was not too great, the scheme worked.This evolved into a "client-server" architecture, in which the remote clients had some compute and storage capability of their own, but still relied on the big server.And, in the background, something else amazing was happening. Mainframes were built from relays and vacuum tubes, magnetic co

This is a work about the Georges Creek Valley in Allegany County, Western Maryland. The Georges Creek Valley is defined by Dan's Mountain to the east, and Savage Mountain to the West, part of the Appalachian range. Portions of Savage Mountain form the Eastern Continental Divide, separating watersheds draining to the Ohio River and those draining to the Potomac River. The history of the settlement of the Georges Creek Valley is the history of coal. George Washington was familiar with the area from his various trips in the wilderness. Once populated entirely by Native Americans, the region was settled by the English, with families from Scotland, Wales, and Ireland.Besides coal, a pioneering iron furnace was built at Lonaconing, which drove the introduction of rail transportation in the region. Where George's Creek meets the Potomac, the C&O Canal was slated to pass by.

This book discusses the floating point data format in computation. It is somewhat architecture-neutral, but does restrict the discussion to binary computation in digital computers based on software and microelectronics technology. To understand why we need the complexity of floating point for scientific, engineering, and financial calculations, we need to review number systems, integer calculations in binary and decimal, and other representations systems, as well as the concept of negative numbers and zero. This work contains a broad list of floating point units and software packages.Both software and hardware approaches are discussed for 8-bit to 64-bit integer machines. The IEEE standard for floating point is discussed, as well as the previous mainframe era standards. A glossary and list of references are included.

The book covers the topic of Embedded Computers for Spacecraft. We need to define and explore some terms, starting with "embedded computer." We'll look at its cpu, memory, and I/O. The Space environment is harsh, and hard on computer components. We'll review these effects, and see what additional requirements they place upon the system.Just as embedded computers are special cases of computers in general, then space flight embedded computers are a special case of embedded. They are embedded computers which operate in a challenging environment. I make the assumption you know a bit of computer architecture, how instructions are executed, and how how cache works. If not, get a good book or two on computer architecture. There's some in the references. That's our starting point.The flight software, both operating systems and application will be explored. In Space, software is the ideal component. It doesn't weigh anything, doesn't need gravity or air. The environment the embedded system is operating in has a major impact on its design and implementation. The unit may be in Earth orbit, in orbit around another planet, on the surface of another planet, or traversing the solar system. Each of these environments is hostile to equipment, and each is different. Closer to the Sun means hotter, and more radiation. Farther away means less solar power. The large distances involved force slower bandwidth communication, and requires different protocols. In many cases, for long periods of time, spacecraft cannot communicate with Earth-based stations. Spacecraft embedded systems are a special class of embedded. Embedded computers are in just about anything we touch on a daily basis, our cars, our mobile phones and entertainment devices, most of our appliances, traffic light controllers - the list is nearly endless. The earliest satellites did not have computers at all, but the technology quickly evolved to have special purpose-built units. Later, commercial microprocessors were employed, and many failed due to the radiation environment. Now, the latest technologies we use on Earth, multicore, graphics engines, non-volatile magnetic storage, FPGA's, are used in spacecraft electronics. The spacecraft have become networks of computers, or, nodes on a network of space assets.

This book presents an overview of the ARM history and architecture, from the 1980's legacy Advanced RISC Machine, to today's 64-bit multicore units. The applications for the ARM in embedded systems is presented, as well as arm-based system-on-a chip designs. Software for the ARM is presented mostly JAVA, as are specialized architectures for vector floating point and media processing. The Thumb, NEON, and Jazelle extensions are discussed. The applications of the ARM architecture onboard spacecraft is explored, with a brief introduction to unique challenges of the space environment. Vector floating point and multicore instantiations of SIMD are covered. System simulation and debugging are discussed. Arm has proven to be a popular architecture for inexpensive Cubesats. Yearly, billions of the ARM chips are sold. They are present in computer tablets, set-top boxes, phones, automobiles, airplanes, locomotives, routers, household appliances, medical devices - every electronic device imaginable. Understanding of the ARM architecture is critical to understand today's electronic ecosystem. Appendices present selected computer architecture topics such as I/O, floating point, cache, and the fetch/execute cycle in some depth. An extensive glossary and bibliography are included.

This book covers the topic of satellite control centers. We'll take a look at the historical development of satellite control centers, from the earliest efforts of the iconic Apollo Mission Control at Houston. The primary focus will be NASA efforts, but similar facilities for other nation's spaceflight efforts will also be presented. This book is intended as an introduction to the subject. We'll look at the evolution of satellite control centers to understand how we got to where we are, and we'll look at evolving technology to see where we can go. As technology advances, we have a better basis for control centers, as well as cheaper yet more capable hardware, and better and more available software. With the proliferation of inexpensive Cubesat projects, colleges and universities, high school, and even individuals are getting their Cubesats launched. They all need control centers. For lower cost missions, these can be shared facilities. Communicating with and operating a spacecraft in orbit or on another planet is challenging, but is an extension of operating any remote system. We have communications and bandwidth issues, speed-of-light communication limitations, and complexity. Remote debugging is a always a challenge. The satellite control center is part of what is termed the Ground Segment, which also includes the communication uplink and downlink. The control center generates uplink data (commands) to the spacecraft, and receives, processes, and archives downlink (telemetry) data. Now, we can implement control-center-as-a service, and there are global colloborative networks for command and control.

MARC is the Maryland Rail Commuter service, operating in the Baltimore/Washington area. MARC began operating in 1974. MARC trains are operated by Amtrak on the Penn Line, and CSX Transportation on the Camden and Brunswick Lines under contract to the Mass Transit Administration (MTA) of the Maryland Department of Transportation (MDOT). The MTA acquired control of MARC, Maryland's commuter rail system, under legislation by the Maryland General Assembly in 1992. MARC had been providing service throughout the Baltimore-Washington metropolitan area for 18 years at that time. The Maryland Department of Transportation has broader responsibilities than commuter rail; it oversees bus and subway systems, roads, airports, and the Port of Baltimore. Besides giving the history of MARC and the details of its stations and equipment, this book is designed as a ride-along guide that you can take with you, whether on your daily commute, or using the MARC rail to explore sections of the great cities it serves. The stations are presented in alphabetical order for easy access. A bit of history and information on the surroundings are given for each station. For those who are interested in the motive power and rolling stock, a brief description of the locomotives and rolling stock is given. A bibliography is included. The latest edition has additional information on the pending "Purple Line" of street cars, and its connections with MARC, as well as information on the planned MagLev system.

By the 1990's, it was becoming increasingly obvious that Massively Parallel Microprocessor-based Systems (MPMS) were becoming significant new forces in the marketplace, as well as a design approach of great importance. There is no one good source that discusses the architecture of MPMS. No one text gives the overall view of MPMS as a design philosophy, as a market force, and as a technology driver. Thus, I took on the thankless task of putting together this set of information. It is important to realize that in a rapidly moving, trendy area such as MPMS, by the time information is published, it is probably obsolete. By the time a book is published, it is probably only of historical significance. This book is intended for the hardware or software practitioner to use as an introduction to the subject. It assumes that the reader know something about the internals of computer systems, architecture, and instruction execution. It would be relevant for an advanced undergraduate or graduate level course in computer design or architecture. It discusses the chip level of MPMS, and looks at the design trade-offs at the systems level.This document covers the field of MPMS. This is a subset of the field of Massively Parallel Computers. Although this variety of computer has been around for a long time, it only started to make an impact on the computer industry in the 1990's, as an alternative to supercomputers.The goal of this document is to give the reader an introductory look at the fundamentals of MPMS design, to allow the reader to understand the trade-offs, limitations, speed, cost, complexity, and architectures. The reader will be shown the history and the trends of the technology of this rapidly moving field. To achieve these goals, we'll review the basics and background of the technology, to understand where the trade-offs are. We'll then look at real-world design examples to see how the trade-offs were made. It is essential to realize that in MPMS technology, as in many cutting edge endeavors, there are no wrong answers in the marketplace, but a multitude of right ones. The wrong answers either never make it to the market, or don't last long there.This is not a source for designers, because the level of detail presented is not sufficient. However, it will be useful for engineers and engineering managers that must make use of this technology in systems. They need to know the capabilities and limitations of this important field, to be able to apply the technology in their particular domains of expertise.MPMS is a rapidly evolving field. Software has not begun to catch up with the processors. Good software tools to develop, debug, and maintain MPMS are just emerging. MPMS is becoming mainstream.In many cases we'll see decisions made that were not influenced totally by the technological issues, but mainly by marketing considerations. To the design engineer, this is heresy, but in the cold, cruel world, this is economic survival. Some companies are the pioneers at the "bleeding edge" of technology development; others prefer to hold back and address mature markets. As Nolan Bushnell says, "The Pioneers are the ones with the arrows in them".

This book will help you understand the fundamentals of robotics and telerobotics for the space environment. It will point out what the robotic systems can and can't do. Examples of systems and case study's and design examples will be presented.We will review the basics and definitions of robotic and telerobotic systems, as well as the unique characteristics of the space environment to determine where the trade-offs lie. We will compare and contrast with underwater, military, commercial, hazmat and other terrestrial systems. We will not discuss CAD/CAM or manufacturing, which probably makes up 90% of the applications of robotics on Earth. We will review system level components, and discuss sensors, power sources, actuators, and computation and communication systems. Actuators will include tools and grippers. Necessarily, we will discuss simulation, task planning, guided autonomy, and autonomous systems, as well as system models. Today's robot systems are deaf, blind and stupid. And, we expect them to operate in an unstructured environment. But, they are getting better, as technology advances. Robotics are handicapped. in terms of mobility and manipulation, sensory input, cognitive processing, learning and the application of experience. However, they have better computational capability, better communications capability, fewer environmental constraints, and, certainly, fewer ethical issues. (Leaving aside the issue of military armed robots). Over 150 references are included