Plotter ROM for the HP9810 - how to use it?

[Tony Duell]

(04-19-2014 08:45 PM)Thomas Falk Wrote:  Hi Eric,


This was easy: I have found that only one bit was wrong at a certain address. It was stuck at H. Therefore I decoded out this address and pulled the bit down. This was done using a 74HCT688 decoder and a AND-Gate made by diodes. The resulting fix is shown in the following picture.

I think I should point out that there are 2 levels of firmware in these machines. The microcode is part of the CPU and is part of the system to interpret machine instructions. It consists of 256 words, each 28 bits long, and is the same in all HP9800 machines (AFAIK, I have never seen an HP9821 inside).

The system firmware is what makes the machine behave as a calcualtor. It consists of 16 bit machine instructions -- 2K words in an HP9810, 4K words in an HP9820, and 7.5K words (IIRC) in an HP9830.

The microcode is stored in 7 bipolar ROM chips (each 256*4 bits) on one of the CPU boards. The system firmware is stored in HP custom ROM chips, each 512*8 bits.

(04-19-2014 08:45 PM)Thomas Falk Wrote:  Finding this was a little more difficult. When I started to repair this calculator I found a dead logic gatter and a dead transistor in the drivers for the DRAM ciruits. After repairing this it worked, but the display was wrong.

In the end I read the addresses and the data of the microcode ROMs and found the faulty bit. Actually after having done this it is quite easy: If you read the adresses and the data during running the calculator you get a partial dump of the mico code ROMs. You will get the data for the adresses the calulator is accessing only, but this is enough. This data you can compare with the listing of the ROMs in the patent US-3,859635 describing the calculator. My work place looked like this:

I have a commented source listing of the microcode (not the system firmware), produced in part by desoldering the ROMs from a working machine, reading them, and figuring out what was going on.

(04-19-2014 08:45 PM)Thomas Falk Wrote:  There are two logic analyzers in use. For comparing the read data and the data from the patent I wrote some small python scripts.

If there are more faulty bits in the ROM the fix above is not practicable and you would have to replace the ROM by some modern or older parallel EPROM. This should be possible.

The microcode ROM has to be quite fast. Remember the CPU clock is 8MHz, giving a 125ns cycle time. In one cycle the microcode program counter has to update, the microcode ROMs have to give the next word, and the decode logic has to work too. Many EPROMs would be nowhere near fast enough for this.

There were fusible-link ROMs with the same pinout as the CPU microcode ROMs. I suspect NOS ones do turn up from time to time, obviosuly these are strictly OTP, so ex-equipment ones are useless.

The system firmware ROMs (where Eric is having problems) are more difficult. HP's ROMs are a bit strange, no standard PROM/EPROM will just drop in. There are, of course, various work-arounds.

(04-19-2014 08:45 PM)Thomas Falk Wrote:  When I repaired my HP9810, it was my only device. I got reference data from the HP9800e emulator and compared its program dumps with the data from my calculator to dig down to the micocode. To isolate a faulty card it is useful to have a second calculator for board swapping.

I will pretend I didn't read that. Suffice it to say I can think of a dozen faults where
board-swapping will cause confusion, and some wehre it will cause damage!

-tony