## What is "Colossus"?

Colossus is the program which was run on the Apollo Guidance Computer installed in the Command Module (CM).  In order to be loaded into the AGC—actually, to be converted to the "core ropes" within the AGC—it was necessary to "assemble" Colossus's source code into binary machine language, using a computer program called YUL.  In the context of the Virtual AGC project, of course, the process is somewhat different:  Colossus source code is assembled by the yaYUL program, and then loaded into the yaAGC simulation.

## It's Always Sunny in Outer Space

Programs with names like Sundisk, Solarium, and Sunspot were pre-Colossus versions of the Command Module AGC's software.  They were not forms of Colossus as such, but provided some code for Colossus.  If you click on the image to the left, you can see a simplified family tree for Colossus, drawn by me, while if you click on the tables to the right depicts the various versions of the software from Apollo-era documents.

The Colossus program eventually had three major versions, not surprisingly known as Colossus 1, Colossus 2, and Colossus 3.  Additionally, there were minor versions such as Colossus 1A, Colossus 2C, and so on.

Colossus 2 was also referred to by the separate name of Comanche.  I'm not fully aware of how the versioning within the "Colossus 2" nomenclature was interrelated to versioning within the "Comanche" nomenclature, but here are some relationships I'm sure of:

Colossus
Comanche
2
Rev. 44 and Rev. 45
2A
Rev. 51 and Rev. 55
2C
Rev. 67
2D
Rev. 72

Additionally, Colossus 3 was referred to by the separate name of Artemis

Finally, Skylark was post-Colossus Command-Module software.  I suspect that it was probably Colossus with features added or removed, but I have no real evidence for this suspicion.

Of course, the command-modules themselves are still in existence, though that doesn't imply they still contain their AGCs.  Zach Greene has compiled the following partial list:
• Apollo 7 is located at the Frontiers of Flight Museum in Dallas, Texas
• Apollo 9 is located in the San Diego Aerospace Museum
• Apollo 10 is located at the Science Museum in London
• Apollo 11 is located at the National Air and Space Museum in Washington D.C.
• Apollo 12 is located at the Virginia Air and Space Museum in Hampton, Virginia
• Apollo 13 is located at the Kansas Cosmosphere and Space Center.
• Apollo 14 is located at the Astronaut Hall of Fame in Titusville, Florida
• The Apollo Soyuz CM is located at California Space Center in Los Angeles, California

## Known Software Versions

### Highlighted Versions, in Gory Detail, Whether We Have Them or Not

Information in the following table was taken from online sources, rather than from official software-configuration documentation, and should not be regarded as authoritative.
Mission CSM number
CM Program Version Source Code
Mission-specific documentation
Where is it now?
n/a
n/a
TRIVIUM
12/1963
Scanned pages

or

Colorized HTML
AGC Information Series #13: YUL Programming System
This is an unusual program, in that its sole purpose was to demonstrate usage of the original AGC assembler, YUL.  In fact, its very short program listing (only one page of source code!) was attached to a 1963 manual (hyperlinked at left) for YUL.  The document itself was obtained from the personal papers of the late Russel Larson.

The program is for a Block I AGC, and thus is not only one of the very few Block I AGC programs that has survived, but is probably the earliest such program that will ever be found.

The program itself contains a pedagogically deliberate error — one of the variables it references is not defined within the program — and thus YUL could not fully assemble it.  Besides that error, there are three also-deliberate items in the program that are not aligned at the proper punch-card columns:  one program label, one operator, and one operand.  YUL was apparently fine with those misalignments, though our modern assembler, yaYUL, is not, and it treats two of them as errors.  In spite of all that, however, yaYUL's assembly of the code is remarkably like YUL's.

Because TRIVIUM contained these deliberate errors and oddities, we're actually providing it for you in two forms:  TRIVIUM (as hyperlinked at the left) corresponds exactly to the original program, errors and all, while TRIVIUM-repaired fixes those errors, and thus assembles as a syntactically-correct program.

