Hier geht's los

Wir bauen eine Mezzanine

Wir legen ein Parkett

Wir bauen eine Bibliothek

Wir fräsen Zinken!


Das intelligente Haus

Nützliches Zubehör




Siemens Comfoset 150

HP LaserJet II > III



My HP9810 repair job

MY 9810
In the summer of 2004 I became the proud owner of a HP 9810A calculator, serial number # 1410602631, built in W. Germany in 1974, with options 001, 002 and 004 installed. From the various stickers on the calculator, and by further investigating the magnetic card’s inscriptions, it would seem the calculator was delivered by a company called Gematronik in Neuss (interestingly, that’s the next bigger city to the place where I was born), and used by a surveyor, who had the last hardware check done in march 1992 by Gematronik, with the next check scheduled in 1995. That’s almost 20 years of service!

I later learned that the machine was part of a larger number of 9810s used for years by the military geographical office of the German armed forces. When these machines were retired in 1998, they were bought by a collector and picked up in northern Germany on his way to Denmark, and left overnight in a car trunk. The car got broken up, the machine was stolen, but found a few days later abandoned in a nearby forest, apparently considered useless by the thieves and left to rot in the dirt. It is unclear if the calculator was already defective before the incident or after, however the machine was taken to Berlin, where it was part of a calculator collection until I picked up the machine in August 2004. This is where the “HP9810 repair job from hell” began.

A first look
Of course we all hope for a broken fuse or a loose wire on a mains switch, but the former owner being a scientist, I knew I could rule out any obvious fault. Once on my desk, I quickly cleaned the machine on all accessible parts, checked for loose boards and connections, and turned it on. The ventilator started humming, but nothing else happened. From an email conversation with Frank, the prior owner, I knew that the Status, Float, Run and Insert Card LEDs would come up, so I turned the machine off and on again – and the four LEDs lit up. The main display, however, stayed dark, and the machine would not react to whatever key I pressed. The good news was that the last transport from Berlin to my bench did not further damage the machine. The bad news was that the problem would require a more in depth diagnosis, as a quick check of the various voltages revealed them all to be present and healthy.

The 9810 was conceived at a time before microprocessors ruled the world, with a CPU built across four printed circuit boards, and more PCBs to hold the memory. Any attempt to repair the machine would be doomed without schematics. The museum of HP calculators has a service manual, which apparently is just a board swappers notice, but on their forum I met Tony Duell, a member of the british HPCC, who reverse-engineered several classics including the even older HP9100 (how I wish I had one!), and made the schematics available to me. They were meticulously hand-drawn and then scanned and come as about 80 letter-sized sheets covering the entire machine, including the peripherals. Tony gave me permission to reproduce some of the schematics here to illustrate the faults found in my machine (thank you Tony!). I don’t think it is possible to do anything on the 9810 without these documents.

Under the hood
After removing the top latch, we notice five printed circuit boards in the middle of the machine, each identified with a different coloured handle. The four rightmost boards are the central processing unit, consisting of the I/O interface (HP number 66511, brown handle), the clock board 66512 (red handle), the cpu control board 66513 (orange), and the data path board 66514 (yellow). The leftmost board (violet handle) is part of the memory cage, which can be pulled out after removing the top cover. It contains the memory timing, address and data boards, as well as the RAM, depending on the options installed. The other parts are obvious, like the power supply to the right.

The 66512 clock PCB
The first thing to look for is of course the clock. On the 9810 all clock signals are derived from a 8 MHz crystal, located on the 66512 clock PCB (brown/red handle). I found it convenient to carry out the tests with the board pulled out and connected to an external 5V power supply, which greatly facilitates the tests. The board consumes about 400mA if operational.

The clock board also contains a huge test connector to hook up an external clock source. I did not have to use this means for my 9810, but at some stage I did consider it. Anyway, I checked the 8MHz master clock and the derived bit clock and microcode clock, and found them all to be working (as seen in the fuzzy scope image). The microcode clock is especially important, as it is this clock which increments the microcode program counter. This was the next part I looked at.

Test connectors
The 9810 has two test connectors, one on the memory cage, and another one on the 66513 CPU control PCB. The address lines on the memory cage test connector all showed static signals, indicating that no activity between CPU and memory was taking place. The CPU control PCBs test connector gives access to the microprogram counter, which showed some activity.

