Wang 600 Microcode Tracing Log Next
Seeking any meaningful microcode activity
The machine was now loading microcode from ROM and executing some sort of microcode sequence but the display remained dark and other microcode-based functions such as Shift key illumination did not respond. This situation does not offer much diagnostic information as it could be caused by:
- ROM failure delivering incorrect microcode instructions
- Execution engine failing to process one or more microinstructions incorrectly e.g. wrong conditional branch processing, ALU error, status codes stuck/failed
- RAM not storing or retrieving data correctly, thus messing up microcode operation
The microcode ROM was already hooked up to the HP 16500C logic analyzer which has a pretty deep sample memory (by the standards of boatanchor instruments). Therefore, it was easy to take a long trace of microcode address data to determine what the Wang was doing over the first several hundred (or several thousand) microinstructions after Prime.
At this stage Douglas Miller’s Wang 600 Simulator became a very useful resource - the simulator has a debug mode where the microcode can be single stepped while observing the microcode address and the internal state registers. This seemed to offer an easier way to home in on the area of the failure by comparing the sequence from the faulty machine with that of the simulator and investigating in detail if/when the sequences diverged.
Tracing showed that execution matched for 74 steps and then diverged at a conditional address based on the ALU Z0 flag. The simulator executed on the basis of Z0=zero while the machine acted as if Z0=1. Furthermore, the machine then fell into a loop of 20 or so instructions that repeated for the duration of the trace, and the repeating sequence included a conditional address based on Z0.
Z0 Status Flag Testing
If the Z0 status flipflop was stuck in the on state, this could lead to the behavior described above.
Instrumenting the 5964 ALU board shows microcode cycles as defined by CL, the Z bus which carries the four Z bits as a serial stream and the Z0 flipflop which clears if any Z bit is set. This trace shows that the Z0 flipflop is set at the start of each cycle and correctly resets if any bit in the Z stream is set.
This shows that the Z0 status flipflop is being correctly set by the ALU logic on the 5964 board. It does however leave open the possibility that conditional addresses based on Z0 may be incorrect due to logic faults in ROM address generation (6182 board).
1-word Microcode Emulator
To assist with further testing a simple ROM emulator was constructed.
- the rotary switches set up a fixed microcode word which is presented to every machine cycle
- the LEDs display the Next Address that is generated from the microcode-supplied address and any conditional modifications such as the Z0 condition described above.
This allowed the Z0 conditional address generation to be tested by setting up a single microcode word with
- A- and B-bus inputs of zero
- ALU set to generate either A + B or A + B + 1
- next ROM address to be conditional on the state of Z0
The A + B instruction should give a zero result and set the Z0 condition bit, causing modification of the next address. A+B+1 should give a non-zero result, clearing the Z0 condition and leaving the next address unaltered. In each case the effect on the next address can be observed to see if it correctly reflects the ALU result.
The results confirmed that the Z0 conditional addressing was working correctly, with all ALU operations correctly modifying the LSB of the next address. It did not appear that faulty Z0 conditional addressing was the cause of abnormal microcode execution.