▲ 101 points
back
18 comments
If anyone has questions about the Apollo Guidance Computer or our restoration of it, I'm here to answer.
I don't have any questions, but I do want to express my interest and joy in reading all about it. I'm not sure how big the audience is, but those of us in the audience love it, so keep it up. I'll keep reading.
The other day, I watched this talk, which at that time had 473 views (and now has just over 500): https://www.youtube.com/watch?v=gAIOy7MucYI
In it, Dan Lickly says people are more interested in his time on a submarine than his work on Apollo. I thought this was disheartening.
A spacefaring billionaire and a genius engineer who sent men to the moon talk for an hour, and it only gets 500 views. What a world.
I've enjoyed CuriousMarc's videos very much. Thanks for publishing them.
Here you guys are helping the AGC pass it's self-tests, which was an amazing step.
https://www.youtube.com/watch?v=HpIwQZaEvV0
I worked on a core memory device when I was in the Air Force, and got to troubleshoot a problem with it (which was rare - it was usually very reliable). One core had gone bad in a particularly poor location, which corrupted the "end of message" indicator. So we'd get one message and it would hang, waiting forever for the message to end!
https://nara.getarchive.net/media/ssgt-anthony-j-mathis-and-...
(neither of them are me)
Brilliant. I miss the days when software was so simple!
My first thought was how error prone it would be with humans weaving it but then that description from Raytheon's processs seemed to have addressed this.
An automated process is only better than humans because it is repeatable. However it can still repeatably do the wrong thing!
Do you have any insight into what was the design process for such a safety critical device and how provable was it's 'correctness'?
Are you asking about the process for the weaving, or the process for the software? For the weaving, it's straightforward to test that everything was woven correctly, by verifying the values in all the memory locations. As for writing the software, they had detailed specifications, review of changes, design reviews, and lots of testing. Some information is here: https://history.nasa.gov/computers/Ch2-6.html
I was suppose my question was more biased to the software side. Thank you for sharing the link it's a great read.
Are reads on a rope core memory destructive like on regular core memory? If so why not just tie each ROM bit high or low as needed? Is it because there was no better way to address that many bits?
If you lost power after a read and before the rewrite would your ROM get corrupted?
It seems like the actual information should be in the weave pattern. Or, was there a reset line that reset all the cores at once?
Reads on a core rope are nondestructive, since the information is hard-wired into the weaving pattern. Unlike regular core memory, there's no way for the data to get corrupted. (Unless, of course, there's a component failure. When reading the modules at the Computer History Museum, we discovered that two strands had one-bit failures, probably due to failed diodes. Fortunately, since the module has parity, we could recover the data despite the corruption.)
Thank you for this article, I love it.
The physical difference between ROM and RAM core memory is not entirely clear to me. If I read it correctly, what causes something to read as 1 or 0 depends on whether the wire was wired through or around the core. How does this work for RAM then?
The core rope memory (ROM) and erasable core memory (RAM) are different in most ways. For RAM, a core is magnetized in one direction for a 1 and the other direction for a 0. Reading the core erases it, so it must be rewritten (destructive read). On the other hand, for rope the wiring determines the value of the stored bits and it can't be changed.
RAM is addressed in an X-Y grid, using core's "coincident current" property. An X line gets half the current necessary to flip a core, and a Y line gets half the current, so only the core where both cross gets flipped. When writing a core, the core is flipped to the 1 state unless an inhibit line blocks it, causing it to stay in the 0 state. Core rope, on the other hand, uses inhibit lines for addressing, blocking all cores except the desired one.
Another key difference is RAM stores one bit per core, while rope (ROM) stores 192 bits per core, making it much more dense. (Each rope core has 192 sense wires passing either through or around it.)
RAM uses tiny ferrite cores, while rope uses much larger cores consisting of a permalloy ribbon wound around a bobbin.
RAM uses a separate plane of cores for each bit in the word, while all the bits of a word share the same core in a rope.
Both RAM and rope use sense wires threaded through the cores, along with sense amplifiers to pick up the weak signals.
I've written about the AGC's RAM core memory here: http://www.righto.com/2019/01/inside-apollo-guidance-compute...
For anyone interested in the AGC itself I can recommend the "ultimative Apollo guidance computer talk"
Great short youtube series about core rope memory https://www.youtube.com/watch?v=WquhaobDqLU
I wonder if twistor memory would have been lighter in mass? It was developed by Bell Labs, and mostly found use in (surprise!) telephone switches. It could be made in both read-only and read/write forms, and its manufacture could be heavily automated.
Twistor memory looks like one of those technologies that was not quite competitive with core for one reason or another and never really caught on. As far as twistor ROM, it used a small permanent magnet per bit, so I expect that its density was worse than core rope.
As core rope was manufactured by (black and white) women:
Regarding how NACA/NASA gave work to black women in times from world war ii until the moon landing, "Hidden Figures" (the book) teached me more about american history of that time than my whole school career.
Technology always also influences humans, forms society.
A relevant comment from an old thread (2018): https://news.ycombinator.com/item?id=17689693
That comment is from Mike, the expert on everything AGC, who is part of the restoration team.