The 66523 memory address PCB
Since I had no activity on the memory address bus, I inspected the memory address PCB. The 9810 is a bit-serial machine, and the memory address PCB basically contains four 7495 4 bit shift registers, which are wired as a 16 bit shift register, called the M-register (see figure 1). Data is clocked in from ALU bit 0 and shifted with the bit clock, if the microcode bit 27 is active. I should have been able to monitor activity on the output of the 74H08 AND gate, generating SRclk from Bitclk and u27, but wasn’t. Since I was able to verify that both Bitclk and u27 were pulsing, I figured the 74H08 AND gate (gate U9d) was defect. I replaced it, but the machine did not wake up. More bugs to look for!

The microcode counter
From the beginning, my machine showed some erratic behaviour on power-on. It would either come up with no LEDs at all, or with Status, Float, and Insert Cart LEDs on. My interpretation was that these LEDs corresponded to some arbitrary status register which was not properly initialized, and therefore would show random results. Had I taken a look at the schematics (or asked Tony), I would have known that these LEDs are the outputs of Flip-Flop, whose inverted outputs are wired to other LEDs. If the machine shows no LED at all, the 5V power line is missing. Since I had verified all voltages early on, I assumed 5V to be always present. This was the reason why occasionally I found no activity on the microcode program counter. Anyway, right after replacing the 74H08 AND gate, I found the microcode program counter to be active, which led me to the conclusion that there was a link between the M-register and the microcode – which of course is wrong.

Well - at this stage Tony asserted that it might be a good idea to know what part of the microcode was actually executed, since it might give us a hint as to what part of the hardware to look for next. I do not have a logic analyzer, so I followed Tony’s suggestion to hook up an address comparator with a 74LS688 chip. This thingy compares two 8 bit addresses and sets a strobe line low if the addresses match. I found three decimal encoders and built myself what I called “my poor man’s logic probe”, shown in the picture. With this device, we were able to figure out that the microcode was stuck in a 2-instruction loop, toggling between addresses $5a and $a7. Tony knew that this sequence corresponds to an I/O operation, where the CPU waits for the I/O state machine to complete a cycle.

The never-ending I/O loop
$5A and $A7 are actually a 2-instruction loop the microcode runs around whenever it’s doing an I/O operation, waiting for the operation to terminate. The 9810 has a state-machine (which HP claimed to be an I/O processor), which is set going, and for which the main CPU microcode waits to complete its operation. This state-machine revolves around a 74H101 flip flop, which is cleared at the beginning of the I/O operation and set again by output #15 of the 154 decoder. Somehow it never got cleared on my machine.

The problem revealed to be the 7410 triple-AND, responsible for generating I/ O clock for the I/O bit counter (see figure 3). After replacing this chip, my 9810 booted up, greeting me with its bright LEDs. Bingo!

Next: The printer
Happy with the apparently operational machine, I did a few calculations, noticing that the 9810’s stack has a slightly different operation than the later machines. I recalled having read that the 9810 resembles the 9100 RPN implementation with only three levels, where no automatic stack lift occurs, as opposed to the later 4 level RPN stack, introduced with the model 35. Interesting!

Time to check the peripherals. I wasn’t expecting the card reader to work (and it did not), but was a bit disappointed when the printer died after playing with the feed mechanism and trying to print a line. The feed mechanism made an ugly noise instead of transporting the paper, which made me suspect a loose belt or something. After removing the printer, I found the belt to be well in place and looking surprisingly healthy for a gummy part in a HP-device. The problem was easier to track down then the previous one with the I/O bit counter: The feed motor is a 2-phase AC motor, whose windings are driven by two phase quadrature signals and their inverses, generated by two J-K flip flops shown in the figure. I found the motor clock input signal to these flip flops to be present whenever I pressed the feed button, but no output on the Q and Q/ outputs. I have to replace the 74107 chip.

The card reader
I admit I don't quite understand what's wrong with my card reader. Unlinke the 97 and 67 card readers and their familiar gummy wheel problem, the two (or three?) gummy rings on the 9810 card reader seem intact. Yet, the card is hardly pulled in, gets stuck in the middle, and may be slowly fed through the reader with a little pushing and pulling.

A closer observation with the innards removed shows that the belt seems to lose grip on the motor spindle, as the card requires too much effort to be pulled through. I noticed that one gummy ring may get in contact with the bearing metal occasionally, but even if I make sure it doesn't, it just takes too much force to pull the card through. I'll get back to this issue later, as soon as I find a fresh idea.

Start   |   97   |   9810   |  

© 2005 Marais