The 9845 Story

How It All Began

Jack Walden
Jack Walden
In his memories, Jack Walden, one of the fathers of the HP 9845 remembers: "I am proud to say that I wrote the first (and so far as I know, the only) product-definition for it. In this definition, since it was to be 'a high-end machine', I 'let myself go'! I included ever feature on my wish-list that I could think of - and I had enough knowledge of the computer world that I could think of quite a bit!".

This was in the year 1976. And according to the Australian hpmuseum, "the 9845 was HP's number one revenue producing product in fiscal year 1980. In the previous two years since its introduction, the 9845 had also been one of the company's top five products."

Now, how did they get such successful with this high-priced product in a world which was dominated by big computers on the one side, and desktop calculators on the other, and an emerging scene of home and personal computers?

I guess the story began in the year 1968, when HP introduced its first programmable scientific calculator, the HP 9100A. At that time, electronic calculators were not much more but electronic versions of the previously wide spread mechanical calculators, with simple calculation capabilities on fixed point numbers.

HP 9100A

HP 9100A (Source: HPMuseum.org)

Tom Osborne
Tom Osborne
The HP 9100A really had been conceptional milestone, since it was the first that brought floating point numbers, programmability, mass storage and complex scientific tasks like trigonometric functions into one desktop system. The story of the 9100A is well documented by Steve Leibson on his hp9825.com website, please check this link for all the backgrounds. The interesting thing is that most of the design was done by one single genius Tom Osborne (he sold the original prototype design to HP), and the design was so optimized and sophisticated, that HP's own engineers hardly got into some deeper understanding how it worked. However, after the product had been developed at HP Labs, it moved for manufacturing to HP's Loveland Division in Colorado, and the product was a large success. The 9100A finally made up about one third of Loveland's business (the remaining share was dedicated to HP's traditional instruments).

Now with some closer look into the 9100A, it had much more of a computer than a calculator. At least with respect to the other electronic calculators of the time. The term "calculator" in fact was said to be chosen in order not to confuse HP's "real" computer division in Cupertino who already worked on HP's first 2116A minicomputer. But the design in fact was that of a computer with very long instruction word (VLIW) logic (based on state-of-the-art finite state machine), with ROM, RAM, I/O circuits and magnetic card reader for program storage. The display already was implemented by a CRT, however just for showing the three number calculation stack to the user. There wasn't a real progamming language, every function was bound to a key, and that key press simply was stored as a program step (much like programmable hand-held calculators after). But it was a self-contained, efficient and nearly complete design.

There was just one thing which did not fully match the needs within an instrument company like Hewlett-Packard: It was really a hack to use a 9100A for instrument control, since this never had been part of Tom Osborne's initial design draft. The facility which was later called "I/O port" in fact once had been intended more or less as a test connector for the 9100 itself.

HP 9100A

Inside HP 9100A

Anyway, every success demands the action for setting up follow-up products in order to make the success sustainable. The success of the 9100A was not unseen by the competitors, and new, competitive products got into the market from other manufacturers. So, as sales got more and more under pressure, Loveland decided to design a follow-up for the 9100A. This actually wasn't that easy, since the 9100A had been developed by HP Labs based on Tom Osborne's design and transferred as a finished product to the Loveland Division. R&D at Loveland had been quite new, and had only experience with instruments, but not with computers. And the original development team for the 9100A at HP Labs did not exist any more.

It happened that Wang Laboratories, one of the most important competitors on the calculator market, was quite successful with a calculator design which was just a scale-down of a larger computer system's architecture (that of an IBM/360, which was more or less making a virtue out of necessity, since Wang simply redirected a project which was originally intended to attack IBM into a calculator project - after the 9100A was presented to Wang in 1968). In fact, HP did steal a large share of Wang's calculator market share with the introduction of the 9100A before, so Wang more or less attempted to regain its former market position with their series 720 calculator. And the 720 was quite impressive. Although based on the same discrete technology made up of nixie tubes, diodes, transistors, hard-wired ROM and core memory with micro-controlled logic, the 720 became the more flexible machine.

Wang 7210

Wang 720 Computer (Source: Wang Museum)

It was quite natural that HP's engineers thought about a similar approach using an already existing general purpose computer architecture, since with the 2116A Hewlett-Packard already had its own minicomputer line into the market. So HP could match several positions at once: They actually did not have enough knowlegde of the 9100A architecture to design a good follow-up, so creating a design based on a multi-purpose architecture like that of the 2116 seemed somewhat appealing, and they expected to be able to re-use much of the 2116A ecosystem in terms of tooling. So they did a feasability study by Frank Wenninger and Ed Olander on whether it would be possible to scale down the 2116A architecture into a line of desktop systems, and then to use that new system to emulate a 9100A.

