Virtual AGC FAQ Page

If you have AGC/AGS information you'd like to contribute, you could do so by contacting me directly. However a more straightforward approach may be to contribute your knowledge to the wiki. Examples of things that are useful are theoretical discussions, historical information or anecdotes, tutorials on how to perform certain tasks with the AGC or AGS, etc. Editing of the wiki is members-only, and you will find instructions for requesting membership at the link just given. Yes, this is a hassle, but it's a one-time thing and it helps to keep the wiki reliable.

Is there a mailing list for this project?

There is! If you'd like to subscribe, changes the preferences of your existing subscription, or unsubscribe, go to

lists.ibiblio.org/mailman/listinfo/apollo

I expect this to be a very low-traffic mailing list, devoted to very technical questions, if my own inbox is any indication. :-) However, as with any mailing list, you're taking your chances. It's a members-only mailing list, so hopefully you'll be spammed by it only if spammers spoof the email address of existing members. Also, there are various options you can set for your subscription, such as concealing your email address from the group. (I think I'd still be able to find out your email address, since I administer the list, but you'd just have to live with that.)

You might also want to look at Orbiter NASSP's Virtual AGC mailing list, where they seem to be making great progress on the practical details of actually using the AGC for running simulated missions. Highly recommended if you're more interested in running the AGC rather than understanding its guts!

Wow, where did you get all this material, and how can I find some too?

If you want to collect AGC documentation and software in a secret shrine where you can admire it without sharing the content with anybody else, please don't. Sometimes you can find this stuff on eBay. There are also auctioneers who buy and sell this stuff. Obviously, we (Virtual AGC) can't afford to buy it there or anywhere else, but if you find yourself doing so please consider sending us a digital copy. The value of your collectable won't be dimished and you'd be doing a public service.

Sadly, a lot of information that would be very helpful for this project does not seem to be publically available on the Internet. For example, where is a dimensioned drawing of the DSKY? What connector types were used for feeding external signals to the AGC, what was the pinout of the connectors, and what were the electrical characteristics of those signals? Where are additional source-code versions of Luminary or Colossus ... or of Sundance (alternate CM software)? (I could go on like this all day.) Alas! I don't know the answers to these and many other questions. One can only hope that the materials still exist somewhere and may become available someday. If you would like some hints about where this kind of information may be lurking, click here.

Fortunately, just enough information has been readily available to allow development of Virtual AGC. All of the materials we've collected are available from our document library page.

I have some of the documentation you need, but what can I do with it?

A pretty complete description of the available options can be found on our "how to digitize" page.

Is this project affiliated somehow with NASA, or Draper Labs, or TRW Aerospace, or IBM, or ... are any former Apollo workers involved?

No, not in terms of running it or providing any of the simulation software. However, in latter years it has been gratifying to see contributions of archived AGC documentation and program listings by various of the original AGC developers.

And who the heck are you, anyway?

Well, I'm not involved in the space program in any way. Professionally, I write embedded software for airborne devices. I have a number of other open-source projects, which you can read about (along with a more-extended write-up about me, Me, ME!) at my main website.

And yes, somebody really did ask this.

Why waste so much time on a project that may be of interest to 3 geeks somewhere?

