Cover of Journey to the MoonHugh Blair-Smith's Annotations to Eldon Hall's Journey to the Moon

Introduction

I make these annotations to serve several purposes. One is to record factual errors as I found them in the original edition (1996), other than simple typos. Another is to amplify and clarify the somewhat elliptical references to my own role in the development, particularly to help members of my family to find more traces of their kinsman. Yet another is to put down some good tales I would have included, which I hereby offer for a second edition if such a thing may be.

Eldon's story focuses on the hardware development, giving fairly short shrift to the software-oriented aspects of the system development, for good reasons: first, that is what he knows best, and second, the hardware story is an amazing piece of technological history, well deserving of its predominance in this book. Vision, boldness, luck, determination, skill, and more luck were Eldon's gifts that brought integrated circuits into space technology a decade before IBM plucked up the courage to incorporate them into office computers. The color plates, for the techno-historian, are like first images from a hitherto unexplored planet; they exhibit a bizarre and compelling beauty in both the microscopic pictures of the chips and the larger views of the intricate packaging that braced and coddled the tiny parts, making realizable the miraculous outcome of zero failures.

If I suggest that the book might have included more stories than it does, it is not to fault book or author, but simply to say that there are a lot of stories to be told, far too many to fit conveniently in one book. In every aspect of Apollo Guidance and Navigation there were Impossible Dreams whose dreamers had to leave their familiar Earth many times before the lunar flight. Integrated circuits, zero failures by whatever means, lightning-proof data memory, ultra-dense program memory, a repertoire of 34 instructions in a machine that might "reasonably" have had 8, another repertoire of interpreted instructions based on the unfamiliar but compact "Polish notation" of Lukasiewicz, a two-level multi-tasking operating system that has only recently been approached by personal computers, a user interface that eerily anticipated recent advances in linguistics, an extraordinary ability to adapt the processing to unforeseen circumstances, long-distance data communications protected against errors to a degree that office network engineers might still admire, mathematical filtering and modeling techniques that winkled the usable truth out of the measured motions of the jounciest, bounciest vehicles ever to fly anywhere: all these had to be achieved in ways they had never been done before, all Impossible Dreams. Truly there were giants in those days, Eldon in the front rank of them, and I too had my turn in the giant costume. The Force was with us all.

The Annotations

 

Foreword, page xix: "...integrated circuits became available in the early 1960s replacing the vacuum-tube circuitry..."

