The Computer That Landed on the Moon: Core Rope, Program Alarms and Margaret Hamilton’s Apollo Code

About five minutes into the final descent to the Moon on July 20, 1969, with the lunar module Eagle still more than six miles above the surface, a yellow warning light came on in front of Neil Armstrong and Buzz Aldrin. Aldrin typed a short request into the computer, and a four-digit number came up in green: 1202. Neither astronaut knew what it meant. “Program alarm,” Armstrong told Houston, and then, with an edge in his voice: “Give us a reading on the 1202 program alarm.”

What happened over the next half minute in Mission Control, and in a back room in Houston, and in a small room at MIT in Cambridge where the people who wrote the software were listening on a squawk box, is one of the best stories in the history of computing. The machine doing the complaining was the Apollo Guidance Computer. It weighed about 70 pounds, used about as much power as a bright light bulb, and had a tiny fraction of the memory in any modern phone. Its programs were not stored on a disk or a chip. They were woven by hand, wire by wire, through thousands of tiny magnetic rings. And the reason it was complaining was not that it was failing. It was doing exactly what it had been designed to do when it got overloaded: throw away the less important work and keep flying the spacecraft.

Margaret Hamilton, who led the MIT team that wrote the onboard flight software, died on September 30, 2026, at 90. The obituaries that followed, from MIT, Nature and others, all came back to those few minutes over the Sea of Tranquility. This is the story of the computer behind them: how a university laboratory came to build the brain of the Moon ship, why its memory was sewn like a tapestry, how a small team turned programming into engineering, and what the 1202 alarm actually meant.

A contract from a laboratory, not a company

In August 1961, less than three months after President Kennedy asked Congress to land a man on the Moon before the decade was out, NASA signed its first major Apollo contract. It did not go to one of the big aerospace companies. It went to the MIT Instrumentation Laboratory, a research lab run by Charles Stark Draper, the engineer whose gyroscopes and inertial guidance systems steered American ballistic missiles and submarines. The lab had just designed the guidance system for the Polaris missile, and Draper was confident it could do the same for a spacecraft. When NASA’s administrator asked when the system would be ready, Draper reportedly offered to fly on the mission himself to prove he meant it.

The job was to build a guidance, navigation and control system that could steer the command module and the lunar module, and the heart of it would be a digital computer. That was a bold choice in 1961. Most computers of the day filled rooms, used vacuum tubes or racks of individual transistors, and broke down often. NASA’s ground controllers would do most of the navigation from Earth, tracking the spacecraft by radar and radioing up its position. But the crews needed to be able to get home if the radio link failed, and some jobs, such as steering the engine during a burn behind the Moon or flying a landing that took place in a few minutes, could only be done on board. The computer would have to fit in a box about the size of a carry-on suitcase and run for days without a hiccup.

There was also a deeper question that the historian David Mindell has written about at length: how much should the machine fly the spacecraft, and how much should the pilots? The astronauts, nearly all of them test pilots, wanted their hands on the controls. The engineers wanted a system that could fly the whole mission automatically if need be. The answer that emerged was a partnership. The computer did the arithmetic of guidance and ran the autopilot, and the crew told it what to do, watched what it was doing, and could take over at any point. On Apollo 11 that partnership would be tested in public.

Betting the Moon on the microchip

The team that designed the hardware was led by Eldon Hall, with engineers including Hal Laning, Albert Hopkins, Richard Battin, Ramon Alonso and Hugh Blair-Smith. Their first designs used core-transistor logic, the usual approach of the late 1950s. In 1962 Hall made a decision that looks obvious now and looked risky then. He chose to build the computer from integrated circuits, the new chips that put several transistors and resistors on a single sliver of silicon.

The chips were brand new, costly and unproven. Each one held a single logic gate, a three-input NOR gate made by Fairchild Semiconductor, and in the early years they cost twenty to thirty dollars apiece. But Hall’s argument was that a computer built from thousands of copies of one simple part would be smaller, lighter and more reliable than one built from many kinds of discrete components, and that the part could be tested to death. The early Block I computer used about 4,100 of these chips. The Block II version that flew on the crewed missions used about 2,800 packages, each holding two gates. For a few years in the mid-1960s the Apollo program was the largest single buyer of integrated circuits in the world, and that steady demand helped push the price of chips down and their quality up just as the rest of the electronics industry was deciding whether to trust them.

