As Director of the Software Engineering Division at the MIT Instrumentation Laboratory, Margaret Hamilton was responsible for the software for the Apollo program. The code she was responsible for ran the lunar lander, and brought multiple missions successfully to the surface of Luna and back to orbital rendezvous. We regret to inform you that she passed on September 30th of 2026, aged 90 years.
Hamilton, with the code that put men on the moon.
If you call yourself a software engineer, you have her to thank. Hamilton didn’t just help define the field through her efforts, she literally coined the term while at NASA in an effort to get “mere” programming taken more seriously. Suffice to say, that ambition was realized, and few see programmer as a low-status career these days.
After decades of obscurity, known only to those willing to dive deep into the Apollo program to discover her work there, Hamilton found deserved fame late in life. Her likeness eventually found its way to classroom posters and even an official LEGO figure. She also got the Presidential Medal of Freedom, but we don’t see how that could possibly compare to being immortalized in LEGO.
Some have called her a feminist icon, blazing a trail for girls and women. While that’s true enough, it’s also thinking perhaps too small. Like the missions she did so much to make successful, Margaret Hamilton blazed a trail for all of humanity.
We wish Margaret’s family the best as she blazes a trail we all must someday follow into that one last undiscovered country. Our own biographical tribute is several years old now, but it bears rereading in light of this news.
After getting his hands on a rope driver module from the Apollo project era that had a big ‘Scrapped Module’ stamped on it, [Mike Stewart] was naturally left curious as to what exactly had failed in this module. Originally destined for the Apollo Guidance Computer, these Raytheon-manufactured modules were the pinnacle of space-grade high-tech of the 1960s, with requisite acceptance testing so as to not endanger a very expensive space mission.
The cool part here is that the acceptance documents for the module in question (B16-B17) have been scanned in and can be found on the Internet Archive. With the part itself being potted and very much inaccessible, this document helpfully lays out the expected measurements on the module’s pins, as well as schematics and mechanical drawings. Unfortunately the reasons for the rejection were not recorded, so replicating the failing test results is required to understand the reason.
NASA Rope Driver Module with suspicious exploration marks. (Credit: Mike Stewart, YouTube)
A slight complication here is that the testing procedure doesn’t just involve hooking up a multimeter for some voltage and capacitance measurements. There are also temperature and voltage extremes, and vibration tolerance involved, which would be somewhat complex to test, but most of all risk damaging a historical artefact. Thus a somewhat conservative testing procedure was chosen, even if this may not reveal the actual fault.
As noted in the video, sometimes modules were also rejected because someone simply dropped it on the floor along the way. However, generally if a module was found to be faulty they would open it to diagnose said fault, with a closer look at this module indeed revealing suspicious marks in the potting compound where it was apparently opened and conceivably repaired. This also might explain why they also put the ‘For engineering use only’ on it.
With multiple of such locations visible in the potting compound, these locations were mapped to the schematics for the module, to get some idea of what may have been accessed. After this, basic testing was performed on the module, as per the acceptance testing document.
Along the way an error was detected in said document, in the form of the wrong pin number. In table 4-2 the input pin 269 was mistakenly listed as having output pin number 169 when it should have been pin 168. Pin 169 is chassis ground, so this was presumably fixed in a later version of the document.
After all the testing with just stationary, room-temperature conditions, everything appeared to check out. This means that likely this was indeed a repaired module that got subsequently used for engineering purposes rather than installed in flight-ready hardware. The only issue found was that channels were out of calibration, but whether this was an original flaw or due to the module being half a century old is hard to tell in the absence of repair logs.
Overall it’s an exciting opportunity to document another part of history, since so many of the details pertaining to these original modules and related technologies got lost or muddled over the decades.
Humans first visited the Moon in 1969. The last time we went was 1972, over 50 years ago. Back then, astronauts in the Apollo program made their journeys in spacecraft that relied on remarkably basic electronics that are totally unsophisticated compared to what you might find in an expensive blender or fridge these days. Core among them was the Apollo Guidance Computer, charged with keeping the craft on target as it travelled to its destination and back again.
Marc Verdiell, also known as CuriousMarc, is a bit of a dab hand at restoring old vintage electronics. Thus, when it came time to restore one of these rare and storied guidance computers, he was ready and willing to take on the task. Even better, he came to the 2023 Hackaday Supercon to tell us how it all went down!
[Luizão] wanted to create some hardware to honour the memory of the technology used to put man on the moon and chose the literal core of the project, that of the hardware used to store the software that provided the guidance. We’re talking about the magnetic core rope memory used in the Colossus and Luminary guidance computers. [Luizão] didn’t go totally all out and make a direct copy but instead produced a scaled-down but supersized demo board with just eight cores, each with twelve addressable lines, producing a memory with 96 bits.
The components chosen are all big honking through-hole parts, reminiscent of those available at the time, nicely laid out in an educational context. You could easily show someone how to re-code the memory with only a screwdriver to hand; no microscope is required for this memory. The board was designed in EasyEDA, and is about as simple as possible. Being an AC system, this operates in a continuous wave fashion rather than a pulsed operation mode, as a practical memory would. A clock input drives a large buffer transistor, which pushes current through one of the address wires via a 12-way rotary switch. The cores then act as transformers. If the address wire passes through the core, the signal is passed to the secondary coil, which feeds a simple rectifying amplifier and lights the corresponding LED. Eight such circuits operate in parallel, one per bit. Extending this would be easy.
One of our favorite retro hardware enthusiasts, [CuriousMarc], is back with the outstanding tale of preserving Apollo Program software, and building a core rope reader from scratch to do it. We’ve talked about [Marc]’s previous efforts to get real Apollo hardware working again, and one of the by-products of this effort was recovering the contents of the read-only core rope memory modules that were part of that hardware.
The time finally came to hand the now-working Apollo guidance computer back to its owner, which left the team without any hardware to read core rope modules. But the archive of software from the program was still incomplete, and there were more modules to try to recover. So, the wizardly [Mike Stewart] just decided to roll up his sleeves and build his own reader. Which didn’t actually work as expected the first time.
And this leads us into one of [Marc]’s elevator music explainers, where he gives a beautiful rundown on how core rope works. And if you are thinking of core memory based on ferrite cores, get ready for a brain stretch, as core rope is quite a bit different, and is even more complicated to read. Which brings us to the bug in [Mike]’s reader, which is actually a bug in the block II design of the core rope modules.
Reading a byte off the module requires setting multiple inhibit wires to select an individual core. An innovation in block II allowed those inhibit wires to run at half current, but it turns out that didn’t actually work as intended, and partially selected multiple cores on the other half of the module. And [Mike] forget to re-implement that bug — the reader needs to literally be bug-for-bug compatible. A quick recompile of the FPGA code makes everything work again. And the conservation effort can continue. Stay tuned for more in the Apollo story!
Seems like all the cool kids are rewriting legacy C programs in Rust these days, so we suppose it was only a matter of time before somebody decided to combine the memory-safe language with some of the most historically significant software ever written by way of a new Apollo Guidance Computer (AGC) emulator. Written by [Felipe], the Apache/MIT licensed emulator can run either ROM files made from the computer’s original rope core memory, or your own code written in AGC4 assembly language.
It’s worth noting that the emulator, called ragc, needs a bit of help before it can deliver that authentic Moon landing experience. Specifically, the code only emulates the AGC itself and stops short of recreating the iconic display and keyboard (DSKY) module. To interact with the programs running on the virtual AGC you’ll need to also install yaDSKY2, an open source project that graphically recreates the panel Apollo astronauts actually used to enter commands and get data from the computer.
Of course, the next step would be to hack in support for talking to one of the physical recreations of the DSKY that have graced these pages over the years. Given the limitations of the AGC, we’d stop short of calling such an arrangement useful, but it would certainly make for a great conversation starter at the hackerspace.
You no doubt recall the incredible Apollo Guidance Computer (AGC) reverse engineering and restoration project featured on the CuriousMarc YouTube channel a few years ago. Well, [Marc] and the team are at it again, this time restoring the Apollo Unified S-Band tracking and communication system flight hardware. As always, the project is well documented, carefully explained, full of problems, and is proceeding slowly despite the lack of documentation.
Like the guidance computer, the Unified S-Band system was pretty innovative for its day — able to track, provide voice communications, receive television signals, and send commands to and monitor the health of the spacecraft via telemetry. The system operates on three frequencies, an uplink containing ranging code, voice and data. There are two downlinks, one providing ranging, voice, and telemetry, the other used for television and the playback of recorded data. All crammed into two hefty boxes totaling 29 kg.
So far, [Marc] has released part 9 of the series (for reference, the Apollo Guidance Computer took 27 parts plus 8 auxiliary videos). There seems to be even less documentation for this equipment than the AGC, although miraculously the guys keep uncovering more and more as things progress. Also random pieces of essential ground test hardware keep coming out of the woodwork. It’s a fascinating dive into not only the system itself, but the design and construction techniques of the era. Be sure to check out the series (part 1 is below the break) and follow along as they bring this system back to life. [Marc] is posting various documents related to the project on his website. And if you missed the AGC project, here’s the playlist of videos, and the team joined us for a Hackaday Chat back in 2020.
