Apollo Guidance Computer

From Wikipedia, the free encyclopedia

This article's citation style may be unclear. The references used may be clearer with a different or consistent style of citation, footnoting, or external linking.

The Apollo Guidance Computer (AGC) was the first recognizably modern embedded system, used in real-time by astronaut pilots to collect and provide flight information, and to automatically control all of the navigational functions of the Apollo spacecraft. It was developed in the early 1960s for the Apollo program by the MIT Instrumentation Laboratory under Charles Stark Draper, with hardware design led by Eldon C. Hall. Based upon MIT documents, early architectural work seems to have come from J.H. Laning Jr., Albert Hopkins, Ramon Alonso,^[1] and Hugh Blair-Smith.^[2] The actual flight hardware was fabricated by Raytheon, whose Herb Thaler^[3] was also on the architectural team.

The display and keyboard (Dsky) user interface of the Apollo Guidance Computer (AGC) mounted on the control panel of the command module (CM), with Flight Director Attitude Indicator (FDAI) above.

Partial list of numeric codes for verbs and nouns in the Apollo Guidance Computer. For quick reference, they were printed on a side panel.

[edit] AGC in Apollo

Each flight to the Moon (with the exception of Apollo 8, which didn't take a Lunar Module on its lunar orbit mission) had two AGCs, one each in the command module and the lunar module. The AGC in the command module was at the center of that spacecraft's guidance & navigation system (G&C). The AGC in the Lunar Module ran its Primary Guidance, Navigation and Control System, called by the acronym PGNCS (pronounced pings).

Each lunar mission also had two additional computers:

• A flight computer on the Saturn V booster instrumentation ring called the Launch Vehicle Digital Computer (LVDC)—a serial computer built by IBM Federal Systems Division.
• A small machine in the lunar module's Abort Guidance System (AGS), built by TRW, to be used in the event of failure of the PGNCS. The AGS could be used to take off from the Moon, and to rendezvous with the command module, but not for landing.

[edit] Applications outside Apollo

The AGC formed the basis of an experimental fly-by-wire system installed into an F-8 Crusader to demonstrate the practicality of computer driven FBW system. The AGC used in the first phase of the program was replaced with another machine in the second phase, and research done on the program led to the development of FBW systems for the Space Shuttle. The AGC also led, albeit indirectly, to the development of FBW for the generation of fighters that were being developed at the time.^[4]

[edit] Description

The Apollo flight computer was the first to use integrated circuits (ICs). The Block I version used 4,100 ICs, each containing a single 3-input nor logic gate. The later Block II version used dual 3-input nor gates in a flat-pack, approximately 5,600 gates in all. The gates were made by Fairchild Semiconductor using resistor-transistor logic (RTL). They were interconnected by a technique called wire wrap, in which the circuits are pushed into sockets, the sockets have square posts, and wire is wrapped around the posts. The edges of the posts press against the wire with very high pressure, causing gas-tight connections that are more reliable than soldered PC boards. The wiring was then embedded in cast epoxy plastic. The decision to use a single IC design throughout the AGC avoided problems that plagued another early IC computer design, the Minuteman II guidance computer, which used a mix of diode-transistor logic (DTL) and diode logic (DL) gates made by Texas Instruments.

The computer's RAM was magnetic core memory (2 kibiwords) and ROM was implemented as core rope memory (36 kibiwords). Both had cycle times of 11.72 ms. The memory word length was 16 bits: 15 bits of data and 1 odd-parity bit. The CPU-internal 16-bit word format was 14 bits of data, 1 overflow bit, and 1 sign bit (ones' complement representation).

[edit] Dsky user interface

Apollo computer Dsky user interface unit.

LM Dsky interface diagram.

The user interface unit was called the Dsky.^[5] Dsky stood for display and keyboard and was usually pronounced dis-key. It had an array of numeric displays and a calculator-style keyboard. Commands were entered numerically, as two-digit numbers: program, verb, and noun. The numerals were green high-voltage electroluminescent seven segment displays. The segments were driven by electromechanical relays, which limited the display update rate (Block II used faster silicon controlled rectifiers). Three 5-digit signed numbers could also be displayed in octal or decimal. These were typically used to display vectors such as space craft attitude or a required velocity change (delta-V). This calculator-style interface^{[nb 1]} was the first of its kind, the prototype for all similar digital control panel interfaces.

