<commit_before><!--- WARNING: DO NOT EDIT! Auto-generated with wikize_refs.py from ApolloGuidanceComputerPart2.md --->
# Celebrating Apollo's 50th Anniversary: The Oldest Code on GitHub

**Hero Image:**

 - <img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0615_Apollo2.jpg' />

#### Contributed by [<NAME>](https://github.com/markcmiller86)
#### Publication date: June 17, 2019

*Second of a three-part series to commemorate the 50th anniversary of the Moon landings.*

Retrocomputing enthusiasts recently uploaded Apollo Guidance Computer (AGC)
source code for various Apollo missions to GitHub. There is even a *Virtual AGC*
that can run this code.<sup>[7]</sup> In all likelihood, it is the oldest *active* code on
GitHub. Remarkably, its development began over half a century ago in the ashes
of Mariner 1, a Venus probe destroyed shortly after launch because of a bug in its
guidance software.<sup>[15],[35]</sup> The prevailing explanation was that in the
transcription of hand-written guidance equations into a software specification
for the contractor, TRW, an overbar to indicate the use of *average* rather than
*instantaneous* velocity went missing, and along with it an $18M
probe ($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](https://bssw.io/blog_posts/celebrating-apollo-s-50th-anniversary-when-100-flops-watt-was-a-giant-leap), we described the
hardware.<sup>[20]</sup> Here, in part 2, we focus on MIT's effort to develop
the software.<sup>[4],[12],[36]</sup>
As in part 1, the scientific computing community will recognize
some familiar themes such as the benefits and challenges of *co-design*, the importance of
sufficient testing resources, the role and impact of software process
improvements and more.

### Extreme Co-design
Initially, about all that was known with any certainty was that a digital
computer would be the centerpiece of a complex collection of GN&C subsystems.
A year would pass before NASA selected the Lunar Orbit
Rendezvous<sup>[37]</sup> (LOR) mission plan involving two separate
and substantially different vehicles each with its own AGC.
AGC software would control everything. Even so-called manually controlled inputs would first
pass through AGC software before affecting the relevant hardware making
the Apollo spacecraft the first all-digital *fly-by-wire*<sup>[49]</sup> vehicles ever created.

<br> 

<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0619_agc_and_spacecraft3.png' class='page' />

<br> 

A challenge in developing the software was that all the GN&C subsystems
pictured above were under development *simultaneously*
right along with the software itself. Their interfaces, performance
characteristics, size, weight and position within the spacecraft, all of
which affect key parameters in the guidance equations, were constantly evolving.
Even techniques to manage the
software effort were under development and evolving with the
software. Eventually, NASA would pressure MIT to adopt techniques pioneered
by IBM to help manage large software development projects.

Today, we would call all of this simultaneous development activity
*co-design,*<sup>[8],[9],[23]</sup> and it has a lot of advantages.
But, in the 1960s where there were no DevOps<sup>[38]</sup> best practices and collaborative tools
such as GitLab, Jenkins, Confluence, Kanban and WebEx, or even email, it presented a massive
coordination and management challenge.

### Evolving requirements, versions and flight rope releases
> NASA had established a need for the machine and had determined its general tasks, and
> MIT received a contract based on only a short, very general requirements statement.
> Requirements started changing immediately and continued to change throughout the program.<sup>[39]</sup>

Midway through development, the AGC was redesigned to support more memory and an expanded
instruction set.
The original and redesigned systems were different enough that each required separate software
development teams, a situation that only worsened already strained resources.
The redesigned AGC had only 2K words of *erasable* core and 36K words of *fixed*
or *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 *rope*
and 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.**

MIT needed to deliver flight programs for ~30 Apollo flights (crewed and uncrewed),
many with unique guidance requirements, planned between 1966 and 1972.<sup>[40]</sup>
The lead engineer in coordinating and approving a completed flight program was
called a *rope mother* and would also name the release. Early on, the names were fairly
creative, including ECLIPSE, SUNRISE, RETREAD and AURORA. Eventually,
NASA put a stop to this, and only the names COLOSSUS and LUMINARY together
with their revision numbers would be used to identify CM and LM flight programs,
respectively.<sup>[24]</sup> LUMINARY 1A is the revision used in the first lunar
landing of Apollo 11.

### The AGC software stack
Each flight program involved a combination of common utilities and mission-specific
space guidance subroutines. Mission-specific components required significant
analysis and development time. Early development activity, 1961-1965, focused on
infrastructural software.

<strong>Program Name</strong> | <strong>Purpose</strong> | Size (AGC words)
:--- | :--- | ---:
Executive<sup>[25]</sup> | Priority-driven large/long-running process manager | ~350
Waitlist<sup>[26]</sup> | Time-sequenced small/short-running process manager | ~300
Down-Telemetry<sup>[29]</sup> | Transmit system data to ground | ~200
Restart<sup>[30],[31],[32]</sup> | Error recovery and restart protection | ~1225
Interpreter<sup>[27]</sup> | Space guidance domain-specific programming language interpreter | ~2200
DSKY I/O<sup>[28]</sup> | Cockpit displays and keypad | ~3500
<strong>Combined Total</strong> | 22% of fixed memory | ~7775<commit_msg>table update<commit_after><!--- WARNING: DO NOT EDIT! Auto-generated with wikize_refs.py from ApolloGuidanceComputerPart2.md --->
# Celebrating Apollo's 50th Anniversary: The Oldest Code on GitHub

**Hero Image:**

 - <img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0615_Apollo2.jpg' />

#### Contributed by [<NAME>](https://github.com/markcmiller86)
#### Publication date: June 17, 2019

*Second of a three-part series to commemorate the 50th anniversary of the Moon landings.*

Retrocomputing enthusiasts recently uploaded Apollo Guidance Computer (AGC)
source code for various Apollo missions to GitHub. There is even a *Virtual AGC*
that can run this code.<sup>[7]</sup> In all likelihood, it is the oldest *active* code on
GitHub. Remarkably, its development began over half a century ago in the ashes
of Mariner 1, a Venus probe destroyed shortly after launch because of a bug in its
guidance software.<sup>[15],[35]</sup> The prevailing explanation was that in the
transcription of hand-written guidance equations into a software specification
for the contractor, TRW, an overbar to indicate the use of *average* rather than
*instantaneous* velocity went missing, and along with it an $18M
probe ($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](https://bssw.io/blog_posts/celebrating-apollo-s-50th-anniversary-when-100-flops-watt-was-a-giant-leap), we described the
hardware.<sup>[20]</sup> Here, in part 2, we focus on MIT's effort to develop
the software.<sup>[4],[12],[36]</sup>
As in part 1, the scientific computing community will recognize
some familiar themes such as the benefits and challenges of *co-design*, the importance of
sufficient testing resources, the role and impact of software process
improvements and more.

### Extreme Co-design
Initially, about all that was known with any certainty was that a digital
computer would be the centerpiece of a complex collection of GN&C subsystems.
A year would pass before NASA selected the Lunar Orbit
Rendezvous<sup>[37]</sup> (LOR) mission plan involving two separate
and substantially different vehicles each with its own AGC.
AGC software would control everything. Even so-called manually controlled inputs would first
pass through AGC software before affecting the relevant hardware making
the Apollo spacecraft the first all-digital *fly-by-wire*<sup>[49]</sup> vehicles ever created.

<br> 

<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0619_agc_and_spacecraft3.png' class='page' />

<br> 

A challenge in developing the software was that all the GN&C subsystems
pictured above were under development *simultaneously*
right along with the software itself. Their interfaces, performance
characteristics, size, weight and position within the spacecraft, all of
which affect key parameters in the guidance equations, were constantly evolving.
Even techniques to manage the
software effort were under development and evolving with the
software. Eventually, NASA would pressure MIT to adopt techniques pioneered
by IBM to help manage large software development projects.

Today, we would call all of this simultaneous development activity
*co-design,*<sup>[8],[9],[23]</sup> and it has a lot of advantages.
But, in the 1960s where there were no DevOps<sup>[38]</sup> best practices and collaborative tools
such as GitLab, Jenkins, Confluence, Kanban and WebEx, or even email, it presented a massive
coordination and management challenge.

### Evolving requirements, versions and flight rope releases
> NASA had established a need for the machine and had determined its general tasks, and
> MIT received a contract based on only a short, very general requirements statement.
> Requirements started changing immediately and continued to change throughout the program.<sup>[39]</sup>

Midway through development, the AGC was redesigned to support more memory and an expanded
instruction set.
The original and redesigned systems were different enough that each required separate software
development teams, a situation that only worsened already strained resources.
The redesigned AGC had only 2K words of *erasable* core and 36K words of *fixed*
or *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 *rope*
and 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.**

MIT needed to deliver flight programs for ~30 Apollo flights (crewed and uncrewed),
many with unique guidance requirements, planned between 1966 and 1972.<sup>[40]</sup>
The lead engineer in coordinating and approving a completed flight program was
called a *rope mother* and would also name the release. Early on, the names were fairly
creative, including ECLIPSE, SUNRISE, RETREAD and AURORA. Eventually,
NASA put a stop to this, and only the names COLOSSUS and LUMINARY together
with their revision numbers would be used to identify CM and LM flight programs,
respectively.<sup>[24]</sup> LUMINARY 1A is the revision used in the first lunar
landing of Apollo 11.

### The AGC software stack
Each flight program involved a combination of common utilities and mission-specific
space guidance subroutines. Mission-specific components required significant
analysis and development time. Early development activity, 1961-1965, focused on
infrastructural software.

Program Name | Purpose | Size (AGC words)
:--- | :--- | ---:
Executive<sup>[25]</sup> | Priority-driven large/long-running process manager | ~350
Waitlist<sup>[26]</sup> | Time-sequenced small/short-running process manager | ~300
Down-Telemetry<sup>[29]</sup> | Transmit system data to ground | ~200
Restart<sup>[30],[31],[32]</sup> | Error recovery and restart protection | ~1225
Interpreter<sup>[27]</sup> | Space guidance domain-specific programming language interpreter | ~2200
DSKY I/O<sup>[28]</sup> | Cockpit displays and keypad | ~3500
Combined Total | 22% of fixed memory | ~7775
{'fraction_non_alphanumeric': 0.07215766331658291, 'fraction_numerical': 0.022770100502512564, 'mean_word_length': 5.2466895537027955, 'pattern_counts': {'":': 0, '<': 89, '<?xml version=': 0, '>': 95, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1557662', 'n_tokens_mistral': 3647, 'n_tokens_neox': 3186, 'n_words': 1658}