However ... you may notice that the program identifies itself as being by "IMA NIT-PICKER".  I surmised that IMA may really have been Hugh Blair-Smith, and Hugh tells me that that is indeed true.  The name IMA NIT-PICKER is actually a tongue-and-cheek reference to Richard Volpi, the principal author of the AGC Information Series document (hyperlinked at the left) in which the program appears.  Richard apparently tended to pay an enormous amount of attention to detail, and hence (Hugh says) was the true nit-picker.  (See also the comments about Volpi in Hugh's book, Left Brains for the Right Stuff.)

Amusingly, though, in reviewing the program after all these years (about 55 of them!), Hugh was surprised to notice that even with the assembly-time error fixed, the program does not actually work.  Given that the program is less than 20 lines long altogether, that may hint at some of the difficulties involved in writing AGC software.  As to exactly what's wrong with the program, I leave that as an exercise for the reader!
Apollo 3
(AS-202)
CSM-011
Corona
TBD

GSOP (R-477)
"Apollo Experience Report—Guidance and Control Systems: Mission Control Programer for Unmanned Missions AS-202, Apollo 4, and Apollo 6"

"Programming Changes from AS-202 to AS-501"

"G&N System Data for Mission AS-202 Development Engineering Inspection"
Quoting from the wikipedia article:
"AS-202 (also referred to as SA-202) was the second unmanned, suborbital test flight of a production Block I Apollo Command/Service Module launched with the Saturn IB launch vehicle. It was launched on August 25, 1966 and was the first flight which included the spacecraft Guidance and Navigation Control system and fuel cells. The success of this flight enabled the Apollo program to judge the Block I spacecraft and Saturn IB ready to carry men into orbit on the next mission, AS-204."
In case you're wondering about the designation "Apollo 3", which is not mentioned specifically in the wikipedia article, that is how the mission is referenced in the Instrumentation Lab's report R-700, MIT's Role in Project Apollo, from which a lot of the software-versioning information here comes, and frankly, it's just catchier than "AS-202".

A fellow named Francois Rautenbach has physically extracted the contents of the rope memory from this specific AGC, which, he says, was "found on a rubbish dump" some time after the mission.  He has posted a YouTube video of the extraction process which is interesting to watch, and includes information about the mission itself (including video) as well:

Right now, the data Francois extracted is simply in the form of stored electrical waveforms, and isn't even a machine-readable file of octal data.  But with some luck, perhaps we can convert this waveform data into an octal dump of the rope, and from that point, convert it back into Block 1 AGC source code, to be presented here.  Right now this is just a plan rather than a reality, so stay tuned!

It may not be immediately obvious to you what the significance of the document "Programming Changes from AS-202 to AS-501, hyperlinked at the left is.  The significance is that we have the source code for AS-502 (Solarium 55, see below), which is almost identical, or indeed perhaps even exactly identical to AS-501 (Solarium 54).  Thus if we knew the changes between AS-202 and AS-501, it might help us reconstruct the Corona source code from Solarium 55 source code, and those change are exactly what the document gives us.  The document was contributed by AGC developer Jay Sampson, who actually coded the changes!
Apollo 1
(AS-204A)
CSM-012
Sunspot
≥247

GSOP (R-507)
Operations Handbook

"Independent Flight Software Validation Test Results for Mission AS-204A"
Yes, Apollo 1 never flew, but it deserves a place of honor.  I'd sure like to know where this program can be found!

This was a Block I spacecraft.

The exact version of SUNSPOT that would have flown isn't presently known to me, but SUNSPOT 247 is the version TRW evaluated in the independent validation testing hyperlinked at the left.  Therefore, the version that would have been in the AGC at mission time must be at least 247, but probably higher.
Apollo 4
(AS-501)
CSM-017
Solarium
54
See the comments at the far right.
GSOP (R-537)
"Apollo Experience Report—Guidance and Control Systems: Mission Control Programer for Unmanned Missions AS-202, Apollo 4, and Apollo 6"

"Programming Changes from AS-202 to AS-501"

"Trip Report on AS-501Meeting at MIT/IL on July 6, 1967"

"Apollo Mission SA 501 Preliminary Mission Profile"

Various documents specific to this mission
Apollo 4 was an unmanned mission, but it did have a working CSM and a working AGC in the CM.

This was a Block I spacecraft.

The "Programer"—yes, that's the real spelling, though some sources do refer to it as the "programmer"—was the gadget that was the stand-in for the crew.

By the way, in the GSOP volumes linked to the left, Volumes I and II are actually separated in time by a few months, and sections 6-7 overlap between them, but with modifications.

The "Programming Changes ..." and "Trip Report ..." documents were contributed by AGC developer Jay Sampson, who authored them and made the coding changes described in the former.

Regarding the software itself:  Jay Sampson, who as I mentioned above coded the changes from the Corona (AS-202) code to derive Solarium (AS-501), is insistent that there were no code changes between missions AS-501 (Apollo 4) and AS-502 (Apollo 6).  He does note that he had left MIT between Apollo 4 and 6 rather than after Apollo 6, and thus there is a tiny time window in which such changes could have occurred without his knowledge.  Still, he believes that Solarium 54 is actually 100% identical to Solarium 55 (see below).  Jay speculates that they simply rebuilt the memory rope, without changing the source code, and gave it a new number.

Here's a timeline of events which, while odd, completely support Jay's assertion:
• According to Instrumentation Lab document R-700, "MIT's Involvement in Project Apollo", Volume 1, page 20, both Solarium 54 and 55 were released, for Apollo 4 and Apollo 6 respectively, in November of 1966.  (And indeed, there are other documents supported this same factoid.)
• Our copy of Solarium 55 is dated December 4, 1966, and thus should be from the released version.  For example, page 10.
• Solarium 54 flew on November 9, 1967, nearly a year after that.
• Solarium 55 flew in April of 1968.
In summary, at this point in time, Jay's account is reasonable and I have no evidence that would lead me to believe that Jay is mistaken, thus I would maintain that the Apollo 4 source code is indeed identical to the Apollo 6 source code described below.
Apollo 6
CM-020
SM-014
Solarium
55
As colorized,
HTML

As scanned page images (very big!)
"Apollo Experience Report—Guidance and Control Systems: Mission Control Programer for Unmanned Missions AS-202, Apollo 4, and Apollo 6"

"Apollo 6 Mission 3-Day Report"
Apollo 6 was an unmanned mission, but it did have a working CSM and a working AGC in the CM.  Eldon C. Hall's copy of this program listing is in the American Computer Museum, which has graciously allowed us to digitize the program listing for use in Virtual AGC.

Honor Roll

Organizational honors

 American Computer Museum Bozeman, Montana

Individual honors
• Eldon C. Hall, for his foresight in preservation, the leads he provided, and for his overall approval.
• George Keremedjiev, Curator of the American Computer Museum, for making the listing available.
• Kim Scott, Archivist of Special Collections, Renne Library, Montana State University, and other MSU individuals whose names I do not know, for helpful and responsible supervision of the digitization effor.
• Marilyn Chang, Librarian, Wings Over the Rockies Air & Space Museum, for the necessary research and contacts.
• Fabrizio Bernardini, for bringing Marilyn into the loop.
• Henry Wesso, for constructing the special copy stand used for the digitization.
• Gil Guerrero, for providing advice and camera equipment.
• Jim Lawton, for single-handedly converting the page scans to source-code files.

This was a block I spacecraft.

The "Programer"—yes, that's the real spelling, though some other sources refer to it as the "programmer"—was the gadget that was the stand-in for the crew.  The same physical programer, not merely the same type of programer, was used in both the Apollo 4 and Apollo 6 missions

The "3-Day Report" was contributed by AGC developer Jay Sampson.
Apollo 7
CSM-101
Sundisk
282

E-2150, Guidance, Navigation, and Control Block II Command and Service Module Functional Description and Operation Using Flight Program SUNDISK (Rev. 282) Regarding document E-2150, linked to the left, the preface reads: "The purpose of this document is twofold.  The first is to provide a functional description (operationally oriented) of the CSM GNCS hardware and software and the interfaces with other SC systems.  The level of detail is that required to identify and define telemetry outputs. Also included are functional flow diagrams of the Sundisk 282 programs and routines together with lists of verbs, nouns, option codes, and checklist codes for this flow. The second purpose is to provide the operational procedures for this hardware and software including malfunction procedures, and program notes.  The nominal airborne expanded and condensed checklist for Sundisk appear in the Guidance System Operation Plan, R547."
Apollo 8
CSM-103
Colossus 1
237
As colorized,
HTML

As scanned page images (very big!)
GSOP (R-577)
Flight Plan Digital Simulation
Checklists

Technical Debriefing
I presently have no definitive configuration-management data from the original Apollo Program which I can call upon to state conclusively which AGC software versions were used for which missions.  In particular, I couldn't prove in court that either Colossus 1 (build 237, August 24, 1968) or Colossus 1A (build 249, October 28, 1968) actually flew.  The GSOP linked at left is a combined operations plan for both builds 237 and 249, and it refers specifically to spacecraft AS-503 and CM-103 (used for Apollo 8), and LM-3 (used for Apollo 9).  From this I infer that build 237 flew on Apollo 8 and build 249 flew on Apollo 9, and will operate on this assumption until more data is available.  Long-time followers of this site will perhaps recall that I used to identify build 249 as being for Apollo 8, but I now think this was probably an error.

The Colossus 237 program listing was made available by original AGC developer Fred Martin.  (Thanks, Fred!)  The listing cuts off abruptly after page 1557—whereas you'd normally anticipate that there are 1700+ pages—so some of the assembler-generated tables at the end of the listing are missing.  Of particular inconvenience, because it presents special problems for verifying the correctness of the simulation, is the absence of the octal listing and of the memory-bank checksums.  However, all of the source code is present, and that's enough to work with.

The Apollo 8 Flight Plan and Technical Debriefing were also provided by Fred.

The digital simulation linked at the left is an Apollo-era simulation, and not one produced by the Virtual AGC Project.  It is the only Colossus digital simulation available so far, although there are a number of Luminary digital simulations in our library, and as such it has a unique value.  Specifically, it has pad-loads, though those pad-loads are for March 1969 rather than for December 1968.
Apollo 9
CSM-104
Colossus 1A
249

Scanned image set #1 (very big!)

Scanned image set #2 (very big!)
GSOP (R-577)
Systems Handbook

Flight Plan
See the Apollo 8 notes above for the rationale for believing that build 249 flew on Apollo 9.

Two separate sets of scanned images of the Colossus 249 program listing are provided.  They are from different reproductions of the same original 1968 printout, as owned by different AGC developers.  Scanned image set #1 is in far better condition than set #2 and is more legible, but only the less-legible set #2 was actually available to me when I originally implemented Colossus 249.  Any hand-written notes on the listings are from the original developers (as far as I know), and so those notes differ on the two image sets.

Scanned image set #1 is from a copy in the collection of original AGC developer Fred Martin.  (Thanks, Fred!)  Fred provided it to us temporarily for the purpose of scanning it.  As far as I know, this reproduction is available only here.

As for scanned image set #2, the marking on the front of the document implies that it was original AGC developer Norm Brodeur's copy.  I originally obtained the scan from MIT's Dibner Institute's now-discontinued website titled "History of Recent Science and Technology."  Here at Virtual AGC, I choose to present the listing as a set of individual page images instead of a giant PDF.  This listing has been improved by the replacement of 52 garbled pages (supplied by Mr. Gary Neff), which I suppose are probably available only here as well.

I have been told that the assembly listings, originally, could be printed either on "very noisy" line-printers with a restricted character set that happened to correspond to the character set allowed for the AGC programs themselves, or else on a page-printer that had a 256-character set, but in which the character set could be swapped out to allow different characters to be printed from the same numerical codes.  All of the AGC printouts that are available to us are from the line printers, except this Colossus 249 printout, which was made on the page printer.  Unfortunately, the wrong character-set was set up on the printer when the printout was made, so that while all of the upper-case alphanumeric characters were printed correctly, many of the non-alphanumeric characters were systematically printed as different characters, in a kind of substitution cipher.  The complete set of character-substitutions, in so far as I have been able to discern them, is as follows:
Desired Character
Printed As
<
±
'
α
"
β
|
γ
>
δ
?
π
%
Σ
&
d
#
$\int$
:
'
@
:
_
Naturally, in transcribing the scanned assembly-listing as source code, we have made these substitutions already, so a '<' looks like a '<', a '?' looks like a '?', etc.
N/A
N/A
Colossus 2
(Comanche)

44
Perhaps some day ...

We know that Margaret Hamilton has a copy of this, and hope to get it from her some day.  Alas! today is not that day.  While it is not a flown version, it's pretty close to the flown version on Apollo 10 (only a two-month difference according to the table from R-700 at the top of this page).
Apollo 10
CSM-106
Colossus 2
(Manche)
45/2

GSOP (R-577)
• Section 5:
Section 5 of the GSOP, presented here, was provided by original AGC developer Fred Martin.
Apollo 11
CSM-107
Colossus 2A
(Comanche)
55

As scanned page images (very big!)
Operational Data Book
Crew Debriefing
Flight Plan
Page images have been taken from a hardcopy from the Charles Stark Draper Historical Collection, MIT Museum, and then converted to source code by a team of volunteers.

Honor Roll

Organizational honors

 Massachusetts Institute of Technology / MIT Museum Building N51, 265 Massachusetts Avenue Cambridge, MA  02139 web.mit.edu/museum/

Individual honors
• Deborah Douglas, the Museum's Curator of Science and Technology, who conceived the idea of making this material available to us, and without whom we had literally no chance of obtaining it.
• Paul Fjeld, for digitizing the hardcopy.
• (In alphabetical order) Fabrizio Bernardini, Hartmuth Gutshe, Onno Hommes, Jim Lawton, and Sergio Navarro, for converting the page images to source code.
• ... and those whose names I do not know at the Charles Stark Draper Laboratory and NASA who allowed us to do this.

Apollo 12
CSM-108
Colossus 2C
(Comanche)
67

Operational Data Book
Flight Plan

Spacecraft Operational Trajectory

E-2442, Guidance, Navigation, and Control Command Module Functional Description and Operation Using Flight Program COLOSSUS 2C (COMANCHE 67)
Regarding document E-2442, linked to the left, the preface reads: "The purpose of this document is twofold.  The first is to provide a functional description (operationally oriented) of the CSM GNCS hardware and software and the interfaces with other spacecraft systems.  The level of detail is that required to identify and define telemetry outputs. Also included are function flow diagrams of the COLOSSUS programs and routines together with lists of verbs, nouns, option codes, and checklist codes for this flow. The second purpose is to provide the operational procedures for this hardware and software including nominal airborne condensed checklists, malfunction procedures, and program notes."
Apollo 13
CSM-109
Colossus 2D
(Comanche)
72/3

Operational Data Book
Regarding the Users' Guide hyperlinked at the left, it is "a comprehensive, user-oriented description of the APOLLO GN&C system ... revised as necessary to remain current", but not targeted at specific missions.  However, given that it is dated July 1970, it is probably pretty accurate for Apollo 13.
Apollo 14
CSM-110
Colossus 2E
(Comanche)
108

Operational Data Book

Users' Guide to Apollo GN&CS Major Modes and Routines, Rev 1

Regarding the Users' Guide hyperlinked at the left, it is "a comprehensive, user-oriented description of the APOLLO GN&C system ... revised as necessary to remain current", but not targeted at specific missions.  However, given that it is dated July 1970, it is probably pretty accurate for Apollo 14.

Although we don't presently have the Apollo 14 CM software, Niklas Beug, a developer and user of NASSP, the Apollo-mission add-on for the Orbiter spaceflight simulator, tells us that it's actually possible to use a modified form of Artemis (the Apollo 15-17 software) to fly satisfactory Apollo 14 missions.  Let me simply quote Nik:
We currently don't have any AGC version available that was flown on Apollo 14, which causes a few, mostly procedural issues for NASSP. Apollo 14 was the only mission flown in the time period from July 1st, 1970 to July 1st 1971 and as such used a slightly different coordinate system than the AGC versions before and after that. And using a different coordinate system means that a few hardcoded constants had to be changed every year: star unit vectors, solar and lunar ephemeris in the LGC and a few other numbers. These numbers for the yearly coordinate system used by Apollo 14 are available or can be calculated. So we did just that and created our own AGC versions for Apollo 14. Both CMC and LGC are derived from the AGC versions flown on Apollo 15, Luminary 1E and Artemis (Colossus 3). We determined that these most closely match the programs and capabilities of the AGC versions actually flown on Apollo 14. One regular NASSP user (Alex Bart, ...) tested Apollo 14 with these modified AGC versions and flew the complete simulated mission with them. We are very confident now that these AGC versions are working as they should. As I said, they are essentially still the AGC versions flown on Apollo 15, only slightly modified to properly work with Apollo 14. ... They are available here, as Artemis072NBY71.bin and Luminary210NBY71.bin, [i.e.] Artemis072 and Luminary210 modified to work for the Nearest Besselian Year (NBY) coordinate system of 1971.

Apollo 15
CSM-112
Colossus 3
(Artemis)
72

As scanned page images (very big!)
GSOP (R-577)
Programmed Guidance Equations for Colossus 3:

Users' Guide to Apollo GN&CS Major Modes and Routines, Rev 4, Colossus 3 and Luminary 1E

CMC Data Cards
or
CMC data cards

Program Notes

CSM Systems Handbook

Operational Data Book
Crew Debriefing

Flight Plan

Checklists
Also known as Artemis build 072, released (Fabrizio Bernardini tells me) January 31, 1971.  A private collector has graciously allowed us to digitize this program listing for use in Virtual AGC.

Thanks also to:
• Henry Wesso, for constructing the special copy stand used for the digitization.
• Gil Guerrero, for providing advice and camera equipment.
• (In alphabetical order) Steve Case, Hartmuth Gutshe, Onno Hommes, Jim Lawton, and Sergio Navarro, for converting the page images to source code.
• To Jim Lawton, for debugging the converted source-code files.
Regarding the Programmed Guidance Equations document hyperlinked at the left, it is basically a pseudo-code description of the Artemis 72 program.  Unfortunately, pages ORBI-9 and ORBI-10 are missing.

Regarding the Users' Guide hyperlinked at the left, it is "a comprehensive, user-oriented description of the APOLLO GN&C system ... revised as necessary to remain current", but not targeted at specific missions.  However, given that it specifically references Colossus 3 and Luminary 1E, that seems pretty specific to Apollo 15, 16, and 17.

Apollo 16
CSM-113
Colossus 3
(Artemis)
72
GSOP (R-577)

Programmed Guidance Equations for Colossus 3:

Users' Guide to Apollo GN&CS Major Modes and Routines, Rev 4, Colossus 3 and Luminary 1E

Program Notes

CSM Systems Handbook

Operational Data Book
Flight Plan
Apollo 17
CSM-114
Colossus 3
(Artemis)
72
GSOP (R-577)

Programmed Guidance Equations for Colossus 3:

Users' Guide to Apollo GN&CS Major Modes and Routines, Rev 4, Colossus 3 and Luminary 1E

Program Notes

CSM Systems Handbook

Operational Data Book
Crew Debriefing

Flight Plan
Skylab 2-4
CSM-116
CSM-117
CSM-118
Skylark
48?

Quick-reference cards

GSOP (R-693)

Programmed Guidance Equations for Skylark 48:

CSM Systems Handbook

Operational Data Book
Regarding the Programmed Guidance Equations document hyperlinked at the left, it is basically a pseudo-code description of the Skylark 48 program.
Apollo-Soyuz
CSM-111
Skylark
TBD

Quick-reference cards

GSOP (R-693)

Programmed Guidance Equations for Skylark 48:

Operational Data Book
As far as the GSOP and guidance-equation documents hyperlinked to the left are concerned, note that internally they refer specifically to Skylab missions and/or to Skylark 48, so I'm not sure of the degree of relevance to the Apollo-Soyuz mission.  However, given the lack of Apollo-Soyuz specific data, I'm provisionally linking them here as well!

## Source Code and Binary

Both source code and (independently derived) binary code are provided within the yaAGC tarball downlod.  The files are contained within a subdirectory named after the software version (such as "Colossus249" and "Artemis072").  The more important files supplied are these:

 Filename.agc Source code for major subdivisions of the Colossus program. MAIN.agc Organizer which treats all of the other assembly-language files (*.agc) as include-files, to form the complete program. Filename.binsource Human-readable form of the binary executable as an octal listing. Filename.bin Binary executable created from binsource (octal listing) file.

In other words, to create a Colossus binary executable rather than using the one provided with yaAGC (such as Colossus249.bin), one simply needs to assemble the file MAIN.agc.  Typically, if all files remain organized the way they are in the yaAGC distribution tarball, the sequence of steps for doing so (from a command-line prompt) would be something like this:

cd Colossus249
../yaYUL/yaYUL MAIN.agc >Colossus249.lst

The binary so produced, MAIN.agc.bin, should be byte-for-byte identical to the binary (Colossus249.bin) provided with the yaAGC distribution.  Therefore, the following Linux command should reveal no differences between the two

diff MAIN.agc.bin Colossus249.bin

(Replace "diff" with "fc /b" in Windows.)

### Technically speaking....

A point which may not be completely appreciated is that Colossus249.bin was not created from the assembly-language source files.  Therefore, the byte-for-byte equivalence mentioned above actually has some significance.  In fact, both the assembly-language source code and Colossus249.bin (or Colossus249.binsource) come from separate readings of the original Colossus assembly listing scan, so their equivalence provides an important check on validity.  (See below.)  The file Colossus249.bin was created from the human-readable/editable ASCII file Colossus249.binsource by means of the program Oct2Bin, with the following steps:

cd Colossus249
../Luminary131/Oct2Bin <Colossus249.binsource
mv Oct2Bin.bin Colossus249.bin

Admittedly, few people are likely to perform any processing of this kind unless contibuting a new version of the Colossus code to the Virtual AGC project.

## Validation

I generally put a lot of effort into insuring that the executable binaries being run in the simulated AGC are byte-for-byte (or in the case of the AGC, word-for-word) identical to the original binaries used in the spacecraft.  Most people won't be interested in this validation effort at all—just as we're not usually interested in how food gets from plants and animals onto the plates in front of us as long as we get our dinners on time; we're happy to trust others to do the work for us—but for those few of you who wonder if the simulated AGC really is running the correct code, the following sections provide explanations.  The different program versions are presented in the order in which they were worked on.

### Validity of the Colossus 249 Code (Apollo 9)

The following description of validation was written prior to having the Colossus249 software source code in machine-readable form, and therefore prior to being able to the core-rope image against the source code as described above.  Not only that, but there were seven errors in the core-rope not detected by the procedure described below!

So the description is now obsolete.  But I like it, and it's my website, so it stays.  (Actually, it continues to have value, since we don't yet have all versions of the AGC source, and since it describes how to proceed in the case of recovering poor-quality assembly listings.)

