|Re: HP 9810A - current value?|
Message #13 Posted by Tony Duell on 13 Nov 2009, 9:34 a.m.,
in response to message #10 by marais
A few thoughts...
Firstly, the sections that are different between the 9810 and 9820 are :
The memory box (the aluminium box at the left side of the machine) and all the boards in it
The display PCB
The keyboard and encoder PCB
The I/O backplane (the 9820 supports DMA IIRC, the 9810 does not)
The other sections are the same (processor, PSU, printer, card reader/controller, main backplane).
The machine will run with the I/O backplane removed and the keyboard disconnected (it plugs in on an edge connector under the front of the printer). So while I don't approve of board swapping, I will say that if you pull the I/O backplane and disconnect the keyboard, you could fit the 'wrong' memory box and display to either machine.
My diagnostic methods go roughly like this :
If I don't think the machine has been powered up recently, I remove all the boards apart from the 3 PSU ones. I disconnect the keyboard from the main backplane, but leave the power swich cable connected. I remove the printer and memory box (in case that's not covered by 'all the boards' :-)). I then power up and check the PSU voltages. There are 6 of them (+5V, +12V, -12V, +24V, +19V, +16V). All but the first have labelled testpoints on the PSU PCBs. For the +5V, I know where to find it on the main backplane (and will tell you too :-)).
Then I fit just the CPU clock PCB (09810-66512). I check the 8MHz master clock and the 2 main CPU clocks (bitclock and muclk). If they're wrong, I find out why.
Then I fit the other 3 CPU boards, the memory box, and the display. If it was working correctly, the machine would run like this and give the right power-on display. Most of the time, if it's faulty, the display remains blank. The first thing I check is the dispstb line on the display connector. It should be pulsing if the CPU is trying to drive the display. It nearly always isn't (pointing to a problem in the CPU or memory areas) but I'd feel a right idiot if I spent time tracing the microcode only for the fault to be in the display driver.
At this point I use the fact that it's a bit-serial machine and that all signals should be changing. I quickly look at the M and T register outputs on the memory box test connector. All bits should be changing. If only the top <n> are, it points to a likely problem with that register. So I look into that.
At this point, alas, it's time to grab the logic analyser and the microcode listings and see what the CPU is doing. You can pick up the microcode program counter on the test connector on the CPU control PCB (09810-66513). I generally find one of 3 things now :
1) The microcode is going through a crazy sequence of states, pointing to a problem with the microcode program counter and/or ROMs. This is rare
2) The microcode seems to be going round the fetch-execute cycle. Maybe a problem in the memory box, or a the data path. Time to look at that
3) The microcode is stuck, often in the I/O loop. So I look as to why.
Electronically-good machines with mechanical problems are easy to fix in theory, but harder in practice (you really need a good workshop including a lathe to do card reader or printer repairs). There are some photos in my flickr account (tony_duell) showing both main mechanical repairs.
Electronic faults are harder to track down (but I assure you it's always possible) but fixing them is much easier. What you want to take on is up to you!