But there was still the problem that there was much hardware knowledge at the Loveland Division, but only few computer and software knowledge. A first step was to get more 'digital' experts into the team (Jack Walden was one of them) and next to found a new division, the Calculator Products Division (CPD) as a spin-off of Loveland Division, in order to focus on the new project.

Loveland Division

Loveland Division, Building C (Courtesy of HPMuseum)

Bob Watson, Engineering Manager of CPD, summarizes the activities, experiences and outcome of the project in the October 1972 issue of the HP Journal magazine. The market strategy behind the project was to setup a new architecture which could be used for low, mid and high end requirements utilizing basically the same hardware, i.e. making most of the difference in software. This approach had been somewhat revolutionary at a time, where the hardware defined most of the value, and software was just a (comparably cheap or even included) add-on.

But there also was a big change in technology from transistorized logic towards low and mid scale integrated circuits. Fortunately, as an engineering company ruling the key technologies, Hewlett-Packard was able to create what they needed on their own, so that CPD could utilize the latest in NMOS fabrication, including semiconductor logic and ROM. The original CRT display of the 9100A could be replaced by numeric and even alphanumeric LEDs produced by HP itself. CPD's engineers added a full I/O instruction set to the one which was borrowed from the series 2100 processors. The overall capabilities could be easily expanded by the customer himself by just ordering new ROM modules or peripherals from a large number of devices, which granted both a new way the extend the power of the own system at need, and to earn revenue on sales of those add-ons.

There were several problems which had to be solved. The original 16-bit wide architecture of the Series 2100 had to be serialized for cost reasons, so that the new logic actually processes one bit after the other. A decision had to be made whether to use binary representation for floating point numbers (as it was common practice in the computer world) or to use BCD coding instead (as it was already the case for the 9100A). The NMOS facturing process for integrated circuits had to be established, and Intel had to be supported to start producing their 1-kbit 1103 dynamic RAM fo the new line of calculators.

HP 9810A HP 9830A

HP 9810A and HP 9830A (Source: MoHPC)

Starting with the 9810A, quickly the 9820A and the 9830A were developed, so that the complete line could be presented in the October 1972 issue of the HP Journal. Wereas the 9810A was intended as a direct successor of the 9100A, with all of its capabilities, but for hald the price, the 9820A basically was designed as instrument controller, equipped with an alphanumeric LED display and larger firmware ROM supporting a high level language (later known as HPL), with a price tag comparable to that of the 9100A. The 9830A as top-of-the-line system actually was a somewhat strange machine. It featured a new high-level BASIC programming language, which had been designed at Dartmouth College a couple of years before and already had become quite popular at the time, more memory, a wider alphanumeric LED display and a full alphanumeric keyboard. The standard printer was a fast 80-character wide 9866A thermal printer. All versions featured an I/O bay with four I/O slots where a large number of interfaces including the brand-new HP-IB could be connected. And later a new 9880A mass storage system based on the combination of a fixed and a removable hard disk, providing up to 2.4 MByte of storage for the 9830A 'calculator' per platter.

Only four months before, HP had introduced the first scientific pocket calculator HP-35. This - together the the new line of 9800 calculators which now fitted perfectly into the ecosystem of an instrument company - simply kicked Wang Laboratories out of the calculator business. Wang gave up the calculator products and headed towards computer systems, and Hewlett-Packard did a large step from just an engineering company towards a leader in technology. And HP redefined the market for desktop systems.

The 9830 really had been a milestone in ease of use and software capability. As Lee White remembers, Dave Packard and Bill Hewlett were nevertheless dissatisfied with the speed of the 9830 in spite of its huge commercial success (engineers, you know...) which was primarily the result of the bit-serial processing. This is where Jack Walden's statement at the introduction of the page comes into play. Hewlett-Packard had learned its lesson, and - once finished with the 9800 series - immediately started with the design of the succesor line. Jack Walden himself already took a large part in the design and development of the 9820A and the 9830A, so he tried to find a definition for a system which should outperfom even the 9830A. Consequently, the first idea for a product number was 9840A, however finally the system was built around a completely new processor manufactured in LSI technology, that the new line of products should be named 9815A, 9825A and 9845A. For its full alphanumeric keyboard, the 9845A got the internal code name 'QWERT' with respect to the upper left key row which identifies a QWERTY typewriter-like keyboard.