#### A Tour of the Source Materials

Let's look at a pages from the source materials (actually, a greatly improved version) I've used in reconstructing Colossus 1A (build 249).  In appearance, what we have is a scan of a photocopy of an assembly listing of the program.  Significant portions of the assembly listing have been corrupted (or even destroyed) after scanning, seemingly by processing with the optical-character-recognition capabilities of Adobe Acrobat.  (The source materials used for Luminary 1C, build 131, are generally similar, except that the original photocopy seems to be of better quality, the scans seem to have been performed with much more care, and no destructive post-processing has been performed.  On the other hand, the original Luminary printout seems to have been on computer paper with green and white color bars, and the remnants of the green bars make portions of the listing very difficult to read with certainty.  Most of what I have to say will apply to Luminary as well as to Colossus.)  With some luck, I'll be able to find (or will be given) better source materials at some point in the future, but I've had no luck so far in obtaining such materials and therefore have had to make do with what's available.

An assembly listing is a type of report created when a program's source code is processed ("assembled"), in this case by the assembler program called YUL.  (Actually, by GAP, the successor to YUL, but when I say "YUL" I really mean "either YUL or GAP".)  Such an assembly listing contains not only a listing of the source code, but also other helpful information such as the octal values which the source code assembles to.  The octal codes are what is needed to run the program, while the source code is what is needed to modify the program.  The general layout of the Colossus (or Luminary) assembly listing has a series of sections, of which some of the more interesting are:
• A listing of the source code, side by side with the octal codes created from the source code, side by side with the addresses at which the octal values are placed.  Click here to see a typical page (without OCR).  The source code is on the right-hand side of the page, whereas the octal values, addresses, and other miscellaneous notations are on the left-hand side of the page.  This section occupies about 1500 pages of the assembly listing.
• A symbol table, giving the addresses at which all of the symbols created by the program are defined.
• An octal listing, which is the same as the octal values shown earlier side by side with the source code, but now rearranged so that the values are arranged by memory address.  Click here to see a typical page (without OCR).  This section occupies about 150 pages of the source listing.
• An octal-to-page cross reference, in which you can find the page of the assembly listing at which the octal value for any given address is defined.

