Home
AGS
LVDC
Gemini
Download
Document library
Change log
Bug and issues
Developer info
Virtual AGC — AGS — LVDC — Gemini

Home Page
Project Overview

FAQ
yaAGC
yaYUL
yaDSKY
yaOtherStuff
Luminary
Colossus
Language Manual
Physical Implementations

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.)

Contents

What are "Block I", "Block II", 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.

And of course, don't forget the "block III" model of the AGC, which ... wait just one second there, buddy!  Anyone who has done any reading at all about Apollo, knows there's no such thing as the block III AGC.  Okay, that's true, but one of the original AGC developers, Hugh Blair-Smith, developed some thoughts in his spare time about what a block III AGC might look like, and has been kind enough to send them to us.  If you're an advanced student of the AGC who has already absorbed everything there is to know about the block II system, you might be interested in reading what Hugh has to say about it.

"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

AGS Elements

LVDC and Gemini OBC Elements

Contributed Code

And to Tie It All together ...

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?

Check out the volunteering page.

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 called VirtualAGCVirtualAGC 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.

Screenshot of VirtualAGC
        program.

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:
  1. Run VirtualAGC as described above, select the "Validation Suite" choice in the "Simulation Type" area, and hit the "Run!" button.  
  2. 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.
  3. 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

(Actually, all of the things down under "Playing with Luminary" work with Colossus also.)

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:
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to Enlarge. 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.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to Enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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!"
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
Step 2
V37E 00E
"Goto Pooh"—i.e., start program P00, the idling program.  The numeric area under the PROG label will show 00.
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of
                yaDSKY. Click to enlarge.
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").
Screenshot of yaDSKY. Click to enlarge.
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.
Screenshot of yaDSKY. Click to enlarge.
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:
  1. Since you will be using the ACA simulation (joystick) for this, you may need to do a little configuration of the joystick first, or risk finding out that (say) you have no yaw control.
  2. Run VirtualAGC,
  3. Select the Apollo 13 Lunar Module AGC simulation in the Simulation Type pane.
  4. 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.)
  5. Run!
  6. In the window titled "LM Simulator vN.N by Stephan Hotto", select Info/Tutorial from the menu bar.
  7. 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:
DEDA displaying results of self-test
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:
+000000   Test still in progress
+100000   Test passed
+300000   Logic test failure
+400000   Memory test failure
+700000   Logic and memory test failure

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.
Resetting the clock.
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.
DEDA display of incrementing time.
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:
  1. 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.
  2. 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.
  1. 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.)
  2. Edit some of the validation-suite source-code files.  The assembly-language programmer's manual is here.
  3. 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!".
  4. You should now see the DSKY doing whatever you've programmed it to do. 
  5. 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!

Click here for the solution.

... 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!)
Apollo 4 Honor Roll

Organizational honors

American Computer Museum
Bozeman, Montana
www.compustory.com


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

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".

(2) Exactly 26 seconds after ignition, manually advance the descent engine throttle to 100%.

(3) Key in

VERB 25 NOUN 7 ENTER 101 ENTER
200 ENTER 1 ENTER

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.

Of course, I bet it seems pretty obvious now, right? ... right?


Last modified by Ronald Burkey on 2016-08-15.

Virtual AGC is hosted
              by ibiblio.org