BATTIN 3
it was dif cult to suppressour smiles. We felt j ust like Br’er Rabbit:
“Please don’t throw us in that briar patch, Br’er Frick!”
Security was also very real. Almost everything was classi ed—
even schedules.Fortunately,t hat particularphobiasoon peteredout.
At the other extreme,there were manywho advocatedcooperation
with the Russians.Dur inga paneldiscussionat an AIAA conference,
Wernher von Braun addressed the question: “Why don’t we work
together on the Apollo program?” His response went right to the
heart of the matter:
“If there were cooperation with the Russians on space-
ight, there wouldn’t be a program in either country.”
To start o ur part of the race we had rst to assemble a team. But
ndingthe rightpeople was frustrating.We had themost challenging
guidance system imaginable to develop. Recruits should have been
pounding at the door. But that didn’t happen.
In the long ru n, though, the best p eople were alreadyat the Lab—
working in other divisions. Appropriate transfers were made. Nev-
ertheless, for a very long time to come, the software task was not
adequately staffed.
We were beginning to learn that “people problems” were often
much more dif cult to solve than the technical ones.
Although we couldn’t seem to get engineers,we did get advice—
both technical and theological:
“Apollo should be launched on a clear night when the
moon is full to provide the best possible target.”
and
“If the Lord had intended man to go to the moon, He
would never have created Senator Proxmire.”
In the Software Jungle
The MIT Instrumentation Lab was designing software for the
Apollo onboard guidance system even before the word “software”
was invented.
I still remember the rst time I told my wife that I was in charge
of “Apollo Software.” She exh orted me: “ Please don’t tell any of
our friends!”
I suppose real men do “Hardware” just as real men don’t eat
quiche.
It was an attitude that prevailed a long time in many organiza-
tions. Salaries fo r computer programmers did not keep up with the
salaries of engineers.Engineers did engineering.The programming
(
or coding
)
was more menial work and should be left to others.
I wanted no such distinction. Our best engineers should design
and
program the software for the ight computers. The reasoning
was simple. A good engineer can learn to write programs. But a
computer software specialist would nd it far more dif cult to do
the engineering without considerably more training.
The basic architecture of the Apollo onboard computers was the
design of Hal Laning—certainly one of our most creative engineers,
and the early application pr ograms were written by our best system
engineers. We tried hard to keep our standards high.
Even so, with the best talent,computer programs seldom perform
as intendedthe rst time. If they work at all, they may do unexpected
or “funny” things. We called them “FLT’s”—short for
Funny Little
Things
.
This was before “Murphy” discovered his famous law. He must
have been secretly watching our software development efforts.
The Apollo Guidance Computer, or AGC as it was called, evolved
from the design for the Mars probe. In 1961, when our Apollo
contract was signed, it had 4096 words of xed memory and 256
words of erasable.
A word was 16 bits
(
that’s
bits
not
bytes
)
with one bit for sign and
one for parity check. Hence, double precision was required for most
calculations. The cycle time was modest, approximately 24¹sec,
which was more than suf cient for t he Mars application.
The xed memory was called a “core rope memory” since the
early models clearly resembled lengths of rope. The high density
of storage was achieved by “storing” a large number of bits in
each
magneticcore. A stored bit is a “one” whenever a sensewire threads
a core and a “zero” when it fails to th read a core.
In the operationof the rope memory, a core is s witched which in-
duces a voltage drop in every senseline which threadsthat core. Six-
teen sense wires were connected to sense ampli ers to detect which
had voltage drops. With the addition of an appropriate switching
network, each core could then hold several words.
All this information was permanently wired at Raytheon by
“LOL’s”—literally, “little old ladies” who slowly and painstakingly
threaded the cores by hand. Late r an ingenious adaptation o f a tex-
tile loom was used for this purpose which was far faster and cer-
tainly more reliable. The loom was driven by a punched paper tape
created by the same program that produced the mission software.
Once a memory module was manufactured, not a single bit could
be changed, either intentionally or unintentionally.
There wa s a dichotomy of opinion regarding the xed memory
concept. Once the memory had been programmed, it took about six
weeks to manufacture. Add to that the time required for testing and
you discover the rule:
No ight-computer memory changes
within two months of a launch!!
It was far too late to change the design so the argumentwas purely
philosophical:“Was it bad or was it good?”
Each side made its own case:
²
There must be a way to make last minute changes.
±
But, last minute changes may be ill-considered and/or hur-
riedly tested. They are dangerous.
In the long run, despite objections, it was good discipline and kept
everyone honest. If you know you can’t ma ke last minute changes,
then, by golly, you’ll be that much more careful in your design and
testing.
Inevitably,of course,someonewould discoverthat erasablemem-
ory could hold more than just data. You could actually write and
execute programs from the erasable memory.
By that time, though, strict NASA approval was required to
do so .
The physical sizeof the computerwasonecubicfoot.That could be
changed only at great cost since the spacecraft manufacturer,North
American Aviation,had allowed that much room and no more in the
Command Module. If we needed m ore capability, it would have to
come fro m advances in computer technology.
Eldon Hall, wh o had designed the Polaris missile computer, was
in charge of the Apollo Guidance Computer development.I can still
remember the day he asked if I could use twice a s much memory.
(
He ha d gure d out how to stuff twice as many sense wires through
a core.
)
I was ecstatic. Our prayers had been answered.
Charlie Frick, however, was not so pleased:
“You told us that 4000 words was enough. And now you
want to double it!!”
He was, obviously,a man of experiencein dealingwith unscrupulous
contractors.Doubling th e size would surely mea n doublingthe cost.
The memory size was, indeed, doubled. And it doubled twice
again after that before it went to the moon. The nal count was
36,864 si xteen-bit words for the xed memory and 2048 for the
erasable. The cycle time had also been cut in half to 12¹sec. Bu t
the physical size never did change.
We were able to cope with limited memory, limited instruction
repertoire, and short word length for mission programs by using a
powerful interpretive language.
Charlie Muntz created the “Interpreter” to manipulate the 28 bit
data words. Memory was conserved
(
dramatically, to be sure
)
but
now the time for numerical computationswas measured in millisec-
onds:
²
Double-precisionadd—0.66 millisec
²
Double-precisionmultiply—1.1 millisec
²
Double-precisionsquare root—1.9 millisec
²
Double-precisionsine—5.6 millisec