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

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:

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!

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

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

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.

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.

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.