The finished Block II computer was a sealed metal case about one cubic foot in volume and roughly 70 pounds in weight. It drew about 70 watts and ran on a clock of 2.048 megahertz, with a basic memory cycle of 11.72 microseconds. Its words were 15 bits long plus a parity bit. It had 2,048 words of erasable memory, the working scratchpad, and 36,864 words of fixed memory for its programs. By today’s standards those numbers are tiny. A modern phone has millions of times as much memory. But in the 1960s this was one of the most capable small computers anywhere, and it was built to survive the shaking of a Saturn V launch, the cold and heat of space, and the chance of a hard landing. The modules were welded together and potted in plastic so that nothing could come loose.

The computer first flew on an uncrewed Apollo test in 1966. Every Apollo command module and lunar module that followed carried one, and each lunar landing mission therefore carried two: one in the command module that stayed in orbit and one in the lander.

Software you could hold in your hand

The programs lived in something called core rope memory, and it is the strangest and most beautiful thing about the machine.

Most computers of the 1960s stored data in magnetic core memory, a grid of tiny ferrite rings, each magnetized one way or the other to hold a single 1 or 0. The Apollo computer used that kind of memory for its erasable scratchpad. But for its programs, which had to be dense and could never be accidentally wiped, the designers used a different trick. In a core rope, each ring is not a single bit. Instead, many wires pass near each ring. If a wire is threaded through the ring, that represents a 1. If the wire goes around the ring, that is a 0. When the computer pulses the ring, every wire that passes through it picks up a signal and every wire that skirts it does not, so dozens of bits can be read from one ring at once.

The computer historian Ken Shirriff, who helped restore an Apollo computer in 2019, worked out that each core in the Apollo rope stored 192 bits, far more than a regular core memory could manage. Each rope module held 512 cores and 6,144 words, and a complete set of six modules held the 36,864 words of the program. Shirriff estimates that a single rope used about half a mile of wire.

Because the bits were literally the path of a wire, the program could not be changed once the rope was made. It was software in the most physical sense possible. The ropes were built by Raytheon at a plant in Waltham, Massachusetts, and the work of threading them fell mostly to women, many of them hired from the region’s textile mills and from the Waltham Watch Company, people with steady hands and long experience of fine, repetitive work. The engineers half-jokingly called it LOL memory, for “little old lady.” The weaving was guided by a machine that positioned the rope frame so that the needle went to the right core at each step, and the instructions for that machine came straight from the programmers’ assembler, punched onto tape. Every thread was then checked electrically.

A rope module took about eight weeks to make and cost something like $15,000. That meant the software for each mission had to be finished, tested and frozen months before launch. There was no patching a bug the night before. If a mistake was found after the ropes were woven, the crew would have to work around it or the ropes would have to be made again. That pressure shaped everything about how the programs were written and checked, and it is one reason the Apollo software teams developed habits of testing and review that the rest of the industry would only adopt much later.

Verbs, nouns and a calculator keyboard

The crew talked to the computer through a panel called the DSKY, short for display and keyboard and pronounced “disky.” It had a grid of warning lights, a set of green electroluminescent number displays, and nineteen keys: the digits, plus and minus signs, and a handful of command keys. Designing a way for pilots to control a computer with nothing but numbers was a problem nobody had solved before, and the answer, credited to Ramon Alonso, was a tiny language of verbs and nouns.

A verb was an action, such as “display,” “monitor” or “load.” A noun was the thing to act on, such as the spacecraft’s velocity, its altitude or the time to the next engine firing. To see a value, an astronaut pressed VERB, typed a two-digit verb number, pressed NOUN, typed a two-digit noun number, and pressed ENTER. Verb 16 Noun 68, for example, asked for a continuously updated display of the lander’s distance to the landing site, the time left in the braking phase and a check on its altitude from the landing radar. The crew carried cue cards listing the combinations they would need, and over hours of simulator training they learned the most important ones by heart.

It sounds clumsy, and in some ways it was. But it was also the first time a vehicle’s crew had used a keypad and a display to command a general-purpose computer in real time, a style of interaction that would become ordinary within a few decades in everything from cash machines to microwave ovens. The DSKY also gave the computer a way to report trouble. When it hit a problem, it lit the PROG light and stored an alarm code that the crew could call up with Verb 5 Noun 9. That is what Aldrin did when the 1202 appeared.

The programmers

