Over the past few years, I’ve expressed an interest in the AGC, or Apollo Guidance Computer. If you haven’t had the time to look at it, the Wikipedia page is good enough to get a brief overview, but if you want to dig deep, you can find all sorts of information and simulators.
I found myself looking back into it this week for two related reasons: one, the anniversary of the Apollo 11 landing, which I still remember, and because of a new argument that I’ve read (but won’t dignify with a link) that claims the moon landings were fake because the AGC could not have worked. But I must admit, he pointed at one bit of the AGC, its core rope memory which he claimed couldn’t work. I think the safer claim would be that he didn’t understand how it worked, but when I thought about it, I realized that I didn’t really know how it worked either. And that bothered me, so I thought I’d dig into a bit more.
Here’s a brief, high level introduction:
The basic idea is pretty simple, and relies on using ferrite toroids as transformers. Imagine that you have two wires going through a ferrite core. If you send a pulse in one wire, it will generate pulse on the other wire. This principle is used in all transformers, which may vary in the number of turns to step the voltage up and/or down by varying the number of turns through the toroid. You can generate a simple memory using this principle. This kind of memory is demonstrated admirably by SV3ORA who created a 70 bit ROM that serves as a decoder for 7 segment LEDS A pulse (or pulse stream, even better) on one of the ten input lines generates the appropriate set of output voltages to display the corresponding numeral on a 7 segment LED display. His webpage has some nice, easy to follow circuits, and a cute little video of it working.
But if you look at the diagram for the Apollo Guidance Computer, it looks a little different. It has a series of “inhibit” lines that weave in and out of the cores, in addition to some sense lines.
The first description I found was around page 90 of this report, MIT’s Role in Project Apollo, Volume 3. But to be honest, I didn’t really understand it. Luckily, I found what appears to be a better description: P. Kuttner’s 1963 paper, The Rope Memory — A Permanent Storage Device. I still need to work through the details, but it makes a lot more sense to me. I begin to see how the address decoding works. I’ll ponder it a bit more, but it is beginning to make sense, and as it makes more sense, I see it for the clever bit of engineering it is. It was a remarkable bit of engineering in its day, and allowed densities of 1500 bits per cubic inch, including all the address decoding. Very cool.
Addendum: Hacker friend Jeff Kellem was unable to post a comment to this blog (got trapped by the spam filter, no doubt because of the high number of links, which normally indicate spam, but in this case indicates SCIENCE!) but he was kind enough to drop me an email with additional reading. I’ll reproduce it here:
You might find this July 1976 issue of BYTE magazine interesting:
Coincident Current Ferrite Core Memories
Also, maybe check out:
Magnetic Core Memory Systems
Ferrite CorePlanes and Arrays: IBM’s Manufacturing Evolution
And start with Volume 1, Issue 2 (May 1973) of Amateur Computer Club Newsletter, there’s a several part series titled “Core for Stores” in there:
Look forward to reading more about your exploration into core memory.
All very cool resources. All us old-timers probably remember Byte magazine (but to be honest, I didn’t recall that they had ever had an article addressing core memory) but I had never actually heard of the Amateur Computer Club newsletter. It’s deliciously old and homebrew. The description of core memories is great, it includes some of the drive circuitry that one would have built back in 1973. I’ll have to check it out further.
Addendum2: If you want to go to a lot of trouble (and per bit, a huge expense) to make a core memory that can be read by your Arduino, Wayne has a lot of advice and detail on his page.