> https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html I'm sorry to say that this particular article contains so

> https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html 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_ https://www.ibiblio.org/apollo/index.html#Final_exam_for_the... -- 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 each time it happened. Rendezvous radar angle was the counter that caused the problem. The reason that counter caused the problem was that when the radar was not set to computer control, the radar position signals going to computer could indicate random quickly changing garbage. For more details see: http://www.doneyles.com/LM/Tales.html http://www.doneyles.com/LM/Tales.html Why do I trust my sources more? In the first case, because I can actually verify that solution on the simulator and because the machine language documentation that was used to create the simulator makes it clear that code and data address spaces are separate. In the second case, because it's a more detailed description that matches what I know about LGC from other sources and because it comes from Don Eyles.