In the early sixties the so called mini-computer had not emerged and there was no commercial computer suitable for use in the Apollo mission. Most of the technologies that were eventually used in the Apollo computer were just emerging from research and development efforts. The design was mainly a task of fitting the components together in order to meet the mission requirements for computational capacity and miniaturization.

From Polaris to Apollo

Previous aerospace computers greatly influenced the development of the Apollo Guidance Computer. The demands that were placed on these computers provided the motivation to miniaturize and develop semiconductors. The MIT Instrumentation Lab, now called Charles Stark Draper Laboratory, had the responsibility for the design of the computers used in the Polaris, Poseidon, and Apollo programs.

The lab's first significant venture into the field of digital computing was for Polaris, a very small ballistic missile launched from a submarine. A special purpose digital computer was designed to solve the specific equations required for the guidance and control system based on analog techniques originally developed by the Navy. With the need for increased accuracy the Navy decided to use digital techniques for the Polaris program, resulting in the construction of a wired-program special purpose computer to solve the guidance and control equations. In 1959 the first version of this system, called the Mark 1, flew in a Polaris missile. It was the first guided flight of a ballistic missile flown with an on board digital computer providing the guidance and control computations. The computer occupied about four-tenths of a cubic foot, weighed 26 pounds, and consumed 80 watts. Even before this first guided flight designs were being explored which would reduce the size and improve the maintainability of the system. The new design, eventually designated Mark 2, repeated the architecture and logic design with improvements in circuits and packaging.

In August 1961, when NASA contracted the laboratory to develop the Apollo guidance, navigation, and control system, the mission and its hardware was defined in only very broad terms. A general purpose digital computer would be required to handle the data and computational needs of the spacecraft. Therefore a special arrangement of display and controls would be necessary for in-flight operations.

The boost phase of the mission, which was the Saturn system, had its own internal guidance system to put the command and service module in translunar trajectory Then the Apollo system took over to guide the mission to the moon.

In effect, navigating in space is the same as navigating on Earth. One might take a star sighting with a sextant. That information is put into the computer and from it the state vector, i.e. the position and velocity of the missile at any point of time, is computed. The computer orients the missile such that the change in velocity will cause the state vector to be updated so the missile will free-fall into the targeted point. While it is thrusting, the guidance system must control the attitude of the vehicle, the magnitude of the thrust in the case of the Lunar Excursion Module (LEM), and the direction of the thrust in the case of the Command and Service module.

Design Constraints

Initially the need for a very reliable computer with significant computational capacity and speed was clear. The design constraints included very limited size, weight, and power consumption. If the designers had known then what they learned later, or had a complete set of specifications been available as might be expected in today's environment, they would probably have concluded that there was no solution with the technology of the early sixties.

Establishing interface requirements was a monumental task. The astronaut interface was one of these. In 1962, computers were not considered user friendly. Heated debates arose over the nature of the computer displays. One faction, which usually included the astronauts, argued that meters and dials were necessary. Logically, the pressure for digital displays won most of the arguments because of their greater flexibility in the limited area allowed for a control panel. In late 1963, as the requirements for the LEM were being firmed up, NASA decided to use identical guidance computers in both the command module and the LEM.

Major units of the CM Guidance. Navigation and Control System.

In the early manned orbital missions before Apollo, NASA learned that the human animal, confined in a spacecraft for a week or so, was not as clean as might be expected from observations on Earth. This additional constraint had a rather interesting and farreaching impact on the mechanical design of the computers and other hardware. All electrical connections and metallic surfaces had to be corrosive resistant and even though the computer was designed to have pluggable modules, everything had to be hermetically sealed.

The Suppliers

By the end of 1962, NASA selected three contractors: General Motors' AC Sparkplug Division for the inertial systems and system integration; Raytheon, Sudbury Division, for the computer and computer testing equipment; Kollsman Instrument for the optical systems; North American Aviation for the command and service module; and Grumman Aircraft for the Lunar Excursion Module.

In late 1959 and 1960 the lab began evaluating semiconductors, purchased at $1,000 each from Texas Instruments. Reliability, power consumption, noise generation, and noise susceptibility were the prime subjects of concern in the use of integrated circuits in the AGC. The performance of these units under evaluation was sufficient to justify their exclusive use in place of the core transistor logic proposed initially for the Apollo project design. The micrologic version of the Apollo computer was constructed and tested in mid 1962 to discover the problems that the circuits might exhibit when used in large numbers. Finally in 1964 Philco-Ford was chosen to supply the integrated circuits used in the proto type computer that operated in February 1965. These cost approximately $25 each.

