Please enable javascript in your
browser to see a site-search form here.

This Project

The purpose of this project is to provide a computer simulation of the
onboard guidance computers used in the Apollo Program's lunar missions,
and to generally allow you to learn about these guidance
computers. Since this can be quite intimidating, we invite you to
look at our "kinder and gentler"
introductory page before
immersing yourself in the full, gory detail presented by the bulk of
the website.

The video clip above (courtesy of user Dean Koska and YouTube)
illustrates some of the cute things you can do with Virtual AGC if
you're of a mind to do so. Dean compiled our simulated
AGC CPU to run on a Palm Centro—explaining that a regular Palm was
too slow. He created his own simulated display/keypad (DSKY), presumably aided by the developer info we provide for just such a
desire. (And sorry, Dean's Palm port isn't provided from our downloads page. Dean has indicated that
he may be able to provide it in the future, so if you want it you'll
just have to be patient.)

What are the "AGC",
"AGS", "LVDC", and "OBC"?

"AGC" stands for Apollo Guidance Computer. The AGC was the
principal onboard computer for NASA's Apollo missions, including all of
the lunar landings. Both the Command Module (CM) and the Lunar
Module (LM) had AGCs, so two AGCs were used on most of the Apollo
missions, but with differing software. The computer and its
software were developed at MIT's Instrumentation Laboratory, also known
as Draper Labs.

The "block II" AGC, employing the AGC4 instruction set, is the
particular computer model in which we're interested. The block II AGC
was used
not only on Apollo 7 through Apollo 17 (including all actual lunar
landings), but also on three Skylab missions, on the Apollo-Soyuz test
mission, and on a fly-by-wire
research project using F-8 aircraft.
Nevertheless, only 57 AGCs were constructed—and 138 display-keyboard
units (DSKYs) for them—and all of the ones installed in the Lunar
Modules were not returned to the Earth—so they are definitely
collector's items.

There was also the "block I" model of the AGC, which predated the block
II model. The block I model was supposed to fly in Apollo 1 and
2. But since Apollo 1 was tragically destroyed by fire, and
Apollo 2 never flew, the block I model was never used in any manned
mission. It was, nevertheless, used in the unmanned Apollo 4-6
missions.

"AGS" stands for Abort Guidance System,
of which the computer portion was known as the
Abort Electronics Assembly (AEA). The AGS/AEA was a
completely separate computer system from the AGC, with a different
architecture, different instruction-set, different runtime
software, and designed/manufactured by different groups than the
AGC. It was in the LM as a kind of backup for the AGC, but
was only supposed to be used (as the name implies) in case of an
aborted landing. It's sole purpose was to get the LM from
wherever it was back into lunar orbit, so that the CM could rendezvous
with the LM.

The "LVDC" (Launch Vehicle Digital Computer)
had yet a different architecture, instruction set, software, and
manufacturer. It was a computer mounted in the Saturn rocket
itself, and its responsibility was to control the firing of the rocket
engines to give the rocket the proper trajectory. It was
discarded when the CSM discarded the rocket, and consequently was used
during only a very short time interval relative to the total length of
the mission.

The Gemini spacecraft also had an on-board computer (OBC), having a
similar functionality to the Apollo AGC, though with greatly reduced
capabilities and sophistication, but with a computer architecture very
similar to the Apollo LVDC.

Because we have much more information about the AGC than we do about
the AGS, LVDC, and OBC, the bulk of this website and of the
Virtual AGC
project in general concentrates on the AGC. Coverage of the other
computers is mostly confined to the AGS page,
LVDC page, and the Gemini page of this website.

What "Virtual AGC" Is

Virtual AGC is a computer model of the AGC. It does not
try to mimic the superficial
behavioral characteristics of the AGC, but
rather to model the AGC's inner workings. The result is a
computer model of the
AGC which is itself capable of executing the original Apollo software
on (for example) a desktop PC. In computer terms, Virtual AGC is
an emulator.
Virtual AGC also provides an emulated AGS and (in the planning stages)
an emulated LVDC. "Virtual AGC" is a catch-all term that
comprises all of these.

The current version of the Virtual AGC software has been designed to
work in Linux, in
Windows XP/Vista/7, and in Mac OS X 10.3 or later (but 10.5 or later is
best). It also works in at
least some versions of FreeBSD. However,
since I personally work in Linux, I have the most
confidence in the Linux version.

What Virtual AGC Is Not