This way-too-brief summary, of a history better expressed in chapter 1, could derail an innocent younger reader. Integrated circuits replaced individual-transistor circuitry, which in turn had replaced vacuum-tube circuitry some years previously. I would place the two transitions, for the electronics industry as a whole, at about 1960 and about 1970. Led by Eldon, Apollo took the second step to production nearly one full lap ahead of the rest of the world(that's the core of this story!

Introduction, page 4: "Those superfluous operations were consuming about 10% of the computational time, enough to cause the overloads."

This may seem like nit-picking, but it wasn't "about" anything; it was exactly 15%, and thereby hangs an excellent irony. More about this at Chapter 15, page 179.

artzybasheff.jpg (59841 bytes)Part I, pages 9-10:

You can tell this is an MIT story (not a whisper about the four pioneering computers (Mark I through Mark IV) developed at Harvard throughout the '40s and the only computational resource there until about 1955. Those were not obscure machines: Mark III's "giant brain" role at ONR (Office of Naval Research) was celebrated in a memorable Artzybasheff cover painting for Time. The irony of this fact was that Eldon's imports from Harvard whom he first mentions in the Foreword (Alonso, Hopkins, and Scott) had done some of the later development on at least Mark IV. I trod the Harvard-to-MIT path just behind this group; although I had not been in the development work, the first three computers I learned to program were Mark I, Mark IV, and the Univac I. Eldon is correct in noting that the AGC's architecture owed much to Whirlwind, but he could have justly shared the credit with Harvard's Mark IV.

Chapter 1, Fig. 4, page 13:

It seems a pity to have only half the truth table here, given the central fact that you can (and we did) build every logical function out of NOR gates. The full table is:

A B C D
0 0 0 1
0 0 1 0
0 1 0 0
0 1 1 0
1 0 0 0
1 0 1 0
1 1 0 0
1 1 1 0

The output, D, is true (1) if neither A nor B nor C is true. Hence, "NOR".

It's also not really clear, from the circuit diagram printed here, that NOR gating is by far the simplest logic circuit possible. Fig. 54 (page 85) and Fig. 5 (page 14) make the point much better.

Chapter 1, page 19: "Design and production of the Block I Apollo computer consumed about 200,000 Micrologic elements."

Within this period, according to our folklore at the time, was a moment at which this activity had consumed "one fifth of all the integrated circuits there had ever been."

Chapter 2, page 32 ff: RCA Spectrum 70

RCA's first commercially viable machine was the Spectra 70, a remarkable recovery from their early disastrous "BIZMAC," the laughingstock of the industry for years.

Chapter 3, Mars Mission Study, page 47: "Model 1B became the baseline for the Apollo computer's architecture, sizing estimates, and functions."

In 1959, the Model 1A was known as the "Christmas computer" because of a wildly optimistic theory that the machine and its system software would be finished by Christmas of that year. My first assignment, on joining the Lab in September 1959, was to write an "assembler for an unknown number of machines with unknown characteristics," meaning the Mod 1A and whatever would come after it. This was what we now call a "cross-assembler," because it had to run on a "real" machine rather than the (yet unbuilt!) one whose code it was translating from assembly language to binary. The other quality, that it could be easily tweaked up to assemble code for other machines that hadn't been designed yet, does not have a modern term because as far as I know, there had never been, and has never been since, anything quite like it. In honor of the "Christmas computer," I named the assembler the "Yul System" and it served the Mod 1A, Mod 1B, Mod 3S, Mod 3C, AGC4 (Block I AGC), and two versions of the final Block II AGC. At each level, it translated two separate assembly languages: a low-level one in which each line of assembly-language text was turned into a binary instruction word of 11 bits (later 15) that the machine could execute directly, and a higher-level one in which each line was turned into a binary "interpretive instruction" which an interpreter program executed by simulating a considerably smarter computer. The Yul System itself was written in assembly language and ran on an IBM 650, in which memory was a magnetic drum, logic was vacuum tubes, and input/output was punched cards. Later I ported it to assembly language for the Honeywell 800.

Mod 1B, sporting the handsome total of 512 words (11 bits each) of program memory, was big enough to have a practical interpreter program, and one of my contributions to that involved spending a happy day or two writing a subroutine to perform addition! It was a loop that covered a whole page of assembly code; I could reproduce it from memory today.

At the same time, I got involved in designing the instruction-repertoire aspect of the successors to the Mod 1B, and the implementation of them by the arcane craft of "microprogramming." There was an abortive effort to design a 24-bit Mod 2; then my first creation was for the 15-bit Mod 3. Al Hopkins took one look at my design, pronounced it so complex as to be risky (it had a multiply instruction and some other neat stuff), named it Mod 3C (C for Complicated), and produced his own version, Mod 3S (for Simple). Prototypes of both were built, but the Mod 3C became the first Apollo Guidance Computer prototype. The quote from Eldon, above, is correct as to hardware technology and perhaps physical sizing, but Mod 3C was the architectural baseline, as Eldon says on page 70.

Chapter 4, pages 61-63:

One of the unsuccessful ideas for a navigational instrument aboard Apollo was a "deployable telescope" which would pass astronomical angle data to the computer based on a wobbly and uncertain linkage that was the object of much scorn. By great good fortune, a secretary mis-typed this item one day as "deplorable telescope" and everyone agreed she had gotten it exactly right!

Chapter 5, page 69: "Since double-precision computations (28 data bits) were satisfactory for navigation accuracy, longer word length didn't seem justifiable."

A double-precision number had two of whatever a single-precision number had one of: 28 data bits, 2 sign bits, and 2 parity bits. A somewhat different design could have had, instead, 29 data bits, 1 sign bit, and 2 parity bits, somewhat more similar to the way long and short integers are handled in modern PCs. The reasons for going the way we did involve more computer science than I want to get into here. In any case, 28 data bits is equivalent to a little over 8 decimal digits, which is enough to express the radius of the Earth in inches, or the distance to the moon in fathoms (6-foot units); that is, 28 bits of precision is more than enough because we don't(or didn't(know the radius of the Earth or the distance to the moon as accurately as that. In fact, navigation data was displayed to the crew, and downlinked to Mission Control, as 5 decimal digits, corresponding to about 17 data bits. However, it was useful to keep count of time in triple precision (42 data bits, 3 sign bits, and 3 parity bits), because timekeeping can be done with accuracies considerably better than 8 decimal digits. See also under AGC Architecture, page 114.

This whole subject came up again in picking an "off-the-shelf" computer for the Space Shuttle: the IBM standard for the two sizes of "floating point" (scientific notation) numbers provided a short size with 21 data bits and a long size with 53 data bits. I argued in vain that 21 is nowhere near enough and that 53 is almost double the requirement, but it was considered much more important that the Shuttle computers should calculate with exactly the same precision as the IBM Series 360 computers used by Mission Control.

Chapter 5, pages 70 and 73:

The most important measures of computing speed in machines of that era were: first, memory cycle time, and second, time to multiply two single-precision numbers (multiply instruction time). At least one of the multiply instruction times in Fig. 42 (page 70) and Table 7 (page 73) seems wrong to me. In the first place, it is inconceivable that AGC3, late in 1962, should multiply so much slower (634 (sec) than the Mod 3C description of 1961 (400 (sec). In the second place, I'm quite sure that my microprogram, which was common to these two versions of the machine, processed one multiplier bit in each cycle. If "cycle" means memory cycle, that makes 14 memory cycles, at 19.5 (sec, plus 1 prologue memory cycle to fetch the multiplicand from memory, plus 1 epilogue memory cycle to fetch the next instruction from memory: total 16 ( 19.5 = 312 (sec. However, I think the only cycle time I had to work with was the 39-(sec instruction cycle, and had to use a whole one of those to process each multiplier bit. Then 16 ( 39 = 624 (sec, for which 634 might be a typo. But I really don't know where 400 came from.

Chapter 5, verb-noun format, page 73:

This was invented by my good friend and later boss, Alan Green, along with Joe Rocchio (also my friend but never my boss). Their user interface program had a name of its own: Pinball Game - Buttons and Lights, and featured among its comments the only Shakespearean quotation in the Apollo software. Everybody who tells lawyer jokes knows part of Dick the Butcher's lines in Henry VI, Part 2: "The first thing we do, let's kill all the lawyers." Almost nobody remembers that Dick's next idea is to behead Lord Say, whose achievement (or crime) was to found a grammar school. The quotation in the software is from rebel leader Jack Cade's indictment of Lord Say: "It will be proved to thy face that thou hast men about thee that usually talk of a noun and a verb, and such abominable words as no Christian ear can endure to hear." The great success of the noun-verb format may well be interpreted, in the light of modern linguistics, as making good use of the central role of verb-phrases and noun-phrases in the Universal Grammar discussed by MIT's Steven Pinker in The Language Instinct (HarperPerennial, 1995).

Chapter 5, References, page 78:

References 4 and 6, to Report R-393 that I co-authored with Albert Hopkins and Ramon Alonso, are properly to AGC4, the next model in the series, rather than to the AGC3 model being discussed in this chapter. But I point them out anyway, as being my footnotes! This report, by the way, passed through the IEEE's Transactions on Electronic Computers (December 1963) to become my only author credit in hard covers, a chapter in Computer Structures: Readings and Examples, by C. Gordon Bell and Allen Newell (McGraw Hill, 1971).

Chapter 6, Fig. 50, page 82:

There's yet another variation on AGC3's multiply time: 640 µsec, contrasted with 90 µsec with Micrologic. Accepting the 640 as meaning 624 (my note against pages 70 and 73), I recall the time with Micrologic (AGC4) as being 8 memory cycles of 11.72 µsec, or 93.76 µsec. What the Micrologic really allowed us to do, to make this great improvement, was to slice each memory cycle into 12 "pulse times" as compared with perhaps 4 in the earlier (longer) cycle. If I've recalled those numbers correctly, each pulse time shrank from 19.5/4 = 4.875 µsec to 11.72/12 = 0.977 µsec, a 5-to-1 speedup in processing at the lowest level. Now the multiply instruction started with a memory cycle time in which the multiplicand was not only fetched from memory but placed (or not placed) in the product according to the first (rightmost) multiplier bit; then there followed 6 memory cycle times in each of which two multiplier bits were processed; finally in the last memory cycle time the 14th and last multiplier bit was processed while the next instruction was being fetched from memory. The faster logic, combined with a less wasteful design, sped up the critical multiplications by a factor of almost 7. As Fig. 50 shows, the overall speedup was 2.5 to 1 rather than 5 to 1, because many of the instructions had to leave some pulse times unused while waiting for the relatively slow memory.

Chapter 6, page 85: "...NASA management was quite receptive to such innovative ideas also, provided cost, schedule, and reliability could be maintained or improved. As a result, the decision [to adopt integrated circuits] came much more easily than might be expected..."

When I said luck was among Eldon's gifts, this is a big part of what I had in mind. We're talking about government here, people, can you believe it??

Chapter 6, page 87: "...fortunately for the Apollo Program, the designers had the freedom that allowed [computer design] evolution."

Some of that luck rubbed off on Al Hopkins, Ray Alonso, Herb Thaler, and me. This is where the four of us sat around a table for a week or so and sketched out the AGC4 functional design.

Chapter 6, Fig. 58, page 89:

Yet more variations in how long it took to multiply! But what's really significant about this tabulation is the repertoire of 11 instructions rather than 8. Given that we still had only 3 bits for the operation code, allowing for 8 combinations, you might well wonder how it was done.

To explain this, I need to look back at what I think was the single most valuable contribution I made to the AGC's capabilities: the INDEX instruction. In all computers except the most primitive of pioneering prototypes (such as Mod 1B), part of each instruction word is devoted to specifying indexing, that is, the trick by which a single instruction can address data in different memory locations at different times, combining the unchanging value of its own address field with the current value in an "index register." For example, a typical 24-bit machine of that time had an instruction word format composed of 3 fields: an operation code of 6 bits (64 instructions!), an indexing code of 3 bits (accessing any of 7 index registers, plus a no-indexing state), and an address field of 15 bits. But of course we didn't have 24 bits, we had 15: an operation code of 3 bits and an address field of 12 bits, none of which could very well be spared to devote to indexing. So I borrowed an obscure feature from an obscure machine by a now unremembered computer company, Bendix: an instruction that could make any data location in memory act, momentarily, like an index register. It picked up the data, added it to the next instruction, and performed the result as the next instruction, in place of the one stored in memory. That at least was my variation: the INDEX instruction made the addition affect the entire instruction word instead of just the address, though we made no particular use of this fact in programming AGC3. What I brought to the AGC4 design table was the insight that adding a data word to an instruction word could not only change the operation code as well as the address, it could create operation codes that, because of overflow, were different from any that could be stored in memory. Suddenly we had potentially 16 instruction codes instead of 8, at the price of using an INDEX instruction for every occurrence of each new "extended" instruction, whether it needed ordinary indexing or not (that's why the AGC4 multiply time is given sometimes as 93.76 µsec and sometimes, allowing for the INDEX instruction's time, as 117.2 µsec).

On the wave of this triumph, I bullied and blustered the rest of the team into accepting also my design for a divide instruction, which (as I was able to convince them eventually) did not greatly increase the machine's complexity. I believe it was Al who then demanded a subtract instruction so that programmers wouldn't have to code subtraction in a roundabout fashion. Finally we had a machine with straightforward instructions for the four basics: add, subtract, multiply, and divide. (I considered selling them a square-root instruction too, but decided to quit while I was ahead.)

Chapter 7, page 95: "Raytheon tackled rope fabrication and developed a machine for sense-line wiring. A punched Mylar tape (the output from the MIT Instrumentation Laboratory's software development process) controlled the machine ... (Plate 18)."

This was the other major function of my "Yul System," which I called manufacturing a program. Once the assembled program had been tested to the point where the powers that be were willing to invest the long fabrication cycle to make it into rope, Yul encoded the binary form of the code into a highly specialized 8-channel teletype code (specified by Raytheon for their machine) and punched that into a "paper" tape. As Eldon says, the tape we used for this purpose was not the usual pink paper at all but the more robust material, Mylar: almost untearable, impervious to oil and other factory-environment hazards, and cannot develop extra holes by any small accident.

Plate_18_small.jpg (15006 bytes)Plate 18 shows the tape reader with its takeup spool on the right, driving the larger machine. Each 8-bit row of the tape set relay switches; when settings were made by reading half a dozen or so of these rows, the fabricating machine shifted the rope frame up or down, and toward or away from the operator. The white plastic funnel (at the left end of the needle in the operator's hand) stayed in a fixed position, and the motion of the rope frame brought a particular core in line with the axis of the pair of funnels: the one you can see and its mirror image on the other side. The operator had a springlike coil of wire inside the needle; what she had to do was poke the needle carefully through the bundle of wires already passing through that core (without scraping any insulation off the 100 or so already threaded through it!), thus adding one more wire to the bundle. Then she pressed a switch to let the machine read more tape and advance the next core to the funnel position, and she passed the needle through the opposite way.

Plate 19 shows the result. I remember meeting 3 or 4 of these operators, all white-haired ladies with gentle voices and an infinitely patient dexterity.Plate_19_small.jpg (27572 bytes)

The Yul System's manufacturing function had another, more obscure, task which was entirely independent of the flight software being developed: the inhibit line tape. Before any of the sense lines were woven in, each rope frame had to have a set of inhibit lines woven to establish which core went with which address. I had to cobble up the appropriate numerical pattern in the same format as an assembled program, and run Yul System manufacturing with that input, so that the output tape would run the fabricating machine as required to weave the inhibit lines. Getting this simple task working was a big help in establishing confidence in the primary tape-punching software. Fig. 63 shows why these lines were called "inhibit" and how they work, provided that you understand that, of the 4 lines shown, the top 2 carry the core address and the bottom 2 carry the complement of the address. That is, when the direct binary address is 00, 01, 10, or 11, the complement address is 11, 10, 01, or 00 respectively, where each "1" represents a current flowing in that wire at core selection time, and each "0" represents absence of such a current. What happens at core selection time is that the Set/Reset line carries a current in the direction that would "set" all the cores (switch their magnetization to clockwise), were it not for the opposing currents flowing in half of the inhibit lines, which neutralize or overwhelm the Set current in every core but one. The result is that one core is set (magnetized clockwise) and all the rest, 3 in the illustration but 511 in each actual rope module, remain reset (magnetized counterclockwise). Then at sense time, the Set/Reset line carries a current, opposite to the setting current, which resets the magnetization of that one set core, inducing currents (logical "1"s) in the sense lines threading it.

Chapter 9, page 112: "Fortunately for the Apollo guidance computer, MIT's system and software designers came to the rescue and investigated the computational capabilities. They ... rose to the challenge and pointed out the deficiencies in the memory capacity and computational speed of the LVDC."

As one of those designers, I was on this rescue team and had my first experience of representing the Lab on a road trip. Analyzing the LVDC and what it did, I saw quickly that it was a machine designed quite narrowly for its task, which was to steer and throttle rocket engines using a technique called "adaptive polynomials." When I saw how clumsy and inefficient it would be at the nimble multi-tasking required of the AGC, I made up a nasty nickname for the LVDC: "APE," for Adaptive Polynomial Engine, in parody of Babbage's 19th-century Difference Engine concept. Several of the startling comparisons on page 113 were the results of my analysis.

The Houston trip itself holds some curious memories. Johnson Space Center was not yet built, and NASA's Manned Spacecraft Center was housed in a former oil company building designed by Frank Lloyd Wright, near Hobby airport (then Houston's only airport), about halfway down to Galveston. But the key meeting wasn't even there; it was in a large bedroom in an airport motel. We all sat around on the two king-size beds and presented a summary report to NASA people and some BellComm people led by one Ike Nahama. It must have stunned them because the rest of the trip was non-memorable, something of an anticlimax. Much of the effect was caused by an immortal sentence in Dick Battin's cover letter for our report, something like "We are astonished that BellComm could have arrived at the conclusions in their report." This was an attitude that I and everyone on the analysis team felt strongly, and we had urged Dick to express it strongly. After the NASAs and BellComms got over saying "You are what??!!", they were motivated to go over our detailed findings quite carefully. Dick and other high officials at the Lab were worried that we may have overstated our case, but history's finding became clear soon enough. So that's how to deal with naysayers, evidently: hit them with a bigger hammer.

Footnote to this history: I saw Ike Nahama about a decade later when Eldon's group (to which I then belonged) was pitching our approach to fault-tolerant computing. The pitch we brought to an audience that included Ike and other BellComms revolved around how much better our new designs were than that of the old AGC, and used some of the same arguments about voting-type redundancy that Ike had used on us in the earlier meeting. I couldn't resist breaking out of the script and reflecting on the delicious irony, while maintaining that both statements expressed the important truth of their respective times. Ike grinned and bore it like a good sport.

Chapter 10, Architecture section, esp. Tables 10 & 11, pages 120-124:

This is the final design, the culmination of all the stages of evolution we were amazingly lucky to have been allowed, and therefore the height of my mini-career as microprogrammer (omitting some really cool later designs that never went to operational status). With all possible extended instruction codes in use, the EXTEND instruction was doubled in speed and made independent of the addition-overflow stunt I had used in Block I.

Once again, major effort was expended to make the multiply instruction go fast, and as the table shows, it now took only 3 memory cycles in addition to the 1-cycle EXTEND. The key to this speedup was a wonderfully elegant technique for handling 2 multiplier bits at once, and I have never quite forgiven Al Hopkins for thinking of it before I did. Since we had the capability to shift any number 1 bit position left or right while copying it from one register to another (see top center of Fig. 74), we could perform conditional shifting based on pairs of multiplier bits. The little logic machine that did this, hidden under 2 control pulses which I believe were somewhat expressively named ZIP and ZAP, had 2 modes, as follows:

NORMAL MODE: Bits Do what to the partially developed product Do what to the mode
00 nothing nothing
01 add the multiplicand nothing
10 add the left-shifted (i.e. doubled) multiplicand nothing
11 subtract the multiplicand(!) set Borrow

 

BORROW MODE: Bits Do what to the partially developed product Do what to the mode
00 add the multiplicand set Normal
01 add the left-shifted (i.e. doubled) multiplicand set Normal
10 subtract the multiplicand(!) nothing
11 nothing(!) nothing

Then if the Borrow mode is still set at the end, add the multiplicand in once more (for simplicity, I have omitted the shift of the developing product, 2 bit positions to the right, that winds up the processing of each pair of bits in the multiplier). This meant that a multiplication by 14 data bits was done in only 8 additions or subtractions, 1 in the first cycle as soon as the multiplicand arrived from memory, 4 in the next cycle, and 3 in the last cycle while the next instruction was being fetched. Damn, that was slick.

Without reaching such heights of splendor, we also sped up the divide to 6 memory cycles after the EXTEND: the first quotient bit was developed in the first cycle as soon as the divisor arrived from memory, then 3 quotient bits in each of the next 4 cycles, and the last one in the sixth cycle while the next instruction was being fetched. In the last cycle also, the remainder was given its proper sign and placed into the lower accumulator L.

The descriptions of how the central registers were used, and of the instruction selection logic, need some correction. The buffer B held not only the next instruction but just about everything else at various times, and its complemented output (sometimes referred to as register C) was the all-important negation device, to change a positive number to its negative form or vice versa.

It is incorrect to say that bits 12, 11, and 10 were decoded to decide whether they were instruction code or address; what happened to bits 12-10 was that their use varied depending on the states of the extend bit and bits 15-13. If these were 1 and 000, implying channel instructions, then bits 12-10 were not really an instruction code but a sub-code to select only which channel instruction. These instructions were restricted to operations on the input/output channels, not the central registers.

It is also incorrect to say that instructions operating only on erasable memory required a 0 extend-bit, although that happened to be true of most of them; rather, certain 4-bit combinations of the extend bit and bit 15-13 were recognized as sets of "quarter-codes" in which bits 10-1 were sufficient to address erasable memory, leaving bits 12 and 11 free to select which of the 4 instructions in that set. There were also pairs of "quarter and three-quarter" codes in which 00 in bits 12 and 11 selected an instruction that operated on erasable memory, and any other value selected the other instruction which could operate only on fixed memory; these are identifiable in Table 11 by the fact that they all end in 'F'.

Notice in part 3 of Table 11 that there were 2 NDX (or INDEX) instructions; the extended one simply carried the force of the EXTEND instruction through to whatever instruction it was indexing. And it did not have a distinct mnemonic code NDXE in assembly language, since the assembler had to know what was indexed and what was not.

In addition to the 7 channel instructions listed in part 5 of Table 11, there was an 8th one known to the assembler as EDRUPT, meaning ED Smalley's personal interRUPT. It was simply the general program interrupt, RUPT, but placed under programmer's control. We did, however, make sure that nothing but Ed's computer self-test program ever used it! The time given for it in the Block II column, 35.1 µsec, seems correct for EDRUPT (with its EXTEND) but wrong for the involuntary RUPT, which I think was 23.4 µsec in both AGC4 and Block II.

Chapter 11, pages 133-134: "The committee ... reported the obvious that there were no formal computer specifications and no programmer's manual."

The referenced document, I'll admit, didn't look much like an industry-standard programmer's reference manual: no 200 pages of glossy paper with gobs of sample code and lots of space devoted to the assembly language rather than the machine itself. The naysayers hadn't caught on to the fact that the intended audience was familiar with a fairly similar machine (AGC4), and had been using the identical assembly language for years. So the (in)famous Memo #9, simply listing the instructions and what they did, was enough for the people that mattered, and not enough for the people who didn't matter. I wouldn't have minded bringing the old pieces together to make a full-scale updated manual, but I had plenty of stuff to do, just keeping up with new requirements.

Chapter 12, page 148: "At last, after the program was complete, the mathematicians could compute a real number for the computer's reliability..."

The joke about this point, as I remember it, was that even then the number was still smoke and mirrors, for the very good reason that computing MTBF (Mean Time Between Failures) involves dividing by the number of failures. What if the number of failures is zero, as it was here? The mathematicians looked in their reliability-theory textbooks, and found that it is standard practice in that case to assume 0.6 failures, just so you can do the division and get an answer...and never mind whether it actually means anything!

Chapter 13, page 155: "Sets of 0s and 1s were loaded into erasable memory by hand using banks of switches, a very primitive technique. When DSKY programs were available in ropes (ROM), code could be loaded manually from the DSKY, allowing greater flexibility."

I'd be surprised to learn that anything more than the simplest mini-programs, a dozen words or so, were ever entered in binary using switches after about April of 1960. Once the Yul System was up and running, it produced decks of punched cards with the program in numerical form, and later, punched paper tape and magnetic tape. We certainly wrote programs of a few hundred words for the Mod 1B in 1960, and ten times that size for AGC3 in 1962; and ten times that size again for AGC4 and Block II when the DSKYs and their programs were available. The key to getting such programs into the developing computers was an auxiliary erasable memory that plugged in where the ropes would go later, with an input unit to receive the results of assembly. Of this technology, the final expression was the Computer Test Set illustrated in Plate 40, with its paper tape reader near the top of the right-hand cabinet, and I remember that everything from Mod 3C on (and almost certainly from Mod 1B on) had the equivalent in one form or another. I have stared at Figure 45, trying to visualize how a tape reader or maybe a card reader was attached to the AGC-3 Monitor, and still can't recall it, but I'm sure it was there. We must have had a machine near the IBM 650 to translate punched cards to paper tape, because that was the low-cost mode of digital communication in those days long before networks. Later we had a neat little magnetic tape system, called Digi-Stor, whose tape reels were about 4 inches in diameter.

In any case, loading code manually from the DSKY, when it became possible, would still have been restricted to mini-program cases where it was clear that scribbling octal digits on a piece of paper, and spending about 20 keystrokes per word entering them, was quicker and easier than going to the keypunch room, typing assembly language into cards, submitting the deck to be run sometime (typically, overnight), then picking up the tape and taking it back to the lab and loading it. Yes, clearly it was quicker and easier sometimes, but I'd have considered it memorably heroic for anyone to have entered any program of more than a hundred words through the DSKY. A strange thing to contemplate, now that we regard a PC program as dinky if its executable file occupies much less than one million bytes.

Another function served by these auxiliary erasable memories was called the "Coroner," which recorded every instruction executed, with its inputs and results, writing over the oldest such record when it filled up. When a program "crashed," you could punch out a full record of what it was doing in most of its last second and analyze the problem at your ease. I have often wished that PCs offered such an advanced feature.

Chapter 13, page 156: "Software code, which operated the TV, displayed up to five simulated balls bouncing in box with a hole in the floor..."

The memorable thing about this demo was a visit from Werner Von Braun, the only time I was in the presence of the great man, though I don't think we were actually introduced. He watched the screen with visible delight for a few minutes and said, "Ach! Dot shows der computer iss on der ball!" Which is exactly what it did show; we were mighty pleased too. Don't be misled by the word "TV" there: it was a standard electronic lab oscilloscope, each "ball" was a single pixel, and the "box" was just a pair of vertical lines at the edges of the screen and a line with a gap along the bottom. No pixels in the box image, though; that was rendered in orange crayon!

Chapter 13, page 156: "In the early days of Apollo, ... even the ideas employed in assemblers ... were in their infancy."

This is essentially correct, though there were a few models to follow. I coded an entire water resources simulation application for the Univac I in alphanumeric machine code in 1957-58, and developed IBM 704 applications in in assembler language called UA SAP 3-7 (no connection with the modern SAP 3, you may be sure). The latter was a good illustration of IBM's total hardware orientation for their "scientific" machines in those days, since mainframes (704s) were originally delivered with no software whatsoever. The "UA" represents the fact that the assembler used at MIT was written at United Aircraft by a Roy McNutt, who declared on the cover sheet of the manual that "the probability that undetected bugs remain in this program differs from unity by the reciprocal of a googolplex" (i.e., the chance of bug-free operation is about that of winning all the world's lotteries on the same day). When I did my first contracting gig in 1959, for United Research, I went to the non-University 704 at the GE jet engine works in Lynn, where I had to use a subtly different assembler named CAGE (Compiled & Assembled at General Electric). That was the 704 whose time was rented by the Lab, as mentioned on page 157.

On the other hand, I did translate the water-resources program to Fortran to run it on the MIT 704, and made considerable use of SOAP (Symbolic Optimizing Assembler Program) for the IBM 650 at Harvard, switching to the Lab's homegrown FLAD (FLoating ADdress) assembler when I made the move to MIT. The Yul System's syntax was patterned mostly on SOAP.

Chapter 13, page 156: "...the AGC's assembler had to be written. This first software "tool" became available in March 1962."

This is seriously incorrect. Assembling with Yul on the IBM 650 became operational in March or April of 1960. The 1962 date refers to availability of the second-generation Yul System on the Honeywell 800 (though I recall June or July rather than March), with the capability of punching the numerical output directly into paper tape instead of cards.

Later in 1962 the Yul System included an oversimplified simulator that could test small programs that didn't make use of real-time interrupts. It had a feature that emulated and improved on the hardware "coroner:" it could detect an infinite loop and stop the simulation so you could trace down how the program got trapped in the loop. But all testing was naturally taken over by the full-scale simulator described on page 157.

Chapter 15, page 179: "The additional tasks, 6400 memory cps to count the erroneous radar input pulses, consumed 7% of the computer's computational time."

Not quite. Each of the two radar axes, shaft angle and trunnion angle, generated the 6400 pulse/second rate, for a total waste of 12,800 memory cycles in each second, exactly 15% of the machine's time. The main irony in this is that NASA's last "performance scrub" before this mission, the process of eliminating the least important functions of the program to save time, had a goal of 85%, that is, to leave 15% slack time for eventualities. We came very close in the final program design, and they said "OK." Oops. The secondary irony is that Grumman's insistence on the rendezvous radar's electrical power supply being wholly independent of the computer's power supply, intended to increase safety, actually prevented the problem from being detected in pre-flight testing; or more precisely, made it possible for random conditions during the flight to produce a problem that had too low a probability to be seen in testing.

The rendezvous radar (RR) was also the only part of the GN&C equipment for which I wrote flight software, a little piece called Routine 29. Its function, shortly after liftoff from the moon, was to wave the RR dish around the approximate direction that the CM was expected to be, monitoring the strength of the return, and so stop the searching when the return indicated that the radar had locked on to its target. To make the program run fast enough, I had to invent a heuristic: logic that should work under most circumstances, rather than an algorithm whose correctness can be proved. I never heard of its being used, and I suspect it fell victim to a memory scrub (to make the program fit in memory) or a performance scrub.

Chapter 15, page 181: "... the AGC began receiving intermittent abort commands from the main panel abort button."

The "procedure to fool the AGC's normal response" was written mostly by Don Eyles, a brilliant young man of great nervous energy who lived on Coke as far as most of us could tell. His next moment in the limelight was as a two-session contestant on Jeopardy in 1996.

Chapter 15, page 181: "... I don't know what the people who actually built the computers thought about us users, ..."

At one point, I was asked to give Dave Scott and two other astronauts a 2-hour briefing that would train them to read and understand the flight program, a notion whose level of reality must have been quickly apparent when I lugged the 1600-page program listing into the classroom. All I could do was to perch awkwardly on the big table, behind this tome, and show them how to find their way around it, in particular how to trace through all the places where a particular variable name appeared. They took in more than I would have thought probable, especially Scott, and I like to think that Dave's appreciation of the computer system was aided to some degree by my presentation.