Hopkins, Alonso & Blair-Smith (1963): AGC Logical Description

Source

Hopkins, Albert L., Jr., Alonso, Ramon L., and Blair-Smith, Hugh, “Logical Description for the Apollo Guidance Computer (AGC),” MIT Instrumentation Laboratory, Cambridge, Massachusetts, Report R-393, November 1963 (revised).

Download PDF

This is the document that defines what the Apollo Guidance Computer actually is — not the system it serves (that’s Hoag), not the algorithm it runs (that’s Battin), but the machine itself: how it stores data, executes instructions, handles interrupts, manages concurrent tasks, and recovers from faults. Hoag (1963) cites it directly as Report R-393.

The AGC described here is the Block I design. The Block II that flew to the Moon expanded the instruction set and enlarged the memory, but the fundamental architecture — 15-bit word, one’s complement arithmetic, core rope fixed memory, ferrite erasable memory, priority-driven executive, and restart protection — carried over unchanged. What R-393 describes is the skeleton of the computer that survived the 1202 alarms on Apollo 11.

The Machine at a Glance

Parameter	Block I Value
Word length	15 bits + 1 parity
Clock frequency	~2.048 MHz
Memory cycle	11.72 μs
Fixed memory (core rope)	12,288 words (24 banks × 512)
Erasable memory (ferrite)	1,024 words (8 banks × 128)
Arithmetic	One’s complement, serial
Instruction format	3-bit opcode + 12-bit address
Basic instructions	8
Single-precision add	~20 μs
Double-precision multiply	~800 μs (subroutine)

This is a single-accumulator machine. There is no hardware multiplier, no floating point, no stack. Multiplication is a subroutine. Double-precision arithmetic is a subroutine. Trigonometric functions are a subroutine. Everything beyond add, subtract, logical AND, and branch is built from those primitives.

Instruction Set

Eight instructions. Three bits of opcode, twelve bits of address:

Opcode	Mnemonic	Operation
000	TC	Transfer Control — subroutine call, stores return address in Q
001	CCS	Count, Compare, and Skip — four-way conditional branch
010	INDEX	Add word to next instruction before execution
011	XCH	Exchange accumulator with memory
100	CS	Clear and Subtract — load one’s complement of memory
101	TS	Transfer to Storage — store accumulator, skip on overflow
110	AD	Add memory to accumulator
111	MASK	Bitwise AND

The CCS instruction deserves particular attention. It decrements the absolute value of a memory word by one and branches to one of four consecutive addresses depending on whether the original value was positive, +0, negative, or -0. A single instruction handles countdown loops, sign testing, and zero detection — the kind of density you design when you have 12,288 words of program memory for an entire spacecraft.

The INDEX Trick

INDEX adds the contents of a memory word to the next instruction before that instruction executes. This effectively turns any memory location into a temporary index register. Need to access the $n$-th element of a table? Store $n$ in a memory word, then INDEX through it. No dedicated index registers, no addressing modes — just one instruction that modifies the next. It is the AGC’s answer to the addressing problem, and it pervades every piece of AGC software.

Memory Architecture

Core Rope: Woven Programs

Fixed memory is core rope ROM — the most distinctive technology in the AGC. Programs and constants are stored by physically weaving sense wires through or around magnetic transformer cores. A wire routed through a core reads as a 1; a wire routed around it reads as a 0.

Manufacturing was done by hand. Workers at Raytheon wove the wires according to patterns derived from the assembled software. A complete core rope module took weeks to produce. Changing a single bit meant re-weaving. This is why “rope freeze” — the deadline after which no software changes could be made — was one of the most critical milestones in the Apollo schedule.

The payoff: core rope is non-volatile (no power needed), radiation-tolerant (magnetic hysteresis is inherently robust against single-event upsets), and extremely dense for its era. No semiconductor ROM of comparable capacity and reliability existed in 1963.

Ferrite Core: Destructive Memory

Erasable memory uses conventional ferrite cores — tiny magnetic toroids, one per bit. Reading a core destroys its state (the sense current flips the magnetization). A write-after-read cycle restores the data after every read.

This has a critical implication: if power is lost during a read cycle, that word is corrupted. The word being read at the moment of failure contains garbage. This vulnerability is not theoretical — power transients were expected during the mission. The entire restart protection system exists to handle this failure mode.

Bank Switching

The 12-bit address field can directly address only 4,096 locations, but the AGC has 13,312 words of memory. The solution: bank registers that select which physical bank maps to the “switched” portion of the address space.

• Unswitched erasable (addresses 0-255): always accessible, holds critical registers and frequently-used variables
• Switched erasable (addresses 256-511): maps to one of several banks via the erasable bank register
• Fixed-fixed (addresses 2048-4095): two banks of core rope that are permanently mapped — the most valuable real estate in the AGC
• Fixed-switchable (addresses 4096+): one of 24 banks selected by the fixed bank register

Crossing a bank boundary requires explicit bank-switch instructions. Programmers organized code to minimize these crossings — especially in time-critical loops. Critical routines lived in fixed-fixed memory where they could be called from any bank without switching overhead.

The Banking Constraint

Bank switching was not an annoyance — it was an architectural force that shaped every program. A subroutine in bank 5 that needed to call a subroutine in bank 12 had to go through a “bank call” sequence that cost several instructions. Large programs were partitioned by execution path, not logical structure, to minimize bank crossings. This is why AGC source code can look bewildering to modern readers: the physical organization reflects memory topology, not software architecture.

