http://en.wikipedia.org/wiki/Apollo_Guidance_Computer wrote:
<<The Apollo Guidance Computer (AGC) was a digital computer produced for the Apollo program that was installed onboard each Apollo Command Module (CM) and Lunar Module (LM). The AGC provided computation and electronic interfaces for guidance, navigation, and control of the spacecraft. The AGC had a 16-bit word length, with 15 data bits and one parity bit. Most of the software on the AGC was 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 was provided.
The Apollo flight computer was the first to use integrated circuits (ICs). While the Block I version used 4,100 ICs, each containing a single 3-input NOR gate, the later Block II version (used in the crewed flights) used 2,800 ICs, each with two 3-input NOR gates. 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.
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 micro-seconds. 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).
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 were 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 5-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 were stored internally in metric units, they were displayed as United States customary units.
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.
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 p erform 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. The F17 stage was used to intermittently run the AGC when it was operating in the 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.
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.
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 cooperative multi-tasking (each job had to periodically surrender control back to the Exec which then checked if there was any waiting job with higher priority). 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: 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, developed by MIT, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC. They were used when navigational computations of greater precision than 8 bits were required. Interpreted code, which featured double precision scalar and vector arithmetic, 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 (memory capacity was very expensive at the time). The average pseudo-instruction required about 24 ms to execute. 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.
PGNCS generated unanticipated warnings during Apollo 11's lunar descent, with the AGC showing a 1201 alarm ("Executive overflow - no vacant areas") and a 1202 alarm ("Executive overflow - no core sets"). The cause was a rapid, steady stream of spurious cycle steals from the rendezvous radar, intentionally left on standby during the descent in case it was needed for an abort.
During this part of the approach the processor would normally be almost 85% loaded. The extra 6400 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 calculate and display DELTAH (the difference between altitude sensed by the radar and the computed altitude). This 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". Happily for Apollo 11, the AGC software had been designed with priority scheduling. Just as it had been designed to do, the software 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 Medal of Freedom on behalf of the entire control center team and the three Apollo astronauts.
The problem was not a programming error in the AGC, nor was it pilot error. It was a peripheral hardware design bug that was already known and documented by Apollo 5 engineers. 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.
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.>>
Good for them 
And us too 