A very serious problem cropped up almost immediately after TLI, as Kitty Hawk attempted to dock with the mission's lunar module, Antares. Fingernail-sized latches on the docking probe used to connect the command module to the lunar module failed to catch, and the two spacecraft were unable to dock. Only after repeated attempts was Kitty Hawk able to capture and securely attach Antares. Afterwards, the S-IVB was sent on its way to a lonely but spectacular death and the combined Apollo 14 spacecraft continued the voyage to Fra Mauro.

The four days in transit and the time spent in lunar orbit were uneventful—or at least as uneventful as a flight to the Moon could be. Insertion into lunar orbit occurred at about 82 hours into the flight. To conserve precious fuel in the LM, the combined spacecraft lowered its orbit to a nine mile (about 14.5 kilometers) perigee several hours later. Preparations for the descent started the next day, with the activation and checkout of the LM.

However, less than four hours before the scheduled landing, controllers noticed that according to the indications on their consoles in Mission Control, the LM's Abort pushbutton appeared to have been pressed. When asked via radio, Shepard confirmed that no one on board Antares had pressed the Abort button—which meant there was a short-circuit or other electrical issue somewhere inside the LM's complicated guts.

This was potentially a mission-ending problem: if the button was pressed and the engine was firing, the LM would immediately begin its abort procedure as soon as the lunar descent started, making a landing impossible.

Under hard time pressure, the ground had to quickly figure out what was wrong and devise a workaround. What they came up with was the most brilliant computer hack of the entire Apollo program, and possibly in the entire history of electronic computing.

To explain exactly what the hack was, how it functioned, and the issues facing the developers during its creation, we need to dig deep into how the Apollo Guidance Computer worked. Hold onto your hats, Ars readers—we're going in.

The Apollo Guidance Computer laid bare

It’s common to find that the AGC is often described as a mere calculator, or compared to a controller chip suitable for a watch or microwave. Looking at your watch, it tells the time and little else. The chip that drives the microwave blindly starts and stops the magnetron to heat expired Kung Pao chicken. In these devices, there is a very limited interaction with the surrounding hardware, no sophisticated computation, and no decision-making of any note.

In describing a "computer," one expects that the system would include the abilities we attribute to contemporary computers—the ability to run several programs at once, for example, or to present a simple yet intuitive interface, to control a wide variety of devices, and to gracefully recover from application errors. “Ha!” you might exclaim, “I carry a computer like that in my pocket!”

The idea of such capabilities being available nearly 60 years ago stretches credulity, but the Apollo Guidance Computer had these features and more. An interpreter to process “virtual” machines, similar to Java byte code? Check. The ability for remote data updates? Yup. Given all of these capabilities and more, it’s quite reasonable to argue that the AGC compares favorably with a modern smartphone. Yes, the AGC is slower and has far less memory, but that is only due to its unfortunate timing at birth, being at the wrong end of the Moore’s Law curve.

Although the processor at approximately 80,000 instructions per second was not especially fast, it is impossible to overemphasize the impact that its scarce memory had on AGC software developers. Consider the limits the programmers were under: all the software for the flight to the Moon and back had to fit in 36K words (15 bits long, plus 1 bit for parity) of read-only core rope memory. As “bytes” were not a concept in the AGC, all 15 bits of a word were accessed at once with no easy way to break the word into smaller divisions.

A number of IBM 2314 disk drives (white) and an IBM 2540 Card Reader / Punch, photographed in 1968.

Secondary storage was not an option: disk units, then the size of washing machines, could not even fit in the spacecraft. Tape storage, while a reliable and viable option, was considered far too late in the development cycle to be included in any designs. The AGC's software was entirely contained within core-rope modules housed inside the AGC itself, a 70lb (about 32kg) box measuring 61cm long, 32cm wide, and 17cm tall.

In addition to the 36k words of read-only memory for the core programming, the AGC had a trivial 2k words of RAM—necessary for the operating system, process management, recovery, and global variables for all mission phases. That’s it. Shoehorned amongst this meager amount of RAM were dedicated memory areas used by application programs: the software that performed the guidance and navigation tasks, landing on the Moon, or rendezvous. Basic programs were each allowed a whopping seven words for temporary variables. And no, that’s not a misprint.

With these constraints in mind, it’s easy to be cynical when facing the task of installing the latest multi-gigabyte application on our laptops.

Quelle: arsTechnica