The Priority-Driven Executive

The AGC runs multiple concurrent “jobs” at different priority levels. The executive — a small real-time operating system baked into the core rope — manages scheduling, context switching, and resource allocation.

Each job has a priority from 0 to 7. A higher-priority job preempts a lower-priority one. When a job yields (waiting for a measurement, a timer, or I/O), the executive switches to the highest-priority ready job. Job state (accumulator, program counter, bank register) is saved in a fixed-size table in erasable memory.

This is the mechanism that saved Apollo 11. On July 20, 1969, during the powered descent, the rendezvous radar was accidentally left in a mode that flooded the AGC with spurious interrupts. The computer fell behind — it could not complete all pending work within the available time. The executive responded exactly as designed:

1. Detected that low-priority jobs could not be scheduled
2. Issued the 1202 program alarm (“executive overflow — no core sets available”)
3. Shed the lowest-priority jobs
4. Continued running the high-priority guidance and control loop

The computer did not crash. It did not corrupt data. It dropped non-essential work and kept flying the spacecraft. Steve Bales in Mission Control called “GO” because he recognized that the 1202 alarm meant the computer was managing an overload, not failing from one.

Interrupt and Counter System

Real-time I/O uses two mechanisms:

Hardware counters increment or decrement in response to external pulses — gyro torquing pulses, accelerometer increments, clock ticks. Counter operations are interleaved with normal instruction execution, stealing single memory cycles as needed. The running program is unaware of counter activity; the hardware handles it transparently.

Interrupts handle asynchronous events that require software response:

Priority	Source	Purpose
1	TIME3	Task scheduling timer
2	TIME4	Display/keyboard service
3	KEYRUPT	DSKY keystroke
4	UPRUPT	Ground uplink data
5	DOWNRUPT	Telemetry request

An interrupt saves minimal context (program counter and accumulator), transfers to a fixed service address, and returns via the RESUME instruction. Interrupt service routines must be short — they run with other interrupts blocked.

The counter/interrupt split is elegant: high-frequency, low-latency events (pulse counting) are handled entirely in hardware with no software overhead. Lower-frequency events that require decisions (keystrokes, uplink commands) use interrupts. This separation keeps the instruction stream undisturbed by the steady rain of sensor pulses while still responding to asynchronous events.

Restart Protection

If the hardware detects an anomaly — a power transient, a logic upset, a watchdog timeout — it forces a restart. The program counter resets to a fixed address, and the restart handler takes over.

The mechanism relies on restart groups. Programs are divided into numbered groups. At defined checkpoints, the running program writes its restart group number and enough state information to a protected region of erasable memory. On restart:

1. The handler reads the restart group number
2. Looks up the corresponding recovery entry point
3. Resumes execution from the last checkpoint

The program does not need to be atomic. It does not need transaction logs or rollback capability. It needs only to reach checkpoints often enough that the cost of re-executing from the last checkpoint is acceptable. For a navigation update that takes a few hundred milliseconds, losing 50-100 ms of work and re-executing is entirely tolerable.

Design Insight

Restart protection works because the AGC’s computations are mostly deterministic given their inputs. The gyro and accelerometer data are captured in hardware counters that survive a restart. The navigation state in erasable memory is consistent as of the last checkpoint. The only lost work is computation done since that checkpoint, and the only cost of recovery is re-doing that computation. This is possible because the hardware/software boundary was designed with restart in mind from the beginning.

One’s Complement Arithmetic

The AGC uses one’s complement representation, which has a property that two’s complement does not: there are two representations of zero. Positive zero is all zeros; negative zero is all ones. The CCS instruction’s four-way branch exists specifically to handle both zeros correctly.

Overflow detection is built into the TS (Transfer to Storage) instruction. If storing the accumulator would overflow the 15-bit word, TS skips the next instruction — providing a branch-on-overflow without a separate test instruction. The skipped instruction is typically a TC to the normal continuation; the instruction after it handles the overflow case.

This is characteristic of the AGC’s design philosophy: every instruction does as much work as possible. With only 8 opcodes and 12,288 words of program memory, there is no room for single-purpose instructions.

What This Paper Teaches

R-393 is a computer architecture document, but the architecture it describes was shaped entirely by its mission. Every choice — the 15-bit word, the 8-instruction set, core rope, bank switching, the priority executive, restart groups — was driven by the constraints of building a computer that could navigate to the Moon and back within the mass, power, volume, and reliability budget of a 1960s spacecraft.

The most lasting contribution is not any single feature but the pattern they establish together: a hard-real-time system where correctness under stress matters more than performance under normal conditions. The executive sheds work to protect critical tasks. The restart mechanism recovers from hardware faults without losing mission state. The counter system handles high-frequency I/O without disturbing computation. These patterns recur in every safety-critical embedded system built since — avionics, medical devices, automotive controllers — though few face constraints as severe as a 15-bit, 1 MHz, 1K-word computer flying to the Moon.

---

E-2052: AGC Basic Training Manual The training companion -- how to program the machine R-393 describes

Hoag (1963): Apollo G&N Architecture The system-level view -- sensors, computer, displays, and the astronaut

Battin (1962): Statistical Navigation The algorithm the AGC executed -- recursive Bayesian estimation for midcourse navigation

Space Software Engineering Collection overview and document inventory