Apollo Guidance Computer

The Apollo Guidance Computer (AGC) was a digital computer produced for the Apollo program that was installed on board each Apollo command module (CM) and Apollo Lunar Module (LM). The AGC provided computation and electronic interfaces for guidance, navigation, and control of the spacecraft.[3] The AGC has a 16-bit word length, with 15 data bits and one parity bit. Most of the software on the AGC is stored in a special read-only memory known as core rope memory, fashioned by weaving wires through magnetic cores, though a small amount of read-write core memory is available.

Astronauts communicated with the AGC using a numeric display and keyboard called the DSKY (for display&keyboard, pronounced 'DISS-key'). The AGC and its DSKY user interface were developed in the early 1960s for the Apollo program by the MIT Instrumentation Laboratory and first flew in 1966.[4] The AGC was one of the first integrated circuit-based computers. The computer's performance was comparable to the first generation of home computers from the late 1970s, such as the Apple II, TRS-80, and Commodore PET.[5]

Apollo Guidance Computer
Agc view
Apollo Guidance Computer and DSKY
Invented byCharles Stark Draper Laboratory
IntroducedAugust 1966
DiscontinuedJuly 1975
Guidance Computer
ProcessorDiscrete IC RTL based
Frequency2.048 MHz
Memory15-bit wordlength + 1-bit parity,
2048 words RAM (magnetic-core memory), 36,864 words ROM (core rope memory)[1]
PortsDSKY, IMU, Hand Controller, Rendezvous Radar (CM), Landing Radar (LM), Telemetry Receiver, Engine Command, Reaction Control System
Power consumption55 W[2]:120
Weight70 lb (32 kg)
Dimensions24×12.5×6.5 inches (61×32×17 cm)


Astronauts manually flew Project Gemini with control sticks, but computers flew most of Project Apollo except briefly during lunar landings.[6] Each Moon flight carried two AGCs, one each in the command module and the lunar module, with the exception of Apollo 8 which did not need a lunar module for its lunar orbit mission. The AGC in the command module was the center of its guidance, navigation and control (GNC) system. The AGC in the lunar module ran its Apollo PGNCS (primary guidance, navigation and control system), with the acronym pronounced as pings.

The display and keyboard (DSKY) interface of the Apollo Guidance Computer mounted on the control panel of the command module, with the flight director attitude indicator (FDAI) above
Agc verb-noun-list
Partial list of numeric codes for verbs and nouns in the Apollo Guidance Computer, printed for quick reference on a side panel

Each lunar mission had two additional computers:

  • The Launch Vehicle Digital Computer (LVDC) on the Saturn V booster instrumentation ring
  • the Abort Guidance System (AGS, pronounced ags) of the lunar module, to be used in the event of failure of the LM PGNCS. The AGS could be used to take off from the Moon, and to rendezvous with the command module, but not to land.


Agc flatp
Flatpack integrated circuits in the Apollo guidance computer

The AGC was designed at the MIT Instrumentation Laboratory under Charles Stark Draper, with hardware design led by Eldon C. Hall.[2] Early architectural work came from J.H. Laning Jr., Albert Hopkins, Richard Battin, Ramon Alonso,[7] [8] and Hugh Blair-Smith.[9] The flight hardware was fabricated by Raytheon, whose Herb Thaler[10] was also on the architectural team.

The Apollo flight computer was the first computer to use integrated circuits (ICs). While the Block I version used 4,100 ICs, each containing a single three-input NOR gate, the later Block II version (used in the crewed flights) used 2,800 ICs, each with dual three-input NOR gates.[2]:34 The ICs, from Fairchild Semiconductor, were implemented using resistor–transistor logic (RTL) in a flat-pack. They were connected via wire wrap, and the wiring was then embedded in cast epoxy plastic. The use of a single type of IC (the dual NOR3) 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 and diode logic gates. This is possible because NOR gates are universal logic gates from which any other gate can be made, though at the cost of using more gates.

