Revision 226ce0dab5018739e8793d5cc421a5e39590e51b authored by Ron Burkey on 24 September 2021, 13:52:10 UTC, committed by Ron Burkey on 24 September 2021, 13:52:10 UTC
used in Apollo 4.
1 parent efa5595
Luminary.html
<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Virtual AGC Luminary Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Author" content="Ronald Burkey">
<link rel="icon" type="image/png" href="favicon.png">
<meta name="author" content="Ronald S. Burkey">
<script type="text/javascript" src="Header.js"></script>
</head>
<body style="background-image: url(gray3.jpg);">
<script type="text/javascript">
document.write(headerTemplate.replace("@TITLE@","Luminary — Sunburst — Sundance").replace("@SUBTITLE@","Lunar Module Flight Software"))
</script>
<h2>Contents</h2>
<ul>
<li><a href="#What_is_Luminary_">What is "Luminary"?</a></li>
<li><a href="#Known_Software_Versions">Available and
Particularly-Desired Lunar Module Software Versions</a></li>
<li><a href="#Source_Code_and_Binary">Source Code and Binary</a></li>
<li><a href="#Validity">Validation</a></li>
<ul>
<li><a href="#Validity_of_the_Luminary_131_Source_Code">Validity
of the Luminary 131 Source Code and of the Binary (Apollo
13)</a></li>
<li><a href="#Validity_of_the_Luminary_099_Code_">Validity of
the Luminary 099 Code (Apollo 11)</a></li>
</ul>
</ul>
<h2><a name="What_is_Luminary_" id="What_is_Luminary_"></a><small><big>What
is
"Luminary"?</big><br>
</small></h2>
<a href="AGC-versions.jpg"><span style="font-weight: bold;"><img
alt="AGC software family tree" title="Click on the image to
enlarge." src="AGC-versions-thumb.jpg" style="border: 2px
solid ; width: 132px; height: 160px;" width="219" hspace="16"
height="360" border="0" align="left"></span></a><span
style="font-weight: bold;"><a href="a042186-051.jpg"><img
src="a042186-051-small.jpg" alt="" width="140" height="160"
border="2" align="right"></a></span><a href="a042186-033.jpg"><img
src="a042186-033-small.jpg" alt="" width="116" height="160"
border="2" align="right"></a><a href="R700-3-Table4-II.jpg"><img
alt="" title="Click to enlarge" src="R700-3-Table4-II-small.jpg"
width="171" height="160" border="2" align="right"></a><span
style="font-weight: bold;"><a href="R700-3-Table4-I.jpg"><img
src="R700-3-Table4-I-small.jpg" title="Click to enlarge"
alt="" width="174" height="160" border="2" align="right"></a>Luminary</span>
is name of the mission software which was run on the Apollo Guidance
Computer installed in the Lunar Module (LM) in all of the later
missions, Apollo 10 through 17. Actually, the title of this
web-page and this section, "Luminary", is a bit of a misnomer, since
we don't limit ourselves to just Luminary. We present <i>all</i>
versions of AGC software targeted for the Lunar Module that we can
get our hands on. The earliest such software had names like <b>Retread</b>,
<b>Aurora</b>, <b>Sunburst</b>, and <b>Sundance</b>. <br>
<br>
In order to be loaded into the AGC—actually, to be converted to the
"core ropes" within the AGC—it was necessary to "assemble" the Lunar
Module's software source code into binary machine language, using a
computer program called <span style="font-weight: bold;">YUL</span>.
In the context of the Virtual AGC project, of course, the process is
somewhat different: The Lunar Module source code is assembled by the
<span style="font-weight: bold;">yaYUL</span> program, and then
loaded into the <span style="font-weight: bold;">yaAGC</span>
simulation.<br>
<br>
The figure at left (click to enlarge), drawn by me, concisely
depicts the relationships among the LM AGC software and the
relationship with the CM's AGC software, while the tables to the
right (click to enlarge) depict the various versions of the software
as given by Apollo-era documents. Additional contemporary
documents (<a href="hrst/archive/967.pdf#page=152">here</a>, <a
href="hrst/archive/967.pdf#page=31">here</a>, and <a
href="hrst/archive/1120.pdf#page=5">here</a>) add the following
release information for AGC software missing from (or sometimes
seemingly at odds with) the tables above:<br>
<br>
<table cellspacing="2" cellpadding="2" border="1" align="center">
<tbody>
<tr>
<th valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">Name<br>
</font></th>
<th valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">System<br>
</font></th>
<th valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">Release Date<br>
</font></th>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNRISE 38<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block I<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">Not Released<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNRISE 45<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block I<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">28 November 1964<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNRISE 69<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block I<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">15 March 1965<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">AURORA 85<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">LM<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">15 March 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">AURORA 88<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">LM<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">15 July 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNDIAL B<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block II<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">16 June 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNDIAL C<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block II<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">24 June 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SOLARIUM 54<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block I<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">November 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SOLARIUM 55<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block I<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">November 1966<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNDIAL D<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block II<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">1 March 1967<br>
</font></td>
</tr>
<tr>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">SUNDIAL E<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">CM Block II<br>
</font></td>
<td valign="middle" align="center"><font size="-1"
face="Helvetica, Arial, sans-serif">13 March 1967<br>
</font></td>
</tr>
</tbody>
</table>
<br>
<h2><a name="Known_Software_Versions" id="Known_Software_Versions"></a>Available
and Particularly-Desired Lunar Module Software Versions</h2>
<p>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 <a
href="links.html#LUMINARY_Memos">LUMINARY Memos</a>, 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.<br>
</p>
<table summary="" style="width: 95%; text-align: left; margin-left:
auto; margin-right: auto;" cellspacing="2" cellpadding="2"
border="1">
<tbody>
<tr>
<td style="font-weight: bold; text-align: center;"> Mission</td>
<td style="font-weight: bold; text-align: center;">LM Number</td>
<td style="font-weight: bold; text-align: center;"> Mission<br>
Type</td>
<td style="font-weight: bold; text-align: center;">LM Program</td>
<td style="font-weight: bold; text-align: center;">Revision<br>
</td>
<td style="font-weight: bold; text-align: center;">Source Code<br>
</td>
<td style="text-align: center;"><span style="font-weight:
bold;">Other Mission-Specific Documentation</span><br>
</td>
<td style="font-weight: bold; text-align: center;">Notes<br>
</td>
</tr>
<tr>
<td rowspan="2" colspan="1" valign="middle" align="center">N/A<br>
</td>
<td rowspan="2" colspan="1" valign="middle" align="center">N/A<br>
</td>
<td rowspan="2" colspan="1" valign="middle" align="center">N/A<br>
</td>
<td rowspan="2" colspan="1" valign="middle" align="center"><b>Retread</b><br>
</td>
<td valign="middle" align="center">44<br>
</td>
<td valign="middle" align="center"><a
href="listings/Retread44/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a
href="https://archive.org/details/blkiiretreadprog00sher/page/1/mode/1up">Scanned
page images</a></td>
<td rowspan="2" colspan="1" valign="middle" align="center">N/A<br>
</td>
<td valign="middle"><a name="RetreadNutshell"
id="RetreadNutshell"></a>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 <i>a
propos</i> since in fact the YUL development system
employed for AGC development didn't sport a linker.
(Joke! Feel free to ignore.)<br>
<span id="moreRETREAD44" style="display:none"> <br>
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!<br>
<br>
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 <i>perfect</i>,
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 <a
href="listings/Retread44/AGC_BLK2_INSTRUCTION_CHECK.agc.html">the
self-check
code</a>, run by VERB 21 NOUN 27 ENTER 1 ENTER, not all
of the CPU tests pass! (There is <a
href="https://github.com/virtualagc/virtualagc/issues/562">a
detailed write-up of this issue</a>, if you're
interested.)<br>
<br>
At any rate, this particular program listing came to us
from Don Eyles, via scanning at <a
href="http://www.archive.org">archive.org</a>,
financially-sponsored by Mike Higgins.<br>
</span><br>
<button onclick="toggleMore('RETREAD44')"
id="buttonRETREAD44">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">50<br>
</td>
<td valign="middle" align="center"><a
href="listings/Retread50/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
<td valign="top"><a name="Retread50"></a>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.<br>
<span id="moreRETREAD50" style="display:none"> <br>
<a href="https://www.computerhistory.org/"><img alt=""
src="chm-logo.png" width="153" vspace="6" hspace="6"
height="55" border="2" align="left"></a>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 <i>executable</i> 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. <i>Small</i> 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.<br>
<br>
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.<br>
<br>
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. <a
href="Restoration.html">Read our full write-up of the
AGC-restoration project here</a>.<br>
</span><br>
<button onclick="toggleMore('RETREAD50')"
id="buttonRETREAD50">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center"><b>DAP Aurora</b><br>
</td>
<td valign="middle" align="center">12<br>
</td>
<td valign="middle" align="center"><a
href="listings/Aurora12/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="https://archive.org/details/aurora00dapg">Scanned
page images</a><br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle"><a name="AuroraNutshell"
id="AuroraNutshell"></a>Don Eyles, one of the AGC
developers who you may know as <a
href="http://www.doneyles.com/LM/Tales.html">the hero of
Apollo 14</a>, has contributed the hardcopy of this
program from his personal collection.<br>
<br>
Now, for years I had presented this program here as "Aurora
12". That would make it a very <i>early</i> revision
of the Aurora program, and that would be somewhat of a
mystery.<br>
<span id="moreAURORA12" style="display:none"><br>
You see, the hardcopy we have is dated November 10, 1966,
and Aurora at the time should have had a much higher
revision level than 12. Why? Because the only
two revisions of Aurora we know of that were released to
manufacturing, Aurora 85 and 88,
were released in March and July of 1966, respectively,
months earlier. So how could this only be Aurora
12? Was it just a reprinting, for some unknown
reason, of a very early revision of Aurora? No, it
was not; it was a new revision on the very day it was
printed, which we know because of the messages printed by
the YUL assembler.<br><br>
No, the answer is that strictly speaking this is not even
the true Aurora program at all, either early or late.
Rather, it is a fork from the main Aurora
source-code tree made by the Digital Autopilot (DAP)
Group, apparently for the purpose of developing the
Sunburst program (see below). Indeed from messages
printed by YUL, we know that the then-most-recent assembly
of Sunburst 37 was made on that very same November 10,
1966. It's unfortunate in a way that the DAP Group
didn't choose a new name, such as "Papagena", for their
forked program in order to avoid confusion, rather than
continuing to call it "Aurora"; on the other hand, if they
had chosen a new name then perhaps it would have taken
longer for us to catch on that this really is a variant of
Aurora. Six of one, half dozen of the other. I have
unilaterally taken the step of calling it "DAP Aurora".<br>
<br>
How do I back up the claim that this program was being
used for Sunburst development? Well, for one thing,
there's a lot of (I'm told) very buggy Sunburst code in
it, all in memory module 4. True Aurora fit entirely
into memory modules 1 through 3, so true Aurora didn't
even have a memory module 4, let alone one filled with
Sunburst code.<br>
<br>
All right, then, if we agree that DAP Aurora is very "close"
to being true Aurora, in that it's basically Aurora
with extra Sunburst stuff stuck at the end. But is
it very close to being an <i>early</i> Aurora or is it
very close to being a <i>late</i> Aurora? The
answer is that it's close to a very late Aurora, and the
key to demonstrating that is System Test Group (STG)
Memo #824. STG Memo #824 is a list of software
changes that were made to turn Aurora 85 into Aurora
88. Some of the changes listed in that memo <i>have</i>
been made in DAP Aurora, and some <i>have not</i> been
made. Presumably this could only happen if DAP
Aurora derived from Aurora 86 or Aurora 87. So it's
very late, but still has a few bugs relative to the final
revision of true Aurora, namely Aurora 88.<br>
<br>
But enough of that. Let's get back to the provenance
of our copy of the program. At our request, Don
Eyles had it scanned by <a href="http://www.archive.org">archive.org</a>,
and Mike Stewart generously financially sponsored the
scanning. So, thanks Don and Mike! I suppose I
should mention that if page 52 or 70 of the images look a
little weird to you (oh, you conspiracy theorists with
your Photoshopping theories!), those were places where
there was a paper-change on the printer. <br>
<br>
Now before you go all elitist and thumb your nose at DAP
Aurora just because it never flew on an actual mission
(even an unmanned one) — and isn't even "real" Aurora
anyway — 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.<br>
<br>
More significantly, Aurora was the <i>last</i> version of
AGC code we know of to incorporate the full range of
the AGC's self-test software. In actual mission
software, most of this self-test 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 self-test code? 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 even original AGC may not have even been able to pass
for all we know. But now that we have DAP Aurora,
which has inherited all of the AGC-testing code inherited
from true Aurora 86 or 87, we can run the <i>real</i>
tests.<br>
</span><br>
<button onclick="toggleMore('AURORA12')" id="buttonAURORA12">Read
more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center"><b>Sunburst</b><br>
</td>
<td valign="middle" align="center">37<br>
</td>
<td valign="middle" align="center"><a
href="listings/Sunburst37/MAIN.agc.html">Syntax-highlighted,
hyperlinked HTML</a><br>
<br>
<a href="https://archive.org/details/sunburst37shepat00miti">Scanned
page images</a><br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle"><a name="Sunburst37"></a>This program,
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.<br>
<span id="moreSUNBURST37" style="display:none"> <br>
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. <br>
<br>
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.<br>
</span><br>
<button onclick="toggleMore('SUNBURST37')"
id="buttonSUNBURST37">Read more</button> </td>
</tr>
<tr>
<td style="text-align: center;">Apollo 5<br>
</td>
<td style="text-align: center;">LM-1<br>
</td>
<td style="text-align: center;">B<br>
</td>
<td style="text-align: center;"><span style="font-weight:
bold;">Sunburst</span><br>
</td>
<td style="text-align: center;">120<br>
</td>
<td align="center"><a
href="listings/Sunburst120/MAIN.agc.html">Syntax-highlighted,
hyperlinked HTML</a><br>
<br>
<a href="https://archive.org/details/yulsystemforagcr00nasa">Scanned
page images</a><br>
</td>
<td align="center"><a href="links2.html#Apollo5"> Document
Library</a><br>
</td>
<td><a name="Apollo5"></a>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
<a href="yaAGS.html">AGS</a> instead for some
maneuvers. The mission itself was not entirely
successful.<br>
<span id="moreSUNBURST120" style="display:none"> <br>
The "Programer" — actually some sources spell it
"programer" and some "programmer" — was a robotic gadget
that was the stand-in for the crew.<br>
<br>
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.<br>
<br>
In spite of the relative lack of resources about the
Apollo 5 mission, <a
href="https://github.com/dseagrav/NASSP">NASSP</a>
developer and enthusiast Niklas Beug tells us that <br>
<blockquote><small>... 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.</small><br>
</blockquote>
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:<br>
<blockquote><small>[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.</small>
<div><small><br>
</small></div>
<div><small>But then I wondered if I could at least try
Sunburst in NASSP, configured correctly with the
padload. So I decided to try and run Sunburst in a
CSM on the launchpad, in a scenario for the
historical Apollo 5 launch time. Sunburst is
special, because it has a lot more in common with a
CMC than any other LGC version. Sunburst has a
launch monitor program, very similar to the one used
in every CMC, It is connected to the Instrument Unit
of the Saturn vehicle like a CMC, so Sunburst gets
the same input channel signals for liftoff etc. as a
CMC. So in that way attempting to run Sunburst in a
CSM made a lot of sense.</small></div>
<div><small><br>
</small></div>
<div><small>... I managed to fly Sunburst120 into Earth
orbit, connected to a CSM and on the same trajectory
and time as the Apollo 5 mission. I then saved the
state of the mission, as usual with Orbiter in a
scenario file, and so had the state of the AGC as it
would have been during Apollo 5 after Earth orbit
insertion. Then I started my Dr. Frankenstein work,
by editing the scenario, removing everything of the
CSM and Saturn vehicles and replacing it with the
state of a Lunar Module that is fully powered up. I
only kept the state of the Sunburst erasable memory,
IMU alignment etc. in that scenario. And to my
suprise Sunburst did not complain that it was
suddenly connected to a LM! So I was sucessful in
circumventing the limitations of NASSP to create an
Apollo 5 scenario, that could be used as the
starting point for further tests.</small></div>
</blockquote>
<blockquote> </blockquote>
</span><br>
<button onclick="toggleMore('SUNBURST120')"
id="buttonSUNBURST120">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center"><b>Super Job</b><br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center"><a
href="listings/SuperJob/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="Documents/R68-4125-Volume2.pdf#page=10">Scanned
page images</a><br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle"><a name="SuperJob"></a>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. In fact, the program listing was hidden
in an Appendix of a Raytheon report.<span id="moreSUPERJOB"
style="display:none"><br>
<br>
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.<br>
<br>
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 <a
href="Gemini.html">our Gemini OBC (on-board computer)
page</a>, 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:<br>
<ul>
<li>An Auxiliary Core Memory (ACM) consisting of memory
cores: Up to 16K 16-bit words, though only 8K×16
bits were used in the prototype units Raytheon
actually built.</li>
<li>An Auxiliary Tape Memory (ATM) consisting of
magnetic tape (10<sup>8</sup> bits capacity).</li>
<li>The ability to transfer data from the ATM to the ACM
or vice-versa.</li>
<li>The ACM could be directly accessed in the
address-space of the AGC as either "extended fixed
memory" or "extended erasable memory" (see Table 2-2
in volume 1 of the Raytheon document hyperlinked to
the left).</li>
</ul>
<p>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.<br>
</p>
<ul>
</ul>
The rationale for the auxiliary memory was that as
"feature creep" (or perhaps "feature explosion") occurred
during AGC development, more and more memory was required,
surpassing the physical resources of the AGC itself.
Many "<a href="http://www.tindallgrams.net">Tindallgrams</a>"
cover this, and indeed, very significant AGC features were
developed in software and then simply discarded due to
memory constraints. For example, code was developed
for the LM for something called a Lunar Optical Rendezvous
System (LORS) that could potentially have been used in
place of the Rendezvous Radar (RR). However, the
code for LORS was larger (much larger) than the code for
the RR, thus causing it to be eliminated, so the only
place it exists today is as a vague reference in a
Tindallgram. I wish we could see the code for LORS,
but we cannot. Perhaps if Raytheon's auxiliary tape
memory for the AGC had eventually been adopted, we might
be able to do just that! But the tape memory was <i>not</i>
adopted, so we cannot. <br>
<br>
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 <a
href="links.html#Miscellaneous_Mission_Documents">our
document library</a>. The radar camp won for
Apollo, but lost for the shuttle. Such is life!<br>
<br>
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.<br>
<br>
And finally, as you may have realized, there is actually <i>no</i>
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!<br>
</span><br>
<button onclick="toggleMore('SUPERJOB')" id="buttonSUPERJOB">Read
more</button> </td>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;">
Apollo 9<br>
</td>
<td style="text-align: center; vertical-align: middle;"> LM-3<br>
</td>
<td style="text-align: center; vertical-align: middle;"> D<br>
</td>
<td style="font-weight: bold; vertical-align: middle;
white-space: nowrap;"> Sundance<br>
</td>
<td style="vertical-align: middle;">306<br>
</td>
<td style="text-align: center; vertical-align: middle;">
<div align="center"><a
href="listings/Sundance306ish/MAIN.agc.html">Syntax-highlighted,
hyperlinked HTML of Sundance306ish</a><br>
</div>
(reconstruction phase 2)<br>
</td>
<td style="text-align: left;" align="center"><a
href="links2.html#Apollo9">Document Library</a> </td>
<td style="text-align: left; vertical-align: middle;"> <a
name="Sundance306"></a>Executive summary: This is a
program we have and yet don't have. I say we <i>do</i>,
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
details!<br>
<span id="moreSUNDANCE306" style="display:none"> <br>
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:<br>
<br>
<div style="margin-left: 40px;"> <small>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.<br>
</small> </div>
<br>
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.<br>
<br>
Not being "in the building" ourselves, <i>we</i> have no
copies of the full Sundance 306 program, nor of any other
revision of Sundance source code. Annoying!
Nevertheless, we <i>do</i> 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 <a href="Restoration.html">Jimmy
Loocke's restored AGC</a>. 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.<br>
<br>
<a
href="https://github.com/virtualagc/virtualagc/tree/master/SundanceXXX">Mike's
dumps of the individual Sundance modules reside in our
GitHub repository</a>. Here's a complete list of
the modules for which we have dumps, and of the personal
collections whence they originally came:<br>
<ul>
<li>B1 (p/n 2003972-371, Sundance 292), Anonymous</li>
<li>B2 (p/n 2003972-451, Sundance 302), Don Eyles</li>
<li>B3 (p/n 2003972-391, Sundance 292), Anonymous</li>
<li>B3 (p/n 2003972-461, Sundance 302), Don Eyles</li>
<li>B4 (p/n 2003972-471, Sundance 302), Eldon Hall</li>
<li>B5 (p/n 2003972-421, Sundance 292), Anonymous</li>
<li>B6 (p/n 2003972-641, Sundance 306), Anonymous</li>
</ul>
<p>But how to fit them together to make something
usable? In case you're wondering, <i>perhaps</i>
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.<br>
</p>
<p>Quite the puzzle!<br>
</p>
<p>With some assistance from Nik Beug, Mike has been
trying to piece together this puzzle by <i>reconstructing</i>
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 <i>complete</i> Apollo 9
mission software.<br>
</p>
<p>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 3-phase process:<br>
</p>
<table width="90%" cellspacing="2" cellpadding="2"
border="1" align="center">
<tbody>
<tr>
<th valign="bottom">Phase<br>
</th>
<th valign="bottom">Status<br>
</th>
<th valign="bottom">Name of Program Produced<br>
</th>
<th valign="bottom">Description<br>
</th>
</tr>
<tr>
<td valign="middle" align="center">1<br>
</td>
<td valign="middle" align="center">Complete<br>
+<br>
Test flown<br>
</td>
<td valign="middle" align="center">SundanceXXX<br>
</td>
<td valign="top">This phase decompiles
(disassembles?) the multi-revision set of Sundance
module binary dumps we already have, creating
source code from them, and reconciles
discrepancies between the modules. This
forms a Sundance program, though not specifically
Sundance 306 (or any other particular revision),
and <i>in principle</i> not necessarily
functional. The "discrepancies" I just
mentioned are almost entirely due to shifts in the
addresses of variables or code between
revisions. The program so-created,
SundanceXXX, matches the binary dumps, aside from
the 800+ "discrepancies" (<a
href="https://github.com/virtualagc/virtualagc/blob/master/SundanceXXX/SundanceXXXDifferences.txt">enumerated
here</a>). It assembles without
error. Moreover, it turns out after doing so
that Sundance XXX is entirely functional, as far
as we can tell, and can acceptably fly simulated
Apollo 9 missions using the Orbiter/NASSP
spaceflight simulator, though it is now
essentially obsoleted by Sundance306ish (see next
entry below). You can view a <a
href="listings/SundanceXXX/MAIN.agc.html">browser-friendly
version of the decompiled source code</a> at
this link.</td>
</tr>
<tr>
<td valign="middle" align="center">2<br>
</td>
<td valign="middle" align="center">Complete<br>
+<br>
Test flown<br>
</td>
<td valign="middle" align="center">Sundance306ish<br>
</td>
<td valign="top">This phase transforms the
SundanceXXX source code, to bring it into a form
in which assembled memory banks in module B6 (the
only available physical module loaded with
Sundance 306, as opposed to earlier Sundance
revisions) precisely match the dump of physical
memory module B6. Some 200+ octal mismatches
in SundanceXXX are addressed in this phase.
I am told that it performs perfectly for simulated
Apollo 9 missions in Orbiter/NASSP, and has become
the accepted Apollo 9 default there.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">3<br>
</td>
<td valign="middle" align="center">Someday<br>
</td>
<td valign="middle" align="center">Sundance306<br>
</td>
<td valign="top">This phase transforms the
Sundance306ish source code to bring the core rope
obtained by assembling it into a form which
corresponds specifically to Sundance 306 <i>throughout</i>:
i.e., in memory modules B1-B2, and not merely
B6. Absent additional source material (such
as a complete list of Sundance 306 memory-bank
checksums), this reconstruction phase will
undoubtedly prove to be <i>very</i> difficult,
and we may never be in a position to make adequate
progress or to know that the effort has been
entirely successful ... but we can hope!</td>
</tr>
</tbody>
</table>
<ol>
</ol>
<p>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 incorrect.<br>
</p>
<p>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
become available. </p>
</span><br>
<button onclick="toggleMore('SUNDANCE306')"
id="buttonSUNDANCE306">Read more</button> </td>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;"
rowspan="2" colspan="1">Apollo 10<br>
</td>
<td style="text-align: center; vertical-align: middle;"
rowspan="2" colspan="1">LM-4<br>
</td>
<td style="text-align: center; vertical-align: middle;"
rowspan="2" colspan="1">F<br>
</td>
<td style="font-weight: bold; vertical-align: middle;
white-space: nowrap;" rowspan="2" colspan="1"> Luminary 1<br>
</td>
<td style="vertical-align: middle;">069<br>
</td>
<td style="text-align: center; vertical-align: middle;"><a
href="listings/Luminary069/MAIN.agc.html">Syntax-highlighted,
hyperlinked HTML</a><br>
<br>
<a href="https://archive.org/details/luminary6900miti">Scanned
page images</a></td>
<td style="text-align: left;" rowspan="2" colspan="1"
align="center"><a href="links2.html#Apollo10">Document
Library</a><br>
</td>
<td style="text-align: left; vertical-align: middle;"><a
name="Apollo10"></a>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.<br>
<br>
Nevertheless, it ended up not being flown in the
mission. (Instead, see Luminary 69/2 below.)<br>
<br>
The version we have here is from Don Eyles's private
collection, as scanned by archive.org, and financially
sponsored by our Onno Hommes.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">069/2</td>
<td valign="middle" align="center"><a
href="listings/LUM69R2/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
<td valign="middle"><a name="LUM69R2"></a>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.<br>
<span id="moreLUMINARY69REV2" style="display:none"> <br>
How is such a reconstruction even possible? Well,
Mike Stewart did the reconstruction, and <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n68/mode/1up">has
explained it in quite a bit of detail</a>.
However, I'll try to give you a relatively brief
overview. There are 4 key ingredients:<br>
<ul>
<li>We know the <i>checksums</i> of all of LUM69R2's
memory banks, because they are listed in the
recently-discovered engineering drawing
2021152B. From this and other documentation,
there is a high degree of confidence that the contents
of only 2 of the 36 memory banks have changed from
LUM69.</li>
<li>We have LUMINARY Memo #75, which <i>describes</i>
what those changes ought to be.</li>
<li>We have LUMINARY Memo #78, which describes a similar
change in Luminary 95 source code.</li>
<li>We have the Luminary 99 source code, which derives
from Luminary 95.<br>
</li>
</ul>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>So in conclusion, we're pretty sure we do have the
LUM69R2 software for Apollo 10, <i>without</i> ever
having been given the assembly listing for the software!
</p>
</span><br>
<button onclick="toggleMore('LUMINARY69REV2')"
id="buttonLUMINARY69REV2">Read more</button> </td>
</tr>
<tr>
<td rowspan="6" colspan="1" valign="middle" align="center">Apollo
11<br>
</td>
<td rowspan="6" colspan="1" valign="middle" align="center">LM-5<br>
</td>
<td rowspan="6" colspan="1" valign="middle" align="center">G<br>
</td>
<td rowspan="6" colspan="1" valign="middle" align="center"><b>Luminary
1A</b><br>
</td>
<td valign="middle" align="center">96<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary096/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
<td colspan="1" rowspan="6" valign="middle" align="center"><a
href="links2.html#Apollo11">Document Library</a></td>
<td colspan="1" rowspan="3" valign="middle"><a
name="Luminary097"></a>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.<br>
<span id="moreLUMINARY9678" style="display:none"> <br>
How can we be confident of that? Mike Stewart
performed the reconstruction and has provided a detailed
explanation (<a
href="https://github.com/virtualagc/virtualagc/pull/1078">Luminary
97 and 98 here</a> and <a
href="https://github.com/virtualagc/virtualagc/pull/1152">Luminary
96 here</a>). In brief, we have known-good source
code for Luminary 99 (see below). <a
href="Documents/LUM85_text.pdf">LUMINARY memo #85</a>
describes the differences between Luminary 99 and 98, so
we can use that information to reconstruct Luminary 98
from 99. Similarly, <a
href="Documents/LUM83_text.pdf">LUMINARY memo #83</a>
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 <a
href="Documents/LNY-59.jpg">software anomaly report
LNY-59</a> describes two minor differences between
Luminary 96 and 97. Meanwhile, <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n70/mode/1up">engineering
drawing 2021152</a> 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 <i>very</i> likely
to be correct. <br>
<br>
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.<br>
<br>
<a name="Kernan" id="Kernan"></a>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:<br>
<br>
<div style="margin-left: 40px;"> <small>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.<br>
<br>
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.<br>
<br>
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.</small><br>
</div>
<br>
Some years later, he retells the story as follows:<br>
<blockquote><small>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.</small><br>
</blockquote>
But wait, you say: These stories relate to Luminary 99,
not to 96! <br>
<br>
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.<br>
<br>
So how are we to reconcile Jim's very-detailed
recollections with the documented facts? As
mentioned above, <a href="Documents/LNY-59.jpg">software
anomaly report LNY-59</a> 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.<br>
<br>
And yet ... Jim's stories are so <i>detailed</i>. He's so
<i>certain</i> about them. And they persist over
time. How could they possibly be wrong in the way
I'm suggesting?<br>
<br>
As it happens, I've just finished reading a book about how
human memory works — if you're interested, it's <i>Remember:
The Science of Memory and the Art of Forgetting</i>, 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
href="https://en.wikipedia.org/wiki/Chinese_whispers">a
game of Telephone</a>, 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 <i>certain</i> you are of
your memory of it, but also you retell it more often, and
hence your recollection of the event mutates <i>more</i>
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!<br>
<br>
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.<br>
<br>
Actually, Jim's story <i>is</i> correct in one
interesting regard, namely that the <a
href="https://en.wikipedia.org/wiki/Ephemeris">ephemeris</a>
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, <a href="Documents/SGA_Memo20_650929.pdf">beginning
on July 1 of one year and continuing through June 30 of
the following year</a>, 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<br>
<ul>
<li><a
href="listings/Luminary099/CONTROLLED_CONSTANTS.agc.html">Apollo
11:
Luminary 99 Rev 1 CONTROLLED CONSTANTS</a></li>
<li><a
href="listings/Luminary116/CONTROLLED_CONSTANTS.agc.html">Apollo
12:
Luminary 116 CONTROLLED CONSTANTS</a></li>
<li><a
href="listings/Luminary131/CONTROLLED_CONSTANTS.agc.html">Apollo
13:
Luminary 131 CONTROLLED CONSTANTS</a></li>
</ul>
<p>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 <a
href="listings/Luminary069/CONTROLLED_CONSTANTS.agc.html">Apollo
10
(Luminary 69)</a>, 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.<br>
</p>
<p>(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 <a
href="https://github.com/virtualagc/virtualagc/tree/master/LUM99R2">source
code</a> 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.)<br>
</p>
</span><br>
<button onclick="toggleMore('LUMINARY9678')"
id="buttonLUMINARY9678">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">97<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary097/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
</tr>
<tr>
<td valign="middle" align="center">98<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary098/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
</tr>
<tr>
<td valign="middle" align="center">099/0<br>
</td>
<td valign="middle" align="center"><a
href="listings/LMY99R0/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a> </td>
<td valign="middle">One of the original AGC programmers, Allan
Klumpp, kept a copy of Luminary 99 Rev 0 (or 99/0 for
short), since donated to <a href="http://www.klabs.org">klabs.org</a>,
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.<br>
<span id="moreLUMINARY99" style="display:none"> <br>
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 <a
href="R700-3-Table4-11.jpg">the chart at the top of this
page</a> we know that it's the revision immediately <i>preceding</i>
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.<br>
<br>
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 <i>reconstruct</i> 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. <br>
<br>
The source code reconstructed by Mike is what you see
linked at the left. <br>
<br>
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 <i>changed</i> 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 <i>did</i> 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 <i>likely</i> 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.<br>
<br>
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.<br>
</span><br>
<button onclick="toggleMore('LUMINARY99')"
id="buttonLUMINARY99">Read more</button> </td>
</tr>
<tr align="center">
<td style="vertical-align: middle;">099/1<br>
</td>
<td style="text-align: center; vertical-align: middle;"> <a
href="listings/Luminary099/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="ScansForConversion/Luminary099">Scanned page images
(copy 1)</a>, plus replacement pages <a
href="AP11ROPEpage1472.jpg">1472</a> and <a
href="AP11ROPEpage1473.jpg">1473</a><br>
<br>
<a href="https://archive.org/details/ap11rope00miti">Scanned
page images (copy 2)</a><br>
</td>
<td style="text-align: left; vertical-align: middle;"> <a
name="Luminary99Blurb"></a>This is the AGC software
version that was flown in the Apollo 11 Lunar Module.<br>
<br>
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.<br>
<span id="moreLUMINARY99REV1" style="display:none"> <br>
<table summary="" style="text-align: left; margin-left:
auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">
<div style="text-align: center;"> <span
style="font-weight: bold;"><span
style="text-decoration: underline;">Honor
Roll</span><br>
</span>
<div style="text-align: left;"> <span
style="font-style: italic;"><br>
<span style="text-decoration: underline;">Organizational
honors</span></span><br>
</div>
</div>
<table summary="" style="text-align: left; width:
100%;" cellspacing="2" cellpadding="2"
border="0">
<tbody>
<tr>
<td style="vertical-align: middle;"> <big><span
style="font-family: sans-serif;">Massachusetts
Institute
of Technology / MIT Museum</span><br
style="font-family: sans-serif;">
<span style="font-family: sans-serif;">Building
N51,
265 Massachusetts Avenue</span><br
style="font-family: sans-serif;">
<span style="font-family: sans-serif;">Cambridge,
MA
02139<br>
<a href="http://web.mit.edu/museum/"><small>web.mit.edu/museum/</small></a><br>
</span></big></td>
<td style="text-align: center;
vertical-align: middle;"> <a
href="http://web.mit.edu/museum/"><img
alt="" title="Click to visit the MIT
Museum website"
src="MITMuseumLogo_red.gif"
style="border: 0px solid ; width:
107px; height: 101px;" width="107"
height="101"></a><br>
</td>
</tr>
</tbody>
</table>
<br>
<span style="font-style: italic; text-decoration:
underline;"> Individual honors</span><br>
<ul>
<li>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.</li>
<li>Paul Fjeld, for digitizing the hardcopy.</li>
<li>(In alphabetical order) Fabrizio Bernardini,
Hartmuth Gutshe, Onno Hommes, Jim Lawton, and
Sergio Navarro, for converting the page images
to source code.</li>
<li>Steve Case and Dawn Masuoka for helping in
proofing the executable binary.<br>
</li>
<li>... and those whose names I do not know at
the Charles Stark Draper Laboratory and NASA
who allowed us to do this.<br>
</li>
</ul>
</td>
</tr>
</tbody>
</table>
<br>
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.)<br>
<br>
<center><iframe
src="https://www.youtube.com/embed/sHaS6sYJsMg"
allowfullscreen="" width="480" height="270"
frameborder="0">&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;br&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
</iframe></center>
<br>
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 <a href="R700-3-Table4-11.jpg">the
chart at the very top of this web-page</a> tells you
that it is indeed the version that was flown in the
mission ... but keep reading, because there are curious
postscripts!<br>
<br>
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:<br>
<ul>
<li>The octal rope for AP11ROPE — i.e., the executable
form into which the source code compiles — is <i>identical</i>
to that of Luminary 99/1. Thus,
differences in the source code are confined to things
like program comments which don't affect the
executable code.</li>
<li>There is precisely one difference between the
program comments in AP11ROPE and our earlier scan from
the MIT library, and that is on page 2 of the listing,
in which a group of software modules is mentioned as
"LEMONAID" in the one case, and "LNYAIDE" in the
other.<br>
</li>
<li>Regarding the software modules just mentioned, even
though Don hadn't changed the program comment naming
them, he actually referred to this section (pp.
153-489) as "AP11AID", indicating that he presumably
intended to make changes in this area to further his
purpose in branching AP11ROPE from LUMINARY, but just
hadn't done so yet. We know this because of the
fact that assembler-generated lines in the printout
refer to this section not as LEMONAID but as AP11AID.<br>
</li>
<li>Finally, "LEMONAID" was the name for this section in
LUMINARY 69, so that fact that the program comments in
AP11ROPE continue to refer to it as LEMONAID rather
than as LNYAIDE implies that AP11ROPE was not branched
directly from LUMINARY 099/1, in spite of being
essentially identical to it. <br>
</li>
</ul>
It's worth mentioning that we have a pair of "digital
simulations" of the landing. These were simulations
performed during the Apollo era, and <i>not</i>
simulations we have performed as part of the Virtual AGC
project. They are very complete, containing not only
pad loads, but also position/velocity data, notations of
what the astronaut is supposed to input on the DSKY, what
the DSKY is displaying on a moment-to-moment basis,
occasional memory dumps, and so on. There are two
such surviving simulations for Apollo 11, both from Don
Eyles's personal collection. We have had them
scanned, with Matthew Fite financially sponsoring <a
href="https://www.ibiblio.org/apollo//Documents/apollo11landingd00miti_0.pdf">the
1969 version</a> and Fabrizio Bernardini financially
sponsoring <a
href="https://archive.org/details/dianarev12level302eyle/mode/1up">the
1971 version</a>. (Thanks Matthew and
Fabrizio!) The two simulations are somewhat
different; i.e., these are <i>not</i> merely two
different scans of the same thing. Unfortunately,
the printout for the 1971 simulation is quite
low-contrast, and its full-color scans quite hard to read.<br>
<br>
The 1969 digital simulation was done a few days <i>after</i>
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 <a href="Documents/LUM140_text.pdf">LUMINARY
Memo #140</a>, for example, for some background
information about TLOSS.)<br>
<br>
Also, you may wonder, why was there a digital simulation
of Apollo 11 in 1971, a couple of years <i>after</i>
Apollo 11 landed on the moon? Shouldn't the
simulations only have been useful <i>before</i> 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.<br>
<br>
Speaking of ZERLINA, if you examine the scans, you may
notice that the label on the binder identifies the 1971
simulation as "DIANA Rev. 12". It is <i>not</i>
DIANA, however: the binder containing the simulation's
printout had <i>formerly</i> 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.)<br>
</span><br>
<button onclick="toggleMore('LUMINARY99REV1')"
id="buttonLUMINARY99REV1">Read more</button> </td>
</tr>
<tr>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;">
Apollo 12<br>
</td>
<td style="text-align: center; vertical-align: middle;"> LM-6<br>
</td>
<td style="text-align: center; vertical-align: middle;"> H-1<br>
</td>
<td style="font-weight: bold; vertical-align: middle;
white-space: nowrap;"> Luminary 1B<br>
</td>
<td style="vertical-align: middle;">116<br>
</td>
<td style="text-align: center; vertical-align: middle;"><a
href="listings/Luminary116/MAIN.agc.html">Syntax-highlighted,
hyperlinked HTML</a><br>
<br>
<a href="https://archive.org/details/luminary11600nasa">Scanned
page images</a><br>
</td>
<td style="text-align: left;" align="center"> <a
href="links2.html#Apollo12">Document Library</a><br>
</td>
<td style="text-align: left; vertical-align: middle;">This is
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
reconstruct them.<br>
<span id="moreLUMINARY116" style="display:none"> <br>
Let me point out a few other documents that help to
provide insight into Luminary 116' innards.<br>
<br>
The <a href="Documents/j2-80-MSC-69-FS-4_text.pdf">Programmed
Guidance Equations</a> 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.<br>
<br>
The <a href="Documents/apollo12landingd00miti.pdf">digital
simulation of the landing</a>, from Don Eyles's personal
collection (with scanning financially sponsored by Matthew
Fite), had been made a few months <i>after</i> the Apollo
12 landing itself. But why? Surely, the
simulation is useful only <i>before</i> 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.<br>
<br>
And then there's <a href="Documents/HSI-208616.pdf">document
E-2260</a>, whose 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."<br>
</span><br>
<button onclick="toggleMore('LUMINARY116')"
id="buttonLUMINARY116">Read more</button> </td>
</tr>
<tr>
<td rowspan="4" colspan="1" valign="middle" align="center"><font
color="#000000">Apollo 13</font><br>
</td>
<td rowspan="4" colspan="1" valign="middle" align="center">LM-7<br>
</td>
<td rowspan="4" colspan="1" valign="middle" align="center">H-2<br>
</td>
<td rowspan="4" colspan="1" valign="middle" align="center"><b>Luminary
1C</b><br>
</td>
<td valign="middle" align="center">130<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary130/MAIN.agc.html">Syntax-hilighted,
hyperlinked, HTML</a></td>
<td rowspan="4" colspan="1" valign="middle">
<div align="center"><a href="links2.html#Apollo13">Document
Library</a><br>
</div>
<ul>
</ul>
</td>
<td valign="middle"><a name="LUM130"></a>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.<br>
<br>
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!).<br>
<br>
The reason this is possible is that we have a scan of a
Luminary 131 assembly listing, plus <a
href="Documents/LUM129-001.pdf">LUMINARY Memo #129</a>
describing the differences (all minor) between 130 and 131,
thus making it possible undo those changes. Finally,
the recently-uncovered <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n80/mode/1up">engineering
drawing 2021152</a> 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.<br>
</td>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;">131<br>
</td>
<td style="text-align: center; vertical-align: middle;"> <a
href="listings/Luminary131/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="https://archive.org/details/luminary131agcpr00miti">Scanned
page
images</a><br>
</td>
<td style="text-align: left; vertical-align: middle;"> <a
name="Luminary131"></a>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 <a
href="R700-3-Table4-11.jpg">document R-700 shown at the
top of this very web-page</a> that what <i>we</i> 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. <br>
<span id="moreLUMINARY131" style="display:none"> <br>
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
href="ScansForConversion/Luminary131/coverLetter.png">a
great cover letter</a> 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! Indeed, Gary Neff also later kindly provided
me with a replacement for a page which is garbled in the
HRST version. <br>
<br>
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. You can still find the original
scan in our Document Library, but I'm providing only the
link to the better version here.<br>
<br>
Finally ... we can tell that these two different scans
actually came from the same <i>physical</i> 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 <i>after</i> 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?<br>
<br>
If you're interested in insights into the internal
structure of Luminary 1C, you might also want to look at <a
href="Documents/19740073277.pdf">the Programmed Guidance
Equations document</a>. 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.<br>
</span><br>
<button onclick="toggleMore('LUMINARY131')"
id="buttonLUMINARY131">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">131/9<br>
</td>
<td valign="middle" align="center">On our wish list<br>
</td>
<td valign="top">This is the third Luminary release whose
ropes were manufactured for Apollo 13, but it was not the
revision eventually flown in the mission. <br>
<br>
In calling it revision 131/9, I am really using 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".<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">131/1<br>
</td>
<td valign="middle" align="center">On our wish list<br>
</td>
<td valign="top">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.</td>
</tr>
<tr>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle"><b>Zerlina</b><br>
</td>
<td valign="middle" align="center">56<br>
</td>
<td valign="middle" align="center"><a
href="listings/Zerlina56/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="https://archive.org/details/zerlina00done">Scanned
page images</a></td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="top"><a name="Zerlina"></a>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.<br>
<span id="moreZERLINA56" style="display:none"> <br>
Our scan of ZERLINA, by the way, was financially sponsored
by Linden Sims. Thanks, Linden!<br>
<br>
Zerlina itself was apparently branched from Luminary 145,
and was developed independently for a period of 6-7
months. Quite a few <a
href="links.html#LUMINARY_Memos">LUMINARY Memos</a>
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.<br>
<br>
Zerlina was not the <i>only</i> 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.<br>
<br>
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!).<br>
<br>
In fact, Nik has actually flown a lunar landing using
Zerlina in the NASSP/Orbiter spacecraft simulator, and has
shared a video of it:<br>
<br>
<center><iframe
src="https://www.youtube.com/embed/PP-LzofxsKA"
allowfullscreen="" width="480" height="270"
frameborder="0"></iframe></center>
<br>
</span><br>
<button onclick="toggleMore('ZERLINA56')"
id="buttonZERLINA56">Read more</button> </td>
</tr>
<tr>
<td rowspan="3" colspan="1" valign="middle"><span
style="color: rgb(0, 0, 0);">Apollo 14</span><br>
</td>
<td rowspan="3" colspan="1" valign="middle" align="center">
LM-8<br>
</td>
<td rowspan="3" colspan="1" valign="middle" align="center">
H-3<br>
</td>
<td rowspan="3" colspan="1" valign="middle"><b> </b><b><span
style="color: rgb(0, 0, 0);">Luminary 1D</span></b><br>
</td>
<td valign="middle" align="center">163<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary163/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
<td rowspan="3" colspan="1" valign="middle" align="center"> <a
href="links2.html#Apollo14">Document Library</a></td>
<td rowspan="2" colspan="1" valign="top"><a name="Luminary163"></a>Luminary
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
below.)<br>
<br>
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 <a
href="https://github.com/virtualagc/virtualagc/pull/1098">#1098</a>
and <a
href="https://github.com/virtualagc/virtualagc/pull/1099">#1099</a>
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 <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n80/mode/1up">2021152N</a>.
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.<br>
</td>
</tr>
<tr>
<td valign="middle" align="center">173<br>
</td>
<td valign="middle" align="center"><a
href="listings/Luminary173/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a></td>
</tr>
<tr align="center">
<td style="color: rgb(255, 0, 0); vertical-align: middle;"
valign="middle" align="center"> <span style="color: rgb(0,
0, 0);">178</span><br>
</td>
<td style="text-align: center; vertical-align: middle;"> <a
href="listings/Luminary178/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a> </td>
<td style="text-align: left; vertical-align: middle;"> <a
name="Apollo14"></a>This is the actual flight program for
the Apollo 14 Lunar Module.<br>
<span id="moreLUMINARY178" style="display:none"> <br>
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.<br>
<br>
Mike describes the reconstruction process in detail in his
notes for issues <a
href="https://github.com/virtualagc/virtualagc/pull/1093">#1093</a>
and <a
href="https://github.com/virtualagc/virtualagc/pull/1095">#1095</a>
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 <i>slightly</i> less mind-boggling way.<br>
<br>
At the time the reconstruction was done (Summer 2019), the
closest revisions to Luminary 178 that were available to
us were those of <a href="#Luminary131">Luminary 131</a>
(Apollo 13) and <a href="#Luminary210">Luminary 210</a>
(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?<br>
<br>
Fortunately, Mike noticed additionally that we had a copy
of <a href="#Zerlina">Zerlina 56</a>, which is not
technically Luminary, but which was branched from Luminary
145, and had had <i>most</i> of the changes up through
Luminary 183 added to it afterward. So Zerlina 56 <i>ought</i>
to be much closer to Luminary 178 than either Luminary 131
or 210 is. Additionally, our document library has a
vast store of "<a href="links.html#LUMINARY_Memos">Luminary
Memos</a>", 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.<br>
<br>
And perhaps most-importantly, since nobody (even Mike!)
would have been likely to attempt a reconstruction without
it, we have MIT/IL engineering drawing <a
href="https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n80/mode/1up">2021152N</a>.
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 <i>agree</i> with the memory-bank checksums you
get when you assemble the reconstructed Luminary 178
source code, we are confident the reconstruction is
correct!<br>
<br>
As the final icing on the cake, Niklas Beug, a developer
and user of <a href="https://github.com/dseagrav/NASSP">NASSP,
the Apollo-mission add-on for the Orbiter spaceflight
simulator</a>, 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 <i>didn't</i> 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:<br>
<br>
<div align="center"><a href="simAtFraMauro.jpg"><img
alt="" title="Click to enlarge"
src="simAtFraMauro-small.jpg" width="420"
height="263" border="2"></a><br>
</div>
<small><br>
</small></span><br>
<button onclick="toggleMore('LUMINARY178')"
id="buttonLUMINARY178">Read more</button> </td>
</tr>
<tr>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center">N/A<br>
</td>
<td valign="middle" align="center"><b>Luminary 1E</b><br>
</td>
<td valign="middle" align="center">209<br>
</td>
<td valign="middle" align="center">On our wish list<br>
</td>
<td valign="middle" align="center"><a
href="links2.html#Apollo15">Document Library</a> </td>
<td valign="middle">AGC developer Allan Klumpp retained a copy
of Luminary 209, based on 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!<br>
<br>
As it turns out, the printout was donated to <a
href="http://www.klabs.org">klabs.org</a> 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. <br>
</td>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;">
Apollo 15<br>
</td>
<td style="text-align: center; vertical-align: middle;"> LM-10<br>
</td>
<td style="text-align: center; vertical-align: middle;"> J-1<br>
</td>
<td rowspan="3" style="font-weight: bold; vertical-align:
middle; white-space: nowrap;"> Luminary 1E</td>
<td rowspan="3" style="vertical-align: middle;">210<br>
</td>
<td rowspan="3" style="text-align: center; vertical-align:
middle;"><br>
<br>
<a href="listings/Luminary210/MAIN.agc.html">Syntax-highlighted,
hyperlinked, HTML</a><br>
<br>
<a href="https://archive.org/details/luminary21000miti">Scanned
page images</a><br>
<br>
<br>
</td>
<td rowspan="1" style="text-align: left;" align="center"><a
href="links2.html#Apollo15">Document Library</a></td>
<td rowspan="3" style="text-align: left; vertical-align:
middle;"><a name="Luminary210"></a>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,
Jim!<br>
<span id="moreLUMINARY210" style="display:none"> <br>
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.)<br>
<br>
<center><iframe
src="https://www.youtube.com/embed/E301HplyA7A"
allowfullscreen="" width="480" height="270"
frameborder="0"></iframe></center>
<br>
We also have <a
href="https://archive.org/details/apollo17landingd00miti/mode/2up">a
"digital simulation" of the Apollo 17 landing</a>. 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.<br>
</span><br>
<button onclick="toggleMore('LUMINARY210')"
id="buttonLUMINARY210">Read more</button> </td>
</tr>
<tr align="center">
<td style="vertical-align: middle; white-space: nowrap;">
Apollo 16<br>
</td>
<td style="text-align: center; vertical-align: middle;"> LM-11<br>
</td>
<td style="text-align: center; vertical-align: middle;"> J-2<br>
</td>
<td style="text-align: left;" align="center"><a
href="links2.html#Apollo16">Document Library</a></td>
</tr>
<tr>
<td style="text-align: center; vertical-align: middle;
white-space: nowrap;"> Apollo 17<br>
</td>
<td style="text-align: center; vertical-align: middle;"> LM-12<br>
</td>
<td style="text-align: center; vertical-align: middle;"> J-3<br>
</td>
<td align="center"><a href="links2.html#Apollo17">Document
Library</a></td>
</tr>
</tbody>
</table>
<div style="text-align: left;"> <br>
<h2><a name="Source_Code_and_Binary" id="Source_Code_and_Binary"></a>Source
Code
and Binary</h2>
You can obtain both the source code and (independently derived)
binary code for each of the software versions mentioned by
installing Virtual AGC on your computer. The files are
contained within a subdirectory named after the software version
(such as "Luminary131"). The more important files supplied
are these:<br>
<br>
<div style="margin-left: 40px;">
<table summary="" style="width: 75%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="0">
<tbody>
<tr>
<td style="vertical-align: top;"><span style="font-style:
italic;">Filename</span>.agc<br>
</td>
<td style="vertical-align: top; text-align: left;"> Source
code for major subdivisions of the <span
style="font-weight: bold;">Luminary</span> program.</td>
</tr>
<tr>
<td style="vertical-align: top;">MAIN.agc<br>
</td>
<td style="vertical-align: top;">Organizer which treats
all of the other assembly-language files (*.agc) as
include-files, to form the complete program.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;"><span style="font-style:
italic;">Filename</span>.binsource<br>
</td>
<td style="vertical-align: top;">Human-readable form of
the Luminary binary executable, as an octal listing.<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;"><span style="font-style:
italic;">Filename</span>.bin<br>
</td>
<td style="vertical-align: top;">Binary executable created
from binsource (octal listing) file.<br>
</td>
</tr>
</tbody>
</table>
<br>
</div>
In other words, to create a <span style="font-weight: bold;">Luminary</span>
binary executable rather than using the one provided with yaAGC
(such as Luminary131.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:<br>
<div style="margin-left: 40px;"> <br>
<span style="font-family: monospace;">cd Luminary131</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">../yaYUL/yaYUL --force
MAIN.agc >Luminary131.lst</span><br>
</div>
<br>
The listfile (Luminary131.lst) so produced is a bit more
manageable than scans of the original printouts, in that it is a
hundredth the size and you can perform text-searches on it.
The binary so produced, MAIN.agc.bin, should be byte-for-byte
identical to the binary (Luminary131.bin) provided with the yaAGC
distribution. Therefore, the following Linux command should
reveal no differences between the two:<br>
<br>
<div style="margin-left: 40px;"> <span style="font-family:
monospace;">diff -s MAIN.agc.bin Luminary131.bin</span><br>
</div>
<br>
(Replace "diff -s" with "fc /b" in Windows.) <br>
<br>
<table summary="" style="width: 60%; text-align: left;
margin-left: auto; margin-right: auto;" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">
<h3 style="text-align: left;">Technically speaking....</h3>
A point which may not be completely appreciated is that
Luminary131.bin was <span style="font-style: italic;">not</span>
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 <span style="font-weight: bold;">Luminary</span>
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 <span style="font-weight: bold;">Oct2Bin</span>,
with the following steps:<br>
<br>
<div style="margin-left: 40px; font-family: monospace;">
cd Luminary131<br>
./Oct2Bin <Luminary131.binsource<br>
mv Oct2Bin.bin Luminary131.bin<br>
</div>
<br>
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. </td>
</tr>
</tbody>
</table>
<br>
<h2><a name="Validity" id="Validity"></a>Validation</h2>
<h3><a name="Validity_of_the_Luminary_131_Source_Code"
id="Validity_of_the_Luminary_131_Source_Code"></a>Validity of
the Luminary 131 Source Code and of the Binary (Apollo 13)<br>
</h3>
I believe that the core-rope image (which is what is needed to
actually run the <span style="font-weight: bold;">Luminary</span>
software in the yaAGC CPU emulator) I've provided for <span
style="font-weight: bold;">Luminary</span> 1C (build 131) is
100% accurate. If you're not willing to take my word for
that, and if the discussion in the preceding section doesn't
convince you, an extended discussion of proofing and validation of
the core-rope appears in the description of the <a
href="Colossus.html#Validity">Colossus</a> software.<br>
<h3><a name="Validity_of_the_Luminary_099_Code_"
id="Validity_of_the_Luminary_099_Code_"></a>Validity of the
Luminary 099 Code (Apollo 11)<br>
</h3>
The Luminary 099 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 Luminary 131, as follows:<br>
<ul>
<li>A small corps of volunteers—thanks (in alphabetical order)
Fabrizio Bernardini, Hartmuth Gutsche, Onno Hommes, Jim
Lawton, and Sergio Navarro!—took the existing Luminary 131
source-code files and laboriously compared them line-by-line
to the Luminary 099 assembly-listing page images, porting the
differences they found.</li>
<li>The resulting Luminary 099 source code was assembled using <span
style="font-weight: bold;">yaYUL</span> to produce a binary
executable, which was horribly wrong at this point, but was
used to create a "binsource" file (which is an octal listing
of the entire program).</li>
<li>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.</li>
<li>Finally, at every point where the binary created from the
source code by <span style="font-weight: bold;">yaYUL</span>
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 <span style="font-weight:
bold;">yaYUL</span> was identical to the binary created from
the binsource file.</li>
</ul>
<p>The binary thus produced by <span style="font-weight: bold;">yaYUL</span>
is supplied in the source tree and used for regression testing.<br>
</p>
<h3>Validity of the Other Versions</h3>
Well, it's much the same as what's above, so I'm not going to keep
describing the same steps over and over again. Suffice it to
say that we verified them all using the same standards.<br>
<br>
</div>
<hr style="width: 100%; height: 2px;">
<center> <br>
<span style="color: rgb(84, 89, 93); font-family: sans-serif;
font-size: 11.05px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
16.575px; orphans: auto; text-align: center; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(255, 255,
255);"> This page is available under the <a
href="https://creativecommons.org/publicdomain/zero/1.0/">Creative
Commons
No Rights Reserved License</a></span><br>
<i><font size="-1">Last modified by <a
href="mailto:info@sandroid.org">Ronald Burkey</a> on
2021-09-23.<br>
<br>
<a href="http://www.ibiblio.org"><img style="border: 0px solid
; width: 300px; height: 100px;" alt="Virtual AGC is hosted
by ibiblio.org" src="hosted.png" width="300" height="100"></a><br>
</font></i> </center>
<br>
</body>
</html>
Computing file changes ...
