Wang 600 ROM Address Test
Next Log Entry
ROM test - no outputs
With basic system timing signals verified a useful next step was to determine if there was any microcode activity.
In the Wang 600 there is no Program Counter as in typical microprocessors. Instead, each microcode address contains the address of the next microcode to be executed. Pressing Prime forces execution to address zero and execution then proceeds according to the addresses specified in the code.
To assess microcode execution one can monitor the address lines that are presented to the microcode ROM and the Next Address fields in the ROM output. If data is captured once per microcode cycle then the first ROM address accessed after Prime should be address zero and for each cycle the Next Address in the ROM output should be seen as the ROM address for the following cycle. The list of ROM addresses shows the sequence of microcode that is being followed, and the actual addresses being executed may give some further clues as to where faults may lie.
ROM Next Address Outputs: All Silent
The 6182 ROM Address board was put on extenders and instrumented to give access to the ROM address bus and the ’next address’ fields. The capture shows complete microcode execution cycles,
- the first cycle has a zero ROM address in AD_LO and AD_HI
- and the ’next address’ data output on JAD, JH and JL is also zero
- subsequent cycles repeat the zero ROM address and zero ’next address'
This execution sequence is “correct” in that execution has correctly started at location zero, and location zero is specifying location zero as the next address to execute - hence an infinite loop at address zero.
It’s obvious that location zero should in fact be delivering an non-zero next address. We are fortunate to have access to a ROM transcript from Douglas Miller’s excellent Wang 600 Simulator. Referring to this transcript shows that ROM address zero should emit next address data of JAD = 0x1FC, JH = 0 and JL = 0.
The fact that all bits in three ROM fields are zero suggests a more global kind of ROM failure. Any ROM failure is unwelcome since the ROM is the most complex and delicate component, and very likely the most impossible to repair.
Troubleshooting Silent ROM
Examining the ROM schematic showed only one feature likely cause a global failure of the ROM - the circuit that translates the CUP signal (already verified to be present when checking basic timing signals) into the controlled current pulse that is injected into a ROM wire so as to generate data pulses from each output transformer that is included by that wire. Without a current pulse, no output bits could be generated and the ROM would be silent, reading as all zeros.
Basic multimeter checks around this circuit showed that the nominal 12.8v supply to the drive circuit was actually 0v and R99 (33R 1W) was hot. Obvious culprits were C2 (100uF tantalum) or C5 (25uF tantalum). C5 was indeed short-circuit.
Replacing it restored the 12.8v supply to the current pulse generator.
Once again, aged tantalums going short-circuit are the culprit….
ROM Outputs Restored, Microcode Executes
Repeating the test above showed that the ROM now produced ’next address’ data after a Prime and that a series of different addresses were seen. Recall that one should see that each successive ROM address has its upper bits nine encoded by the JAD outputs of the previous instruction, and the lower two bits set according to machine state and the JH and JL fields of the previous instruction. This appears to be the case and provides evidence that the logic involved with capturing ROM ’next address’ fields and translating these into the actual next ROM address is working.
The (brief) capture shows that after address zero is forced into the AD HI and AD LO lines, execution goes to a new location and then continues by alternating between each of two further locations. This may represent being stuck in a tight loop, perhaps the result of further fault(s) that don’t allow normal execution to proceed.
By way of confirmation, the machine still did not produce a display, confirming that further faults existed.
Previous Log Entry Back to Log Index Next Log Entry