AGC — AGS — LVDC — Gemini
A Kinder, Gentler Introduction
browser to see a site-search form here.
Ron's 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
(CM) and the Lunar
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,
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
Fabrizio's Alternate Introduction to the AGC
has contributed this alternate introduction to the AGC, from
a poster presentation he made, and then was kind enough to give use
both the poster, in Italian, and an English translation. The
words and photos are his, and I'll simply present them as-is.
Don't be surprised if there's some duplication of material.
first contract assigned within the scope of the Apollo program, a
little after the decision by president Kennedy to reach the Moon
before the decade was out, has been that for the computerized
guidance and navigation system. Requirements for the system were
clear and simple, but apparently unreachable at the time: build a
small autonomous system, able to steer a crew from the Earth to the
Moon and bring it back safely to the Earth.
A giant leap for
in 1962 MIT's Instrumentation Laboratory began, under the direction
of the legendary Dr. Charles Stark Draper (a pioneer of inertial
navigation systems), the development of a computer to bring people
from the Earth to the Moon, computers where in their childhood. They
were giant electronic-tubes devices, big as rooms or even building
floors, controlled by means of of perforated tapes or cards, with
insiggnificat memory capacity compared to the personal computers that
would be born at the end of the 1970's.
an engineering courage that has few precedents, designers (historical
characters like Hal Laning Jr, Eldon Hall, Ramon Alonso, Albert
Hopkins and many others) elected to use for the first time in history
a newly born electronic component: the integrated circuit. Still far
away from the microprocessor or microcontrollers of the 1980's, the
only functions available were simple logic ones. Using thousands of
these logic gates, it was possible to implement what would be called
today the central processing unit of the computer and all support
circuitry. For memory, since it was still impractical to build it
with integrated circuits, the ferrite core technology (where small
rings were used to store single bits) was adopted. being reasonable
easy to miniaturize. Using the same technology, the program memory
was made of tens of thousands of ferrite cores, hand woven with thin
copper wire to represent the 1's and 0's of the computer software.
These wire were to be woven by specialized workers at least one month
before the launch of a mission.
critical decisions, taken in the era of the "dinosaur
computers", were found to be winners in the following years,
just seven, that saw men land on the Moon. The onboard computer
developed for the Apollo program (and installed into both the Command
Module and the Lunar Module, but with different software for each
vehicle) was an outstanding technological success and established
rules for the development of future computers both for aerospace and
other applications. It also opened the way to new applications of
integrated circuits (it has been the first big user on an industrial
scale) and being at the time the smallest computer in the world,
helped push computers into other sectors of technology.
AGC, CMC, LGC?
the navigation system developed for the Apollo program
were used both on board the Command (and Servce) Module, or CSM, and
on board the Lunar Module, or LM. To distinguish them, the one in the
Command Module was said CMC (Command Module Computer), that in the
Lunar Module was said LGC (Lunar-module Guidance Computer).
software was different for the two computers, and each "edition"
had an independent development path, with shared components. It was
in common the management of the various programs, as well as the
management of the inertial platform and that of the interface toward
the crew (called DSKY, for Display and Keyboard).
CMC software was different for the presence of the Saturn V rocket
monitoring and control program (never used in its controlling
functions as the Saturn computer always performed flawlessly). It
also contained functions to steer during the trans-lunar trajectory
maneuver, during orbital flight and of course for the re-entry into
the Earth's atmosphere.
LGC software was different for the descent and landing programs, and
for the ascent program and the subsequent lunar orbit insertion.
part in common was devoted to the rendez-vous maneuvres, as both
vehicles could perform as the active part in the complex process of
rejoining each other in orbit.
the software of both vehicles was different in the management of
propulsion devices, and the navigation sensor which, while in the CSM
were a sextant and a telescope, in the LM they were a single optical
device with a special behavior (due to the reduced size of the LM and
the need to keep weight within precise limits).
Display and keyboard
component of the whole AGC was the panel used by the
crew to interact with the computer. In an era in which "speak"
to a computer using a video terminal was still a futuristic
advancement, the unit called Display and Keyboard, or DSKY,
represented a drastic achievement in the relationship between man and
machine. For the first time the famous seven-digits numericla
displays were introduced and for the first time it was possible to
tell the computer, while it was working, what to do, being also
possible to interact with it to change parameters, or to monitor
numerical values of different kind (which by itself was a real
novelty in an aerospace workd still dominated by gauges).
limitations imposed, of course, a number of restriictions and
ingenuous solutions even if using the language developed for the
purpose of user interaction with the computer required patience and
training to ensure efficency and confidence.
was based in two-digits numeric codes, used to
represent Verbs (that is actions) and Nouns (that is the object of an
action). In the figure it is shown part of a checklist (from the
Apollo A17 Flight Crew G&N Dictionary) that summarized all the
Verb/Noun codes for the Lunar Module computer. Verb and Noun values
had a prominent display on the DSKY as well as the active program (or
major mode, related usually to a flight phase), which was also
assigned a two-digits numerical value and displayed on the top right
corner of the unit.
Verb and Noun keys were used to set the Verb/Noun combination of
interest, and telling the computer to accept it by pressing the Enter
key (e.g,, a typical sequence could have been: Verb 16 Noun 65 Enter).
The Clear key was used to correct user typing errors, while the Reset
key was used to cancel error warnings from the computer. The Pro key
(where Pro stands for Proceed) was sued to confirm critical
operations (like the execution of a maneuver or the starting and
stopping of the computer). The Key Release key was ued to release the
control of the DSKY to other routines that required its use, that is
when the corresponding indicator light was flashing to grab the
attention of the operator. The latter behavior was another novelty as
many programs could run inside the AGC at the same time.
real task assigned to MIT's Instrumentation Laboratory (now Draper
Laboratoroes) was the design and implementation of a guidance system
for Apollo, that is a system able to keep a notion of the state of
the vehicle in every instant and provide guidance directions for the
execution of specific flight phases (for instance, landing on the
Moon). The whole AGC is therefore a wider system, not limited only to
the computer, that provided sensors, actuators, interfaces for the
crew and the communications system (to exchange data with the control
sensors, designers chose an inertial navigation system
based on a "three-axis inertial platform" able to maintain
an given orientation (used as reference) independently by the motions
of the vehicle. On the "platform", three accelerometers
were mounted to measure accelerations and thus update the vehicle
state during propulsive phases. In the free-fall phases, when the
vehicle moved along orbits dictated by Earth/Moon gravities, the
state was updated mathematically by applying Newton's and Kepler's
equation. Verification of the state, to correct it in case of
possibile deviations from the intended path, were done by means of a
sextant mounted with the "platform". By observing stars and
the angle between stars and the horizon (or a landmark) crew were
able to navigate in the Earth/Moon system like sailors did for
centuries before the advent of of modern radio navigation systems.
The mathematics behind the whole guidance and navigation system was
worked out by prof. Richard Battin, at the time one of the most
prominent experts in the sector, who also went to initially lead the
software development task for AGC.
the course of the project, the AGC was added other main functions,
like that to act as go-between for the manual control of the vehicle.
By all means that was the first "fly-by-wire" guidance
system in history, and the first "digital autopilot". This
and other additional utilities for secondary tasks demonstrated the
versatility of computerized system with respect to more classical
in all computerized systems, the physical part of the computer
(circuits, logic gates and memory) is useless without a program to
manage its operation. Software became soon one of the principal
aspects of each Apollo mission and hundreds of programmers (at a time
when the word "software" was still unknown but to a few
insiders) worked to produce programs of very high quality, and with
lots of ingenuity, having to overcome not only the intricacies of the
space guidance and navigation equations, but also the limitations
imposed by the inflexible hardware architecture. Even in this case,
methods and technologies were developed for this specific purposes to
soon become part of the required knowledge in the aerospace world.
development was not even worthy a mention in the original contract,
as it was considered expected, at the time (but often it is still the
same today), that programming the computer was a side task in the
whole project. In truth, at the peak of the Apollo program, in 1969,
software workers were approximately as much as the hardware workers.
But being the "software culture" not widely diffused,
everybody looked with suspicion at this intangiblebut fundamental,
were the programming languages available: one was the proper central
processing unit language, or assembly language, and the other was a
higher-level language, that was to be interpreted at execution time
within the computer by a program called, exactly, Interpreter. This
second language enabled to save memory speeding up the programming of
complex mathematic operations, at the expense of a slower execution
the course of software development, in addition to performance
limitations, programmers had to fight against memory limitations.
Uncountable tricks were used by programmers to save memory words,
often to the detriment of code readability. In addition, to worsen
the situation, it was required to adopt particular techniques to
protect critical functions from a sudden computer restart. By keeping
tab on the state of programs under execution it was possible to
ensure that in case of serious problems, the computer were able to
restart and resume programs from the place they were at the moment of
the trouble, without causing issued with critical functions, like the
experience acquired with the Apollo program, that continued after the
lunar missions with the Skylab flights and the Apollo-Soyuz mission,
was not lost. The perfomance of the software and the reliability of
the hardware made the AGC the logical choice for the first computer
controlled flight, or "fly-by-wire", of an airplane (a
modified F-8 fighter). The experience of programmers was subsequently
transferred to the Space Shuttle program, where an evolution of the
AGC software, and the methods used to implement it, contributed to
the making of a space vehicle entirely controlled by the on-board
Myths and legends
it true that the Apollo computer had less power than a digital pocket
No it is not true. The performances of the Apollo Guidance Computer
were comparable to that of the central processing unit of computers
llike the Apple II, the Commoder 64 and the ZX Spectrum, the personal
computer that opened the way for the digital revolution at the end ot
the 1970's. The big difference was that the AGC was highly reliable
and had many more input/outpu ports to be able to control, and
receive data from, sensors and devices within the Command Module and
the Lunar Module. In addition, it was able to execute programs in
real-time, that is which operated continuously performing more tasks
at the same time and guaranteeing that high priority tasks were
performed first when required. Its architecture is not much different
from that of modern microcontrollers used today for the most
disparate tasks, with the difference that the latter are at least 10
to 20 times faster than the AGC and enormously smallet (being
integrated in a single chip). For this reason programming and using
the AGC is not very far from th world in which control systems and
embedded systems designers and hobbysts work today.
it true that during the landing of Apollo 11, Neil Armstrong had to
take control from the computer because of the alarms it generated?
Stupid media remarks often cite "software errors" that
generated alarms during Apollo 11 descent to the Moon (the most
critical phase of the mission). In truth, the robustness of AGC
software, in terms of good desing and reliability, saved the mission
when other issues, external to the computer, were causing an overload
in it its operation (and was thus correctly alerting the crew of the
condition). The LGC kept working correctly, but toward the end of the
descent, Armstrong took manual control (as everybody else who
followed him on this task) because the landing point targeted by the
computer was too dangerous for a safe landing.
AGC the first space computer?
No, AGC wasn't the first space computer or the first computer who
flew on a crewed vehicle. Gemini spacecrafts had also an onboard
computer, made with transitors, and able to assist the crew (but not
totally control the vehicle) in the propulsive phases, during
'rendez-vous' and during re-entry. But that computer was not an
essential part of the mission, while AGC was born to privide
assistance in completing the mission without ground support.In
addition to that, other digital computers were developed for the
Titan rockets, and of course for the Saturn, but they were limited to
a single task and were much bulkier and heavier. The Lunar Module
also had a second onboard computer, the AGC, Abort Guidance System,
much simpler and able to ensure the climb back to orbit and a
rendez-vous with the CSM in case of troubles with the primary
guidance and navigation system.
the AGC have an operating system?
In a certain sense it had, in the sense today commonly considered for
computers for control applications. The AGC operating system was made
of an executive and a manager of queue for waiting programs. The
executive provided, in turn and basing on priority, a chance to each
program to execute its own instructions and also managed possible
interruptions generated by random external events. This way more than
a single program could be active at the same time, even if the
allocation of "machine time" was not based by a rigid
scheduling (preferred technique at the time). but was was
asynchronous and linked to the correct design of each function. Also,
it was available a separate process to verify the well-being of the
computer, one for the management of the DSKY and one for managing
external devices. And another part of this "operating" was
devoted to the higher level language used for mathematical operations
that did not require a real-time response.
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.
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.
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"
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.
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.