#### Proofing in the Usual Case

From the description above, you will have noted that source code is listed once within the assembly listing, but that octal values created from the source code are listed twice, and are therefore redundant.  Furthermore, knowing the source code, one can recreate the octal values from it.  (The reverse is not as easy.)  Finally, the octal listing is much shorter than the source-code listing.  Therefore, it shouldn't be surprising that it is much easier to create a file containing a valid octal listing of the program than it is to create a file containing a valid source-code listing.

It is also much easier to know that an octal listing is valid than it is to know that a source-code listing is valid.  This is true because the YUL assembler has added "checksums" to the octal values, which can be used to verify (or at least give a high degree of confidence) that the octal values are correct.  The way this works is that the so-called "fixed memory" of the AGC has been divided into 36 banks, numbered 0-43 in octal notation, each of which has a 15-bit checksum created by adding up all of the 15-bit words within the bank.  (Actually, the rule for computing the checksum is more complicated, but that's the basic idea.)  Therefore, if we compute the checksum of a bank and see that it is the same as the checksum provided by YUL, we can be fairly confident that the contents of the bank are correct.  (I should mention that I've provided a utility called Oct2Bin which is helpful in this connection.  Octal codes can be placed in a simple ASCII file, and then processed with Oct2Bin to create a file containing the actual octal/binary codes and to verify all bank checksums.)

