# Apollo Guidance Computer (AGC) Architecture: A Deep Dive into the 1960s Spaceflight Computer > Explore the Apollo Guidance Computer AGC architecture. Discover its 16-bit design, memory banks, and custom instructions that powered the Apollo 11 mission. - Repository: [Chris Garry/Apollo-11](https://github.com/chrislgarry/Apollo-11) - Tags: deep-dive - Published: 2026-03-04 --- **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: ```assembly TC STARTUP # Branch to the STARTUP routine ``` Arithmetic patterns appear in `Luminary099/SINGLE_PRECISION_SUBROUTINES.agc`, showing how the CPU manipulated erasable memory variables: ```assembly 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: ```assembly 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: ```assembly 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.