Virtual AGC is not a flight simulator, nor a lunar-lander simulator,
nor even a behavioral simulation of the Apollo Lunar Module (LM) or
Command-Module (CM) control panels. (In other words, if you
expect a realistic LM control panel to suddenly appear on your computer
screen, you'll be disappointed.) Virtual AGC could be used,
however, as
a
component of such a
simulation, and developers of such software are
encouraged to do so. Indeed, some developers already have!
But see the FAQ for
more info on this.

Existing
Elements of the Virtual AGC Project

AGC Elements

yaAGC is an emulation of the AGC CPU. To function,
it
requires a LM or CM "core rope" binary (see below).

yaDSKY is a simulation of the Display/Keyboard
used in Apollo. It supplies input to yaAGC, or receives
output from it. The design of the emulator is modular, so the
DSKY simulation may be
easily replaced if you don't care for mine, or if you want to replace
it with a complete control-panel simulation.

yaTelemetry is a dumb
terminal on which telemetry downlinks from yaAGC may be viewed, similar to the
way such telemetry from the AGC was originally viewed by Mission
Control.

yaACA is a program that
emulates the LM's hand-controller (possibly with a joystick), and to
communicate the desired pitch/roll/yaw changes to yaAGC.

yaYUL is an assembler, capable of converting AGC4 assembly
language into the binary executable format needed by the AGC.

Luminary is the name of the program used for the Apollo
Lunar Modules in the actual missions. Both binary executable
(needed by yaAGC) and source
code (needed by yaYUL) are
provided.

Colossus is the name of the program used for many (but
not all) of the Apollo Command Modules. As with Luminary, both binary and source are
provided.

Validation is the name of
a newly-created AGC assembly-language program that provides a
validation suite for helping to assure that the implementation of the
virtual CPU is correct. It was written by closely following the
original Apollo documentation describing the validation software used
at that time.

Apollo-program documentation relevant to programming the AGC has
been corrected, rewritten, and expanded in some ways—just in case you
want to write your own AGC programs. Also, scans of some of the
relevant original Apollo-program documents not available elsewhere on
the web have been provided.

Supplemental materials for John Pultorak's physical Block I AGC
model.

AGS Elements

yaAGS is an emulation of
the AGS CPU. To function, it requires a binary of one of the
flight programs (see below).

yaDEDA is a simulation
of the AGS user interface.

yaLEMAP is an assembler
for AGS assembly language.

The source code for the AGS flight program.

AGS scanned documentation, including specification, programmer's
manuals, and so on.

(Speculation only) Newly written LVDC and Gemini source code for
implementing the documented guidance equations. Note that there
is no known existing copy of true LVDC or Gemini OBC source code, or
else we wouldn't
need to write new code for it!

Scans of all known existing LVDC and Gemini OBC documentation.

Contributed Code

LM_Simulator
is a contributed program by Stephan Hotto. This program has
quickly ceased to be an optional add-on, and to become an essential
element of the project. It adds all kinds of nifty things:

And to Tie It All together ...

VirtualAGC is a GUI
front-end that ties all of the stuff listed above together into an
"easily" used bundle. (It should be obvious why "easily" is in
quotes here.)

Licensing

PC-based programs such as yaYUL, yaAGC, and yaDSKY are copyrighted by the
author, Ron Burkey, but are provided to you as "free software" under
the GNU General Public License
(GPL). Validation was
written by me, Ron Burkey, but is being placed in the public
domain.
Luminary
and Colossus are in the public domain, to the best of my
non-lawyer understanding. Newly-written or revised documentation
is being
placed in the public domain. Note that if you wanted to use yaAGC
or
yaDSKY
as components of a more-complete Apollo simulation, the modularity of
the design allows them to be run as stand-alone programs (whilst
communicating with your own software), and doing so does not force any
particular licensing requirements upon your own code. However, if
you choose instead to incorporate
the
code directly into your program or to link to it, your program will
itself need to be licensed under the GPL unless you feel like
negotiating an alternate license with me. (As of 2005-02-27, the yaAGC
source code license also has a "special exception" as allowed/required
by the GPL, allowing linking to the non-free Orbiter
spacecraft-simulator SDK libraries.) Refer to the Developer info page for more detail.

What If You Want To Help?

Running the Emulator ... or, A
Brief Introduction to the GUI

The first step, of course, is to download the Virtual AGC software and
install it or build it for the computer platform you're using, by
following the
instructions on the download page.
While the Virtual AGC project provides many different programs that
implement bits and pieces of the full emulation, the only program you
normally need to worry about running is the one that's actually calledVirtualAGC. VirtualAGC is a GUI front-end which
allows you to choose almost any reasonable set of options related to
the emulation, and then to run all of the emulation programs needed, in
a way that allows those programs to intercommunicate properly.

Hopefully, VirtualAGC is
itself simple enough
that it really requires very little explanation to use, and your
troubles will really begin only after the emulation is actually
running! But I'll provide a very brief overview here.
There's also a more detailed
explanation of VirtualAGC
available for your enjoyment.

The screenshot above depicts the one and only window of the VirtualAGC program. There are
no menus, toolbars, hot-buttons, or other controls.
While a large number of options are presented, you don't necessarily
need to change any of the selected options. The defaults are as
shown, and if you simply click the "Run!" button at the bottom of the
window, the simulation will run. If you change any of the
settings, the program will remember those changes and the settings
you've selected will be the ones that appear the next time you run VirtualAGC. Or,
you could click the "Defaults" button at the bottom of the window to
restore all of the settings to their defaults. There's really
very little for a complete newcomer to change any of the settings, but
you will note that you can choose from among the several available sets
of AGC software for different Apollo missions in the pane labeled
"Simulation Type."

When the simulation runs, VirtualAGC's
rather large window will courteously disappear to conserve space on
your screen, to be replaced by a much smaller pop-up window containing
options that are useful during the actual running of the simulation,
and will only return when the simulation ends.

To end the
simulation, simply exit from any of the visible elements of
the simulation—though there's a bit of platform to platform variation
as to which components are easily terminated, so I'd recommend closing
the DSKY. Within a few seconds
all of the other elements of the simulation will automatically
terminate. Note, however, that the automatic closing of all the
simulation windows isn't active until several seconds (5 in most
versions, 30 in some) passed
from the time the simulation started up, so if you start a simulation
and then immediately decide to shut it down, you'll still have to wait
a little while for the process to complete. Also, on Mac OS X,
there are various windows that simply may not close automatically,
running programs called Wish
and Terminator, and these will
simply have to be closed manually from their main menus.

