Apollo Guidance Computer | 1966

Apollo Guidance Computer

 The Apollo Guidance Computer (AGC) was a digital computer designed for the Apollo program, installed in each Apollo Command Module (CM) and Apollo Lunar Module (LM). The AGC provided calculations and electronic interfaces for the spacecraft's navigation, guidance, and control. It was the first computer based on silicon integrated circuits (ICs) and had performance similar to the first home computers of the late 1970s, such as the Apple II, TRS-80, and Commodore PET.

The AGC had a 16-bit word length, consisting of 15 data bits and 1 parity bit. Most of the AGC's software was stored in a special read-only memory called "core rope memory," which was made by weaving wires through magnetic cores. There was also a small amount of read/write core memory.

Astronauts communicated with the AGC using a numeric display and keyboard known as DSKY (pronounced "DIS-kee"). The AGC and DSKY user interface were developed in the early 1960s by the MIT Instrumentation Laboratory for the Apollo program and first flew in 1966.

During Project Gemini, astronauts manually piloted the spacecraft, but in the Apollo project, most of the flying was handled by the computer, with manual flying occurring only briefly during lunar landing. Each lunar mission carried two AGCs, one in the Command Module and another in the Lunar Module. However, Apollo 7 was an Earth orbit mission, and Apollo 8 did not require a Lunar Module for its lunar orbit mission. The AGC in the Command Module was central to its guidance, navigation, and control (GNC) systems. The AGC in the Lunar Module operated the Apollo PGNCS (Primary Guidance, Navigation, and Control System), which was pronounced "pings."

Each lunar mission also had two additional computers. One was the Launch Vehicle Digital Computer (LVDC) mounted on the Saturn V rocket's instrumentation ring, and the other was the Lunar Module's Abort Guidance System (AGS, pronounced "ags"). The AGS was used if the Lunar Module's PGNCS failed and could lift off from the Moon and rendezvous with the Command Module, but it could not land.

The AGC was designed under the guidance of Charles Stark Draper at the MIT Instrumentation Laboratory, with hardware design led by Eldon C. Hall. Initial architectural work was performed by J.H. Laning Jr., Albert Hopkins, Richard Battin, Ramon Alonso, and Hugh Blair-Smith. The flight hardware was manufactured by Raytheon, and Herb Thaler was also a member of the architecture team.

After the introduction of IC technology in the 1963 Interplanetary Monitoring Platform (IMP), the AGC adopted integrated circuit (IC) technology. The Apollo flight computer was the first computer to use silicon IC chips. The Block I version used 4,100 ICs, each containing a single 3-input NOR gate. The subsequent Block II version (used for manned flights) used about 2,800 ICs, most of which were dual 3-input NOR gates, with a few expanders and sense amplifiers included. These ICs were produced by Fairchild Semiconductor and were made using resistor-transistor logic (RTL). They were created in flat-pack form and connected with wire wrap, with the wiring embedded in cast epoxy plastic.

One type of IC used in the AGC (dual 3-input NOR) allowed it to avoid problems encountered in other early IC computer designs. For example, the guidance computer of the Minuteman II missile had issues because it mixed diode-transistor logic and diode logic gates. NOR gates are universal logic gates that can create all other gates, but they require more gates to do so.

The AGC's memory consisted of 2,048 erasable magnetic core memory and 36,864 read-only core rope memory. Both types of memory had a cycle time of 11.72 microseconds. The memory word length was 16 bits, including 15 data bits and 1 parity bit. The internal 16-bit word format of the CPU consisted of 14 data bits, 1 overflow bit, and 1 sign bit (in one's complement representation).

The AGC's user interface was the DSKY (Display and Keyboard), commonly pronounced "DIS-kee." The DSKY had various indicator lights, a numeric display, and a calculator-style keyboard. Commands were entered as two-digit numbers, where the Verb specified the type of action to be performed, and the Noun specified the data affected by that action.