The command module (CM) had two Dskys; one located on the main instrument panel and another located in the lower equipment bay near a sextant used for aligning the inertial guidance platform. Both Dskys were driven by the same AGC. The lunar module (LM) had a single Dsky for its AGC. A Flight Director Attitude Indicator (FDAI), controlled by the AGC, was located above the Dsky on the commander's console and on the LM.

[edit] Timing

The AGC was controlled by a 2.048 MHz crystal clock. The clock was divided by two to produce a four-phase 1.024 MHz clock which the AGC used to perform internal operations. The 1.024 MHz clock was also divided by two to produce a 512 kHz signal called the master frequency; this signal was used to synchronize external Apollo spacecraft systems.

The master frequency was further divided through a scaler, first by five using a ring counter to produce a 102.4 kHz signal. This was then divided by two through 17 successive stages called F1 (51.2 kHz) through F17 (0.78125 Hz). The F10 stage (100 Hz) was fed back into the AGC to increment the real-time clock and other involuntary counters using Pinc (discussed below). The F17 stage was used to intermittently run the AGC when it was operating in the standby mode.

[edit] Central registers

The AGC had four 16-bit registers for general computational use. These were called the central registers:

A

The accumulator, used for general computation

Z

The program counter, which contained the address of the next instruction to be executed

Q

Used to hold the remainder in the DV instruction, and to hold the return address after TC instructions

LP

Used to hold the lower product after MP instructions

There were also four locations in core memory, at addresses 20-23, dubbed editing locations because whatever was stored there would emerge shifted or rotated by one bit position, except for one that shifted right 7 bit positions, to extract one of the 7-bit interpretive op. codes that were packed 2 to a word. This was common to Block I and Block II AGCs.

[edit] Other registers

The AGC had additional registers that were used internally in the course of operation. These were:

S

The 12-bit memory address register, which held the lower portion of the memory address

Bank or Fbank

The 4-bit ROM bank register, which selected the 1 kibiword ROM bank when addressing was in the fixed-switchable mode

Ebank

The 3-bit RAM bank register, which selected the 256-word RAM bank when addressing was in the erasable-switchable mode

Sbank (super-bank)

The 1-bit extension to Fbank, required because the last 4 kibiwords of the 36-kibiword ROM was not reachable using Fbank alone

SQ

The 4-bit sequence register, which held the current instruction

G

The 16-bit memory buffer register, which held data words moving to and from memory

X

Used to hold one of the two inputs to the adder; the adder was used to perform all 1's complement arithmetic, and to increment the program counter (Z register)

Y

Used to hold the other input to the adder

U

