Boardswapping and debugging (was Need contact...)

Yes, but try convincing a non-technical person of that. Absolutely... OK, a lot of HP9810 info that you probably don't need, but which might interest somebody here (it's better than flaming about E-bay, surely...) The machine is 16 bit, bit serial. The CPU is 4 boards, about 20 chips on each board. Mostly TTL, with some 74Hxxx parts (!). Also 9 small (256*4 bit) PROMs, 7 for the microcode (28 bits wide), 2 for the ALU (its essentially done by lookup tables). Actually, both the '16 bit' and the 'bit serial' are possibly wrong. The CPU registers, etc are 16 bits wide. Data (numbers) memory is 8 bits wide in the hardware, with logic to read 2 locations and turn them to/from a 16 bit word when transfering to the CPU. User program memory (to store keystroke-like programs) looks to be 6 bits wide to the CPU (a keycode is 2 octal digits), as above it's physically half that width, 3 bits. Incidnetally, other machines in the family (9820, 9821, 9830) don't play such shenanigans, the memory is all physcially and logically 16 bits wide. And the machine is not always bit-serial. It is for binary operations, but BCD addition, which has to be done between the A accumulator and the T register (memory data register) is done a digit (4 bits) at a time. The 4 CPU boards are : I/O Interface, Clock (which also includes the I/O control sequencer), CPU control (microcode), Data Path. Those are my names for them, and IMHO are less confusing than the HP names. There are 3 memory control boards that contain the shift registers to convert between the bit-serial CPU data and the parallel memory buses. One board contains the M registers (address), address decoder, etc. Anotehr contains the T register (data), buffers, etc. The last is the timing, control, refresh, etc. RAM is 1103s. Early Intel 1K*1 bit chips. With strange (19V) logic levels and power supplies. There are level shifters all over the place. ROM is HP custom 512 byte chips. At least most of the signals to those are TTL levels, although the select lines are at 12V levels. The display is 45 7-segment digits (!). It displays all 3 stack levels, 10 digit mantissa, desimal point, 2 digit exponent, mantissa sign and exponent sign for each level. It's almost entirely firmware scanned and driven. The I/O interface contains a 16 bit shift register. It provides 16 outputs nad 12 inputs (the other 4 inputs are grounded on the card) For external peripherals, which you plug into the I/O slots on the back, it's 8 data outputs, 8 data inputs, 4 status outputs, 4 status inputs, 4 select outputs (to select 1 of 16 peripherals). For internal peripherals, like the display, selection is done by dedicated lines from the I/O interface, so all 16 outputs can be used for 'data'. In the case of the display, 15 lines are used : 3 to select a particular row of the display (X, Y, Z register display) -- 1 of 3 code ; 4 to select a digit (binary code), 8 for the segment drives (7 segments + decimal point). There is a display strobe line from the I/O interface to the display. It drives monostables on the display board, which ensure that whatever the processor does, a particualr digit can't be left enabled. If that happened the display segment would burn out (the instantaneous current is high, to get adequate brightness). Displays were expensive back then. What all this means, of course, is that 90% of the machine must be working to get anything on the display at all. The CPU must be running the microocde correctly, in order to fetch and execute instructions (some of which hopefully will scan the display). The data path must be OK, to transfer data from memory to the I/O register, etc. The ROM must he OK provide instructions to the CPU. The RAM must be OK too, it holds the stack refisters, etc (not to mention the subroutine stack, scratchpad, etc). Memory cotnrol, addressing, etc need to be OK too so that the memory can be accessed. Of coutrse the display and its drivers need to be OK. And everything depends on a working PSU. And of course, just about all faults result in a blank display. How do you sort it out? Well, start by removing unneccessary bits (the intenral printer, card reader controller, even the keyboard logic connector). It's unlikely to help, but it's worth eliminating possible problems on the I/O bus. Check the PSU. There are testpoints for all voltages apart from +5V on the PSU boards, marked on the PSU cover. The 5V line is marked on the display PCB. Assuming that doesn't help, you're into the logic. IMHO, the best way to continue is to check for the display strobe at the display PCB edge connector. It's very liklely to be missing, but you'd feel a right idiot if you spent hours tracing the CPU operation only to find that the problem was one of the monostables on the display board! Then check the clocks (there are 2, bitclk to clock the registers <n> times between each muclk, which drives the microode. <n> is determined by 4 bits of the current microinstruction). If they're OK (the clock board can be powered up out of the machine, whereupon <n> is 16, for testing), next look at the microcode address lines on the CPU control board top test connector. If they're not changing at all, then either the INIT/ line from the PSU is stuck asserted (it's sourced on the 5V regulator board), or there's a problem with he sequencer. If the microcode is running, use a logic analyser to trace it. You are looking to answer the following : 1) Is the sequence sane? That is, could it occur if the sequencer and ROMs are workin correctly? 2) Is it stuck in the I/O loop (a 2 state loop, I can look up the addresses). When the CPU does an I/O operation, it sets an I/O control flip-flop on the clock board, then sits in this loop until the I/O control system has finished (and therefore clears said flip-flop). This is acually a very unreliable part of the machine, much of the time this is the cause of a blank display. If it is stuck in said look, of course you start to debug the I/O control logic 3) Is it going found the fetch-execute cycle? In particular, is it fetching instructions from ROM? If so, does the memory control system seem to be working? Are you getting reasanble signals to the ROM (and RAM). And so it goes on..... Of course you then may need the 'scope to find out what's up with the PSU drive waveforms, etc... Perhaps I'd better not admit to the time I tried to find out why the local oscillator in a radio wasn't doing that... I spent a long time checking components, and forgot to measure the battery voltage.... I don't think any one instrument will always give you the necessary clues. Part of faultfinding is knowing what an instrument _can_ tell you, and thus whether it's a suitable instrument for the job in hand. And of course, knowing what it's not telling you, so you don't assume something is right (like no ringing on a clock) when the instrument you've chosen (LA) can't tell you that. -tony