This Project

^*My apologies, but at present I don't care to be too specific about non-ITAR related restrictions on the surviving Space Shuttle flight software.  It's a first-rule-of-fight-club kind of thing.

^†Due to the limited information available when it was written, the syntax accepted by the Gemini OBC assembler is likely to differ from the syntax of actual OBC source code, if any is ever discovered.

^😮

Contents

• What are the "AGC", "AGS", and "LVDC"?
• What "Virtual AGC" is
• What Virtual AGC is not
• Existing Elements of the Virtual AGC Project
  
• Licensing
• What if You Want to Help?
• Running the Emulator ... or, A Brief Introduction to the GUI
  
• Quick Start
• Running the Validation Suite
• Playing with Colossus
• Playing with Luminary
• Much more intensive playing with the LM
• Canned, pre-recorded mission segments
  
• Playing with the Abort Guidance System
  
• Playing with AGC assembly language
• Modifying the LM software (for the truly brave)
• Final exam (for the advanced student)
• ... Or, for the silly mood
• ... Or, for the even sillier mood
  
• Acknowledgements

What are "Block I", "Block II", the "AGC", "AGS", "LVDC", and "OBC"?

What "Virtual AGC" Is

What Virtual AGC Is Not

Existing Elements of the Virtual AGC Project

This isn't exactly an exclusive list, but some of the important things we provide in the Virtual AGC project proper are listed below.

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.
• LM_Simulator is a simulation of various other Guidance & Navigation (G&N) system components, such as the Inertial Measurement Unit (IMU), an FDAI ball, an alternative simulated DSKY, and a monitor for the AGC's i/o-channel activity. 
  
• 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 programs like Luminary or Colossus (see below) into the binary executable format (a "core rope") needed by the AGC.
• Luminary is the name of the original 1960's and 1970's software used for the Apollo Lunar Modules in the actual missions.  Both binary executable (needed by yaAGC) and source code (needed by yaYUL) are provided.  We have many, many versions of this software, for different missions.
  
• Colossus is the name of the original 1960's and 1970's software used for many (but not all) of the Apollo Command Modules.  As with Luminary, both binary and source are provided, and we have many versions of the software.
• 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.
  
• We have 1000+ scans of many, many of the original Project Apollo documents in our document library.
• We're making an ongoing effort to provide hardware support (both electrical and mechanical) for the original AGC and DSKY designs, and for the Guidance & Navigation (G&N) system in general:
• Tens of thousands of scans of the original G&N electrical and mechanical drawings. 
  
• Many electrically-accurate transcriptions of AGC/DSKY electrical drawings in a modern CAD (Computer Aided Design) system.
• Translations of into AGC electrical design into the Verilog for simulation of the AGC electrical circuitry.
• (Coming real soon now.)  3D-models created from AGC/DSKY mechanical design files, for 3D printing.
  

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, in a couple of different versions.
• AGS scanned documentation, including specification, programmer's manuals, and so on.

LVDC and Gemini OBC Elements

• (Planning only.) yaLVDC, an emulation of the LVDC and Gemini OBC CPUs, and various programs emulating Gemini-spacecraft peripherals.
• yaASM, an assembler for the Apollo LVDC and Gemini OBC assembly language.
• Scans of all known existing LVDC and Gemini OBC documentation.
• Of course, the missing element here is that we have no significant access to any true LVDC or Gemini OBC source code, so having an assembler or simulator for it is of questionable utility.  We hope this situation will change, but that hope fades with each passing year.
  

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

What If You Want To Help?

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

Quick Start

Running the Validation Suite

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 several tens of seconds, 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

	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—no comments on this terminology, please, since I didn't invent it; when I asked Don Eyles some question that involved them, he somewhat-laconically stated "we called them check sums"—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 Document Library 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

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

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.
   

Canned, pre-recorded mission segments

One nice thing about open-source software (which our Virtual AGC Project is!) is that other people are free to incorporate the software within their own projects, and thus it can see a more-rapid diffusion into a wider sphere of usage than would have been possible if (say) it was just me developing it by myself.  In the case of Virtual AGC, one thing that has been done with it is that it has been incorporated into the Orbiter Space Flight Simulator system, via the Project Apollo NASSP add-on, which people then use to fly very realistic or imagined Apollo missions.  The NASSP folks have been kind enough to incorporate the capability of logging interactions between the simulated AGC and simulated DSKY, with the result that we can "play back" (though not interact with) such realistic logged activity on the simulated DSKY.

This capability is only available in Virtual AGC software versions 2017-12-11 and later, and it works as follows:  if you left-click on the PROG lamp indicator with the mouse, a file-dialog will open up.  Of course, in the real DSKY, PROG was not a button; it was merely a lamp.  But we've assigned it this additional function in our simulated DSKY.  In the file-dialog, select the pre-recorded script

Apollo8-launch.canned