Another helpful touch added by YUL is that each octal value is accompanied by a parity bit, contrived to make the number of 1-bits within the octal value (including the parity bit) an odd number.  This is useful in detecting single digit errors of some kinds.  (The digits 0, 3, 5, and 6 have even parity, while the digits 1, 2, 4, and 7 have odd parity.  Therefore, examination of the parity bit could detect substitution of a '2' for a '3', for example, but not substitution of a '5' for a '6'.)

In almost all cases, the following simple procedure suffices to produce a valid octal listing:
1. Manually proof-read a memory bank of the octal listing against the original assembly listing, using the redundancy of the octal values or manually assembling source code as necessary to account for corrupted areas of the assembly listing.
2. Compute and verify the checksum.
3. On failure, go back to step 1.  On success do the next memory bank.
Given a valid octal listing, determining the validity of a source-code listing is rather trivial:  simply run the source code through the yaYUL assembler, and verify that the same octal listing is produced.

This procedure in fact suffices for the entire Luminary octal listing, and for all memory banks of Colossus except banks 35 and 36 (octal).  If you want to learn more about proofing Colossus memory banks 35 and 36, read onward.  Otherwise, quit now!

Postscript:  After writing all of the material below, I was fortunate enough to receive some much-improved page scans of relevant portions of bank 36 from Mr. Gary Neff.  Therefore, bank 36 is now capable of being proofed by the simple method explained above.  However, it was previously proofed using the much more complex methods explained below, and therefore I haven't bothered to change the explanation that follows.

