Virtual AGC — AGS — LVDC — Gemini
The Apollo Guidance Computer
A Kinder, Gentler Introduction
Introduction to the AGC
The Apollo spacecraft used for lunar missions in
the late 1960's and early 1970's was really two different
spacecraft, the Command
Module (CM) and the Lunar Module (LM).
The CM was used to get the three astronauts to the moon, and back
again. The LM was used to land two of the astronauts on the moon
while the third astronaut remained in the CM, in orbit around the moon.
Apollo 15 CSM (Command
and Service Modules)
Apollo 16 LM
Each of the spacecraft needed to be able to navigate through space,
with or without the assistance of the astronauts, and therefore needed
to have a "guidance system". The guidance system was developed by
MIT's Instrumentation Lab, now an independent company known as the Charles Stark Draper Laboratory.
An important part of the guidance
system was the Apollo Guidance Computer—or just "AGC" for short.
On any given Apollo mission, there were two AGCs, one for the Command
Module, and one for the Lunar Module. The two AGCs were identical
and interchangeable, but they ran different software because the tasks
the spacecraft had to perform were different. Moreover, the
software run by the AGC evolved over time, so that the AGC software
used in later missions like Apollo 17 differed somewhat from that of
earlier missions like Apollo 8.
Considered just as a computer, the AGC was severely underpowered by any
more-modern standards. The basic characteristics of the AGC were:
It is occasionally quipped—with perhaps greater wit than insight—that
the AGC was more like a calculator than
a computer. But to say this is to grossly underestimate the AGC's
sophistication. For example, the AGC was multi-tasking,
so that it could seemingly run multiple programs simultaneously.
- 2048 words of RAM. A "word" was 15 bits of data—therefore
just under 2 bytes (16 bits) of data—and so the total RAM was just 3840
- 36,864 words of read-only memory, equivalent to 69,120 bytes.
- Maximum of about 85,000 CPU instructions executed per second.
- Dimensions: 24"×12.5"×6".
- Weight: 70.1 pounds.
- Power supply: 2.5A of current at
Another important part of the guidance system was the Display/Keyboard
unit—or just "DSKY" for short. The AGC by itself was simply a box
with electrical connections, without any built-in way for the astronaut
to access it. The DSKY provided the astronaut with an interface
by which to access the AGC.
The Lunar Module had a single DSKY, positioned between the two
astronauts where it could be operated by either of them. The
Command Module actually had two DSKYs. One of the CM's DSKYs was
only the main control panel, while the other was positioned near the
optical equipment used to mark the positions of stars or other
The DSKY as a substantial piece of equipment in its own right:
Perhaps the most important part of the guidance system was the Inertial
Measurement Unit—or just "IMU" for short. The IMU continuously
kept track of the acceleration and rotation of the spacecraft, and
reported this information back to the AGC. By mathematically
processing this data, the AGC could know on a moment-by-moment basis
the orientation and position of the spacecraft.
- Dimensions: 8"×8"×7"
- Weight: 17.5
Introduction to Virtual AGC
The Virtual AGC project provides a virtual machine
which simulates the AGC, the DSKY, and some other portions of the
system. In other words, if the virtual machine—which we call yaAGC—is given the same software
which was originally run by the real AGCs, and is fed the same input
signals encountered by the real AGCs during Apollo missions, then it
will responds in the same way as the real AGCs did. The Virtual
AGC software is free of charge, can be
obtained for Windows, Mac OS X, Linux, or as open source software
source code so that it can be studied or modified.
The video clip above (courtesy of Dean Koska and YouTube)
illustrates Virtual AGC running on a Palm Centro—which isn't supported
directly from our download page. But
it's one of the great advantages of open-source
software that you can take it an adapt it to your wishes without
being at the mercy of the creators of the software.
After you install the Virtual AGC software you can run the simulation
by clicking its desktop icon :
While there are all manner of runtime options you can select in this
screen, such as which Apollo mission you which to fly, it's simplest as
a newcomer to just click the Novice button and then to click Run.
In the screenshot below, the DSKY is displaying the time since startup
(00000 hours, 00003 minutes, 00270 hundreds of a second), though that's
not something it will do automatically when you start it up.
In this simplest of configurations, you are simulating the AGC of the
Lunar Module of Apollo 13, and you are provided with a simulated AGC
and simulated DSKY. You can enter commands at the DSKY keypad,
and the AGC will report the results of its actions on the DSKY's
How to Operate the AGC from the DSKY
The first thing you need to know when operating the AGC is that it
contains a collection of programs, each identified by a two-digit
number. The most-basic program is program 00, usually known as
"pooh" (as in "Winnie the Pooh") or P00. In fact, in the
screenshot above, the AGC is running P00, as you can see by looking at
the "PROG" area in the upper right-hand corner of the DSKY. The
available programs differ somewhat from mission to mission, and the
picture below (taken from reference cards supplied to the astronauts)
is a sampling of some of the programs available for the Apollo 15
From the astronaut's perspective, all operations of the computer are
controlled by a quirky system of "verbs" and "nouns". Verbs and nouns aren't words, as you might
suppose, but are instead two-digit numbers. What makes them
"verbs" and "nouns" is that they are somewhat analogous to verbs and
nouns in natural languages like English, in which the verb describes
the action to be taken and the noun describes the data to which the
action is applied. So most commands are applied by hitting a key
sequence like the following on the DSKY:
digit NOUN digit digit ENTR
VERB digit digit ENTR
For example, a command like V06N36E (VERB 0 6 NOUN 3 6 ENTR) would mean
to perform action 06 on data 36. The exact meanings of the
verbs-numbers and noun-numbers differ from mission to mission—i.e.,
from AGC software version to version. The pictures below show a
sampling of the available verbs and nouns from the astronaut's
reference cards for the Apollo 15 Command Module, from which you can
see that verb 06 means to perform a decimal display and noun 36 means
"time of AGC clock", so V06N36E should display the current time from
the AGC's clock, if that happens to be a legal action for the current
There are also some exceptions, such as getting the AGC to run the P00
program. You do that with a key sequence like V37E00E, in which
NOUN is replaced by ENTR for some reason.
How did this strange verb/noun system get put into place? One of
the original AGC developers, Ramón Alonso, provides an
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, 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. Many
objections to the verb/noun system were received by the developers,
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 arguments as to why the interface
was really a good one. In the end, the coders won and the verbs
and nouns stayed. Nevertheless, the following Shakespearian quote
(from Henry IV) is embedded
within the AGC source code: "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."
The main Virtual AGC web-page gives
you various step-by-step procedures you can perform to see the DSKY
actually do something.
It's the Software, Stupid!
You may notice that on the Virtual AGC main display screen there are a
number of different Apollo missions listed, but that not all of them
are selectable. That's because Virtual AGC strictly simulates the
original AGC computer hardware, and that requires having the original
software that ran on the AGC. But we don't have copies of all of
the different software versions used for the different missions!
Collecting this software is one of the principal goals of the Virtual
AGC project, so if you happen to know a collector, a museum, or any of
the original AGC developers who have printouts of AGC software, let us know! (We don't want
the printouts themselves, just copies of the information in them, and
we're willing to travel there to do the copying work ourselves.)
Here's a brief rundown on the known AGC software:
These programs, though having different names, are not really
independent programs. There is a complex family heritage, and a
lot of overlap between them. So if you understand one of the
programs, you will understand 99% of what's in any of the others.
The AGC software is mostly written in assembly language.
"Assembly language" is a very simple language in which each
instruction—usually, each line of software source code—represents a
single primitive CPU operation. Since each type of CPU provides
different primitive operations, the assembly language for each type of
CPU differs from that of every other type of CPU. The AGC
assembly language, being based on the custom AGC CPU, thus differs in
detail from every other type of assembly language but shares certain
customary elements. The specific assembly language of the AGC was
referred to as "basic"—not to
be confused with the famous later computer language BASIC which is many
people's first introduction to simple computer programming.
Here's a short excerpt from the Apollo 11 Lunar Module software to give
the flavor of it:
TS L # SAVE DELAY TIME IN L
ADS Q # CREATING OVERFLOW AND Q-1 IN Q
XCH Q # SAVE DELTA
TS WAITEXIT # WAITEXIT.
INDEX WAITEXIT # IF TWIDDLING, THE TS SKIPS TO HERE
DCA 0 # PICK UP 2CADR OF TASK.
-1 TS WAITADR # BBCON WILL REMAIN IN L
DLY2 CAF WAITBB # ENTRY FROM FIXDELAY AND VARDELAY.
The things at the left-hand side (TWIDDLE,
WAITLIST, DLY2) are "program labels", and
are used to provide names for different blocks of source code.
The next column to the right contains the actual CPU instructions (INHINT, TS, CA, ADS, etc.) while the column to
the right of that (L, POSMAX, Q, etc.) specifies the data on
which the CPU instructions are supposed to operate. For example,
at the very bottom you'll find "TCF
WAIT2"; when the program reaches that point, the instruction TCF causes it to jump to
program label WAIT2.
Finally, anything preceded by the '#' symbol is just a comment added
for explanatory purposes by the programmer, but not affecting program
execution in any way.
You can learn all about AGC basic assembly language, if you so desire,
in the Virtual AGC
assembly-language manual. The Virtual AGC software provides
an assembler, which is a program that converts assembly-language source
code to executable code which can actually be run on the AGC CPU.
So with Virtual AGC, you can actually create and run your own AGC
As it happens, the functionality which the AGC needed to provide was so
complex that it wouldn't have fit within the amount of physical memory
provided by the AGC if it were written entirely in basic assembly
language. One thing that was done to get around this was to
provide also a higher-level computer language referred to as
"interpretive", in which each interpretive instruction represents a
large number of basic assembly-language instructions.
Interpretive thus has the advantage of cutting down on memory usage,
but typically has the disadvantage of running much more slowly, and
therefore had to be used with care. Within any given AGC program
like Luminary, basic and interpretive code is intermixed.
Here's a sample of interpretive code:
STATINT1 TC INTPRET
QUITFLAG # KILL INTEGRATION UNTIL NEXT P00.
600SECS 2DEC 60000 B-28
ENDINT CLEAR EXIT
Some of the things here
are the same as in the basic assembly language, such as the program
labels and the program comments. As with basic assembly langauge,
the next column to the right of the program labels (BON, STORE, CALL, etc.) contains
instructions—though mostly interpretive instructions rather than basic
In this sample, "TC
INTPRET" and "TC PHASCHNG"
are basic assembly-language code. In fact, "TC INTPRET" actually means to
begin interpreting the lines that follow as interpretive code, and
every block of intepretive code must somehow be preceded by a basic
instruction like that. Near the end, you see the interpretive
instruction EXIT, and
this means to stop working with interpretive code and to resume working
with basic assembly language.
In other respects, though, interpretive is very weird in comparison to
basic assembly language. For example, the column to the right of
the instruction column contains mostly names of variables operated on
by the instructions ... but can also contain more instructions, because
intepretive instructions can be packed two to a word of memory.
Also, many variables don't seem to be preceded by instructions, because
a single interpretive instruction may operate on the lines below it as
well as on the column to the right of it. For example, in the two
lines of code "CLEAR EXIT
/ STATEFLG" near the end
of the sample, the CLEAR
and EXIT instructions are
grouped together because they are packed into a single word of memory,
but the CLEAR instruction
actually operates on the variable STATEFLG.
Oh, those wacky AGC developers! How they must have chuckled when
they dreamed up that scheme.
You can learn all about AGC interpretive language, if you so desire, in
the Virtual AGC
The Abort Guidance System (AGS)
The AGC was not the only computer in the Lunar Module. As a
backup to the main guidance system, there was a completely separate
guidance system called the Abort Guidance System (AGS) developed by TRW
Aerospace, now a division of Northop Grumman. As the name
implies, the AGS was intended to be used only in the case of an aborted
landing, and its basic function was simply to get the LM into an orbit
from which it would be possible for the CM to rendezvous.
Fortunately, this functionality never had to be used in a real mission,
but that does not alter the significance of the system.
Naturally, an important part of the AGS was a computer, and this
computer was called the Abort Electronics Assembly—or just "AEA" for
short. Since the AGC and AEA were developed independently by
unrelated groups, there is no commonality between them in terms either
of hardware or of software. There was essentially no interaction
between the AGC and AEA, except that the spacecraft's "state
vector"—its current position, velocity, and orientation—could be
Here are the basic characteristics of the AEA:
Just as the AGC had its DSKY for interfacing to the astronaut, the AEA
had its own Data Entry and Display Assembly—or "DEDA" for short.
- 2048 words of RAM. A "word" was 18 bits of data—therefore
just over 2 bytes (16 bits) of data—and so the total RAM was just 4608
- 2048 words of read-only memory, so equivalent to 4608
bytes. It should be noted that the "RAM" retained its contents
when power was removed, so that the full 4096 words (9216 bytes) of
memory were available for program storage.
- Maximum of about
100,000 CPU instructions executed per second.
- Dimensions: 23.75"×8"×5".
- Weight: 32.7 pounds.
- Power supply: 90 Watts.
The astronaut interface was very simple. You could do one of two
In other words, to usefully interact with the AEA, you had to know the
numerical values of the memory addresses that had any significant
purposes. But don't be fooled by the simplicity of the interface
into believing that the AEA was a mere calculator. Though its
functionality was much less than that of the AGC, it still had to
perform very significant guidance functions on demand, and to have very
- Change the value stored in a memory location; or
- Cause the value of a memory location to be displayed (and to
update twice per second).
Virtual AGC provides the ability to simulate the AEA and DEDA, and you
can activate this ability by selecting the "LM Abort Computer (AEA)"
option in the Virtual AGC main window. In the screenshot below,
the DEDA is displaying the contents of location 377, which is the
number of interations of the units self-test which have been executed
As with the AGC software, the AEA software evolved over time and we
have only a subset of the software versions known to have been created,
so if you know of the existence of
others please let us know! We do have the versions for Apollo 11 ("Flight Program 6") and
probably for Apollo 15-17 ("Flight
The AEA was programmed in its own assembly language, which was
completely different from that of the AGC. The Virtual AGC
software includes an AEA assembler, so you can create and run your own
AEA software, if you'd like to do so.
You can learn more about the AEA, including the definition of
assembly language, at the main Virtual AGC
web-page for it.
Guiding the Mighty Saturn Rocket
It's natural to think that the AGC might have steered and otherwise
controlled the Saturn V rocket that hurled the Command Module and Lunar
Module onto its moon-bound trajectory, or the Saturn IB rocket that was
used for Earth-orbital missions like Apollo 7, but in fact it isn't
true. The AGC was able to provide limited guidance-system backup
for some of the Saturn burns, but the main responsibility for guiding
the Saturn rested with yet another onboard computer, the Launch Vehicle
Digital Computer (or LVDC for short). The astronauts were able to
monitor various sensor readings from the Saturn's guidance system
on their displays, but neither they nor the AGC normally had any
control over the rocket.
Unlike the AGC and AGS, the LVDC was not installed in the Command
Module or Lunar Module, but was instead installed in the Saturn itself,
in a non-propulsive stage called the IU (Instrumentation Unit).
The IU perched above the final propulsive stage, the S-IVB, and
therefore was the last part of the Saturn to be discarded by the
Command Module. The picture at right illustrates this for a
Saturn IB rocket, but the Saturn V is very similar ... only much bigger!
There's a lot more information about the LVDC on the main Virtual AGC web-page for it, but there's no
denying that at present we know far less about the LVDC than about any
of the other Apollo flight computers.
To Learn More ...
This web page has provided a brief introduction to the AGC &
friends, and to Virtual
AGC, but if you'd like to learn more about the AGC without taking the
trouble to become a full expert on it, you might want to read the AGC's
If that's not enough for you, you can learn a lot more by looking at the main Virtual AGC web pages, and of course that's
what we think you should
do! In fact, the main Virtual AGC website contains every
AGC-related scrap of data, documentation, and software we've been able
to find, so it can be somewhat intimidating. We're sorry about
that, but training for an Apollo moon landing isn't easy!
Last modified by Ronald Burkey on 2009-08-17.