Savage & Drake (1967): AGC Basic Training Manual

Source

Savage, Bernard I. and Drake, Alice, “AGC4 Basic Training Manual,” MIT Instrumentation Laboratory, Cambridge, Massachusetts, Report E-2052, Volume I of II, January 1967.

Download PDF

R-393 tells you what the Apollo Guidance Computer is. E-2052 tells you how to program it. Hopkins, Alonso, and Blair-Smith wrote the architecture specification for computer designers. Savage and Drake wrote the training manual for the people who would actually write the flight software — the engineers who built COLOSSUS and LUMINARY.

This is a teaching document, approved by E.M. Copps Jr. (group leader of Apollo guidance software), David G. Hoag (G&N program director), and Ralph R. Ragan (deputy director of the Instrumentation Laboratory). Its existence tells us something important: MIT IL did not assume that smart engineers could figure out the AGC on their own. There was a formal training pipeline. New programmers studied this manual before they touched flight code. The quality of Apollo software was cultivated, not accidental.

E-2052 covers the Block II AGC — the version that flew to the Moon — and it documents two distinct programming languages that lived on the same 15-bit machine.

Two Languages, One Machine

The AGC had, in effect, two instruction sets:

Property	Basic	Interpretive
Designer	Hugh Blair-Smith	Charles Muntz
Instructions	8 opcodes + ~15 extracodes	~40 operations
Precision	15 bits (single)	30 bits (double)
Arithmetic	Integer, ones complement	Fixed-point, scaled fractions
Speed	Native hardware	~5x slower than Basic
Code density	Baseline	~3x more compact than Basic
Used for	Executive, I/O, time-critical loops	Guidance equations, navigation

Basic is the assembly language — direct hardware instructions. Eight three-bit opcodes plus a set of “extracodes” accessed through the INDEX 5777 prefix. Every instruction the hardware can execute is a Basic instruction.

Interpretive is a virtual machine. The programmer writes TC INTPRET to enter the interpreter, which then fetches and executes its own instruction stream using Basic operations underneath. A vector cross product in interpretive code might cost hundreds of microseconds, but it occupies a fraction of the memory that the equivalent Basic code would require.

This is arguably the first practical use of a bytecode interpreter on a flight computer. The motivation was not abstraction — it was memory. With 36,864 words of core rope for the entire spacecraft, the guidance equations simply would not fit in native assembly. The interpreter traded the one resource the AGC had (time between guidance cycles) for the one resource it did not (program memory).

Section I: Basic — The Hardware Language

Memory Architecture (Block II)

E-2052 documents the Block II AGC, which tripled the fixed memory and doubled the erasable memory compared to the Block I described in R-393:

Region	Addresses (Octal)	Size	Access
Unswitched erasable	0000—0377	256 words	Always visible
Switched erasable	0400—0777	8 banks × 256	Via EB register
Common fixed	2000—3777	1,024 words	Always visible (“fixed-fixed”)
Fixed switchable	4000—7777	36 banks × 1,024	Via FB register

Total erasable: 2,048 words. Total fixed: 36,864 words.

The 12-bit address field directly addresses only 4,096 locations. Everything else requires bank switching. E-2052 teaches programmers the bank-crossing protocols — TC BANKCALL, TC POSTJUMP, the CADR (Complete Address) format — as core skills, not advanced topics. These are the first things a new AGC programmer had to learn after the instruction set itself.

The CADR Format

A CADR (Complete Address) is a 14-bit value encoding both the bank number and the offset within that bank. Any word in the AGC’s entire memory space can be specified by a CADR regardless of the current bank register state. This was essential for the executive’s job table, the interpreter’s variable access, and any code that needed to reference data across bank boundaries. Where R-393 describes bank switching as hardware architecture, E-2052 teaches it as a programming discipline.

Special Registers

The first 62 addresses in erasable memory are not general storage — they are hardware registers. E-2052 walks through each one:

Register	Address	Width	Function
A	0000	16 bits	Accumulator (extra bit for overflow detection)
L	0001	15 bits	Lower product / second word of double-precision pair
Q	0002	15 bits	Return address (saved by TC)
EB	0003	15 bits	Erasable bank selector (bits 9—11)
FB	0004	15 bits	Fixed bank selector (bits 11—15)
Z	0005	15 bits	Program counter
BB	0006	15 bits	Both banks (EB + FB combined)
ZERO	0007	—	Hardwired to +0

The accumulator is one bit wider than memory. This is how the AGC detects overflow: bits 15 and 16 of A disagree when an addition has overflowed the 15-bit word. The TS instruction checks this condition and skips the next instruction on overflow, providing a branch-on-overflow without a dedicated test opcode.

Instructions and Extracodes

The eight basic instructions are the same as R-393 documents for Block I: TC, CCS, INDEX, XCH, CS, TS, AD, MASK. E-2052 teaches each one with worked examples — what happens to the accumulator, what happens to the source word, what happens to the program counter.

The Block II addition is the extracode mechanism. The instruction INDEX 5777 (octal) sets a hardware flag that causes the next instruction to be decoded from an alternate table. This doubles the effective opcode space without changing the 3-bit opcode field:

Extracode	Operation
MP	Multiply (hardware in Block II — was a subroutine in Block I)
DV	Divide (hardware in Block II)
SU	Subtract
BZF	Branch on zero (handles both +0 and -0)
BZMF	Branch on zero or minus
QXCH	Exchange Q with memory
LXCH	Exchange L with memory
DXCH	Double exchange (A,L pair with two memory words)
DCA	Double clear and add
DCS	Double clear and subtract
AUG	Augment (increment magnitude by 1)
DIM	Diminish (decrement magnitude toward zero)

