A sneaky fault

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