http://www.ibiblio.org/apollo/index.html


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


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

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

Because we have much more information about the AGC than we do about the AGS and LVDC, 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 and the LVDC page of the 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 Elements

  • (Planning only) yaLVDC, an emulation of the LVDC CPU.
  • (Speculation only) yaASTEC, a program for feeding simulated spacecraft sensor inputs to yaLVDC and observing yaLVDC outputs.
  • (Planning stage only) yaLVDCASM, an assembler for the LVDC assembly language.
  • (Speculation only) Newly written LVDC source code for implementing the documented guidance equations. Note that there is no known existing copy of true LVDC source code, or else we wouldn't need to write new code for it!
  • Scans of all known existing LVDC 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.