The promotion of multiply and divide from subroutines to hardware instructions was one of the most significant Block I to Block II changes. A multiply that took ~800 μs as a subroutine on Block I executed in a few memory cycles on Block II.

Ones Complement and the Two Zeros

E-2052 devotes considerable attention to ones complement arithmetic — specifically, to the fact that there are two representations of zero. Positive zero is 15 zero bits. Negative zero is 15 one bits. They are numerically equal but not bitwise identical.

This matters because CCS (Count, Compare, and Skip) branches to one of four locations: the operand is positive, positive zero, negative, or negative zero. A programmer who writes a loop termination test using CCS must handle all four cases or risk an infinite loop on one flavor of zero.

The manual also teaches the “corrected difference” — the value CCS actually leaves in A is the absolute value of the operand minus one. This is not a side effect; it is the designed behavior, optimized for countdown loops where you want to decrement and test in a single instruction.

Section II: The Interpreter — Virtual Double Precision

The interpreter is where the guidance equations live. Navigation computations require double-precision trigonometry, vector rotations, and matrix operations — none of which the Basic instruction set can express directly. The interpreter provides all of this in a compact instruction format.

Instruction Format

Interpreter instructions use 7 bits of opcode and 7 bits of address, packed two per 15-bit word. This is entirely different from Basic’s 3+12 format. The interpreter maintains its own state: a multi-precision accumulator (MPAC), its own program counter, and index registers for address computation.

The Operation Repertoire

Category	Operations
Arithmetic	DAD, DSU, DMP, DDV (double add, subtract, multiply, divide)
Trigonometric	SIN, COS, ASIN, ACOS (scaled fixed-point)
Vector	DOT, VXV (cross product), UNIT (normalize), VXSC (vector-scalar multiply)
Matrix	MXV (matrix-vector), VXM (vector-matrix), TRANSPOSE
Flow control	GOTO, CALL, RTB (return to Basic), BPL, BMN, BZE
Load/Store	VLOAD, DLOAD, SLOAD, STORE

Every operation uses fixed-point arithmetic with explicit scaling. There is no floating point. The programmer must track the binary point through every computation and insert scaling corrections where needed. A vector dot product, for example, produces a result whose scaling depends on the scaling of both input vectors — the programmer must know this and account for it.

The Scaling Discipline

Without floating point, every AGC programmer had to carry a mental (or written) model of the binary scaling of every variable through every computation. E-2052 teaches this as a fundamental skill. Multiply shifts the result; divide shifts it the other way; trigonometric functions expect inputs scaled to specific ranges. A scaling error does not produce an exception — it produces a silently wrong answer. This discipline is why AGC source code is dense with comments documenting units and scale factors, and it directly informed Hamilton’s later formalization of data types and access rights in Higher Order Software.

The Speed-for-Memory Tradeoff

The interpreter runs approximately 5x slower than equivalent Basic code but occupies roughly a third of the memory. For guidance equations that execute once per navigation cycle (typically once per second or once per two seconds), the speed penalty is negligible. The memory savings are not.

Consider: the entire AGC had 36,864 words of fixed memory for guidance, navigation, autopilot, display routines, the executive, the interpreter itself, and every other function aboard the spacecraft. The interpreter let the guidance engineers write their equations in something resembling mathematical notation — load a vector, cross it with another vector, take the arcsine — while the time-critical code (the executive, the digital autopilot, the I/O handlers) stayed in native Basic where every microsecond mattered.

This separation — native assembly for real-time code, interpreted bytecode for computational code — is a pattern that recurs in every embedded system that faces the same constraint. The AGC just got there first.

What Is Missing

E-2052 was planned as two volumes. Only Volume I survives:

Volume	Section	Status
I	I — AGC Programming (Basic)	Present
I	II — The Interpreter	Present
II	III — The Executive	Missing
II	IV — SUNDISK and SUNDANCE	Missing

The missing Volume II would have documented the real-time executive — the priority-driven scheduler, the waitlist, restart protection, the mechanisms that saved Apollo 11 during the 1202 alarms. It would also have documented the actual mission programs. Whether Volume II was never completed or simply never scanned is unknown.

R-393 describes the executive at the architectural level. E-2052 Volume I teaches the instruction set and the interpreter. The gap between them — a practitioner’s guide to writing code that works with the executive — remains unfilled in the surviving literature.

The Training Pipeline

E-2052’s existence, and the seniority of its approval chain, tells us that MIT IL invested seriously in programmer education. You did not arrive at the Instrumentation Laboratory, sit down at a keypunch, and start writing guidance code. You studied this manual. You learned ones complement arithmetic, bank switching, the CADR format, and interpreter scaling before you wrote a line of flight software. When Hamilton later described the rigor of Apollo software engineering, this is part of what she meant — the discipline started at onboarding.

---

Hopkins, Alonso & Blair-Smith (1963): AGC Logical Description The hardware architecture that E-2052 teaches programmers to use

Hamilton & Zeldin (1976): Higher Order Software The theoretical formalization of the programming patterns taught in E-2052

Hoag (1963): Apollo G&N Architecture The system-level view of the guidance system that the AGC served

Space Software Engineering Collection overview and document inventory