Dealers of Lightning (25 page)

Taylor had to admit that the affair was a complete frost. "It ended up
like a trial," he said. "Butler and Chuck Thacker knew the Sigma system
very well, and they just demolished the Sigma 7. They gave the SDS peo­ple fits." When the inquisition finally concluded, Pake took Taylor aside.
"You sure know a bunch of smart people," he said. "Butler Lampson
seems to understand those guys' machines better than they do."

Neither side seemed able to budge, despite Pake's efforts to find
grounds for a truce. He recalled "I asked my guys, 'Is there any way we
can reconfigure that Sigma machine and make it work?' The answer
kept coming back no from everybody. Meanwhile we talked to SDS to
see if they were interested in making any changes. They weren't. They
wanted to sell us whatever they had."

Pake's desperation communicated itself to the computer scientists. The
choices indeed looked bleak. They could accept the Sigma, which meant
suffering with an inadequate machine
and
knuckling under to the corpo­rate suits the very first time their interests conflicted.
Or
they could stand
their ground and browbeat Xerox into buying them the PDP "But that
would cost us so many brownie points we figured it was not a good idea,"
Lampson recalled. Not a few times in the heat of discussion was the sug­gestion heard that they should all just quit.

Yet a different impulse, one much more powerful, was beginning to
assert itself. This was the engineer's equivalent to the "fight or flight"
syndrome, the instinct when confronted by an obstacle not to back off,
but to barrel through it.

"We started having these long discussions," Alan Kay remembered.
"I
was saying, 'Let's not chuck our badges in just yet. Let's think it through.'"
Someone else suggested that perhaps they were looking at the question
from the wrong end. They had made an issue out of hardware
—
what
machine to buy
—
when their real concern was software—what programs
they could run. What if they simply built their own machine to run the
programs they needed?

Asking the question was the same as answering it. "The talk," Kay
said, "turned to how long it would take us to
build
our own PDP-10."
The answer was about one year and less than $1 million. The truth was
that Xerox had only forbidden the lab to buy a PDP-10. Nobody had
said anything about cloning one. 'We were fearless," Lampson recalled. "We had built this BCC
machine which was a substantially more complicated and elaborate
machine than a PDP-10. And furthermore the underlying technology
was evolving very rapidly, so we actually had much better physical
resources at our disposal. We had great confidence that we could build
this thing with a fairly modest investment of effort, and very little risk.
Which turned out to be absolutely correct." The machine, he said, "was
not
built because Xerox refused
to
let us
buy a PDP-10,
but
because we
thought it was the path of least
resistance."

Work on
the clone began in
February. Thacker
assumed the
role
of
project manager as well as the
bedrock task
of designing the internal
logic.
The
other jobs got apportioned
out to the
lab members willy-nilly,
as among townspeople at a community barn-raising, often with little rela­tion to the work in which they were
most expert—
but then, anyone who
could make it through Taylors selection
process
was assumed
to
be smart
enough to learn anything. Lampson
was an
operating systems designer
nonpareil,
for example, but with
Tenex they
already had their
operating
system.
So
he was dragooned into designing the central processor,
a hard­
ware task unlike anything he had
ever undertaken
in his life.

Another
who got swept into the project was
Ed McCreight,
an
ex-
Boeing engineer of unshakably sunny disposition who was
still
in his first
week
or two on the job, "rummaging around for something
to
do."
No
one could remain in that state for long at
PARC.
Thacker
lassoed
him
into designing the disk controller, a hardware unit that would supervise
the
way
the machine moved data to and from a spinning magnetic
hard
disk.
McCreight
recalled,
"I
told him,
'I
don't know squat about disk
con­
trollers but, hey,
I'm
game.
If
you promise to answer all of
my
questions
I'll
do it.'"

They
all were game because they viewed the task as the
construction
of their own laboratory. One principle Taylor imparted to his
people
was that the things they built had to be designed for daily use.
Too
many
research
labs turned out playthings and prototypes
designed to
go on
a
shelf,
as
though merely for display.

"They
show wonderful things and nothing much ever comes
of
them," he complained. That would not happen on his watch.
They
would build nothing that could not be put to work, because that
was
the only
way to
find out in the end if the stuff was any good.

This rule would become one of the hallmarks of
PARC's
creative
method. Undoubtedly it held special meaning for the
CSL
members
who had lived through the painful saga of Berkeley Computer, whose
machine relied too much on idealistic designs and not enough on
working pragmatism. As Kay recalled, "Within a couple of weeks after
the BCC people showed up Butler got up at a meeting. BCC had
failed and he was still venting. He said he was sick and tired of the six­ties, when your stuff 'sort of worked and you could usually get it to
work long enough for a demo, but that was about it. He said we should
decide never to make something at PARC that isn't engineered for a
hundred users. If we were building a time-sharing computer, it should
support a hundred people, a network should take a hundred connec­tions, and so on. Our initial reaction to that was, 'Gee, it's really going
to cramp our style.' But in fact the extra thought we had to put into
everything in order to support it for a hundred users made things work
so much better that it probably sped us up by a factor of three."

The idea that they were building their own computing environment
galvanized them into working at breakneck speed, like settlers hastening
to erect a rudimentary shelter before the onset of a hard winter. An
almost alchemical change overtook the lab, infusing it with the pure
excitement of discovery that a research manager may be lucky to witness
once in a lifetime. People would contend later that being forced to clone
the PDP-10 was the best thing that ever happened to CSL—even Strassmann eventually bragged, "I made everyone a hero." This is the period
they were referring to, when a bunch of disparate talents came together
in appreciation of the virtues of working together on challenges that had
virtually no precedent and the air filled with new ideas. Then there was
the added satisfaction of testing their mastery of a new technology. "It
was fun," Lampson said later, "to see how easy it was."

The fundamental problem was that to the extent the PDP-10's phys­ical design belonged to Digital Equipment Corporation it could not
simply be copied, at least not legally. In any case, no one at PARC had
spent enough time inside that machine to reproduce it circuit for cir­cuit. The trick was to turn this limitation into an advantage. Since the
task at hand was not really to build a PDP-10, only a machine that
would follow the same instructions as a PDP-10, there was no reason
not to find a shortcut. The best shortcut, as they all knew, was to substi­tute their own microcode for the PDP-10's wiring.

DEC's machine, as it happened, was the epitome of the "hard­wired" computer. Its operation depended on the physical configuration
of its transistors; these were arranged into intricately linked "gates"—
the building blocks of traditional digital computers that received
electrical impulses at one end and passed, propagated, blocked, or
modified them according to the rules of binary mathematics and nine­teenth-century Boolean logic.

From thousands of these devices, artfully arranged, could be con­structed a machine able to add, subtract, multiply, and divide; read a
character from a teletype and output it to a cathode-ray screen; or fore­cast the trajectory of a launched missile. But it was no longer necessary to
fashion the gates out of wires and transistors. In place of much of the
PDP-10's intricate circuitry the CSL engineers planned to substitute a
class of software known as microcode.

One can think of microcode as a way of allowing digital signals to
replicate the twists and turns of a hard-wired machine's circuits with­out actually traversing the physical pathways. Microcode examines a
programmed instruction, determines where it would end up if it
primly followed all the wiring, and deposits it in the right place without
making the arduous overland trek.