#### Proofing in Extraordinary Cases

The simple proofing method outlined above fails when the scan of the assembly listing for some memory bank is so corrupted that the bank checksum or some value(s) within the memory bank are completely unknown.  Sadly, this condition occurs within Colossus 1C (build 249) banks 35 and 36.  Click here to see the culprit page of the octal listing.  This corrupted page from the octal listing actually wads together the end of bank 35 and the beginning of bank 36 in such a way that there is no chance of figuring out any but a small part of them.  In this case, one has no choice but to use the redundant listing of the octal values that appears side by side with the source code.

Unfortunately, though, the redundant octal values in the source code listing fail us here, though in different ways for bank 35 and bank 36.  For bank 35, we encounter the problem that the bank checksum appears only within the octal listing and is not redundant.  Therefore, we can theoretically know all of the octal values in the memory bank—if our proofing is 100% accurate—but cannot use the bank checksum to give us the degree of confidence we would like.  For bank 36, the checksum is intact but some of the octal values cannot be directly determined because of corruption within the source-code listing.  (In other words, both the octal listing and the source-code listing are corrupted in the corresponding place.)  As far as proofing is concerned, however, the conclusion is the same:  We need some method of proofing which gives us a high level of confidence in the result, in the absence of a checksum.

Here is the alternate method of proofing used in this cases, which seems to offer a fairly high level of confidence:
1. Note first that each memory bank actually occupies 4 pages within the octal listing.  For this method, we proof each memory page separately from the others.
2. Manually proof-read the memory page, using either the octal listing or the source-code listing as desired or appropriate.  While doing so, record the number of digits which have been corrected.
3. Repeat step 2 until zero corrections have been made in two successive proofings.
4. To the extent feasible, one of the 0-error proofings should use the octal listing, and the other should use the source-code listing.
The theory behind this procedure is that in any given proofing a certain percentage of errors is corrected, and that by monitoring the number of errors that have been corrected we can get a good sense of the number of errors remaining.  To take a "typical" case, suppose that on the first proofing 100 errors are detected and corrected, on the second proofing 1 error is detected and corrected, and on the third and fourth proofings 0 errors are detected.  It would be reasonable to suppose that each proofing pass detects 99% of errors, so the expected number of errors remaining after the 4th pass is 100*0.01*0.01*0.01*0.01, or about a millionth of an error.  Of course, this reasoning assumes that our ability to detect and correct different errors has some quality of statistical independence, and that errors are not remaining undetected through some systematic problem.  We try to overcome that objection by making sure that we use both the octal listing and the source-code listing in the proofing process, but how successful we have been is always debatable.

