Home
AGS
LVDC
Gemini
Download
Document library
Change log
Bug and issues
Developer info
Virtual AGC — AGS — LVDC — Gemini

Abort Guidance System (AGS)
and Abort Eletronics Assembly (AEA)

FAQ
yaAGC
yaYUL
yaDSKY
yaOtherStuff
Luminary
Colossus
Language Manual
Physical Implementations

Please enable javascript in your browser to see a site-search form here.

Contents

What is the Abort Guidance System (AGS) or Abort Electronics Assembly (AEA)?

LM's Integrated Flight Control subsystemThe AGS was a computer system used in the LM.  It was a completely separate computer system from the LM's AGC, with a different architecture, different instruction-set, and different runtime software.  It was in the LM as a kind of backup for the AGC, but was only supposed to be used (as the name implies) in case of an aborted landing.  The AGS doesn't have as commanding a rôle in the history of lunar explanation as does the AGC, because no aborts were ever needed in actual missions.  However, when the AGS made its few appearances in history it did so dramatically.

For example, the AGS was involved in a near-disaster during the Apollo 10, at the closest approach of the LM to the moon.  This wasn't a flaw in the AGS or its software, of course.  It was caused by problems executing the crew procedures. Recall that the mission of Apollo 10 was to orbit the moon, then to take the LM close to the lunar surface (but not to land), and then to jettison the LM's descent stage and return to orbit with the LM's ascent stage.   When the LM ("Snoopy") staged, the plan was to do it under AGS/Attitude Hold, with Tom Stafford controlling the attitude with his hand-controller.  As the LM approached the perilune of the Descent Orbit, at the point of simulated lunar liftoff, Stafford noticed a small yaw drift (caused, as it turned out, by yaw rate-gyro stiction) and presumably he wanted to not have to worry about controlling the LM's attitude when he was punching off the Descent Stage and firing the down-jets for separation. Unfortunately the AGS was mistakenly set for "CM pointing," only useful during rendezvous, so when he toggled back to Auto, from Attitude Hold, the AGS promptly fired the jets to get the LM facing the CM in its orbit, above and ahead of them. Because there were no real attitude rate limits for maneuvering in AGS, the Ascent Stage swung wildly back and forth as the AGS crudely did its normal thing, damping out the rates as it approached its target, and settled nicely where it was "supposed" to be with no inputs from Stafford.  (See the mission report.)  So it all turned out okay.

The AGS was used on the Apollo 11 mission also, when Armstrong decided not to do the proper attitude sequence as he was getting ready to re-dock with Columbia after returning from the moon. He rolled the LM through PGNS gimbal lock, instead of yawing and pitching, and had to switch to the AGS for attitude control.

Amusingly, the AGS was orginally called the "Backup Guidance System" but its acronym (BUGS) apparently was not considered suitable.

The AGS was developed by TRW, rather than by the MIT Instrumention Lab that developed the AGC, so there was no overlap in development personnel between the AGS and AGC systems.  Furthermore, there was almost no overlap in engineering technique, other than that both groups of necessity were generally constrained by the technology available at the time.  For example, both needed to use memory based on ferrite-core technology.  Moreover, there was no interaction between the AGS and AGC systems, other than a downlink enabling the AGS to download the AGC's navigational data (and thus avoiding manual entry of data) .

Strictly speaking, the computer part of the AGS is called the Abort Electronics Assembly (AEA), and so you may sometimes see references to the AEA rather than the AGS.   Various components in the AGS include:
The AEA can process Rendezvous Radar data but not Landing Radar data, which makes sense because it's only potential use was to get away from the immediate vicinity of the lunar surface.  There is, however, a story that Gene Cernan says they had figured out how to use the AGS to land the LM without an AGC.  This may have been Gene pulling somebody's leg, but I'm gullable enough or possibly ignorant enough to believe it.

(Thanks to Paul Fjeld for a lot of this explanation and, in fact, a lot of the verbiage as well.)

