4 ms·

Thanks. Good info. It helped my search. THOSE ALARMS "It wasn't 10 seconds after the LEM was secured on the (lunar) surface that NASA was on the phones to the

by pdm55 10y ago

Thanks. Good info. It helped my search. THOSE ALARMS "It wasn't 10 seconds after the LEM was secured on the (lunar) surface that NASA was on the phones to the (MIT) Lab. This was the Lab's responsibility, our system, our machine, our alarms. "What were those alarms? We're launching (the lunar module from the moon's surface) in 24 hours and we're not going with alarms. We must have an operational computer." We really went to work. The computer seemed to be operating at 80% of its normal speed, but why? We turned to our simulation facilities. We had a high-fidelity digital simulation of the computer and the executing programs, surrounded by a digital simulation of the LEM vehicle, the equations of motion, and the gravitational environment. We also had an analog simulator with the real guidance computer, the inertial measurement unit (IMU), and a man-in-the loop. We tried every anomalous condition. We examined the executive code, the alarm mechanism, and the fundamental algorithms. We worked all night and time was running short. Our NASA buddies called us every 15-30 minutes anticipating, demanding a solution. We had to find it. We re-covered old ground, new ground, brainstorms, crazy ideas, anything." Fred H. Martin https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html http://history.nasa.gov/alsj/a11/A11_MissionReport.pdf http://history.nasa.gov/alsj/a11/A11_MissionReport.pdf Mission Report with 22 pages of text and 22 pages of diagrams describing significant problems during the Apollo 11 mission. http://www.htius.com/Articles/r12ham.pdf http://www.htius.com/Articles/r12ham.pdf Margaret H. Hamilton describes the software’s global error detection and recovery mechanisms she helped design. http://www.doneyles.com/LM/Tales.html http://www.doneyles.com/LM/Tales.html Don Eyles describes the components of the Lunar Guidance Computer.

robryk 10y ago
> 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.

by pdm55 10y ago

robryk 10y ago

> 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.