HP 9845A

HP 9845A "QWERT"

At the same time when the development of the 98x5 series was started, another big project was launched at HP's Computer Division in Santa Clara, the AMIGO project. Whereas the 9845 at Loveland's Calculator Products Division was a follow-up on the 9830 desktop calculator, Santa Clara's AMIGO (also known as HP 300) came from the HP 3000 minicomputers, and had a totally different approach. Both systems were intended to become "super" personal computers, but the 9845 was primarily meant for scientists and engineers, whereas the AMIGO was positioned as a small business system. The 9845 re-used lots of the previous concepts of the 9830, but with much extended hardware and software capabilities, whereas the AMIGO was planned as a newly designed system with a completely new AMIGO/300 operating system. In fact, the 9845 team did not just turn the original bit-serial approach of the 9830 into a fully implemented 16-bit parallel architecture, but also used many components working in parallel, with two powerful 16-bit processors and lots of microcontrollers dedicated for several I/O tasks.

HP 300 AMIGO

HP 300 AMIGO Computer (Courtesy HPMuseum)

To understand the further development, we have to recall what the situation was at Hewlett-Packard in 1973. The 98x0 series showed fairly successful, as did the minicomputer business which was based on the 2100 series. But still HP was an instrument company. The 2116 originally had been developed for the orchestration of test and measurement instrument equipment, whereas the calculator line step by step also moved into the role of instrument controllers and desktop computers. On the other side, desktop computers were a strongly emerging technolgy, and HP had - from a technology point of view - a good standing in that technology, including its own facilities for producing integrated circuits based on its NMOS manufacturing process. In fact, HP had been extremely capable in designing and building hardware also from the instrument business, where product design included solid-state mechanical construction and perfection in the design of digital circuits (sometimes the difference between HP's computer products and those of other manufacturers gets instantly obvious when having a look inside those machines, they are extremely well designed, I personally love that).

Interior of an 9845A Computer

Interior of an HP 9845A Computer

HP's management understood that getting into the personal computer market would be a must, considering the strengths HP already had in technology and the upcoming potentials of the market. And HP still had the application scenarios where computer and instrument technolgy built a perfect symbiosis, so the use cases for HP's existing customer group were there. Even more, the risk for loosing instrument customers without being into the computer business was at hand. But HP's management obviously had been uncertain about the right approach. "Personal" had been just a matter of Lovelands Calculator Products Division, whereas "Computer" had been more the focus of Cupertino. So, as it is most when management can't find a decision, they decided to let the market decide. Both the CPD and the Computer Division were demanded to set up their own project for developing the next generation personal computer system. The projects did not only differ in technology and experience background, they also were assigned to different target groups. The AMIGO should become a small business system with multi-user capability, whereas the QWERT should create a single-user high end computer for scientists and engineers. So HP's management intentially created an intense competitions between both divisions.

The parallel development of both systems also reflects the competition of both of HP's divisions, with all differences in knowledge and culture. The AMIGO inherited new computer concepts like text windows, it supported multiple users, and it had user friendlyness as its highest goal (possibly with respect to the brand-new Xerox Star system, the commercial successor of the Alto from Xerox), whereas the QWERT was turning into a fast single-user desktop system with graphics capabilities for improved engineering productivity. Most of the HP's peripherals could be used with both computers, which was especially true for the HP-IB based peripherals. It was obvious that HP's strategy had recognized computers as the new business line next to the traditional instrument business. As Jack Walden tells in his memories, HP's upper management had a strong interest in both developments, and they performed project reviews almost every month. Which had not necessarily been always comfortable for the project teams. During the first months of the project, HP's upper management had been involved in any decision, since they didn't want to put any risk into HP's computer market stake.

Now although a tremendous effort was brought into the AMIGO project, the 9845A was being finished in schedule in mid 1977 (one year after the 9825A), whereas the AMIGO was introduced in mid 1979 with a noticeable delay. The 9845A got a big success. HP's Calculator Product Division (CPD), who were responsible for the full 98x5 line, moved from Loveland to the newly built Fort Collins Division and renamed to Desktop Computer Division (DCD), which rapidly produced successors like the 9845B and the 9845C, becoming even more successful. Fort Collins went on developing and producing the HP 9000 series 200, 300 and 500, participated in the PA-RISC development and in 1990 merged with Apollo Systems Division to HP's Workstation Sytems Division.

The AMIGO project, although heavily supported by marketing (two full HP Journals were dedicated just to the AMIGO computer), was no commercial success at all, only a few systems were produced, and the total revenue was about $15 million over its five year sales life. It is interesting that Fort Collins Division concurrently developed the HP 250, a system quite similar to the AMIGO system, but based on many of the concepts and some of the hardware components of the 9845. Just as the AMIGO, the HP 250 was designed as a small business system, and even that system was introduced before the AMIGO system was released. And just like the 98x5 series, it was a large success with double the lifetime and ten times the revenue compared to the AMIGO. In 1979, HP's management decided to move responsibility for the HP 250 from Fort Collins to the General Systems Division (which had just moved back from Santa Clara to Cupertino).

It had been a lucky coincidence that Don Morris, who had been assigned as project manager for the 9825A development could not start immediately with the product because his team of engineers were still involved in other projects. So he (together with Dick Barney, who worked as product manager for the 98x0 interfaces) did some market research on HP's 9820/9830 customer base. During the trip they learned much on how the systems had been used, and which features were missing, and why sales had been in some cases lost against competitors (such as Wang and DEC). This information was of high value for the product definition and the positioning of the new systems in the market. One of the results was that the new systems should address high end desktop computing on the one side, and instrument control on the other.

So when starting with the 98x5 development in 1973, three sections were set up within the R&D lab, each dealing with the development of different products. The first section aimed at a high-end desktop computational system (which was the 9845A), a second section on the mid- to low-end instrument controller systems (9825A and 9815A), and a third section to develop peripherals and interface cards for serving all of the 98x5 computers. The 9815A project got the codename CJ (for "Caesar Julius"), whereas the 9825A project was named Keeper (for "Key per Function", although the 9825A finally also was equipped with a typewriter-like QWERTY keyboard).

Bill Eads
Bill Eads
The software effort for the 9845A was divided into two groups with a core team of four members each plus group leader. One group was to implement the "language" features of the machine (with Bill Eads as group leader and John Bidwell, Dave Landers, Jeff Eastman, Jeff Osborne, Jack Cooley and John Schmidt as group members) and the other implemented the I/O structure of the machine (led by Jack Walden with Bob Jewett, Ken Huen, Frank Cada and Gene Burmeister as group members). The hardware design could refer to some common building blocks which were developed for the whole 98x5 series such as the newly developed hybrid processor, the 3M DC100 cartridge drives and a number of I/O interfaces.

Concerning the computer language used, everything was the same as it was before with the previous 9800 series. So the 9815 still used stored keys, the 9825 finally (happily) used HPL, and the 9845 again used a super-set of BASIC with many powerful extensions, such as long identifiers, code indentation and matrix operations, because BASIC still was "big" within both the calculator and the computer Divisions. Actually APL still was also quite polular at the time within the computational society, so many APL features (especially for supporting structured programming) found their way into the System 45 BASIC, which later evoluted towards Rocky Mountain BASIC.

One of the early discussions within the language group was how to implement the representation of the BASIC program in storage. The normal way to store a BASIC program was to first perform a syntax check and then store all the statements in tokenized form after the programmer had entered a complete line of code. When running a program, the tokens are driving an interpreter with jump table, which finally calls the appropriate native machine language routines. For other languages like FORTRAN, compilers were run over a file holding all of the program source, which then produced code which could be directly executed without any other system software except just a program loader (which did not much more but transferring the execution code into memory and then hand over execution to that code).

Now both the interpreter and the compiler approach have advantages and disadvantages. Whereas an interpreter can be run in interactive mode line by line and devlivers immediate results (especially in terms of syntax errors), a compiler perform code anaysis and produces execution code during a batch process. On the other side, every interpreter has a relative high overhead for analysis and code generation and execution every time a program is run, whereas fully compiled programs doing all the analysis and code generation once during the compilation process and are afterwards running at maximum speed. So interpreters are good for rapid, interactive prototyping, but in general much slower than compiled executables (often to an order of magnitude).

Finally the language team decided to use a mixture for best of both worlds. All BASIC commands were stored in a pre-compiled form in firmware, each with three dedicated routines: One for syntax check, one for recovering the ASCII source code within a program listing, and one for command execution. Rather than using tokens, pointers were used which had just to be linked in a daisy chain manner during run-time in order to create a program flow. So that solution was just one level of indirection away from compiled code. Programs could be stored in a highly compact form, and still provided fast processing. But that compromise also had its drawback: Since routine addresses and with them pointers could change over the firmware revisions, it was not possible any more to guarantee upward compatibility for programs stored in that compact form.

So the language team decided also to allow saving and loading programs as BASIC source files (with all BASIC code in ASCII format). For regaining upward compatibility, a program just had to be stored in that ASCII representation on one system, and loaded from another system, which then could use the compact form again for saving both load time and storage space. The nice thing is that this feature also could be used to merge new or altered code into a running program, which again opened the door for self-modifying code (a conceptional no-go and horror scenario for every serious system developer).

Summarizing the language part of the project, quite few could be re-used from the HP 9830. Altough maintaining compatibility to code and data, almost everything had to be created new, including the tools for assembling, debugging and testing. According to Bill Eads, much of the development was done with simulators, because hardware and software got developed in parallel, so that both were finished almost at the same time. There were profiler-like performance tools made by Bonnie Dykes, which let the language team do graphs of exactly where the LPU was spending its time running (interpreting) BASIC code. So the team was able to make some significant improvement using these tools.

Wang 2200 Computer

Wang 2200 Computer, Without CPU Cabinet From 1973 (Source: digibarn.com)

Since the time of the 9100A, CPD had been in close competition with Wang Laboratories, so it can be assumed that HP's engineers were aware of the Wang 2200 system, which had been launched exactly in 1973. The Wang 2200 featured a 9" CRT display with 16 lines of 64 characters each, integrated cassette mass storage, and a detached alphanumeric keyboard (with either typewrite-style QWERTY or BASIC keyword layout) with user-definable special function keys. However, the whole Wang 2200 system was a collection of several items which all had to get connected for a working system (CPU cage, PSU block, keyboard and user terminal with CRT and cassette drive). It did not yet feature a microprocessor (the whole CPU logic was built up by hundreds of TTL chips). Also, it lacked a graphics display (memory for bitmapped graphics still was extremely expensive).

The development of the new hybrid processor is a story on its own, and well documented on Steve Leibson's site on the 9825A. Now the hybrid processor used for the QWERT not exactly the same as the one which was used for the 9825A (the 9815A used Motorola's 6800). It was changed for extending the address space from 32K words to 64K words (the indirection bit was changed into an address MSB bit), and it was equipped with a new clock timing circuit, which was necessary for running two hybrid processors in sync. Because the QWERT had two processors, one for processing the BASIC language (called language processing unit or LPU) and another for I/O control (the peripheral processing unit or PPU). Both processors had access to the same portions of system memory, which then was used for communication between both processors with buffers and flags.