Quick Start

I expect that anyone who would really
use Virtual AGC would likely want to adapt it quite a bit, and so any
simple instructions I might give wouldn't help much. Not to
mention
the burden of training yourself on the technical nitty-gritty of Apollo
systems before you can actually use
the AGC for anything! :-) But here are a few scenarios
where you can
quickly get to
the point of seeing something
happen, if not necessarily anything meaningful to our sad little
earthbound minds. The "full Apollo experience" isn't available
yet, since peripheral devices like the AOT haven't been created
yet.
But
there are still a few things you can try that are amusing in a geekish
sense.

Running the Validation
Suite

There
is a "validation suite", which I've written in AGC assembly
language, that attempts to check that each CPU instruction is
implemented correctly in the AGC simulator. You won't get the
"Apollo experience" by running it, but at least you'll be executing
real AGC assembly-language code:

Run VirtualAGC as
described above, select the "Validation Suite" choice in the
"Simulation Type" area, and hit the "Run!" button.

On the DSKY, you'll see 00 appear in the
PROG and NOUN fields,
and you'll see the OPR ERR annunciator will light. This
means that the validation program is ready to start. Press the
DSKY's PRO key to start the program. The OPR ERR annunciater will
turn off to indicate that the command was accepted.

After about 77 seconds or so, 77 will appear in the PROG field
and the OPR ERR annunciator will light. If anything other than 77
appears in the PROG field, then the numbers in the PROG and NOUN fields
will indicate which area of the test failed. (You can press PRO
again to proceed with the remaining tests.)

Playing
with Colossus

Run the VirtualAGC program as described earlier, select any of the
Command Module choices in the "Simulation Type" area, and then try the
following stuff:

View the alarm codes

Because of some current bugs
(07/19/04) in the way I initialize Colossus, there will be some program
alarms at startup, and the PROG indicator will light to inform you of
this. You can view the alarms by keying in V05N09E at the
DSKY. (In normal AGC shorthand, 'V' is short
for "VERB", 'N' is short for "NOUN", and 'E' is short for "ENTR".
So "V05N09E" means to hit the keys VERB 0 5 NOUN 0 9 ENTR.)

Program alarms 1105 and 1106 happen to be "downlink too fast" and
"uplink too fast". Uplinks or downlinks refer to exchange of
telemetry information with ground equipment.

DSKY lamp test

