A sneaky fault
ard at p850ug1.demon.co.uk
Sat Jan 20 16:45:12 CST 2007
Please forgive me for the marginal off-topic nature of this post. The
machine in qurstion is an HP9820, which is, I think, a programmable
calculator (the distinction being that it has a key-per-function type of
keyboard, not a full alphanumeric one where you type out the keywords).
I'm working on an HP9220,. For those who know nothing about this series
of machines, its one of the few common-ish bit-serial procesors (and is
intereting for that reason alone). The processor has 2 accumulators (A
and B), program counter (P), current instruction (Q -- stands for
'qualifier,' I am told), extension (E -- only 4 bits wide), I/O, memory
address (M) and memory data (T) registers. It's microcoded (256 28 bit
words). Binary operations are done bit-serially, BCD operations (which
have to be between the A and T registers, with the result going into A)
are done 1 nybble at a time. The ALU is actually a pair of programmed
PROMs, not 'normal' logic. Oh, nnd to add to the fun, the memory system
uses some odd voltages. The ROMs are HP custom chips with chip select
lines that have to be driven to +12V (all other I/O line are TTL
compatible). THhe RAMs are Intel 1103 DRAMs, they're PMOS and use 16V
logic levels with a further 3V bius supply on top of that (so there are
+16V and +19V lines to the RAM boards).
Anyway, the fault was 'no display'. That is not a suprise. Since the
display is software-scanned, almost all the machine has to be working to
get a display.
Well, I started off checking the PSU lines (actually with all the logic
boards removed), they were all fine. Then it's worth knowing that the
clock board will run on its own. If you power up just the clock board,
you get a muclock pulse (microcode clock) for every 16 bitclock pulses
(shift register clocks). That was fine too.
Now there are 2 ways to procesed. The hard and sure way -- look at
various signals, work out what the machine is doing, compare to what it
should be doing, and figure out what must be causing the problem. And the
easy and uncertain way -- it's a bit-serial machine so just about
everything should be changing. If something is stuck, that's a likely
place to start looking.
The M and T register bits are brought out on a test connector on the
memory box. So I looked there. It turend out that M(15) down to M(12)
were all toggling, the remaining 12 M lines were all stuck low. Rememebr
the M register is a 16 bit shift register, loaded from the MSB end. And
it's built from 4 7495 chips. So it seemed 'obvious' that the chip that
handles bits 11..8 had failed. It wasn't accepting data, it was providing
0's to the next lower chip.
Getting a replacement was not easy, but I mamanged it. Soldering it in
was trivial (pin-through-hole on a very well-made PCB). But would you
believe the fault was the same. Of course I'd checked the clocks and mode
control line were getting to all the chips in the M register.
Puzzeled, I looked again and M(12). It was toggling alright, but when I
sampled it with a logic analyser, I found high time of the pulses was
only the bitclock pulse high-time width. Which clearly can't be right for
a shift register made up of D-types clcokced form bitclock. Moreover
M(12) as always low just before the active edge of bitclock. so the next
shift register in the chain would always clock in 0's.
Out came the most significant nybble of the M register, and it was
replaced with the ship I'd removed ffrom M(11)..M(8). And the machine
then sprang to life.
So be careful. A signal can appear to be doing the right thing but can
have nasty timing problems...
More information about the cctalk