The computer had 2048 words of erasable magnetic-core memory and 36 kilowords of read-only core rope memory. Both had cycle times of 11.72 microseconds. The memory word length was 16 bits: 15 bits of data and one odd-parity bit. The CPU-internal 16-bit word format was 14 bits of data, one overflow bit, and one sign bit (ones' complement representation).

DSKY interface

AGC user interface
Apollo computer DSKY user interface unit
Apollo DSKY interface
LM DSKY interface diagram

The user interface to the AGC was the DSKY, standing for display and keyboard and usually pronounced dis-key. It had an array of indicator lights, numeric displays and a calculator-style keyboard. Commands were entered numerically, as two-digit numbers: Verb, and Noun. Verb described the type of action to be performed and Noun specified which data was affected by the action specified by the Verb command.

The numerals were displayed via green high-voltage electroluminescent seven-segment displays. The segments were driven by electromechanical relays, which limited the display update rate. Three five-digit signed numbers could also be displayed in octal or decimal, and were typically used to display vectors such as space craft attitude or a required velocity change (delta-V). Although data was stored internally in metric units, they were displayed as United States customary units. This calculator-style interface[nb 1] was the first of its kind, the prototype for all similar digital control panel interfaces.

The command module had two DSKYs connected to its AGC: one located on the main instrument panel and a second located in the lower equipment bay near a sextant used for aligning the inertial guidance platform. The lunar module 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.

In 2009, a DSKY was sold in a public auction held by Heritage Auctions for $50,788.[11]


The AGC timing reference came from 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.

Central registers

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

A: The accumulator, for general computation
Z: The program counter – the address of the next instruction to be executed
Q: The remainder from the DV instruction, and the return address after TC instructions
LP: 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 seven bit positions, to extract one of the seven-bit interpretive op. codes that were packed two to a word. This was common to Block I and Block II AGCs.

Other registers

DSKY and AGC on display at the Computer History Museum. The AGC is opened up, showing its logic modules.
Prototype logic module from Block I AGC
Agc mount
Block II logic module, with flat-pack ICs
Agc nor2
AGC dual 3-input NOR gate
Agc nor2a
AGC dual 3-input NOR gate schematic

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

S : 12-bit memory address register, the lower portion of the memory address
Bank/Fbank : 4-bit ROM bank register, to select the 1 kiloword ROM bank when addressing in the fixed-switchable mode
Ebank : 3-bit RAM bank register, to select the 256-word RAM bank when addressing in the erasable-switchable mode
Sbank (super-bank) : 1-bit extension to Fbank, required because the last 4 kilowords of the 36-kiloword ROM was not reachable using Fbank alone
SQ : 4-bit sequence register; the current instruction
G : 16-bit memory buffer register, to hold data words moving to and from memory
X : The 'x' input to the adder (the adder was used to perform all 1's complement arithmetic) or the increment to the program counter (Z register)
Y : The other ('y') 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 : General-purpose buffer register, also used to pre-fetch the next instruction. At the start of the next instruction, 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 the 1's complement of the B register
IN : Four 16-bit input registers
OUT : Five 16-bit output registers

Instruction set

The instruction format used 3 bits for opcode, and 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 TC 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 one might suppose. That left two whole words unoccupied, and a special committee was responsible for assigning data constants to these holes.
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.
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 exceed twice the capacity of a word.
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.


Apollo 1024 bit core memory module
Apollo AGC 1024-bit erasable core memory module (front and back)

Block I AGC memory was organized into 1 kiloword 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 kilowords of fixed memory, but this was later increased to 24 kilowords. Block II had 36 kilowords of fixed memory and 2 kilowords 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, with each word being 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.

Interrupts and involuntary counters

The AGC had five vectored interrupts:

  • Dsrupt was triggered at regular intervals to update the user display (DSKY).
  • Erupt 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.

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.

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.


Margaret Hamilton - restoration
Margaret Hamilton standing next to listings of the software she and her MIT team produced for the Apollo Project.[12]

AGC software was written in AGC assembly language and stored on rope memory. The bulk of the software was on read-only rope memory and thus couldn't be changed in operation,[13] but some key parts of the software were stored in standard read-write magnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done on Apollo 14.

The design principles developed for the AGC by MIT Instrumentation Laboratory, directed in late 1960s by Charles Draper, became foundational to software engineering—particularly for the design of more reliable systems that relied on asynchronous software, priority scheduling, testing, and human-in-the-loop decision capability.[14] When the design requirements for the AGC were defined, necessary software and programming techniques did not exist so it had to be designed from scratch.

There was a simple real-time operating system designed by J. Halcombe Laning,[15] consisting of the Exec, a batch job-scheduling using cooperative multi-tasking[16] and an interrupt-driven pre-emptive scheduler 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 AGC also had a sophisticated software interpreter, developed by the MIT Instrumentation Laboratory, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC. These instructions simplified the navigational programs. Interpreted code, which featured double precision trigonometric, scalar and vector arithmetic (16 and 24-bit), even an MXV (matrix × vector) instruction, could be mixed with native AGC code. While the execution time of the pseudo-instructions was increased (due to the need to interpret these instructions at runtime) the interpreter provided many more instructions than AGC natively supported and the memory requirements were much lower than in the case of adding these instructions to the AGC native language which would require additional memory built into the computer (at that time the memory capacity was very expensive). The average pseudo-instruction required about 24 ms to execute. The assembler and version control system, named YUL for an early prototype Christmas Computer,[17] 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.

Many of the trajectory and guidance algorithms used were based on earlier work by Richard Battin.[15] The first command module flight was controlled by a software package called CORONA whose development was led by Alex Kosmala. Software for lunar missions consisted of COLOSSUS for the command module, whose development was led by Frederic Martin, and LUMINARY on the lunar module led by George Cherry. Details of these programs were implemented by a team under the direction of Margaret Hamilton.[18] Hamilton was very interested in how the astronauts would interact with the software and predicted the types of errors that could occur due to human error.[16][18] In total, software development on the project comprised 1400 person-years of effort, with a peak workforce of 350 people.[15] In 2016, Hamilton received the Presidential Medal of Freedom for her role in creating the flight software.

The Apollo Guidance Computer software influenced the design of Skylab, Space Shuttle and early fly-by-wire fighter aircraft systems.[19][20] The AGC code was uploaded to the internet in 2003, and the software itself was uploaded by a former NASA intern to GitHub on July 7, 2016.[21][22][23]

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 kilowords. Fixed memory was expanded from 24 to 36 kilowords. 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 on board the ill-fated Apollo 1.

The decision to expand the memory and instruction set for Block II, but to retain the Block I's restrictive three-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 TC called EXTEND. 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 kilowords, so an Sbank (super-bank) register was required to access the last 4 kilowords. 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.

PGNCS trouble

PGNCS generated unanticipated warnings during Apollo 11's lunar descent, with the AGC showing a 1201 alarm ("Executive overflow - no vacant areas[24]") and a 1202 alarm ("Executive overflow - no core sets").[25] The cause was a rapid, steady stream of spurious cycle steals from the rendezvous radar (tracking the orbiting command module), intentionally left on standby during the descent in case it was needed for an abort.[26][27]

During this part of the approach, the processor would normally be almost 85% loaded. The extra 6,400 cycle steals per second added the equivalent of 13% load, leaving just enough time for all scheduled tasks to run to completion. Five minutes into the descent, Buzz Aldrin gave the computer the command 1668, which instructed it to periodically calculate and display DELTAH (the difference between altitude sensed by the radar and the computed altitude).[nb 2] The 1668 added an additional 10% to the processor workload, causing executive overflow and a 1202 alarm. After being given the "GO" from Houston, Aldrin entered 1668 again and another 1202 alarm occurred. When reporting the second alarm, Aldrin added the comment "It appears to come up when we have a 1668 up". The AGC software had been designed with priority scheduling, and automatically recovered, deleting lower priority tasks including the 1668 display task, to complete its critical guidance and control tasks. Guidance controller Steve Bales and his support team that included Jack Garman issued several "GO" calls and the landing was successful. For his role, Bales received the US Presidential Medal of Freedom on behalf of the entire control center team and the three Apollo astronauts.[28]

The problem was not a programming error in the AGC, nor was it pilot error. It was a peripheral hardware design bug that had already been known and documented by Apollo 5 engineers.[29] However, because the problem had only occurred once during testing, they concluded that it was safer to fly with the existing hardware that they had already tested, than to fly with a newer but largely untested radar system. In the actual hardware, the position of the rendezvous radar was encoded with synchros excited by a different source of 800 Hz AC than the one used by the computer as a timing reference. The two 800 Hz sources were frequency locked but not phase locked, and the small random phase variations made it appear as though the antenna was rapidly "dithering" in position, even though it was completely stationary. These phantom movements generated the rapid series of cycle steals.

J. Halcombe Laning's software and computer design saved the Apollo 11 landing mission. Had it not been for Laning's design, the landing would have been aborted for lack of a stable guidance computer.[30]

Applications outside Apollo

Fly by wire
Fly By Wire testbed aircraft. The AGC DSKY is visible in the avionics bay

The AGC formed the basis of an experimental fly-by-wire (FBW) system installed into an F-8 Crusader to demonstrate the practicality of computer driven FBW. 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 fly-by-wire systems for the Space Shuttle. The AGC also led, albeit indirectly, to the development of fly-by-wire systems for the generation of fighters that were being developed at the time.[31]

The AGC was also used for the United States Navy's Deep Submergence Rescue Vehicle.[32]

See also


  1. ^ The first advanced desktop calculators hit the market in roughly the same time frame, with scientific and then programmable pocket calculators appearing during the following decade. The first programmable handheld calculator, the HP-65, was tried on backup computations aboard the command and service module in the Apollo–Soyuz Test Project in 1975.
  2. ^ More specifically, verb 16 instructs the AGC to print the noun (in this case, 68, DELTAH) approximately twice per second. Had Aldrin known this, a simple 0668 (calculate and display DELTAH, once) would have only added approximately 5% load to the system, and would have only done so once, when ENTER was pressed.


  1. ^ Programmer's Manual, Block 2 AGC Assembly Language, retrieved 2018-08-27
  2. ^ a b c Hall, Eldon C. (1996), Journey to the Moon: The History of the Apollo Guidance Computer, Reston, Virginia, USA: AIAA, p. 196, ISBN 1-56347-185-X
  3. ^ https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20090016290_2009014409.pdf Apollo Guidance, Navigation and Control Hardware Overview
  4. ^ https://history.nasa.gov/computers/Ch2-5.html
  5. ^ "How did the Apollo flight computers get men to the moon and back ?".
  6. ^ Agle, D.C. (September 1998). "Flying the Gusmobile". Air & Space. Retrieved 2018-12-15.
  7. ^ "Ramon Alonso's introduction", AGC History Project (Caltech archive, original site closed), MIT, July 27, 2001, retrieved 2009-08-30
  8. ^ "Ramon Alonso's interview (Spanish)", Ramón Alonso, el argentino que llevó a la Apollo 11 a la Luna, Diario La Nacion, March 7, 2010
  9. ^ "Hugh Blair-Smith biography", AGC History Project (Caltech archive, original site closed), MIT, January 2002, retrieved 2009-08-30
  10. ^ "Herb Thaler introduction", AGC History Project (Caltech archive, original site closed), MIT, 14 September 2001, retrieved 2009-08-30
  11. ^ "Lot 41178 – Apollo Guidance Computer: Original Display and Keyboard (DSKY) Unit". October 8, 2009.
  12. ^ Weinstock, Maia (2016-08-17). "Scene at MIT: Margaret Hamilton's Apollo code". MIT News. Retrieved 2016-08-17.
  13. ^ Mindell 2008, pp. 154, 157.
  14. ^ NASA Press Release "NASA Honors Apollo Engineer" (September 03, 2003)
  15. ^ a b c Hoag, David (September 1976). "The History of Apollo On-board Guidance, Navigation, and Control" (PDF). Charles Stark Draper Laboratory.
  16. ^ a b Mindell 2008, p. 149.
  17. ^ "Hugh Blair-Smith's Introduction", AGC History Project (Caltech archive, original site closed), MIT, 30 November 2001, retrieved 2010-03-21
  18. ^ a b Harvey IV, Harry Gould (13 October 2015). "Her Code Got Humans on the Moon—And Invented Software Itself". WIRED. Retrieved 2018-11-25.
  19. ^ NASA Office of Logic Design "About Margaret Hamilton" (Last Revised: February 03, 2010)
  20. ^ By A.J.S. Rayl "NASA Engineers and Scientists-Transforming Dreams Into Reality"
  21. ^ Collins, Keith. "The code that took America to the moon was just published to GitHub, and it's like a 1960s time capsule". Quartz. Retrieved 19 August 2016.
  22. ^ Garry, Chris. "Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules". GitHub. Retrieved 19 August 2016.
  23. ^ "Earlier (7 April 2015), more complete upload on Github, maintained by iBiblio". Retrieved 24 November 2017.
  24. ^ "chrislgarry/Apollo-11". GitHub. Retrieved 2016-07-17.
  25. ^ Collins, Michael; Aldrin, Edwin (1975), Cortright, Edgar M., ed., "A Yellow Caution Light", NASA SP-350, Apollo Expeditions to the Moon, Washington, DC: NASA, pp. Chapter 11.4, ISBN 978-0486471754, retrieved 2009-08-30
  26. ^ Adler, Peter (1998), Jones, Eric M., ed., "Apollo 11 Program Alarms", Apollo 11 Lunar Surface Journal, NASA, retrieved 2009-09-01
  27. ^ Martin, Fred H. (July 1994), Jones, Eric M., ed., "Apollo 11 : 25 Years Later", Apollo 11 Lunar Surface Journal, NASA, retrieved 2009-09-01
  28. ^ Cortright, Edgar M., ed. (1975), "The Lunar Module Computer", Apollo 11 Lunar Surface Journal, NASA, retrieved 2010-02-04
  29. ^ Eyles, Don (February 6, 2004), "Tales From The Lunar Module Guidance Computer", 27th annual Guidance and Control Conference, Breckenridge, Colorado: American Astronautical Society
  30. ^ Tales From The Lunar Module Guidance Computer
  31. ^ Tomayko, James E. (2000), "NASA SP-2000-4224 — Computers Take Flight: A History of NASA's Pioneering Digital Fly-By-Wire Project" (PDF), The NASA History Series, Washington, D.C.: NASA, retrieved 2009-09-01
  32. ^ Craven, John Pina (2002). The Silent War: The Cold War Battle Beneath the Sea. New York: Simon and Schuster. p. 120. ISBN 0-684-87213-7.


External links

Documentation on the AGC and its development
Documentation of AGC hardware design, and particularly the use of the new integrated circuits in place of transistors
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.
  • Stengel, R., Manual Attitude Control of the Lunar Module, J. Spacecraft and Rockets, Vol. 7, No. 8, August 1970, pp. 941–948.
  • Source code for Command Module code (Comanche054) and Lunar Module code (Luminary099) as text.
  • GitHub Complete Source Code Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.
Some AGC-based projects and simulators
  • AGC Replica – John Pultorak's successful project to build a hardware replica of the Block I AGC in his basement. Mirror site: AGC Replica.
  • Virtual AGC Home Page – Ronald Burkey's AGC simulator, plus source and binary code recovery for the Colossus (CSM) and Luminary (LEM) SW.
  • Moonjs – A web-based AGC simulator based on Virtual AGC.
  • 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).

Feature Stories

Albert L. Hopkins

Albert L. Hopkins Jr. is a computer designer. He worked at the US MIT Instrumentation Laboratory (now known as the Draper Lab) during the development of the Apollo Guidance, Navigation, and Control System, or the GN&C. The system was designed in two forms, one for the command module and one for the lunar module. The CM version included an optical system with an integrated scanning telescope and sextant for erecting and correcting the inertial platform. Albert Hopkins received a Ph.D. from Harvard University under Howard Aiken, he then joined the MIT Instrumentation Lab where he was Assistant Director; together with Ramon Alonso, and Hugh Blair-Smith he was a member of the group that designed the computer, designated AGC for Apollo Guidance Computer, identical in the CM and LM.

The AGC was a 15-bit plus parity machine with a 1 MHz clock. It was about one cubic foot in volume and weighed about 80 pounds. It used integrated circuit NOR gates, two to a package, but integrated RAM and ROM devices had not been developed yet. It had 2,000 words of magnetic ferrite core read-write memory and maybe 24 thousand words of read-only memory in the form of magnetic core ropes. These cores used metal tape magnetic cores. With such limited computing resources, the software had to be extremely tightly written in assembly code. These computers were designed with extremely long mean times to failure. Fifty were built by Raytheon, and none failed during several years of life. The human interface was a keyboard with ten digit keys and a few auxiliary keys for such things as "+" and "–" and "enter", and a display with three numbers of 5 decimal/octal digits, a two-digit program number, and a two-digit verb and a two-digit noun. The astronauts used it for all phases of command.

After leaving Draper Labs, Albert Hopkins, with his wife Lynne Zaccaria, opened a pottery and antiques shop in South Danbury, New Hampshire. Lately they lived in Florida. He died on May 17, 2016. http://www.chadwickfuneralservice.com/fh/obituaries/obituary.cfm?o_id=3724138&fh_id=12966

Apollo Abort Guidance System

The Apollo Abort Guidance System (AGS, also known as Abort Guidance Section) was a backup computer system providing an abort capability in the event of failure of the Lunar Module's primary guidance system (Apollo PGNCS) during descent, ascent or rendezvous. As an abort system, it did not support guidance for a lunar landing.

The AGS was designed by TRW independently of the development of the Apollo Guidance Computer and PGNCS.

It was the first navigation system to use a strapdown Inertial Measurement Unit rather than a gimbaled gyrostabilized IMU (as used by PGNCS). Although not as accurate as the gimbaled IMU, it provided satisfactory accuracy with the help of the optical telescope and rendezvous radar. It was also lighter and smaller in size.

Apollo PGNCS

The Apollo primary guidance, navigation, and control system (PGNCS) (pronounced pings) was a self-contained inertial guidance system that allowed Apollo spacecraft to carry out their missions when communications with Earth were interrupted, either as expected, when the spacecraft were behind the Moon, or in case of a communications failure. The Apollo command module (CM) and lunar module (LM), were each equipped with a version of PGNCS. PGNCS, and specifically its computer, were also the command center for all system inputs from the LM, including the Kollsman Instrument built alignment optical telescope, the radar system, the manual translation and rotation device inputs by the astronauts as well as other inputs from the LM systems.

PGNCS was developed by the MIT Instrumentation Laboratory. The prime contractor for PGNCS and manufacturer of the inertial measurement unit (IMU) was the Delco Division of General Motors. Development was under the direction of Charles Stark Draper and MIT Draper Labs and consisted of the following components:

an inertial measurement unit (IMU)

the Apollo Guidance Computer (AGC)

resolvers to convert inertial platform angles to signals usable for servo control

an optical unit

a mechanical frame, called the navigation base (or navbase), to rigidly connect the optical device and, in the LM, the rendezvous radar to the IMU

the AGC software


AverStar (formerly Intermetrics, Inc.) was a software company founded in Cambridge, Massachusetts in 1969 by several veterans of M.I.T.'s Instrumentation Laboratory who had worked on the software for NASA's Apollo Program including the Apollo Guidance Computer.

The company specialized in compiler technology. It was responsible for the design and implementation of the HAL/S programming language, used to write the Space Shuttle PASS (Primary Avionics Software System). It participated in the design effort leading to the Ada programming language effort, designed the Red language, one of the finalists in the design competition, and wrote one of the first production-quality Ada compilers. The large-scale Ada 95 revision of the language was designed at Intermetrics.

Intermetrics merged with Whitesmiths Ltd. in December 1988. In 1997, Intermetrics merged with computer game developer Looking Glass Studios [1]. In 1998, Intermetrics acquired Pacer Infotec, and changed its name to 'AverStar'. AverStar merged with the Titan Corporation in March, 2000; Titan was acquired by L-3 Communications in 2005.

Bit bucket

In computing jargon, the bit bucket is where lost computerized data has gone, by any means; any data which does not end up where it is supposed to, being lost in transmission, a computer crash, or the like, is said to have gone to the bit bucket — that mysterious place on a computer where lost data goes, as in:

The errant byte, having failed the parity test, is unceremoniously dumped into the bit bucket, the computer's wastepaper basket.

Millions of dollars in time and research data gone into the bit-bucket?

Charles Stark Draper

Charles Stark "Doc" Draper (October 2, 1901 – July 25, 1987) was an American scientist and engineer, known as the "father of inertial navigation". He was the founder and director of the Massachusetts Institute of Technology's Instrumentation Laboratory, later renamed the Charles Stark Draper Laboratory, which made the Apollo Moon landings possible through the Apollo Guidance Computer it designed for NASA.

Core rope memory

Core rope memory is a form of read-only memory (ROM) for computers, first used in the 1960s by early NASA Mars space probes and then in the Apollo Guidance Computer (AGC) designed and programmed by the Massachusetts Institute of Technology (MIT) Instrumentation Lab and built by Raytheon.

Contrary to ordinary coincident-current magnetic-core memory, which was used for random access memory (RAM) at the time, the ferrite cores in a core rope are just used as transformers. The signal from a word line wire passing through a given core is coupled to the bit line wire and interpreted as a binary "one", while a word line wire that bypasses the core is not coupled to the bit line wire and is read as a "zero". In the AGC, up to 64 wires could be passed through a single core.

Software written by MIT programmers was woven into core rope memory by female workers in factories. Some programmers nicknamed the finished product LOL memory, for Little Old Lady memory.


A determinative, also known as a taxogram or semagram, is an ideogram used to mark semantic categories of words in logographic scripts which helps to disambiguate interpretation. They have no direct counterpart in spoken language, though they may derive historically from glyphs for real words, and functionally they resemble classifiers in East Asian and sign languages. For example, Egyptian hieroglyphic determinatives include symbols for divinities, people, parts of the body, animals, plants, and books/abstract ideas, which helped in reading, but none of which were pronounced.

Draper Laboratory

Draper Laboratory is an American not-for-profit research and development organization, headquartered in Cambridge, Massachusetts; its official name is "The Charles Stark Draper Laboratory, Inc". The laboratory specializes in the design, development, and deployment of advanced technology solutions to problems in national security, space exploration, health care and energy.

The laboratory was founded in 1932 by Charles Stark Draper at the Massachusetts Institute of Technology (MIT) to develop aeronautical instrumentation, and came to be called the "MIT Instrumentation Laboratory". It was renamed for its founder in 1970 and separated from MIT in 1973 to become an independent, non-profit organization.The expertise of the laboratory staff includes the areas of guidance, navigation, and control technologies and systems; fault-tolerant computing; advanced algorithms and software solutions; modeling and simulation; and microelectromechanical systems and multichip module technology.

Eldon C. Hall

Eldon Hall was the leader of hardware design efforts for the Apollo Guidance Computer (AGC) at MIT, and advocated the use of integrated circuits for this task. He has written extensively of the development of the AGC, culminating in his 1996 book, Journey to the Moon: The History of the Apollo Guidance Computer (ISBN 1-56347-185-X)

He pursued his undergraduate education at the Eastern Nazarene College in Quincy, Massachusetts, his graduate education at Boston University in Boston, and his doctoral degree at Harvard University in Cambridge, Massachusetts.


In electronic systems and computing, firmware is a specific class of computer software that provides the low-level control for the device's specific hardware. Firmware can either provide a standardized operating environment for the device's more complex software (allowing more hardware-independence), or, for less complex devices, act as the device's complete operating system, performing all control, monitoring and data manipulation functions. Typical examples of devices containing firmware are embedded systems, consumer appliances, computers, computer peripherals, and others. Almost all electronic devices beyond the simplest contain some firmware.

Firmware is held in non-volatile memory devices such as ROM, EPROM, or flash memory. Changing the firmware of a device may rarely or never be done during its lifetime; some firmware memory devices are permanently installed and cannot be changed after manufacture. Common reasons for updating firmware include fixing bugs or adding features to the device. This may require ROM integrated circuits to be physically replaced, or flash memory to be reprogrammed through a special procedure. Firmware such as the ROM BIOS of a personal computer may contain only elementary basic functions of a device and may only provide services to higher-level software. Firmware such as the program of an embedded system may be the only program that will run on the system and provide all of its functions.

Before the inclusion of integrated circuits, other firmware devices included a discrete semiconductor diode matrix. The Apollo guidance computer had firmware consisting of a specially manufactured core memory plane, called "core rope memory", where data was stored by physically threading wires through (1) or around (0) the core storing each data bit.

List of films about computers

This is a list of films about computers, featuring fictional films in which activities involving computers play a central role in the development of the plot.

Logical NOR

In boolean logic, logical nor or joint denial is a truth-functional operator which produces a result that is the negation of logical or. That is, a sentence of the form (p NOR q) is true precisely when neither p nor q is true—i.e. when both of p and q are false. In grammar, nor is a coordinating conjunction.

The NOR operator is also known as Peirce's arrow—Charles Sanders Peirce introduced the symbol ↓ for it, and demonstrated that the logical NOR is completely expressible: by combining uses of the logical NOR it is possible to express any logical operation on two variables. Thus, as with its dual, the NAND operator (a.k.a. the Sheffer stroke—symbolized as either ↑, | or /), NOR can be used by itself, without any other logical operator, to constitute a logical formal system (making NOR functionally complete). It is also known as Quine's dagger (his symbol was †), the ampheck (from Ancient Greek ἀμφήκης, amphēkēs, "cutting both ways") by Peirce, or neither-nor.

Other ways of notating include, P NOR Q, and "Xpq" (in Bocheński notation). It is logically equivalent to , where the symbol signifies OR and signifies the negation.

The computer used in the spacecraft that first carried humans to the moon, the Apollo Guidance Computer, was constructed entirely using NOR gates with three inputs.

Mobile Web

The mobile web, also known as mobile internet, refers to browser-based Internet services accessed from handheld mobile devices, such as smartphones or feature phones, through a mobile or other wireless network.

Traditionally, the World Wide Web has been accessed via fixed-line services on laptops and desktop computers. However, the web is now more accessible by portable and wireless devices. An early 2010 ITU (International Telecommunication Union) report said that with current growth rates, web access by people on the go – via laptops and smart mobile devices – is likely to exceed web access from desktop computers within the next five years. In January 2014, mobile internet use exceeded desktop use in the United States. The shift to mobile web access has accelerated since 2007 with the rise of larger multitouch smartphones, and since 2010 with the rise of multitouch tablet computers. Both platforms provide better Internet access, screens, and mobile browsers, or application-based user web experiences, than previous generations of mobile devices. Web designers may work separately on such pages, or pages may be automatically converted, as in Mobile Wikipedia. Faster speeds, smaller, feature-rich devices, and a multitude of applications continue to drive explosive growth for mobile internet traffic. The 2017 Virtual Network Index (VNI) report produced by Cisco Systems forecasts that by 2021, there will be 5.5 billion global mobile users (up from 4.9 billion in 2016). Additionally, the same 2017 VNI report forecasts that average access speeds will increase by roughly 3 times from 6.8 Mbit/s to 20 Mbit/s in that same time span with video comprising the bulk of the traffic (78%).

The distinction between mobile web applications and native applications is anticipated to become increasingly blurred, as mobile browsers gain direct access to the hardware of mobile devices (including accelerometers and GPS chips), and the speed and abilities of browser-based applications improve. Persistent storage and access to sophisticated user interface graphics functions may further reduce the need for the development of platform-specific native applications.

The mobile web has also been called Web 3.0, drawing parallels to the changes users were experiencing as Web 2.0 websites proliferated.Mobile web access today still suffers from interoperability and usability problems. Interoperability issues stem from the platform fragmentation of mobile devices, mobile operating systems, and browsers. Usability problems are centered on the small physical size of the mobile phone form factors (limits on display resolution and user input/operating). Despite these shortcomings, many mobile developers choose to create apps using mobile web. A June 2011 research on mobile development found mobile web the third most used platform, trailing Android and iOS.In an article in Communications of the ACM in April 2013, Web technologist Nicholas C. Zakas, noted that mobile phones in use in 2013 were more powerful than Apollo 11's 70 lb (32 kg) Apollo Guidance Computer used in the July 1969 lunar landing. However, in spite of their power, in 2013, mobile devices still suffer from web performance with slow connections similar to the 1996 stage of web development. Mobile devices with slower download request/response times, the latency of over-the-air data transmission, with "high-latency connections, slower CPUs, and less memory" force developers to rethink web applications created for desktops with "wired connections, fast CPUs, and almost endless memory."

The mobile web was first popularized by a silicon valley company known as Unwired Planet. In 1997, Unwired Planet, Nokia, Ericsson, and Motorola started the WAP Forum to create and harmonize the standards to ease the transition to bandwidth networks and small display devices. The WAP standard was built on a three-layer, middleware architecture that fueled the early growth of the mobile web, but was made virtually irrelevant with faster networks, larger displays, and advanced smartphones based on Apple's iOS and Google's Android software.

NOR gate

The NOR gate is a digital logic gate that implements logical NOR - it behaves according to the truth table to the right. A HIGH output (1) results if both the inputs to the gate are LOW (0); if one or both input is HIGH (1), a LOW output (0) results. NOR is the result of the negation of the OR operator. It can also be seen as an AND gate with all the inputs inverted. NOR is a functionally complete operation—NOR gates can be combined to generate any other logical function. it shares this property with the NAND gate. By contrast, the OR operator is monotonic as it can only change LOW to HIGH but not vice versa.

In most, but not all, circuit implementations, the negation comes for free—including CMOS and TTL. In such logic families, OR is the more complicated operation; it may use a NOR followed by a NOT. A significant exception is some forms of the domino logic family.

The original Apollo Guidance Computer used 4,100 integrated circuits (IC), each one containing only a single 3-input NOR gate.

NOR logic

A NOR gate is a logic gate which gives a positive output only when both inputs are negative.

Like NAND gates, NOR gates are so-called "universal gates" that can be combined to form any other kind of logic gate. For example, the first embedded system, the Apollo Guidance Computer, was built exclusively from NOR gates, about 5,600 in total for the later versions. Today, integrated circuits are not constructed exclusively from a single type of gate. Instead, EDA tools are used to convert the description of a logical circuit to a netlist of complex gates (standard cells) or transistors (full custom approach).

Resistor–transistor logic

Resistor–transistor logic (RTL) (sometimes also transistor–resistor logic (TRL)) is a class of digital circuits built using resistors as the input network and bipolar junction transistors (BJTs) as switching devices. RTL is the earliest class of transistorized digital logic circuit used; other classes include diode–transistor logic (DTL) and transistor–transistor logic (TTL). RTL circuits were first constructed with discrete components, but in 1961 it became the first digital logic family to be produced as a monolithic integrated circuit. RTL integrated circuits were used in the Apollo Guidance Computer, whose design was begun in 1961 and which first flew in 1966.

Richard Battin

Richard "Dick" Horace Battin (March 3, 1925 – February 8, 2014) was an American engineer, applied mathematician and educator who led the design of the Apollo guidance computer during the Apollo missions during the 1960s.Battin was born on March 3, 1925 in Atlantic City, New Jersey to Martha Scheu and Horace L. Battin.

Battin began his career in 1951, serving as the assistant director of the Massachusetts Institute of Technology’s (MIT) Instrumentation Laboratory. Battin left the laboratory in 1956, becoming a senior staff member at Arthur Little Inc., but returned to MIT’s Instrumentation Laboratory in 1958. He subsequently became the technical director of the Apollo Mission Development program, as well as associate director of the laboratory. Under Battin’s leadership, his team created the analytic and software design of the navigation, guidance and control systems for each of the Apollo spaceflights, making the lunar landing of Apollo 11 possible. In 1973, the MIT Instrumentation Laboratory became the Charles Stark Draper Laboratory Inc., where Battin served as the associate head of the NASA Program Department. After his retirement from Draper in 1987, Battin continued to teach at MIT, where he was a senior lecturer in the Department of Aeronautics and Astronautics until 2010.

Battin was noted for his teaching abilities, especially for his work in teaching, mentoring and inspiring many of the leaders in the world’s guidance, navigation and control community. Three of the Apollo astronauts were his graduate students. To honor his teaching abilities, the students of MIT’s Aeronautics and Astronautics Department honored Battin with their first Undergraduate Teaching Award in 1981.

In addition to being an AIAA Honorary Fellow, Battin was also a Fellow of the American Astronautical Society (AAS), a member of the National Academy of Engineering, and a member of the International Academy of Astronautics. Battin’s many honors include the 1972 AIAA Louis W. Hill Space Transportation Award, the 1978 AIAA Mechanics and Control of Flight Award, the 1989 AIAA von Kármán Lectureship in Astronautics, the 2002 AIAA Aerospace Guidance, Navigation and Control Award, and the 1996 AAS Dirk Brouwer Award.An MIT professor in later life, his lecture, "A Funny Thing Happened on the Way to the Moon", is available through the MIT Open Courseware program.


XCH is a three-letter acronym that can mean:

an EXCHANGE instruction in the IBM 1130 and the Apollo Guidance Computer

The IATA airport code for Christmas Island Airport

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.