In 1976, 30 years ago, Hewlett-Packard Corporation introduced a landmark product: the HP97 portable, programmable, printing scientific calculator with magnetic-card storage. The HP97 was one of a matched pair with the HP67, the pocket version of the SAME calculator! These two could read and write the same magnetic cards containing programs and data, and they could execute the same programs. The pocket version, the HP67, did not have a printer, so it just paused the display when it executed a PRINT instruction of some kind or another. Other than that and the form factors, These two machines were clones.
These were as close to a commercial personal computer as could be bought in their day. Hewlett-Packard had already changed the world in 1972 with the HP35, the world’s first pocket slide-rule calculator. It is difficult to overstate the impact the HP35 had on the scientific and technical world, especially in areas with a lot of field and lab work such as surveying, navigation, prospecting, refining, and power generation. Overnight, HP had obsoleted slide rules and pocket mechanical calculators like the Curta, which, itself, had revolutionized the world 25 years prior. Technical people could now carry around anywhere a single instrument with unprecedented accuracy, speed, reliability, and quality. And the battery was very long-lasting, the machines were unbelievably tough (I dropped an HP45 off my motorcycle at speed, turned around, found it in the gutter, picked it up, turned it on, and it still worked. It still works TODAY!)
These machines also had a wonderful look and feel, both in the software – they used RPN – and in the hardware – the buttons prevented accidental pressing with a slight resistance and confirmed pressing with a satisfying click. Not only were they a landmark of technical capability, but of industrial design and aesthetics. They have never been equaled, frankly, even by HP itself.
By 1975, HP had developed a stored-program version of the pocket slide-rule calculator, the HP65. This was so powerful and reliable that it was routinely used in life-and-death situations, for instance, as the back-up navigation computer aboard the Apollo-Soyuz space mission (read about it at the link above).
Now, I’m an official rocket scientist. At the time, I was an official student of rocket science. I routinely used an HP45, a souped-up HP35. It had cost me $400, which was a substantial fraction of my annual income. I had never been able to afford a Curta, but the HP45 was just a must-have and worth every penny. I could not afford the HP65. At $1000 in 1975, it would be like spending $4000 today. At that time, a 3-year-old Volkswagen could be bought for $500. It was a stunning amount of money. But it was a stunning machine. Everyone in science and engineering knew about HP65s and lusted after them.
Then, one year later, HP outdid themselves and introduced the 67/97 pair. The 67 was $450 and at least three times as capable as the HP65. Interestingly, HP continued to sell the more expensive HP65 at its original price of $1000, a move which endeared its customers. Rather than slap them in the face by dropping the price to liquidation levels, they refused to punish their early adopters. But the 67s and 97s flew off the shelves – even students could afford them.
When I started my PhD thesis, I plunked down a bankrupting, heartbreaking $750 for an HP97. But the need for printed results was overpowering, never mind the fact that I was under the sway of irrational lust and I just had to have the thing.
I still have it. It sits on my desk at work, crunching out prime numbers above 1,000,000,000, at the rate of 1 about every three hours. It makes a great conversation piece: if someone happens to be in my office and the printer goes off, it can make a nice break to say “Oh, we have good news: 1,000,022,897 is prime!”
In honor of the 30th anniversary year of this incredible machine that changed the world and affected my life, and in honor of the new technologies embodied in VB9, LINQ, and ADO.NET which are doing the same things, I decided to write a simulation of the HP97 using those new technologies in such a way as to show them off. This simulation runs, in fact, the exact same programs as the original HP97. The simulator can execute in two modes: with UI and as a console application. With the UI on, the simulation blinks lights and pretend-prints and runs about 20 times faster than the real calculator, spitting out a big prime about once every 10 minutes. As a console app, it runs about 20,000 times faster than the real calculator, spitting out a big prime about once a second.
This simulator does not cheat. It has a delegate function for every allowable calculator key. There is a database of instructions with their key scancodes, which I typed in from the HP97 manual. Each instruction is represented as a string. Here’s a sampling of those instructions.
| 12 | 1/X | 52 | NULL | NULL |
| 13 | 10^x | 16 | 33 | NULL |
| 14 | ABS | 16 | 31 | NULL |
| 15 | CF0 | 16 | 22 | 0 |
| 16 | CF1 | 16 | 22 | 1 |
| 17 | CF2 | 16 | 22 | 2 |
| 18 | CF3 | 16 | 22 | 3 |
| 19 | CHS | -22 | NULL | NULL |
| 20 | CLRG | 16 | -53 | NULL |
| 21 | CLX | -51 | NULL | NULL |
| 22 | COS | 42 | NULL | NULL |
| 23 | COS-1 | 16 | 42 | NULL |
The programs are stored in a different database table as sequences of strings. Again, I just keyed these in from the manual or from actual paper-tape printouts. Here are the first few instructions of the primes program:
| 1 | LBLA |
| 2 | STOB |
| 3 | ENT^ |
| 4 | INT |
| 5 | X<>Y? |
| 6 | GTO5 |
| 7 | 0 |
| 8 | STOD |
When the user simulates the reading of a mag card into calculator memory (with a drop-down list box or with a “read” console command), I use LINQ over Dataset in ADO.NET to read the program, as strings, into memory. To execute the program, I dispatch each instruction string through a lookup table to its delegate function, and advance the instruction pointer by the appropriate number of steps. While the program is running, I write the state of the machine back out to database tables, including the 4-position stack, all 25 registers, and a few hidden registers like the instruction pointer (ip) and LASTX. For performance reasons, I throttle back the state-saving, saving once every N instructions, typically 100,000. The simulator can also read back its state from the database and pick up calculation from a saved checkpoint.
If I set the throttle to save to the database every time a single instruction executes, then the simulator effectively runs out of the database. It’s quite slow, but, as a demonstration, it’s also quite amazing. The simulator could be made even more databasey if I implemented the calculator functions as stored procedures in the database and actually executed them there. I might make a version to do that in the future.
But for now, I’m focusing on another trick: saving the code for the calculator functions in the database as serialized LINQ Expressions. In a previous life, I would have just implemented the calculator functions in Scheme and written them out as S-expressions into the database. But with the new facilities in VB9 and LINQ, we’re going to have all that capability and more, since we can get at the .NET framework. This isn’t quite working, yet, due to some bugs in the internal development version of LINQ, but I will show off this idea once we get it off the ground. There will be a new version of the VB9, LINQ, and ADO.NET Customer Technology Preview (CTP) some time in the next few weeks, and, when that is released, I’ll blog the details of my simulator program and explain how they exercise our new technology. In particular, I will be able to show how dynamic identifiers, relaxed delegates, and late-bound delegates drastically reduce the size of the UI code and make certain bugs impossible. It’s a great time to be a programmer, even 30 years after the HP97.