Not really a register, but the output of the adder (the 1's complement sum of the contents of registers X and Y

B

A general-purpose buffer register, also used to pre-fetch the next instruction. At the start of the next instruction sequence, the upper bits of B (containing the next op. code) were copied to SQ, and the lower bits (the address) were copied to S.

C

Not a separate register, but a different output from the B register, containing the 1's complement of the contents of B

IN

Four 16-bit input registers

OUT

Five 16-bit output registers

[edit] Instruction set

The instruction format was 3 bits for opcode, 12 bits for address. Block I had 11 instructions: TC, CCS, INDEX, XCH, CS, TS, AD, and MASK (basic), and SU, MP, and DV (extra). The first eight, called basic instructions, were directly accessed by the 3-bit op. code. The final three were denoted as extracode instructions because they were accessed by performing a special type of INDEX instruction (called EXTEND) immediately before the instruction.

The Block I AGC instructions consisted of the following:

TC (transfer control)

An unconditional branch to the address specified by the instruction. The return address was automatically stored in the Q register, so the TC instruction could be used for subroutine calls.

CCS (count, compare, and skip)

A complex conditional branch instruction. The A register was loaded with data retrieved from the address specified by the instruction. (Because the AGC uses ones' complement notation, there are two representations of zero. When all bits are set to zero, this is called plus zero. If all bits are set to one, this is called minus zero.) The diminished absolute value (DABS) of the data was then computed and stored in the A register. If the number was greater than zero, the DABS decrements the value by 1; if the number was negative, it is complemented before the decrement is applied—this is the absolute value. Diminished means "decremented but not below zero". Therefore, when the AGC performs the DABS function, positive numbers will head toward plus zero, and so will negative numbers but first revealing their negativity via the four-way skip below. The final step in CCS is a four-way skip, depending upon the data in register A before the DABS. If register A was greater than 0, CCS skips to the first instruction immediately after CCS. If register A contained plus zero, CCS skips to the second instruction after CCS. Less than zero causes a skip to the third instruction after CCS, and minus zero skips to the fourth instruction after CCS. The primary purpose of the count was to allow an ordinary loop, controlled by a positive counter, to end in a CCS and a TC to the beginning of the loop, equivalent to an IBM 360's BCT. The absolute value function was deemed important enough to be built into this instruction; when used for only this purpose, the sequence after the CCS was TC *+2, TC *+2, AD ONE. A curious side effect was the creation and use of CCS-holes when the value being tested was known to be never positive, which occurred more often than you might suppose. That left two whole words unoccupied, and a special committee was responsible for assigning data constants to these holes.

INDEX

Add the data retrieved at the address specified by the instruction to the next instruction. INDEX can be used to add or subtract an index value to the base address specified by the operand of the instruction that follows INDEX. This method is used to implement arrays and table look-ups; since the addition was done on both whole words, it was also used to modify the op. code in a following (extracode) instruction, and on rare occasions both functions at once.

RESUME

A special instance of INDEX (INDEX 25). This is the instruction used to return from interrupts. It causes execution to resume at the interrupted location.

XCH (exchange)

Exchange the contents of memory with the contents of the A register. If the specified memory address is in fixed (read-only) memory, the memory contents are not affected, and this instruction simply loads register A. If it is in erasable memory, overflow "correction" is achieved by storing the leftmost of the 16 bits in A as the sign bit in memory, but there is no exceptional behavior like that of TS.

CS (clear and subtract)

Load register A with the one's complement of the data referenced by the specified memory address.

TS (transfer to storage)

Store register A at the specified memory address. TS also detects, and corrects for, overflows in such a way as to propagate a carry for multi-precision add/subtract. If the result has no overflow (leftmost 2 bits of A the same), nothing special happens; if there is overflow (those 2 bits differ), the leftmost one goes the memory as the sign bit, register A is changed to +1 or -1 accordingly, and control skips to the second instruction following the TS. Whenever overflow is a possible but abnormal event, the TS was followed by a TC to the no-overflow logic; when it is a normal possibility (as in multi-precision add/subtract), the TS is followed by CAF ZERO (CAF = XCH to fixed memory) to complete the formation of the carry (+1, 0, or -1) into the next higher-precision word. Angles were kept in single precision, distances and velocities in double precision, and elapsed time in triple precision.

AD (add)

Add the contents of memory to register A and store the result in A. The 2 leftmost bits of A may be different (overflow state) before and/or after the AD. The fact that overflow is a state rather than an event forgives limited extents of overflow when adding more than two numbers, as long as none of the intermediate totals exceeds twice the capacity of a word.

MASK

Perform a bit-wise (boolean) and of memory with register A and store the result in register A.

MP (multiply)

Multiply the contents of register A by the data at the referenced memory address and store the high-order product in register A and the low-order product in register LP. The parts of the product agree in sign.

DV (divide)

Divide the contents of register A by the data at the referenced memory address. Store the quotient in register A and the absolute value of the remainder in register Q. Unlike modern machines, fixed-point numbers were treated as fractions (notional decimal point just to right of the sign bit), so you could produce garbage if the divisor was not larger than the dividend; there was no protection against that situation. In the Block II AGC, a double-precision dividend started in A and L (the Block II LP), and the correctly signed remainder was delivered in L. That considerably simplified the subroutine for double precision division.

SU (subtract)

Subtract (one's complement) the data at the referenced memory address from the contents of register A and store the result in A.

Instructions were implemented in groups of 12 steps, called timing pulses. The timing pulses were named TP1 through TP12. Each set of 12 timing pulses was called an instruction subsequence. Simple instructions, such as TC, executed in a single subsequence of 12 pulses. More complex instructions required several subsequences. The multiply instruction (MP) used 8 subsequences: an initial one called MP0, followed by an MP1 subsequence which was repeated 6 times, and then terminated by an MP3 subsequence. This was reduced to 3 subsequences in Block II.

Each timing pulse in a subsequence could trigger up to 5 control pulses. The control pulses were the signals which did the actual work of the instruction, such as reading the contents of a register onto the bus, or writing data from the bus into a register.

[edit] Memory

Apollo AGC 1024 bit memory module (front and back).

Block I AGC memory was organized into 1 kibiword banks. The lowest bank (bank 0) was erasable memory (RAM). All banks above bank 0 were fixed memory (ROM). Each AGC instruction had a 12-bit address field. The lower bits (1-10) addressed the memory inside each bank. Bits 11 and 12 selected the bank: 00 selected the erasable memory bank; 01 selected the lowest bank (bank 1) of fixed memory; 10 selected the next one (bank 2); and 11 selected the Bank register that could be used to select any bank above 2. Banks 1 and 2 were called fixed-fixed memory, because they were always available, regardless of the contents of the Bank register. Banks 3 and above were called fixed-switchable because the selected bank was determined by the bank register.

The Block I AGC initially had 12 kibiwords of fixed memory, but this was later increased to 24 kibiwords. Block II had 32 kibiwords of fixed memory and 4 kibiwords of erasable memory.

The AGC transferred data to and from memory through the G register in a process called the memory cycle. The memory cycle took 12 timing pulses (11.72 μs). The cycle began at timing pulse 1 (TP1) when the AGC loaded the memory address to be fetched into the S register. The memory hardware retrieved the data word from memory at the address specified by the S register. Words from erasable memory were deposited into the G register by timing pulse 6 (TP6); words from fixed memory were available by timing pulse 7. The retrieved memory word was then available in the G register for AGC access during timing pulses 7 through 10. After timing pulse 10, the data in the G register was written back to memory.

The AGC memory cycle occurred continuously during AGC operation. Instructions needing memory data had to access it during timing pulses 7-10. If the AGC changed the memory word in the G register, the changed word was written back to memory after timing pulse 10. In this way, data words cycled continuously from memory to the G register and then back again to memory.

The lower 15 bits of each memory word held AGC instructions or data. Each word protected by a 16th odd parity bit. This bit was set to 1 or 0 by a parity generator circuit so a count of the 1s in each memory word would always produce an odd number. A parity checking circuit tested the parity bit during each memory cycle; if the bit didn't match the expected value, the memory word was assumed to be corrupted and a parity alarm panel light was illuminated.

[edit] Interrupts and involuntary counters

The AGC had five vectored interrupts:

• Dsrupt was triggered at regular intervals to update the user display (Dsky).
• Errupt was generated by various hardware failures or alarms.
• Keyrupt signaled a key press from the user's keyboard.
• T3Rrupt was generated at regular intervals from a hardware timer to update the AGC's real-time clock.
• Uprupt was generated each time a 16-bit word of uplink data was loaded into the AGC.

The AGC responded to each interrupt by temporarily suspending the current program, executing a short interrupt service routine, and then resuming the interrupted program.

The AGC also had 20 involuntary counters. These were memory locations which functioned as up/down counters, or shift registers. The counters would increment, decrement, or shift in response to internal inputs. The increment (Pinc), decrement (Minc), or shift (Shinc) was handled by one subsequence of microinstructions inserted between any two regular instructions.

Interrupts could be triggered when the counters overflowed. The T3rupt and Dsrupt interrupts were produced when their counters, driven by a 100 Hz hardware clock, overflowed after executing many Pinc subsequences. The Uprupt interrupt was triggered after its counter, executing the Shinc subsequence, had shifted 16 bits of uplink data into the AGC.

[edit] Standby mode

The AGC had a power-saving mode controlled by a standby allowed switch. This mode turned off the AGC power, except for the 2.048 MHz clock and the scaler. The F17 signal from the scaler turned the AGC power and the AGC back on at 1.28 second intervals. In this mode, the AGC performed essential functions, checked the standby allowed switch, and, if still enabled, turned off the power and went back to sleep until the next F17 signal.

In the standby mode, the AGC slept most of the time; therefore it was not awake to perform the Pinc instruction needed to update the AGC's real time clock at 10 ms intervals. To compensate, one of the functions performed by the AGC each time it awoke in the standby mode was to update the real time clock by 1.28 seconds.

The standby mode was designed to reduce power by 5 to 10 W (from 70 W) during midcourse flight when the AGC was not needed. However, in practice, the AGC was left on during all phases of the mission and this feature was never used.

[edit] Data buses

The AGC had a 16-bit read bus and a 16-bit write bus. Data from central registers (A, Q, Z, or LP), or other internal registers could be gated onto the read bus with a control signal. The read bus connected to the write bus through a non-inverting buffer, so any data appearing on the read bus also appeared on the write bus. Other control signals could copy write bus data back into the registers.

Data transfers worked like this: To move the address of the next instruction from the B register to the S register, an RB (read B) control signal was issued; this caused the address to move from register B to the read bus, and then to the write bus. A WS (write S) control signal moved the address from the write bus into the S register.

Several registers could be read onto the read bus simultaneously. When this occurred, data from each register was inclusive-ored onto the bus. This inclusive-or feature was used to implement the Mask instruction, which was a logical and operation. Because the AGC had no native ability to do a logical and, but could do a logical or through the bus and could complement (invert) data through the C register, De Morgan's theorem was used to implement the equivalent of a logical and. This was accomplished by inverting both operands, performing a logical or through the bus, and then inverting the result.

[edit] Software

AGC software was written in AGC assembly language and stored on rope memory. There was a simple real-time operating system consisting of the Exec, a batch job-scheduling system that could run up to 8 'jobs' at a time using non-preemptive multi-tasking (each job had to periodically surrender control back to the Exec). There was also an interrupt-driven component called the Waitlist which could schedule multiple timer-driven 'tasks'. The tasks were short threads of execution which could reschedule themselves for re-execution on the Waitlist, or could kick off a longer operation by starting a 'job' with the Exec.

The Exec jobs were priority-based. The lowest priority job, called the dummy job, was always present. It did diagnostic checks and controlled a green computer activity light on the Dsky display: If the dummy job was running, this meant the computer had nothing better to do, so the light was turned off. The dummy job exited if there was some higher priority job to be done and this was indicated by the computer activity light being illuminated.

The AGC also had a sophisticated software interpreter that implemented a virtual machine with more complex and capable instructions than the native AGC. Interpreted code, which featured double precision scalar and vector arithmetic, even an MXV (matrix × vector) instruction, could be mixed with native AGC code. The assembler and version control system, named YUL for an early prototype Christmas Computer, enforced proper transitions between native and interpreted code.

A set of interrupt-driven user interface routines called Pinball provided keyboard and display services for the jobs and tasks running on the AGC. A rich set of user-accessible routines were provided to let the operator (astronaut) display the contents of various memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time. Monitor routines were provided so the operator could initiate a task to periodically redisplay the contents of certain memory locations. Jobs could be initiated. The Pinball routines performed the (very rough) equivalent of the UNIX shell.

[edit] The Block II

A Block II version of the AGC was designed in 1966. It retained the basic Block I architecture, but increased erasable memory from 1 to 2 kibiwords. Fixed memory was expanded from 24 to 36 kibiwords. Instructions were expanded from 11 to 34 and I/O channels were implemented to replace the I/O registers on Block I. The Block II version is the one that actually flew to the moon. Block I was used during the unmanned Apollo 4 and 6 flights, and was onboard the ill-fated Apollo I.

The decision to expand the memory and instruction set for Block II, but to retain the Block I's restrictive 3-bit op. code and 12-bit address had interesting design consequences. Various tricks were employed to squeeze in additional instructions, such as having special memory addresses which, when referenced, would implement a certain function. For instance, an INDEX to address 25 triggered the RESUME instruction to return from an interrupt. Likewise, INDEX 17 performed an INHINT instruction (inhibit interrupts), while INDEX 16 reenabled them (RELINT). Other instructions were implemented by preceding them with a special version of INDEX called EXTEND which arithmetically modified the 3-bit op. code by employing the overflow bit to extend it. The address spaces were extended by employing the Bank (fixed) and Ebank (erasable) registers, so the only memory of either type that could be addressed at any given time was the current bank, plus the small amount of fixed-fixed memory and the erasable memory. In addition, the bank register could address a maximum of 32 kibiwords, so an Sbank (super-bank) register was required to access the last 4 kibiwords. All across-bank subroutine calls had to be initiated from fixed-fixed memory through special functions to restore the original bank during the return—essentially a system of far pointers.

The Block II AGC also has the mysterious and poorly documented EDRUPT instruction (the name may be a contraction of Ed's Interrupt, after Ed Smally, the programmer who requested it) which is used a total of once in the Apollo software: in the Digital Autopilot of the Lunar Module. At this time, while the general operation of the instruction is understood, the precise details are still hazy, and it is believed to be responsible for problems emulating the LEM AGC Luminary software.

[edit] PGNCS trouble

The PGNC System malfunctioned during the first live lunar descent, with the AGC showing a 1201 alarm ("Executive overflow - no vacant areas") and a 1202 alarm ("Executive overflow - no core sets").^[6] In both cases these errors were caused by spurious data from the rendezvous radar, which had been left on during the descent. When the separate landing radar acquired the lunar surface and the AGC began processing this data too, these overflow errors automatically aborted the computer's current task, but the frequency of radar data still meant the abort signals were being sent at too great a rate for the CPU to cope.^[7]

Happily for Apollo 11, the AGC software executed a fail-safe routine and shed its low-priority tasks. The critical inertial guidance tasks continued to operate reliably. The degree of overload was minimal because the software had been limited so as to leave very nearly 15% available spare time which, wholly by luck, nearly matched the 6400 bit/s pulse trains from the needless, rendezvous-radar induced Pincs, wasting exactly 15% of the AGC's time. On the instructions of Steve Bales and Jack Garman these errors were ignored and the mission was a success.

The problem was caused by neither a programming error in the AGC nor by pilot error. It was a procedural (protocol) and simulation error. In the simulator, the astronauts had been trained to set the rendezvous radar switch to its auto position. However, there was no connection to a live radar in the simulator and the problem was never seen until the procedure was carried out on Apollo 11's lunar descent when the switch was connected to a real AGC, the landing radar began sending data and the onboard computer was suddenly and very unexpectedly tasked with processing data from two real radars.^[8]

[edit] 00404 error code

The computer's other error codes included error 00404, which was shorthand for "IMU orientation unknown". Since the Inertial Measurement Unit device literally told the craft where to go, this has been compared to the HTTP 404 not found or browser navigation error code used on the World Wide Web. However, the later familiar HTTP error code did not originate with the AGC.^[9]

[edit] Notes

[edit] References

• Hall, Eldon C. (1996). Journey to the Moon: The History of the Apollo Guidance Computer. AIAA. ISBN 1-56347-185-X.

[edit] See also

• AP-101 (IBM S/360-derived) computers used in the Space Shuttle
• History of computer hardware

[edit] External links

Documentation on the AGC and its development:

• AGC4 Memo #9, Block II Instructions – The infamous memo that served as de facto official documentation of the instruction set
• Computers in Spaceflight: The NASA Experience – By James Tomayko (Chapter 2, Part 5, The Apollo guidance computer: Hardware)
• Computers Take Flight – By James Tomayko
• The Apollo Guidance Computer - A Users View (PDF) – By David Scott, Apollo mission astronaut
• Lunar Module Attitude Controller Assembly Input Processing (PDF) – By José Portillo Lugo, History of Technology
• The MIT AGC Project – With comprehensive document archive
  • Luminary software source code listing, for Lunar Module guidance computer.
  • Colossus software source code listing, for Command Module guidance computer.
• National Air and Space Museum's AGC Block I and Dsky
• The Lunar Module Computer – From in Space: our gateway to the stars by the Australian Broadcasting Corporation (1999)
• Annotations to Eldon Hall's Journey to the Moon – An AGC system programmer discusses some obscure details of the development of AGC, including specifics of Ed's Interrupt

Documentation of AGC hardware design, and particularly the use of the new integrated circuits in place of transistors:

• Apollo Guidance Computer Schematics
• AGC Integrated Circuit Packages
• Integrated Circuits in the Apollo Guidance Computer

Documentation of AGC software operation:

• Delco Electronics, Apollo 15 - Manual for CSM and LEM AGC software used on the Apollo 15 mission, including detailed user interface procedures, explanation of many underlying algorithms and limited hardware information. Note that this document has over 500 pages and is over 150 megabytes in size.

Some AGC-based technology history projects:

• AGC Replica – John Pultorak's successful project to build a hardware replica of the Block I AGC in his basement
• Virtual AGC Home Page – Ronald Burkey's AGC simulator, plus source and binary code recovery for the Colossus (CSM) and Luminary (LEM) SW
• Project Apollo for Orbiter – Addon for Orbiter spaceflight simulator, working towards a full simulation of the CSM and LEM including the Virtual AGC.
• Eagle Lander 3D Shareware Lunar Lander Simulator with a working AGC and Dsky (Windows only)