Remembering Apollo: core rope memory

What was special about this computer is that people had to stake their lives on it. If this computer failed - if one of the circuits went bad or crashed or had a bug at the wrong moment - people were gonna die; and that was really a first: to put people’s lives on the line with integrated circuits and hardware. No one had done that before
— David Mindell, Historian of Technology at MIT

Introduction

On Saturday Feb. 19th, 2019, I visited the Living Computers Museum, where I witnessed the history of computing in all aspects - from hardware to software. This was part of my History of Computing course at UW, for which this blog post is being written. In the beginning of that class, we were asked why we were taking it. My answer was along the lines of this: As far back as I remember, I was always interested about how things came to be made - how the materials had to be gathered from mines and other places, purified, and parts formed and assembled in some precise design; this formation and assembly would be made by tools, which were made by previous tools, made by previous tools and so on. Computers fascinate me in that same aspect, and I really want to know how computers came to be, and where we are in this process of building upon previous tools. That’s why, out of all the things I saw in the museum, I found woven core rope memory to be fascinating (and extremely cyberpunk):

Upon doing further research on the topic, this is the kind of memory they used in developing the first guidance computers to be used in the Apollo space missions. The goal of this blog post is to give an overview of the first Apollo guidance computer - which has a fascinating history independent of core memory; then I’ll dive more into how/ why core rope memory works, and mention other kinds of memory.

The Apollo Guidance Computer

A Documentary of the Apollo Navigation Computer:

The documentary (~40 mins) above shows how the Apollo guidance computer came to be. It began development at MIT, after NASA scrambled to find a way to get to the moon. They had to produce gyroscopes and manufacture the inertial guidance systems (which had just been developed for aircrafts) that were perfect. To compensate for the imperfection, they used sextants (used by sailors) to correct and check-in on the system. The inertial guidance system required a computer. They just began manufacturing silicon-based circuitry - and everything had to be perfect; any flaws in production would throw out entire batches. New protocols - like priority queues (as opposed to time-sharing) had to be invented. Software was just becoming a concept, and even at the very early stages of software, it was messy and redundant and was vastly outgrowing the memory available.

Eventually, due to the intense and cutthroat timeline, they weren’t able to produce a complete computer for the Apollo guidance system - they had to split the computer between one on Earth (which would communicate information by radio), and a backup/ on-board computer. However, this doesn’t mean they were off-the-hook. The onboard computer still had to be used when the spacecraft went around the dark side of the moon. A very suspenseful part of that mission was the “1202 alarm,” which could be SPOILER ALERT for the reader if they want to watch the documentary (skip the rest of this paragraph). After they came back from around the dark side of the moon, they had an alarm that only one person in the mission control room had written down the number of. The “1202” alarm was actually the computer being overloaded/ overflowing due to a checklist error. It was dumping the low-priority jobs, as designed, and worked perfectly.

The Apollo 11 project code is actually quite interesting, and contains a number of easter eggs, for those curious.

Core Rope Memory

One aforementioned issue of creating the Apollo 11 guidance computer was memory. Now, my assumption is that the memory they’re talking about is read-write memory for the purpose of executing code and storing real-time data. In the early development of the Apollo guidance computer, they utilized core rope memory - which was read only (ROM - Read Only Memory). This was used to store code, but one wouldn’t be able to store variables or execute code on this hardware. The way it works is quite interesting.

The overall memory for the Apollo Guidance Computer was equivalent to 72kB of memory. The computer disks that stored the program were unreliable and fragile. They would send the program to a factory, and the workers would weave the software into the core rope memory. The way it works is best described by Margaret Hamilton (Director Apollo On-Board Flight Software 1965-76, MIT Instrumentation Laboratory) - one of the few female engineers on the team. “The rope is made up of rings and wires. If the wire goes through the core, it represents a 1, and around the core, it represents a 0.” It was a slow and risky process - a program could take months to weave, and it was extremely difficult to correct.

Upon further research about how it works, it becomes rather intuitive. An example from Hackaday shows how it works:

A modern implementation of core rope memory by Kos (from the Hackaday example)


Before going into the technical details, the whole point of memory is to have the name of something (an address, consisting of a few bits) and acquire what that name points/ refers to, in the same way you’d go into a library looking for a book given the title. It’s sort of like knowing a few bits to get some other bits (knowing a word to get more words).

There are seven (ferrite) cores in the image above, so there are 7 bits to represent here. These cores are used as transformers. Again, a wire going through the core represents a 1, and a wire going outside the core represents a 0. How does this actually become encoded? If you pass an alternating current through a wire inside the core, then a current will be induced in the wire wrapped 30 times around the core (shown on the bottom of each core, acting like the secondary part of a transformer). The circuit above, specifically, lights up a seven-segment display (like the number of a digital clock) given a number encoded in binary.

Given what I’ve learned in my digital design class, this can be utilized to make a decoder: such that given a few wires of input, one can turn on a bunch of wires corresponding to that input; so given n wires, one can turn on 2^n patterns of wires! The example above isn’t necessarily a decoder nor encoder - it just transforms a given input (binary representation) into an output (leds which need to be turned on to represent that number) with the same number of bits, which is still very useful.

All in all, “weaving software” is something I thought I’d never hear in engineering (I’ve heard the term in mechatronics art when it comes to electronic textiles). It’s humbling to know that only a few decades ago, this was the technology we had. It gives me a weird feeling typing up this blog post on my laptop, and I hope you feel that feeling too when reading this on whatever device you’re using.

Anand Sekar