Each number was displayed through a green (530nm) high-voltage electroluminescent 7-segment display, which was driven by electromechanical relays, limiting the update speed. Three-digit signed numbers could be displayed in octal or decimal, typically used to show vectors like the spacecraft's attitude or required delta-V (change in velocity). Internal data was stored in metric units, but displayed values were shown in customary units familiar to American astronauts. This calculator-style interface was the first of its kind at the time.

The Command Module had two DSKYs connected to the AGC: one on the main instrument panel and the other located near the sextant for aligning the inertial navigation platform. The Lunar Module had one DSKY connected to the AGC. The Flight Director Attitude Indicator (FDAI) was controlled by the AGC and was located above the DSKY on the commander consoles of both the Command Module and LM.

The AGC's timing reference came from a 2.048 MHz crystal clock. This clock was divided twice to generate four frequencies of 1.024 MHz, which the AGC used for internal operations. The 1.024 MHz clock was divided again to produce a master frequency of 512 kHz, which was used to synchronize external systems of the Apollo spacecraft.

The master frequency was divided by 5 through a ring counter to create a 102.4 kHz signal, which was further divided into 17 stages from F1 (51.2 kHz) to F17 (0.78125 Hz). The F10 stage (100 Hz) was fed back to the AGC to increment the real-time clock and update other essential counters. The F17 stage was used to intermittently run the AGC while it was in standby mode.

The AGC had four 16-bit registers for general calculations, referred to as the central registers:

A: Accumulator for general calculations

Z: Program counter – address of the next instruction to execute

Q: Remainder value of DV commands and return address after TC commands

LP: Lower multiplication result after MP commands

Additionally, there were four locations in core memory corresponding to addresses 20 to 23, known as "edit locations." The values stored in these locations appeared as a single bit position shifted or rotated, one of which shifted right by 7 bits to extract one of the 7-bit interpretive operation codes. This operation was common to both Block I and Block II AGCs.

The AGC also had additional registers used during internal operations:

S: 12-bit memory address register, lower part of the memory address

Bank/Fbank: 4-bit ROM bank register, selects a 1-kilobyte ROM bank in fixed-switching mode

Ebank: 3-bit RAM bank register, selects a 256-word RAM bank in erasable-switching mode

Sbank (Super-bank): Extended 1-bit of Fbank, needed because the last 4 kilobytes of the 36-kilobyte ROM could not be accessed by Fbank alone

SQ: 4-bit sequential register; current instruction

G: 16-bit memory buffer register, used when moving data from memory

