Dealers of Lightning

Home > Other > Dealers of Lightning > Page 21
Dealers of Lightning Page 21

by Michael Hiltzik


  Now English volunteered some further advice to his wounded young colleague. Among the PARC brass, Kay lacked credibility. All the way up to George Pake he was regarded tolerantly as a sort of precocious child, engaging enough in his place but profoundly in need of adult supervision. His reputation as a dreamer only made it easier for bureaucratic types like Jerry Elkind to dismiss his ideas without afford­ing them serious scrutiny. English informed Kay, in essence, that his barefooted treks through Ideaspace would no longer do. He had to learn to develop written research plans, compile budgets, and keep notes—in short, to look and act like a serious researcher.

  Kay took the advice to heart. Over the next few months he drafted a detailed plan for a music, drawing, and animation system to teach kids creative programming on Novas. He did not abandon his cherished miniCom, but recognized that he would have to reach the grail via a series of smaller steps and commit himself to a program of several years. The effort bore fruit. By summers end he had acquired a $230,000 appropriation to equip a bank of Novas with character generators that produced text and simple graphics for display on a high-quality screen. His small group of learning software specialists had been about to begin developing the programming environment for this jury-rigged system when Lampson and Thacker knocked at his door with a different idea.

  Elkind, not for the last time, had been following a different vector from that of his principal research scientists. As it happened, many CSL engineers were convinced that time-sharing's potential was thoroughly exhausted. Lampson and Thacker had thought hard about how to redis­tribute computer power so no one would have to share processing cycles with anyone else. They agreed with Kay that this meant building dozens of individual machines, not just one. This would take money. Not that funds were scarce at PARC; but they were scattered too widely for any single group to have enough to finance the massive engineering program they envisioned. What was required was a fiscal version of "Tom Sawyering," in which they would collect contributions from every interested researcher and rake them together in one great pile.

  Thacker and Lampson regarded Kay as a prime donor. For one thing, the architecture of his cherished Dynabook, or miniCom, or Kiddicomp—whatever he was calling the thing in its latest incarna­tion—corresponded neatly with their own visions of the ideal personal computer—for Lampson a suitcase-sized MAXC with a component cost of about $500; and for Thacker a computer with the Nova 800’s capabilities and ten times its speed.

  The notions of all three intersected at one common goal: a fast, com­pact machine with a high-resolution display. "The thing had to fit in a rea­sonable sized box and it couldn't cost too much," said Lampson. "Small and simple was critical, because the whole point of it was to have one for everybody." By combining the latest electronic components coming into the market with their own powerful intellects, they might just pull it off. Not the Dynabook in all its interactive glory, perhaps, but a giant leap in the right direction—in Kay's words, an "interim Dynabook."

  Hearing their offer, Kay could barely contain his excitement—until he realized they might still face one important obstacle.

  "What are you going to do about Jerry?" he asked glumly. Elkind still controlled the CSL budget. Lampson and Thacker had both been present the day he shot down the miniCom. Was there really any hope that he would see this new project any differently?

  "Jerry's out of the office for a few months on a corporate task force," Lampson replied. "Maybe we can sneak it in before he gets back."

  "Can you get it done that quickly?"

  'We'll have to. Anyway, there's another reason to move fast."

  "What is it?"

  That was when they told him about Thacker's bet.

  "Bill Vitek was a vice president at SDS," Thacker recalled later. "I had been down in El Segundo visiting SDS for some reason I don't remember. We didn't make a lot of friends there when we built MAXC, and the fact it took only eighteen months led them to think that somehow we had cheated, although they couldn't quite figure out how.

  "So I was arguing about that with Bill Vitek, and being a cocky and fairly arrogant guy I said, 'You know, you can build a computer in three months if it's small enough.' And Vitek said, 'Aw, bullshit!' And I said, 'Not bullshit at all!' And we ended up betting a bottle of wine or a din­ner, I don't even remember which.

  "But I do remember that I won that bet."

  Chuck Thacker started designing the Alto on November 22, 1972. He enlisted Ed McCreight to help with the engineering and com­pleted the design before the end of February, beating Vitek's deadline.

  The original plan was to manufacture up to thirty Altos for distribu­tion to the engineers in the Computer Science Lab and to Kay's Learn­ing Research Group (his seed money was allocated to finance the first ten). But from the moment of its birth the Alto created a sensation. As Taylor had long anticipated, the power of the interactive display spoke for itself. The Alto's screen, whose dimensions and alignment repli­cated that of an 8½-by-ll-inch sheet of paper, produced such a vivid impression that the lab's modest construction plan was soon expanded. In the end Xerox would build not thirty Altos, but nearly two thousand.

  The Alto was by no means the fastest or most powerful computer of its time. MAXC could blow it away on any performance measure in existence and for a considerable time remained the machine of choice at PARC for heavy-duty computation. Even without the burden of illu­minating the full-screen display, the Alto ran relatively slowly, with a processor rate of less than 6 megahertz (the ordinary desktop personal computer as of this writing runs at a rate of 400 MHz or faster); the display slowed it further by a factor of three.

  But the Alto's great popularity derived from other characteristics. To computer scientists who had spent too much of their lives working between midnight and dawn to avoid the sluggishness of mainframes burdened by prime-time crowds, the Alto's principal virtue was not its speed but its pre­dictability. No one said it better than the CSL engineer Jim Morris: "The great thing about the Alto is that it doesn't run faster at night."

  Then there was the marvelous sleekness of its engineering. To some extent this was an artifact of Thacker's haste, for his tight deadline erased any impulse he might have felt to create a second system varia­tion on MAXC. There was simply no opportunity for biggerism.

  Instead, to save time and money Thacker and his team went entirely the other way. Alto was like a fine timepiece somehow assembled from pieces of stray hardware lying around the lab. Rather than design new memory components, they ingeniously reused boards that had already been built for MAXC. Ed McCreight revisited his own design of the MAXC disk controller and managed to strip out a few more circuits for the Alto. Even the display monitors were appropriated from POLOS, which had fallen so far behind schedule that its specially ordered video display terminals were still sitting around in boxes.

  In almost every respect the Alto design was so compact and uncom­plicated that during the first months, while prototypes were still scarce, engineers desperate to get their hands on one were invited to come into the lab and assemble their own. Ron Rider, who had joined PARC only a few months earlier upon graduating from Washington University, "had an Alto when Altos were impossible to get," recalled one of the lab managers. "When I asked him how he got one, he told me that he went around to the various laboratories, collected parts that people owed him, and put it together himself."

  Of course Thacker did not really design the Alto from scratch in three short months. His wager with Bill Vitek was something of a sucker bet. Several basic elements of Alto's design had been known to computer sci­ence for years, and others had been kicking around CSL ever since the completion of MAXC. During the summer of 1972 Thacker had even outlined for CSL the design points for a small machine in a ten-page memo entitled "A Personal Computer with Microparallel Processing."

  The philosophical core of the design came from Bob Taylor, who also supplied the machine's name (Alan Kay never entirely ceased calling it the "interim D