Specifications

Approximately one cubic foot had been allocated in the command module for the computer. The first prototype was operating in the spring of 1964 and utilized the wire wrap and modular welded cordwood construction which had been produced for the Polaris program. It was designed to have pluggable trays with room for spare trays.

Since the clock in the computer was the prime source of time, it had to be accurate to within a few parts per million. The data and instruction words in the memory were 15 bits plus parity. Data was represented as 14-bit binary words plus the sign bit. Double precision operations were provided to supply 28-bit computations. The instruction word contained the address and operation codes for the computer operation. The memory address field was extended by organizing the memory in banks.

The AGC had 2,00015-bit words of erasable core memory and started with 12,000 words of readonly memory, called rope memory. It was quickly upgraded to 24,000 words. Then by mid-1964, when the first mission program requirements had been conceived and documented, there was increasing concern about the possible insufficiency of the memory. This prompted a further expansion to 36,000 words.

Design and Use of the Console

A display and keyboard was developed for the astronauts and had the designation DSKY (pronounced "Diskey'). Functionally the DSKY was an integral part of the computer, and two were mounted remotely and operated through the discrete interface circuits. One was for a sitting position and another one near the entry to the LEM, convenient for a reclining position.

The principle part of the DSKY display was a set of three numeric light registers. Each register contained 5 decimal digits consisting of segmented electroluminescent lights. Five decimal digits were used so that a computer word of 15 bits could be displayed in either decimal or octal. In addition, three two-digit numeric displays indicated the major program in progress, the verb code and the noun code. The verb/noun format permitted communication in a language whose syntax was similar to that of spoken language. Examples of verbs were display, monitor, load, and proceed. Examples of nouns were time, gimbal angles, error indications, and star identifications. Commands and requests were made in a form of sentences, each with a noun and a verb, such as display velocity or load desired angle. To command the computer the operator pressed the Verb key followed by a two digit code. This entered the desired verb into the computer. The operator then pressed the Noun key and a corresponding code. When the enter key was pressed, the computer carried out the operation that had been commanded. The computer requested action from the operator by displaying a verb and noun in flashing lights so as to attract the astronauts' attention.

The read-only memory of the computer consisted of six rope memory modules, each containing 6,000 words of memory. This special type of core memory depended on the patterns set at the time of manufacture. Its sensing wires were woven into a set pattern information. It had five times the density and was far more reliable than the coincident current core memory used for erasable storage in the computer. Being unalterable, it also provided a greater incentive for error-free software development. The AGC rope memory is on display in the primary memory case.

In-flight Use

Shortly after liftoff of Apollo 12, two lightning bolts struck the spacecraft. The current passed through the command module and induced temporary power failure in the fuel cells supplying power to the AGC. During the incident the voltage fail circuits in the computer detected a series of power trenches and triggered several restarts. The computer withstood these without interruption of the mission programs or loss of data.

The module in the background is exactly the same as one in the foreground, but it has only been used on Earth. The Museum's prototype computer ran at Draper Labs and was used to test the routines for the in-flight machines. In space all of the components had to be totally "potted" to insure that all the parts would stay firmly in place and remain uncontaminated during space flight.

The Apollo 11 lunar landing had an anomaly which attracted public attention. The computer in the LEM signalled a restart alarm condition several times during a very critical period prior to touchdown. This fact was broadcast to the public and those who knew its significance were close to a state of panic. After analysis, it was determined that the alarms were an indication to the astronauts that the computer was overloaded and was eliminating low priority tasks from the waitlist.

The overload resulted from the rendezvous radar being set in the wrong mode during the lunar landing phase, wasting computer memory cycles. The computer software was responding to overloads as designed.

This incident triggered a news brief in Datamation in October, 1969, faulting the computer design for being too slow. It rightfully claimed that there were a number of minicomputers, including the PDP-11, that were at least an order of magnitude faster. In the eight years since the initiation of the Apollo program commercial technology had far surpassed that of the Apollo design and capacity. However, no commercial computer could claim to match the power consumption and space characteristics of the AGC.

The Apollo Guidance Computer, shown on the left, was responsible for the guidance, navigation, and control computations in the Apollo space program. The AGC was the first computer to use an integrated circuit logic and occupied less than 1 cubic foot of the spacecraft. It stored data in 15 bit words plus a parity bit and had a memory cycle time of 11.7 microseconds, utilizing 2,000 words of erasable core memory and 36,000 words of read-only memory. The frame is made of magnesium for lightness and designed to hermetically seal the components. The interface with the astronauts was the DSKY shown on the right. It used digital displays and communicated with the astronauts using the verb and noun buttons visible in the photograph and two digit operation and operand codes. A set of status and caution lights is shown in the top left corner of the DSKY The AGC and DSKYare on display in the Four Generation Gallery.

Excerpted from an Illustrated Lecture, June 10, 1982, by Ben Goldberg. The video- tape is archived by The Computer Museum.

David Scott Astronaut for the Gemini 8, Apollo 9, and Apollo 15 missions.

In 1963 when NASA was conducting the selection of the third group of astronauts for the U.S. space program, I had just received a graduate degree at MIT and finished test pilots school. My interests and the program's need for a user to interact with the design of the guidance computer at the MIT Instrumentation Lab was a good fit. I was part of those discussions whether to use analog or digital controls that Eldon described.

The MIT Interface

When I was studying at MIT, the ability to rendezvous in space was an issue for debate. It wasn't clear whether it was possible to develop the mathematics and speed of computation necessary to bring two vehicles together at a precise point in space and time-a critical issue for the Apollo missions successful landing on the moon and return to Earth. Between 1963 and 1969, with the flight of Apollo 9 this was accomplished. I stayed in the spacecraft while Rusty Schweickart and Jim McDivitt got in the lunar module and went out about 60 miles away. The computer behaved flawlessly during our first successful rendezvous in space.

Another assignment for Apollo 9 was to take the first infra-red photographs of the Earth from space. To do this, a large rack of four cameras was mounted on the spacecraft. Since they were fixed to the spacecraft, the vehicle itself had to track a perfect orbit such that the cameras were precisely vertical with respect to the surface that they were photographing. During simulations it was determined that manual orbit procedures would be inaccurate. We were at a loss. About two weeks before the flight I called up MIT and asked if they could program the computer to give the vehicle a satisfactory orbit rate. They answered, "Of course, which way do you want to go and how fast?". In a matter of a couple of days we had a program and a simulator that automatically drove a spacecraft at perfect orbit rate. We got into flight with very little chance to practice or verify, but we put on the cameras and the results were perfect.

Potential Computer Failure

During the development process we ran many simulations of in-flight computer operations with particular concern for in-flight failure. But in the 10 years that I spent in the program there was never a real computer failure. Yet, people often wonder what a computer failure would have meant on a mission. It would have depended on the situation and the manner in which the computer failed. We probably would not have expired, but there were some parts of the mission in which a computer fail- ure would have been especially compromising. Navigation was not necessarily time critical but the lu- nar landing was very time critical. You could have a situation during a lunar landing in which, if the computer failed, the engine would be driven into the ground. Unless the astronaut could react quickly enough to stop it, the Lunar Module could have been flung on its side. Chances are that the astronaut could prevent such an event by switching to manual control of the vehicle. It must be remembered that the computer had been de- signed to be as reliable as pos- sible and the astronauts had a great amount of confidence in the machine.

And Problems of Success

We had a backup called the entry monitor system, which had a graphic display based on the accelerometers in the spacecraft. With this display the vehicle could be flown manually using pre-drawn curves to be followed for attitude, g-loading, and velocity. It was reas- suring to know that we were still able to return to Earth even if the Apollo Guidance Computer failed. During reentry there was a scroll in the entry monitor system and we could see the computer tracking the predetermined curves all the way to the landing site. As our skills and the computer programs improved over the years of the Apollo program, we came down closer and closer to the carrier. Finally, by the last Apollo mission they didn't park the carrier on the landing point.

Excerpted by Ben Goldberg from remarks after Eldon Hall's Lecture, June 10, 1982.

In October, 1950, I joined the Whirlwind team. At that time the first thirty-two registers of toggle switch memory were working. The four variable flip-flop registers could be assigned to any one of the thirty-two addresses. They were able to demonstrate small mathematical programs such as the bouncing ball problem or solve simple differential equations. The first memory consisted of electrostatic storage tubes totaling 256 locations. We felt really rich with a full 256 variable registers to write our programs. We calculated the operation in the octal address and then looked up what was then called the sexidecimal conversion number (later the term hexadecimal was used). We had a little load program in the 32 registers and that bootstrapped the programs up into the memory in order to run them.

This 1951 photograph of Whirlwind shows Joe Thompson seated at the Flexowriter typewriting unit. Jack Gilmore is standing in front of the 256 x 256 point display used for alphanumeric and graphic representations of various computations. The display was utilized to plot solutions of partial differential equations for determining the optimal rate of pumping oil from underground caverns and also for displaying the optimal placement of television antennas for compliance with F.C.C. regulations.

The first thing that we were very anxious to do was to get an assembly program that would allow us to be able to write our programs using mnemonic symbols and expressing the numbers in decimal and octal. My boss, Charlie Adams, was concerning himself with that and so it became my job to write the assembly program. I'm fairly certain that if it is not the first, it is one of the very first assembly programs ever written. The only one that I know of that predates it was Wilkes' 'Load and Go' on the EDSAC.

In September, 1951, John Carr, later Chairman of Duke's Computer Science Department, and I wrote a document that explained how people could actually use subroutines in conjunction with assembly programs, so that they didn't have to write all the various utilities. People could write their programs in a relative fashion and then we would give them the library of subroutines and they'd actually pick out the tapes that they needed. We'd then string the tapes together and literally make a copy not only of their program but also of the subroutines. All of those would be pulled in through the bootstrap program and it would run. This was the indirect birth of the symbolic address. The thing that we discovered, I think I actually discovered it, was that when we ran the tape through twice, you could refer to an address above where you were, as opposed to everything going below. The two pass assembler came out of all that. I have a recollection of Charlie Adams and I briefing IBM's Nat Rochester on how to produce symbolic addresses.

The Ph.D. candidates who needed to use the Whirlwind really didn't know how to run the machine. There were full scale electronic technicians who knew how to bring it up, and most of the systems programmers like myself knew how to do it, as well as some of the engineers. It was a fairly routine procedure so I went to Charlie Adams and suggested that I could train two people right out of high school to be computer operators if I had enough funds to hire them for one year. Jay Forrester provided the funds and I went out to two local high schools and asked for students that were college material but didn't have the money for college. I hired Joe Thompson from Boston Technical High School (shown sitting down in the photograph) and Bill Kyle from Boston English. Within four or five months they were competent operators, and Joe stayed on to complete his degree at Lowell Tech in the eve- nings. One day Forrester came in and sat at the back of the room. He watched for about an hour while Bill and Joe completed eight or nine different jobs. Finally Jay said, "We've just created a new voca- tion." He also recognized this as the solution to the problem of computer operators for the SAGE project.

The flexowriter typewriting unit we used was a word process- ing system, originally designed for list processing and promotional mailings. It had a mechanical reader and would create a form letter in a loop with stop codes to key in the personal information. We used it as an integrated word processing system, circa 1951.

One Sunday afternoon in December 1951 the Whirlwind was featured on 'See It Now', Edward R. Murrow's program. Ron Meyer and I stayed up all weekend writing a program to display the trajectory of a Viking rocket on the display and another program that played Jingle Bells. They wired Jay Forrester with a mike and had the wire coming up his back with cables on the floor so he could walk from one part of the console to another. As he started to walk the wire snagged and the back of his coat started to come up. One of the CBS technicians decided that he was going to undo the snag and started to crawl across the floor like a commando. Forrester, not realizing that his coattails were at 90 degrees, couldn't understand why the technician was crawling towards him. We decided that Forrester was getting too distracted and so the technician was pulled back across the floor by his ankles. Meanwhile, Edward R. Murrow and Jay Forrester completed the interview which ended with Jingle Bells being played for the pre- Christmas viewers.

[The museum has archived a copy of the video tape of the Murrow in- terview in which Jack Gilmore may be seen loading the tape reader]

Extracted by Ben Goldberg from a Gallery Talk by Jack Gilmore, June 16, 1982.