 Apollo Guidance Computer and DSKY | |
| Invented by | Charles Stark Draper Laboratory |
|---|---|
| Manufacturer | Raytheon |
| Introduced | August 1966; 59 years ago (1966-08) |
| Discontinued | July 1975; 50 years ago (1975-07) |
| Type |
|
| Processor | Discretesiliconintegrated circuit (IC) chips (RTL based) |
| Frequency | 2.048 MHz |
| Memory |
|
| Ports | DSKY, IMU, Hand Controller, Rendezvous Radar (LM), Landing Radar (LM), Telemetry Receiver, Engine Command, Reaction Control System |
| Power consumption | 55 W[2]: 120 |
| Language | AGC Assembly Language |
| Weight | 70 lb (32 kg) |
| Dimensions | 24 in × 12.5 in × 6.5 in (61 cm × 32 cm × 17 cm) |
TheApollo Guidance Computer (AGC) was adigital computer produced for theApollo program that was installed on board eachApollo command module (CM) andApollo Lunar Module (LM). The AGC provided computation and electronic interfaces forguidance, navigation, and control of the spacecraft.[3] The AGC was the first computer based onsiliconintegrated circuits (ICs).[4][5] The computer's performance was comparable to the first generation ofhome computers from the 1970s, such as theKenbak-1,Apple II,TRS-80, andCommodore PET.[6] At around 2 cubic feet (57 litres) in size, the AGC held 4,100 IC packages.[5]
The AGC has a 16-bitword length, with 15 data bits and oneparity bit. Most of the software on the AGC is stored in a specialread-only memory known ascore rope memory, fashioned by weaving wires through and aroundmagnetic cores, though a small amount of read/writecore memory is available.
Astronauts communicated with the AGC using a numeric display and keyboard called the DSKY (for "display and keyboard", pronounced/ˈdɪski/DISS-kee). The AGC and its DSKY user interface were developed in the early 1960s for the Apollo program by theMIT Instrumentation Laboratory and first flew in 1966.[7] The onboard AGC systems were secondary, as NASA conducted primary navigation with mainframe computers in Houston.[8]
In the earlierProject Gemini program, the astronauts flew manually withcontrol sticks. In the Apollo program however, the flight was controlled by the computer. The astronauts flew manually briefly during lunar landings.[9] Each Moon flight carried two AGCs, one each in thecommand module and theApollo Lunar Module, with the exception ofApollo 7 which was an Earth orbit mission andApollo 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 itsApollo PGNCS (primary guidance, navigation and control system), with the acronym pronounced aspings.
Each lunar mission had two additional computers:
The AGC was designed at theMIT Instrumentation Laboratory underCharles Stark Draper, with hardware design led byEldon C. Hall.[2] Earlyarchitectural work came fromJ. H. Laning Jr.,Albert Hopkins,Richard Battin, Ramon Alonso,[10][11] and Hugh Blair-Smith.[12]The flight hardware was fabricated byRaytheon, whose Herb Thaler[13] was also on the architectural team.
According to Kurinec et al., the chips were welded onto the boards rather than soldered as might be expected.[14] Apollo Guidance Computer logic module drawings specify resistance-welding.[15][16]
Following the use ofintegrated circuit (IC) chips in theInterplanetary Monitoring Platform (IMP) in 1963, IC technology was later adopted for the AGC.[17] The Apollo flight computer was one of the first computers to usesilicon IC chips.[4][8]
While the Block I version used 4,100 ICs, each containing a single three-inputNOR gate, the later Block II version (used in the crewed flights) used about 2,800 ICs, mostly dual three-input NOR gates and smaller numbers of expanders and sense amplifiers.[18]: 27, 266 The ICs, fromFairchild Semiconductor, were implemented usingresistor–transistor logic (RTL) in aflat-pack. They were connected viawire wrap, and the wiring was then embedded in castepoxy plastic.[18]: 129
The use of a single type of IC (the dual NOR3) throughout the AGC avoided problems that plagued another early IC computer design, theMinuteman IIguidance computer, which used a mix ofdiode–transistor logic anddiode logic gates.[citation needed] NOR gates areuniversal logic gates from which any other gate can be made, though at the cost of using more gates.[19]
The computer had 2,048 words of erasablemagnetic-core memory and 36,864 words ofread-onlycore rope memory.[18]: 27, 90–93 Both had cycle times of 11.72 microseconds.[18]: 27 The memory word length was 16 bits: 15 bits of data and one odd-parity bit. TheCPU-internal16-bit word format was 14 bits of data, oneoverflow bit, and onesign bit (ones' complement representation).[18]: 35–37
_used_on_F-8_DFBW_DVIDS683588.jpg)
Theuser interface to the AGC was theDSKY, standing fordisplay and keyboard and usually pronounced/ˈdɪski/DISS-kee. It has an array of indicator lights, numeric displays, and acalculator-style keyboard. Commands were entered numerically, as two-digit numbers:Verb andNoun.Verb described the type of action to be performed andNoun specified which data were affected by the action specified by the Verb command.
Each digit was displayed via a green (specified as 530 nm[20]) high-voltageelectroluminescentseven-segment display; these were driven by electromechanicalrelays, limiting the update rate. Three five-digit signed numbers could also be displayed inoctal ordecimal, and were typically used to displayvectors such as space craftattitude or a required velocity change (delta-V). Although data was stored internally inmetric units, they were displayed asUnited States customary units. This calculator-style interface was the first of its kind.
The command module has two DSKYs connected to its AGC: one located on the main instrument panel and a second located in the lower equipment bay near asextant used for aligning theinertial guidance platform. The lunar module had a single DSKY for its AGC. Aflight director attitude indicator (FDAI), controlled by the AGC, was located above the DSKY on the commander's console and on the LM.
The AGC timing reference came from a 2.048 MHzcrystalclock. The clock was divided by two to produce afour-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 themaster frequency; this signal was used to synchronize external Apollo spacecraft systems.
The master frequency was further divided through ascaler, 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 thereal-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 thestandby mode.
The AGC had four 16-bitregisters for general computational use, called thecentral registers:
DV instruction, and thereturn address afterTC instructionsMP instructionsThere were also four locations in core memory, at addresses 20–23, dubbedediting 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.
The AGC had additional registers that were used internally in the course of operation:
Theinstruction format used 3 bits foropcode, and 12 bits for address. Block I had 11 instructions:TC,CCS,INDEX,XCH,CS,TS,AD, andMASK (basic), andSU,MP, andDV (extra). The first eight, calledbasic instructions, were directly accessed by the 3-bit op. code. The final three were denoted asextracode instructions because they were accessed by performing a special type ofTC instruction (calledEXTEND) immediately before the instruction.
The Block I AGC instructions consisted of the following:
TC (transfer control)TC instruction could be used for subroutine calls.CCS (count, compare, and skip)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 afterCCS. If register A contained plus zero,CCS skips to the second instruction afterCCS. Less than zero causes a skip to the third instruction afterCCS, and minus zero skips to the fourth instruction afterCCS. The primary purpose of the count was to allow an ordinary loop, controlled by a positive counter, to end in aCCS and aTC to the beginning of the loop, equivalent to anIBM 360'sBCT. The absolute value function was deemed important enough to be built into this instruction; when used for only this purpose, the sequence after theCCS wasTC *+2,TC *+2,AD ONE. A curious side effect was the creation and use ofCCS-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.INDEXINDEX can be used to add or subtract an index value to thebase address specified by the operand of the instruction that followsINDEX. 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.RESUMEINDEX (INDEX 25). This is the instruction used to return from interrupts. It causes execution to resume at the interrupted location.XCH (exchange)TS.CS (clear and subtract)TS (transfer to storage)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 theTS. Whenever overflow is a possible but abnormal event, theTS was followed by aTC to the no-overflow logic; when it is a normal possibility (as in multi-precision add/subtract), theTS is followed byCAF 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)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.MASKMP (multiply)DV (divide)SU (subtract)Instructions were implemented in groups of 12 steps, calledtiming pulses. The timing pulses were named TP1 through TP12. Each set of 12 timing pulses was called an instructionsubsequence. 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 calledMP0, followed by anMP1 subsequence which was repeated 6 times, and then terminated by anMP3 subsequence. This was reduced to 3 subsequences in Block II.
Each timing pulse in a subsequence could trigger up to 5control 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.
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 theBank register that could be used to select any bank above 2. Banks 1 and 2 were calledfixed-fixed memory, because they were always available, regardless of the contents of the Bank register. Banks 3 and above were calledfixed-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 thememory 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 aparity alarm panel light was illuminated.
The AGC had five vectoredinterrupts:
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 involuntarycounters. 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.
The AGC had a power-saving mode controlled by astandby 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.
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 logicalAND operation. Because the AGC had no native ability to do a logicalAND, but could do a logicalOR through the bus and could complement (invert) data through the C register,De Morgan's theorem was used to implement the equivalent of a logicalAND. This was accomplished by inverting both operands, performing a logicalOR through the bus, and then inverting the result.
AGC software was written in AGCassembly language and stored onrope memory. The bulk of the software was on read-only rope memory and thus could not be changed in operation,[22] but some key parts of the software were stored in standard read-writemagnetic-core memory and could be overwritten by the astronauts using the DSKY interface, as was done onApollo 14.
A simplereal-time operating system designed byJ. Halcombe Laning[23] consisting of the 'Exec', a batch job-scheduling usingcooperative multi-tasking,[24] and aninterrupt-drivenpre-emptive scheduler called the 'Waitlist' which scheduled timer-driven 'tasks', controlled the computer. 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. Calculations were carried out using themetric system, but display readouts were in units of feet, feet per second, and nautical miles – units that the Apollo astronauts were accustomed to.[25] Laning's design saved the Apollo 11 landing mission when the rendezvous radar interface program began using more register core sets and "Vector Accumulator" areas than were physically available in memory, causing the infamous 1201 and 1202 errors. Had it not been for Laning's design the landing would have been aborted for lack of a stable guidance computer.[26]
The AGC had a sophisticated software interpreter, developed by theMIT Instrumentation Laboratory, that implemented avirtual machine with more complex and capable pseudo-instructions than the native AGC. These instructions simplified the navigational programs. Interpreted code, which featured double precisiontrigonometric, scalar and vector arithmetic (16 and 24-bit), even anMXV (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 (inthe 1960s memory was very expensive). The average pseudo-instruction required about 24 ms to execute. The assembler, namedYUL for an early prototypeChristmas Computer,[27] 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 set of user-accessible routines were provided to let the astronauts display the contents of various memory locations inoctal 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 design principles developed for the AGC byMIT Instrumentation Laboratory, directed in late 1960s byCharles Draper, became foundational tosoftware engineering—particularly for the design of more reliable systems that relied onasynchronous software,priority scheduling, testing, andhuman-in-the-loop decision capability.[28] When the design requirements for the AGC were defined, necessary software and programming techniques did not exist so they had to be designed from scratch. Many of the trajectory and guidance algorithms used were based on earlier work byRichard Battin.[23] 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[29] on the lunar module led by George Cherry. Details of these programs were implemented by a team under the direction ofMargaret Hamilton.[30] 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.[24][30] In total, software development on the project comprised 1400person-years of effort, with a peak workforce of 350 people.[23] In 2016, Hamilton received thePresidential Medal of Freedom for her role in creating the flight software.
The Apollo Guidance Computer software influenced the design ofSkylab,Space Shuttle and early fly-by-wire fighter aircraft systems.[31][32]
The Apollo Guidance computer has been called "The fourth astronaut" for its role in helping the three astronauts who relied on it:Neil Armstrong,Buzz Aldrin andMichael Collins.[33]
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 uncrewedApollo 4 and6 flights, and was on board the ill-fatedApollo 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, anINDEX to address 25 triggered theRESUME instruction to return from an interrupt. Likewise,INDEX 17 performed anINHINT instruction (inhibit interrupts), whileINDEX 16 reenabled them (RELINT). Other instructions were implemented by preceding them with a special version ofTC calledEXTEND. 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 offar pointers.
The Block II AGC also has theEDRUPT instruction (the name is a contraction ofEd's Interrupt, afterEd Smally, the programmer who requested it). This instruction does not generate an interrupt, rather it performs two actions that are common to interrupt processing. The first action, inhibits further interrupts (and requires aRESUME instruction to enable them again). In the second action, theZRUPT register is loaded with the current value of the program counter (Z). It was only used once in the Apollo software, for setting up the DAP cycle termination sequence in the Digital Autopilot of thelunar module.[34] It is believed to be responsible for problems emulating the LEM AGCLuminary software.
.jpg)
PGNCS generated unanticipated warnings duringApollo 11's lunar descent, with the AGC showing a1202 alarm ("Executive overflow - NO CORE SETS"),[35] and then a1201 alarm ("Executive overflow - NO VAC AREAS").[36] The response of the AGC to either alarm was a soft restart. The cause was a rapid, steady stream of spuriouscycle 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.[37][38]
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 command1668, which instructed it to periodically calculate and display DELTAH (the difference between altitude sensed by the radar and the computed altitude).[nb 1] The1668 added another 10% to the processor workload, causing executive overflow and a1202 alarm. After being given the "GO" from Houston, Aldrin entered1668 again and another1202 alarm occurred. When reporting the second alarm, Aldrin added the comment "It appears to come up when we have a1668 up". The AGC software had been designed with priority scheduling, and automatically recovered, deleting lower priority tasks including the1668 display task, to complete its critical guidance and control tasks. Guidance controllerSteve Bales and his support team that includedJack Garman issued several "GO" calls and the landing was successful.[39]
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.[40] 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 withsynchros 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. It was caused by a radar switch set incorrectly, causing the cycle steals and thus a1202.
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.[40][41]
The AGC formed the basis of an experimentalfly-by-wire (FBW) system installed into anF-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 theSpace 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.[42]
In 2003, Ron Burkey initiated the Virtual AGC Project, aiming to recover the Apollo Guidance Computer (AGC) source code and build a functional emulator.[43][44] As part of this project, the original code, transcribed and digitized from 1960s hard copies,[45] was made available through theVirtual AGC Project andMIT Museum.[46] This effort gained renewed attention in mid-2016 when former NASA intern Chris Garry uploaded the code to GitHub, generating significant media attention.[47][48][49]
{{citation}}: CS1 maint: work parameter with ISBN (link)
Feature Stories
| Launch vehicles | |
|---|---|
| Launch vehicle components | |
| Spacecraft | |
| Spacecraft components | |
| Space suits | |
| Lunar surface equipment |
|
| Ground support | |
| Ceremonial | |
| Related | |
Guidance computers | |
|---|---|
| On crewed spacecraft | |
| On launch vehicles | |