As you may imagine, this is a recorded Apollo 8 launch sequence, which takes about 15 minutes to play back.  You'll see various things in watching it:

• PROG 02, VERB 75.  The script begin at T-40, i.e., 40 seconds prior to launch, and in this state the AGC simply waits to receive an ignition signal from the Saturn rocket ... or technically, what it will eventually receive is the "liftoff discrete" from the S-IVB stage.  Program 02 is the Gyro Compassing Program, and its purpose is "to provide the stable member orientation for launch".  The "stable member" is a part of the inertial measuring unit (IMU) which holds the gyroscope (for determining the spacecraft orientation) and the accelerometers.  The astronaut doesn't actually have to select Program 02, because it is automatically selected by Program 01 (the initialization program), which was run prior to T-40, and hence you won't see it in the playback.
  
• PROG 11, VERB 06, NOUN 62.  At ignition, the AGC automatically transitions from Program 02 to Program 11, the Earth Orbit Insertion Monitor Program.  Realize that the AGC itself was not able to control the Saturn rocket itself, other than the Saturn IVB stage, and the Saturn was controlled instead by its own internal computer, the LVDC. The AGC's real work began later! Nor did the AGC receive any information from the LVDC as to the quantities it is monitoring and displaying on the DSKY.  The LVDC and AGC separately each had access to their own inertial measurement units (IMUs) that measured the acceleration and orientation of the spacecraft, and by mathematically integrating this data from the IMU, the LVDC and AGC could independently figure out everything they needed to know about the current state of motion of the rocket ... and hopefully the LVDC and AGC would come up with very similar results.  So this monitoring activity is much less trivial that it may sound to you at first.  As for what's actually being monitored in this program, the AGC is driving the FDAI (i.e., the "eight ball" or "attitude indicator") is being driven to show the astronaut the orientation of the rocket in a nice graphical way, though the FDAI is not a part of the DSKY.  But the AGC is also computing trajectory parameters and displaying them on the DSKY.  Those parameters, from top to bottom, are "VI" (the inertial velocity magnitude, in feet per second), "H DOT" (the rate of change of altitude above the launch pad, also in feet per second), and "H" (the height above the launch pad, in tenths of a nautical mile).
  
• PROG 11, VERB 16, NOUN 50.  After a few minutes, the astronaut has initiated this monitoring command.  You'll notice that the KEY REL lamp is flashing, because the previous monitoring (VERB 16, NOUN 62) wasn't actually terminated but merely temporarily interrupted, and the astronaut is being warned that when he terminates the VERB 16 NOUN 50 monitoring he'll automatically return to the other monitoring.  As for what's being monitored here, from top to bottom, it's the "splash error" (in tenths of a nautical mile), and a couple of other items about which the documentation is inconsistent.  The "splash error" part sounds a bit confusing, but apparently in Program 11 it has nothing to do with splash-down, but is rather the negative of the range to target.
  
• ... and so on.  Eventually, after this phase of the mission is completed, the astronaut keys in VERB 37 ENTR 00 ENTR to return to program 00, and then keys in VERB 66.  I'm not sure why the latter was done.  It was for transferring state vectors (i.e. the position, velocity, and orientation) from the LM's AGC to the CM's, or vice-versa.  But of course, for Apollo 8 there was no LM.  Oh well, I'm inexcusably ignorant, so it's probably the correct thing to do!
  

If you get tired in the middle of all this and don't want to watch it all the way to the end, just click PROG again to terminate the script.

Playing with the Abort Guidance System

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

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 select "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)

Final exam (for the advanced student)

... Or, for the silly mood

... Or, for the even sillier mood

Acknowledgements

AGC Software Developers

• Program P12: Larry Berman
• Program P06: Dana DeWolf
• Programs P10-P11: Phil Shakir
  
• Program P12: Larry Berman, Craig W. Schulenberg
  
• Program P20: Peter Volante, Virginia Dunbar
  
• Program P21: Ted Crocker
  
• Program P22: Peter Volante, Virginia Dunbar
  
• Program P25: Peter Volante, Jack Connor
  
• Program P27: Paul Fagin
  
• Program P30: Peter Adler
• Programs P31-P35: Pat White
  
• Programs P38-P39: Jane Goode
  
• Programs P40-P42: Peter Adler
  
• Progam P47: Bob Covelli, Ken Vincent
  
• Programs P51-P52: Don Millard
  
• Programs P57: Don Millard
  
• Programs P63-P67: Don Eyles
• Programs P66-P67: Don Eyles, Craig W. Schulenberg
• Programs P70-P71: Walter Bernikowich, Larry Berman, Craig W. Schulenberg
• Programs P72-P75: Pat White
  
• Program P76: Ted Crocker
• Programs P78-P79: Jane Goode
  
• Routines R00: Dana DeWolf
  
• Routines R02: Dana DeWolf
  