9845A Dual CPU Board (LPU and PPU)

9845A Dual NMOS-II CPU Board (LPU and PPU)

The overall functionality needed for the HP 9845 did overstrain the capabilities of the NMOS-II production process in terms of chip size. So each hybrid processor comprised separate chips on one common ceramic substrate, one for instruction fetch/decoding and basic logic (the binary processor chip or BPC), a chip for I/O and stack operations (the I/O chip or IOC) and a math chip for floating point calculations (the extended math chip or EMC) in combination with buffer chips and sime clock logic, Since the PPU didn't have to cope with floating point calculations, that chip (the EMC) was simply dropped for the PPU to save cost. For later 9845 models, another chip was added (the address extension chip or AEC) and LPU and PPU were identical, which again provided the option of full user programming in Assembler as alternative language on the PPU.

Both processors ran in parallel, so that I/O tasks could be processed independent of working the BASIC program. I/O tasks were scheduled with cooperative multitasking, i.e. once one task had sent some data, it could pass control to another task, which did another I/O, so that virtually a large number of concurrent I/O tasks could be processed. So it also was possible to enter and execute user commands during a program run, including altering the running program itself. The user program could decide on its own, whether it wanted to wait for the termination of an I/O task (synchronous processing or sequential mode), or whether it wanted to go on (asynchronous processing or OVERLAP mode) and - if desired - initiate another I/O task although the previous task was still processed. This is very much like the early MS Windows worked, and was totally innovative for desktop systems at the time.

