Actually, there are a lot of Lunar Module program versions we
don't have, and won't ever have. For example, the reason
Luminary 69 is called 69 is because of the 68 versions preceding
it, all of which have now vanished with the wind ... we
presume. The same goes for the documentation associated with
the software, so we only have incomplete snapshots at various
points in time, and in the table below I've made an effort to
associate important version-specific documentation with the
software version. However, in case of Luminary, we have an
additional very important resource that I haven't bothered to link
in on a version by version basis, but which you can nevertheless
consult. I refer to the so-called LUMINARY Memos, a
collection of 250+ internal Instrumentation Labs covering many
aspects of the Luminary development process, including extensive
descriptions of revision-to-revision changes. Instead of
trying to isolate which memos are specific to which of the many
program revisions, I'll just recommend that you browse the memo
collection yourself as you see fit.
|Mission||LM Number|| Mission
|LM Program||Version||Source Code
Know About It, in a Nutshell
Reduced-size scanned JPG
High-quality scanned JPEG 2000
||As you've seen elsewhere on this
site, there where two major versions of the AGC, the Block I
and Block II models. While there was never any Block I
code for the Lunar Module, there was certainly Block I code
for the Command Module, and at some point a transition was
made both from writing Block I code to writing Block II code
... but also from writing CM code to writing LM code, and
Retread marks that transition point! It's the
veritable Missing Link of AGC code, which is particularly a
propos since in fact the YUL development system
employed for AGC development didn't sport a linker.
(Joke! Feel free to ignore.)
In other words, Retread was when Block I code for the CM began to be adapted into Block II code for the LM. Thus, like Aurora below, Retread was never intended to be mission code, and was never flown. But it has the honor of being the "first" LM software. It is, in fact, more than a year older than any other AGC software of any kind (Block I, Block II, CM, LM) available publicly at the present time, as far as I'm aware!
Indeed, if you look at the date on this software — I'll save you the trouble; it's July 9, 1965 — that's the same time (within a month or two) of when the first Block II AGCs were actually becoming available, and thus the only way to have run RETREAD at that time was probably in a digital simulation. But of course, digital simulations in advance of actual hardware are never perfect, so there would be every possibility that RETREAD 44 may not be exactly compatible with Block II AGC hardware yet ... and it turns out that that's the case. If, for example, you look at the self-check code, run by VERB 21 NOUN 27 ENTER 1 ENTER, not all of the CPU tests pass! (There is a detailed write-up of this issue, if you're interested.)
At any rate, this particular program listing came to us from Don Eyles, via scanning at archive.org, financially-sponsored by Mike Higgins.
||As colorized, hyperlinked, HTML||This is highly
unusual software, not of itself perhaps, but due to the way
we acquired it. We do not have any assembly listing
for it (scanned or otherwise), nor has it been reconstructed
from problem reports and speculations about how it might
differ from the closely-related RETREAD 44 software above.
Rather, this software was dumped from physical core-rope modules presently living in an AGC at the Computer History Museum in Mountain View, California. In other words, what was obtained was the executable form of the program, and not the source code for it. The source code linked at the left was mostly taken from corresponding sections of RETREAD 44 source code (see above) and AURORA 12 source code (see below), but it assembles identically to the contents of the dumped core-rope modules, thus validating that the source code is correct. Small areas of the source code, particularly in memory bank 11, have not yet been matched to any preexisting code, and therefore source code for those areas was decompiled from the rope, using presently-arbitrary program labels and variable names.
One of the Computer History Museum's (two) rope modules was defective, but fortunately defective in a way that allowed ultimate recovery of the data.
This work was not done by the Virtual AGC Project, but by an independent project (leading up the 50th anniversary of Apollo 11) to make one of the original remaining AGCs operational. The code was then donated by the restoration project to us. Read our full write-up of the AGC-restoration project here.
Reduced-size scanned JPG
High-quality scanned JPEG 2000
||Don Eyles, one of the AGC
developers who you may know as the hero of
Apollo 14, has contributed the hardcopy of this
program from his personal collection. We have had it
scanned by archive.org,
and Mike Stewart has generously financially-sponsored the
scanning. So, thanks Don and Mike! As usual, we
provide it here in the form of reduced-size (but therefore
reduced-quality) images for easier access, but the original
scans in their full quality are still available in our
Virtual AGC collection at archive.org.
I suppose I should mention that if page 52 or 70 of the reduced-sized images look a little weird to you (oh, you conspiracy theorists with your Photoshopping theories!), I should mention that those were places where there was a paper-change on the printer, and I simply glued two partial pages together to make it look pretty. You can look at the high-quality scans to see all of the pages in their original, un-Photoshopped glory, if you like.
Now before you go all elitist and thumb your nose at Aurora just because it never flew on an actual mission (even an unmanned one), let me tell you that from this project's standpoint it is quite a terrific find. For one thing, it employs unique flavor of the AGC programming language; although it is a Block 2 program for a Block 2 computer, the language version precedes its final form as used in the later software versions we have available, requiring changes to the assembler just to assemble it. Technically, it was targeted at the "BLK2" software architecture rather than the "AGC" software architecture.
More significantly, it was the last version we know of to incorporate the full range of AGC testing software that had been created. In actual mission software, most of this testing software was removed due to size constraints, and due to the fact (I presume) that most of the tests were more-appropriately done in the lab, as acceptance tests, rather than in space where nothing could be done about the failures anyway. Why do we care about that? Well, how do you think we test our AGC-emulation software? Prior to having Aurora, our only choice was to roll our own tests, which the original AGC may not have even been able to pass for all we know. But now that we have Aurora, we can run it and just make sure the real tests pass.
Finally, there's something of a mystery associated with Aurora 12. The hardcopy we have of it is from November 10, 1966, and Aurora at the point should have had a version number in the 80's. How could it be version 12? Perhaps one day we'll know!
Reduced-quality PDF (160MB)
High-quality scanned JPEG 2000 (400MB)
SUNBURST rev 37, otherwise known as SHEPATIN rev 0, is an
early revision of the SUNBURST program, not used in any
mission. The scan was taken from Don Eyles's personal
copy, for our Internet Archive collection, and financially
sponsored by Peter McDermott.
I would hazard the guess that SHEPATIN was a program Don used for off-line development of new program features or bug fixes for SUNBURST, and that SHEPATIN 0 happened to have been branched from SUNBURST 37 ... thus it is a "clean" copy in which no changes had yet been made, which fortuitously (for us) gives us a nice snapshot of SUNBURST development as well. We know that SHEPATIN was developed at least through SHEPATIN 6, since the notes at the end of the AURORA 12 assembly listing mention assembly of SHEPATIN 6. At any rate, whatever the exact history, we're obviously we're thrilled that Don saved it for us.
SUNBURST 37 is substantially different from SUNBURST 120 (see below), used later for Apollo 5, and thus, like RETREAD and AURORA (see above) is a kind of missing link in the evolutionary chain of the AGC software in general and the LGC software in particular.
Reduced-size scanned JPG
High-quality scanned JPEG 2000
| GSOP (R-527)
Apollo Experience Report—Guidance and Control Systems: Lunar Module Mission Programer"
"LM-1 Trip Report at MSC - Flight Support and Debriefing"
"Results of Independent Flight Software Validation Test of the BURST116 Program for the LM-1 Mission"
|Apollo 5 was an unmanned mission to
test the LM, and as such it had a working AGC, though at
certain points in the mission the ground controllers
bypassed the AGC (which hadn't been planned for), using the
AGS instead for some
maneuvers. The mission itself was not entirely
The "Programer"—actually some sources spell it "programer" and some "programmer"—was a robotic gadget that was the stand-in for the crew.
Don Eyles provided the hardcopy for our the program-listing scan we present here. It was scanned by archive.org, and was generously sponsored by Mike Stewart. The original printout unfortunately has some problems in the vicinity of pp. 820-830, but we naturally correct those in our transcription.
The LM-1 Trip Report was provided by its author, AGC developer Jay Sampson, and provides a fascinating blow-by-blow description of what transpired during the actual mission, and a summary of the subsequent debriefing.
In spite of the relative lack of resources about the Apollo 5 mission, NASSP developer and enthusiast Niklas Beug tells us that
... we have successfully been able to fly most of the Apollo 5 mission with that scenario, including two burns with the Descent Propulsion System and one with the Ascent Propulsion System. As you know, during the actual Apollo 5 mission Sunburst didn't actually make it beyond the first DPS burn due to slow thrust buildup and a resulting thrust fail indication. But in NASSP Sunburst has been able to complete the simulated DOI, and the simulated powered descent with a late abort and staging, followed by a short APS burn.Recall that NASSP is an Apollo-mission add-on for the Orbiter spaceflight simulator that integrates our AGC simulator so that it can run the actual AGC software to control the simulated CM or LM. The "scenario" Nik is referring to here is, of course, using SUNBURST 120 in a simulated LM, but it also involves the trickery employed to account for the fact that we have no documentation for the pad-loads needed for this mission. What Nik did to generate these pad-loads is very interesting, so I'll quote him in full:
[In NASSP], we can't currently have a running simulated Lunar Module on the launchpad, due to how NASSP simulates the CSM and Saturn vehicles as one entity. But nothing was stopping me from creating the usual padload worksheet for Sunburst120. Luckily there were a few resources available for that, including the "Prelaunch Erasable Memo Load Definition for AS206" document.
Listing in Appendix D of Volume 2 of Raytheon document R68-4125
volume 1, "Final Report: Auxiliary Memory for Apollo
Raytheon R68-4125, volume 2, "Final Report: Auxiliary Memory for Apollo Guidance Computer"
E-2254: "Auxiliary Memory System, Final Report on Phase I"
|This program, Super
Job, is a very unusual offering, in that it is AGC code not
written by the MIT Instrumentation Lab, but rather by
Raytheon. Of course, sub-contractors from Raytheon,
A.C. Electronics, and others, were used to help write the
"regular" AGC programs as well, but this program is entirely
written by Raytheon.
Nor does it seem to have been assembled with the YUL or GAP assemblers used to assemble all of the other AGC code, but rather (as far as we can tell!) an in-house Raytheon assembler. That in-house assembler is almost, but not quite, compatible with YUL/GAP: slightly different address formats were used, and the interpretation of certain operands is slightly different. We support that with a special command-line switch (--raytheon) in yaYUL.
The way this program came about is that Raytheon was contracted to do a feasibility study for potentially expanding the AGC memory capacity by adding a magnetic-tape recorder. If you have looked at our Gemini OBC (on-board computer) page, you'll know that the later Gemini missions did use a tape-memory unit to load different OBC software for different mission phases, and this is a similar idea. The basic characteristics of the auxiliary memory were:
The auxiliary memory was never used in a mission, so you
may suppose it was a completely-obscure feature, but there
is actually some measure of legacy support for it, albeit
very trivial, in every LM code version from Sunburst
onward. The way its effect is seen is that the AGC's
so-called "superbit"— the flag in the memory-bank register
that selects memory banks 40-43 vs banks 30-33 — actually
consists of 3 bits even though single bit is needed.
The extra two superbits would have been used to select the
various auxiliary-memory functions mentioned above.
Actually, the story I've been told (by MSC's Clark Neily) is that there was an intense dispute (which he labeled The Rendezvous Wars) between the optical camp (led by Max Faget) and the radar camp. You can read Clark's extended comments about it in our document library. The radar camp won for Apollo, but lost for the shuttle. Such is life!
At any rate, Super Job is a test program for this tape-drive system. While we provide the transcribed source code for SuperJob, it's probably not too useful to run it in the AGC simulator as of yet; probably the tape drive itself will have to be simulated as well, perhaps with a new program that might be named yaTape. Or not; we'll have to wait and see. It's also worth noting that the scanned program listing is rather wimpy in places, and has no niceties such as memory-bank checksums to give us confidence that the transcription of the source code is correct ... but we hope (and think) it probably is.
And finally, as you may have realized, there is actually no logical reason for including Super Job here on the Luminary page. There's nothing in the documentation suggesting that it would be installed in the LM vs the CM. Rather, it's just a generic concept that might apply to either spacecraft, or to both of them. But it has to go somewhere, so here it stays!
|| As colorized,
hyperlinked HTML of Sundance306ish
(reconstruction phase 2)
Navigation, and Control Lunar Module Functional
Description and Operation Using Flight Program Sundance,
LM Digital Autopilot Study Guide, Sundance 302
Lunar Module Systems Handbook, LM-3
Apollo Operations Handbook, Lunar Module 3
| Executive summary: This is a
program we have and yet don't have. I say we do,
but there are legitimate grounds for disagreement, and you
may need to decide for yourself whether or not you agree
with me. At any rate, we do have software that allows
you to fly Apollo 9 missions. Read on, for more
Here is some info from James Kernan, one of the LGC developers, in response to a question from me about about correct versioning of Sundance:
Sundance 306 is correct. I was the "rope mother" for Sundance-Apollo 9. ... Sundance was not only the Apollo 9 LM flight program, it was also the development bed for the Lunar orbit and landing software. At some point we created a version and called it Luminary. I think the last few revisions of Sundance were devoted to disabling crew access to the Lunar orbit and landing software that was present in the build.
Jim also tells me that a copy of Sundance 306 may still "be in the building". I'm not certain which building he's talking about, but it's nevertheless interesting news that a copy of the program does exist somewhere.
Not being "in the building" ourselves, we have no copies of the full Sundance 306 program, nor of any other revision of Sundance source code. Annoying! Nevertheless, we do have quite a bit of access to Sundance software. What do I mean by that cryptic statement? Well, within the AGC itself, Sundance (or any other AGC program) physically resided in executable form, in up to 6 core-rope modules, denoted as modules B1 through B6. Various individual Sundance physical rope modules have shown up in private collections and auction sites, and Mike Stewart has sometimes been able to dump their contents using Jimmy Loocke's restored AGC. While these disparate dumped modules do not form a complete set of software for any one Sundance revision, they are tantalizingly close to doing so.
Mike's dumps of the individual Sundance modules reside in our GitHub repository. Here's a complete list of the modules for which we have dumps, and of the personal collections whence they originally came:
But how to fit them together to make something
usable? In case you're wondering, perhaps
they could just magically be compatible with one another,
so that you could simply stick they modules into an AGC
which you happen to have in your garage and have them work
correctly. Well, you should disabuse yourself of
that hope: These revisions of the core-rope modules
are not compatible enough to provide a working
Sundance program when you try using them together.
Quite the puzzle!
With some assistance from Nik Beug, Mike has been trying
to piece together this puzzle by reconstructing
Sundance 306 from these binary dumps and other existing
material. If Mike succeeds, it would be quite a
coup, since we already have the Apollo 9 CM software
(Colossus 249). Thus if we had Sundance 306 as well,
we would have the complete Apollo 9 mission
This software reconstruction turns out (surprise!) to be
quite difficult, and is not yet complete, but the effort
has been rewarded with great success. It is a
As you may imagine, any comments appearing in such source
code that has been reconstructed from the dumped memory
modules could not have come from the core ropes
themselves. In almost all cases they come from
corresponding lines of source code in Luminary, and may be
The most-important takeaway from this is that you can
presently fly an Apollo 9 mission using reconstructed
SundanceXXX software in the LM and Colossus249 software in
the CM. We would expect the same to be true of the
reconstructions produced in phases 2 and 3, if/when they
|| Luminary 1
Reduced-size scanned JPG
High-quality scanned JPEG 2000
LUMINARY Memo #75
LUMINARY Memo #78
|This seems to have been the first
Luminary revision targeted at the Apollo 10 mission, and
seems additionally to have been the first revision of
Luminary for which core-rope modules were
manufactured. In other words, it was the first
non-developmental revision of Luminary and the first
released for manufacturing.
Nevertheless, it ended up not being flown in the mission. (Instead, see Luminary 69/2 below.)
The version we have here is from Don Eyles's private collection, as scanned by archive.org, and financially sponsored by our Onno Hommes.
|069/2||As colorized, hyperlinked, HTML||We do not have any
scans of the Luminary 69 Rev. 2 software used in the Apollo
10 Lunar Module. But, that software can be
reconstructed with confidence, and that's what's presented
here! For simplicity, we'll refer to it simply as
LUM69R2, and the revision for which we actually have scans
(see the item above) as LUM69.
How is such a reconstruction even possible? Well, Mike Stewart did the reconstruction, and has explained it in quite a bit of detail. However, I'll try to give you a relatively brief overview. There are 4 key ingredients:
With all of that at our disposal, the appropriate changes
in Luminary 99 can be back-ported to Luminary 69, and then
the fact that we know the LUM69R2 checksums means we can
check that the back-ported changes do indeed produce the
proper bank checksums.
As a cross-check, Nik Beug has flown the reconstructed
software in the Orbiter/NASSP Apollo 10 simulation, and
reports that it works as expected.
So in conclusion, we're pretty sure we do have the
LUM69R2 software for Apollo 10, without ever
having been given the assembly listing for the software!
||As colorized, hyperlinked, HTML7||
Erasable pad loads
Excerpted LM Systems Handbook
The 1201/1202 alarms
The Apollo 11 Adventure
Operational Data Book
"Exegesis of the 1201
and 1202 Alarms Which
Occurred During the
Mission G Lunar
Digital simulations of the landing:
|Luminary 96, 97, and 98 were the
initial development revisions of the Apollo 11 code.
We do not have physical program listings for any of them,
but their source code has been reconstructed from other
available data, and we are confident that these
reconstructions are correct.
How can we be confident of that? Mike Stewart performed the reconstruction and has provided a detailed explanation (Luminary 97 and 98 here and Luminary 96 here). In brief, we have known-good source code for Luminary 99 (see below). LUMINARY memo #85 describes the differences between Luminary 99 and 98, so we can use that information to reconstruct Luminary 98 from 99. Similarly, LUMINARY memo #83 describes the differences between Luminary 98 and 97, so that allows reconstruction of Luminary 97 from 98. As far as Luminary 96 is concerned, the software anomaly report LNY-59 describes two minor differences between Luminary 96 and 97. Meanwhile, engineering drawing 2021152 lists all of the memory-bank checksums for Luminary 96 and 97; since they match the reconstructed Luminary 96 and 97 code exactly, we can be confident that Luminary 96 and 97 are very likely to be correct.
Unfortunately, Luminary 98 was merely an engineering revision of the software for which no core-rope modules were manufactured, so drawing 2021152 does not record its memory-bank checksums. However, since the correctness of our Luminary 98 reconstruction is a prerequisite for the correctness of our Luminary 97 reconstruction, which we are confident in, we can have a pretty fair degree of confidence that Luminary 98 is correct as well.
Luminary 96 and 97 are connected by a very interesting story. I'll let James Kernan, one of the original AGC developers and the Apollo 11 Luminary "rope mother", tell it in his own words:
I was an employee at Draper Lab, and was in charge of the Lunar Module LGC computer programming group and also in charge of Assembly Control for the flight software during the Apollo 9-12 software development period. The latter responsibility included reviewing all proposed alterations to the flight software and the YUL assembler inputs.
I can explain the confusion over the Luminary version that flew on Apollo 11. We were aiming for Luminary Revision 99 as the Apollo 11 Lunar Module flight software. There was a tradition (or rule) that the flight software version should have no revision, so we renamed Luminary Revision 099 as Lum99 Revision 0. At the last minute, Dan Lickly, our chief engineer, appeared with ephemerides updates and it took two tries to get it right. The result was that we created Lum99 Revision 1 and Lum99 Revision 2. We made a no-change version of the latter and named it Lum99R2 Revision 0.
The tapes and ropes were made from that. That is my recollection. Unfortunately, I did not have the foresight to keep a printout of the flight version.
Some years later, he retells the story as follows:
The evening of the release for Apollo 11, John Sutherland and I were in the assembly control room about to make the final assembly of Luminary. For reasons unsupportable by reason, I had decided that the Luminary revision for Apollo 11 would be less than 100 and lo and behold we were about to make revision 99. The procedure for releasing a program for manufacture entailed assigning a <unique name> Revision 0 by NASA <part number>. The Revision Number had to be 0 and the author had to be NASA with the manufacture part number included. So we chose Lum99 Revision 0 by NASA <part number>. We had previously got the part number from Bob Millard in the Program Office. The LM part numbers were in the 2 million series (if I remember correctly) and CM numbers were one million. We had just made LUMINARY Revision 99 when Dan Lickly, our chief engineer, came into the room with the news that the ephemeris numbers had to be updated. This seemly upset my desire to keep the revision number under 100. But the Yul system was flexible. We changed the name to LUM99R1, and since it took 2 to get the ephemeris numbers right, the final listing is named LUM99R2 Revision 0 by NASA <part number>. So if you have a listing of what you think is the landing program for Apollo 11, look at the name, revision, and author to make sure. I did not keep a copy ( I wish I had). The mainline development of Luminary for subsequent missions continued with revision 100.But wait, you say: These stories relate to Luminary 99, not to 96!
Yes, that's true. But Jim's stories have a problem, in that there's no documentary evidence whatever to support them if taken at face value. Every other scrap of evidence we have, some of it quite compelling, tells us that Luminary 99 rev 1 was flown in Apollo 11, and there is no mention at all, anywhere, of a Luminary 99 rev 2.
So how are we to reconcile Jim's very-detailed recollections with the documented facts? As mentioned above, software anomaly report LNY-59 tells us that there's a problem in Luminary 96, and that the problem is two incorrect ephemeris constants ... which could easily be exactly what Jim remembers being wrong about Luminary 99 rev 1. Moreover, LNY-59 was filed by Jim himself! So insofar as the specific software problems are concerned, it's easy to see that Jim's stories are more likely to be about Luminary 96/97 than about Luminary 99 rev 1/2.
And yet ... Jim's stories are so detailed. He's so certain about them. And they persist over time. How could they possibly be wrong in the way I'm suggesting?
As it happens, I've just finished reading a book about how human memory works — if you're interested, it's Remember: The Science of Memory and the Art of Forgetting, by Lisa Genova — and from it, this kind of memory error seems extremely plausible. The book says that in some sense, human memory is a kind of read-writeback system; in other words, every time you recall a memory, it is then subsequently written back to refresh it. So what you recall the next time isn't the original memory, but instead whatever was written back the previous time you recalled it. Moreover, the memory may have been subtly, unintentionally edited in the brief interval between recall and writeback. The whole thing is like a game of Telephone, in which a repeatedly-retold story inevitably become mutated while being retold, until it is unrecognizable when it eventually returns to its originator. Ironically, the bigger the impression the event originally made upon you — as is the case in this story of Jim's — the more certain you are of your memory of it, but also you retell it more often, and hence your recollection of the event mutates more over time. And why would it mutate in just this way? Well, it makes a lot better story if it occurs at the last minute in the final release of Apollo 11, rather than in an earlier version that ended up not being flown. Every time the story is repeated, it's under pressure to mutate in a way that make it more interesting or significant. Keep that in mind the next time you embellish one of your memories when you recount it as a story to impress someone; you're fooling not just your listener, but maybe your future self as well!
On the other hand, I'm no memory expert myself, so you can accept or reject my rationale about Jim's story however you like.
Actually, Jim's story is correct in one interesting regard, namely that the ephemeris data in Luminary 99 Rev 1 still ended up being out-of-date, but just not out-of-date enough to be of concern. I'm sure Jim knew this, and that it probably had some role in mutating his recollection. How do we know the ephemeris was outdated? Well, ephemeris data in an AGC program covers the timespan of a year, beginning on July 1 of one year and continuing through June 30 of the following year, and so the missions in the time range July 1, 1969, through June 30, 1970, should all have the same ephemeris data. Those missions happen to be Apollo 11, Apollo 12 , and Apollo 13. The ephemeris data is roughly the last 50 lines of the CONTROLLED CONSTANTS in the Luminary source code, or in this case
and it's pretty easy to see that there's a mismatch
between Luminary 99 Rev 1 and the other two. Nor, as
Jim's story would suggest, does it match Apollo
(Luminary 69), from the preceding 12-month
interval. But not to worry! Apollo 11
ephemeris, as flown, was slightly out of date, but it was
plenty fine for a lunar landing. I presume is why
they didn't bother to correct it until Apollo 12.
(As it happens, I created the source code for a
hypothetical Luminary 99 rev 2, with the correct
ephemeris, before LNY-59 was discovered, back when we
still believed that Jim's story really related to Luminary
99 rev 1. You can still find the source
code for that in our software repository. But
it's of no historical value or validity, though it does
work fine for a lunar landing, so I no longer include it
in this table.)
||As colorized, hyperlinked, HTML|
||As colorized, hyperlinked, HTML|
||As colorized, hyperlinked, HTML||One of the original AGC programmers, Allan
Klumpp, kept a copy of Luminary 99 Rev 0 (or 99/0 for
short), since donated to klabs.org,
having been told that it was the version that flew on Apollo
11. Unfortunately, that turns out not to have been the
case, but it was indeed the first revision of Luminary
released for manufacture for Apollo 11 ... by which I mean
that its core-rope memory modules were actually
manufactured, though not flown.
We know that the program identifies itself as "REVISION 099 OF AGC PROGRAM LUMINARY BY NASA 2021112-051" in the page headings of the printouts, so from the chart at the top of this page we know that it's the revision immediately preceding the flown version. Unfortunately, we at the Virtual AGC Project have never actually had access to the Luminary 99/0 hardcopy itself, or to any scans of it. I hope some day to have it scanned, though with each passing year that seems an increasingly distant dream. Apparently, Luminary 97 was actually the first AGC software version actually targeted for Apollo 11, and thus had already been modified by the time of Luminary 99/0.
As it turns out, our Mike Stewart (thanks Mike, and Nik Beug who also helped out) has noticed that we have just enough info at our disposal to reconstruct the source code for Luminary 99/0 even in the absence of the program listing itself. And having reconstructed the source code, we thus get the executable octal rope for free, and can run it in the AGC simulator.
The source code reconstructed by Mike is what you see linked at the left.
A few things worked in Mike's favor in performing the reconstruction. For one thing, at the time the reconstruction was done, we already had the program version immediately following it (namely Luminary 99/1, see the very next row in this table), and a version not much earlier (namely Luminary 69/2, see the preceding row in this table). For another, in hardcopies of program listings like those for Luminary 99/1, the relatively few lines which have changed from prior versions are marked with a *, making them relatively easy to find. Finally, while Allan did not give us his hardcopy of Luminary 99/0 to scan, he did agree to look at the memory-bank checksums for us, and was kind enough to give us the checksum of the single memory bank that differed from 99/1 ... so we could easily verify that the reconstruction was very likely to be correct. Of course, one can never be 100% sure, in the continued absence of the hardcopy. But we're pretty confident that the reconstruction is accurate; admittedly, it's possible we may not have found all of the program-comment changes.
In case you're wondering, the only change between this version and the flown version (099/1) is the correction of a long-standing bug, in which a reset of the computer incorrectly reset (cleared) certain of the hardware timers, thus resulting in events that were triggered by the next expiration of those timers occurring at the wrong time.
|| As colorized,
(MIT Library printout)
As scanned page images (very big!)
(Don Eyles's "AP11ROPE" printout)
Reduced-size page scans (JPG)
Full-resolution page scans (JPEG 2000)
| This is the AGC software
version that was flown in the Apollo 11 Lunar Module.
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.
Below, you can see a video made by Niklas Beug, in which this Luminary 99/1 AGC software is used to make a simulated Apollo 11 lunar landing, using the Orbiter spaceflight simulator, with the NASSP 7.0 Apollo-mission add-on and our own AGC CPU simulator. (A higher-resolution version is probably available if you go directly to YouTube.)
The MIT Museum copy is dated 14 July, 1969, which seems odd at first glance, since it would be far too late to actually have been included in the Apollo 11 mission. AGC developer Hugh Blair-Smith speculates that this is the date of the printing rather than of the program build, and that seems plausible ... it seems as though you'd want to have it, for historical purposes! At any rate, the printout identifies itself as "REVISION 001 OF AGC PROGRAM LMY99 BY NASA 2021112-061", which according to the chart at the very top of this web-page tells you that it is indeed the version that was flown in the mission ... but keep reading, because there are curious postscripts!
AGC developer Don Eyles also has a copy of Luminary 99, though oddly named AP11ROPE BY EYLES rather than LMY99 BY NASA, and it was printed in 1970 for some reason. Our scan was financed by Vipin Rathor (thanks, Vipin!) After a full analysis of AP11ROPE yet, I can tell you the following:
The 1969 digital simulation was done a few days after the actual landing. While we're not 100% sure why it was made, one speculation is that it was done in order to investigate the causes of the 1201 and 1202 program alarms that had been experienced during the landing itself. Don Eyles agrees that this must have been what he intended, and points out that his notes indicate that TLOSS (the maximum amount of CPU time that it was permissible to "lose") was set to 10% in that run. (It was the fact that the CPU time lost in interacting with the rendezvous radar was excessive that caused the Apollo 11 1201/1202 alarms. See LUMINARY Memo #140, for example, for some background information about TLOSS.)
Also, you may wonder, why was there a digital simulation of Apollo 11 in 1971, a couple of years after Apollo 11 landed on the moon? Shouldn't the simulations only have been useful before the landing? Well, Don Eyles had this simulation performed for his own purposes and (after nearly 50 years!) is no longer sure quite what that purpose was. He worked on several off-the-main branch AGC programs, such as ZERLINA (see below), intended to explore improved methods for performing the landing; my theory is that this simulation provided baseline data against which to measure such improvements, and Don admits that this is a plausible theory.
Speaking of ZERLINA, if you examine the full-color scans for the digital simulation found at archive.org, you may notice that the label on the binder (removed in the B&W PDF I've posted here at this site) identifies the 1971 simulation as "DIANA Rev. 12". It is not DIANA, however: the binder containing the simulation's printout had formerly contained a copy of DIANA, we believe, and Don simply reused it for this printout without relabeling it. DIANA was another off-the-main-branch program, like ZERLINA, which was developed by Peter Adler and Don Eyles in order to explore an improved time-sharing technique that would avoid the 1201 and 1202 program alarms experienced in the Apollo 11 landing. The approach wasn't adopted, though, and copies of DIANA no longer exist as far as we know. (At any rate, neither Don nor Peter has a copy.)
|| Luminary 1B
Reduced-size scanned JPG
High-quality scanned JPEG 2000
LM Systems Handbook
Operational Data Book
Spacecraft Operational Trajectory
Programmed Guidance Equations for Luminary 1B
Digital simulation of the lunar landing
E-2260: Guidance, Navigation, and Control Lunar Module Functional Description and Operation Using Flight Program LUMINARY (Rev. 116)
from the hardcopy in Don Eyles's private collection, as
scanned at archive.org (sponsored by Ron Burkey, me).
Unfortunately, the printout is pretty faint, and pp.
217-220, 226 are entirely missing. But we've worked
around the missing pages and have been able to completely
Regarding the Programmed Guidance Equations document hyperlinked at the left, it is an MSC document whose purpose is "to provide more effective identification and analysis of various program performance features and to permit more effective review of published computer program documentation". In other words, while it does contain material related to guidance equations, it is perhaps better to think of this as being a pseudo-code description of the Luminary 116 program.
The digital simulation of the landing, from Don Eyles's personal collection (with scanning financially sponsored by Matthew Fite), had been made a few months after the Apollo 12 landing itself. But why? Surely, the simulation is useful only before the landing? Niklas Beug has researched the matter, and has noticed that a couple of the pad-load settings (namely TCGIBRAK and TCGFBRAK) in the digital simulation are a bit puzzling. What these tricky pad-load values do is to prevent the time-consuming computation of the matrix for converting between the coordinate system of the Inertial Measurement Unit's stable platform and the coordinate system of the landing site from occurring within P63. This is fine because the stable platform is aligned (by the astronauts) with the landing site reference frame before the approach occurs, so the two coordinate systems are one and the same. The Apollo 12 software, then, was used for testing that this would work simply because it was coincidentally the most-current software revision at the time, and not because the digital simulation had anything to do with Apollo 12 as such. And Niklas has actually performed a simulated landing with these pad-loads to insure that it can be done. Admittedly, Don Eyles isn't particularly receptive of this explanation, so the conclusion remains in doubt.
As far as document E-2260 is concerned, its preface say the following: "The purpose of this document is twofold. The first is to provide a functional description (operationally oriented) of the LM 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 LUMINARY 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."
||As colorized, hyperlinked, HTML||
Excerpted LM Systems Handbook
Operational Data Book
|Luminary 130 was the
first software release whose ropes were manufactured for the
Apollo 13 LM. There were several subsequent releases
due to bug fixes, so it never actually flew.
We do not have a physical assembly listing for Luminary 130, but it has proven possible to reconstruct the source code with complete confidence (thanks, Mike Stewart!).
The reason this is possible is that we have a scan of a Luminary 131 assembly listing, plus LUMINARY Memo #129 describing the differences (all minor) between 130 and 131, thus making it possible undo those changes. Finally, the recently-uncovered engineering drawing 2021152 lists all of the memory-bank checksums for Luminary 130, thus making it possible to verify that the modified code has the proper memory-bank checksums.
|| As colorized,
Scanned page images from HRST (very big, very poor quality!)
Scanned page images, Don Eyles (very big, medium quality!)
Scanned page images, Don Eyles (very very big, good quality!)
| This is the second Luminary release
whose ropes were manufactured for Apollo 13, but it was not
the revision eventually flown in the mission. Unfortunately,
for over a decade, I said here that it was the revision
actually flown. Niklas Beug was sharp enough to notice
what I was not, namely in the table from document R-700 shown at the
top of this very web-page that what we have is
the first version (December 1969) of Luminary 131, but that
subsequent versions were released in January and February
1970, and it was the latter of which that was flown.
In the early years of this project (2003-2016), we relied on a scanned PDF of Luminary 131 that had appeared on the now-defunct History of Recent Technology (HRST) website. We're not entirely sure of the history of that scan, though there is a great cover letter from original AGC developer Jim Kernan that goes with it. What we are pretty sure of is that David Craig, apparently a great collector of AGC artifacts, asked for an AGC program listing, got this one (possibly xeroxed by Hugh Blair-Smith according to one theory), and that Gary Neff scanned it, passing the scans along to the HRST website administrators. Unfortunately, the image quality became severely compromised after that point ... but whatever the image quality, we have to be grateful to all of these folks, because it was really the existence of this scan that made our entire Virtual AGC project possible. Thanks, guys! Gary Neff also later kindly provided me with a replacement for a page which is garbled in the HRST version. This original scan is still available, linked at the left as "Scanned page images from HRST".
Nevertheless, however grateful we may feel for the HRST version, we're luckier today to have an infinitely superior scan, made for us from the personal collection of AGC developer Don Eyles, and scanned for us by archive.org. A few pages (1728-1734) happen to be missing from Don's copy, and I've simply inserted them from the HRST copy.
Finally ... we can tell that these two different scans actually came from the same physical copy. This makes sense from Jim Kernan's cover letter to David Craig, which says that Don Eyles supplied it. However, if you try to check the scans for the hand-written notes that appear on many of the AGC listings, you soon realize that the HRST version doesn't have the notations that the Eyles version has, which is at first blush is impossible from the same printout! Well, if you're persistent enough, you do eventually find notations that appear on both of them. (Look on page 750.) So the conclusion must be that Don (or somebody) wrote in most of these notes after the HRST version was copied in 1991, rather than during the actual Apollo project. Isn't that nice to think that the program was actually being read and deeply examined, instead of simply being forgotten on a shelf?
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.
Regarding the Programmed Guidance Equations document hyperlinked at the left, it is an MSC document whose purpose is "to provide more effective identification and analysis of various program performance features and to permit more effective review of published computer program documentation". In other words, while it does contain material related to guidance equations, it is perhaps better to think of this as being a pseudo-code description of the Luminary 116 program. (On the other hand, Section 5 of the GSOP, "Guidance Equations", also hyperlinked at the left, does indeed cover this topic explicitly.)
||Perhaps soon ...
||This is the third Luminary release whose
ropes were manufactured for Apollo 13, but it was not the
revision eventually flown in the mission.
In calling it revision 131/9, I am really shorthand for "LUM. 131 REV. 9", which is a very curious designation, considering that it is "LUM. 131 REV 1" from a few months later that actually flew in the mission. My guess is that "REV. 9" is really itself a shorthand for "REV. 0.9".
||Perhaps soon ...||This is the fourth and final Luminary release whose ropes were manufactured for Apollo 13, and it was the revision eventually flown in the mission.|
Scanned page images (big, medium quality!)
Scanned page images (very big, good quality!)
||Digital simulation of a lunar landing: low resolution
||ZERLINA was an
off-the-main branch AGC program, by Don Eyles, which
experimentally developed a number of proposed improvements
to Luminary. Some of these improvements were actually
incorporated in later versions of Luminary ... but also,
many were never used, even where they were demonstrably
better, due to the need to avoid unnecessary risks —
changing software is always a risk! — as the Apollo program
approached its end. For example, I believe that improved
methods for increasing the positional accuracy of the
landing were explored in it, partially due to some ideas of
astronaut John Young, who flew Zerlina in the LM simulator.
Our scan of ZERLINA, by the way, was financially sponsored by Linden Sims. Thanks, Linden!
Zerlina itself was apparently branched from Luminary 145, and was developed independently for a period of 6-7 months. Quite a few LUMINARY Memos describe the evolution of Zerlina, such as memos #138, #149, #161, #171, and #177. Memo #177 covers Zerlina 56 specifically, so as far as we know, 56 was probably the last version of Zerlina.
Zerlina was not the only such experimental branch of the AGC code, but it is the only one (that we know of) to have survived, and it is the one about which we have the most information.
Regarding the digital landing simulation linked at the left, it is an Apollo-era simulation run by Don Eyles, rather than a "modern" simulation done by the Virtual AGC project. The printout came from Don's own private hoard, and the scanning for our Internet Archive collection was financed by Niklas Beug and Alex Bart (thanks, guys!).
In fact, Nik has actually flown a lunar landing using Zerlina in the NASSP/Orbiter spacecraft simulator, and has shared a video of it:
|| Luminary 1D
||As colorized, hyperlinked, HTML||AGC
LM Systems Handbook
The solder ball
Users' Guide to Apollo GN&CS Major Modes and Routines, Rev 1
Apollo Guidance and Navigation Flowcharts, Program Luminary 1D (Rev 173): Volume 1/2 and Volume 2/2
Operational Data Book
163 and Luminary 173 were the first and second revisions of
Luminary targeted for the Apollo 14 Lunar Module.
Their core-rope modules were manufactured, but they were not
actually flown in the mission. (See Luminary 178
No contemporary program listings for Luminary 163 and 173 are known to us, but the programs have been reconstructed with a high degree of confidence. You should consult Mike Stewart's notes on the reconstruction (see issues #1098 and #1099 in our software repository) to understand the reconstruction process and the differences from software version to software version. Regarding confidence, however, the important point to note in these (and in all such) reconstructions is that in addition to matching the documented version-to-version changes, the memory-bank checksums of the reconstructed software match those of the manufactured core-rope modules as listed in MIT/IL engineering drawing 2021152N. However, things like program comments and page numbering, which do not affect the contents of the rope memory, may differ from those of the true program listings.
||As colorized, hyperlinked, HTML|
||As colorized, hyperlinked, HTML|| This is the actual flight program for
the Apollo 14 Lunar Module.
We've never found any original printout of the Luminary 178 program, but Mike Stewart has managed to reconstruct the program, and we have a very high degree of confidence that the reconstruction is correct. By that, I mean that the source code which has been reconstructed assembles to a core-rope image in 100% byte-for-byte (or word-for-word, to be picky) agreement with what was flown in Apollo 14 — i.e., a 100% correct executable program. However, because of the nature of the reconstruction process, it's extremely likely that some program comments or other superficial features that don't affect the final core-rope image won't agree perfectly with the original code, if/when we ever find a copy of it.
Mike describes the reconstruction process in detail in his notes for issues #1093 and #1095 in our software repository, but don't read them unless you want to be awed. I'm willing to summarize it for you in a slightly less mind-boggling way.
At the time the reconstruction was done (Summer 2019), the closest revisions to Luminary 178 that were available to us were those of Luminary 131 (Apollo 13) and Luminary 210 (Apollo 15). Note the huge gaps: There were 47 revisions of Luminary between Apollo 13 and 14, and 32 revisions of Luminary between Apollo 14 and 15 ... and the reconstruction requires you to either add in or subtract out most of those changes! So how does one fill in such huge gaps?
Fortunately, Mike noticed additionally that we had a copy of Zerlina 56, which is not technically Luminary, but which was branched from Luminary 145, and had had most of the changes up through Luminary 183 added to it afterward. So Zerlina 56 ought to be much closer to Luminary 178 than either Luminary 131 or 210 is. Additionally, our document library has a vast store of "Luminary Memos", many of which are devoted to describing (albeit only textually) the differences from one Luminary (and Zerlina) revision to the next. Simply slogging through all of the differences between Luminary 131, Luminary 210, and Zerlina 56, and cross-referencing those differences to the Luminary Memos (and other supporting documentation), was all it took to reconstruct Luminary 178. Well, that and a lot of cleverness, and several months of effort! In the end, Mike says that only 6 lines of code needed to be written from scratch, as opposed to being taken as-is from one of those other sources.
And perhaps most-importantly, since nobody (even Mike!) would have been likely to attempt a reconstruction without it, we have MIT/IL engineering drawing 2021152N. This drawing is a list of the memory-bank checksums of all manufactured Luminary rope-memory modules. Since the memory-bank checksums for Luminary 178 listed in drawing 2021152N agree with the memory-bank checksums you get when you assemble the reconstructed Luminary 178 source code, we are confident the reconstruction is correct!
As the final icing on the cake, Niklas Beug, a developer and user of NASSP, the Apollo-mission add-on for the Orbiter spaceflight simulator, has flown the reconstructed Luminary 178 code in the simulator, and performed a landing with it, apparently without problems of any kind ... I guess that means that the simulator didn't have a ball of solder rolling around inside the control panel and threatening to short out the ABORT button. (Ha!) I have no video of the simulated landing to show you, but at least you can see the lander resting at Fra Mauro at the end of the simulation in the following screenshot:
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.
||AGC developer Allan Klumpp retained a copy
of Luminary 209, based on the the belief that it had flown
on Apollo 17. Unfortunately, this turns out not to
have been the case, and it was really Luminary 210 that flew
(see below). But that doesn't invalidate the value of
Luminary 209. We'd still like to scan it and present
it for you here!
As it turns out, the printout was donated to klabs.org before we could get access to it, nor do we have access to it today, but perhaps we'll be able to scan it some day.
As colorized, hyperlinked, HTML
Reduced-resolution high-contrast black&white PNG
Reduced-resolution scanned color JPG
High-resolution scanned JPEG 2000
| LGC Data
LM Familiarization Manual
|Luminary 210 is what flew
on Apollo 15-17. The scan we have is taken from AGC
developer Don Eyles's collection, as scanned by archive.org,
and financially sponsored by our Jim Lawton. Thanks,
Below, you can see a video made by Niklas Beug of a simulated Apollo 15 lunar landing, using this Luminary 210 AGC software and the Orbiter spaceflight simulator, with the NASSP 8.0 Apollo-mission add-on and our own AGC CPU simulator. (A higher-resolution version is probably available if you go directly to YouTube.)
Regarding "digital simulation" of the Apollo 17 landing hyperlinked at the left, it is an Apollo-era computer run (not one done by our project!), also from Don Eyles's collection, scanned by archive.org, and financially sponsored by our Fabrizio Bernardini. It includes things like the pad loads, position of the LM at any given time, what's displayed on the DSKY at those times, and so forth.
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.
| Program Notes
Operational Data Book
LM Familiarization Manual
| Apollo 17
Excerpted LM Systems Handbook
Operational Data Book
LM Familiarization Manual
Landing digital simulation:
||Source code for major subdivisions of the Luminary program.|
||Organizer which treats
all of the other assembly-language files (*.agc) as
include-files, to form the complete program.
||Human-readable form of
the Luminary binary executable, as an octal listing.
||Binary executable created
from binsource (octal listing) file.
Technically speaking....A point which may not be completely appreciated is that Luminary131.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 Luminary131.bin (or Luminary131.binsource) come from separate readings of the original Luminary assembly listing scan, so their equivalence provides an important check on validity. (See below.) The file Luminary131.bin was created from the human-readable/editable ASCII file Luminary131.binsource by means of the program Oct2Bin, with the following steps:
mv Oct2Bin.bin Luminary131.bin
Admittedly, few people are likely to perform any processing of this kind unless contributing a new version of the Luminary code to the Virtual AGC project.
The binary thus produced by yaYUL
is supplied in the source tree and used for regression testing.