As far as proofing is concerned, this technique suffices for Colossus banks 35 and 36, but does not actually give us a 100% knowledge of the octal values within the banks.  For bank 35, we can simply construct a checksum and be done with it.  But for bank 36, we need to do a little more work.  If you want to know more about that, read onward!

#### When All Else Fails—Digital Archaeology

In a case like bank 36, the technique above may give us confidence that all octal values that are legible in the page images are keyed accurately, but the proofing technique can't give us any insight into the octal values that are simply missing from both the source-code listing and the octal listing.  One trick we can try is to compare the Colossus and Luminary source-code, which actually have a high degree of overlap in general.  Unfortunately, this is not a case in which there is any such overlap, so the comparison is of no help.

Click here (p. 846) and here (p. 847) to see the pages of the source-code listing that are relevant to the problems in bank 36, namely:
1. Address 36,2634:  This source-code line is simply missing.  We have no clue as to what may have been in it, except that it is seemingly the first part of a double-precision constant whose second part is the word 00000 octal.
2. Address 36,2734:  Appears to be interpretive code reading "something1 something2", but only a couple of pixel rows are present, and so neither the octal code nor the assembly-language code can be read.
3. Address 36,2742:  Highly corrupted, but may have the octal code 00021 and may have interpretive source code reading "16D".
4. Address 36,2747:  Pretty corrupted, but seems likely to be the interpretive source code "CALL" with octal code 77624.
As far as points 3 and 4 are concerned, I think it's pretty easy to convince ourselves that the proposed interpretations are probably correct.  If you want a challenge, you may like to try solving problems 1 and 2 for yourself, before continuing to read my proposed solution below.

Point 2 is somewhat trickier than problems 3 and 4, because the corruption of the page-image is so much greater.  But with some effort, we can still figure it out.  Within the offending page of the source-code listing, notice the notations "REF" and "LAST".  These notations appear only on source-code lines referencing variables.  "REF" gives the number of times the variable has been referred to so far in the assembly listing, which "LAST" gives the page number on which the preceeding reference occurred.  The problematic source line clearly contains REF and LAST notations (even though we cannot read them), and so it is clear that something2 is the name of a variable.  You should be able to convince yourself fairly easily that the variable in question is RCON.  In other words, something2="RCON".  (In case it's still not obvious how you would convince yourself of this, note that "REF 6" to RCON is below the missing source line, while "REF 4" is on the preceding page, but that "REF 5" is nowhere to be found.)  Next, because this section of code is AGC interpreter language (rather than assembly language), we can narrow down the choices for something1; theoretically, the only possibilities are STORE, STODL, or STOVL.  Simply in terms of appearances, it seems likely that something1=STODL.  Unfortunately, the interpreter documentation (Users Guide to the Block II AGC/LGC Interpreter, by Charles A. Muntz) was last updated in early 1965, and contains an incorrect numerical opcode for STODL.  Not to be deterred, though, if we look at the other source-code lines near the missing line, we see intact lines like "STODL RPRE," (the comma after "RPRE", by the way, is actually part of the variable name), from which we can deduce that the octal code for STODL is 16000.  Noting that RCON has the address 1635, therefore, "STODL RCON" must assemble to the octal code 16000+1635+1=17636.  But—and why, I'd like to know, does there always seem to be another "but"?—the missing line of code is preceded by a line of source code reading simply "STADR".  The STADR opcode has the odd effect of complementing the code that follows it.  Therefore—finally!—the missing octal code for address 36,2734 is probably 60141.  This closely matches the remaining pixel fragments (and expected parity bit) of the missing line, and so we can feel good about it.

Having now determined all of the octal values within the bank except at address 36,2634, and noting the checksum for bank 36 is known, we can consider the possibility of recreating the octal value at 36,2634 simply by putting a value there that correctly reproduces the bank's checksum.  This is actually trickier than you may suppose, since the checksum is unique only up to a sign.  (In other words, we don't know whether to insert a value that produces the positive checksum or one that produces the negative checksum.)  Often, either the positive or the negative checksum will be impossible to produce, thus removing the uncertainty.  Where it is possible to produce both the positive and the negative checksum, we note that 90% of the memory banks have positive checksums, so we have a much better chance of being correct if we choose the positive checksum.   All of this turns out to be an anti-climax, however:  Prior to any of the reasoning listed above, our inclination was simply to put 00000 at address 36,2634.  Remarkably, this produces the correct bank checksum without any additional work on our part!  Perhaps this is the first time in history that a gut reaction has been confirmed by checksum.

#### Happy Epilogue!

After the all of the intricate reasoning above was worked out—and the description above written—Mr. Gary Neff was able to send me some terrific replacement scans of the problematic assembly-listing pages from bank 36, namely pp. 846-847.  If you examine locations 36,2634, 36, 2734, 36,2742, and 36,2747 on the new scan, you'll see that they indeed contain exactly the values deduced above!  I still think the exploration I went through before receiving the new scans is a valuable illustration of technique, not to mention being soothing to my ego, so I'll leave it in place for future generations to enjoy.  :-)

### Validity of the Comanche 055 Code (Apollo 11)

