ROM Fault?
To date it has been possible to demonstrate that:
- the microcode ROM is emitting plausible microcode addresses and data
- the machine initialises correctly by loading microcode from address zero
- some execution sequence follows, but this does not result in correct machine operation
- single-word microcode produces plausible address and ALU results
- single-word tests are very limited in scope
This still leaves two general possibilities for the ongoing failure:
- that the ROM is delivering incorrect microcode (perhaps just one incorrect but critical bit)
- that there is a specific fault in the execution engine.
Considering these, it seemed simplest to instrument the entire ROM output and assess if the microcode values were in agreement with the available listings.
Suggestion of ROM Fault
Setting up the HP16500C to monitor all ROM address lines and output lines while the machine was attempting to run microcode soon showed a suspicious finding.
The 16500C has a handy feature, a live view of the activity on each signal that is connected. When monitoring an active machine most of the signals will be dynamic and this is shown by a vertical double-headed arrow. Signals permanently high or low display the appropriate horizontal bar.
When connected to the complete 42-bit microcode word, the live view feature shows that 3-bit BI value in the has varying bits 0 and 2 but bit 1 is always zero.
The microcode BI field controls data input to the ALU. A stuck bit in this field would clearly cause major disruption to the microcode and would be sufficient to explain the dead machine.