Apollo Guidance Computer (AGC) Architecture: A Deep Dive into the 1960s Spaceflight Computer

The Apollo Guidance Computer utilized a 16-bit word architecture with 2K-word fixed core memory and 4K-word erasable memory banks, executing custom instructions at 2.048ms cycles via a ~500kHz clock to control the Apollo 11 Command and Lunar Modules.

The Apollo Guidance Computer (AGC) served as the digital autopilot for the Command Module Comanche 055 and Lunar Module Luminary 099 during the historic Apollo 11 mission. Analyzing the source code in the chrislgarry/Apollo-11 repository reveals a compact, fault-tolerant real-time architecture that defined the state of aerospace computing in the 1960s. This article examines the hardware specifications, memory organization, and instruction set that powered the first moon landing.

Word Size and Memory Architecture

The AGC operated on a 16-bit word structure, comprising 15 data bits plus one parity bit for error detection. This word size handled both data values and machine instructions, creating a unified memory architecture that simplified hardware design while maximizing storage efficiency in the resource-constrained spacecraft computer.

Fixed vs. Erasable Memory

The computer divided memory into two distinct physical types. Fixed memory (core rope memory) provided 2,000 words (~4KB) of read-only program storage containing the flight software. Erasable memory offered 4,000 words (~8KB) of magnetic core RAM for variables, temporary calculations, and system registers.

In Comanche055/DOWNLINK_LISTS.agc, comments explicitly distinguish between these memory types when defining telemetry data structures. The fixed memory contained the immutable program code, while erasable locations like DSPTEM2 and TIME2 stored volatile mission data as referenced in Luminary099/PINBALL_NOUN_TABLES.agc.

Instruction Set and Addressing Modes

The AGC implemented a minimalist 13-bit opcode combined with a 2-bit addressing mode field, packing each instruction into the 15-bit available word space (reserving one bit for parity). This design yielded approximately 35 distinct instructions including arithmetic, logical, and control-flow operations optimized for aerospace calculations.

Control Flow and Arithmetic Operations

Key instructions included TC (Transfer Control) for subroutine jumps, CCS (Count, Compare, and Skip) for branching, and AD/SU for addition and subtraction. Logical operations used AND and OR for bitwise manipulation of sensor data and status registers.

The Comanche055/IMU_CALIBRATION_AND_ALIGNMENT.agc file demonstrates the TC instruction for navigation routines:

          TC      STARTUP        # Branch to the STARTUP routine

Arithmetic patterns appear in Luminary099/SINGLE_PRECISION_SUBROUTINES.agc, showing how the CPU manipulated erasable memory variables:

          CAF     VAR1           # Load VAR1 from erasable memory

          AD      VAR2           # Add VAR2 (also erasable)

          CAF     RESULT         # Store result back to RESULT

Timing and Execution Cycle

The AGC maintained deterministic real-time control through a fixed 2.048 millisecond instruction cycle, corresponding to a ~500 kHz clock frequency. This predictable timing allowed programmers to calculate exact execution durations for critical guidance calculations and ensure synchronous operation with spacecraft sensors.

Timing constants reference hardware registers like TIME1 and TIME2 throughout the codebase. In Luminary099/PINBALL_NOUN_TABLES.agc, these registers track mission elapsed time with precise synchronization to the computer's internal clock, enabling coordinated engine burns and navigation updates.

Fault Tolerance and Reliability

To survive the harsh radiation and vibration of spaceflight, the AGC incorporated redundant hardware designs including dual processors and triple-modular redundancy for critical registers. The system featured a watchdog timer capable of resetting the computer without aborting the mission or losing essential guidance data.

The restart logic is implemented in Comanche055/RESTARTS_ROUTINE.agc, which contains the controlled recovery procedures:

          EXTEND  RESET          # Extend to the reset entry point

          CAF     RESTART        # Perform a controlled restart

Input/Output System

The architecture interfaced with spacecraft sensors and displays through 12-bit digital I/O channels. These channels connected to the DSKY (Display and Keyboard), inertial measurement units, and engine actuators, translating physical spacecraft state into digital values processed by the CPU.

The Luminary099/SERVICE_ROUTINES.agc file contains I/O handling examples showing how the CPU read sensor values into the accumulator before transferring them to erasable buffers:

          READ    SENSE1         # Read sensor value into ACC

          CAF     SENSOR_BUFFER  # Copy to a buffer in erasable memory

Programming the AGC

Developers wrote flight software in AGC assembly language, a custom syntax processed by the yaYUL assembler. All source files in the chrislgarry/Apollo-11 repository use the .agc extension, preserving the exact code flown on Apollo 11.

The language exposed hardware-specific features like the ECADR pseudo-op for defining erasable memory addresses and the CAF (Clear and Add Fixed) instruction for loading constants. Files like Comanche055/TVCCONTROL.agc and Luminary099/DAP_INTERFACE_SUBROUTINES.agc demonstrate how programmers optimized every word of memory for the 76KB total storage constraint.

Summary

• The AGC used a 16-bit word size with parity checking, packing instructions and data into unified memory spaces.
• Memory was split between 2K words of fixed core (program code) and 4K words of erasable core (variables and registers) as documented in DOWNLINK_LISTS.agc.
• The 13-bit instruction set supported arithmetic, logical, and control-flow operations with deterministic 2.048ms cycle times.
• Fault tolerance was achieved through redundant hardware and software-controlled restart capabilities documented in RESTARTS_ROUTINE.agc.
• 12-bit I/O channels interfaced with spacecraft systems via routines in SERVICE_ROUTINES.agc.
• All software was written in AGC assembly language, with original source files preserved in the chrislgarry/Apollo-11 repository.

Frequently Asked Questions

How much memory did the Apollo Guidance Computer have?

The AGC contained approximately 76 kilobytes of total memory: 2,000 words (roughly 4KB) of fixed read-only core memory for the flight program, and 4,000 words (approximately 8KB) of erasable magnetic core memory for data storage. The 16-bit word architecture meant each memory location held 15 data bits plus one parity bit for error detection, as seen in the memory declarations throughout Comanche055 and Luminary099 modules.

What programming language was used for the Apollo Guidance Computer?

Engineers wrote AGC software in a custom assembly language specifically designed for the computer's hardware architecture. This language used mnemonics like TC, CAF, and CCS, and was assembled using the yaYUL tool. The chrislgarry/Apollo-11 repository contains the digitized original source files with the .agc extension, representing the exact code executed during the Apollo 11 mission.

How fast was the Apollo Guidance Computer?

The AGC executed instructions at a rate of approximately one every 2.048 milliseconds, corresponding to a clock speed of roughly 500 kHz. While slow by modern standards, this deterministic timing allowed precise real-time control of spacecraft navigation and guidance systems during critical mission phases like lunar descent and rendezvous.

What made the Apollo Guidance Computer fault-tolerant?

The architecture incorporated redundant hardware including dual processors and triple-modular redundancy for essential registers. Software-implemented watchdog timers and restart logic in Comanche055/RESTARTS_ROUTINE.agc allowed the system to recover from transient errors or radiation-induced upsets without compromising the mission, enabling automatic computer resets while maintaining critical flight data integrity.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}