The Comanche 055 page images became available after the Colossus 249 and Luminary 131page images had already been converted to source-code files, and prior to any other missions becoming available.  The conversion technique was very abbreviated compared to that of Colossus 249, as follows:
• A small corps of volunteers—thanks (in alphabetical order) Fabrizio Bernardini, Hartmuth Gutshe, Onno Hommes, Jim Lawton, and Sergio Navarro!—took the existing Colossus 249 source-code files, or on occasion the Luminary 131 source-code files, and laboriously compared them line-by-line to the Comanche 055 assembly-listing page images, porting the differences they found.
• The resulting Comanche 055 source code was assembled using yaYUL to produce a binary executable, which was horribly wrong at this point (with dozens of conversion errors), but was used to create a "binsource" file (which is an octal listing of the entire program).
• The binsource file was laboriously proofed against the octal listing in the page images (this time by me), and corrected.  As a double-check, the bank checksums are all correct.
• Finally, at every point where the binary created from the source code by yaYUL differed from the binsource file, the source code was compared to the page images and corrected.  After all corrections were made, the binary created by yaYUL was identical to the binary created from the binsource file.
The binary thus produced by yaYUL is supplied in the source tree and used for regression testing.

### Validity of Artemis 072 Code (Apollo 15-17)

The Artemis 072 executable (Artemis072.bin) was created by manually entering binary data from scans of an Artemis 072 assembly listing.  The data was proofed and reproofed until the bank checksums, as described above, were correct, and the binary was made available to the public on 2006-01-10.  On 2010-02-20 (more than 4 years later), source code was finally available and assembled.  A single error which did not affect the memory-bank checksum was found and corrected in the binary.  So we are now confident that what is being provided is both complete and correct.

This is an interesting object lesson.  My previous notes in this section, prior to the availability of source code, made it clear that I wouldn't be surprised if additional pairs or even triplets of errors were found in the binary ... but the notion that an unpaired error might still exist which did not affect the checksum never occurred to me.  The problem is a weakness in the checksumming algorithm used in the AGC.

If the AGC had used a "normal" checksumming algorithm (from the modern point of view) with 2's-complement arithmetic, any single error in data would have caused the checksum to change, and the error to be detected.

But in the 1's-complement arithmetic of the AGC, simple checksumming does not have the same desirable property.  For example, since there is both a +0 and a -0, which produce the same result in an addition, a memory error in which +0 is replaced by -0 (or vice versa) produces the same checksum and would be undetectable.  But algorithmically the problem is more complicated than that, since a simple checksum algorithm was not used.  The actual algorithm used on a data-word by data-word basis was this:
• The next data word is added to the running checksum.
• If there is positive overflow, the result is reduced by 040000 (considered as a positive number, thus preserving the sign of the result) and then incremented.
• if there is negative overflow, the result is incremented by 040000 (again, considered as a positive number, thus preserving the sign of the result), and then decremented.
For example, if the running checksum was 030000 (a positive number), and the next data word was 020000 (another positive number), then adding them would give 050000 (arithmetic overflow!), which would be decremented (due to the overflow) by 040000 to give 010000, and then incremented by 1 to give a running checksum of 010001.

If you are amused by such stuff, I invite you to consider the ways in which such an algorithm might fail to detect error.  In the case of the Artemis 72 binary, the now-corrected error was a single bit (the most significant bit) of a single memory location.

### Validity of Colossus 237 (Apollo 8)

The Colossus 237 program listing presented a special challenge, because the only physical copy we've had access to is truncated.  It contains all of the source code, as well as the binary words associated with the source code on a line-by-line basis.  But it is missing the octal listing that condenses all of the binaries into an easily accessible form.  Because the octal listing is missing, the "bugger words" that are used to make the memory-bank checksums compute correctly are also missing.  Thus, important redundancies and checksums that normally would be used to provide confidence of correctness are missing.

Therefore, the following unique validation procedure was applied instead:
• A "binsource" file was created by laboriously stepping through the page images of the program listing, line-by-line, and observing the listed binary words.  The "bugger words" are not available in this fashion, and are therefore left at zero.
• Since Colossus 237 and Colossus 249 are separated in time by only a few months, the binsource files of Colossus 237 and Colossus 249 — i.e., the binary files we create manually, independently of the source listings, as part of the data-entry process — were compared using automated tools ('diff' or similar).  Where differences existed, the page images of the Colossus 237 program listing were referenced to verify (to the extent possible) that the differences were real rather than being transcription errors.
• Where complete memory banks were found to be identical by the automated comparison, the bugger words were copied from Colossus 249 to Colossus 237.
• Source-code files were created from the page images of the program listing.
• The binary of the assembled source-code files was compared in an automated fashion against the binary created from the binsource file, and either the binsource file or the source code (or both) were corrected when any discrepancies were found.  At this stage of the process, validation process, it is very typical for "superbank" errors to show up; these are errors not in the source code per se, but are due to discrepancies between yaYUL's assumptions about the superbank memory settings in comparison to the assumptions of the original YUL or GAP assemblers; thus, those superbank problems were corrected as well.
• For any banks remaining without bugger words in the binsource file, the bugger words created by yaYUL were added.

Thus while we can't have as much confidence in the validity of the Colossus 237 transcription, in comparison to almost all of the other Colossus and Luminary transcriptions, the code has nevertheless been double-checked both manually (visually) and in an automated fashion as well.

### Validity of Solarium 055 (Apollo 6)

Solarium 055 presented a big challenge because it is the first Block I code processed, and no Block I support was previously provided by the yaYUL assembler.  However, support for Block 1 was in fact added to yaYUL, and after that validation of Solarium 055 differed little from any other AGC program.  Unfortunately there is no way as of yet to run Solarium in yaAGC, so we have not had the additional pleasure (and assurance!) of witnessing it run.