AGS Documentation

The following documentation is not available (as far as I know) anywhere else.  It was digitized by John Pultorak (thanks, John!) from physical documents preserved and donated by Davis Peticolas (thanks, Davis!).

Evolution of the Flight Software

The known versions of the AGS flight software are as follows.  As you can probably tell by looking, this table should not be taken as authoritative.

Program Name
Acronym
Description
Listing
Design Mission Computer Program
DMCP
The baseline software, of which all other programs listed below are modifications

Flight Program 2
FP2
December 1967, probably for Apollo 5 (unmanned LM Earth-orbit test mission)

Flight Program 3
FP3
May 1968, probably for Apollo 9

Flight Program 4
FP4
(Identical to FP 3)

Flight Program 5
FP5
Probably for Apollo 10

Flight Program 6
FP6
Our copy is dated February 14, 1969, for Apollo 11
FP6.aea.html
Flight Program 7
FP7
(Unknown)

Flight Program 8
FP8
Released April 28, 1971 (though our copy is dated December 18, 1970), probably for Apollo 15-17
FP8.aea.html

Architecture of the Abort Electronics Assembly (AEA)

LM Abort Guidance Section block diagram
"As with the PGNCS computer, the AGS computer went through an evolutionary period in which designers clarified and settled the requirements. The first design for the system did not include a true computer at all but rather a "programmer," a fairly straightforward sequencer of about 2,000 words fixed memory, which did not have navigation functions. Its job was simply to abort the LEM to a "clear" lunar orbit (one that would be higher than any mountain ranges) at which point the crew would wait for rescue from the CM, with its more sophisticated navigation and maneuvering system. The requirements changed in the fall of 1964. To, provide more autonomy and safety, the AGS had to provide rendezvous capability without outside sources of information. TRW, the contractor, then decided to include a computer of about 4,000 words memory. The company considered an existing Univector accumulation machine but, instead, chose a custom designed computer.
 
"The computer built for the AGS was the MARCO 4418 (for Man Rated Computer).  ...  The computer was 5 by 8 by 23.75 inches, weighed 32.7 pounds, and required 90 watts. The memory was bit serial access, which made it slower than the PGNCS computer, and it was divided into 2K of fixed cores and 2K of erasable cores. The actual cores used in the fixed and erasable portions were of the same construction, unlike those in the PGNCS computer. Therefore, the ratio of fixed memory to erasable in the MARCO 4418 was variable TRW was obviously thinking in terms of adaptability to later applications."

-- James Tomayko, Computers in Space Flight
AGS block diagramThe AEA (the computer) had the following characteristics:
Register
Description
A
The "accumulator", involved implicitly in most instructions as the source or destination for data.
Q
The "multiplier quotient" register.  A kind of less-significant-word register for extending the length of the accumulator, but also used in a dedicated way for a number of different kinds of operations like multiplication and division.
Index
A three-bit register which can optionally be added to addresses to create an indexed addressing mode by setting the index flag in the instruction word.  Also used as a loop counter.  Obviously, since the register can only take values 0-7, the array and loop sizes used were very small.
Much more detailand indeed, almost everything you'd want to know architecturallymay be found by consulting the Abort Electronic Assembly Programming Reference.

yaAGS, the AGS CPU Emulation

yaAGS is the program which emulates the AGS CPU.  In other words, it loads the binary form of the AGS flight software, or other software newly written for verification purposes, and then executes that software on a cycle by cycle basis, emulating the CPU's architecture and instruction set. 

The program has just become operational (2005-06-15), but probably with plenty of bugs to fix.

