Loading
Everything HP200LX: Knowledge, Products, Service

 Archives
9 years, 100's of pages of HP Palmtop Paper, jammed with tips, reviews and how-to's

Links
Most useful, up-to-date Web sites devoted to the HP 200LX

Downloads
Direct link into 1000's of pieces of Palmtop software

Tips from Our Techs

2008 Catalog
(PDF, 2.6 MB)

Contact Us/About Us

 
Weekly Palmtop Paper Newsletter
(Palmtop tips, latest happenings, and HP Palmtop Paper Store information)


 

 

Privacy Policy

The Evolution of the HP Palmtops

The Evolution of the HP Palmtops

An HP engineer on both design teams describes the development of the HP 95LX and HP 100LX.

By Everett Kaser, Hewlett-Packard Company

[Editor's note: Because of HP internal policy, only the first names of the individuals involved in the development of the HP Palmtops have been mentioned in this article. This article is accessible to any level of reader, but does use some technical terms. We have included a glossary at the end of the article. ]

The following is one person's view of the development of the HP 95LX and HP 100LX Palmtop PCs. There were MANY people involved in the development of these products, and some of the following is based upon what I've been told by others, while much of it is from my own experience and point of view.

I have worked for HP since 1976, and have seen the coming and going of dozens of calculators, the HP-01 calculator watch, the HP-85 and HP-87 computers, the HP 110 PORTABLE and The Portable PLUS computers, the Portable Vectra, and the BASIC Language Processor Card (Rocky Mountain BASIC on a card for PC's). I've worked in Manufacturing, R&D, Marketing (Support), and back to R&D.

Developing the HP 95LX

In the spring of 1990 I became involved on a temporary basis with the new "Jaguar" project. I was given the task of writing the selftest code for the new machine. Jaguar was of course to become the HP 95LX.

Memories are starting to fade and notes are starting to rot, but here's roughly how Jaguar came to be.

Cheetah Comes First

HP Corvallis Lab and Marketing decided that an "information manager" would be a nice product to develop. This product was to be implemented (as was all other Corvallis products in recent years) on the Saturn CPU architecture. Talk, thinking, and research began in earnest in late 1988. By January 1989, there was a preliminary product idea called "Cheetah" that was to be in a package very similar to the HP-19B calculator, with application keys for Time, Schedule, Lists (ToDo, Address, Business), Reports (Expense, Forms), Calculator (Business, Scientific), and Phone. An early email memo described Cheetah as follows:

"Accommodate 32K of RAM, with support for 64K and 128K. Provide all functionality of 19B, plus set of information management features. Provide I/O between Cheetahs and between Cheetah and PC."

The display/keyboard hardware was basically the same as the HP 19B.

Cheetah Evolves into a "Jaguar"

By the end of February 1989, the project name was changed to Ocelot. The basic concept was the same, but by this time many of the features were becoming well defined "on paper." Up to this point, the "clamshell" opened side-to-side (i.e. the unit looked much like the HP-19B calculator). This was changed to the current form (opening up and away) in the first half of 1989. The display was moved into the top half of the clamshell (along with a couple of rows of function keys), and the project was renamed to "Jaguar."

Although the features of the Jaguar were becoming better defined, they had not been finalized at this point. Susan, one of the developers, still has a document she wrote at the time describing the functionality to be included in the Time Manager (Appointment Book). Many of the features never made it into the HP 95LX, but were eventually included in the HP 100LX Appointment Book (written by Susan and Jean).

Still Not Quite Right

In August of 1989, an attempt was made to get management's permission to start actual development on Jaguar. However, there was still a feeling that it just wasn't quite "right," that the product didn't have enough "punch." Talk began that maybe what the product needed was a spreadsheet program, but no one was sure whether we should write one or "buy" one from another developer. At this time we also discussed the possibility of using an industry standard processor instead of the Saturn CPU because it would make it easier to incorporate a spreadsheet program into the package.

HP / Lotus Partnership

In late September of 1989, Lotus management called up and said they were interested in working with a hardware vendor to build what they called a "portable 1-2-3 machine" with PIM (Personal Information Management) software. HP described what they were working towards. The two visions were remarkably similar.

HP and Lotus decided to work together on the project. The hardware architecture changed from HP Saturn calculator to Intel/PC to make it easier to work together. HP would focus on the hardware and the Calculator software while Lotus focused on the PIM, communications, and 1-2-3 software.

At this point, the vision was that Jaguar's hardware would be similar to other PC-compatibles, but that it would NOT be an MS-DOS machine. Lotus would write enough low-level code to support the built-in applications, but nothing more. Eventually it was decided that some kind of DOS compatibility was desirable. After looking at another MS-DOS compatible operating system, HP finally decided to use a ROM executable version of Microsoft DOS 3.2.

The Corvallis Division had originally developed the HP 110 and the Portable Plus computers, so they had some history with DOS machines. Unfortunately, most of the engineers involved in those projects had since moved on to other jobs in other divisions. As a result, the HP Corvallis Division R&D lacked experience in developing software for PC's under MS-DOS. However, it DID have a great deal of experience developing small, rugged calculators. Lotus, on the other hand, had a great deal of experience with PC's and MSDOS. This led to a natural split in development work.

Over the course of the development of the HP 95LX, HP Corvallis gained a lot of experience with PC's and MS-DOS. This allowed HP to play a larger role in the development of the HP 100LX applications.

Aggressive Development for Jaguar

In December of 1989, Jaguar II (thereafter known simply as Jaguar, although the hardware was totally different from the original Jaguar) went into the development stage. The projected release of the product to manufacturing was January 1991 -- only 13 months later. This was a VERY aggressive schedule for a product of Jaguar's complexity.

Jaguar was actually released to manufacturing in March 1991. The original goal in December 1989 was for a palmtop with 512K ROM and 128K RAM, costing $595. Those specifications changed by the summer of 1990 to 1MB ROM and 512K RAM, costing $699.

Becomes More than a "Portable 1-2-3" Computer

Initially, the Lotus position was that the HP 95LX was to be a "portable 1-2-3" machine with organizer PIM software. At some point, HP decided they wanted to be able to access the MS-DOS prompt and run other MS-DOS programs. Lotus added the ability to shell to DOS from FILER, providing all other applications are closed. The requirement for all applications to be closed was because of the way memory was managed and the fear that "undisciplined" DOS programs might trash the data spaces of the built-in applications. This decision to provide access to MS-DOS was critical to the future development, marketing, and positioning of the HP Palmtop product line.

Breadboard Prototypes

I joined the project in March of 1990, just as the first "breadboard" was being put together. (A breadboard is a cage with five or six wire-wrapped boards, each about 6 inches wide and 8 inches long, crammed with ICs. It's used to develop and test the hardware and software before having actual integrated circuit chips made.) Jaguar contains an ASIC chip called the "Hopper" that has EVERYTHING in it except for the CPU, RAM, ROM, and miscellaneous discrete components (resistors, capacitors, serial/IR transceivers). It includes the display controller, keyboard control, UART, interrupt controller, interval timer, real time clock, A/D converter, tone generator, memory management, mapping, card port support, and more.

The hardware team wanted to test their designs before committing themselves to silicon (i.e. having Intel actually manufacture a test run). Also, the software engineers needed some "real" hardware to start using for code development, particularly for the BIOS, DOS, and selftest code. The breadboards contained all of the "guts" of a Jaguar, built from individual logic chips, with a keyboard/display mock-up connected to it via a ribbon cable. An HP 64000 (in-circuit emulator for the CPU) could be plugged in instead of the NEC V20 CPU, and the ROM image was downloaded from a local UNIX system. Keeping the breadboards functional for the software engineers kept the hardware team extremely busy. "Temperamental" only begins to describe a breadboard.

After the first prototype Hopper parts became available, "handsets" were built (complete Jaguars except that they contained no ROM). In place of the ROM was a PC board that plugged into the card slot. This PC card contained an EPROM and three 512K RAM chips. This arrangement let us test the software as we refined it. The EPROM contained bootstrap code that allowed us to download software through the serial port into two of the RAM chips.

UNIX / PC Culture Shock

The software engineers developing the HP CALC application did most of their work on a PC. They used TKERNEL (a TSR software program) to simulate the System Manager environment on the PC. This allowed them to use "standard" development tools (like Codeview) on the PC. Considering that most of them had been developing HP CALC code on UNIX systems to run on Saturn CPUs, they experienced a bit of a "culture shock." Instead of writing RPL code on a UNIX system for running on a Saturn CPU, they were now writing C code on a PC to run on a PC, on top of System Manager, on top of MS-DOS.

Four Guys in a Motel Room in Phoenix, Arizona

When the first test batch of Hopper IC's became available from Intel, four HP hardware engineers (Howard, Dan, Randy, and Kevin) flew down to the Phoenix, Arizona area to pick them up and test them. At that time, Intel was not equipped to support outside engineers in their lab. As a result, the HP engineers took a "foldapart" with them, along with power supplies, volt meters, oscilloscopes, etc. They checked into a hotel room around 7 p.m., the parts were delivered by an Intel employee about 10 p.m., and work started.

The "fold apart" is a large (about two square feet) PC board with all of the electrical components of a Jaguar laid out for easy access by probes. Intel supplied an IC socket with the sample Hopper chips, but the socket didn't fit the IC's. This required a little artistic carving on the plastic socket with the soldering iron.

They got the IC socket to work, but discovered a few problems with the Hopper chip. For one thing, the oscillator (clock) on the Hopper chip didn't work. Without that, nothing else was going to work. It was 11 p.m. and all the local Radio Shacks were closed, so they tore apart Howard's HP-17 calculator and used the crystal from it to supply an external oscillator for the Hopper.

Disassembled HP 95LX:  Graphic

 Eventually, they got everything working well enough to get the system booted. The chip had to be modified once to get it functional for production, but the original Hopper chip could be made to work well enough for development to continue.

Development a Team Effort

After working on the selftest code for a while, I was also given the task of writing the disk driver software (for accessing drive A: and the drive C: ROM/RAM disk). In between those, I adapted the low-level graphics code which was based upon graphics routines that I had written at home for my shareware games. Eventually, I ported TigerFox (which I had originally written years ago for the HP 110 Portable) and wrote Hearts & Bones. Towards the end of the project, I wrote the global password code. That comprised the bulk of my contribution to the HP 95LX.

The calculator application was developed primarily by five engineers (Pat, Bill, Stan, Jean, and Bruce). Stan implemented the BCD math library, translating routines that had been developed and refined over the years for the calculators, and optimizing some of them to run more quickly on the Intel CPU. Jean worked primarily on the Solver memory management, parsing for the Solver, the algebraic solver, and was primarily responsible for the $1000 bill (see sidebar). Bill did most of the general display routines and solver user interface. Bruce did the numeric solver, the "core calculator", the calc line, the stack, etc, and helped optimize the graphing routines. Pat did the "glue" that held everything together (key handling, switching between various calculator functionality, etc), the equation graphing, most of the remaining calculator sub-functions (TVM, List, Conversions, etc), and was in charge of doing the "builds" each week (where everyone's code was merged together into a [hopefully] working whole). Another engineer had been working on some other aspects of the project when he took a position in Marketing in June 1990. That opened a permanent position on the Jaguar team which was eventually filled by me.

The BIOS was adapted by Jim, and Lynn took care of DOS, memory mapping, and ROM building. Eric tried to ride herd over us and mostly survived the experience!

There were a lot of other people that worked on the HP 95LX. There were hardware and software, HP and Lotus, lab and marketing and manufacturing, procurement and shipping, support, all kinds of folks.

I enjoyed working on Jaguar more than any other project since the HP-85. (The HP-85 was the first "low-cost" computer offered by HP. It included a built-in display, printer, tape drive, keyboard, four I/O slots, had BASIC built in to ROM, and was introduced in Jan 1980 for around $3,250.) The 95LX was a revolutionary product developed by a great team. At introduction, it was on magazine covers, TV, and even the NBC Nightly News. Projects like that come along VERY rarely.

Developing the HP 100LX "Cougar"

Before the HP software team had even finished Jag (released the ROM code to manufacturing), the hardware engineers were already busy investigating Cougar (as the HP 100LX was known during its development phase). The primary changes that the hardware group wanted to make were to improve PC compatibility (which, in addition to the desires of the software team and the managers, is what drove the adoption of CGA for the display), lengthen battery life (which was mostly achieved through the use of 3 volts internally instead of the 5 volts used by the 95LX), make the card port a PCMCIA rev 2.0 compatible port, increase the IR port baud rate, and improve the speed of the Palmtop.

Improving Display a Priority

One of the things the software team wanted to do was to mix font sizes on the display and use a more "graphical" user interface. This implied writing applications in graphics display mode. In order to do this and get a reasonably quick display response when writing an entire display full of text, the software needed an assist from the hardware. This brought about the inclusion of a "bit-blitter" in the Hornet chip (the ASIC chip which contains basically all of the Cougar electronics). The Bit-Blitter is used for copying character bits from the font table directly into the graphics bitmapped memory with proper shifting and masking.

No one was certain whether a CGA display would be readable at the size needed to fit into the HP Palmtop case. Samples were acquired from several different LCD vendors, test software was written to display screens of different sized text, and opinions were gathered from all. The combination of this testing, the desire for a full CGA display, and for backwards compatibility with software written for the HP 95LX convinced us that we needed three fonts built into the machine: 80x25 for CGA display, 64x18 for optimal display, and 40x16 for Jaguar compatibility. The 64x18 display was considered optimal since it was quite readable and allowed 80% more display than the 40x16 display.

Work Begins in Ernest

Once work was finished on Jag and its Connectivity Pack, the software team dove into the Cougar project, developing ideas for the user interface and the new PIM applications. The engineers and managers at HP wanted to develop more of the PIM applications here in Corvallis, including the Appointment Book, Phone Book, and Memo. Roughly six months was spent by the software team at HP investigating proposals for the appearance of the user interface and applications that we intended to implement. A user test was done in early Summer to see how people "received" and used the proposed interface. All of this culminated with some "fast prototyping" of code in December 1991 and January 1992.

A prototype user interface was implemented (called CAP, Cougar Applications Platform), and the Appointment Book, Phone Book, and Memo were "sketched out" on PCs with software that emulated the 100LX environment. This gave us (and our managers) an opportunity to see what the applications would look like on a real display, with real dialogs and soft keys, etc. Many things WEREN'T implemented in this fast prototype stage, but enough was to get a feel for the applications.

Lotus also was enthusiastic about using a graphical user-interface. Their User Interface design group suggested some enhancements, such as including push buttons within dialog boxes. However, management at Lotus felt that the user interface code properly belonged in the System Manager since it was a "platform resource". The decision was reached to have Lotus take responsibility for this code, and so Lotus engineers began implementing their version of the user interface called LHAPI (Lotus Handheld Applications Programming Interface) in the spring of 1992. Meanwhile, HP engineers continued to begin implementation of the HP applications using CAP, since schedules were pressing (as usual). When LHAPI became available, the HP applications then had to go through a conversion process, much of which was handled by a header file with LOTS of #define statements to translate CAP style programming into the very similar LHAPI style. Independent Software Vendor developers will still see occasional references to CAP in documents and some header files and sample programs.

Cougar Handles Larger Data Files; Database Program Heart of PIMs

One of the large complaints about the software in the HP 95LX had been the inability to deal with files larger than about 40K to 50K bytes (depending upon the application). This happened on the HP 95LX because the applications were designed to read the entire file into System memory in order to operate upon it, and because the "small memory model" was chosen for the programs which limits the total data space for the program to 64K. This turned out to be a significant limitation, so there was a need to implement the Cougar PIM applications in such a way as to be able to deal with larger than 64K byte blocks of data. In order to be able to use more than one or two applications at a time, it was decided that the Cougar's applications would not read the entire contents of their data files into memory at once.

At the same time, it was recognized that a database program would be a great addition to the machine, as MANY people were using the Phone Book on the HP 95LX as a database program, and many people have collections of data that they'd like to carry about with them.

Since we needed to create a database program that dealt with partial files, we thought it made sense to base most of the PIM applications on the basic database engine. The basic database engine was written by Andy, the newest addition to our software team.

Some applications were varied from Data Base more than others. The Appointment Book, although sharing much commonality with the Phone Book, Database, World Time, and NoteTaker, has so many unique requirements that it is a totally separate application, whereas the other four are actually the same program, simply invoked in four different ways causing slightly different behavior. All are based upon the "index view/card view" paradigm.

Much more could be said about the development of the Palmtops, but as another HP engineer is often quoted as saying, "Life is short, and the ROM is full." So now for answers to some of the questions posed by the folks at The HP Palmtop Paper:

Questions and Answers

How do you decide what hardware and software features go into HP Palmtops?

It's a cooperative effort between all of the folks involved in the project, R&D and Marketing, engineers and managers, etc. Ideas are collected from many sources including suggestions from customers via Tech Support, CompuServe, internet, letters, Email, market research, etc. Some issues are simple: everyone is in agreement that a particular item should or should not be in the product. Others require a great deal of discussion and persuasion, and sometimes boil down to requiring a decision to be made by some level of management which is then the "final word." That actually happens surprisingly infrequently. An initial design is created before development begins. Some features get added during the development phase, some get deleted. Sometimes features are deleted because they don't work out, sometimes because there's insufficient time in the schedule to implement them. Some features are added because everyone agrees they're important; others are added because an engineer simply added the feature and everyone then agreed it was worth keeping (this applies mostly to software).

What application do you find most useful? Why?

DEBUG. I use the 100LX all the time for work, doing development, support, etc. For that work, Debug is invaluable to me because it lets me operate at a very low level in the Palmtop, doing things that are otherwise impossible to do.

How do other developers use their Palmtops?

Most of the other developers use their Palmtops daily, keeping appointments, to-do's, phone books, etc. A couple use the Database application to keep a database of songs (for their guitar playing), one keeps track of a check register, and another uses it for recording miscellaneous notes and thoughts.

Why isn't there support for .EXMs (task swapping) in the HP 100LX Connectivity Pack?

Due to the size of the "SysMgr" in the HP 100LX CPACK (TKERNEL .EXE), memory is too tight to allow reasonable task swapping. Remember that the SysMgr on the HP 100LX added the database engine, GLED (global editor), LHAPI, and additional System Manager functions. All of these features are necessary in order to run the HP 100LX applications. This takes memory. It was felt that it was better not to offer a feature at all than to offer it and not have it work.

What caused the development of the small keyboard? Was this ever thought to be a drawback? If so, why wasn't a larger one designed, given the limitations of overall size of the computer?

The "small keyboard" was caused by two design constraints: the desired size of the product and the desired functionality. The product HAD to fit in a reasonable size pocket, or be very easy to carry. That set the upper limit on the package size. Additionally, the keyboard had to contain almost all of the functionality of a PC keyboard, in order to properly use 1-2-3 and the other built-in PIM applications.

Many people have asked, "Why not get rid of the numeric keypad and make the other keys bigger?" That wasn't (and isn't) an option, for a number of reasons. First, the Palmtops were designed to have numeric processing (HP Calculator and Lotus 1-2-3) as one of their main features. A numeric keypad is critical to the usability of those applications. An "embedded" numeric keypad just doesn't cut it. Second, if you DID embed the keypad (in the alpha keyboard), you STILL have to find locations for the shifted characters that are currently on the keypad (punctuation marks, mostly).

Well, get rid of the "blue application" keys, some say. You end up chasing your tail around in circles and eventually end up back where you started: with a keyboard VERY similar to what we chose. Believe me, Keyboard Wars were waged long, hot, and heavy around here. The keyboard was NOT designed lightly or without a GREAT deal of thought.

Why does the HP 100LX run slower than the 95LX?

Among other things, we (the software developers) wanted to allow larger Appointment Books and Phone Books and Memos on the Cougar. We also wanted to include database capability. To allow larger appointment and phone books, you can't read the entire data file into memory at once (like on the HP 95LX). It necessitates some type of database management.

As soon as you go to a database style setup (as opposed to an "everything's in memory" style), you immediately take a BIG hit in speed performance, because you're now reading and writing records to the RAM disk all the time instead of just pushing things around in system memory. We were aware of the fact that this would slow things down, but we were hoping that the hardware developers would give us enough horsepower to make it bearable.

They did, but we only got about 1/2 to 2/3 of the horsepower improvement that we (the software developers) were hoping for. However, they did give us some hardware specifically designed to write characters rapidly to the screen. This helped us develop applications that run in graphics mode.

How does manufacturing fit into the whole development process?

Manufacturing (like all other areas) is involved from the start. They're responsible for working with the R&D engineers to make sure the product is "manufacturable," to design the production line, assembly and test equipment, test procedures, etc. The parts that are included in the product are evaluated and specified by the R&D engineers.

Are your hardware people so used to the whole process that it all works together without too much difficulty?

Yes -- but occasionally no. Each product (except minor revisions/ changes) goes through one or more Lab prototype "builds," where the first units are put together and tested. Eventually, there will be one or two production prototype "builds," which provide manufacturing and the lab with the opportunity to "train" the production line, refine the production process, and work out any last bugs in the product.

How does the cost of manufacturing and of parts effect the design?

A "list price" goal is set from the very beginning and, although not totally set in concrete if a good reason arises to change it, pretty much sets limits on what can be included in the product. Neither price nor feature list comes first. It all develops together in a kind of tug-of-war.

How are disagreements resolved? Is there a natural tension between hardware and software developers?

Disagreements are resolved in a very mature fashion. We have plastic buckets that we use for helmets and Nerf swords, and we just "duke" it out. The last one standing wins!

Actually, it's just a matter of discussing it amongst all the knowledgeable engineers and managers, weighing the pluses and minuses and various options. Sometimes the conclusion is pretty obvious to everyone, sometimes there's two or three "camps" all with strong arguments. In that case, it eventually boils down to a management decision (democracy always runs into problems that require a little bit of dictatorial direction to solve).

No, I'd say there's not any "natural tension" between hardware and software engineers. It's really a very cooperative relationship. When all joking is put aside, I think there's a great deal of respect on both "sides" for what the other group is able to do with their knowledge and skills. Both groups sometimes look like magicians to the other. (And sometimes, both groups look at the other group in dismay asking, "WHY can't you do that?")

What are some of the ways that HP's calculator products have been useful in the development of the HP Palmtops?

I'd say it's the long history of experience at designing pocket sized products that are rugged, low power, and pack lots of computing power. It's a different mind set from someone that's used to designing desktop computers where size, weight, and power are not as big issues.

Is there anything you or others on your team would like to say to HP Palmtop users?

(With a rousing chorus of HP voices harmonizing as one): Thank you!

iPhone Life magazine


Notice about Palmtop.net
The Palmtop Network with its S.U.P.E.R. (Simply Unbeatable Palmtop Essentials Repository) software is now available under the domain name of hp200lx.net.  

 
We Buy
We buy used palmtops, working or broken: HP 200LX, HP 100LX and 1000CX.
 

Copyright 2010 Thaddeus Computing Inc