Apollo Source Code Github

[Silvana Fleischacker]

The entire source code for Apollo 11's flight computer software was recently posted to GitHub, a collaborative platform for developers, and it's filled with tons of hidden Easter eggs including jokes, a Shakespeare quote and a reference to the Black Power movement going on at the time.

Apollo 11's original source code was developed by computer programmers at the Massachusetts Institute of Technology in the '60s. The code was backbone of the Apollo Guidance Computer (AGC), which astronauts used to guide, navigate and control what became the first spacecraft to ever land on the moon.

AGC's source code was actually made available online at Virtual AGC for the first time in 2003, when technology researcher Ron Burkey transcribed the original scanned hard-copy pages that MIT made public.

Garry explained that in programming, developers often leave comments throughout their code to describe to readers what the code is supposed to do. However, it's obvious that IT developers did more than just that. They added in playful messages, puns and pop culture references.

For example, the name for the ignition file in the code is \"BURN_BABY_BURN,\" a phrase popularized by '60s R&B disc jockey Magnificent Montague. One of the developers wrote in a NASA journal that it was a reference to the ongoing Black Power movement.

\"We might not have been out on the streets, but we did listen to the news, and the two biggest news stories were Viet Nam and Black Power, the latter including H. Rap Brown and his exhortations to 'Burn Baby, Burn' -- this was 1967, after all,\" developer Peter Adler wrote in the journal.

Another file in the source code is titled \"PINBALL_GAME_BUTTONS_AND_LIGHTS,\" a reference to a popular arcade game at the time. That file apparently contained the code that ran the program for the keyboard and display system.

\"As you can see, there are humorous comments riddled all over the code,\" Garry told ABC News. \"It's obvious that these guys had a lot of fun writing this code, and we developers have been having a lot of fun reading it.\"

It was fifty years ago, July 20th 1969. Six hundred million people all over the world were holding their breath watching on television the blurry black and white images of the first manned spacecraft landing on the moon: I was one of them, and I will never forget the huge emotion we all felt.

Back then, very few people knew that a key role in that landmark achievement was played by software, run on the Apollo Guidance Computer, also known as AGC, developed by a great team at MIT led by Margaret Hamilton. And yet, just minutes before the landing, several program alarms, 1201 and 1202, signalled a computer overload that could have jeopardized the entire mission, if they had not been properly handled by the system. We can now read a breathtaking account of these events by Don Eyles, one of the engineers that wrote the code, published a recent book, and is also featured in the beautiful Hack the Moon website.

As the AGC was programmed in assembler, which is far from being very human readable, the source code is full of detailed comments that provide us a sort of full immersion in the mind of the developer culture back in the 1960s, and it is great to see how many people have started delving into it.

Here at Software Heritage we are delighted to be able to contribute to this effort, by archiving for the long term the software source code of the AGC, and by providing a means to reference specific fragments of the code that is designed to stand the test of time, using persistent intrinsic identifiers (see also the full paper describing them) also known as SWH-IDs.

It is great to be able to pinpoint like this precise fragments of code in a blog post, an article, a tweet, or a documentation, and indeed many collaborative software development platforms offer this functionality. But development platforms are not archives: sometimes they go away, like Gitorious, Google Code or CodePlex, and often the code they store can be altered, or moved around: this may lead to link rot if you use them to write blog posts like this. Indeed, this is what already happened to the great 2016 article by Quartz, with many of its links into GitHub now dead (see for example here, here and here).

In a fun bit of software archaeology, former NASA intern Chris Garry uploaded the entire Apollo 11 flight guidance source code on GitHub. While the source code has been available for some time, its appearance on GitHub ensures a huge audience of coders and enthusiasts. The Apollo 11 source code has quickly become a fun window into the world of computer programming in the 1960s.

