The Apollo Guidance Computer: An Electrical Engineering Perspective
Alright, let’s dive into the fascinating world of the Apollo Guidance Computer, or AGC. Think of it not just as an old calculator, but as a groundbreaking piece of engineering that played a vital role in getting humans to the Moon. For us folks interested in electrical engineering, it’s a treasure trove of early digital design challenges and solutions.
What Was the AGC?
So, the Apollo Guidance Computer was basically the brains of the Apollo spacecraft. It was a digital computer specifically built for the Apollo program. Every Command Module and Lunar Module had one installed. Its main job was to handle the guidance, navigation, and control of the spacecraft.
What’s cool from an engineering standpoint is that the AGC was among the very first computers to use silicon integrated circuits (ICs). This was a big deal back in the 1960s! While its raw power might seem small compared to today’s gadgets – maybe similar to home computers from the late 1970s like an Apple II or TRS-80 – it was incredibly advanced for its time and built to be robust and reliable in the harsh environment of space. It was pretty compact too, roughly the size of a small microwave oven, holding about 4,100 IC packages in the early version.
The AGC used a 16-bit word length. This means it handled data in chunks of 16 bits. Out of these 16 bits, 15 were for the actual data, and one was a parity bit, which was used to check if the data had gotten corrupted.
Most of the programs the AGC ran were stored in a special kind of memory called core rope memory. This was like the computer’s permanent instruction manual, literally woven from wires! There was also a small amount of regular core memory that the computer could write to and read from, used for temporary data and variables.
Astronauts talked to the AGC using a simple setup called the DSKY (pronounced “DIS-kee”). This stood for “display and keyboard.” It had indicator lights, some numeric displays, and a keyboard similar to an old calculator.
The AGC and its DSKY were developed starting in the early 1960s by the MIT Instrumentation Laboratory. The first time an AGC actually flew was in 1966. It’s worth noting that while the onboard AGC was critical, NASA also relied on bigger mainframe computers back in Houston for primary navigation calculations, especially during launch and trajectory updates. The AGC often cross-checked or executed commands based on Houston’s data.
Where Did the AGC Fit In?
In the earlier Gemini program, astronauts flew their spacecraft mostly by hand using control sticks. But for Apollo, the computer took over much of the flight control. Astronauts would still take manual control during critical phases like lunar landing, but the AGC was always there, doing calculations and providing data.
Each Moon mission had two AGCs: one in the Command Module (the part that stayed in orbit) and one in the Lunar Module (the part that landed on the Moon). The AGC in the Command Module was the heart of its Guidance, Navigation, and Control (GNC) system. In the Lunar Module, the AGC was the main part of its Primary Guidance, Navigation, and Control System (PGNCS), often pronounced “pings.”
Besides the AGCs, there were other computers involved in the Apollo missions:
- The Launch Vehicle Digital Computer (LVDC): This was on the Saturn V rocket itself, specifically in the part called the instrument unit, and it handled the rocket’s guidance and control during ascent.
- The Abort Guidance System (AGS): Pronounced “ags,” this was a backup computer in the Lunar Module. If the main PGNCS (the AGC) failed, the AGS could be used for emergencies, like taking off from the Moon and linking back up with the Command Module, but it couldn’t handle the landing.
How Was It Built? (The Design Side)
The AGC was a product of brilliant minds at the MIT Instrumentation Laboratory, led by folks like Charles Stark Draper and Eldon C. Hall (who led the hardware design). Key architectural ideas came from people like J. H. Laning Jr., Albert Hopkins, Richard Battin, Ramon Alonso, and Hugh Blair-Smith. Raytheon actually built the flight hardware.
An interesting detail about the manufacturing was how the chips were connected. Instead of soldering them, which is common today, they were often resistance-welded onto the circuit boards according to the original drawings.
The Logic Behind It: Integrated Circuits
As mentioned, the AGC was a pioneer in using integrated circuits (ICs). Following a successful use in a satellite called the Interplanetary Monitoring Platform (IMP) in 1963, ICs were chosen for Apollo. The AGC was one of the very first computers built with these silicon chips.
Integrated Circuit (IC): Also known as a chip, this is a small electronic component made on a piece of semiconductor material (like silicon) that contains many tiny electronic circuits (like transistors, resistors, capacitors) fabricated together. Using ICs allowed for much smaller and more complex circuits than building with individual components.
The early version (Block I) used about 4,100 ICs. Each of these ICs contained a single three-input NOR gate. Later, the version that flew the Moon missions (Block II) was more efficient, using around 2,800 ICs, mostly containing dual three-input NOR gates (meaning two NOR gates on one chip) and fewer other types like expanders and sense amplifiers.
These ICs were based on resistor–transistor logic (RTL) and came in a flat-pack shape. After the welding, the connections (often made with wire wrap) were embedded in epoxy plastic for protection and structural integrity.
NOR Gate: A fundamental digital logic gate. Its output is TRUE (or 1) only if all of its inputs are FALSE (or 0). If any input is TRUE, the output is FALSE (or 0). NOR gates are considered “universal gates” because you can build any other logic gate (like AND, OR, NOT, NAND, XOR) just by combining NOR gates.
Resistor–Transistor Logic (RTL): An early type of digital circuit design that used resistors to feed logic signals into transistors. It was simpler than later logic families like DTL or TTL but had limitations in terms of speed and power consumption.
Using just one main type of IC (the dual NOR3 in Block II) simplified the design and manufacturing compared to computers that mixed different logic families. While using only NOR gates sometimes meant needing more gates overall to build a circuit, it made the design process more standardized and less prone to certain types of errors seen in other early IC computers.
Memory System: Woven and Wired
The AGC had two types of memory:
- Erasable Memory: This was like the computer’s scratchpad or RAM. It used magnetic core memory and could be read from and written to. The Block II AGC had 2,048 words of this.
- Fixed Memory: This was like the computer’s permanent program storage or ROM. It used a special technology called core rope memory. The Block II AGC had a large 36,864 words of this.
Magnetic Core Memory: An early type of computer memory that stored data by magnetizing tiny rings (cores) of magnetic material. It was non-volatile (held its data when power was off) but relatively slow and bulky compared to modern semiconductor memory.
Core Rope Memory: A type of read-only memory (ROM) used in the AGC. Data was stored by physically threading (weaving) wires through or around magnetic cores. Whether a wire passed through or around a core determined if it represented a binary 0 or 1 at that position. This made the memory non-volatile and extremely reliable, but it was literally “programmed” by human weavers, making it very slow and expensive to change!
Both types of memory in the AGC had a cycle time of about 11.72 microseconds. This is the time it took to read or write a word of data.
The memory word length was 16 bits, as mentioned earlier. For data storage in memory, this was 15 data bits plus one parity bit. However, inside the CPU’s registers, the 16 bits were used differently: 14 data bits, one overflow bit (to indicate if a calculation result was too large), and one sign bit. The AGC used ones’ complement to represent negative numbers.
Parity Bit: An extra bit added to a binary number to make the total number of 1s either always odd (odd parity) or always even (even parity). This is a simple way to detect single-bit errors during data transfer or storage. The AGC used odd parity.
Ones’ Complement: A method of representing signed binary numbers. To find the ones’ complement of a number, you flip all the bits (0s become 1s, and 1s become 0s). This method has some quirks, notably having two representations for zero (all 0s for +0 and all 1s for -0) and requiring special handling for addition carries that wrap around.
Talking to the Computer: The DSKY
The DSKY was the astronaut’s primary way to interact with the AGC. It wasn’t a graphical interface like we use today, but a simple numeric display and keyboard.
DSKY (Display and Keyboard): The user interface of the Apollo Guidance Computer. It consisted of a numeric keypad, function keys, indicator lights, and three five-digit numeric displays.
Astronauts would enter commands using two-digit codes: a Verb and a Noun.
- Verb: Described the action they wanted the computer to perform (e.g., display something, start a program).
- Noun: Specified the data or system component the action should apply to (e.g., display the spacecraft’s attitude, start the lunar landing radar program).
The numeric displays were glowing green (using electroluminescent technology) and showed numbers using seven-segment displays. These were pretty slow to update because they were driven by electromechanical relays. The displays could show up to three five-digit numbers, often used for displaying important values like position or velocity, usually in octal or decimal format. Interestingly, even though the computer did all its internal calculations using the metric system, the DSKY displayed results in units the astronauts were used to: feet, feet per second, and nautical miles.
This Verb/Noun, calculator-style interface was quite innovative for its time and was one of the first of its kind.
The Command Module had two DSKYs: one easily accessible on the main control panel and another in a lower bay near the sextant (a navigation tool). The Lunar Module had just one DSKY. Both modules also had a Flight Director Attitude Indicator (FDAI), a display similar to an aircraft’s attitude indicator, controlled by the AGC to show the spacecraft’s orientation.
Keeping Time: Timing System
The AGC’s sense of time came from a 2.048 MHz crystal clock. This master clock signal was divided down to create the various timing signals needed by the computer and other spacecraft systems.
- Dividing by 2 gave a 1.024 MHz four-phase clock, used for the AGC’s internal operations.
- Dividing the 1.024 MHz clock by 2 gave a 512 kHz signal, called the master frequency. This was used to synchronize other systems in the spacecraft.
The 512 kHz signal was further divided down by a component called the scaler.
- Dividing by 5 using a ring counter produced a 102.4 kHz signal.
- This was then divided repeatedly by 2 through 17 stages (F1 through F17).
- The F10 stage (100 Hz) was sent back into the AGC. This signal was used to update the real-time clock and trigger certain automatic counter updates within the computer using special processes called
Pinc(discussed later). - The F17 stage (0.78125 Hz), which is very slow (less than once a second), was used in a power-saving standby mode.
Holding Data: Registers
Computers use registers to hold data that the central processing unit (CPU) is actively working on or needs quick access to. The AGC had several registers.
Register: A small, high-speed storage location within a computer’s CPU (or closely associated with it) used to temporarily hold data, instructions, or memory addresses that the CPU is currently processing.
The main ones, called the central registers, were 16 bits wide:
- A: The Accumulator. This was the primary register for arithmetic and logical operations. Most calculations involved the A register.
- Z: The Program Counter. This register always held the memory address of the next instruction the computer needed to execute.
- Q: Used for two purposes: it held the remainder after a
DV(divide) instruction and, importantly, stored the return address when the computer jumped to a subroutine using theTCinstruction. This allowed the program to know where to come back to. - LP: Held the lower product after an
MP(multiply) instruction. Since multiplying two 16-bit numbers can result in a number larger than 16 bits, the result was split: the higher part went into the A register, and the lower part went into LP.
There were also some specific memory locations (addresses 20-23) that acted like special registers, offering bit-shifting or rotation when accessed.
Beyond the central registers, the AGC had several other registers used internally for managing operations, memory access, and I/O:
- S: A 12-bit memory address register. Held the specific address within a memory bank that the computer wanted to access.
- Bank/Fbank: A 4-bit register used to select which 1-kiloword bank of fixed (ROM) memory the computer was currently looking at, specifically in the “fixed-switchable” area.
- Ebank: A 3-bit register used to select which 256-word bank of erasable (RAM) memory the computer was currently looking at in the “erasable-switchable” area (in Block II).
- Sbank (Super-bank): A 1-bit register needed in Block II to access the very highest bank of fixed memory (the last 4 kilowords), as Fbank alone wasn’t enough.
- SQ: A 4-bit register holding the opcode (the part of the instruction that says what to do) of the instruction currently being executed.
- G: A 16-bit memory buffer register. Data being read from or written to memory temporarily passed through this register.
- X: One of the inputs to the computer’s adder circuit. Used in arithmetic operations.
- Y: The other input to the adder circuit.
- U: Not a physical register, but represented the output of the adder (the result of X + Y in ones’ complement).
- B: A general-purpose buffer register. It also played a key role in fetching the next instruction. The next instruction’s opcode and address were loaded into B, and then transferred to SQ and S registers respectively to start the next execution cycle.
- C: Not a separate register, but essentially the ones’ complement (inverted value) of the data in the B register. This was useful for operations involving subtraction or logical NOT.
- IN: Four 16-bit input registers, used to receive data from external spacecraft systems.
- OUT: Five 16-bit output registers, used to send commands and data to external spacecraft systems.
The Commands: Instruction Set
The AGC understood a set of commands called its instruction set. Each instruction was typically encoded in a 16-bit word (though sometimes instructions were modified by preceding ones). The basic format used 3 bits for the opcode (what operation to perform) and 12 bits for the address (where to get the data or jump to).
Opcode (Operation Code): The part of a computer instruction that specifies which operation is to be performed (e.g., add, subtract, jump).
Address: A number that identifies a specific location in memory where data or an instruction is stored.
The Block I AGC had 11 instructions. Eight were considered basic instructions and were directly represented by the 3-bit opcode. The other three were extracode instructions, meaning they required a special instruction called EXTEND right before them to signal that the next instruction wasn’t one of the basic eight.
Here’s a look at the main instructions (these descriptions apply generally to Block I and Block II, though Block II added more and refined some):
TC(Transfer Control): This instruction told the computer to jump to a different location in the program specified by the instruction’s address. It’s like a “goto” command. Crucially, before jumping, it automatically saved the address of the next instruction in theQregister. This madeTCperfect for calling subroutines (blocks of reusable code), because the subroutine could use the address inQto know where to return when it finished.CCS(Count, Compare, and Skip): A complex instruction used for conditional branching (doing different things based on a condition) and looping. It would load data from a memory address into the A register. Then, it would calculate the “diminished absolute value” (DABS) of the value in A and put the result back in A.- Diminished Absolute Value (DABS): For a positive number, DABS is the number minus 1. For a negative number, it’s the absolute value of the number minus 1. It’s “diminished” because it never goes below zero.
- After calculating DABS,
CCSwould perform a “four-way skip” – it would skip over the next 1, 2, 3, or 4 instructions depending on whether the original value in A (before DABS) was greater than 0, equal to +0, less than 0, or equal to -0. This complex skip allowed for various loop and conditional logic structures. It was often used for simple loops by decrementing a counter and skipping back to the loop start until the counter hit zero.
INDEX: This instruction added the value retrieved from a memory address to the next instruction’s address. This was super useful for accessing elements in arrays or looking up data in tables. By adding an “index” value to a base address, you could point to different data locations. It could even be used to modify the opcode of the following instruction in clever ways.RESUME: A special case of theINDEXinstruction (specifically,INDEXwith address 25 in Block II). This was the standard way for the AGC to return from handling an interrupt, causing the program to continue exactly where it was interrupted.XCH(Exchange): Swapped the data in the A register with the data at a specified memory address. If the memory location was in fixed (read-only) memory, it acted like aLOADinstruction, just putting the memory content into A without changing memory. If it was erasable memory, it performed the swap.CS(Clear and Subtract): Loaded the A register with the ones’ complement of the data from a specified memory address. This is equivalent to loading the negative of the number.TS(Transfer to Storage): Stored the data in the A register into a specified memory address. This instruction also had special behavior related to overflow in arithmetic, which was important for doing arithmetic on numbers larger than 15 bits (multi-precision arithmetic). If an overflow occurred during a calculation that resulted in the value in A, theTSinstruction would adjust A and skip the next instruction, allowing the program to handle the carry-over needed for multi-precision math.AD(Add): Added the data from a specified memory address to the current value in the A register, storing the result back in A. The AGC’s ones’ complement arithmetic allowed for some limited “overflow” conditions in the A register without immediate errors, as long as the final sum didn’t exceed the register’s capacity by too much.MASK: Performed a bit-by-bit logical AND operation between the data from a memory address and the current value in the A register, storing the result in A. This is used to isolate or clear specific bits in a word.MP(Multiply): Multiplied the value in the A register by the data from a specified memory address. As mentioned, the result was split: the high part in A, the low part in LP (or L in Block II).DV(Divide): Divided the value in the A register by the data from a specified memory address. The quotient went into A, and the absolute value of the remainder went into Q (or the correctly signed remainder into L in Block II). The AGC treated numbers as fractions, so dividing a smaller number by a larger one was the expected operation; dividing by a smaller number could lead to unexpected results (no hardware protection against that).SU(Subtract): Subtracted (using ones’ complement arithmetic) the data from a specified memory address from the value in the A register, storing the result back in A.
Instructions weren’t executed in one go; they were broken down into smaller steps controlled by timing pulses. There were 12 timing pulses (TP1 through TP12) making up an instruction subsequence. Simple instructions took one subsequence. More complex ones, like multiply (MP), took several. Each timing pulse could trigger specific actions called control pulses, which actually moved data between registers, performed arithmetic, or interacted with memory.
How Memory Was Accessed: The Memory Cycle
The AGC’s memory was organized into banks of 1,024 words (1 kiloword).
- Bank 0: Erasable memory (RAM).
- Banks 1 and 2: Fixed-fixed memory (ROM). These were always accessible regardless of the memory bank selection registers.
- Banks 3 and higher: Fixed-switchable memory (ROM). To access these, the program had to load the bank number into a register (
BankorFbank).
An instruction’s 12-bit address field could directly point to any word in Bank 0 (erasable), Bank 1, or Bank 2 (fixed-fixed). To access words in the fixed-switchable banks (3 and up) or the erasable-switchable banks (in Block II), the bank registers had to be set correctly first. Block II expanded fixed memory significantly, needing an additional Sbank register to reach the highest banks.
Data moved between the CPU and memory using a process called the memory cycle. This cycle took 12 timing pulses (the same duration as a simple instruction, 11.72 μs) and happened continuously.
- At TP1, the address the CPU wanted to access was loaded into the S register.
- The memory hardware would then find the data word at that address.
- By TP6 (for erasable) or TP7 (for fixed), the data word was available in the G register (the memory buffer register).
- The CPU could access the data in G from TP7 through TP10.
- After TP10, the data in the G register was automatically written back to the memory location it came from.
This continuous cycle meant that even if the CPU just read from memory, the data was effectively “refreshed” back into the location. If the CPU modified the data in G (e.g., during a TS instruction), the modified data would be written back.
As mentioned, each 16-bit word in memory included an odd parity bit. Before writing a word, a circuit ensured the total number of ‘1’ bits was odd. During each memory cycle, a parity checking circuit verified this. If the parity was wrong, it meant a single bit error had likely occurred, and a “parity alarm” light came on, alerting the astronauts and triggering a system error flag.
Responding to Events: Interrupts and Counters
The AGC needed to react quickly to important events happening in the spacecraft, like a key press or a signal from the timer. It did this using interrupts. When an interrupt occurred, the computer would temporarily stop what it was doing, save its place (often using the RESUME instruction later), jump to a special small program (an interrupt service routine) to handle the event, and then return to the original task.
The AGC had five types of vectored interrupts:
Dsrupt: Triggered regularly to update the display on the DSKY.Erupt: Signaled various hardware problems or alarms.Keyrupt: Happened when an astronaut pressed a key on the DSKY keyboard.T3Rrupt: Generated by a hardware timer at regular intervals (based on the 100 Hz signal) to update the computer’s internal real-time clock.Uprupt: Triggered every time a 16-bit word of data was successfully received from Earth (uplinked) into the AGC.
Besides interrupts, the AGC had 20 involuntary counters. These weren’t general-purpose registers but specific memory locations (in erasable memory) that could be automatically incremented, decremented, or shifted by the hardware without the main program having to explicitly command it. These updates happened between normal instructions using tiny sequences of operations called Pinc (increment), Minc (decrement), or Shinc (shift).
Some interrupts were tied to these counters. For example, T3Rrupt and Dsrupt were triggered when certain counters, automatically incremented by the 100 Hz signal via Pinc operations, overflowed after a certain number of increments. The Uprupt was triggered after a counter used as a shift register, updated by the Shinc subsequence, had accumulated 16 bits of uplinked data.
Saving Power: Standby Mode
The AGC had a feature to save power, controlled by a switch labeled “standby allowed.” In this mode, most of the computer would shut down, except for the main 2.048 MHz clock and the scaler circuits. The very slow F17 signal (0.78125 Hz) from the scaler would periodically wake the AGC up (about every 1.28 seconds). When awake, the AGC would do a few quick essential tasks (like updating its real-time clock by 1.28 seconds to account for the sleep time and checking the standby switch), then turn itself off again if standby was still allowed.
This mode was intended to save about 5-10 Watts out of the AGC’s total power draw of around 70 Watts during long, quiet periods of the mission when the computer wasn’t needed constantly. However, in practice, the AGC was usually left running full-time throughout the missions, so this standby feature wasn’t actually used in spaceflight.
Moving Data Around: Data Buses
Inside the AGC, data moved between different parts (registers, memory) using data buses. The AGC had a 16-bit read bus and a 16-bit write bus.
Data Bus: A set of wires or electrical paths used to transfer data between different components within a computer or between computers. A “read bus” is typically used for data flowing from a component, and a “write bus” is used for data flowing to a component.
When a control signal instructed a register (like A, Q, Z, LP) to “read” its contents, the data was placed onto the read bus. The read bus was connected to the write bus through a simple buffer, so whatever was on the read bus also appeared on the write bus. Other control signals would then “write” the data from the write bus into a destination register. For example, to move data from register B to register S, a control signal would activate “read B” (RB), putting B’s content on the buses, and then “write S” (WS), copying the bus content into S.
A peculiar but important feature: multiple registers could be commanded to read onto the bus at the same time. When this happened, the electrical signals combined, effectively performing a bit-wise inclusive-OR operation on the data from all activated sources.
This ORing feature on the bus was cleverly used to implement the MASK instruction, which performs a logical AND. Since the AGC hardware could do OR and could complement (invert) data using the C register, the logical AND was implemented using De Morgan’s Theorem: A AND B is equivalent to NOT ((NOT A) OR (NOT B)). The AGC would invert the operands, OR them together on the bus, and then invert the result.
The Brains Within: Software
The AGC’s software was primarily written in its own assembly language. This is a low-level programming language where instructions correspond closely to the computer’s native instruction set. The programs were “stored” (woven) into the core rope memory. Because core rope was read-only, the main flight software couldn’t be changed once built and installed. A small part of the software, however, resided in the erasable magnetic-core memory and could be modified by astronauts via the DSKY if necessary, though this was rare.
Assembly Language: A low-level programming language that uses mnemonic codes (like
ADfor add,TCfor transfer control) to represent the computer’s basic instructions. Each assembly instruction usually translates directly into one or a few machine code instructions.Real-time Operating System (RTOS): A type of operating system designed to process data as it comes in, typically within strict time constraints. RTOSs are crucial in systems where timely responses are critical, like control systems for spacecraft or industrial machinery.
The AGC ran using a simple real-time operating system. This OS had two main parts:
- The ‘Exec’: A batch job scheduler that used cooperative multitasking. This meant programs (called “jobs”) would run one after another, and each job was expected to voluntarily give up control periodically so others could run.
- The ‘Waitlist’: An interrupt-driven pre-emptive scheduler. This handled shorter, time-critical tasks (called “tasks”) that needed to run at specific times or in response to interrupts. A task could interrupt a running job or even another task if it had higher priority. Tasks could reschedule themselves to run again later or start longer-running “jobs” with the Exec.
As mentioned earlier, calculations inside the computer used the metric system, but the DSKY converted and displayed values in US customary units.
A significant part of the AGC software’s capability came from a software interpreter. Developed by MIT, this interpreter created a virtual machine on top of the native AGC hardware.
Interpreter: In computing, a program that directly executes instructions written in a programming language, without requiring them to be pre-compiled into native machine code. It reads and runs the source code (or a form of it) one instruction at a time.
Virtual Machine: An emulation of a computer system. It can be based on hardware or software. In the AGC’s case, the interpreter created a software-based virtual machine that understood a richer set of instructions than the native AGC hardware did.
The interpreter allowed programmers to write code using a set of pseudo-instructions that were much more powerful and complex than the AGC’s basic 11 (or 34 in Block II) native instructions. These pseudo-instructions included complex math operations like double-precision trigonometry, scalar and vector arithmetic, and even matrix-vector multiplication.
Why use an interpreter? While interpreted code runs slower because the interpreter has to read and execute each pseudo-instruction using a sequence of native AGC instructions, it offered a much richer instruction set. More importantly for the time, it dramatically reduced the amount of precious memory needed to store complex navigation programs compared to trying to implement all those operations directly with native AGC instructions. Memory was extremely expensive and limited back then. An average pseudo-instruction took about 24 milliseconds to execute.
The assembler used to write AGC code was called YUL. It helped manage the transitions between native AGC code and interpreted code.
The AGC also had routines for interacting with the astronauts, collectively called ‘Pinball’. These handled the DSKY keyboard inputs and display outputs, driven by interrupts. Astronauts could use specific Verb/Noun commands to access routines (like ‘Monitor’) to display the contents of memory locations or start jobs.
The software development for the AGC, particularly the complex guidance and navigation algorithms, was groundbreaking. It established principles that became foundational in modern software engineering, especially for creating reliable systems that handle tasks asynchronously, manage priorities, require rigorous testing, and involve human operators in the loop. Since suitable software methods didn’t exist, they had to be invented! Richard Battin’s earlier work on trajectory and guidance was crucial. The software packages had names: CORONA for the first Command Module flights, COLOSSUS for the Command Module on lunar missions, and LUMINARY for the Lunar Module. Margaret Hamilton led the team responsible for implementing many of the details in these programs. She famously focused on predicting and handling potential human errors via the DSKY interface, which proved critical later on. The sheer scale was huge – 1,400 person-years of effort and up to 350 people working on it. Hamilton received the Presidential Medal of Freedom for her contributions.
The AGC’s software design significantly influenced later systems, including those on Skylab, the Space Shuttle, and early fighter aircraft fly-by-wire systems. Its importance led some to call it “The fourth astronaut” for its indispensable role.
Moving to Block II
The Block I AGC was used on uncrewed Apollo flights (Apollo 4, 6) and was on the ill-fated Apollo 1. An improved version, Block II, was designed in 1966 and was the one that actually flew on crewed missions to the Moon.
Block II kept the basic architecture but had key upgrades:
- Increased erasable memory (RAM) from 1 kiloword to 2 kilowords.
- Increased fixed memory (ROM) from 24 kilowords to 36 kilowords.
- Expanded the instruction set from 11 basic instructions to 34.
- Introduced dedicated I/O channels to handle communication with external systems, replacing the simpler input/output registers of Block I.
Even with 34 instructions, the AGC still used a 3-bit opcode and a 12-bit address field in its instruction format. This limitation meant engineers had to get creative to fit in the new instructions and access the larger memory. Tricks included:
- Assigning special functions to specific memory addresses when used with certain instructions (like
INDEX 25triggeringRESUME). - Using the
EXTENDinstruction before others to indicate a wider range of opcodes. - Using the
BankandEbankregisters to switch between larger blocks of memory. TheSbankregister was needed in Block II specifically for accessing the very highest range of fixed memory. - Creating special “far pointer” routines, often located in fixed-fixed memory, to manage calling subroutines located in different, switchable memory banks and ensuring the correct bank was restored upon return.
Block II also added a peculiar instruction called EDRUPT. Despite the name (a contraction of “Ed’s Interrupt” after the programmer Ed Smally), it didn’t actually generate an interrupt. Instead, it performed two actions often associated with interrupt handling: it disabled further interrupts (requiring a RESUME to re-enable) and loaded the current program counter (Z register) into a special register (ZRUPT). This was used in a specific part of the Lunar Module’s autopilot software and is believed to cause issues for modern software emulators of that program.
A Real-World Test: The 1201 and 1202 Alarms
A famous moment showcasing the AGC’s design robustness happened during the Apollo 11 lunar descent. As the Lunar Module approached the Moon, the AGC suddenly displayed 1202 and 1201 program alarms.
- 1202 Alarm: “Executive overflow - NO CORE SETS”
- 1201 Alarm: “Executive overflow - NO VAC AREAS”
Both alarms meant the AGC’s “Exec” (the job scheduler) was overloaded and couldn’t keep up with all the requested tasks. The AGC’s designed response was a “soft restart” – it would stop non-essential tasks, reset its state slightly, and continue running critical functions.
The cause of the overload was unexpected signals coming from the Lunar Module’s rendezvous radar. This radar was intentionally left on standby during the descent (as a backup for an abort scenario), but it was flooding the AGC with requests for processor time (“cycle steals”). These requests were triggered by noisy signals from the radar’s antenna position sensors, which were getting power from a source slightly out of phase with the computer’s timing system. Even though the antenna was still, the computer perceived it as rapidly “dithering.”
Normally, the AGC’s processor was about 85% busy during descent. The radar cycle steals added about 13% more load. This was tight but manageable. However, about five minutes into the descent, astronaut Buzz Aldrin entered command “1668” on the DSKY. This command asked the AGC to calculate and display the difference between radar altitude and computed altitude (DELTAH). This single command added another 10% to the processor load, pushing it over the edge and triggering the 1202 alarm. When Aldrin tried “1668” again after being told “GO” by Houston, it triggered another alarm.
Crucially, the AGC software had been designed with priority scheduling. When overloaded, it automatically dropped lower-priority tasks to ensure the most critical tasks – guiding and controlling the spacecraft’s descent – could still run. The 1668 display task was low priority, so the AGC correctly discarded it to focus on landing.
Guidance controller Steve Bales and his support team in Houston, including subsystem manager Jack Garman, recognized the alarms indicated an overload but knew the AGC’s design meant it was prioritizing critical functions. They quickly assessed the situation, confirmed the critical guidance tasks were still running, and confidently told the crew “GO.” Thanks to the software’s robust design and the team’s understanding, the landing proceeded successfully despite the alarms.
This wasn’t a programming error or astronaut mistake; it was a hardware design issue related to how the radar sensors were powered relative to the computer’s clock, known but deemed acceptable risk before the flight. The AGC’s software intelligence and design saved the mission.
AGC’s Lasting Impact
The Apollo Guidance Computer’s influence extended beyond the Moon missions. It was the starting point for an experimental fly-by-wire (FBW) system installed in an F-8 Crusader jet.
Fly-by-wire (FBW): A system that replaces conventional manual flight controls with an electronic interface. Pilot inputs are sent to a computer, which then processes them and sends electronic signals to the actuators that move the control surfaces (like wings or tail). This allows the computer to help stabilize the aircraft, prevent dangerous maneuvers, or integrate automated functions.
The AGC used in the initial phase of this F-8 FBW project demonstrated the concept’s viability. Although a different computer was used in the second phase, the research paved the way for the FBW systems used in the Space Shuttle and influenced the development of FBW in modern fighter aircraft.
A Note on the Code
For anyone interested in seeing how this pioneering software worked, the original AGC source code has been made available. Transcribed from old printouts, it’s been digitized and is accessible through projects like the Virtual AGC Project and repositories like GitHub. Looking through it is like stepping back in time and seeing the foundational code that helped land humans on another world.
That’s a rundown of the Apollo Guidance Computer, focusing on its technical bits and pieces relevant to electrical engineering. It was a compact, reliable, and incredibly innovative machine that pushed the boundaries of computing and control systems design in the 1960s.