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.
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?
Is this site mirrored anywhere?
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
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
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 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
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
I have some of the documentation you need, but what can I do
Is this project affiliated somehow with NASA, or Draper Labs, or
TRW Aerospace, or IBM, or ... are any former Apollo workers
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
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
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
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
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
project turns out to be an interesting experiment in digital
: 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
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
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
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
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.
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
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
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
(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
well also, though I have not heard anything about it for several
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
module has made a good start towards providing some of these
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
, etc.) and the
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:
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
Troubleshooting Running the
Various things to to look out for
are found in the quirks
, 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
- 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?
Assembler---the LM's hand-controller for pitch/roll/yaw
|Abort Electronics Assembly.
|Apollo Guidance Computer
|Abort Guidance System---a
separate computer aboard the Lunar Module
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
|The Command Module---i.e.,
Computer---i.e., the AGC in the CM.
|The combined Command and
|Guidance and Navigation
|CM G&N Control
System---i.e, the AGC plus G&N measurement and control
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.
Computer---i.e., the AGC in the LM.
|The Lunar Module---i.e., the
|Launch Vehicle Data Adapter
|Launch Vehicle Digital
|("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.
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.
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
Many valuable Apollo technical drawings and other
references. The following links were particularly valuable
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. (Now a zombie for all practical
purposes, unfortunately, and hopefully most of significant
AGC-related content has migrated here.)
collection of Apollo (and Mercury, Gemini, and shuttle) docs
from a diverse set of websites.
press kits for all of the missions. (Now moved
somewhere else, I guess.)
A very nice Apollo site, with the highlight (for my
DSKY. (Now defunct.)
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.
some unusual miscellaneous information (such as Block I DSKY
photos). You need to read French, though, which I
unfortunately do not.
- "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
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.)
The home of Eagle Lander 3D, a lunar-lander
simulator, freeware as of this writing, but with a commercial
The home of the ISIS
lunar-lander simulator. (Now defunct or renamed
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):
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).
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
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
|UNIX & BSD
|GNU gcc, make, etc.
automatically by almost all Linux distributions.
developer CD, or download from www.apple.com.
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
No longer needed for the yaDSKY2
programs that have superceded yaDSKY and yaDEDA!
|Provided automatically by many Linux
distributions. Otherwise, download from www.gtk.org
||Install using fink
||Sometimes provided automatically.
Otherwise, download from www.gtk.org
builder for gtk+.
No longer needed for the yaDSKY2
programs that have superceded yaDSKY and yaDEDA!
|Provided automatically by many Linux
distributions. Otherwise, download from glade.gnome.org
|Sometimes provided automatically.
Otherwise, download from glade.gnome.org
Threads for Win32
|Allegro cross-platform GUI
toolkit for building yaACA.
No longer needed for the yaACA2
program that has
|Provided automatically by some Linux
distributions. Otherwise, download from alleg.sourceforge.net
||May be provided automatically.
Otherwise, download from alleg.sourceforge.net
|bzip2 for unpacking
|tar for unpacking
|Tcl/Tk scripting language for LM_Simulator.
What books and movies do you recommend?
Brains for the Right Stuff: Computers, Space, and History,
by Hugh Blair-Smith. A terrific book, not to be missed!
- 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,
- 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.
- Apollo 13, Universal
- 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
- 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
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
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
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
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
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?
Last modified by Ronald Burkey on