Placing men on the moon is one of the greatest accomplishments of the United States of America. It is arguable, indeed, that it is the greatest accomplishment (of any kind) in the history of the human race. If so, perhaps it makes sense to preserve the relics of the Apollo project. (Besides, I'm one of the 3. )

I got the idea while watching the movie Apollo 13. The instant in the movie where the AGC is powered up on Earth approach is the instant when the viewer suddenly feels that survival of the astronauts has changed from "highly unlikely" to "very probable". It gives me a chill whenever I see it. Anyhow, on watching this one day, it struck me that it was a shame nobody knew any longer how to operate the AGC—let alone write the programs for it. (As it happens, that thought was a bit premature: only 35 years had passed since the AGC software was written, thus many of the original software developers were still reasonably young. Nevertheless, the principle is correct, since very few people could use or program the AGC.)

Anyway, it then occurred to me that it would be cool to bring the AGC back to life, and to allow anyone so inclined to use it or program it ... assuming, of course, that sufficient publically information was available to do so. As it quickly turned out, there was enough information publically available, though just barely enough. The project turns out to be an interesting experiment in digital archaeology.

News flash: I found a couple more geeks, bringing the total to 5. Here's their website, where they're doing almost the same thing as me, inspired (no less) by From the Earth to the Moon.

Later news flash: I've found still more geeks. Let's just assume that the total is around 100 and do away with these further news flashes!

Tom Hanks, Wherever You Are, Call Me!

I jest, of course. But I suspect that if Tom Hanks (a well-known space buff) had an assistant make a few judicious telephone calls to people hoarding the AGC-related information we need to advance this project, it could accomplish more in a few hours than years of knocking on doors by me has accomplished.

If you know someone like Tom (or know someone who knows someone like Tom) who might be sympathetic, pass the word along to them.

What's with the "ya" stuff all over the place?

Computer programmers are aware—though Apollo enthusiasts may not be—that "ya" is often added to computer program names to mean "yet another". Thus, yaYUL is "yet another YUL", yaDSKY is "yet another DSKY", and so on.

What's the deal with "verbs" and "nouns"?

The following amusing (if not necessarily helpful) comment may be found in the source code of the keyboard and display program (otherwise known as "pinball"):

THE FOLLOWING QUOTATION IS PROVIDED THROUGH THE COURTESY OF THE AUTHORS.

"IT WILL BE PROVED TO THY FACE THAT THOU HAST MEN ABOUT THEE THAT
USUALLY TALK OF A NOUN AND A VERB, AND SUCH ABOMINABLE WORDS AS NO
CHRISTIAN EAR CAN ENDURE TO HEAR."
HENRY 6, ACT 2, SCENE 4

It turns out, though, that the authors' literary skills didn't quite match their programming skills, as this quote is really from Henry VI, Part 2, Act IV, Scene VII. (Thanks to Frank O'Brien of the Apollo Flight Journal and Apollo Lunar Surface Journal for this correction.) By the way, if you take it upon yourself to actually read the play to figure out the context, you may find yourself reading about "a Nowne and a Verbe" rather than "a noun and a verb".

Original AGC hardware developer Ramón Alonso provides a little more insight: Apparently, nobody had yet arrived at any kind of software requirements for the AGC's user interface when the desire arose within the Instrumentation Laboratory to set up a demo guidance-computer unit with which to impress visitors to the lab. Of course, this demo would have to do something, if it was going to be at all impressive, and to do something it would need some software. In short order, some of the coders threw together a demo program, inventing and using the verb/noun user-interface concept (in the whimsical fashion seen in much of this code), but without any idea that the verb/noun concept would somehow survive into the flight software. As time passed, and more and more people became familiar with the demo, nobody got around to inventing an improvement for the user interface, so the coders simply built it into the flight software without any specific requirements to do so.

However, that does not mean that the verb/noun interface was universally beloved. Ramón says that many objections were received from naysayers, such as "it's not scientific", "it's not dignified", or even "astronauts won't understand it". Even though the coders of the demo hadn't seriously intended the verb/noun interface to be used in any permanent way, it became a kind of devilish game to counter these objections with (perhaps) sophistic arguments as to why the interface was really a good one. In the end, the coders won. I don't know whether they were elated or dismayed by this victory.

The astronauts, of course, could understand the interface, but they did not like it. Most of them really wanted an interface much more like that they had used in aircraft: i.e., lots of dials and switches. Dave Scott is the the only astronaut I'm aware of who had kind words for it (or for the AGC in general), though we are told that Jim McDivitt wasn't necessary completely hostile to it.

Why Isn't More Information Provided About Why the Guidance System User Interface Was Like it Was?

A lot of thought about usability went into the design of the guidance system, much more so than the story above about verbs and nouns would indicate. Questions like what kinds of controls needed to be provided, or even where those controls would be physically located, were extremely important (Thanks to George Silver for pointing this out.) Sadly, I don't know anything about these topics, and that's why I don't cover them here.

Tell Us More Amusing Stories

Well ... maybe just a couple more.

The story of the 1201 and 1202 alarms on the descent by Armstrong and Aldrin to the lunar surface during Apollo 11 is well known. (If you don't know it, the astronauts received repeated alarms from the AGC of type 1201 and 1202 -- 5 alarms in all, if I'm not mistaken. On each alarm, the question was raised as to whether to continue or to abort. Obviously, they continued.) I'm informed that the representative from the MIT Instrumentation Lab who was present to be consulted by Mission Control was Russ Larson. When consulted on the go/no-go question, Larson simply gave a "thumbs up" signal. When asked years later why he had done this, he said simply that he was too scared to speak. (Thanks to Allan Klumpp for this story.)
And continuing on the topic of the 1201/1202 alarms in Apollo 11: These alarms were caused by the fact that during the landing, both the landing radar and the rendezvous radar were turned on. Only the landing radar actually needed to be active, but it was felt by some that having the rendezvous radar turned on would be useful in case of a sudden abort. What wasn't known was that this extra load on the AGC CPU would cause it to run out of processing cycles. The software would work all right at first, but eventually the loss of about 15% of the CPU cycles due to processing the excess radar data would cause some tasks to be spawned before earlier instances of those tasks had completed running. Eventually, because of the duplication of tasks, the software would be unable to allocate the memory needed to spawn new tasks, and would need to restart. Fortunately, the cunning design of the software allowed the software to basically continue executing at the same point where it had been before restarting, and so it could continue operating normally until it ran out of memory again. Eldon Hall likes to point out that this is a success of the AGC rather than a failure (as some other people like to say). At any rate, Allan Klumpp coded a workaround for this problem in time for the Apollo 13 mission, but the powers-that-be declined to use the new software. Klumpp was upset enough about this to contact the mission commander, Jim Lovell, and describe why the new software (Luminary 131) would be so much better than the old. The next morning, Dick Battin dropped by Klumpp's office and announced, "Allan Klumpp, your political savoire-faire has descended to a new low!" That was his way of saying that Luminary 131 would be used on Apollo 13 after all, because Jim Lovell wanted it.
The original source code for the AGC assembler program called "YUL" isn't presently publicly available, though I expect it will be soon, and I'll link to it when it is. However, here is a scan of pages 2 and 3 of the listing for YUL. Please examine it closely. I needn't comment further.
Not an AGC story, but I like it: I'm told that one of the perks of writing software at MSC in the Apollo era was taking the coding sheets to the 'swamp' for the keypunch operators to build the card decks to be taken to the computer center. The 'swamp' was a tiered auditorium with many young women at keypunch machines on the tiers. Of course, the young engineers would enter the room at the front at what was the focus of the tiers, feeling a little like a bull at the rodeo auction. Apparently, this was a good way to meet bored young women in need of stimulation. This is a case, obviously, where progress has been in completely the wrong direction. (Thanks to Paul Schlein for this story.)
When the disks containing the Apollo 11 assembly listings arrived (May 2009), the shipping clerk who handed the box to me asked if it contained a software update. I informed him that it did. That it was a very old software update ... in fact, perhaps the oldest software update in the history of the world. And you know what? I think it may actually be true.

Wouldn't it be better to incorporate Virtual AGC into a flight simulation or lunar landing simulation?

Yes. I would strongly encourage it. But it's outside of my personal limits, workload-wise. If you want to work on that, I may be able to connect you to other people who are also interested in doing so.

If you do want to work on this, I'd strongly advise that you use (or adapt and improve) the socket-based interconnect model I've provided and described on the developer page (so that yaAGC can be used as a stand-alone program), rather than trying to cut-and-paste yaAGC code into the flight-simulator. Remember that even though Virtual AGC is free of cost, you are still bound by the licensing provisions of the General Public License (GPL); in other words, there are consequences for misuse of the code. If, for example, you insert yaAGC code into a flight simulator, then that flight simulator must also be open-sourced under the GPL, or else I would have to grant you a special exception to the license. (For example, I have granted such an exception for the Orbiter program. See below.) On the other hand, if you use yaAGC as a stand-alone program that merely communicates with the flight simulator, then there is no such problem. Remember also that Virtual AGC is a work-in-progress, and if you insist on customizing yaAGC itself, you will have to carefully consider what you intend to do when I improve it without consulting you, and you have no way to merge the changes.

Work to integrate Virtual AGC into the Orbiter spacecraft simulator has proceeded marvelously. There is a Sourceforge project, complete with working code and documentation such as installation instructions.

I'm told that integration into FlightGear is proceeding well also, though I have not heard anything about it for several years.

How come the stuff the simulation can do is so trivial?

It takes more than just a computer to fly an Apollo LM or CM. At the very least, you need simulations of the spacecraft's IMU, AOT, and of the physical spacecraft (i.e., acceleration, torque, fuel usage, etc.). Maybe we'll have those things, one of these days. The LM-Simulator module has made a good start towards providing some of these things.

It doesn't work! How do I make it work?

It's Too Slow!

At the moment, Virtual AGC consists of two parts: the core programs (like yaAGC, yaDSKY, etc.) and the contributed LM-Simulator program. I separate them because very different techniques and tools were used for creating them, so they don't contribute to slowing down you computer in the same way. Furthermore, the contributions of the various parts are different on different platforms. Here are some approximate timings I've made using the 20050716 development snapshot:

CPU	Speed	Operating System	CPU Utilization
			Core Programs	LM-Simulator		Total
			Core Programs	Without Rotation	With Rotation	Total
Intel P4	2.8 GHz	Windows XP Home	0-3%	65-70%	>95%	65-100%
Intel P4	2.53 GHz	Linux	0-3%	35%	40-45%	35-45%
G3	450 MHz	Mac OS X	50%	60%	90%?	110-140%

While the benchmarks above are very far out of date technology-wise by now, they are still somewhat instructive. What you'll notice, undoubtedly, is that the simulation is going to need a relatively modern system to run all of the bits and pieces. If you don't have a fast enough CPU, it doesn't observably affect the core programs, but has the symptom that LM-Simulator slows to a crawl, and responds increasingly slowly as time goes on, because the backlog of unprocessed data increases.

So what is to be done about this? Well, I'm sure that over time we'll be able to improve the speed of these programs, but that's not of any immediate help to you. One thing you can do immediately, assuming you have the resources, is to take advantage of Virtual AGC's client-server architecture. You can do things like running LM-Simulator on one computer, and the core programs on another computer. Splitting up the bits and pieces this way has the additional advantage (if each computer has its own monitor) of making it easier to see all of the various controls without having them obscure each other.

Of course, if you're so inclined, you could also roll up your sleeves, pitch in, and help us figure out how to speed up the simulation programs.

Troubleshooting Running the Simulation

Various things to to look out for are found in the quirks list, but here's a separate, supplemental list just to make it even more confusing:

If you're running the simulation by separately running yaAGC and yaDSKY rather than through the VirtualAGC GUI, remember that the two programs have to be run from two different command-line windows. A reason why you might want to do this is that on some slow Win32 systems, there are some timing problems if the startup scripts are used.
VirtualAGC enforces a certain ordering in the way the various components of the simulation start up. If you bypass VirtualAGC, you should note that there some are some quirks in the startup and shutdown ordering of yaAGC and yaDSKY. If you don't stick to my recommended ordering, you will probably encounter problems. In Win32: You can't start peripherals before you start yaAGC; if you do, the programs will not be able to communicate amongst themselves. In Linux (pre-20050131): You can't terminate yaAGC before terminating peripherals; if you do, there will be a timeout (which may be a minute or two) before the operating system allows the port connecting the simulated CPU and peripherals to be reused. (In Win32, command "netstat -a" --- or in Linux, the command "netstat -a | grep 19697" --- is useful for detecting this condition.) The startup/shutdown procedure I'd recommend for both platforms is:

Start yaAGC.
Start all peripherals (like yaDSKY).
Use to your heart's content.
Stop all peripherals (like yaDSKY).
Stop yaAGC.

Startup of the LM-Simulator component, which is written in the Tcl/Tk scripting language, has always been problematic: If it doesn't connect within a certain limited time, it will abort, and if the simulation is being run from the VirtualAGC GUI it will generally cause the entire simulation to abort. One thing that seems to help is to delay startup of LM-Simulator for several seconds, to insure that yaAGC is up and waiting for connections before LM-Simulator even tries to connect.
The main place (I think/hope) where things could go wrong would be in the TCP socket interface connecting yaAGC and yaDSKY. If some other service on your computer was already using port 19697—if, for example, you were simultaneously running two copies of yaAGC or yaDSKY—then there could be a problem. You can check this by closing out all instances of yaAGC and yaDKSY (in Win32 with ctrl-alt-del, or in Linux with "killall -KILL yaDSKY" and "killall -KILL yaAGC"), and then trying this: "telnet localhost 19697". If telnet says it connected to something, then you definitely have another service using this port, and you can work around it with the --port command-line switch of yaAGC and yaDSKY to choose a new port. If not, then you probably don't, and that's not the cause of your problem.

Another possibility, I suppose, is that you may have a personal firewall installed which is blocking port 19697. In that case, you'll have to reconfigure the firewall.
Perhaps your computer is not even set up properly for networking, which is necessary for any of the socket-based communications to work. For example, you may not have an Ethernet card. These comments from Joe Durnavich (thanks Joe!) may help if you have this problem and you're using Linux.

How do I Uninstall this Thing?

On Linux or Windows, an uninstaller program is provided when the installer program is run. Alternately—if installed on Mac OS X or from source code—simply remove the installation directories which were created. Unless you've renamed them, these will be folders with names like "yaAGC/" (dev snapshot), "VirtualAGC/" (Linux binaries), "Virtual AGC\" (Windows binaries), or "VirtualAGC.app/" (Mac OS X binaries. On very old versions, in Linux or Mac OS X, the installation directory might have been "~/.yaAGC".

I'm drowning in Alphabet Soup! What does it all mean?

ACA	Attitude Controller Assembler---the LM's hand-controller for pitch/roll/yaw adjustments.
AEA	Abort Electronics Assembly.
AGC	Apollo Guidance Computer
AGS	Abort Guidance System---a separate computer aboard the Lunar Module
AOT	Alignment Optical Telescope. Telescope used to make star sightings. By monitoring the orientation of the telescope, the AGC could compute the orientation of the spacecraft and use this information to calibrate the IMU (see below).
CM	The Command Module---i.e., the capsule.
CMC	Command Module Computer---i.e., the AGC in the CM.
CSM	The combined Command and Service Modules.
G&N	Guidance and Navigation
GNCS	CM G&N Control System---i.e, the AGC plus G&N measurement and control devices.
IMU	Inertial Measurement Unit. This a stable platform (i.e., retains its orientation with respect to the fixed stars rather than to the spacecraft) containing accelerometers. By monitoring the accelerometers and the orientation of the platform with respect to the spacecraft, the AGC can compute the orientation of the spacecraft, as well as its position, velocity, and acceleration.
LGC	Lunar Guidance Computer---i.e., the AGC in the LM.
LM	The Lunar Module---i.e., the lunar lander.
LVDA	Launch Vehicle Data Adapter
LVDC	Launch Vehicle Digital Computer
PGNCS	("Pings".) The LM Primary G&N Control System---i.e, the AGC plus G&N measurement and control devices.

Are there other websites I should look at?

There are lots of online sites with worthy Apollo-related resources, though not necessarily specializing in the AGC. Some terrific ones are listed below, in no particular order.

De la Terre à la Lune. This site is in French, but you don't have to speak the language to admire that amazing Apollo-related graphics and videos presented there.
spacecraft.it. Fabrizio Bernardini (whose help I've acknowledged in a number of places on the Virtual AGC website) has put together this spacecraft-related site. It's only in its beginning stages, and isn't devoted to Apollo exclusively, but does have Apollo-related (and specifically AGC-related) material on it. Not to mention the fact that it's pretty sharp looking!
history.nasa.gov. Many valuable Apollo technical drawings and other references. The following links were particularly valuable for me:

Apollo Designations.
Chapter 2 of Computers in Spaceflight: The NASA Experience, by James E. Tomayko, March 1988.

www.klabs.org. The NASA Office of Logic Design has various interesting AGC-related documents online. There's not a lot of unique content yet, but strides are being made and it looks like there soon will be, so it's worth checking out.
bobandrepont/spacepdf.htm. A site which links an interesting collection of Apollo (and Mercury, Gemini, and shuttle) docs from a diverse set of websites.
www-lib.ksc.nasa.gov/lib/presskits.html. The Kennedy Space Center Library has press kits for all of the missions.
apollo.spaceborn.dk/dsky-sim.html. A very nice Apollo site, with the highlight (for my purposes) being a simple little Javascript emulation of a DSKY.
www.apollosaturn.com. Lots of useful miscellaneous info, including spacecraft photos.
www.jsc.nasa.gov/history. This site doesn't contain any actual materials of interest to Virtual AGC, as far as I can tell, but it's very useful in figuring out where existing records from Apollo are physically located.
perso.wanadoo.fr/max.q/main.htm. An excellent general-purpose Apollo site with some unusual miscellaneous information (such as Block I DSKY photos). You need to read French, though, which I unfortunately do not.
www.hq.nasa.gov/alsj/a15/a15.CMsoftware.html. The Apollo 15 Lunar Surface Journal site has this very interesting manual by Delco, covering many aspects of the Apollo 15 mission, but (in particular) computer operation. Thanks to Mark Grant for pointing this out.
klabs.org/mapld04/papers/p/p202_portillo_p.pdf. An excellent paper by José Portillo Lugo, describing everything you may ever want to know about the LM's hand-controller, and how it interacts with the AGC.
"Tales from the Lunar Module Guidance Computer", transcript of a terrific talk by Don Eyles, covering the infamous Apollo 11 1202 alarms, the Apollo 14 solder-ball incident, and more.
And last, but not least, the Apollo Lunar Surface Journal and Apollo Flight Journal(s). But I imagine that anybody who has managed to find their way here already knows all about them anyhow.

Here are sites of some folks who are doing pretty much the same kind of stuff as I am:

John Pultorak has recreated a working Block I AGC, has recreated some of its software and back-ported some Block II software to it, and offers us instructions for doing the same. Must see!
www.cems.uwe.ac.uk/~jtwebb/agc/, by Julian Webb. Click here to see Julian's abstract for the September 2004 MAPLD conference.
www.calsoft.de/~christian/AGC/, by Christian Bucher et al.

Here are links to some apparently pretty realistic full-feature LM simulations, but (of course) without true AGC simulations except insofar as efforts have been made to integrate Virtual AGC with them. (I've not tried any of them myself, except for briefly messing with Orbiter.)

eaglelander3d.com/. The home of Eagle Lander 3D, a lunar-lander simulator, freeware as of this writing, but with a commercial version planned.
ourworld.compuserve.com/homepages/IvanScheers/Index.htm. The home of the ISIS lunar-lander simulator.
www.medphys.ucl.ac.uk/~martins/orbit/orbit.html. The home of the freeware Orbiter space-flight simulator. There is an Apollo add-on for Orbiter, called "NASSP", and there is work being done to integrate Virtual AGC into the CSM portion of the NASSP add-on, started by Mark Grant and continued by Markus Joachim. Apparently, that work is at or near a usable (if not complete) state, which in my (admittedly prejudiced) view is very cool. Here is the latest word I have on it from Markus (with a little editing from me):

I just want to inform you that I finally released my stuff "Virtual Apollo". It's available at SourceForge together with it's "parent Orbiter add-on" called "Project Apollo - NASSP". You can find it here: http://sourceforge.net/projects/nassp/. The Virtual Apollo documentation is also available online: Look here http://nassp.sourceforge.net/ and click the "Virtual Apollo - The Virtual AGC integration" link.

With "I finally released my stuff" I don't mean [that the integration of Virtual AGC] is finished or that this is the final release.... :-). My stuff isn't finished; the IMU is working fine, but optics, RCS, the DAP and so on are still missing.... [Later] I plan to do a tighter integration of the Virtual AGC in Project Apollo.... But I suppose it will be months (or years) until all this is finished. Perhaps Mark Grant will help with that; more help, any comments or suggestions are welcome. ;-)

Project Apollo - NASSP is not only an Apollo CSM add-on but it contains the complete Apollo missions including a fully functional LM, mission specific textures, the Skylab, the Saturn 1b missions... A really huge add-on! But "Virtual Apollo" covers only the CSM and there only lift-off and earth orbit insertation.

Update: I've also received the following comments from Mark to indicate that the integration effort continues to make great progress:

I now have the AGC functioning up to orbit and outputting something resembling the correct numbers on the DSKY.... Actually, we are [working on an LM simulation also]. The Virtual Apollo release only had the Saturn V, but we've also got the Saturn 1b and LEM. The LEM AGC is up and running the Luminary code, but currently doesn't do much other than P00.

www.flightgear.org. The home of the FlightGear flight-simulator.

Emulators for other spacecraft-borne computers, such as the Gemini flight computer, the Apollo LM Abort Guidance System (AGS), the Apollo launch vehicle inertial guidance system (LVDC), or the shuttle computer (4pi AP101).

Gemini flight computer, as an add-on for Orbiter. The computer portion of this project is still (as of 2004-09-13) in the planning stages, due to a lack of hard information on the computer. However, there are already some great scanned Mercury and Gemini docs, such as a Gemini computer user manual, Gemini spacecraft manuals, Agena command set, and so on. Write directly to Robert Conley if you have additional documentation or source-code for the Gemini computer, or useful contact information.

... And some folks who are doing nothing relevant, but cool and possibly interesting to anybody interested in Virtual AGC.

The Druantia Project, an attempt to create "a 1:1 scale (in terms of both size and resolution) working model" of the entire planet of Mars. Gosh!

Tools used in developing for Virtual AGC. Modern Linux distributions typically provide all of the tools needed, if not in a default installation at least in the distribution's package system for painless download. Win32, in contrast, provides none of them. (Hey, folks, they're free. It wouldn't cost Microsoft anything to provide them.) Mac OS X is somewhere in between.

Tool	Linux	Win32	Mac OS X	UNIX & BSD
GNU gcc, make, etc.	Provided automatically by almost all Linux distributions.	www.mingw.org	Apple developer CD, or download from www.apple.com.	Often provided automatically. Note that although GNU tools are assumed (www.gnu.org), native tools may work also.
wxWidgets cross-platform GUI toolkit for building VirtualAGC, yaDSKY2, yaDEDA2, and yaACA2.	Provided automatically by many Linux distributions. Otherwise, download from www.wxwidgets.org	Download from www.wxwidgets.org	Provided in Mac OS X 10.5, but you may need to update. The version provided in Mac OS X 10.4 is too early, so download from www.wxwidgets.org	If not provided, download from www.wxwidgets.org
gtk+ cross-platform GUI toolkit for building yaDSKY and yaDEDA. No longer needed for the yaDSKY2 and yaDEDA2 programs that have superceded yaDSKY and yaDEDA!	Provided automatically by many Linux distributions. Otherwise, download from www.gtk.org	www.gtk.org	Install using fink	Sometimes provided automatically. Otherwise, download from www.gtk.org
Optional glade GUI builder for gtk+. No longer needed for the yaDSKY2 and yaDEDA2 programs that have superceded yaDSKY and yaDEDA!	Provided automatically by many Linux distributions. Otherwise, download from glade.gnome.org	glade.gnome.org	(Don't know.)	Sometimes provided automatically. Otherwise, download from glade.gnome.org
Thread library.	(Not needed.)	POSIX Threads for Win32	(Not needed.)	(Not needed.)
Allegro cross-platform GUI toolkit for building yaACA. No longer needed for the yaACA2 program that has superceded yaACA!	Provided automatically by some Linux distributions. Otherwise, download from alleg.sourceforge.net	alleg.sourceforge.net	alleg.sourceforge.net	May be provided automatically. Otherwise, download from alleg.sourceforge.net
bzip2 for unpacking development snapshots.	(Not needed.)	sources.redhat.com/bzip2/	(Not needed.)	(Not needed.)
tar for unpacking development snapshots.	(Not needed.)	www.gnu.org/software/tar/tar.html	(Not needed.)	(Not needed.)
Tcl/Tk scripting language for LM_Simulator.	www.tcl.tk/

What books and movies do you recommend?

Books

The Apollo Guidance Computer: Architecture and Operation, by Frank O'Brien. Chichester, UK: Springer/Praxis Publishing, 2010. The title says it all. I think you'll find this to be a very readable book, somewhat like a much kinder, gentler form of this website in terms of the material presented. Conversely, some of the material on this website came from Frank originally, so I guess what goes around comes around. Good job, Frank!
Journey to the Moon: The History of the Apollo Guidance Computer, by Eldon Hall. Reston, Virginia: American Institute of Aeronautics and Astronautics, 1996. If you're at all interested in the stuff on my website, buy this book and read it. It's much more technical than you probably imagine from the title. I have an autographed copy, purchased from the author. The sign on the table read, roughly, "Signed by the author -- $50. Unsigned -- $55." (And no, that's not a misprint. Either price was a bargain compared to amazon.com, so I cleverly bid it up to $60.) Also, you should read Hugh Blair-Smith's annotations to the book.
This New Ocean, by William E. Burrows. New York: Random House, 1998. A very comprehensive and seemingly authoritative history of the space program up to 1998.
Carrying the Fire: An Astronaut's Journeys, by Michael Collins. New York: Copper Square Press, 1974. Very funny.
Deke! U.S. Manned Space: From Mercury to the Shuttle, by Donald K. "Deke" Slayton with Michael Cassutt. New York: Forge, 1994.
The Last Man on the Moon, by Eugene Cernan and Don Davis. New York: St. Martin's Griffin, 1999.
A Man on the Moon, by Andrew Chaikin. New York: Penguin Putnam, 1994. Upon which From the Earth to the Moon (see below) is partially based.
Moon Lander: How We Developed the Apollo Lunar Module, by Thomas J. Kelly. Washington: Smithsonian Institution Press, 2001.
Flight: My Life in Mission Control, by Chris Kraft and James Schefter. Penguin Putnam, 2001.
Failure is Not an Option, by Gene Kranz. Berkley Books, 2000.

Video

Apollo 13, Universal Studios.
From the Earth to the Moon, HBO Home Video.
Spacecraft Films has a series of DVD-sets containing the films, television transmissions, still photos, and numerous other materials for various missions---Apollo 8, 11, 15, 16, and 17 as of this writing. I've seen the Apollo 11 and Apollo 15 sets, and would recommend them for enthusiasts (but not for the friends and families of enthusiasts). The Gemini films, on the other hand, seem extremely compelling. One reader, Eugene Dorr, writes with rave reviews about a video called "Mission to the Moon", which is a 2-DVD set of documentaries; the star of the show (he tells us) is a half-hour film called "Computer for Apollo", which includes a demonstration of the AGC, as well as "a totally engrossing demonstration of how the AGC was manufactured." I guess I should go an buy it myself, right now!
In the Shadow of the Moon is a terrific documentary by David Sington on the various lunar missions, consisting principally of interview material with a large number of Apollo astronauts. It doesn't really have anything to do with the AGC, but I'd recommend it highly anyway.
The AGC (and other) episodes of the Science Channel series "Moon Machines". This has lately also become available on DVD.

Is the moon landing a hoax?

Yes, though I've removed all references to the hoax from the Luminary and Colossus source code. (Joke!)

But I must congratulate those 1960s tricksters on their attention to detail, such as seeding copies of software listings for various versions of the AGC software in people's homes, museums, and what-not, so as to send me on expensive merry chases to find them and make them publicly available 40 years later. And to do it in such a way that with my dull, cowlike mentality I can't perceive the fakery in it. Usually it takes a beautiful woman or somebody waving a fistful of dollars at me to deceive me so badly. I mean, the gosh-darn software actually works when you run it! You really have to admire the level of commitment those evil geniuses had back then. I doubt that today we even retain the skills to fake anything so thoroughly. That's why former President Bush's bravado about (faking) a return to the moon or visit to Mars is doomed to failure. :)

But seriously, I've found the blog of some thinker who has used the existence of our Virtual AGC project itself as evidence that the moon landing was faked. His reasoning goes as follows: a) Virtual AGC simulates some Apollo hardware; b) therefore, it is possible to simulate Apollo missions; and c) therefore Apollo missions were fake 40 years ago.

Well, you hardly need Virtual AGC as a step in that reasoning, since lots of people already know that the astronauts trained extensively in simulated spacecraft. The simulators being used in the 1960s and 70s were far better and more accurate than our 21st-century software-only simulations.

How can the Virtual AGC project be contacted?

Email to Ron Burkey <info@sandroid.org>.

Last modified by Ronald Burkey on 2010-08-11.