|1||L0001 (FPA)||FP750 Floating Point Accelerator (option)|
|2||L0002 DPM||Data Path Module|
|3||L0003 MIC||Memory Interconnect Cache|
|4||L0004 (UBI)||Unibus Interconnect|
|5||L0008 (PCS)||Patchable Control Store|
|9||NX0075||Nemonix Disk Controller with Systems Industries PROMs|
|11||NX75-4||Nemonix 1MB Memory|
|12||NX75-1||Nemonix 1MB Memory|
|13||240-011-900||EMC 1MB Memory|
|14||240-011-900||EMC 1MB Memory|
|15||240-011-900||EMC 1MB Memory|
|16||240-011-900||EMC 1MB Memory|
|17||240-011-900||EMC 1MB Memory|
|18||240-011-900||EMC 1MB Memory|
|20||-||Bus Grant Continuity|
|21||-||(slot marked "Ethernet")|
|22||-||Bus Grant Continuity|
|23||TC131||Emulex Tape Controller|
|24||-||Bus Grant Continuity|
|27||-||Bus Grant Continuity|
[... the XX2247 key was] eventually duplicated the key from an original, which
resulted in the following ordered cuts: 7573715.
Looking at the key with the open end of the tube facing you and the metal
bit at the top, the numbers correspond to the depth of the cuts going in a
counter-clockwise order. Put another way, the bit is at the 12-o'clock
position, a cut of depth 7 half-way between 9 and 12-o'clock, cut of depth 5
at 9 o'clock, depth 7 half-way between 9 and 6 o'clock, depth 3 at 6
o'clock, depth 7 half-way between 6 and 3 o'clock, depth 1 at 3 o'clock and
finally a cut of depth 5 half way between 3 and 12-o'clock (all this while
looking at the open end of the tube).
As an estimate, it looks like a cut of 8 would correspond to 1/8 of an inch.
With an original on loan I was able to have three duplicates cut, one of which will go to the person who lent me the original by way of thanks.
While I was cleaning, I noticed that the air blower unit has a standard US power cord on it so I unplugged it from the power controller and plugged it into an extension cord (after first checking across the live and neutral pins with an ohmmeter to check for shorts). The fan spun up cleanly and produces an adequate, although not exactly hearty, airflow up through the card cage. Closer inspection showed that the foam rubber gasket between the blower and the ductwork is crumbling away to dust. This will be replaced with non-foam rubber weather stripping or draught excluder material. The presence of airflow is important not only because of its cooling function but because there is an airflow sensor that can shut the system down if adequate airflow is not detected.
With the +5V and +2.5V lines disconnected at the power supply, the ohmmeter across +5 and +5 Return, and then +2.5 and +2.5 Return on the 2K range showed a slow, steady increase from zero upwards. After about half a minute readings of better than 400 ohms were noted. Switching to a DC volts range showed a slow steady discharge back out of the caps. The conclusion from this, coupled with the knowledge that the device has been powered on recently, is that the capacitors do not need to be reformed, there are no direct shorts across the power supplies themselves and the output caps are not open circuit.
All the cards in the cage were pulled out of their slots but left in the cage. Additionally, P2 on the lower edge of the console board in the front of the unit was disconnected, and both connectors on the TU58 interface board (front RHS of the chassis) were disconnected. Finally, a Nemonix daughter board was removed from the backplane after carefully photographing the position. This eliminates all known power sinks from the power supply.
While I was close to the backplane, I took the opportunity to inspect it for bent pins. I just got reading glasses in the last month and these certainly help. A tip here is to align yourself so that you can look down an entire row or column of pins and look for any that are not standing up straight. In addition to bent pins, another possible cause of shorts is a stray end of a wire-wrapped connection so I checked for these two. Of the three backplanes, the most difficult to check is the Unibus one because it's heavily wire-wrapped.
No bent pins or wire-wrap shorts were observed.
I inspected the time-of-year (TOY) battery pack for leakage. The pack appeared to be in good condition. The TOY battery is intended to keep the time of year clock running during brief power outages, either scheduled or unscheduled, and is designed to last around 100 hours. I believe it can be removed entirely if necessary although at this point I have no need to do so.
Incandescent headlamp bulbs (not quartz halogens) seem to be recommended as dummy loads for these types of application. NAPA has 60W/50W incandescent sealed beam units for $5 apiece and I bought two of them and wired the filaments on each lamp in parallel using a decent heavy gauge wire, giving me two separate dummy loads. I used 10AWG automotive 'primary' wire from NAPA and crimped quick-release terminals on one end to connect to the lamp, leaving the other end bare to slide under the screwheads on the power supply terminals. The power supplies have to be left connected to the backplane because, at least for the 2.5V lines, there is a sense signal that must be left in place in order for the 2.5V supply to function properly.
With the dummy loads assembled and connected across the +5V and +2.5V lines respectively, and the power controller remote/local switch set to Local, I applied power. The power controller showed the green OK light and no error lights. I measured the following voltages under load:
|Supply Line||Actual Voltage|
I removed the dummy loads and reconnected everything.
With a few minutes to spare I tried fitting the covers. It appears that the top hinge bracket for the back door is missing.
I have three slots - 7,8 and 9 that are empty, and I set the baud rate jumpers to 300 baud (just jumper C installed) as that is the default.
The CPU run light came on even through the unit is being booted in HALT mode. This was disconcerting. I scoped the backplane ACLO, DCLO and ~INIT signals which could affect the run status of the CPU and noted a periodic resetting of DCLO and ~INIT, once every .7 seconds or so. Even after pulling all the controllers the periodic resets occur so I am concluding that this may be an error in the power supplies.
No text appeared on the console but this may be due to the CPU not initializing correctly. Since the CPU should be halted and in console mode (i.e. running console microcode), it's reasonable to assume that nothing will appear on the terminal until the CPU halts.
Unfortunately changing the caps did not resolve the problem and it turns out that there are no outputs at all from the supply, not just the 12V line.
According to the diagnostic procedure in the H7104 Power System Technical Description this points to a plug-in regulator failure in the 2.5V PSU. The plug in regulators provide +5VB and +12V.
Checked over both the 12V and 5VB regulators and replaced some dying capacitors. No improvement.
Measured the voltage entering the regulator boards which should be 3048VDC. There is no voltage present at the input (J1, J2 on page 50 of the H7104-c schematic). There is no evidence of a short on the input to the plug-in regulators. No blown fuses and no shorts on the outputs. I have not checked the crowbar signals.
The 20KHz clock to drive the switching circuits is present and is derived from the 5V supply unit.
The 12VA line, which provides power to bootstrap the devices on the plug-in regulators, is present but low at around 10.5V. This is also derived from the 5V supply.
Working from the primary side (schematic page 50 of the h7104-c document), I measure 300V across the two 4500uf filter capacitors.
The power switching transistors Q1, Q2, Q3, Q4 all look ok under static analysis on the Huntron. Perhaps theres a voltage breakdown issue with one of them.
D4 looks OK statically as does D13.
There is evidence of a trigger waveform (+TRIGGER, -TRIGGER at J4) which should in turn drive the regulator pulse at J7 if the power switching through Q1-Q4 is working correctly. I'm not sure though what it should really look like.
As a result of swapping out the 2.5V supply, the cycling of the ACLO, DCLO and ~INIT signals also cleared up.
With regard to console wiring, the 11/750 console only uses pins 1,2,3 and 20 of the 25-way D-type RS-232 connector (GND, RD, TD and DTR) so a null modem cable will be required when connecting to a terminal.
Just as quickly as I got the %% displayed, I also got a status of %O when resetting the 11/750.
The execution buffer XB forms part of the instruction decode logic of the CPU. The buffer itself is part of the memory interconnect (MIC) board. There were also intermittent %X errors, which translate to 'Cache Parity Error Test' failures.
Both errors were eventually eliminated by removing the FPA from slot 1. For the %O error, this is unsurprising as the presence of the FPA is communicated to the MIC board where it is used in the XB and instruction decode logic.
The display following the 'T' command is now
which signifies normal completion of the microcode verify test when initiated from the console.
I made several false starts on the tu58 emulator source for linux. The most promising Linux-based TU58 emulation for this application would appear to be Don North's work described by Toby Russell here. I downloaded and installed the software on the SuSE 11 virtual machine on my laptop (Macbook Pro running Fusion 2.0). Since the machine lacks a serial port I plugged in a USB-serial adapter which was recognized by the tu58em program, as long as I was running as root. I have no problem running this as root. The command for the tu58 emulator is:
tu58em -r 750console -p /dev/ttyUSB0
I tried to run the boot PROM code to see what would happen with no devices attached. The code halts with status 15 which indicates that the cold start bit is set. I need to investigate what this means and whether it's possible to continue from it.
I also did a preliminary check on the TU58 serial interface, as described in the TU58 manual. The principle is as follows: send a BREAK to the drive; send INIT (04 octal) followed by another INIT, and then examine the console storage receive register which should contain octal 20. The following console commands should work:
D/I 1E 0 ; clear the break bit in the console storage transmit status register
D/I 1E 1 ; send break to TU58
D/I 1E 0
D/I 1F 4 ; transmit INIT command
D/I 1F 4 ; transmit another INIT
E/I 1D ; should be octal 20 My TU58 doesn't appear to conform to these instructions so I have to conclude that there's a problem somewhere in the TU58 or the console storage circuitry on the UBI board.
Running the emulator I tried the manual test described above but the 750 hung on the %% prompt. From the wirewrap jumpers on the TU58 it appears that the 750 console storage baud rate should be 19.2K. Setting the protocol analyzer to 19.2K I could see characters coming from the VAX but the emulator was apparently receiving garbage. After some inspection of the code it seems that tu58em was not setting the baud rate correctly on the line. Overriding it with an stty -F /dev/ttyUSB0 ispeed=19200 ospeed=19200 seemed to fix the problem and at that point I was able to boot into the BOOT58 program. From the information displayed by boot58, the correct command is b/800 dda0 as this suppresses the search for a particular command file. Once I had the boot command correct, the BOOT58> prompt came up cleanly.
I decided to try booting some other tape images from Jared Blaser's repository on the web. I was successful in booting tape 5 (ECKAL Cache/TB Diagnostic), tape 6 (ZZ-ECSAA Diagnostic Supervisor), tape 17(also the diagnostic supervisor) and tape 41 (11/750 Console).
I located an RDM card from an online vendor and ordered it today (1/19/2010) so am anxious to get tape 1 working.
The listing file also contains the BOOT58 help text.
Here's an example of a boot command file for the RL02:
! DL1 BOOT COMMAND FILE - DL1BOO.CMD
D/G 0 2 ! RL02 DISK
D/G 1 FFE000 ! BASE OF UNIBUS I/O PAGE
D/G 2 3F900 ! CSR ADDRESS OFFSET
D/G 3 1 ! CONTROLLER UNIT = 1
D/G 4 0 ! BOOT BLOCK LBN (UNUSED)
D/G 5 0 ! SOFTWARE BOOT FLAGS
D/G E 200 ! ADDRESS OF WORKING MEMORY + ^X200
LOAD VMB.EXE/START:200 ! LOAD PRIMARY BOOTSTRAP
START 200 ! START PRIMARY BOOTSTRAP
The picture shows the front panel status with the 11/750 halted (and therefore running console microcode).
Using an HP protocol analyzer to debug the TU58 emulator.
The picture shows the long-awaited BOOT58> prompt. The BOOT58 program was loaded off the laptop running tu58em
The help screen from the Diagnostic Supervisor program on Diagnostic Tape #6