• Routine R03: Peter Weissman
  
• Routine R04: Jim Kernan
  
• Routine R05: Peter Volante
  
• Routine R10: Walter Bernikowich
  
• Routine R11: Don Eyles, Walter Bernikowich
  
• Routine R12: Bob Covelli
  
• Routine R13: Don Eyles
• Routine R21-R25, R29: Peter Volante
  
• Routine R30: Frank Gauntt
  
• Routine R31: Ted Crocker
• Routine R33: George Cox
  
• Routine R36: Ted Crocker
• Routine R47: Jim Kernan, Phyllis Rye
  
• Routines R50-R55, R59: Don Millard
  
• Routine R60: Frank Gauntt
  
• Routine R61: Virginia Dunbar, Jack Connor
  
• Routines R62-R63: Frank Gauntt
  
• Routine R65: Virginia Dunbar, Jack Connor
  
• Routine R77: Jim Kernan
  
• Pinball: John Vella, Marjorie Besas
• Display interface: Margaret Hamilton, Phyllis Rye
  
• Restarts, fresh start, and other service areas: Phyllis Rye, Dana DeWolf
• Integration: Bill Ostanek

May 1962

September 1968, Group 23B only

February 1969 (18 pages)

February 1972 (18 pages)

Others

• I don't want to forget the original developers of the AGS software either, but I don't yet know any of your names!
• Gemini software developers Gene Mertz, Charlie Leist, Alden Minnick, and Don O'Neill have been of assistance to me, and other references to the original developers appear on the Gemini page.
  
• 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!) (In alphabetical order) Steve Case, Hartmuth Gutshe, Onno Hommes, Jim Lawton, and Sergio Navarro, for converting the page images to source code. 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.

• Acquisition of the Apollo 11 LM & CM AGC software was a team effort:
  

  Apollo 11 Honor Roll Organizational honors Massachusetts Institute of Technology / MIT Museum Building N51, 265 Massachusetts Avenue Cambridge, MA  02139 web.mit.edu/museum/ Individual honors Deborah Douglas, the Museum's Curator of Science and Technology, who conceived the idea of making this material available to us, and without whom we had literally no chance of obtaining it. Paul Fjeld, for digitizing the hardcopy. (In alphabetical order) Fabrizio Bernardini, Hartmuth Gutshe, Onno Hommes, Jim Lawton, and Sergio Navarro, for converting the page images to source code. Steve Case and Dawn Masuoka for helping to proof the LM binary. ... and those whose names I do not know at the Charles Stark Draper Laboratory and NASA who allowed us to do this.

• Thanks to Paul Fjeld, who has fed me extraordinary information on locating versions of Luminary and Colossus source code not otherwise known to me, and on various other related topics.
• Thanks to Fabrizio Bernardini for providing some unique documentation.
• Acquisition of the Apollo 6 CM AGC software was a team effort:

Apollo 6 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.

• Acquisition of the AURORA 12 and SUNBURST 120 (Apollo 5) LM AGC software was a team effort:

AURORA and Apollo 5 Honor Roll Organizational honors The Internet Archive www.archive.org Individual honors Don Eyles for preserving the AURORA 12 and SUNBURST 120 program listings, making them available to us, and going to the effort of physically transporting them for us. Mike Stewart for financially sponsoring the scanning of these programs, as well as doing all of the background work needed to find them and figure out the best way to get them scanned. Our volunteer team, for transcribing the scanned program listings into source code.

• Acquisition of RETREAD 50 (unflown) LM AGC software was a team effort.

RETREAD 50 Honor Roll Organizational honors The Computer History Museum Mountain View, California www.computerhistory.org Individual honors Jimmie Loocke, owner of AGC s/n RAY 14 AGC Restoration Core Team: Carl Claunch Ken Shirriff Mike Stewart Marc Verdiell Auxiliary AGC Restoration Team Members: John Carlsen Rob Lion

• 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 my own meager resources were exhausted.  In latter days, The services of The Internet Archive and GitHub have also become crucial.
  
• 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 my core developer team:
• Onno Hommes for stepping in to add many features to the project, such as syntax highlighting, GUI debugging interfaces, subversion repository, wiki, etc.
• Jim Lawton especially but not exclusively for great infrastructural improvements such as tying the project's website to our GitHub repository and setting up continuous-integration for the latter, along with many other things.
• Mike Stewart for using his hardware-based AGC simulator to track down and fix many subtle, lingering bugs in our software AGC simulator (and vice-versa), as well as a number of other innovations.
  
• 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 Document Library 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

1. For the first couple of minutes, shows what would the actual spurious abort have looked like.  (Answer:  It separates the ascent and descent stages of the LM, and takes the ascent stage back into orbit.  You don't die, but you don't land!)
2. The remainder of the video shows how to enter the fix, prevent the spurious abort, and proceed to the surface.
   

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2024-08-26