Without the computers on board the Apollo spacecraft, there would have been no moon landing, no triumphant first step, no high-water mark for human space travel. A pilot could never have navigated the way to the moon, as if a spaceship were simply a more powerful airplane. The calculations required to make in-flight adjustments and the complexity of the thrust controls outstripped human capacities.
The Apollo Guidance Computer, in both its guises—one on board the core spacecraft, and the other on the lunar module—was a triumph of engineering. Computers had been the size of rooms and filled with vacuum tubes, and if the Apollo computer, at 70 pounds, was not exactly miniature yet, it began “the transition between people bragging about how big their computers are … and bragging about how small their computers are,” the MIT aerospace and computing historian David Mindell once joked in a lecture.
The trends that this computer foretold kept spinning out, exponentially, for decades: From big to small, from vacuum tubes to silicon, from hardware to software. Now, if you compare the computing power that NASA used with any common device, from a watch to a greeting card to a microwave, it induces technological vertigo. Michio Kaku, the physicist and popular author, put it like this: “Today, your cell phone has more computer power than all of NASA back in 1969, when it placed two astronauts on the moon.”
To understand how significant the Apollo system was, and why its tiny amount of raw processing power is irrelevant, you only have to listen to the OG computer programmer and volunteer NASA historian Frank O’Brien, who has spent his life lovingly detailing the functions of the Apollo Guidance Computer. O’Brien’s father was a pilot, so Frank became a military brat. He was interested in computers from an early age, and when one of his dad’s old friends rose up the ranks at NASA, he came into possession of the technical manuals that governed the operation of the computer.
“At 13 years old, I get a box on Christmas, around two feet on a side, weighed a million pounds,” O’Brien told me. “I open it up, and it had all the technical manuals on Apollo. You had tons and tons of kids looking at Playboys; I was reading about guidance computers.”
Since then, he’s spent countless hours learning precisely how these machines worked. Even as a teenager, he could fly NASA’s Apollo simulator. As an adult, after earning a computer-science degree and working a long stint as a corporate programmer, he wrote the book The Apollo Guidance Computer, an ode to the machine.
The Apollo Guidance Computer in the command module had two main jobs. First, it computed the necessary course to the moon, calibrated by astronomical measurements that the astronauts made in flight, with a sextant not unlike that used by oceanic navigators. They’d line up the moon, Earth, or the sun in one sight, and fix the location of a star with the other. The computer would precisely measure those angles and recalculate its position. Second, it controlled the many physical components of the spacecraft. The AGC could communicate with 150 different devices within the spacecraft—an enormously complicated task. “It has dozens of thrusters and all kinds of interfaces and a guidance platform and the sextant,” O’Brien said. “You start adding up all this stuff and go, Holy cannoli. This is really capable.”
Conceptually, the MIT Instrumentation Laboratory, which designed the system, built it atop the work they’d done for the Polaris guided-missile system, made to launch nuclear weapons from American submarines. The Apollo computer’s hardware, as Mindell has noted, was fairly well understood “in the world of military avionics.”
Building it dominated the project at first—the lab heavily underestimated the complexity of the software-engineering task. For years afterward, deep into the 1970s, programmers were still using punch cards to code. But the necessity of having Apollo astronauts and NASA engineers “in the loop,” making decisions, required a different kind of software. There had to be an interface. Multiple operations had to run at the same time.
The initial focus on hardware locked in what O’Brien called a “primitive architecture” while opening space for Margaret Hamilton, a woman in the heavily male Apollo program, to lead software design. As it became clear that the software was truly where the mission would be made, Hamilton’s team expanded to 350 people at its peak. The system they built was remarkably advanced.
To maximize the built-in architecture, Hamilton and her colleagues came up with what they named “The Interpreter”—we’d now call it a virtualization scheme. It allowed them to run five to seven virtual machines simultaneously in two kilobytes of memory. It was terribly slow, but “now you have all the capabilities you ever dreamed of, in software,” O’Brien said.
The astronauts communicated with the computer through the DSKY, short for “display and keyboard.” They’d punch in numbers and get responses. It’s not easy to describe the user-interface system, but it relied on a series of program codes, as well as “verb” and “noun” codes. Verbs were things the computer could do (“78 UPDATE PRELAUNCH AZIMUTH”). Nouns were numerical quantities or measurements (“33 TIME OF IGNITION”). It was a long way from point-and-click simplicity.
Most of the system’s memory had been woven, literally, onto rope memory, but some could be written, both by the astronauts and remotely from Mission Control. Perhaps the most brilliant software-engineering feat was the software designed by J. Halcombe Laning that prioritized the system’s computational tasks.
This turned out to be a mission-saving advance for Apollo 11. As the lunar module descended, noise from one of its radars began to feed bad data into the system. The guidance computer understood it had a problem, but was able to stay functional throughout the descent, dumping the bad information and continuing its more important operations, saving the mission.
The popular narrative of this moment—at the time and still today—holds that the computer had problems and that Neil Armstrong, seizing “manual” control, piloted the spacecraft to the moon’s surface. Humans did it! Computers are no match for us!
But the lunar lander was a fly-by-wire system. Any command that Armstrong gave had to route through the computer. So it’s probably more accurate to say that when Armstrong landed on the moon, he told the computer where to touch down. There was no usable manual control; the real triumph was the flexibility of human-computer interaction.
Historians such as Mindell, who has modeled the descent on a second-by-second basis, don’t put much stock in the necessity of Armstrong’s actions. He still needed the computer to control the craft. “Had it been set on automatic landing, the [lunar module] would have come down anyhow, with less ballyhoo, though perhaps amid a field of boulders,” Mindell concluded. The story about human prowess was almost a perfect reversal of the reality.
Given all this, perhaps it’s not surprising that O’Brien takes umbrage at the idea that a microwave or calculator could be considered “as powerful” as the Apollo computer.
“How do you define power?” O’Brien asks. “It’s great to say, ‘This machine is so powerful.’ What do you mean by that?”
For him, it’s not about the raw number of transistors, but the machine fitting the mission. Capability, not power. “We had to get to the moon, get down, and get back, autonomously. They hit their targets of being accurate after a quarter million miles, hitting a target within 500 to 600 feet and one-tenth of a foot a second,” O’Brien said. “And you go, ‘My watch is more powerful.’ No, it is not.”
The lesson, maybe, is simple: If your phone is so much more powerful than the computers that put humanity on the moon, then why are you just staring at Instagram all day? Computation is means, not end.