Jack Walden tells that once he did a demo for a management review with five plotting devices connected to a 9845 and executed a program which invoked plotted output on ervery one of them. He started the demo in the non-overlapped mode, and the plotters did their job one after the other, just as they should - until he typed the OVERLAP command, and they all took off simultaneously. And there was Bill Hewlett watching, among other managers, and the reaction was a sight to behold!

The whole design was quite orthogonal, the designers were proud that every function could be used in a similar way in any context. But at one point they got struggled. The issue was that if a BASIC I/O commands was processed, it had to be handed over from the LPU to the PPU, which then would create a new buffer for the task. The language in principle allowed to use a user defined function as parameter to that I/O command. Now it could happen that within this user defined function another I/O statement could be invoked, which, of course, could be nested, which could put the system into a deadlock state. The simple solution just to prohibit the use of user defined functions within the argument list of an I/O statement was heavily discussed, because that would create a restriction in the orthogonal design. However no other solution was found, so after a long fight (the discussion stopped the whole project for better than two weeks) finally that kind of use was dis-allowed. And the deadlock situation never occured.

The alpha display of the HP 9845 was something special. It featured a large buffer "stolen" from the main memory with some kind of display list control. So character information could be randomly mixed with commands which controlled the display flow. A "jump" command could guide the display processor to continue at another memory address, and an explicit end-of-line command could indicate that no more characters are present and the display processor can continue immediately with the next line. As a result there was a highly efficient use of the display buffer, and the amount of "stolen" memory cycles could be held at a minimum. By sophisticated use of the display commands, it was easy to implement arbitrary windows scrolling over a much larger character buffer or to utilize double buffering with display of one buffer while writing to another. HP spent a lot of effort on accurate CRT geometry. Every single CRT had been manually fine tuned to achieve perfect results.

