Houston, we have a program – rescuing the computer code that flew us to the moon
In July 2016 a 47-year-old, fiendishly complex document of extraordinary length was uploaded to a corner of the internet – and the programming world went wild. It was the source code that had powered the 1969 Apollo moon landing; it was also a relic of an iconic moment in history that was nearly lost forever
27th July 2016 (Taken from: #24)
Capcom: We’ve got serious time pressure here, Jim. You’ve gotta get the guidance program transferred, you gotta do it before you’re out of power in the command module. Or you are not gonna be able to navigate up there.
Captain Jim Lovell: How much time? Can you give me a number?
Capcom: Well, we’re looking at less than 15 minutes of life support…
It’s one of the tensest moments in Ron Howard’s already unrelentingly tense 1995 film Apollo 13. Captain Jim Lovell, played by a dogged Tom Hanks, is told by mission control that in order to get home from their catastrophic attempt to land on the moon, he and his crew will have to rescue the spacecraft’s navigation program. The set of data they need is trapped on the dying command module they’re about to abandon and they have a matter of minutes to transfer it manually to the computer aboard the lunar landing craft, and pray for it to boot up.
He’d seen the movie before, but watching the action play out again at home one evening in 2003, software designer Ron Burkey was suddenly inspired.
“It struck me that the guidance computer in the spacecraft almost had the role of a character,” says the 59-year-old from Dallas, Texas. “The astronauts interacted with it at certain points in the movie… Finally, when they have to turn the computer on, and it comes up, it’s oh, I know they’re going to be safe!”
That night Ron decided to embark on his own software rescue mission: to track down and recreate a working version of Nasa’s moonshot code for posterity to marvel at. Googling into the small hours, he happened upon a set of rough-and-ready scans of original printouts salvaged from MIT’s Instrumentation Laboratory, the agency contracted by Nasa to write the source code for the Apollo moon landings. It was just a fraction of the full software story. From the mid ’60s until Project Apollo was cancelled in December 1972, the team constructing the software for the various spacecraft would put in some 1,400 person-years of work as the AGC – the Apollo Guidance Computer – code sprawled through multiple updates and refinements. Led by director of engineers Margaret Hamilton, at its peak the project would employ some 350 people.
Of course, there was only one Ron. And it wasn’t just a matter of typing the program out. There were gaping holes in the scanned code where chunks of text were incomplete or illegible. But Ron had the expertise to fill in the blanks. “If you referred to enough places in the code and enough different documents,” he says, “you could work out the parts that you couldn’t read.” And to verify what he was reconstructing was correct, he had to craft his own program to translate (or “assemble”) it all into a binary format a modern machine could understand.
Eventually, he found he had recreated, “byte for byte”, the guidance code for both the Apollo 13 lunar module and the the command module from Apollo 8 (which had become the first manned flight to orbit the moon in December 1968, also with Jim Lovell aboard). Three decades after Nasa’s lunar missions had been grounded, a computer was running the software that took humanity to the moon. “If there had been just a fraction less of it available,” says Ron, “it would have been impossible to create an authentic reproduction.”
It was that deep authenticity that sent the world’s coding community into a lunar clamour earlier this year. After his success with Apollos 8 and 13, Ron began hunting down AGC versions for other lunar missions, and in 2009 he hit the jackpot when he convinced a curator at the MIT Museum to take the “the courageous decision” to give him access to the hard copy for Neil Armstrong’s epoch-defining Apollo 11 mission of July 1969 – the monstrous slab of subroutines and source files that led him 340,000 kilometres towards his one small step.
In July 2016 a former Nasa intern, Chris Garry, uploaded Ron’s reconstruction of the Apollo 11 AGC program in full to the popular code-sharing site GitHub, and invited fellow code connoisseurs to take a look. It caused a sensation. Programmers swarmed to parse and pore over the detail, some offering suggestions for improvement, others posting sardonic bug reports – “It may be a problem with the moon. Just trying to narrow down the issue.” “Nasa strongly recommends that you migrate to a supported version. Unfortunately no such version exists at this time.” “This is fixed in Apollo 14.”
Most, though, finding the esoteric assembly language impenetrable, were transfixed by the gauche comments left by the original engineers. In coding lingo ‘comments’ are pockets of plain English interpolated into programs that the computer doesn’t see, which are intended to explain to other humans what’s going on at particular points in the syntax. In the AGC text, such comments dotted throughout the code, along with some oddly casual naming conventions, shed light on a looser, pre-professionalised era of programming that feels breezily at odds with the bellicose Cold War rhetoric of the time.
Shakespeare? Now that’s not the kind of thing you expect to find in the middle of your guidance system software”
Files and functions were assigned names such as “BURN_BABY_BURN” – this identified the tract of code that controlled the lunar module’s ignition routine, which in one place contains a memorable instruction for astronauts to “CRANK THE SILLY THING AROUND”. Or “PINBALL LIGHTS AND GAMES”, which was the program that governed the guidance system’s rudimentary display and keyboard on the spacecraft’s instrument panel. “Pinball? Why Pinball?” ponders Ron. “The AGC software seems as though it should be a pure product of theoreticians – but it’s full of quirks and oddities and it’s all sort of chaotic,” he says. “I don’t mean chaotic in the technical sense that it doesn’t work right,” he clarifies. “I mean a mixture of personalities, of styles and jokes and all sorts of stuff that’s just strewn through it.”
“You go through and you might find in some section of the code that this particular function is called ‘Guildenstern’ – and in the next line there might be a label called ‘Rosencrantz’.” And the Shakespearean insertions aren’t confined to minor characters from Hamlet. Elsewhere one erudite engineer appears to despair at the idiosyncratic system of ‘verbs’ and ‘nouns’ the astronauts employed to operate the guidance computer – actually a numerical shorthand which corresponded to a set of basic commands – by way of recourse to a quote from Henry VI Part 2:
# IT WILL BE PROVED TO THY FACE
# THAT THOU HAST MEN ABOUT THEE
# THAT USUALLY TALK OF A NOUN AND
# A VERB, AND SUCH ABOMINABLE
# WORDS AS NO CHRISTIAN EAR
# CAN ENDURE TO HEAR
“Now that’s not the kind of thing you expect to find in the middle of your guidance system software,” says Ron.
Despite the eccentricities, the code itself is an impressive feat of software design, even by today’s standards. “For the most part they were inventing everything from the ground up. This is a computer that they designed the hardware for; they designed the programming languages that went on to it; and they designed the principles for the software, some of which were quite advanced.” They had to be, to squeeze into a device running on just 73,728 bytes of RAM – a memory capacity some 14,500 times smaller than the 1GB you might find on the smartphone in your pocket.
On 18th March 1971 Rolling Stone magazine carried an interview with an MIT software engineer. The headline screamed “Extra! Weird-Looking Freak Saves Apollo 14!” The self-identified “freak” was Don Eyles, whose software specialism was the companion system to the AGC, the Abort Guidance System for the lunar modules. This program’s sole function was to blast the landing craft back into orbit in the event of major mishaps on the way to the lunar surface.
On the Apollo 14 mission, the mechanism to trigger this procedure had become jammed, and when Eyles reprogrammed his system mid-mission to bypass the abort command, he earned as legendary a status as a 27-year-old computer engineer could ever hope to. His coding gymnastics (conveyed by phone from MIT to mission control, who relayed instructions to the astronauts, who overwrote the software with ten minutes to spare) allowed the landing craft’s descent to proceed successfully – and Nasa to get past the horrendous misfire of Apollo 13 nine months earlier.
The headline screamed ‘Weird-Looking Freak Saves Apollo 14!’… The ‘freak’ earned as legendary a status as a computer engineer could ever hope to”
The psychedelic, jive-riddled Rolling Stone article captured the moment of Eyles’s celebrity, and offered a glimpse into the coding culture of the times. In it Eyles suggests that some 25 percent of his colleagues have also “blown grass” like him, and bemoans the rest as “an awful lot of people… you’d have to call straight”. Musing on his public accolade at Boston City Hall, he says: “They passed a resolution with a lot of whereases and things in my honour. I was introduced to Monsignor somebody-or-other. I was stoned out of my mind.”
Eyles, now 72, is among many who have stepped forward to help since Ron’s AGC project surfaced on GitHub, and has offered to share a large amount of space programme hard copy still in his possession. Making contact with this living legend has been a breakthrough for Ron, who has dedicated much of the past 13 years to recovering moonshot software and building it into simulations so the public – or at least those willing to verse themselves in verbs and nouns – can “participate in these historical events”.
(A smartphone emulation of the ACG in action, built using Ron’s transcripts)
His struggle to obtain the source material over the years, though, should give any would-be software archaeologist pause for thought. Even once Ron had targeted and tracked down veterans of the Apollo development team with polite requests for printed program listings, “invariably they would tell me, ‘Sorry, I didn’t keep them – I mean, they’re six inches thick!’” One MIT engineer had thrown out his keepsakes to make some space just a few months before Ron got in touch; another passed his stack to someone at Nasa to scan for posterity while in negotiations with Ron – “and it never happened. It just went into the black hole of Nasa and disappeared.”
Calling for backup
According to computing heritage specialist Chris Monk, from the UK’s Centre for Computer History in Cambridge, Ron’s experience illustrates just how vulnerable the world’s most momentous software is to being erased from the historical record forever, a risk that few are aware of. “If this was evidence from other parts of society, it would be incredibly valuable,” says Monk. “But there’s still a view that because computing technology is changing so fast this stuff really isn’t important.”
While Unesco World Heritage Sites exist to preserve architectural treasures, in the digital age do we need World Heritage Bytes to consecrate these much less tangible historic artefacts? And might they include such constructions as the machine-learning models that allowed IBM’s Deep Blue computer to beat reigning world chess champion Garry Kasparov in 1997? Or the original protocols for ARPANET, the US defence department’s ’80s precursor to today’s internet?
Monk believes the onus is on those involved in technology to rapidly develop standards of conservation similar to established heritage fields such as archaeology. “We need to get the message out there that we need to keep this stuff. It is part of history, and organisations have got some responsibility in digging in their archives and making sure it isn’t thrown out, or that it’s passed on to organisations that can look after it. It’s a cultural issue.”
One major hurdle, as Ron Burkey’s 13-years-and-counting AGC project illustrates, is that truly faithful preservation is a lonely, labour-intensive calling. “A lot of this work is very, very tedious,” Ron says with a sigh. “You get a program listing that’s 2,000 pages long and you have to convert it into source code that you can assemble, and that’s 100 percent correct – that’s a…” He trails off, lost for a couple of seconds in his own personal looping subroutine… “Fortunately I have volunteers that come in and help me with all that. These days I don’t do it all myself.”
We need to get the message out there that we need to keep this stuff. It is part of history”
Speaking to his Rolling Stone interviewer in 1971, Don Eyles had expressed a hope that in the future, “Maybe some programmers will be minor poets of the 20th century.” Forty-five years into that future, Ron has a far less rosy view. “You know, engineers in general, they labour in obscurity,” he demurs. “Nobody ever hears their names. They might be the minor poets, but they’re minor poets whose work just sits in closets. And somebody every once in a while just comes and dumps the contents of the closet.”
Which is a worry. Anyone who isn’t concerned, complacent that there will always be a Ron Burkey or a retro-obsessed GitHub community on hand to step in and decipher the relics of our digital history, should take note: it took 20 years for an army of scholars working on the Rosetta Stone in the early 1800s to crack the code that has enabled subsequent generations to translate Ancient Egyptian hieroglyphics. And that code was only 100 lines long.
You can check in on Ron Burkey’s ongoing software preservation project at his Virtual AGC website.
We hope you enjoyed this sample feature from issue #24 of Delayed Gratification
You can buy the issue from our shop or
Subscribe and receive the magazine through your letterbox every three months
Slow Journalism in your inbox, plus infographics, offers and more: sign up for the DG newsletter. Sign me up
Thanks for signing up.