Of itself, the emulation is not very visually exciting, since the CPU requires peripheral devices as well.  The peripherals are not provided directly by yaAGS; rather, they must be emulated by separately-provided software.  (Once these peripherals are available for yaAGC, we'll work to make them available for yaAGS as well.)  This technique allows a developer of (for example) a lunar lander simulation to use the CPU emulation, but to replace simulated peripherals in order to achieve better integration.  The principal peripheral is the DEDA (see below).

The command-line syntax is:

yaAGS [OPTIONS] --core=Filename

The name of the file for the "--core" switch is an executable binary created using the yaLEMAP cross-assembler or the binLEMAP utility.  (Typically, "--core=FP6.bin" or "--core=FP8.bin", since these are the available AEA flight binaries.)  Both programs are described below.  The core file format is discussed in the binLEMAP section, although it won't be of interest to most users.

The presently-defined options are:

--help
Displays a list of options (such as this one) and then quits.

--debug
Causes the AGS program (such as Flight Program 6 or Flight Program 8) to halt prior to executing its first instruction, and activates a debugging mode (very primitive) in which you can do things like examine AEA CPU registers, single-step through the AGS program, etc.  This mode is described further below.  

--debug-deda
(20090319 and later.)  Prints messages on the console about data packets received from the DEDA(s).

yaDEDA, the AGS User-Interface Simulation


Line drawing of a DEDA DEDA block diagram

Click for a larger screenshot of yaDEDAThe term DEDA refers to the Data Entry and Display Assembly, which is the assembly used by the astronauts to enter data into the AGS, or to see data displayed by the AGS.  The DEDA was mounted in the lower-right portion of the LM's control panel, just in front of the LMP (Lunar Module Pilot).  Recall that in the somewhat odd terminology employed in the Apollo program, the LMP did not actually pilot the LM.  Rather, the commander piloted the LM from the left-hand position.

yaDEDA is an emulation of the DEDA for use with yaAGS.  However, it is certainly possible for the developer of a LM simulation to develop his or her own emulation of the DEDA.  Indeed, the program yaDEDA2 has now superceded the original yaDEDA program, although the original is still available if someone was interested in it.  When I refer to "yaDEDA" below, I actually mean to refer interchangeably to both "yaDEDA" and "yaDEDA2" unless I state otherwise.  For information on developing these kinds of alternative implementations, you should refer to the developer info page.  You'll notice that the screenshot of yaDEDA to the right is somewhat different from the drawing of the DEDA above, particularly as to the HOLD-key; that's because of discrepancies in the available documentation, so feedback on this issue is particularly welcome.

Unlike the DSKY, which is basically completely useless without the AGC, the DEDA has some built-in smarts.  Actually, most of the DEDA user-interface is built into the DEDA, and so yaDEDA can be operated even without the presence of yaAGS.  Notice that the DEDA has two displays:  a three-digit display which is an octal "address", and a 5-digit display (plus sign) of "data".  Quite a lot of the operation of the DEDA was simply to enter an address (in the first 512 bytes of AEA memory), after which the AEA would output the value of that memory location every half-second.  The AEA software would format the data, which could be either octal or decimal, or could involve various scale factors or units.  However, the units and scaling and octal vs. decimal choices are hardcoded into the AEA software, and are not selectable by the user.  This mode persists until pressing the HOLD key, which signals the AEA software to stop outputting data.  (After hitting HOLD, you could hit READOUT again to restart the data-monitoring.)  To put the DEDA/AEA in this continuous readout mode, you do the following on the DEDA keypad:

CLR OctalDigit OctalDigit OctalDigit READOUT

The digits appear on the address display as you enter them.  Any error in entering this sequence causes the OPR ERR lamp to light, making the DEDA basically inoperative until the CLR key is pressed again.  All of this, except for the actual generation of the data, occurs within the DEDA without needing an AEA (yaAGS).

The other thing you can do with the DEDA user interface is to perform data entry:  i.e., to send the AEA a command or data.  The interpretation of the data you enter is dependent on the address you enter:

CLR OctalDigit OctalDigit OctalDigit Sign Digit Digit Digit Digit Digit ENTR

Again, both the 3-octal-digit address and the 5-digit data (plus sign) appear on the display as you strike the keys, but any departure from the above sequence lights the OPR ERR lamp, which can only be cleared with CLR.  The 5-digit data can be either octal or decimal, but this is address-dependent (as hardcoded into the AEA software), so it's not a matter of your choice.  Other than the actions which this type of operation is supposed to cause within the AEA, all of this takes place within yaDEDA.

The command-line syntax for the yaDEDA2 or yaDEDA program is:

yaDEDA2 [OPTIONS]
or
yaDEDA [OPTIONS]
The presently-defined options are:

--help
Display a list of options, something like the information shown here.

--ip=addr
yaDEDA and yaAGS are a client/server pair, and can be running on the same computer or on different computers. In order to connect to the yaAGS server, yaDEDA has to know the IP-address of the machine on which yaAGS is running. By default this is "localhost"---i.e., the two are running on the same computer. However, a different IP address may be specified using this command-line switch. In Linux, this may be either the machine's name, or else a numerical address in dotted format (n.n.n.n). MS-Windows---at least Windows 98---is somewhat crippled in this respect, and will only accept a host name rather than a numerical IP address.

--port=port
Similarly (see above), in addition to an IP address, a port number is needed. This must be in the range of port numbers yaAGS is scanning (which by default is 19897-19906).  If no port is specified, yaDEDA will use 19897, in accordance with the suggested port assignments on the developer page.

--half-size
 yaDEDA's graphical interface is simply too big for PCs with lower graphical resolution (smaller than 1024×768).  If the --half-size switch is used, half-size graphics are used, and so the interface should be usable even down to 640×480 resolutions.  The smaller interface doesn't really look very good, because it is simply blindly scaled down from the larger interface, rather than being optimized, but at least it's usable at 800×600 and 640×480 resolutions.

--delay=Milliseconds
Adds a delay at start-up, so that yaDEDA does not immediately begin attempting to communicate with yaAGS.  The current defaults are 0 ms. in Linux and 500 ms. in Win32.  This "feature" has been added as a temporary work-around for problem report #23, and probably has no other sensible purpose.  Even on Win32 it isn't usually needed, but it's here for the 10% (or whatever) of the time it's needed.

--relative-pixmaps
(Final version of yaDEDA only; not available on yaDEDA2.)  Alters the locations of graphics files used by the yaDEDA program to the ./pixmaps/yaDEDA/ folder rather than the default system folders.  This makes the program compatible with the directory structures and runtime assumptions of the VirtualAGC GUI system rather than the previously used script-driven runtime system.

yaLEMAP, the AGS Cross-Assembler

The original cross-assembler for AGS assembly language was known as the "LEM Assembly Program", or LEMAP.  You can read all about it in the document by H. L. Stiverson (see above).  We don't have the code for the original cross-assembler, nor (if we did) do most of you have access to the type of computer on which it ran.  So, we're providing you with a completely new assembler that can assemble the original flight-software source code into a binary usable by the AGS CPU emulation, yaAGS.  Naturally, we call this new cross-assembler yaLEMAP.

The command-line syntax for yaLEMAP is:

yaLEMAP [OPTIONS] SourceFilename

The only presently-defined option is:

--compare=Filename
This switch causes the assembler to load the binary file called Filename, and to compare the binary output produced by assembly of the source code to the contents of Filename.  Presumably, Filename was produced by an earlier run of yaLEMAP or binLEMAP (see below).  This is type of comparison is useful principally for regression testing of the assembler itself, and (indeed) such regression testing is performed during a normal build.  This switch also causes a change in yaLEMAP's return codes, which are normally based on the presence of errors and warnings.  (In other words, a non-zero return code normally occurs in case there are errors during assembly.)  With the "--compare" switch, though, yaLEMAP has a return code of zero when the binaries match, and a non-zero return code when they don't match.  Naturally, one could use operating-system utilities (such as fc in Win32 or diff in Linux) to mimic this functionality as well; however, the "--compare" switch also has the property of adding meaningful messages about any mismatches to the assembly listing, which the operating-system utilities do not.

--html
(20090629 and later.)  Causes creation of an HTML version of the assembly listing.  The HTML filename is the same as SourceFile, except that the .ags filename extension (if present) is replaced with .html.  The HTML is syntax-highlighted, so that it is easy to distinguish opcodes from line labels, etc.  Finally, the HTML contains hyperlinking from where symbols are used to where they are defined.  It is also possible to define modern annotations for the source code.
 
yaLEMAP is a simpler program in may ways than the AGC cross-assembler yaYUL.  There are several reasons for this:
yaLEMAP always outputs its binary in a file called yaLEMAP.bin, which has a format compatible with both yaAGS (see above) and binLEMAP (see below).  Similarly, the assembly listing file is always output to the file yaLEMAP.lst.  The listing format is not identical to that of the original LEMAP program, but its flavor is pretty similar, and the changes are probably more in line with today's thinking.  (For example, in the symbol tables produced by yaLEMAP, the symbols are referenced to their numerical values.  In symbol tables produced by LEMAP, the symbols are referenced to line numbers within the assembly listing, and you can look at that line number to see the numerical value which has been assigned.  That's logical, perhaps, in a world where everybody is looking at paper printouts; it's not logical in an online world, so I haven't felt too bad about changing it.)