The QWERT's graphics of option probably was unique at the time with respect to resolution, accuracy, ergonomy and software capability. An optional ROM module held lots of functions for almost any type of graphcis operation including real-world to machine coordinate transformations, functions for creating coordinate systems and an character generator for labelling. Even 3D graphics calculations could easily be achieved with support of the rich set of built-in matrix operations. Block data transfers between the 16 kByte graphics memory and system memory could be done with DMA support without processor intervention with up to 200 kWords/s.

The only drawback was that for the 9845A all of the line drawing and fill operations had to be performed by the PPU. Since the graphics subsystem was integrated just as any other internal peripheral via the I/O bus, and no more than just one single pixel could be drawn or erased with each I/O bus command, the drawing speed was limited to roughly 8 inches per second, which is about 5,600 pixels per second in average. Later with the 9845B Model 200 and 9845C, HP used hardware accelerated vector generation, which boosted line drawing by up to a factor of 100.

According to Brent DeWitt, the CRT graphics solution as it worked out was not the only choice: "Because RAM was so expensive for the graphics display, we looked for lots of other ways to build big graphics. One of our investigations was into the use of a smectic mode liquid crystal on the dimensions of a microfiche cell with cheap microfiche projector optics to make it viewable. The cell would have been written with an IR diode and would have behaved much like the large and bulky storage CRTs of the day, but without the "large and bulky" bit and with one bit per color. It wasn't "write once", it was just "write slow". When the IR beam was focused on a point, the smectic mode liquid crystals were "melted" and could be changed, by a bulk electric field impressed across the whole display, from clear to black or visa versa. The problem was that you couldn't really erase the whole screen like a storage CRT as Tektronix did. You needed to address each write location to within about a tenth of a dot diameter to create the state change. Since we were trying to do 1000 pixels across a microfiche cell something bigger than 1 cm, the positioning was incredibly tight. I had a rough idea how to do it, but we dropped the project before determining if it would have worked. The bottom line is that the redraw would have been painfully slow and RAM memory was just starting to get down to where the color CRT was looking viable. So we never made it work because the erase/redraw was nearly impossible".

Anyway, it is roumored that George Lucas did use a 9845 system for scene preparation when producing the Star Wars movie. Now, what is certainly true is that Colin J. Cantwell, one of the model designers at Lucas Films, who created prototypes for most of the well-known space vessels such as the TIE fighter, the Y-Wing fighter or the Star Destroyer, had some relation to Hewlett-Packard. Colin Cantwell took a major role in the graphic production of "Buck Rogers in the 25th Century" and used to work together with Douglas Trumbull on "2001 - A Space Odyssey" in 1968 and also on "Andromeda Strain" in 1971. The latter movie already featured an HP 9100B with 9125A plotter as "movie stars" in its opening scene. Later Colin did work as a part time consultant for HP on the development of the 9845C, and contributed much to its concepts, probably including its code name "Odyssey". Finally, Colin managed to work as a computer graphics design consultant on the "Wargames" movie, where 9845C systems were used for the production of the (at the time) impressive large scale animated projections at NORAD.

