Don Eyles

> https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html

I'm sorry to say that this particular article contains some inaccuracies.

First: The Apollo 14 fix didn't involve providing any new code to execute. The fix changed some data values in erasable memory so as to fool the computer into thinking an abort has already started. For more details see: https://www.ibiblio.org/apollo/index.html#Final_exam_for_the_advanced_student_

-- Edit: The following paragraph is wrong. --

In fact, it was impossible to execute code from erasable memory: it was a Harvard architecture machine and code memory was in the nonerasable memory.

----

In fact, the ranges of adresses for ROM and RAM were disjoint and the code likely never jumped to RAM, so it seems to have been impossible to have any executable code from RAM be executed.

Second: The Apollo 11 problems were not caused by an undesired piece of software operating during the landing. It was caused by a mechanism for updating hardware counters that used up CPU cycles. In order to simplify concurrency issues, hardware counters were not directly manipulated by hardware in LGC. There were "increase" and "decrease" interrupts, which were raised when the counter would need to be increased or decreased. These interrupts had a hardwired interrupt service routine that called a "hardware counter inc/decrement" instruction (this instruction didn't even have an opcode, because it wasn't designed to be called from actual code). This took some CPU time…

Don Eyles' writing about programming the lunar module (which was something he did!) is fantastic [1]. There's also a gallery of photos on that site and he has a whole book!

And, click around on Bret Victor's references page[2] -- it's a real treasure. Despite my constant fear that mentioning it will make it go away, it needs to be shared to be useful. It's a big collection of classic papers and interviews. Someone mentioned "As You May Think", which is on there, as is Bush's follow-up from ~20 years later, and Douglas Engelbart's own partly annotated version of the original!

Also check out folklore[3], which is a great bunch of stories about working at Apple in its early days, by people who worked there (mostly Andy Hertzfeld, I'm pretty sure).

Lastly, look up "Ignition!" by John Drury Clark[4], which is a tangent, but is amazing -- it's about the history of the design of rocket engines, largely about the wild experiments and chemical science involved, and is very well written. I didn't feel right finding a pdf to link straight to, but they aren't that hard to find.

As a bonus, this isn't so much historical, but it's a great inspirational essay, Richard Hamming's "You and Your Research"(transcript[5], a video version[6]). Talks about working at Bell Labs and the different cultural elements there across people as part of analysing what makes certain people truly great.

1 - https://www.doneyles.com/LM/Tales.html

2 - http://worrydream.com/refs/

3 -…

Indeed! He has a fun anecdote on his website [1] about the throttle control routines, which he was responsible for. His account of it is worth reading, but long story short: The ICD for the descent engine specified that its throttle response time was 0.3 seconds, and so that's what the simulator hardware implemented. Don discovered, through testing, that he only needed to code in 0.2 seconds to get a clean throttle control, and so he opted to not give it any more compensation than needed.

At some point, though, the throttle response time for the descent engine was improved from 0.3 seconds to 0.075 seconds, but the ICD was not updated. So at least Apollo 10-13* all flew with 0.2 seconds of compensation. As it turns outs, the throttle was just barely stable with this much, and if Don had implemented the specified 0.3 second compensation it wouldn't have worked.

Apollo 15-17 (and likely Apollo 14) all had this issue corrected. You can see the difference in the constant THROTLAG comparing the Apollo 13 [2] and Apollo 15-17 [3] lunar module source.

* We haven't yet found a copy of the Apollo 9 or Apollo 14 flight software, so I can't definitively say that either had the error. We do have Apollo 5 source, but THROTLAG, the constant in question, does not have the same name there, and I'm not sure what the equivalent value is.

[1] http://www.doneyles.com/LM/Tales.html (towards the bottom)

[2]…

As we're in a closed energy loop we're going to have to address this, sooner rather than later.

Every starry eyed AI/ML piece has me thinking, yes but where's the power going to come from? And where's the power on top to encrypt all this?

And quantum computing? Super-cooling at scale? Aye right pal.

The elegance of the AGC and it's approach to computing could provide a good starting point to a solution out of our mess.

to quote from a 2004 paper by Don Eyles, one of the AGC programmers:

"When Hal Laning designed the Executive and Waitlist system in the mid 1960's, he made it up from whole cloth with no examples to guide him. The design is still valid today. The allocation of functions among a sensible number of asynchronous processes, under control of a rate- and priority-driven preemptive executive, still represents the state of the art in real-time GN&C computers for spacecraft."

https://www.doneyles.com/LM/Tales.html

This summary of events is incorrect. The LM guidance computer’s executive routines detected an overload (which occurred because Buzz Aldrin had left the rendezvous radar on) and continued to operate in a degraded state where lower priority work was not performed. These faults were reported and the landing proceeded with the computer remaining responsive to inputs despite the concerns the alarms produced. Armstrong’s control changes near the end of the descent were made for reasons unrelated to the rendezvous radar error.

Modern systems use more formal techniques to achieve the same goal: graceful degradation.

For a detailed account of computer operations during the Apollo 11 landing, you can read this analysis from an engineer who worked on the program:

https://www.doneyles.com/LM/Tales.html

He overcame some computer problems as he landed the Lunar Module as well. His experience, knowledge, and sheer courage were amazing.

http://www.doneyles.com/LM/Tales.html

ABSTRACT: The Apollo 11 mission succeeded in landing on the moon despite two computer-related problems that affected the Lunar Module during the powered descent. An uncorrected problem in the rendezvous radar interface stole approximately 13% of the computer's duty cycle, resulting in five program alarms and software restarts. In a less well-known problem, caused by erroneous data, the thrust of the LM's descent engine fluctuated wildly because the throttle control algorithm was only marginally stable.