The syntax of the source code for yaLEMAP similarly isn't identical to that accepted by LEMAP as outlined in the AGS programmer's manual, but it's pretty close.  The principal differences are:

Utility Programs

binLEMAP, for ASCII Entry of AGS Executable Binary

There are two distinct ways of obtaining executable AGS binaries from an AGS assembly listing.  You could enter the assembly-language instructions into the computer, creating source code that can be assembled with yaLEMAP as explained above.  Or, you could enter the octal form of the opcodes into the computer, creating a file of numbers that can be processed with the binLEMAP utility.  In fact, for verification purposes we do both, and then compare the results as explained below.

Use of the binLEMAP utility is quite simple, as it has no command-line options.  It simply reads the standard input and creates a file called binLEMAP.bin.  The command-line syntax is:

binLEMAP < InputFile

The output file, binLEMAP.bin, consists of 10000 (octal) entries, each one of which is a 32-bit unsigned integer in little-endian format (i.e. with the least-significant byte first).  The first entry represents AGS memory address 0, the second represents AGS memory address 1, and so forth.  This file is therefore always exactly 16384 (decimal) bytes in size.

The input file obeys the following simple rules, tailored to match the way the assembled data appears in LEMAP assembly listings, in order to make data entry easy:
The purpose of the rather odd rule about removal of the character 'p' is that it means an optional 'p' can be inserted after an octal number.  It helps me in my proofing to run these files through the text-to-speech converter on an iMac, and this subterfuge of adding the extra 'p' fools the iMac's text-to-speech converter into pronouncing the numbers in the way I want.

