As a realtime/scientific programmer, contracted to NASA via McDonnell-Douglas Astronautics, here's a highlight from my work on two events for two missions. With appreciation to my NASA mentor Chuck Pliske and to Dave Lang, and from MDA, Harold Ipolyi, Richard Hamm and others.
A) Apollo 11 - Patching the Apollo Guidance Computer(AGC) in realtime while Michael Collins was flying a critical mission on the CMPS
In early 1969, Astronaut Collins was scheduled to come in to train on P56 on the CMPS. I was told he had to successfully complete 4 such missions if we were to launch in 1969. I was the only one at the CMPS when he showed up early, I was 23. He walked up and with sterness asked if the program was operable, 'uh, yes sir'. Everybody else showed, a general and such, so he began the program and I sat down at the console and could look at memory. GAWK, a floating point number had been written into the return stack. While he was still flying and just before exiting the program I, in octal code, changed the return to a jump to a part of memory I knew was free and I set up a call to P00. That's Pooh's corner as Margaret Hamilton might say. I set it up for just a casual visit, unlike the call after the 1202 alarm during the lunar landing, a problem we were working on at the time, job stack overflow caused by the task stack sending too much too often. Later I found the missing single line of code in P56, a register clear opcode.
B) Apollo 13 - Flashing in realtime the computer controlling the CMPS for Ken Mattingly
While watching the Apollo 13 movie a scene was re-created that jarred me in remembrance such that I remarked to my wife they are talking about software that I wrote. Now the story, while walking in the hallway of Bldg 13 during the mission, home of the CMPS & LMPS, the trainer, an ex-helicopter pilot who had served in Vietnam said to me, "Ken asked to use your Checkpoint/Restart (CR) routine to create a mission right before, 'and he laughed' he keeps crashing the simulator. CR was a piece of software that allowed the simulation to be saved at a point and then restarted at the exact same realtime. It used to take 3 weeks to complete the parameters for a particular simulation to be set up to start. I re-wrote the I/O sub-system of the Control Data computer to set up a special bus-mastered DMA call. When Ken pressed the hardware switch, I checked that before all else during the analog/digital hardware interrupt sequence, and then put the large block of data, all the critical parameters out to disk in one realtime clock cycle. By freezing action just before the SPS firing Ken was able to try and re-try the firing to get the necessary, very narrow attitude and timing of the firing solution. Geek programmer side note: I was testing the routine Friday evening, after main shift 6PM, I typed "1500 0000 0400 0000" the sixty bits of the computer word into the interrupt register 0 to make sure no other interrrupt got in my way. After I hit return every display light controlled by the Control Data 6400 blinked once then off for both the CM and the LEM. Computer operator, Horace was his name, said it would take 2 1/2 hours to restore the system, I went down to the bar with the night engineers, had a good time.
C) Creating a mathematical curve of the earth's atmospheric density
The simulating spacecraft needed a way of obtaining the drag coefficient of the earth's atmosphere at any altitude. JPL sent us a table of measurements of the drag at various altitudes obtained from hot air balloons. Graphing them I used curve fitting techniques to determine the slope and the inflection points for the data. What resulted was a fourth degree polynomial for the upper atmosphere and a fifth degree polynomial below some altitude. Then I used equations of numerical analysis I found in the books at the MSC library written by Indian mathematicians. I programmed the numerical algorithms into the Fortran programming language for the simulator. It's mathematics like this that was "not done" before computers due to the immense calculations involved.
D) Angry Astronaut
Prior to Apollo 13, back-up command module pilot Jack Swigert while training became upset with the response of the DSKY, the display keyboard. He "threw the AGC manual" at the same trainer as mentioned above. I was told that Astronaut Swigert wanted to show me, the responsible programmer, how the DSKY should respond, (is this the 1st recorded instance of an enraged computer user?). So he had me attend the next scheduled training on the "real" command module, one of three made, in Building 5 MSC. After doing a star sighting alignment he instructed the AGC to re-calculate the spacecraft's position relative to the moon, earth, sun. While the AGC crunched through Kepler's equations, Jack entered a verb-noun to read a simple memory value, fuel? So I said to myself that's nice, the AGC is executing a million transcendental calls per real time frame and you want to check the fuel before it's done.
Problem solution: this was a real learning experience for me. 1) I spent a week looking at the programming of Kepler's equation and found an innermost loop of which contained a NOP, 3 nanoseconds in duration. By factoring I was able to remove that instruction, thus saving 1 million times 3 nanoseconds in processor time. 2) I looked at the AGC program blocks and found about four intermediary places where I could place calls to the executor in the form of