A sneaky fault

[Tony Duell]

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). 
But anyway...

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...

-tony