Building Programs

For about four years, the programming effort trundled along at a comparatively leisurely rate while the hardware design proceeded apace. No more than a hundred people worked on software until mid-1965, when the hardware effort peaked with more than six hundred people. Once the hardware design was completed, however, the manpower began to decline, and by the end of 1966 there were more people assigned to the software effort (about two hundred and fifty), which peaked at more than four hundred in mid-1968.25 These numbers reflect the last-minute programming crises that arose before the flights (figure 7.1).

Apollo programmers faced an irony: the early missions were unique test flights requiring custom programs whereas the later, more challenging flights with landings tended to have more uniform requirements. For each mission, the IL developed a ''guidance systems operations plan,'' or GSOP, that had all the specifications, parameters, and custom routines (the CSM and LM each had their own GSOP for a particular mission). Essentially a series of equations and flowcharts, the GSOP theoretically contained everything required in advance to produce the program code for each mission. In practice, the GSOPs tended to document code after it was written, rather than specifying it beforehand.26

For each mission, the infrastructure for running and managing the programs came together with the GSOP and generated code that implemented the equations for navigation, targeting, and trajectory calculations, based on Battin and Laning's work. Early missions, unmanned test flights, tended to be sequence-oriented, commanding the spacecraft to do a series of specified operations, or allowing control from the ground. Final versions were named after the sun (Apollo being the sun god): ECLIPSE, SUNRISE, and CORONA. Some were just collections of routines for testing, others, like SOLARIUM, actually flew and executed real maneuvers. SUNDANCE evolved into the program for the LM. These programs were divided into two categories, for the two spacecraft. A naming contest for programs beginning with ''C'' for the command module and ''L'' for the LM rejected ''coughdrop'' and ''lemon.'' Instead, COLOSSUS flew on the command module, and LUMINARY flew on the LM, each in various

MIT Instrumentation Lab Apollo manpower plots, showing the time difference between the peak of the hardware and software efforts. Note the rapid rise in software manpower during 1966 when five core ropes (i.e., flight programs) were being developed simultaneously, and when Bill Tindall from NASA intervened. These figures do not include subcontractors. (Redrawn by the author from Johnson and Giller, ''MIT's Role in Project Apollo, Vol. V,'' 19-21.)

Figure 7.1

MIT Instrumentation Lab Apollo manpower plots, showing the time difference between the peak of the hardware and software efforts. Note the rapid rise in software manpower during 1966 when five core ropes (i.e., flight programs) were being developed simultaneously, and when Bill Tindall from NASA intervened. These figures do not include subcontractors. (Redrawn by the author from Johnson and Giller, ''MIT's Role in Project Apollo, Vol. V,'' 19-21.)

versions (LUMINARY IA, for example, ran the Apollo 11 landing). These had full display and keyboard functions and allowed the astronauts to select and run individual programs (figure 7.2).27

Programmers labored under strict constraints. All of the programming was done with punch cards—there were no ''online'' terminals for rapid interaction with the computer. In typical hacker fashion, stacks of program cards were assembled at night. Managers used this rhythm to advantage and began to hold nightly ''configuration control boards'' that would incorporate any changes that had been made during the day into a single overnight computer run. Cumbersome as it might seem today, the nightly builds proved an effective means of keeping control of the software changes.28

Along with schedules, limited onboard memory imposed the tightest constraints. NASA and the IL had to come up with strict priorities about what was important enough to include in a flight. Jack Funk at NASA felt that from the beginning of the program, the IL ''made a fantastic error in judgment'' in their estimate of the memory

Figure 7.2

Timeline of software versions and Apollo flights. Note the busy years of 1966 and 1967, when five and six ropes were in development, respectively. (Redrawn by the author from Johnson and Giller, ''MIT's Role in Project Apollo,'' 22.)

capacity required for the Apollo computer, in part by including only enough in their estimate for the calculations themselves and not enough capacity for the executive and other infrastructure that would make the life-critical system ultrareliable. ''That was some battle, to convince people that we needed that big a computer to begin with,'' he said.29 The original Mars computer had 4,000 words, which was what the IL proposed for Apollo. As built, the original Apollo computer had 8,000 words fixed memory, then it was doubled to 16,000, then to 36,864 fixed memory and 2,048 words erasable for the Block II.

In today's world of prodigiously cheap memory, it is easy to forget how dear storage space was in those days. A great deal of programming effort went into shrinking the memory required. Different routines could actually share the same erasable memory for storing parameters, for example, but only if they never ran simultaneously. With the asynchronous executive, that was not always perfectly predictable, leading to subtle problems with overlapping data. Moreover the software tended to accumulate functions as time went on and hardware units were eliminated or consolidated, so memory and processor time became ever more stuffed.