AGS Flight Software

Availability

The following versions of AGS flight software are available:
If you know of other existing versions of the AGS source code, give them to us!

Validity

Validation of the AGS source code is somewhat streamlined from the method used to validate AGC source code.  The following process is used:
  1. The source code is entered into the computer from the assembly listings. 
  2. It is assembled with the yaLEMAP cross-assembler.  As a byproduct, a ASCII file is produced with just the columns of the assembly listing containing the assembled octal values.
  3. The byproduct ASCII file mentioned above is fed into a text-to-speech converter program, and the now-audible octal codes are compared visually against the original scan of the assembly listing.  The source files are fixed as needed when mismatches are found.
Obviously, it's a matter of opinion how many times the  proofing process described above needs to be repeated.  I have repeated it only until the embedded checksums are correct.  If anyone wants to volunteer to perform additional proofing—for example, of the program comments, which are not checked by the process I used—feel free to do so and to report the results to me.

Special Problems of Flight Program 6

Unfortunately, the assembly listing we have of Flight Program 6 is missing a couple of pages (namely, pp. 90 and 96).  From comparison of FP6 and FP8, I believe that the missing pages contain code that has not changed between FP6 and FP8, and therefore have simply substituted the corresponding chunks of code from FP8 into FP6.  The types of circumstantial evidence that this is acceptable are as follows:
This all seems pretty conclusive, but if you have a listing of FP6, please scan pages 90 and 96 and send them to me and save us this dreadful uncertainty!  (Of course, if you have other versions of the program, scan them and send them to me too!  Or send them to me via snail-mail, and I'll scan them and return them.)

yaAGS Debugging Mode (--debug)

Important Note!
The description that follows covers the "classic" debugging mode for versions prior to 20090427.  I retain this description as-is for the benefit of those using one of those versions of yaAGS.  However, for versions 20090427 and later, command-line debugging is in the process of changing to a style more closely related to that of the widely used gdb program, and the "classic" mode described below will gradually disappear.  Since these changes have been driven by Onno Hommes, we have agreed that Onno will maintain documentation for the new debugging mode at his website.

When the "--debug" command-line switch is used, a mode is entered in which AGS programs can be debugged.  This mode is very primitive compared (for example) to the facilities provided by a debugging program like gdb, but has been pretty useful for my purposes, and may conceivably be useful for yours.  You are unlikely to find this mode (or my description of the mode!) of any use unless you are very familiar with AGS assembly language, and are writing/debugging AGS code.  In this mode, rather than simply running the software contained within the core image, yaAGS halts prior to executing the first instruction of the program and allows you to interactively determine its further actions.  You are presented with a status message and a prompt from which you can enter commands.

The debugging mode's status display may look something like this:

Stopped because program loaded.
A=000000        Q=000000        Overflow=0      Index=000       Halted=0
Icount=1        Cycles=0

6000  706177    DLY     6177
>

We see the current values (in octal) of various important CPU registers.  All numerical values displayed by the debugger are in octal, because octal notation is used almost exclusively throughout  existing AGS code, and because almost all of the numerical values reported by the LEMAP assembler were in octal.  The values shown are for:
The final status line is, of course, a disassembly of the next instruction scheduled to be executed.  It shows the current address (6000), the octal value of the instruction (706177), and a disassembly of that octal value into assembly-language (DLY 6177).  The debugging mode does not currently understand any labels defined within the AGS program itself; therefore, understanding code like "DLY 6177" as something like "DLY INIT" (involving labels) is aided by having a symbol table or assembly listing at hand.

The debugger understands addresses in one of three formats:
  1. Addresses within memory are represented by a single octal number, such as 1234.  Modifiable memory is in the range 0000-3777, while non-modifiable memory is in the range 4000-7777.
  2. Addresses within input-channel space (i.e., accessed by the INP instruction) are prefixed by 'I', such as I2020.
  3. Addresses within output-channel space (i.e., accessed by the OUT instruction) are prefixed by 'O', such as O2020.  There is also a fictional output register O0, which is used by yaAGS to combine all of the discrete outputs.  The bit positions within O0 correspond to the AEA CPU's discrete outputs as follows:
0001   Ripple Carry Inhibit discrete
0002   Altitude discrete
0004   Altitude Rate discrete
0010   DEDA Shift In discrete
0020   DEDA Shift Out discrete
0040   GSE Discrete 4
0100   GSE Discrete 5
0200   GSE Discrete 6
0400   Test Mode Failure discrete
1000   Engine Off discrete
2000   Engine On discrete

Within the status display's instruction-disassembly, the distinction between memory locations and i/o channels is always obvious, so i/o channel numbers are not prefixed by 'I' or 'O' in disassemblies.

The user-commands which are currently recognized by the debugger are:
PC
A
Q
OVERFLOW
INDEX
HALT


Last modified by Ronald Burkey on 2010-02-20.

Virtual AGC is hosted by ibiblio.org