Annotations to Eldon Hall's Journey to the Moon.

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:

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