Retrocomputing enthusiasts recently uploaded Apollo Guidance Computer (AGC)source code for various Apollo missions to GitHub. There is even a Virtual AGCthat can run this code.7 In all likelihood, it is the oldest active code onGitHub. Remarkably, its development began over half a century ago in the ashesof Mariner 1, a Venus probe destroyed shortly after launch because of a bug in itsguidance software.15,35 The prevailing explanation was that in thetranscription of hand-written guidance equations into a software specificationfor the contractor, TRW, an overbar to indicate the use of average rather thaninstantaneous velocity went missing, and along with it an $18Mprobe ($152M in 2019 dollars) and a regrettable ration of American prestige.How would MIT and NASA avoid similar mistakes developing software for the AGC?

This is the second of three articles about the AGC. In part 1, we described thehardware.20 Here, in part 2, we focus on MIT's effort to developthe software.4,12,36As in part 1, the scientific computing community will recognizesome familiar themes such as the benefits and challenges of co-design, the importance ofsufficient testing resources, the role and impact of software processimprovements and more.

Initially, about all that was known with any certainty was that a digitalcomputer would be the centerpiece of a complex collection of GN&C subsystems.A year would pass before NASA selected the Lunar OrbitRendezvous37 (LOR) mission plan involving two separateand substantially different vehicles each with its own AGC.AGC software would control everything. Even so-called manually controlled inputs would firstpass through AGC software before affecting the relevant hardware makingthe Apollo spacecraft the first all-digital fly-by-wire49 vehicles ever created.

A challenge in developing the software was that all the GN&C subsystemspictured above were under development simultaneouslyright along with the software itself. Their interfaces, performancecharacteristics, size, weight and position within the spacecraft, all ofwhich affect key parameters in the guidance equations, were constantly evolving.Even techniques to manage thesoftware effort were under development and evolving with thesoftware. Eventually, NASA would pressure MIT to adopt techniques pioneeredby IBM to help manage large software development projects.

Today, we would call all of this simultaneous development activityco-design,8,9,23 and it has a lot of advantages.But, in the 1960s when there were no DevOps38 best practices and collaborative toolssuch as GitLab, Jenkins, Confluence, Kanban and WebEx, or even email, it presented a massivecoordination and management challenge.

NASA had established a need for the machine and had determined its general tasks, andMIT received a contract based on only a short, very general requirements statement.Requirements started changing immediately and continued to change throughout the program.39

Midway through development, the AGC was redesigned to support more memory and an expandedinstruction set.The original and redesigned systems were different enough that each required separate softwaredevelopment teams, a situation that only worsened already strained resources.The redesigned AGC had only 2K words of erasable core and 36K words of fixedor rope core memory. All software and data had to fit into this combined 76KB of memory.

The essential step for software developers was to produce a flight program or ropeand release it to Raytheon for rope core manufacture approximately 4 months prior to launch:2 months to manufacture the ropes followed by 2 months for installation in the spacecraft,checkout, integrated system testing, crew rehearsals and final erasable memory load.

These programs constituted what we might call today the Apollo guidance software stack.All were implemented in assembly language. By 1965, most of this code had beenwritten and fully tested and changed little with each new flight program. Allhigher level space guidance routines were implemented primarily in the Interpreterlanguage13 but also by using some of these lower-level pieces.

An example of a space guidance subroutine is computing the relative positions of Earth,Sun and Moon at any moment. After evaluating options34 in MAC50 or Fortran on mainframe systems, developers settled on an approach using 8th-degree polynomial fits totime-varying positional data predicted from mainframe solution of the 3-body (Earth, Sun, Moon)problem. Eight double-precision X, Y and Z polynomial coefficients, 48 words of data,fitting a 2-week period of Moon position data wouldthen be stored in fixed memory. Another example is a list of stars47and spatial positions used with the Apollo space sextant33requiring 112 words.41 This dataand code would be among the 76 kilobytes of a flight programhand woven into rope core in the months before launch. For time-sensitive data,multiple ropes for different launch windows would be manufactured as contingencies.A 1962 memo19 lists 45 major software analysis efforts thenunderway for various aspects of planned Apollo missions.

Flying to the moon and returning safely involved long periods of boredompunctuated by moments of extreme peril. A mission was divided into phases byvelocity change maneuvers or burns of the main engines1. A complete missioninvolved around 11 burns. For each maneuverthere was a corresponding major mode program, to handle it.For every phase of the mission, the AGC had an app for that.45

c80f0f1006