At the DSKY, key in V35E.
This will light
up all of the DSKY annunciators, flash the VERB/NOUN labels, and
display 88 or +88888 in all of the numerical registers. After
about 5 seconds, the test stops—you can tell, because the flashing
stops, though the numbers remain—and you can continue.

When the accompanying screenshot was taken, I didn't yet know how the
AGC controls the DSKY's STBY and RESTART indicators, so those weren't
turned on by the test. Because of a bug in the simulator (as of
07/19/04), the PROG indicator doesn't re-light after the lamp-test
completes. Therefore, you may
or may not see the PROG indicator lit if you try the sample operations
below.

Display memory-bank
checksums

The core-rope (read-only) memory
is divided
into 36 banks, numbered 00-43 (octal). A so-called "bugger word"
has been stuck at the end of each bank—yes, I get the joke, so
please don't send me an
explanation (and if you don't
get it, don't ask me)—which causes the checksum of the bank to come
out to a known value. This known value is the same as the bank
number when possible, and is the logical complement of the bank number
otherwise. (For example, the checksum of Colossus bank 00007 is 00007,
but the checksum of bank 00006 is 77771. Both are correct.)
Colossus's
"show-banksum" program can be used to display the bank numbers, one by
one. You can execute the show-banksum program by keying in V91E
on the DSKY. After a few seconds, the statistics for bank 00 will
be shown: R1 (the topmost 5-digit display) will contain the
computed checksum; R2 will contain the bank number; and R3 will contain
the bugger word. Each of the displays will be in octal, as
indicated by the fact that the +/- sign is blank. To advance to
the next bank, key in V33E. (Hitting the PRO key does the same
thing.) If
you have the patience to advance
through each of the banks, the next V33E (or PRO) after bank 43 will
wrap-around
to bank 00 again. To terminate the show-banksum program, you can
key in V34E.

By the way, the bank-6 bugger word shown (05143) is for Colossus
249. If you ran the Artemis 072 program, it would have been
04275, while if you ran the Luminary 131 program, it would have been
63402.

Monitor
the current time

If you key in V16N36E or
V16N65E, it will cause the current time to be displayed. (Since
we haven't set the time in any way, this will be the time since
AGC power-up). R1 (the topmost 5-digit display) will
be in hours, R2 will be in minutes, and R3 will be in 100ths of a
second. This display is updated once per second.

In the accompanying screenshot, the time is 06:58:33.86.

Setting the current time

If it annoys you to see the time
since power-up, you can change the
time (for example, to mission time) by keying in V25N36E. R1 will
go blank, enabling you
to key in the current hour. Make sure you start with a + sign
(this is how the AGC knows you're using decimal rather than octal), and
make sure you enter all five digits (including the leading
zeroes).
In case you make a mistake, you can clear R1 any time before pressing
ENTR by using the CLR key. After you hit the ENTR key, R2 will
clear and you can enter the current minutes. Finally, you can key
in the number of seconds in R3. Don't forget that the number of
seconds is actually in 100ths of seconds, so that if (for example) you
want 30 seconds you'd key in +03000E.

In the accompanying screenshot, it just happened to be 06:55:25 am., so
that's how I set the clock.

Examining the contents of
the core-rope

Key in V27N02E. This
allows you to
enter the address of a word in the core-rope into R3. This
address will generally be in octal, and therefore should not be
preceded by a + sign. Also, unlike entry of decimal data, in
octal you can
enter just as many digits as you need, and don't need to enter a full
five digits. The addresses will be 00000-01777 for memory bank
00, 02000-03777 for memory bank 01, and so forth, up to 76000-77777 for
memory bank 37. (I'm not sure how to examine banks 40-43.)
The binary listing of the core rope is at the very back of the Colossus
249 assembly
listing, which can be downloaded from MIT if you have some spare time
and disk space. (See my links
page.)

In the accompanying screenshot, we see that address 4000 (octal) of
Luminary's core-rope contains the value 00004. This just happens
to be the first instruction executed after power-up. It is an INHINT instruction, and
disables interrupts. The contents of R2 (the middle 5-digit
register) are not cleared, and thus are just whatever lingers from
before.

Examining the contents of
erasable memory

Key in V01N02E. This
allows you to
enter the address of a word in erasable memory into R3. The
addresses will be 00000-00377 for erasable bank E0, 00400-00777 for
memory bank E1, and so forth, up to 03400-03777 for memory bank
E7. Alternately, you can "monitor" a memory location (i.e., get
updates for it once per second) by using VERB 11 rather than VERB
01. For example, V11N02E25E will monitor register 25, the "TIME1"
register, which is an internal counter that increments every 10
ms. In general, of course, the numbers won't mean much unless you
reference them to the Colossus 249 assembly listing.

In the accompanying screenshot, we actually do look at the TIME1
register, and discover that at that instant it contained the value
20245 (octal). Of course, you'll see something different.
Display R2 is not changed, so it just contains whatever it contained
before.

Altering the contents of
erasable memory

Key in V21N02E, and enter an
octal
address as above, and then enter a new value to be stored at that
address. It goes without saying that you need to know what you're
doing when you do this!

In the accompanying screenshot, I've chosen to reload the TIME1
register with the value 12345 (octal), which probably won't cause too
many adverse effects. Display R2 is not changed, so it just
contains whatever it contained before.

Fresh start

Key in V36E. This
apparently restarts the "pinball" program—i.e., the program that is
responsible for accepting verbs and nouns and
displaying stuff on the DSKY—and it's useful
for clearing garbage from the DSKY's display, as the accompanying
screenshot demonstrates.

In the accompanying screenshot, a side-effect of the fresh start is the
thoughtful re-display of the PROG (program alarm) which the earlier
DSKY lamp-test
had wiped out.

(Your
picture here.)

Do-it-yourself research

The file
yaAGC/Colossus249/ASSEMBLY_AND_OPERATION_INFORMATION.s lists
the verb and noun tables,
so perhaps you can figure out some neat stuff yourself. If you
do, let me know and I'll add it
to this list.

Playing
with Luminary

You can do
the same
things as for Colossus above.
Or rather than trying stuff at random, you can try stepping through a
more realistic startup checklist. (Thanks to Julian Webb.)

Step 0

Run the simulator

Run VirtualAGC as described
above, select "Apollo 13 Lunar Module" in the "Simulation Type" area,
and hit "Run!"

Step 1

V35E

Starts the DSKY lamp test.
All of the indicator lamps are lit, the numerical displays show 88 or
+888888 as appropriate, and things which are supposed to flash,
flash. After about 5 seconds, the lamp test automatically
terminates.

Step 2

V37E 00E

"Goto Pooh"—i.e., start
program P00, the idling program. The numeric area under the PROG
label will show 00.

Step 3

V25E N01E 01365E 0E 0E 0E

Set the count of total failed
self-tests, total started self-tests, and successfully-completed
division tests to 0.

Step 4

V15 N01E 01365E

Begin monitoring the self-test
counts. R1 (the top 5-digit display) shows the number of failed
tests, R2 shows the number of started tests, and R3 the number of
completed division tests. Each should be +00000 ("all balls").

Step 5

V21 N27E 10E

Begin background
self-tests. These tests will continue until the astronaut (you!)
terminates them. Continue at least until the number of started
tests (R2) reaches 3.

Step 6

V21 N27E 0E

Terminate the background
self-tests.

(Looks
the same,
of course.)

...

(more later)

Much more
intensive playing with the LM

Stephan Hotto has provided a helpful tutorial that will let you do much
more than the simple computer-maintenance activities described
above. Following his tutorial you'll be able to control the LM
using the hand-controller (joystick), see the orientation of the
spacecraft change on the 8-Ball, fire the thrusters, etc. The
instructions for his tutorial are actually build into the program
itself, so I'll just tell you enough to read his tutorial rather than
duplicating the tutorial's information here:

In the Interfaces pane, click the "Expert" button. (You can
unclick the AEA simulation if you like. The Telemetry monitor
won't be directly used either, but I like it so much I'd never advise
you to deselect it.)

Run!

In the window titled "LM Simulator vN.N by Stephan Hotto", select
Info/Tutorial from the menu bar.

In the window titled "Tutorial for LM System Simulator" that pops
up, follow either the
instructions in Section 0.0 or
else the instructions in Sections 0.1-1.4,2.0-2.3.

Playing
with the Abort Guidance
System

Now admittedly, I don't understand much you
can do with the Abort Guidance System yet, nor do I claim that the
program is complete, but there are some
things you can try:

CLR 4 1 2 READOUT

View the results of the
self-test, which are stored in the AGS CPU at (octal) location
412. A code of +10000 means the test has passed.

Oops! the
test has failed. That's because the self-test is pretty thorough;
it tests not only memory checksums, but also the operation of various
CPU instructions. The possible error codes here are:

I was having a little problem with the instruction set when this
screenshot was taken, thus the self-test failed. Fortunately, the
AGS flight programs have been written to continue
operating in the case of self-test failure, even though it is "not
recommended". The current version of yaAGS actually does pass the
self-test, and so you'll see a code of +100000 here.

CLR 3 7 7 + 0 0 0 0 0 ENTR

Set the clock to 0. The
CPU uses address 377 (octal) as a counter that increments at 6-second
intervals. Before using it, though, we want to set it to a known
value.

In real life, the AGS time would be initialized by synchronizing with
the AGC electronically. However, I'm not quite yet ready with
that particular feature.

CLR 3 7 7 READOUT

Watch the clock
incrementing. Although the counter changes at 6-second intervals,
and counts in units of 6 seconds, the CPU actually updates the DEDA
display every 1/2 second.

More
later ... however, the operations listed above are very representative
from the user-interface perspective of all the other kinds of
operations you can perform on the DEDA. There are basically two
classes of DEDA-based operations:

Get a running display of the contents of a memory
location. The command sequence for this is CLR OctalDigit1
OctalDigit2 OctalDigit3 READOUT. Upon receiving
this command, the AGS CPU will monitor the selected memory location and
display it on the DEDA every 1/2 second. You can pause the
readout by hitting HOLD,
or resume it by hitting READOUT
again. The flight software will automatically scale the data or
otherwise modify it (by changing units of measurement) in a way
appropriate to the particular memory location before displaying the
data. If you make a mistake in the key sequence, the OPR ERR lamp
will light, and you'll have to hit CLR to clear the error
condition.

You can change the value of a location of memory. In
doing so, the flight software may choose to interpret your action as a
command to perform some further action, but I'm not up to speed on what
those other actions might be. The command sequence is CLR OctalDigit1
OctalDigit2 OctalDigit3 +/- Digit1
Digit2 Digit3 Digit4 Digit5 ENTR. The
5-digit data may be octal or decimal, but that is dependent on the
particular memory location chosen, and isn't a choice that the
astronaut/user makes. Again, a mistake in the sequence will cause
the OPR ERR lamp to light.

Of course, there are operations the astronaut/user can perform that are
outside of this framework, such as hitting the ABORT button or
downloading the spacecraft state vector from the AGC.
However the abort button is a separate switch rather than being a part
of the
DEDA, and I've not perfected AGC-to-AGS communication yet.

Playing with AGC
assembly language

You can modify the validation-suite AGC assembly-language software I've
provided, and then run the modified software on yaAGC, as follows.

Copy the folder containing the
Validation Suite software
to a new folder. (In the developer snapshot, these are the files
yaAGC/Validation/*.s; in the binary installation, they'll still be the
files *.s, but the easiest way to find the name of the directory
they're in is to "Browse Source Code" from within the VirtualAGC
program and to simply note down what directory is being referenced by
the browser.)

Edit some of the validation-suite
source-code files. The assembly-language
programmer's manual is here.

Run the VirtualAGC program, select "Custom" in the "Simulation
Type" area, choose Validation.s from the folder in which you've been
working. After VirtualAGC
automatically runs this through the assembler to create a binary
executable, just hit
"Run!".

You should now see the DSKY doing whatever you've programmed it
to do.

On the chance that your program
may not do what you expected it to do, there is primitive debugging
capability built into yaAGC
which may be helpful in tracking down the problems. Just slect
"Run with debug monitor" under "AGC Debug" in the "Options" area of VirtualAGC. Instructions for
how to use the
debugger are here.

Modifying the LM
software (for the truly brave)

Same as "Playing with AGC assembly language", but start from the
Luminary131 source code instead of the Validation Suite software, and
note that the "custom" file you have to select is MAIN.s rather than
Validation.s.

Final exam (for
the
advanced student)

Prior to the descent of Apollo 14's LM
to the lunar surface, a short in the LM control panel caused the abort
switch to be triggered intermittently. If this actually happened
during the landing, an abort would have automatically occurred (meaning
that the lower stage of the LM would have been jettisoned and the upper
stage would have blasted back into space). No landing would have
been possible, and the astronauts would have faced the grave situation
of needing rescue by the command module. It was therefore
necessary, in the orbit or two before descent, for the some of the
software designers to work out a fix for this problem that allowed a
software lockout of the abort switch during the initial phase of the
descent, but also allowed reenabling the abort switch later in the
descent, in case the astronauts needed to use it. They did, in
fact, work out such a fix. Your mission, should you choose to
accept it, is this: Work out such a fix and send it to me.
Remember, your fix can only involve erasable memory, since the
core-rope containing the program cannot be altered. The fix needs
to be keyed in at the DSKY by the astronauts. You have about 90
minutes to figure it out. Go!

... Or, for the silly
mood

Use Virtual AGC as a clock for your PC
desktop. (My word, this software is versatile!) I'd suggest
using the "DSKY Type" of "Half-size" for this. Use
the instructions given above for setting
and monitoring the time. You'll have to reset the time very
morning, because the "hours" will not wrap around to 0 after 24.
(And besides, the timers will overflow after 228/100
seconds, or just over 31 days.)

Hint: Once you get this
working well, you'll want to be able to start this up automatically,
and not have to run VirtualAGC
every time. Well, when VirtualAGC
runs the simulation, it does so by creating batch files (in Windows) or
a shell script (in Linux or Mac OS X), then simply running those batch
files or shell scripts. When you run a custom program in VirtualAGC, you use the "More"
button in the simulation window to show you the contents of those batch
files or shell scripts. So you can reuse or adapt those files for
starting up your own simulation.

... Or, for the
even
sillier mood

Write your own AGC or AEA assembly language program
for a calculator, or a game (like tic-tac-toe), or some other frivolous
purpose. It's not very respectful, but it will hone your skills
for that next AGC or AEA programmer opening you hear about. :-)

Acknowledgements

(When I first added this section to the document, I thought it would be
easy to keep up-to-date. As it happens, so many people have
stepped forward at one point or another that my mind simply isn't big
enough to hold all of their names. So it's entirely possible that
even very significant contributers may have been inadvertantly omitted
from the list below. Have no hesitation about reminding me if
I've slighted you by forgetting to mention you!)

Of course, it goes without saying that the greatest thanks go to
the
original software developers of the Apollo project. Hugh
Blair-Smith needs to be specially mentioned, since
his activities had a special relevance to my own project, and since he
has patiently allowed me to pepper him with many questions. But
we are
told that as many as 300-400 programmers contributed to the Colossus
and Luminary source
code. Though not specifically a software
developer, Eldon C. Hall also has been very specifically helpful to me.
I've
not yet uncovered a full list of the software developers. Only a
small fraction of the developers'
names appear in the source-code versions accessible to me, and in
poking around the web, as follows
(corrections, additions, deletions, and biographical data
welcome!):

It should go without saying that by singling out coders, I don't mean
to imply that hardware design, system architecture, or even program
management is not important. The AGC hardware was certainly
pretty revolutionary for its time, in terms of miniaturization and
reliability. A complete
AGC honor roll would need to include names like Charles
Stark Draper and many others. But since our simulation of
necessity concentrates on the software aspects of the AGC over the
hardware aspects, the software developers are the ones particularly
being honored here.

I don't want to forget the original developers of the AGS
software either, but I don't yet know any of your names!

I'm grateful
to the folks at MIT's
Dibner Institute's now-discontinued History of Recent Science and
Technology website
for making the scans of Luminary
131 and Colossus 249, along
with scans of other related documents,
available online. I'm not sure who
is responsible for providing the online version of Colossus 249 (at MIT's site), but a
special
thanks goes to you. Thanks to David Mindell for helping me
to move in the right direction with my inquiries, and to Sandy Brown
for giving me extremely valuable information about the available
AGC-related material at MIT.

Gary Neff deserves a big vote of gratitude for having the
foresight
(and presumably fortitude) to create the page scans of Luminary
131 software source code. Without those I wouldn't even have
attempted this project. Mr. Neff has also been extremely
helpful in supplying me with quite a lot of replacement scans for
garbled pages (52 of them so far) in the
currently-available online versions of Colossus
249.
(Thanks also to Mr. Eric Jones, of the Apollo Lunar Surface Journal,
for putting me into contact with Mr. Neff.)

Thanks also to the many helpful people at NARA
Southwest Region. Special thanks to Rodney Krajca and Meg
Hacker.

Thanks to Julian Webb for some very fruitful
interactions, in comparing his AGC simulator to mine, for
explaining some interactions between the AGC and DSKY, and for some
helpful introductions.

Acquisition of the Apollo 15-17 CM AGC software was a team
effort:

Apollo
15-17 CM Honor
Roll

The anonymous donor of the Artemis 72 program listing,
who I have oh-so-amusingly previously referred to as "D. Thrust".
(It's a Nixon/Watergate joke, folks!)

Jim Lawton for debugging the source code. This is
an enormous amount of effort, and since it is the first time I didn't
have to do it myself, I'm very appreciative. Jim also did a lot
of extra editing and behind-the-scenes management.

Eldon C. Hall, for his foresight in preservation, the
leads he provided, and for his overall approval.

George Keremedjiev, Curator of the American Computer
Museum, for making the listing available.

Kim Scott, Archivist of Special Collections, Renne
Library, Montana State University, and other MSU individuals whose
names I do not know, for helpful and responsible supervision of the
digitization effor.

Marilyn Chang, Librarian, Wings Over the Rockies Air
& Space Museum, for the necessary research and contacts.

Fabrizio Bernardini, for bringing Marilyn into the
loop.

Henry Wesso, for constructing the special copy stand
used for the digitization.

Gil Guerrero, for providing advice and camera
equipment.

Jim Lawton, who seems to have single-handedly converted the
scanned pages both to source-code and binary form.

Thanks to Matteo Giani for figuring out how to get this beast to
compile in Mac OS X Panther.

Thanks to ibiblio.org,
which began hosting the Virtual AGC project when by own meager
resources were exhausted.

Thanks to John Pultorak of Block I AGC
fame. John has provided not only documentation for his project
that doesn't appear on the websites hosting his other materials, but
also has digitized many AGS-related documents available nowhere else
online (or not online, as far as I can tell).

Thanks to Davis Peticolas, the donor for all of the scanned AGS
documents.

Thanks to Mark Grant and Markus Joachim for their work in
integrating Virtual AGC into the Orbiter
spacecraft simulator.

Thanks to Stephan Hotto for the enormous amount of code he has
contributed, and for
finding various bugs in the simulation.

Thanks to Onno Hommes for stepping in to add many features to the
project, such as syntax highlighting, GUI debugging interfaces,
subversion repository, wiki, etc.

Thanks to Shelly Kelly, archivist at the University of Houston at
Clear Lake, for efforts (and patience) above and beyond the call of
duty, and particularly for some GSOP scans appearing on our links page.

Thanks to Jordan Slott, for implementing symbol tables into the
debugging mode of the AGC simulator.

And finally, thanks to my other correspondants who have
contributed in ways that don't necessarily fall into any of the neat
pigeonholes listed above. There are too many of you to note
adequately here, but I've tried to acknowledge you throughout the
website where your contributions are relevant. If I've unfairly
overlooked you, attribute it to a 1201 alarm in my brain; let me know
and I'll fix it.

Solution to the
Apollo 14 "Final Exam" Problem

Above, we semi-jokingly proposed as a "final exam" problem a
situation which actually occurred during Alan Shepard and Edgar
Mitchell's attempt to land the LM during the Apollo 14 mission. Paul
Fjeld has provided a lot of detail about this at the Apollo Lunar
Surface Journal, by consulting mission transcripts. Our Onno
Hommes has also gotten an explanation directly from Don Eyles, the AGC
developer who solved the final exam problem in real time during the
mission and, as far as I know, the only AGC coder ever to be dramatized
(in the Apollo 14 episode of From
the Earth to the Moon). And Don has written about it
himself (among many other stories) pretty interestingly, in a
fairly popularized way.
But here's the detailed solution, in as nearly Don's words as we can
make it:

The
procedure developed to work around the erroneous abort signal on Apollo
14 was as follows:

(1) After the NOUN 62 countdown starts (an automatic display of the
countdown toward engine ignition), but before ignition, key in

VERB 21 NOUN 1 ENTER 1010 ENTER
107 ENTER

to set the mode register to 71 to indicate that an abort had already
occurred. Note that the numbers are in "octal" (i.e. based
on the root of 8 not 10) so that the number "107" actually means "71".

to enable the landing guidance equations. The equations were
prevented from starting automatically because the mode register is set
to the phony value of 71.

(4) Key in

VERB 25 NOUN 7 ENTER 105 ENTER
400 ENTER 0 ENTER

to explicitly disable the abort monitor. This clears the FLAGWORD bit that controls the abort monitor.

(5) Key in

VERB 21 NOUN 1 ENTER 1010 ENTER
77 ENTER

to set the mode register to its proper value of 63.

(6) Return the manual throttle to its minimum setting. The
throttle stays at 100% because it is now being commanded by the
guidance equations. But if this step were omitted the
throttle would be forced to stay at 100% when the guidance equations
later request partial thrust, with bad effects.