26.06.2019
The lunar module, as photographed from the command vessel. Inside, Neil Armstrong and Buzz Aldrin were preparing to make their historic landing. But the craft’s computer console went blank. “I never expected it to come back,” Armstrong later said.
FOR MOST OF the trip, the astronauts had been passengers. The spacecraft had been guiding itself, relaying its position to Mission Control’s IBM mainframe—a contraption the size of a walk-in freezer, which in 1969 was what people thought of when they heard the term computer. Something called a “minicomputer” had recently been introduced; it was the size of a refrigerator. The Apollo guidance computer—there was one on board the command module and another on the lander—was a fraction of that size. At just 70 pounds, it was the most sophisticated such device humanity had yet conceived.
Instead of bulky vacuum tubes, the Apollo computer used thin slices of silicon called chips. Each chip contained a pair of logic gates, and each gate was a simple electronic switch that monitored three inputs, and turned its output to “off” if any of the inputs were “on.” Some 5,600 of these primitive integrated circuits, arranged in a sequence, formed the digital cascade that was the computer’s brain. It was mounted in a hardened metal container on the wall behind the astronauts, then connected by wire to the console in front of them.
The chips had been designed by Fairchild Semiconductor, a technology startup in Palo Alto, California. In the early 1960s, the computing industry was decentralized, with research conglomerates like Bell Labs and MIT dominating on the East Coast; Fairchild was an outpost on the Western frontier. The Apollo program had breathed life into the fledgling company by ordering hundreds of thousands of Fairchild components. The demand for miniaturization had led Gordon Moore, Fairchild’s head of R&D, to hypothesize that the number of components on an integrated circuit would double every year. NASA had pioneered the use of silicon, and the computer on the wall behind the astronauts was Moore’s law’s proof of concept.
The computer’s console, with its numeric keypad, resembled that on a microwave oven, and its small readout screens cast an eerie green light from below. Aldrin managed the device by punching in two-digit commands he had memorized. In response, three small panels displayed five-digit codes that he’d been trained to interpret.
In that critical moment, hurtling like a lawn dart toward the surface of the moon, the Apollo guidance computer had crashed.
As the astronauts began the first stage of their descent, the engine ignited and the computer slotted the lander into an elliptical orbit that brought them within 50,000 feet of the surface. From there, Aldrin keyed in a new program, dropping the lander from orbit into a contact course with the moon.
For the next three minutes, the cratered lunar landscape grew closer, until, at around 46,000 feet, Armstrong rotated the vehicle, pointing the landing radar toward the surface while the astronauts turned to face Earth. The moon’s gravity is irregular, and to account for this, the astronauts had to take new measurements. With the void outside his window, Aldrin punched in a request to compare the lander’s calculated position with the reading from the radar.
He was answered by a klaxon ringing in his earpiece. Aldrin hurriedly keyed in the two-digit code 5-9-Enter, which translated, roughly, as “display alarm.” The console responded with error code “1202.” Despite his months of simulations, Aldrin didn’t know what this one meant; Armstrong, equally baffled, radioed Mission Control for clarification. The stress in his voice was audible, but only later would the two men learn how bad things really were. In that critical moment, hurtling like a lawn dart toward the surface of the moon, the Apollo guidance computer had crashed.
SEVERAL YEARS EARLIER, Hal Laning, a computer scientist at MIT’s Instrumentation Laboratory in Cambridge, Massachusetts, had been asked to design the operating system that would fly men to the moon. He was bound by novel constraints: To save time, Apollo’s operating system would have to process inputs and deliver outputs without noticeable delay. And to stick the landing, it would have to be resilient enough to recover from almost every mode of error, human or otherwise.
Laning’s colleagues spoke of him with awe. His office was adjacent to an air- conditioned room that housed two giant mainframe computers, which took up much of the first floor of the building, and which he oversaw in the manner of a doting parent. The programmers interacted with the computer via a desk-sized control panel. When they got stuck, they went across the hall to interact with Laning. Computer code was not displayed on a monitor—there weren’t any—but instead printed onto reams of oversize paper called listings, which the programmers hand- edited with a marker. Laning’s office overflowed with these listings, making it difficult for his supplicants to find an open chair.
Laning had set the paradigm for computing once before. In the 1950s, he started programming MIT’s first digital computer, which had just been completed. Doing so required complicated mathematical notation, and, seeking to reduce his workload, Laning devised an assistant called “George,” which translated higher- order algebraic equations into language the computer could understand. This early compiler helped inspire Fortran, which in turn spawned most major computer programming languages used today.
Working on Apollo, Laning did it again. Drawing from intuition, with no historical examples as a guide, he determined that each program in the Apollo operating system would be assigned a priority number. Jobs like guidance and control would be given low numbers and run as constant background processes. These could be interrupted by higher-priority jobs, like data requests from the astronauts. The result was a virtual parallel processor that could run off a single central processing unit.
Having drafted the prototype, the sensei retreated to his chambers; Laning’s protégé Charles Muntz took over much of the actual programming. One concern about Laning’s scheme was that a surplus of interruptions might clog the CPU, like a juggler thrown too many balls. Muntz devised a solution he called restart protection. If an unmanageable number of jobs was sent to the processor, certain protected programs would spit their data into a memory bank. The processor queue would then reset, and the computer would restart immediately, resuming the protected tasks and abandoning the rest.
Once Muntz’s team was finished, the operating system was assembled on a mainframe, then printed out as a sheaf of instructions, which were brought to a nearby facility managed by the defense contractor Raytheon. Converting the code to machine-readable binary meant threading bits of copper wire through magnetic cores on a kind of loom. Most of the weavers were women, whose progress was measured bit by bit: A wire that threaded through a magnetic core was a 1; a wire threaded outside of it was a 0.
A completed bundle of wires was called a rope. Once all of the ropes containing the operating system were completed, they were plugged into the computer and run through a battery of tests. Error 1202 signified that the processor was overloaded and that Laning’s scheme had forced a restart. In the months preceding the Apollo 11 launch, computer scientists had deliberately triggered numerous restarts in simulation. The operating system had never failed to preserve the critical data.
ARMSTRONG AND ALDRIN didn’t know that. On the lander’s control panel, above the computer’s console, was a circular button marked ABORT, which, when depressed, would cleave the spacecraft in two, blasting the ascent module back into orbit while sending the remainder hurtling into the moon. The two men had trained for a computer error scenario; they’d worked the console in their simulator at Cape Canaveral so hard they’d nearly wiped the labels off the keys. But there were dozens of possible error codes, and the astronauts hadn’t memorized them all. Some could be overridden with a “go” command; others called for an “abort.” It was up to Houston to make the call.
When Mission Control heard Armstrong’s tense request for information, a well- rehearsed sequence of events played out. Gene Kranz, the flight director, delegated the decision to Steve Bales, the guidance officer; Bales turned to mission specialists Jack Garman and Russell Larson, who consulted the handwritten table of error codes Garman had compiled. Together, Garman and Larson confirmed that error 1202 meant the computer had managed to save the lander’s navigation data before croaking. This scenario was a go.
But what if the computer continued to behave unpredictably? In addition to running the spacecraft’s guidance and navigation systems, the computer assisted Armstrong with steering and control. Below a certain altitude—100 feet or so—an abort was no longer possible, and Armstrong would be forced to attempt a landing even if his computer was malfunctioning. He had little margin for error. On a hard crash landing, the astronauts might be killed; on a not-so-hard crash landing, the astronauts might survive, only to be stranded on the moon. In this nightmare scenario, Mission Control would bid Armstrong and Aldrin farewell, then cut communication as the two prepared to asphyxiate. Michael Collins, in the command module, would make the long journey back to Earth alone.
Imagine pulling the plug on the moon landing. Imagine not pulling the plug, then explaining to a congressional committee why two astronauts had been killed. Jack Garman, 24 years old, gave the go-ahead. Larson, too scared to speak, gave a thumbs-up. Bales made the final call. “It was a debugging alarm,” Bales told me recently. “It was never supposed to occur in flight.” Bales had a monitor in front of him, with a digital readout of the computer’s vital signs. They appeared unaffected. He said, “Go.” By the time Houston relayed the message to Armstrong, almost 30 seconds had passed.
Armstrong resumed assessing the course. Apollo 10 had reconnoitered the landing area, and Armstrong had spent hours studying those photographs, committing landmarks to memory. He’d noticed earlier that his trajectory was a little long, but before he could fully react, Aldrin queried the computer for altitude data. As before, he was answered by an alarm. The computer had crashed again.
BACK AT MIT, dozens of people were crowded around a squawk box with an open line to Mission Control. Among them was Don Eyles, 26 years old, who, along with his colleague Allan Klumpp, had programmed the software for the lander’s final descent. The first restart had alarmed Eyles. The second terrified him. This was not just a glitch but a series of glitches, and he worried that Mission Control didn’t fully understand the consequences.
This phase of the guidance program consumed about 87 percent of the computer’s processing power. The request from Aldrin used an additional 3 percent or so. Somewhere in the middle, a mysterious program was stealing the remaining 10 percent, plus a little more, overloading the processing queue and forcing the restarts. The next phase of the landing was still more computationally demanding, and during that phase the computer would crash even without Aldrin’s input. “Some dreadful thing is active in our computer, and we do not know what it is, or what it will do next,” Eyles wrote of this moment in his memoir.
In Cambridge, Eyles stared at his colleagues in dismay as Mission Control authorized the second go command. Eyles was out of the command loop, but he knew how the computer worked better than anyone in Houston. It might keep restarting, and the closer Armstrong and Aldrin came to the surface, the worse the problem could get. What Eyles deduced in that terrifying moment he would not reveal publicly for years to come: To him, this scenario was not a go. It was an abort.
IN THE NEXT three minutes, the lander dropped roughly 20,000 feet. Scanning the moon’s desolate surface, Armstrong began to make out features in the lunar plain. (Apollo planners had timed the landing so the sun would cast long shadows on the rocks.) The computer automatically entered the next phase of the descent, followed by another reboot and another go command from Mission Control until finally, at less than 2,000 feet above the lunar surface, the computer had its worst crash yet.
The alarm blared and the lander’s readout went dead. For 10 long seconds, the console displayed nothing—no altitude data, no error codes, just three blank fields. Armstrong’s heart began to race, rising to 150 beats per minute, the same as that of a man at the end of a sprint. With the moonscape zipping by outside his window, he was the closest any human had ever been to another world, but, like a distracted driver, his attention was focused on the computer. Finally the console came back on line. Mission Control confirmed: It was another 1202. “I never expected it to come back,” Armstrong later said.
The alarm subsided, but just seconds later came another reboot, another dropout of the display, this last one just 800 feet or so above the surface. That made five crashes in four minutes, but the go commands from Houston kept coming. The controllers had put their faith in the box on the wall. “An abort is not that safe either, and the lower you go, the less safe it becomes,” Bales told me. “There was an unspoken assumption, I think, that anywhere below 1,000 feet, Armstrong was gonna take a shot at it.”
Mission Control went quiet; there was nothing useful left for them to say. Armstrong, following protocol, assumed partial control via stick. This reduced the processing load, ending the errors, but the distractions had led Armstrong to overshoot the designated touchdown corridor by several miles. The long hours he’d spent memorizing the Apollo 10 photographs were wasted. Armstrong was going to have to eyeball it.
The Sea of Tranquility, he could see, was a misnomer; up close, the moon looked as if it had been used for target practice. Armstrong flew the lander almost parallel to the surface, passing over a large crater and an unsuitable field of rubble before spotting a flat expanse of powder. Aldrin consulted the computer for the data that would help them navigate the tricky final seconds of the landing. He had no way of knowing if it was going to go blank again.
Armstrong had had his wings clipped over Korea; he’d bounced an airplane off the upper atmosphere; he’d rescued Gemini 8 from a violent zero-gravity spin. Now he was piloting a malfunctioning spacecraft to touch down on an alien world.
Just 40 seconds after the computer’s final restart, he slowed the lander’s forward momentum, then rotated the legs toward the surface. As the engine kicked up a blinding cloud of dust, Aldrin read aloud a steady stream of figures from the console. With almost no fuel to spare, the lander dropped, in slow motion, to kiss the surface upright, and the particles of moondust hung suspended in the sunlight until the gentle lunar gravity pulled them back to rest.
BACK ON EARTH, the computer scientists scrambled to figure out what had caused the processor overload. Aldrin and Armstrong were walking on the moon, but if their computer kept crashing they might have a hard time getting back. They had about 13 hours before the astronauts were to blast off in the ascent module.
The MIT team located the source of the error with only two or three hours to spare. In anticipation of a possible abort, Aldrin had insisted that the spacecraft’s rendezvous radar remain turned on. This system pointed upward, allowing it to track Collins in the command module. During the descent, the dial for the rendezvous radar had been turned to the wrong setting. Normally, this shouldn’t have caused a problem. But because of a design defect, every once in a while the system would bombard the computer with unnecessary requests. It was the worst kind of error: erratic, subtly dangerous, and difficult to reproduce.
“This was the first time men submitted to ride in a vehicle controlled by a computer.”
The Apollo 11’s rendezvous radar system triggered this rare error, and during the most difficult portion of the landing, 13 percent of the computer’s resources had been stolen by an antenna pointing at the sky. Fortunately, the programmers considered the stray requests expendable, and with each restart, they had been temporarily dismissed. Instead, the computer had focused on the critical tasks of navigation, guidance, and control. These, Apollo programmers had determined, were the most important of all programs, trumping even the software that ran the display. When the computer had blanked out the registers, it was trying to preserve the precious navigation data that told the spacecraft where to go. Laning and Muntz’s scheme, woven into incorruptible rope, had saved the touchdown.
Before leaving the moon, on orders from Mission Control, Armstrong and Aldrin turned the rendezvous radar’s knob to the correct position and, for good measure, cut its power supply. Having implemented this crude fix, they blasted off to lunar orbit, leaving behind the empty lower half of the lander and knocking over the American flag they had planted in the lunar surface. They reunited with Collins, then, three days later, splashed down in the Pacific. Upon their return, the Apollo program was showered in glory. Aldrin became an advocate for the exploration of Mars; Armstrong moved to Cincinnati. Collins wrote a memoir, in which he acknowledged how dangerous the mission had been. “If they fail to rise from the surface, or crash back into it, I am not going to commit suicide,” he wrote of watching Armstrong and Aldrin prepare to ascend. “I am coming home, forthwith, but I will be a marked man for life, and I know it.”
The reclusive Hal Laning, having conquered spaceflight, moved into 3D modeling. The operating system he devised was ported from Apollo to the Navy’s F-8 fighter jet, proving the feasibility of computer-guided flight control. Gordon Moore, who had observed Apollo’s insatiable demand for miniaturized silicon chips, left Fairchild to cofound Intel. In 1971, Don Hoefler, a correspondent for Electronic News, wrote a series of articles surveying the dozens of Bay Area companies that had sprung up in Fairchild’s wake. It was titled “Silicon Valley, USA.”
Finally, there was Don Eyles—the man who would have scrapped the mission if only he’d had the authority. I caught up with him in April, after he’d had 50 years to reflect. Had Mission Control made the right call? “I think from our point of view, at MIT, something was missing inside the computer, something unknown was seriously affecting our software,” he said. “But maybe we knew too much! Those guys could only see it from the outside. In a way, it was easier for them, and I think they got it right.” He paused for a moment. “Anyhow, the mission landed, so they must have got it right,” he said.
Eyles then made another point: “This was the first time men submitted to ride in a vehicle controlled by a computer.” In the most critical phase of the descent, that computer had suffered five unplanned restarts in four minutes, but from the perspective of operating stability it had performed better than its programmers thought possible. Apollo launched six more missions, but public interest waned. Perhaps the program’s true legacy is etched not in moondust but in silicon. Aldrin and Armstrong got the glory, but housed in a metal box on the back wall of the lander was the blueprint for the modern world.