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

LVDC and Gemini OBC Elements

• (Planning only) yaLVDC, an emulation of the LVDC and Gemini OBC CPUs.
• (Speculation only) yaASTEC, a program for feeding simulated spacecraft sensor inputs to yaLVDC and observing yaLVDC outputs.
• (Planning only) yaPanel, a program for simulating various OBC user-interface devices of the Gemini control panel.
  
• (Planning stage only) yaASM, an assembler for the Apollo LVDC and Gemini OBC assembly language.
• (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:
• An IMU simulation.
• An FDAI ball.
• A DSKY (if for some reason yaDSKY cannot be used).
• An i/o channel monitor, for viewing or creating arbitrary i/o-channel activity.

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?

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

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:

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

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:

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 2²⁸/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!):
  
  Jonathan D. Addelston, A. Peter Adler, Rama M. Aiyawar, Ramón Alonso, R. R. Bairnsfather, Hugh Blair-Smith, Norm Brodeur, George W. Cherry, Edgar M. Cshika, Ed Copps, Steve Copps, Bob Covelli, J. D. Coyne, Danforth, Dana Densmore, DeWitt, Bart DeWolf, Stan Eliassen, Al Engle, Don Eyles, Fagin, Filene, Naomi Fisher, Jim Flanders, Follett, Gauntt, Richard D. Goss, John Green, Margaret Hamilton (also, Hamilton Technologies, Inc.), R. Hirschkop, Mike Houston, Eileen T. Hughes, Lowell G. Hull, T. James, G. Kalan, Don Keene, James E. Kernan, Kilroy, Allan Klumpp, Tom Knatt, Alex Kosmala, Krause, Dan Lickly, Lonske, Lu, Fred W. Martin, R. Melanson, Jim Miller, John Miller, Ray Morth, N. M. Neville, North, Olsson, Rhode, Robertson, S. Rudnicki, Phyllis Rye, Joe Saponaro, Robert Schlundt, George Schmidt, Schulenberg, P. Shakir, Smith, Robert F. Stengel, Gilbert Stubbs, Sturlaugson, Richard Talayco, W. H. Vandever, Ken Vincent, P. Volante, P. S. Weissman, Bill Widnall, P. White, Willman, Craig Work, Saydean Zeldin.
  
  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!)
    
  • (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 4 CM AGC software was a team effort:

• 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:


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

---