Virtual AGC Home Page

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:

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 bytes.
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 28V DC

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.

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 landmarks.

The DSKY as a substantial piece of equipment in its own right:

Dimensions: 8"×8"×7"
Weight: 17.5 pounds.

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.

Introduction to Virtual AGC

The Virtual AGC project provides a virtual machine which simulates the AGC, the DSKY, and some other portions of the guidance 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 display.

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 Command Module.

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:

VERB digit digit NOUN digit digit ENTR
or sometimes
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 program.

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 explanation. 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, 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:

Mission	AGC Software by Name and Version
Mission	Command Module	Lunar Module
Apollo 1	Sunspot build TBD	-
Apollo 4	Solarium build 55	-
Apollo 5	-	Sunburst build TBD
Apollo 6	Solarium build TBD	-
Apollo 7	Sundisk build TBD	-
Apollo 8	Colossus build 237?	-
Apollo 9	Colossus build 249?	Sundance build 306
Apollo 10	Comanche build 45?	Luminary build 69
Apollo 11	Comanche build 55	Luminary build 99
Apollo 12	Comanche build TBD	Luminary build 116
Apollo 13	Comanche build 67	Luminary build 131
Apollo 14	Comanche build 72	Luminary build 178
Apollo 15	Artemis build 72	Luminary build 210
Apollo 16	Artemis build 72	Luminary build 210
Apollo 17	Artemis build 72	Luminary build 210
Skylab 2 Skylab 3 Skylab 4	Skylark build 48?	-
Apollo-Soyuz	Skylark build TBD	-

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:

TWIDDLE           INHINT                                         
                  TS       L        #  SAVE DELAY TIME IN L
                  CA       POSMAX                                
                  ADS      Q        #  CREATING OVERFLOW AND Q-1 IN Q
                  CA       BBANK                                 
                  EXTEND                                         
                  ROR      SUPERBNK                              
                  XCH      L                                     

WAITLIST          INHINT                                         
                  XCH      Q        # SAVE DELTA           
                  TS       WAITEXIT # WAITEXIT.                  
                  EXTEND                                         
                  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.
                  XCH      BBANK                                 
                  TCF      WAIT2

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 programs.

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                               
                  BON      RTB                                   
                           QUITFLAG          #  KILL INTEGRATION UNTIL NEXT P00.
                           NOINT                                 
                           LOADTIME                              
                  STORE    TDEC1                                 
                  CALL                                           
                           INTSTALL                              
                  SET      CALL                                  
                           NODOFLAG                              
                           SETIFLGS                              
                  GOTO                                           
                           STATEUP                               
600SECS           2DEC     60000      B-28                       
ENDINT            CLEAR    EXIT                                  
                           STATEFLG        
                  TC       PHASCHNG

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 instructions.

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 assembly-language manual.

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 transferred.

Here are the basic characteristics of the AEA:

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 bytes.
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.

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.

The astronaut interface was very simple. You could do one of two things:

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).

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 sophisticated software.

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 (and passed).

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 Program 8").

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 its 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 Wikipedia article.

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.