When the Instrumentation Laboratory took on Apollo, nobody thought of the software as the hard part. The prevailing view in the lab’s early days, the software engineer Don Eyles later wrote, could be summed up as “Hal will take care of it,” meaning the mathematician Hal Laning. In fact the programs grew into one of the most complex software projects of the decade, and by 1968 more than 400 people were working on them.

Margaret Hamilton was one of the people who made that growth manageable. Born in Paoli, Indiana, in 1936, she earned a mathematics degree at Earlham College in 1958 and moved to Boston, where she found a job writing weather prediction software for the MIT meteorologist Edward Lorenz, whose work would later help found chaos theory. She went on to program the SAGE air defense system at MIT’s Lincoln Laboratory, where she grew interested in what made software reliable. In 1965 she answered an advertisement for people to help “send man to the moon,” and, by MIT’s account, was hired as the first programmer for the Apollo project at the lab and its first female programmer.

She started on programs for the uncrewed test flights and rose quickly. By 1968 she was an assistant director in charge of the command and service module software, and she went on to lead the software engineering effort for the onboard flight programs of both spacecraft. The famous 1969 photograph of her standing beside a stack of program listings as tall as she was shows printouts of that code. Her colleagues included Eyles and Allan Klumpp, who wrote the lunar landing guidance, and dozens of others whose names rarely appear outside histories of the program.

Hamilton had a habit of asking what would happen if things went wrong in ways nobody expected. One story she liked to tell came from the lab’s command module simulator. Her young daughter, playing with it one day, managed to start P01, a prelaunch program, while the simulator was in the middle of a flight, and the simulated mission collapsed. Hamilton proposed adding protection to the flight software so that an astronaut could not do the same thing by accident. She was told it was unnecessary, because astronauts were trained not to make that mistake. So she added a note to the documentation instead. Then, on Apollo 8, the first crewed flight around the Moon, Jim Lovell selected P01 by mistake during the flight and wiped out part of the navigation data. The team had to work out a fix and radio it up, and after that her protection was built into the software.

That kind of thinking, which today would be called defensive programming, became a hallmark of her approach. So did the insistence that software was a discipline in its own right, to be designed and tested as carefully as any piece of hardware. Hamilton started using the term “software engineering” to describe what her team did. At first, she later said, people found it amusing. “It was an ongoing joke for a long time,” she told the Spanish newspaper El País in 2018. Today it is the name of the profession.

An operating system that could drop things

The most important design decision in the Apollo software, as it turned out, had been made years before Apollo 11 by Hal Laning. A spacecraft computer has to do many things at once: run the autopilot, read the radar, update the navigation, refresh the displays, listen to the keyboard. A simple way to organize that is what the Apollo engineers called a “boxcar” design, where each task is given a fixed slot in a repeating schedule, like cars in a train. It is predictable, but brittle. If one task runs long, everything behind it slips.

Laning designed something more flexible. His Executive, the core of the computer’s operating system, let programs schedule jobs with priorities. Whenever it had a choice, the Executive ran the most important job waiting. A separate Waitlist handled short tasks that had to happen at precise times. And the whole system was built so that if it ever got into trouble, it could restart in a fraction of a second, throw away everything except the jobs that mattered, and pick up those jobs where they had left off.

The Executive kept its bookkeeping in a small number of fixed slots in erasable memory. In the lunar module computer there were seven “core sets,” each twelve words long, that every scheduled job needed, and five larger work areas, called VAC areas, for jobs that used the computer’s interpreted math routines. If a new job came along and there was no core set left, the Executive could not schedule it. Rather than crash or carry on with corrupted data, it jumped to a routine in the alarms software, raised alarm 1202 and restarted. If no VAC area was free, the alarm was 1201. The restart preserved the critical work, such as guidance and the autopilot, and dropped the rest.

In other words, the 1202 alarm did not mean the computer had broken. It meant that it had been asked to do more work than it had time for, and that it had dealt with that by shedding the work that could wait.

Three minutes over the Sea of Tranquility

Powered descent began behind the Moon. Eagle’s engine lit at about 50,000 feet and began to slow the lander for its long, curving fall toward the landing site. About five minutes in, the first alarm came. In Cambridge, Eyles remembered, the word went around the room: “Executive alarm, no core sets.” The MIT team could tell that something was draining time from the computer, but events were moving too fast for them to say what. The decision belonged to Houston.