X: 'x' input of the adder (the adder performs all one's complement arithmetic operations)

Y: 'y' input of the adder

U: Not actually a register but the output of the adder (the one's complement sum of X and Y registers)

B: General-purpose buffer register, also used to prefetch the next instruction

C: Not a separate register but the one's complement of the B register

IN: Four 16-bit input registers

OUT: Five 16-bit output registers

AGC Instruction Set

The Apollo Guidance Computer (AGC) used an instruction set divided into basic and extended instructions. The instruction format consisted of a 3-bit opcode and a 12-bit memory address. The Block I AGC had a total of 11 instructions, which were categorized into basic and extended instructions. The first 8 were basic instructions, and the last 3 were extended instructions executed through special instruction sequences.

Basic Instructions (directly accessible with 3-bit opcodes)

TC (Transfer Control):

This instruction unconditionally branches to the address specified in the instruction.

The return address is automatically stored in the Q register, allowing TC instructions to be used for subroutine calls.

CCS (Count, Compare, and Skip):

A complex conditional branching instruction that loads data from the address specified in the instruction into the A register.

It then calculates the decreased absolute value (DABS) and stores it in the A register. Depending on the value in the A register, it skips to one of four branches.

The CCS instruction was frequently used in loops or conditional branching, playing a crucial role in creating loops in the AGC.

INDEX (Index):

Modifies the address of the next instruction by adding data from the address specified in the instruction. This is used for processing arrays or tables.

RESUME (Resume):

A special form of the INDEX instruction defined as INDEX 25. This instruction is used to resume execution from the point where an interrupt occurred.

XCH (Exchange):

An instruction that exchanges the contents of the A register and memory. If the memory address is in read-only memory (ROM), the memory's contents are unaffected, and the value from the A register is loaded. However, in erasable memory (RAM), overflow correction may occur.

CS (Clear and Subtract):

An instruction that loads the one's complement value from the memory address specified in the instruction into the A register.

TS (Transfer to Storage):

An instruction that stores the value of the A register at the specified memory address. The TS instruction detects overflow and corrects it to handle multiple precision addition/subtraction. If an overflow occurs, the upper bit is sent to memory, and the A register is changed by +1 or -1.

AD (Add):

An instruction that adds the contents of memory to the A register and stores the result in the A register. The leftmost two bits of the A register can indicate overflow status, and overflow may occur when adding two or more numbers.

Extended Instructions (accessed through special TC instructions)

MASK (Bitwise Operation):

An instruction that performs a bitwise AND operation between the value in memory and the value in the A register, storing the result in the A register.

MP (Multiply):

An instruction that multiplies the contents of the A register with the data at the specified memory address, storing the high multiplication result in the A register and the low multiplication result in the LP register. The sign of the multiplication result matches.

DV (Divide):

An instruction that divides the contents of the A register by the data at the specified memory address, storing the quotient in the A register and the remainder in the Q register. The AGC handles fixed-point numbers, so if the divisor is smaller than the dividend, incorrect results may occur.

SU (Subtract):

An instruction that subtracts the data from the memory address specified in the instruction from the A register and stores the result in the A register.

The AGC's instructions were executed in groups consisting of 12 timing pulses (timing cycles). Each timing pulse could trigger up to 5 control pulses to perform actual operations. For example, the MP (Multiply) instruction used 8 sub-sequences, with the first sequence, MP0, followed by 6 repetitions of the MP1 sequence, and finally executing the MP3 sequence. In Block II, the multiplication instruction was reduced to 3 sub-sequences.

In the AGC, memory was organized into banks of 1 kilobyte with 12-bit addresses, with the first bank used for erasable memory (RAM) and the remaining banks used for fixed memory (ROM). Each instruction communicated data through memory addresses, and memory cycles were executed over 12 timing pulses.

Interrupts and Involuntary Counters

The AGC supported five vectorized interrupts:

Dsrupt: Triggered at periodic time intervals to update the user display (DSKY).

Erupt: Generated when various hardware errors or warnings occurred.

Keyrupt: Occurred when a key was pressed on the user's keyboard.

T3Rrupt: Periodically generated by a hardware timer to update the AGC's real-time clock.

Uprupt: Occurred whenever 16-bit uplink data was loaded into the AGC.

When responding to each interrupt, the AGC temporarily paused the currently executing program, executed a short interrupt service routine, and then resumed the paused program.

The AGC also had 20 involuntary counters. These functioned as up/down counters or shift registers in memory locations. Counters could increment or shift in response to internal inputs. Increments were handled by micro-instruction sub-sequences called Pinc, decrements by Minc, and shifts by Shinc, which were inserted between two general instructions.

Interrupts could occur when a counter overflowed. The T3rupt and Dsrupt interrupts were triggered when a counter driven by a 100Hz hardware clock overflowed, occurring after many Pinc sub-sequences were executed. The Uprupt interrupt occurred when a counter executed the Shinc sub-sequence to shift 16-bit uplink data into the AGC.

Standby Mode

The AGC had a power-saving mode controlled by a standby enable switch. In this mode, all AGC power was turned off except for the 2.048 MHz clock and scaler. The F17 signal from the scaler turned the AGC power back on and reactivated the AGC at 1.28-second intervals. In this mode, the AGC performed essential functions and checked the standby enable switch, turning off power and going back to sleep if still activated.

In standby mode, the AGC spent most of its time asleep, so it could not execute the Pinc instruction needed to update the real-time clock at 10ms intervals. To compensate, the AGC performed a function to update the real-time clock by 1.28 seconds each time it woke from standby mode.

The standby mode was designed to save 5-10W of power when the AGC was not needed during mid-course flight. However, in practice, the AGC remained powered on throughout all flight phases, and this feature was not utilized.

Data Bus

The AGC had a 16-bit read bus and a 16-bit write bus. Data could be gated from the central registers (A, Q, Z, or LP) or other internal registers to the read bus. The read bus was connected to the write bus through an inverting buffer, and data appearing on the read bus also appeared on the write bus. Other control signals could copy the data from the write bus back to the registers.

Data transfer worked as follows: to move the address of the next instruction from the B register to the S register, the RB (Read B) control signal was issued, which moved the address from the B register to the read bus and then to the write bus. The WS (Write S) control signal moved the address from the write bus to the S register.

Data could be read from multiple registers to the read bus simultaneously. In this case, the data from each register was synthesized onto the read bus using an included OR operation. This included OR function was used to implement the Mask instruction and was utilized for performing logical AND operations. While the AGC could not perform logical AND operations directly, it implemented an equivalent operation by applying De Morgan's theorem, utilizing logical OR through the bus and complementing (inverting) through the C register. This was achieved by inverting both operands, performing a logical OR operation through the bus, and then inverting the result again.

Software

The AGC software was written in AGC assembly language and stored in rope memory. Most of the software was stored in read-only rope memory, which could not be changed during operation, but some critical software was stored in standard read-write magnetic core memory, which astronauts could overwrite using the DSKY interface. For example, during Apollo 14, some software was overwritten in this manner.

The AGC was controlled by a simple real-time operating system designed by J. Halcombe Laning. This operating system included a batch job scheduling system called Exec and an interrupt-based preemptive scheduler called Waitlist. Exec supported cooperative multitasking, while Waitlist scheduled timer-based tasks to control operations. Tasks were short execution units that could reschedule themselves or start longer tasks through Exec. Calculations used metric units, but display outputs were shown in feet, feet per second, and nautical miles, units familiar to Apollo astronauts.

The AGC had a software interpreter developed by the MIT Instrumentation Laboratory, allowing the AGC to implement more complex and functional pseudo-instructions that it originally did not support. This interpreter executed a virtual machine and supported 16-bit and 24-bit double-precision trigonometry, scalar and vector arithmetic, and even MXV (matrix × vector) instructions. The interpreter code could be mixed with AGC native code. While the execution time of the interpreter code was longer, it required less memory, allowing for memory savings when adding new instructions to the AGC. On average, pseudo-instructions took about 24ms to execute.

The AGC software also provided a set of interrupt-based user interface routines called Pinball to handle keyboard and display services. Astronauts could use these routines to display specific memory locations in octal or decimal and use monitor routines to periodically refresh specific memory locations. Routines to initiate tasks were also provided.

The design principles of the AGC developed by the MIT Instrumentation Laboratory played a crucial role in establishing the foundations of software engineering, including asynchronous software, priority scheduling, testing, and human-machine collaborative decision-making capabilities. When the AGC design requirements were defined, the necessary software and programming techniques did not exist, so they had to be designed from scratch.

Block II

The Block II version of the AGC was designed in 1966. While maintaining the basic Block I architecture, erasable memory increased from 1 kilobyte to 2 kilobytes, and fixed memory expanded from 24 kilobytes to 36 kilobytes. The instruction set grew from 11 to 34 instructions, and I/O channels were introduced to replace the I/O registers of Block I. The Block II version was the actual AGC version that went to the Moon. Block I was used in the unmanned Apollo 4 and 6 flights and was also installed in the unfortunate Apollo 1.

The decision to expand memory and the instruction set in Block II led to interesting design outcomes. Various tricks were used to insert additional instructions while maintaining the limited 3-bit operation code and 12-bit address of Block I. For example, a special reference to specific memory addresses was used to implement certain functions. For instance, referencing address 25 executed the RESUME instruction that returned from an interrupt, address 17 executed the INHINT (interrupt inhibit) command, and address 16 reactivated the interrupt with the RELINT command. Other instructions were implemented by prefixing them with a special TC version called EXTEND. The address space was expanded through bank (fixed) and Ebank (erasable) registers using fixed and erasable memory, so the memory that could be addressed at any given time was limited to the current bank and a small amount of fixed-fixed memory and erasable memory. Additionally, since the bank registers could address up to 32 kilobytes, the Sbank (super-bank) register was needed to access the last 4 kilobytes. All cross-bank subroutine calls had to restore the original bank using special functions through fixed-fixed memory before returning. Essentially, this was a distant pointer system.

The Block II AGC also had the EDRUPT instruction (the name is an abbreviation for "Ed's Interrupt," named after the programmer Ed Smally who requested this instruction). This instruction does not generate an interrupt but performs two tasks typically executed during interrupt handling. The first task is to inhibit additional interrupts, which can only be reactivated with the RESUME instruction. The second task is to load the current value of the program counter (Z) into the ZRUPT register. This instruction was used only once in Apollo software, and its purpose was to set up the digital autopilot (DAP) cycle termination sequence for the Lunar Module. It is believed that this instruction caused issues when emulating the Luminary software of the LEM AGC.

1201 and 1202 Program Alarms

During the lunar landing of Apollo 11, the AGC generated the 1202 alarm (“Executive overflow - NO CORE SETS”) and the 1201 alarm (“Executive overflow - NO VAC AREAS”). The AGC's response was a soft restart, caused by rapid and continuous cycle stealing from the rendezvous radar, which had been intentionally left in standby mode in case it was needed during landing.

During the landing process, the AGC's processor was typically loaded to about 85%. With an additional 6,400 cycles being stolen per second, the processor load increased by about 13%, leaving barely enough time to complete all scheduled tasks. Five minutes before landing, Buzz Aldrin entered the command 1668 into the computer. This command instructed the AGC to periodically calculate and display DELTAH (the difference between the radar-detected altitude and the calculated altitude). The 1668 command increased the processor workload by another 10%, triggering the executive overflow and the 1202 alarm. Afterward, Aldrin received a "GO" command from Houston and re-entered the 1668 command, which again triggered the 1202 alarm. Reporting the second alarm, Aldrin said, "It seems that this alarm occurs when 1668 is executed."

The AGC software was designed using priority scheduling and automatically recovered. It deleted the lower-priority task of the 1668 display operation and completed the critical guidance and control tasks. The guidance controller, Steve Bales, and his support team (including Jack Garman) successfully led the landing by sending multiple "GO" signals.

The root cause of the problem was not a software error in the AGC or a pilot mistake, but rather a hardware design bug that had already been identified and documented by the Apollo 5 engineers. However, since this issue had only occurred once during testing, the engineers concluded that it was safer to use the existing hardware than to test a new radar system. In actual hardware, the position of the rendezvous radar was encoded by synchros driven by two different 800Hz AC frequency sources, one of which was used as the timing reference for the computer. The two 800Hz sources were frequency-locked but not phase-locked, and slight random phase changes made the antenna appear to "vibrate" rapidly, although it was actually stationary. This virtual movement quickly generated cycle stealing.

Thanks to the software and computer design by J. Halcombe Laning, the Apollo 11 landing mission was successful. Without Laning's design, the landing would have been aborted due to a lack of a stable guidance computer.

Applications Beyond Apollo

Fly-by-Wire Testbed

The AGC formed the basis of an experimental fly-by-wire (FBW) system installed in the F-8 Crusader aircraft. This system was used to demonstrate the practicality of computer-driven FBW. The AGC used in the first phase of the program was replaced by another machine in the second phase, and this research led to the development of FBW systems for the Space Shuttle. The AGC also indirectly contributed to the development of fly-by-wire systems for next-generation fighter aircraft that were under development at the time.

Source Code Release

In 2003, Ron Burkey initiated the Virtual AGC project, aiming to restore the source code of the Apollo Guidance Computer (AGC) and create a functional emulator. As part of this project, the original code, transcribed and digitized from hard copies from the 1960s, was made available through the Virtual AGC project and the MIT Museum. This effort gained renewed attention in mid-2016 when former NASA intern Chris Garry uploaded the code to GitHub, attracting significant media interest.