When received it dirty and several parts were missing or broken. A first inspection gave that both the top and bottom cover was missing. The front decorative panel beneath the switch front panel has a broken fastening thread. The cable to the switch front panel is damaged. The power supply is lose and not secured in the chassis and the six screws are missing. Further one connector in the PSU has become alarmingly hot. Then also the copper trace to one transistor has became very hot, as much as it has lifted from the PCB. Then also the fans for the card cage are missing. The top filler panel is replaced with an aluminium panel.
Work on the H750 power supply gave that the 5V H744 supply (to the left in the picture above) module was in good shape but the main supply (to the right) providing all other supplies had a big filtering capacitor which was in very bad shape. It stayed charged for a few hours while others stayed charged for several weeks. Replacing this with a modern one was a little bit difficult since finding a direct replacement was hard. Putting a modern electrolytic capacitor inside was possible, but it was fairly difficult to get the innards of the old one out off the shell. Then also two small caps were leaking and had to be replaced. Now the PSU was running fine when loaded.
The serial number for this machine appears to be 09742 if I read the plate correctly. It is stamped PR which means that it has been produced at the Puerto Rico facilities.
First power up
The control board was marked "Faulty" but the Data Path board was marked "OK". With the console connector repaired we powered it up with only two bus terminators installed in the bus. No memory. At first it was quite responsive but shortly it ended up in a mode where nothing but the START switch made any difference. Pushing down the start switch made the RUN lamp to go dark and the display to increment. All the other switches gave no effect. Time for some error tracing.
Checking the schematics give that the switches enters on the Data Path board but goes directly to the backplane to connect to the control board. On the control board these enter into a register. The Deposit, Continue, Examine and Load address signals is decoded in a PROM to start addresses for the microcode. So it seems that the console handling is done in microcode. Also some parts of the microcode is visible on the backplane which makes it easier to measure those signals.
With the logic analyzer connected I took two different traces of microprogram flows. Firstly what happened at power up and then what happened after releasing the START switch. The microprogram address is the next address to execute since this is what is present on the back plane.
Since I had another pair of non fully working board I compared the behavior.
At power up
Why is it going from address 241 to address 247 rather than 347? Could there be a problem with bit 6 in the MPC (Microcode PC) signals from the E102 / A04A2 PROM? The MPC signals are wire ORed with different signals when the machine perform micro code branches. The MPC is active low so address 347 is 00011000 binary which means that it is impossible to wire OR it to get to 247 (01011000). After address 247 it is supposed to get to 226 not 206. This could potentially be a wire-OR problem. It is not a OC driver which has failed permanently since that would have caused problems with all addresses. So instead of probing on the backplane the control board was put on extenders and the logic analyzer clips were attached to various gates. None of the micro branch BUT enable signals were active at the time so nothing should be wire-ORed. Running the machine without the DataPath board gave exactly the same result so there are nothing there that is affecting the MPC bus.
Since all address that have problem is in the high nibble of the MPC a micro code PROM is suspect. E102 / A04A2.
Removing the chip and reading it out show considerable differences from the micro code listing in the schematics. New PROM chips has been ordered. Asking around, there were no one else that has this problem before so we had to I had to resort to use the micro code listing and prepare a Intel HEX file from it. The new PROM was burnt and soldered into place. It worked much better than before. Now it was even possible to execute a small program out of the registers and access memory.
More PROM failures
The next step was to insert a M9301-YF boot card to see if we could make it run the console emulator over serial port so that I could download diagnostics into the machine and test it out further. Unfortunately this was not very successful. It halted at address 165102. The contents of the PROM has been dumped and spliced together. The resulting file was compared with the dump that Noel Chiappa has performed. It matched well. So why did the CPU read some words with the high bit set when it was not set in the PROM dump? This could be a CPU fault or M9301 board fault that has to be researched further.
Testing the M9301 board yet more with a logic analyzer actually showed that there were a PROM content problem in one of the chips. A new dump was made in the PROM programmer and this time there were a few bits most significant PROM that was always set to 1. Burning a new PROM solved this. It was now possible to do examine in the M9301 address space and recover content that matched the listing the Noel did earlier. At least a while. After a short while first one DEC 8881 bus driver failed and then soon another.
BIS instruction misbehaving
The machine was still not working it just stopped with 165102 showing at the display. This is the code from a disassembly that Noel Chiappa have done.
Normally the display shows the instruction of the next instruction to execute which means that the halt was at 165100 which is the offset of the BIS indexed addressing operaton. Poking some instruction into core memory and experimenting from the console of the machine revelas that not only BIS has problems, but also MOV and BIC. Could there be some general problem with indexed addressing causing trouble? Testing deferred indexed addressing works just fine.
To understand more I attached the logic analyzer to the microprogram address and did some tracing. Trigger was set on micro address 062 octal which is the first micro step in the fetch phase.
More tracing also gave that there were no micro branching taking place and the failing bits is in the upper next address bits. Was there something wrong with the burnt PROM? Checking the original files gave that unfortunately the location 30 has been missed while typing in the file.