Colin Cantwell

Colin Cantwell With George Lucuas During the Production of Star Wars Episode IV "A New Hope"

Since the 9845A was introduced in 1977, it is unlikely that it was already used for the first Star Wars movie (now "Episode IV - A New Hope"), which entered the cinemas already in May 1977. But it might match with the following sequel ("Episode V - The Empire Strikes Back"). Jack Walden remembers "An important user of the graphics was Lucas Film, the creators of Star Wars. George Lucas was very impressed with the 9845 graphics capability, and it's interactiveness, and used a 9845 at Lucas Film to plan many of the scenes shown in Star Wars".

HP had a strong ambition in creating a state-of-the art keyboard for any type of user, whether occasional writer or experienced professional. The benchmark at the time was the IBM Selectric typewriter, so the HP 9845 not only adapted the layout, but also tried to reproduce the "feeling" of the selectric. It was the Licon division of Illinois Tool Works (ITW) that created the devices, and they were a pretty clever idea, since they worked contactlessly. When the keys are not depressed, the small magnetic core is held in saturation by the permanent magnets of the moving plunger. When the key is depressed, the magnets move away and a signal can be coupled from the drive loop to the output loop in the key. A version of the key that had a small sliding plastic bit to simulate the "break-over" feel of the IBM Selectric typewriter came up as a choice, but it would have reduced the reliability by almost a factor of ten, so it was dropped back to the linear spring. It fact the key construction is so reliable that I have never encountered any key failure on any 9845 until today.

Now this for now is an overview of some parts of the whole story, more to come, stay tuned.

Memory Gems

In the following section, I would like to give place for memories contributed by those who have participated in the story of the HP 9845. The beginning is done by Lee White, who used to work for HP as physicist and mechanical engineer during the early days of the series 9800. Many thanks to Lee for giving us some insight in the mechanical design challenges of cooling design in general and the design of the printer subsystem in particular.

Lee A. White

I am a physicist and a mechanical engineer and I originally worked at HP as a production engineer overseeing the manufacturing lines for the 9810, 9820, 9821, 9830, and the 9866 products. I was also involved in improving soldering, IC insertion, and PCB manufacturing processes at HP Loveland, and did some important research particularly with respect to reducing bad solder joints in wave soldered boards and on reducing the very high failure rates of multilayer memory board inner layer interconnects.

I was then assigned to the design engineering laboratory working for Ray Cozzens. This was at the beginning of the 9845 project - a project code named "QWERT". Ray reported to Gary Egan and was responsible for all mechanical design engineers working on the project. Because I had considerable prior experience with the 9866 thermal printer and with the 9830 calculator series mechanical design issues, I was given responsibility for overall mechanical design of the 9845 printer itself and for all its mechanical parts including the paper feeding and tracking system and the drive motor and cog belt drive system, as well as for the integration of the printer and the CRT display into the calculator itself. Design of the thermal print head itself was another engineer's responsibility as was the design of the printer step motor drive electronics and I played no significant part in those aspects of the printer design.

Building the printer and the CRT into one desk top unit presented many difficult design problems particularly with regard to overall thermal management and component cooling, for access to the printer for paper loading, and for reducing total noise and vibration to very quiet office appropriate levels. It was my responsibility to find a way to put it all together, to provide for easy paper loading and proper paper tracking, for testing thermal paper and for evaluating and approving paper suppliers, and for finding a method to keep it all cool enough that the wax coated thermal paper would not stick together or change colors. Reducing internal temperatures was also critical to reducing the over all failure rate of the calculator electronics insuring warranty expenses would be acceptably low and customer satisfaction high. Attaining these goals required production of reliability/failure rate estimates and calculation of the expected warranty costs for the entire calculator, as well as for estimating probable board exchange program costs so marketing could establish appropriate board exchange program pricing. I also had responsibility for shock and vibration and environmental test performance for the entire calculator.

