Colossus Erasable Memory Programs (1972)
What These Documents Are
Section titled “What These Documents Are”These are primary source documents from Hamilton’s direct technical leadership of the Apollo software effort. The Guidance System Operations Plan (GSOP) was the governing specification for the flight software. Section 7, “Erasable Memory Programs,” documents how the severely limited erasable memory of the Apollo Guidance Computer was allocated, organized, and managed across mission phases.
The AGC had approximately 2,048 words (about 4KB) of erasable memory organized across 8 banks. This was the only writable storage available to the flight software — everything else was in fixed (read-only) core rope memory. Every variable the software needed to track during a mission — navigation state, guidance parameters, display data, timing counters — had to fit in this space.
Two versions exist: one for the Command/Service Module (CSM) and one for the Lunar Module (LM). The systems software (“commonware”) shared between both modules had to be consistent with both memory layouts.
Erasable Memory Programs (EMPs)
Section titled “Erasable Memory Programs (EMPs)”The documents specify Erasable Memory Programs — small procedures that modify the AGC’s erasable memory to alter the computer’s behavior in ways not anticipated by the original fixed-memory program design. As the introduction to the CSM version states:
The EMPs vary in complexity from a simple flagbit setting to a long and intricate logical structure. They all, however, cause the computer to behave in a way not intended in the original design of the programs; they accomplish this off-nominal behavior by some alteration of erasable memory to interface with existing fixed-memory programs to effect a desired result.
Each EMP entry follows a standard format:
- Number and Name — A three-digit identifier (CSM EMPs begin with “5”, LM EMPs begin with “1”)
- Purpose — What the EMP accomplishes
- Functional Description — How it interfaces with fixed-memory programs
- Assumptions — Prerequisite conditions and configurations
- Restrictions and Limitations — Conditions under which the EMP must not be used
Examples from the CSM Table of Contents
Section titled “Examples from the CSM Table of Contents”The CSM version catalogs dozens of EMPs addressing specific operational scenarios:
| EMP | Purpose |
|---|---|
| 509 | P40/41/47 Termination During Average G |
| 514 | Shortened P23 |
| 515 | Manual Range Input |
| 517 | Software Restart |
| 518 | GDC REFSMMAT Determination |
| 520 | Enter MINKEY at Post Plane Change Pulse Torquing |
| 522 | Non-P40 SPS Gimbal Drive Test |
| 523 | Monitor Jet-On Failure |
| 525A | Optics Switch Monitor |
| 526 | IMU CDU Transient Monitor |
| 527 | Monitor Single IMU CDU |
| 528 | Monitor Jet-On Failure and Do EMP 526 |
These entries reveal the kinds of edge cases and hardware interactions the flight software had to accommodate — from optics tracking with failed hardware to recovery from software restarts during guidance maneuvers.
Why This Document Matters
Section titled “Why This Document Matters”The erasable memory allocation problem is where Hamilton first encountered the interface errors that drove her toward formal prevention methods. The forced sharing of erasable memory across mission phases created implicit dependencies — analogous to shared mutable state in concurrent programming — that were nearly impossible to verify by inspection alone.
Hamilton’s later analysis found that approximately 75% of all errors in the Apollo software were interface errors. The erasable memory sharing documented in these specifications was a primary source of those errors: variables used by one mission phase might occupy the same physical address as variables used by another phase, creating subtle coupling that could only be detected by understanding the full temporal flow of the software across all mission phases.
As Hamilton wrote in the 2008 USL paper:
This was due in part to size constraints in the hardware, which made it necessary for mission phases to share erasable memory.
And her later formal rule in USL — “a reference to an object’s state cannot be modified if other references are being (or could be) made to that state” — is a direct formalization of lessons learned from the problems inherent in the memory allocation these documents define.
The Approval Page
Section titled “The Approval Page”The LM version’s approval page bears Hamilton’s signature directly:
M. H. HAMILTON, DIRECTOR, MISSION PROGRAM DEVELOPMENT APOLLO GUIDANCE AND NAVIGATION PROGRAM
Additional signatories include S. L. Copps (Colossus Project Manager), R. H. Battin (Director, Mission Development), D. G. Hoag (Director, Apollo Guidance and Navigation Program), and R. R. Ragan (Deputy Director, Charles Stark Draper Laboratory). The document was approved by NASA/MSC representatives John R. Garman (Section Chief, Guidance Section), John E. Williams Jr. (Chief, Simulation and Flight Software Branch), and James C. Stokes Jr. (Chief, Flight Support Division).
Extraction Status
Section titled “Extraction Status”These scanned documents have been partially extracted. The OCR output captures page structure and some text, but the typewritten tables that make up the bulk of the content — memory maps, address allocations, variable definitions with scaling factors — require manual verification. The 1972 typewritten originals include hand-annotated corrections that challenge automated extraction.
Key content yet to be fully extracted includes:
- Complete erasable memory layout maps showing variable-to-address assignments
- Variable definitions with word format, units, scaling, and valid ranges
- Memory sharing rules specifying which variables coexist across mission phases
- Differences between CSM and LM memory allocations
Related Documents
Section titled “Related Documents”- The Apollo On-Board Flight Software (2019) — Hamilton’s retrospective describes COLOSSUS by name and discusses the erasable memory sharing problem these documents specify.
- USL: Lessons Learned from Apollo (2008) — The USL paper’s discussion of interface errors (75% of all errors) and the need for formal access rights derives directly from the problems inherent in the memory allocation these documents define.
- Skylark GSOP (1972) — The Skylark GSOP sections follow the same structure and conventions, showing the evolution of the specification approach for Skylab.
- The Executive (1202/1201) — The AGC source code for the executive routines that managed process scheduling within the memory constraints documented here.