ynabook"). As Taylor constantly informed his top engi­neers, time-sharing's success in making computing more accessible to the user quantitatively was only part of the equation: Nothing had yet been accomplished in terms of improving "the quality of man-machine interaction." Finishing the job involved three steps: placing computing power in individual hands, delivering information directly to the eye­ball via a high-performance display, and linking the computers together on a high-speed network.

  As late as 1971, all three steps still seemed technically unfeasible. Com­puting power and memory were plainly too expensive to hand out in indi­vidual parcels, especially since they were consumed insatiably by the so-called "calligraphic" display tubes then in use with graphics-oriented computers. Moreover, because these displays laboriously constructed their images stroke by stroke, rather than by scanning a phosphor beam across a luminous surface thousands of times a second like television tubes, they were prone to annoying flicker. These were not qualities that would lend themselves to relaxed communication between man and machine. As for existing network technologies, they were either complex and slow or, like the ARPANET, required the installation of hundreds of thousands of dollars in specialized hardware.

  Then there was Taylor’s habit of speaking in parables when he could not articulate his ideas in the precise argot of engineering. "When we were building MAXC, Taylor told Chuck and me a bunch of stuff we couldn't understand at all at the time," Lampson recalled in amuse­ment. "We dismissed it as the ravings of a technically illiterate man­ager. But looking back on it two years later, it was crystal clear what he was trying to tell us to do: Build the Alto."

  What had changed by mid-1972 was their recognition of how quickly memory and computing power were sliding down the cost curve. "It was only when we realized that memory would get really cheap, when we understood Moore's Law and internalized it," recalled Thacker, "that it became clear that this is what Bob had been saying all along. All of a sudden it was perfectly sensible to build a computer that used two-thirds of its processor cycles and three- fourths of its memory to run the display. From then on it was all downhill. The engineering was easy. But getting that basic idea required understanding that eventually you'd have so much power in a machine that running the display wouldn't require anywhere near two-thirds of it."

  Thacker still had to solve numerous problems in designing a service­able personal computer that would be fast and compact without sacri­ficing versatility and power, and that would also have a display clear, sharp, and nimble enough to keep up with the processor without driv­ing the user blind. In the end he found the crucial answers inside PARC itself.

  His first inspiration was the concept of "microparallel processing." The basic idea came from a singular aspect of MAXC s operation—what Ed McCreight had described as "hijacking" the central processing unit. Thanks to a common bottleneck in computer architectures, the proces­sor, or brain, of a typical machine shared access to the computers main memory with all the machine's peripheral devices. Because only one device could be serviced at a time, the processor was often left idle while some other component temporarily monopolized the memory. "While the disk was accessing the memory, for instance," Thacker said, "the processor essentially stopped because it was waiting its turn."

  Thacker's inspiration was to shift the bottleneck from the memory to the processor itself. In his design, only the CPU, which after all was the most important component of the machine, would be permitted to address the main memory at any time. The CPU would take over the computing func­tions of all the peripherals—disk drive, keyboard, and display—deciding on its own when they needed servicing and for how long.

  Thacker reasoned that if each of the computer's routine tasks could somehow be ranked by urgency and funneled through the processor in appropriate order, he could keep the processor occupied almost full­time. If the ranking was correct, every task would be handled when it needed to be, no sooner and no later. Low-priority tasks could be interrupted for brief periods to make way for more urgent ones, then resumed later, when nothing more pressing was in the way. The gain in efficiency, speed, and hardware was potentially huge. Whole circuit boards that served as the ancillary brains of disk drives and other units could be dispensed with. The Alto's CPU would be drafted into doing the thinking for all of them.

  Thacker's second crucial inspiration involved the question of how to power a high-performance display without busting the budget on memory. This was not trivial: He understood that the quality of the dis­play would make or break his new computer.

  Up until then, computer designers wishing to provide an interactive display faced two equally unappetizing choices: They could give the display little memory support, which led to flickering and slow perfor­mance, or they could provide backup memory through a character generator, which meant burdening the system with another and bug- prone peripheral the size of a washing machine.

  Thacker struggled at length with the riddle of how to direct a suit­able volume of information to the screen without adding excess hard­ware. The answer came to him one day while he was watching a demonstration of one of Kay's graphics programs in the Systems Sci­ence Lab.

  The demo utilized a character generator designed by a former Engel­bart engineer named Roger Bates (with Lampson's assistance). This unit, which had thousands of dollars' worth of memory inside, was a distant relative of the one Ron Rider would later build for the SLOT. It was designed to store custom fonts by allowing each character to occupy a small rectangular patch of memory until summoned to the screen. Most of the PARC engineers considered it a disappointment, largely because the designers' ambition to reproduce book-quality pages on the POLOS screen turned out to be a tougher programming challenge than they anticipated.

  Kays group was an exception. Bored with the idea of painting text on the screen but fascinated with the possibility of displaying images, they had appropriated the system—"perverted it," in Lampson's unpejora- tive phrase—to use for their graphics and animation programs by load­ing its memory not with print characters, but graphical designs. The result was a rudimentary black-and-white "bitmap"—a block of mem­ory in which each bit corresponded to a dot on a display screen. Flip a given memory bit "on" and the corresponding dot lit up on the display; turn on these bits in a given pattern and you could map the same image to the screen.

  As Lampson explained, "In the normal deal there would be a little bitmap for the character 'A' in the font memory and a bitmap for 'B' and 'C' and so on, and then the character memory would say display an A,' an 'h,' and an 'a,' and aha, you have 'Aha.' Alan said, 'We'll have a whole bunch of artificial characters numbered 1 through 500, and the character memory will say display 1, then 2, then 3.' The result was to take the font memory and turn it into a bitmap"—that is, well before the lab had the resources to build a full-scale bitmap.

  Kay's group had only begun to investigate the potential of this new way of displaying information (although they had done enough to help persuade Thacker and Lampson of the need to equip the Alto with a high-resolution display). Among their first simple programs was one that could embed "icons," or thumbnail-sized pictures, within blocks of text. Another was a painting system in which users wielded square "brushes" up to four pixels wide to draw or erase lines and curves on the screen.

  Impressed as he was by these applications, Thacker was struck more by the underlying principle by which Kay's system used the memory blocks. He realized that just as Kay's team had turned the character generator into a simple bitmap, he could convert idle blocks of the Alto's main memory into a bitmap for the display screen. Forcing the memory to per­form this double duty would eliminate the need for a separate character generator. This required cutting a few corners, because the display would now have to compete with all of the machine's other functions for mem­ory blocks. When the Alto placed a text document on its screen, for exam­ple, it would economize by omitting from the bitmap any part of the page that lacked text, such as the white spaces
between lines and at all four margins. Also, whenever there were competing demands for memory from data and display, the display lost. Users had to be alerted to expect a strange phenomenon: During a work session the image of the docu­ment they were writing or editing would gradually shrink, like a window shade rolling up from the bottom. The reason was that as the increasing volume and complexity of the data claimed more memory, less remained for the bitmap. The same phenomenon accounted for what happened whenever the Alto displayed a full-screen graphical image. On those occasions it tended to run agonizingly slowly, in part because so many processor cycles were consumed in painting the screen, but also because the display consumed so much memory there was barely enough left to keep the program percolating along.

  Without this sort of artfulness the Alto display would not have been possible at all. Even within its limits it made severe demands on the machine; its resolution of 606 by 808 pixels meant that nearly a half- million bits needed to be refreshed thirty times per second. (Kay envisioned a one-million-pixel display for his Dynabook, but had to be satisfied with what he got.)

 

‹ Prev