The software that landed men on the Moon was not loaded onto the Apollo Guidance Computer so much as woven into it, with women at a Raytheon plant threading wire through or around thousands of tiny magnetic rings by hand, one pass for a one and one miss for a zero, until the whole program was a physical textile

The software that guided Apollo 11 towards the Moon did not reach its computer as an electronic download. Once the program had been written, tested and approved, much of it had to be manufactured.

At a Raytheon facility outside Boston, women passed fine copper wires through or around tiny magnetic cores. A wire threaded through a core produced a binary one. A wire routed around it produced a zero. The approved program became a dense physical object called core-rope memory.

Describing the code as woven is accurate, but not the whole story. Apollo’s permanent instructions lived in the rope. The computer also carried a smaller erasable memory for the changing measurements and results it needed during flight.

The code reached Raytheon only after testing

The Apollo Guidance Computer was designed by the MIT Instrumentation Laboratory, now Draper. Programmers wrote the flight software in assembly language and a specialised interpretive language.

An MIT history of the Apollo computer explains that programmers wrote code, had it entered on punch cards and received printed output from the mainframe used to assemble and test it. Only a frozen version became manufacturing data.

At Raytheon, punched paper tape controlled a fixture that positioned the cores. An operator passed a wire bobbin through holes selected for ones and bypassed those representing zeros. A 1966 Apollo report calls this a tape-controlled semiautomatic process: machinery positioned the work, but a person performed the threading.

When all the wires had been routed and terminated, the finished module was tested against the program encoded on paper tape.

One core helped store many bits

The familiar description can sound as if Apollo required one ring for every bit. Core rope was more efficient.

The computer’s fixed memory had six modules. The MIT Instrumentation Laboratory’s final computer subsystem report says each module contained 512 cores and 192 sense wires. The intersection of a wire and a core represented one bit. If the wire passed through, the computer read a one when that core was selected. If it went around, the computer read a zero.

Across the six modules, this produced 589,824 bits, or 73,728 bytes. That is the 72 kilobytes of read-only memory commonly quoted for the Apollo Guidance Computer.

The rope retained its information without power and could not be overwritten by an accidental instruction. Its strength was also its weakness: changing a bit meant changing the physical assembly.

The women were building permanent memory

Most of the Raytheon employees who threaded the ropes were women, many recruited for their experience in the region’s textile industry. Their work demanded precision because one incorrectly routed wire could alter an instruction or constant.

These workers are sometimes confused with Margaret Hamilton and the MIT software group she led. They occupied different points in the process. Hamilton’s team developed the flight software. Raytheon’s workers manufactured the approved binary program into memory modules.

A dated nickname often repeated in histories, “little old ladies”, diminishes what the work involved. This was safety-critical electronics assembly. The program could not fly until skilled workers had turned its bits into a tested physical component.

A software deadline became a factory deadline

Programmers could revise and test the code using ground equipment before manufacture. A flight version eventually had to be declared complete so its ropes could be built.

After that cutoff, changing one instruction was no longer just a matter of producing a new sequence of bits. The alteration could require another physical assembly followed by electrical checks and integrated testing. The Computer History Museum notes that these memories were made by hand and could take months to weave.

The delay bought something valuable. Once a rope passed its tests, its contents did not disappear when power was removed, and the computer could not accidentally overwrite its own flight program. The cost of changing the code and the reliability of the finished memory were two sides of the same design.

The computer could still change its working data

Apollo could not have navigated if every number were fixed. The computer needed to update velocity, position, time and intermediate results while accepting commands from the astronauts.

It therefore carried 2,048 words of erasable magnetic-core memory beside 36,864 words of fixed memory. With 15 working bits and a parity bit in each word, that amounted to about 4 kilobytes of erasable memory and 72 kilobytes of fixed memory.

Executable code and permanent constants mostly lived in the rope. Variables lived in erasable memory, whose limited addresses were reused for different jobs at different points in a mission.

In my article about the small plutonium supply that has kept Voyager operating for almost half a century, the engineering story was one of endurance under strict physical limits. Apollo’s programmers faced the same category of problem. Memory, power, weight and reliability defined what their software could become.

The fixed code could still respond to an overload

During Apollo 11’s descent, the lunar module computer displayed 1201 and 1202 program alarms. Extra work associated with the rendezvous radar was consuming processing time. The computer restarted, preserved the state it needed, discarded lower-priority jobs and resumed the guidance tasks that mattered most.

A NASA Apollo Lunar Surface Journal account explains that the priority-driven executive restarted essential work, including steering the descent engine, while leaving out radar jobs not needed for landing.

The program was physically fixed, but its behaviour was not simplistic. It contained rules for deciding what should survive an overload.

I found a related kind of permanence when writing about IceCube’s 5,160 sensors frozen deep in Antarctic ice. Those modules cannot be retrieved after the boreholes refreeze. Apollo’s rope memories and IceCube’s buried sensors come from different eras, but both show what happens when repair after deployment is impractical: testing and manufacturing become part of the scientific idea.

The Moon-landing software was abstract logic, but it was never weightless. Before it could fly, a programmer had to settle every instruction, a machine had to translate it, and a worker had to give the resulting ones and zeros a permanent path through copper and magnetic rings.