There, the guidance officer at the console responsible for the lander’s computer was Steve Bales, who was 26 years old. A few weeks earlier he had taken part in a review of every alarm the landing software could raise, and the conclusion for 1202 had been that it was safe to continue unless the alarms came too often or the guidance began to go wrong. In the back room behind him sat Jack Garman of NASA, who had helped work through that list of alarms, and Russ Larson of MIT. Garman said go. Larson, who later said he was too frightened to speak, gave a thumbs-up. Bales answered go, the flight director, Gene Kranz, said go, and Charlie Duke, the capsule communicator, passed it up to the crew. About half a minute had passed since the alarm.

The alarms kept coming: another 1202, then a 1201, then two more 1202s, five in all. Each time the computer restarted and kept guiding the lander, and each time Houston said go. Between alarms, something reassuring happened. On schedule, the guidance software throttled the descent engine back from full thrust, exactly as planned. “Ah! Throttle down… better than the simulator,” Aldrin said, and Armstrong added, “Throttle down on time!” In the official transcript of the descent, Eyles noted, those are the only exclamation points.

Closer to the surface, Armstrong saw that the computer was steering them toward a crater surrounded by boulders. He took partial manual control in the program called P66, in which the computer held the descent rate he commanded with a switch while he flew the lander sideways with a hand controller. With fuel warnings being called out, he found a clear spot and set Eagle down at 102 hours, 45 minutes and 40 seconds into the mission. “Houston, Tranquility Base here. The Eagle has landed.”

In hindsight, the alarms showed the design doing its job. The software had been built to recognize that it was overloaded, to tell the crew and the ground, and to protect the jobs that mattered most. It did all three. As the MIT obituary put it, Houston trusted the software and allowed the mission to go on.

Why the computer was overloaded

The question of what had been stealing the computer’s time was answered within days, and the full story, as Eyles told it in a 2004 paper, is more interesting than the shorthand that usually appears in retellings.

The lander had two radars. The landing radar looked down at the surface. The rendezvous radar looked up and was used to find the command module again after the moonwalk. During the descent the rendezvous radar was not needed, but its switch was set in a position that kept its electronics connected to the computer, so that it would be ready in case of an abort. That setting by itself should not have mattered.

The trouble was electrical. Years earlier, an interface control document had laid out how the guidance system’s power should be matched to that of an assembly built by Grumman, the lander’s manufacturer. It said the two 800-hertz power supplies had to be “frequency locked.” It did not say “phase synchronized.” As built, the two were locked in frequency but at a random phase angle, set by the moment the computer happened to be switched on. With an unlucky phase angle, the electronics that converted the radar antenna’s angles into digital signals went haywire and began sending the computer a constant stream of tiny counting pulses, each of which took a slice of a memory cycle to handle.

Those pulses stole roughly 13 percent of the computer’s time. The descent programs were already using most of the rest, and a display the crew had asked for added a little more. The total was more than the computer could do, so new jobs began to pile up waiting for core sets, and the Executive did what it had been built to do.

The phasing problem had in fact been seen in ground testing of an earlier lunar module, but it had not been fixed. It is often described as a checklist error by the astronauts. It was not. The crew had set the switch exactly as their procedures said. The fault lay in a single missing phrase in a document written years before. That is a pattern that would repeat in later space missions, including the Mars probe lost to a mix-up between pounds and newtons in 1999, where two teams each followed their own specifications and the spacecraft paid for the gap between them.

There was a second, less famous problem on the same descent. Faulty data in the lunar module’s engine model made the throttle control loop only marginally stable, so the commanded thrust oscillated more than it should have. That one also stayed within limits.

Sixty-one keystrokes on Apollo 14

Because the programs were woven into rope, fixing them in flight was impossible in the normal sense. But the computer could still be reprogrammed in a limited way, by having the crew change values in its erasable memory through the DSKY. The most dramatic case came on Apollo 14 in February 1971.

Hours before Alan Shepard and Edgar Mitchell were due to start their descent, the abort switch on the lander’s instrument panel began sending a false signal now and then. If it did so during the landing, the computer would obey it and abort, throwing away the mission. Eyles had written the code that watched that switch. Working against the clock with colleagues in Cambridge, he came up with a sequence of changes to the computer’s memory that fooled the abort monitor into thinking an abort was already under way, so it would ignore the switch, and then cleaned up afterward so the landing could go on normally. The procedure was radioed up and the crew keyed it in. It took 61 keystrokes on the DSKY, and it worked. Shepard and Mitchell landed at Fra Mauro.

