Why Does it Say "ibiblio" All Over these Pages, and Yet the Site URL is "github" ... Maybe?

At the moment, there are two Virtual AGC websites.  Actually, it's even more confusing, as you may find the site referenced as any of the following:

What a mess!  The explanation is that the site is being developed in conjunction with our github repository, using the github website as a "staging area" for changes, and then the content is pushed to our ibiblio website afterward. We're trying an experiment in managing the site collaboratively rather than having me (Ron Burkey) continue to manage it as an individual, as well as tying the website more-closely to our github code repository.  It may eventually be an actual migration to github, though that's undecided yet.  In the interim, you can view either site more-or-less interchangeably. The github site is likely to be a little more up-to-date, but may have errors in it that need to be fixed before pushing the content to ibiblio.  You choose which you'd prefer.  Using the Google search bar on the pages will always return results about ibiblio and not github.

But there's no intention of abandoning ibiblio, regardless of the eventual URL of the website.  Only the web pages might move over to github.  The vast document library, page images of AGC assembly listings, and supplemental materials that people have sent me over the years will continue to be hosted at ibiblio.  At this writing, there's about 5.5GB of material that we will continue to host at ibiblio, and that's expected (hoped?) to continue to increase considerably in the future.

How can I help?

If you want to participate directly (in the sense of contributing effort), there are indeed some areas in which assistance would be helpful.

Is this site mirrored anywhere?

The Virtual AGC website is mirrored at http://apollo.josefsipek.net/.  Thanks, Jeff!

Is there a Wiki for this project?

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.  You may be required to register ... but I'm not sure exactly how it works.  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


Important note:  For whatever reason, the mailing list subscription form has been rejecting new subscribers with a message like "invalid capcha".  I have so far been unable to resolve this with ibiblio.  If this happens to you, email me directly (at the address at the bottom of this page), and I will manually subscribe you to the list.

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!  Unfortunately, I never seem to be able to find it myself from one time to the next, so I don't have a handy link to give you; you'll have to google it yourself.

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


                                           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.

I've Heard About the Block I and Block II Systems ... Is There a Block III Also?

No, never was, and never will be ... and you can read all about it at this link.

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:

Operating System
CPU Utilization
Core Programs
LM-Simulator Total
Intel P4
2.8 GHz
Windows XP Home
Intel P4
2.53 GHz
450 MHz
Mac OS X

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:

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?

Attitude Controller Assembler---the LM's hand-controller for pitch/roll/yaw adjustments.
Abort Electronics Assembly.
Apollo Guidance Computer
Abort Guidance System---a separate computer aboard the Lunar Module
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).
The Command Module---i.e., the capsule.
Command Module Computer---i.e., the AGC in the CM.
The combined Command and Service Modules.
Guidance and Navigation
CM G&N Control System---i.e, the AGC plus G&N measurement and control devices.
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.
Lunar Guidance Computer---i.e., the AGC in the LM.
The Lunar Module---i.e., the lunar lander.
Launch Vehicle Data Adapter
Launch Vehicle Digital Computer
("Pings".)  The LM Primary G&N Control System---i.e, the AGC plus G&N measurement and control devices.

What about GitHub Repositories?

At the time I'm writing this (July 2016), Chris Garry's AGC source-code repository has gotten a lot of press, and I've gotten some mail in regard to it.  I'm not involved with it, but my understanding is that it is clone of some of the AGC source files here at Virtual AGC, but with the distinction that Chris has an active group of volunteers (more active than here, anyway!) who are helping to track down discrepancies between those source files and the page-images we've made of the original printouts of those program listings.  The discrepancies are expected to relate entirely to comments in the source code and not to any actual software.  I'm not sure if that site has other activities or not.  At any rate, if that sounds interesting to you, check it out!

As it happens, Chris is neither the first nor the last to clone some or all of Virtual AGC, and you'll find a number of them at GitHub, and I'm not certain what most of them are for.  Just for clarification, however, our own (Virtual AGC's) official GitHub repository is

The previously-existing subversion repository at Google Code no longer exists other than in archival form, since Google Code ceased its normal operations.

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.
Here are sites of some folks who are doing pretty much the same kind of stuff as I am:
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.)
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.
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). 
... And some folks who are doing nothing relevant, but cool and possibly interesting to anybody interested in Virtual AGC.
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.

Mac OS X
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.

What books and movies do you recommend?



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.

Amusingly to me, the Virtual AGC project has also been used as a counter-argument to those who believe in the hoax theory.  I quite like a YouTube video in which a Microsoft Windows based compilation of our AGC assembler (yaYUL) is performed, and then yaYUL is used to assemble one of the Luminary or Colossus programs.  Too bad the demonstration stops short of actually running the simulated system.  The video is well worth watching, but I'm merely giving the link for rather than embedding the video itself within in this page, because there is an audio track that might startle those around you if you happened to be reading this page while on a break at your workplace.  Anyway, a claim had been made that Luminary and Colossus were not real programs, or something of that sort, and the demo video is supposed to debunk that by showing the the programs not only exist as scanned program listings, but can also be assembled.  Naturally, this was not very conclusive as far as the believer whose argument being debunked was concerned.

How can the Virtual AGC project be contacted?

Email to Ron Burkey <info@sandroid.org>

Last modified by Ronald Burkey on 2016-10-20.

Virtual AGC is hosted
              by ibiblio.org