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

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

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

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

	View the alarm codes	Because of some current bugs (07/19/04) in the way I initialize Colossus, there will be some program alarms at startup, and the PROG indicator will light to inform you of this.  You can view the alarms by keying in V05N09E at the DSKY.  (In normal AGC shorthand, 'V' is short for "VERB", 'N' is short for "NOUN", and 'E' is short for "ENTR".  So "V05N09E" means to hit the keys VERB 0 5 NOUN 0 9 ENTR.) Program alarms 1105 and 1106 happen to be "downlink too fast" and "uplink too fast".  Uplinks or downlinks refer to exchange of telemetry information with ground equipment.
	DSKY lamp test	At the DSKY, key in V35E.  This will light up all of the DSKY annunciators, flash the VERB/NOUN labels, and display 88 or +88888 in all of the numerical registers.  After about 5 seconds, the test stops—you can tell, because the flashing stops, though the numbers remain—and you can continue. When the accompanying screenshot was taken, I didn't yet know how the AGC controls the DSKY's STBY and RESTART indicators, so those weren't turned on by the test.  Because of a bug in the simulator (as of 07/19/04), the PROG indicator doesn't re-light after the lamp-test completes.  Therefore, you may or may not see the PROG indicator lit if you try the sample operations below.
	Display memory-bank checksums	The core-rope (read-only) memory is divided into 36 banks, numbered 00-43 (octal).  A so-called "bugger word" has been stuck at the end of each bank—yes, I get the joke, so please don't send me an explanation (and if you don't get it, don't ask me)—which causes the checksum of the bank to come out to a known value.  This known value is the same as the bank number when possible, and is the logical complement of the bank number otherwise.  (For example, the checksum of Colossus bank 00007 is 00007, but the checksum of bank 00006 is 77771.  Both are correct.)  Colossus's "show-banksum" program can be used to display the bank numbers, one by one.  You can execute the show-banksum program by keying in V91E on the DSKY.  After a few seconds, the statistics for bank 00 will be shown:  R1 (the topmost 5-digit display) will contain the computed checksum; R2 will contain the bank number; and R3 will contain the bugger word.  Each of the displays will be in octal, as indicated by the fact that the +/- sign is blank.  To advance to the next bank, key in V33E.  (Hitting the PRO key does the same thing.)  If you have the patience to advance through each of the banks, the next V33E (or PRO) after bank 43 will wrap-around to bank 00 again.  To terminate the show-banksum program, you can key in V34E. By the way, the bank-6  bugger word shown (05143) is for Colossus 249.  If you ran the Artemis 072 program, it would have been 04275, while if you ran the Luminary 131 program, it would have been 63402.
	Monitor the current time	If you key in V16N36E or V16N65E, it will cause the current time to be displayed.  (Since we haven't set the time in any way, this will be the time since AGC power-up).  R1 (the topmost 5-digit display) will be in hours, R2 will be in minutes, and R3 will be in 100ths of a second.  This display is updated once per second. In the accompanying screenshot, the time is 06:58:33.86.
	Setting the current time	If it annoys you to see the time since power-up, you can change the time (for example, to mission time) by keying in V25N36E.  R1 will go blank, enabling you to key in the current hour.  Make sure you start with a + sign (this is how the AGC knows you're using decimal rather than octal), and make sure you enter all five digits (including the leading zeroes).  In case you make a mistake, you can clear R1 any time before pressing ENTR by using the CLR key.  After you hit the ENTR key, R2 will clear and you can enter the current minutes.  Finally, you can key in the number of seconds in R3.  Don't forget that the number of seconds is actually in 100ths of seconds, so that if (for example) you want 30 seconds you'd key in +03000E. In the accompanying screenshot, it just happened to be 06:55:25 am., so that's how I set the clock.
	Examining the contents of the core-rope	Key in V27N02E.  This allows you to enter the address of a word in the core-rope into R3.  This address will generally be in octal, and therefore should not be preceded by a + sign.  Also, unlike entry of decimal data, in octal you can enter just as many digits as you need, and don't need to enter a full five digits.  The addresses will be 00000-01777 for memory bank 00, 02000-03777 for memory bank 01, and so forth, up to 76000-77777 for memory bank 37.  (I'm not sure how to examine banks 40-43.)  The binary listing of the core rope is at the very back of the Colossus 249 assembly listing, which can be downloaded from MIT if you have some spare time and disk space.  (See my links page.) In the accompanying screenshot, we see that address 4000 (octal) of Luminary's core-rope contains the value 00004.  This just happens to be the first instruction executed after power-up.  It is an INHINT instruction, and disables interrupts.  The contents of R2 (the middle 5-digit register) are not cleared, and thus are just whatever lingers from before.
	Examining the contents of erasable memory	Key in V01N02E.  This allows you to enter the address of a word in erasable memory into R3.  The addresses will be 00000-00377 for erasable bank E0, 00400-00777 for memory bank E1, and so forth, up to 03400-03777 for memory bank E7.  Alternately, you can "monitor" a memory location (i.e., get updates for it once per second) by using VERB 11 rather than VERB 01.  For example, V11N02E25E will monitor register 25, the "TIME1" register, which is an internal counter that increments every 10 ms.  In general, of course, the numbers won't mean much unless you reference them to the Colossus 249 assembly listing. In the accompanying screenshot, we actually do look at the TIME1 register, and discover that at that instant it contained the value 20245 (octal).  Of course, you'll see something different.  Display R2 is not changed, so it just contains whatever it contained before.
	Altering the contents of erasable memory	Key in V21N02E, and enter an octal address as above, and then enter a new value to be stored at that address.  It goes without saying that you need to know what you're doing when you do this! In the accompanying screenshot, I've chosen to reload the TIME1 register with the value 12345 (octal), which probably won't cause too many adverse effects.  Display R2 is not changed, so it just contains whatever it contained before.
	Fresh start	Key in V36E.  This apparently restarts the "pinball" program—i.e., the program that is responsible for accepting verbs and nouns and displaying stuff on the DSKY—and it's useful for clearing garbage from the DSKY's display, as the accompanying screenshot demonstrates. In the accompanying screenshot, a side-effect of the fresh start is the thoughtful re-display of the PROG (program alarm) which the earlier DSKY lamp-test had wiped out.
(Your picture here.)	Do-it-yourself research	The file yaAGC/Colossus249/ASSEMBLY_AND_OPERATION_INFORMATION.s lists the verb and noun tables, so perhaps you can figure out some neat stuff yourself.  If you do, let me know and I'll add it to this list.

Playing with Luminary

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.
   

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.
More later ... however, the operations listed above are very representative from the user-interface perspective of all the other kinds of operations you can perform on the DEDA.  There are basically two classes of DEDA-based operations: Get a running display of the contents of a memory location.  The command sequence for this is CLR OctalDigit1 OctalDigit2 OctalDigit3 READOUT.  Upon receiving this command, the AGS CPU will monitor the selected memory location and display it on the DEDA every 1/2 second.  You can pause the readout by hitting HOLD, or resume it by hitting READOUT again.  The flight software will automatically scale the data or otherwise modify it (by changing units of measurement) in a way appropriate to the particular memory location before displaying the data.  If you make a mistake in the key sequence, the OPR ERR lamp will light, and you'll have to hit CLR to clear the error condition. You can change the value of a location of memory.  In doing so, the flight software may choose to interpret your action as a command to perform some further action, but I'm not up to speed on what those other actions might be.  The command sequence is CLR OctalDigit1 OctalDigit2 OctalDigit3 +/- Digit1 Digit2 Digit3 Digit4 Digit5 ENTR.   The 5-digit data may be octal or decimal, but that is dependent on the particular memory location chosen, and isn't a choice that the astronaut/user makes.  Again, a mistake in the sequence will cause the OPR ERR lamp to light. Of course, there are operations the astronaut/user can perform that are outside of this framework, such as hitting the ABORT button or downloading the spacecraft state vector from the AGC.  However the abort button is a separate switch rather than being a part of the DEDA, and I've not perfected AGC-to-AGS communication yet.

Playing with AGC assembly language

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)

Final exam (for the advanced student)

... Or, for the silly mood

... Or, for the even sillier mood

Acknowledgements

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

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.

• 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

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