From the Moon to every airliner

The Apollo computer’s influence did not end when the program did. In the early 1970s NASA engineers at what is now Armstrong Flight Research Center in California wanted to test a radical idea: an airplane in which the pilot’s controls were connected to the control surfaces only by wires and a digital computer, with no mechanical linkage at all. They needed a reliable flight computer, and the most reliable small digital computer available was the one from Apollo.

They installed an Apollo Guidance Computer, with its DSKY, in a Navy F-8C Crusader fighter. On May 25, 1972, the test pilot Gary Krier flew it, the first flight of an aircraft whose controls depended on a digital computer with no mechanical backup. The F-8 Digital Fly-By-Wire program ran for thirteen years and later moved to other computers, and what it proved went into the space shuttle’s flight controls and into military and civilian aircraft. Most modern airliners fly with digital fly-by-wire controls, and the same basic approach is now found in fighters and spacecraft.

The deeper legacy is in how software is built. The Apollo teams learned to treat a program as something that had to be specified, reviewed, simulated and tested from every angle before it was allowed anywhere near a crew. They learned to design for failure, assuming that switches would be in the wrong position, that people would press the wrong keys and that the hardware would surprise them. And they learned that the software team had to be at the table with the hardware engineers from the start. Hamilton spent much of the rest of her career trying to turn those lessons into formal methods. She founded Higher Order Software in 1976 and Hamilton Technologies in 1986, where she developed the Universal Systems Language, an approach built around preventing errors rather than finding them later.

Recognition came slowly and then all at once. NASA gave her an Exceptional Space Act Award in 2003. In 2016 President Obama awarded her the Presidential Medal of Freedom, with a citation saying her software architecture “led to giant leaps for humankind.” A year later a LEGO set honoring the women of NASA included a small figure of her beside her stack of listings.

The code comes back

For decades the actual Apollo code survived mostly as yellowing printouts. In 2003 an engineer named Ron Burkey began the Virtual AGC project, collecting scans of listings and documents and writing a simulator that could run the original programs. In 2016 Chris Garry, a former NASA intern, posted the transcribed source code for the command module and lunar module computers of Apollo 11 to GitHub, where it quickly drew enormous attention.

Readers discovered that the code was full of personality. Its comments include gentle jokes and cultural references, and one routine famously carries the note “TEMPORARY, I HOPE HOPE HOPE.” The module that handled the keyboard and display was called PINBALL GAME BUTTONS AND LIGHTS. The programmers were young, mostly in their twenties, and they were writing code that people’s lives depended on with tools that would seem primitive to any first-year student today. They kept their sense of humor anyway.

In 2019, for the 50th anniversary of the landing, a group of engineers and computer historians including Ken Shirriff, Marc Verdiell, Mike Stewart and Carl Claunch restored a real Apollo Guidance Computer that had been rescued from a scrap yard decades earlier. They got it running, loaded programs into it through a rope simulator and ran the original software, a reminder that the machine that guided Apollo was not a myth but a piece of hardware, carefully made and still capable of doing its job.

The ghost in the machine

There is a fine contrast between the Apollo computer and an earlier machine that this site has written about, the Mechanical Turk, the 18th-century chess automaton that seemed to think but hid a human player inside its cabinet. The Apollo computer did not hide anyone. But there were people inside it all the same: in the choices about which jobs mattered most, in the protection against a stray keystroke, in the alarm codes and the restart logic, and in every wire that a woman in Waltham threaded through a ring or around it. When the computer dropped its less important work and kept flying Eagle, it was doing what Laning, Hamilton, Eyles and hundreds of others had decided, years earlier, that it should do.

The landing also left something on the Moon that is still in use. The retroreflector Armstrong and Aldrin set up at Tranquility Base still bounces laser pulses back to Earth, letting scientists measure the distance to the Moon to within centimeters. And the idea at the heart of the Apollo Guidance Computer, a small onboard machine that combines measurements and precise timing to tell a vehicle where it is, now rides in every phone, which works out its position from atomic clocks flying overhead with more computing power than all of Apollo put together.

Looking back, Hamilton once said, “we were the luckiest people in the world.” Nobody had built software like this before. There were no textbooks, no standard methods and no second chances once the ropes were woven. “There was no choice,” she said, “but to be pioneers.”

Further reading