Producing straight vertical lines when printing (and especially when doing graphical plotting) was much much more of a problem for this first ever high density graphical printer/plotter than it had been for any prior character printer. We were printing far more dots per inch than previous printers and the printing was done by heating and melting a wax coating on the thermal print paper. When the wax coating on the paper was melted by the thermal print head chemicals mixed into the wax combined and chemically reacted and changed colors to produce a colored dot. When power to the print head heater element was turned off the wax cooled and solidified again, and when it did so it stuck the paper to the print head. Printing more dots per inch meant more paper stick making it much harder to unstick the paper from the print head when advancing the paper to print the next dot row. When the majority of the printed dots were located off to one side of the paper, the paper wanted to turn toward the heavier dot density side. When that happened the lines bent and the plot twisted; so tracking was a big problem. The solution developed and in long term performance test when I left the project was to incororate a wide radius convex surface placed across the print paper guide channel. Production pilot parts had this feature. Tests indicated that using a higher responsivity paper that produced denser colors with less melting allowed a reduction in thermal input and wax melting/sticking yielding better tacking. That paper was sourced from Nashua Paper and was available from them in several colors. As best i recall, colors included red, green, blue, and black. All the available colors were approved for use in the printer but I am not certain which were ultimately offered for sale by HP marketing. I personally preferred the Blue.

Cooling the high power density switching power supply was a particularly difficult challenge, there were lots of very hot dynamic ram chips inside the calculator itself, and the printer was buried down among all of those heat sources. In the earliest designs the top of the printer was capped by the CRT which blocked any cooling air flow over that surface. As previously explained, the printer paper was a wax coated thermally sensitive type and it would turn dark if it got hot - so effective thermal management was a big challenge for this integrated printer/calculator/CRT design. Extensive work was done measuring air flow rates and component temperatures and testing various solutions to the problem of reducing temperatures. The result was the dual fan dual path cooling system and all aspects of this thermal management system were my original ideas and my designs. Early examples of this design were very noisy. One of the project desgn engineers was something of an artist and there is even a cartoon that was done at the time spoofing me and the dual cooling fans. Air flow rate testing was initially done with hot wire anemometers, pitot static tubes, then propeller flow rate meters, and finally with a 50 ft. long very light weight big flexible plastic film tube made out of dry cleaner bags taped together - and that last method worked the best.

It was comical but simply capturing the outflow air over a predetermined time interval worked very well. Internal component temperatures were initially measured with thermocouples and later with an IR camera. Dual fans allowed separate cooling flow paths for the calculator and for the power supply providing both with cool fresh intake air and isolating the very hot power supply area outflow air from entering the cooler calculator processor and memory areas. Dual fans also allowed use of lower velocity and thus very much quieter fans reducing noise output to more acceptable levels while providing increased total air flow rate for over all cooler operation. Calculator failure rates were reduced several fold as a direct result of this cooling system design. Audible noise studies were conducted in the sound proof room of the HP recording studio at Loveland. Noise sources were identified and noise reduction strategies evaluated using directional microphones and an HP low frequency spectrum analyzer. The final product design met the low initial design goal noise levels.

The original overall case design concept had the CRT located directly on top of the printer severely limitting access for paper loading. In this design the paper roll was loaded from the rear and the printed paper exited forward over the keyboard where it then interfered with typing. The next design raised the CRT on rigid legs mounted high enough that the paper could be loaded into the printer conveniently, but that resulted in too high of a viewing angle and an operator head angle that was too high for comfort. It also resulted in too much glare from light reflecting off the screen, and the industrial designer thought it just did not look right. Obviously, none of these designs were satisfactory. It was my original design idea to incorporate a tilting mechanism that would allow the CRT to be tilted up in front raising the front edge enough to enable convenient paper loading. Tilting the CRT back down after paper loading would lower the CRT slightly for better viewing. The opening between the CRT support legs would be wide enough to load a roll of paper directly into the paper bucket. This tilt latch idea combined with a self loading paper system solved all the mechanical design problems surrounding the printer and CT integration into the calculator case itself. You just tilt the CRT, open the paper door, toss the roll of paper into the bucket, push the feed button, and the paper self loads. There is no need to thread the leading edge of the paper through the paper channel as it loads itself. This approach did make feeding the signals up to the CRT very much more difficult, but another engineer who was responsible for designing all the case parts solved those problems and designed the actual tilt latch mechanism into the CRT case parts. Still, the original tilting CRT design concept was mine.

I left HP for other opportunities in June of 1977, just shortly before the product was released to production. The design was firm, most all of the tooling was done, hard tooled parts were available, we had completed a production pilot run, and the product was in the process of being moved to manufacturing when I left. The engineers I worked with at HP were the best group of engineers I ever worked with at any time in my career. I am very glad to have had the opportunity to be there working at HP Loveland at that particular time, to have met and spoken with Bill and Dave and Barney, to have worked with those engineers, and to made a contribution to those leading edge procucts.

Lee A. White