DEC VAX-11/750


Original Configuration/Board Complement

Slot Board Description
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
6 -
7 -
8 -
9 NX0075 Nemonix Disk Controller with Systems Industries PROMs
10 -
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
19 M9202 Unibus interconnect
20 - Bus Grant Continuity
21 - (slot marked "Ethernet")
22 - Bus Grant Continuity
23 TC131 Emulex Tape Controller
24 - Bus Grant Continuity
25 M7819 Serial Lines
26 M7819 Serial Lines
27 M7819 Serial Lines
27 - Bus Grant Continuity
28 M9313 Unibus terminator

11/750 adopted June 2009. From right to left in the image, you can see the 11/750 chassis with covers removed; an RK07 drive; a BA11 Unibus expansion rack; a Microvax 3500 with an RA82 in the top of the chassis (the white cylindrical item with the vents on top of the RK07 is a HEPA filter).

Bringup Plan

With a device of this magnitude I felt a little planning was in order. I came up with the following based on web reading and prior knowledge from other systems:
  1. Inventory boards and parts
  2. Locate sources for missing parts
  3. Clean and remove dust and contaminants
  4. Test backplane and ancillaries for shorts
  5. Evaluate power supplies (test electrolytics and reform if necessary; load-test PSUs with boards out)
  6. Verify that backplane is configured correctly for boards (jumpers, wiring)
  7. Install boards and power up without mass storage
  8. Get console working (issue noted from previous owner)
  9. Assemble TU58 emulator and diagnostic tape images
  10. Run diagnostics and test CPU and controllers
  11. Decide on mass storage configuration approach
  12. Obtain mass storage controller, cabinet kit and cables
  13. Install VMS from CDROM onto mass storage from another VAX (with a SCSI controller in it)
  14. Connect mass storage to 11/750
  15. Boot

1. Inventory Boards and Parts

The original board complement is shown on the right and it turns out to be 90% complete. Missing from the CPU is the memory controller, of which three models existed: the L0011, L0016 and L0022. Normally, the choice of memory controller would determine the memory configuration of the machine. In this case, however, the machine came to me with 8MB of memory installed (from Nemonix and EMC but believed to be compatible with DEC 1MB memory). The L0011 was designed for 256K boards; the L0016 supports 1MB boards up to 8MB, and the L0022 supports 2 x 4MB boards and 6 x 1MB boards for a total of 14MB. Since I have 8 x 1MB boards, the L0016 was the best option and I was able to locate one fairly quickly. With regard to installation, the memory controller should be installed in slot 10, the last CPU slot.

The Nemonix disk controller in slot 9 was configured for use with a System Industries disk rack, which I do not have, and don't particularly want, so that controller will ultimately be removed and replaced with either a UDA50 or possibly an Emulex UC17 or UC18 SCSI controller if I can save up enough cash for one.

The empty slot 21 was originally intended to house a DEUNA Ethernet interface and I will locate one in due course. For now I will install a bus grant continuity board in there.

Finally, and perhaps most irritatingly, the key is missing. The key is the usual ACE XX2247 tubular key used in many DEC computers over the years. A call to my local locksmith turned up nothing (although he has now cut me two replacement keys for my Dranetz project, so all was not lost).

2. Locate Sources for Missing Parts

L0016 Memory Controller

The L0016 memory controller was ordered from J T Computer Marketing. They list DEC parts frequently on eBay. The board was $45 plus shipping.

That Pesky Key

XX2247 keys are a bit of a pain to find unless you can duplicate from an original. Quoting from the alt.sys.pdp11 group, the following cutting information was posted some years ago:

[... 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.

3. Clean and Remove Dust and Contaminants

Simple Green cleaner and a shop vacuum were used to remove surface dust and grime from most of the cabling and metalwork. There was no evidence of any screws or other small parts loose in the chassis.

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.

4. Test Backplane and Ancilliaries for Shorts

With the power supplies disconnected from the backplane, I measured 780 ohms across the +5V line. This was eventually traced to the SYSID board, plugged into the backplane. With the SYSID board out, open circuit was measured. On the +2.5V line I measured around 1.5K which I did not consider a cause for concern at this point.

5. Evaluate Power Supplies

I heard from the donor that the system has been powered up within the last 12 months.

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.

Dummy Loads

Two things you don't want to do with these supplies: 1) don't put them on a variac and 2) don't run the high current sections unloaded, even though they have overvoltage protection. Dummy loads are the way to go.

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
+5V +5.256V
+2.5V +2.56V
+15V +15.27V
-15V -15.28V
-5V -4.98V

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.

6. Verify that backplane is configured correctly for boards (jumpers, wiring)

According to the 11/750 Installation Guide, the interesting jumpers that need to be installed are the bus grant jumpers on any unused CPU slots, and the baud rate jumpers.

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.

7. Install boards and power up without mass storage

After reinstalling the boards and connecting a VT131 terminal to the console port, I cautiously applied power. The memory configuration error light came on, indicating a problem with the combination of boards. On closer inspection it appears that the Nemonix boards are in fact 4MB boards, not 1MB. I removed them and moved the remaining boards to the right. After powering up again, the memory configuration error cleared. Yellow LEDs on the EMC boards glowed solid at first and then remained lit dimly after a few seconds. It seems likely that the lights are on solid at first because the memory controller runs through each memory board, in parallel, and initializes memory and memory parity bits.

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.

Reg Fail

Unfortunately while working on diagnosing the above, the 2.5V power supply failed. The REG FAIL light came on. After consulting the Power Supply Technical Description and applying the diagnostic flowchart, I concluded that it was a 5VB or 12V regulator failure and I pulled the 2.5V power supply and checked over the two regulator boards. I concluded that the electrolytic on the 12V output had gone open circuit, and all the other large caps showed excessive leakage. I am awaiting replacements in the mail.

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.


No output from any of the +2.5V Supply Unit. The PSU makes a loud squealing noise and the REG FAIL lamp is on.

Technical References

These are temporarily 'cached' here until I can resolve this problem.

H7104 Power System Technical Reference
H7104c Schematics

Test Conditions

Dummy loads connected to all lines. Boards removed from the system. Wires soldered to various points on the 2.5V motherboard allow inspection of voltages and signals.

Lamp and Switch Status

Keyswitch – ON
Power Lamp– ON
Circuit breaker – ON
Remote/Off/Lock – REMOTE
+2.5 FAIL – OFF

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 30–48VDC. 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 there’s 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.

Spare Boards

In the meantime, I ordered a spare console board, data path board and control store board to aid in fault diagnosis and to have on hand as spares.

2.5V PSU Status at 1/16/2010

Finally, having changed all the big caps on all the boards, and having spent hour after hour attempting to understand and fault-find the supply, I've given up and, in admitting defeat, have purchased another supply for a large and undisclosed sum. I wish I could have repaired the old one but it was frankly beyond me. At least I will have the parts in the old supply as spares should the 2.5V supply fail again.

As a result of swapping out the 2.5V supply, the cycling of the ACLO, DCLO and ~INIT signals also cleared up.

8. Console Problem Solved (1/16/2010)

Finally, with the new supply in place, I was able to continue fault-finding the 11/750. The console issue was finally traced to a multiple board failure. The L0002 Data Path Module board and L0004 Unibus Interconnect board (which hosts the console hardware) were both defective, and with board-swapping the fault cleared out and I got the double % prompt indicating that the on board microverify diagnostics ran OK. I'll need to take a closer look at both boards. Although I'd reseated all the gate arrays and PROMs, the problem may just be a poorly seated device on a board.

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.

Microverify Error %O with PC+2=0xF1

From the value of the program counter it is possible to determine the nature of the microverify error. Add 2 to the program counter and look up the value on p118 of the 11/750 VAX Maintenance Handbook. 0x000000EF+2=0x000000F1 which translates as 'Error in XB<31:0>'. By the way the 0xFF displayed after the program counter is the console halt error code which, from p117 of the VAX Maintenance Handbook translates as 'Microverify error', which of course makes sense.

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 %% 00000000 01 which signifies normal completion of the microcode verify test when initiated from the console.

9. Assemble TU58 Emulator and Diagnostic Tape Images

I located a number of 11/750-related TU58 images here, the most appropriate of which would appear to the the standard 11/750 console tape image (256KB).

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

Dumping the 11/750 Boot PROMs

I'd like to dump the boot PROMs to figure out what they are. The devices themselves, of which there are four, appear to be bipolar PROMs, including 74S571, 63S241 and Am27S13 devices. It seems likely that the Advin Pilot-MVP programmer at work will be able to read these devices. More research needed here I think, although it occurs to me that knowing the start location for each boot routine in PROM (see VAX Maintenance Manual) I could just examine each location in PROM from the console. This would become tiresome after a few lines. However, the 11/750 installation guide describes a way to determine what the boot device names are. Apparently if you dump the following locations, it will tell you. Use E/L to get the following values:

Address - Device - Address Device Letters
F20400 - Device A - 8FC04444 => DD - TU58
F20500 - Device B - 8FC0444D => DM - RK07
F20600 - Device C - 8FC0444C => DL - RL02
F20700 - Device D - AFC04455 => DU -

Other Diagnostic Things

I decided to look at the time of year clock to see if it was running. E/I 1B echoes the contents of the time of year clock which is expressed in 10ms intervals. Sure enough, it was zero, indicating that the clock was not running, probably due to a dead time of year battery. D/I 1B 1 puts a 1 in the time of year register. A few seconds later I examined it again with E/I 1B, and the clock was incrementing.

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.

Getting Emulated Console Storage Up and Running

I built tu58em from Don North as described above. The cable design I had from the web was wrong so I designed a new one based on the actual pins in use on the existing TU58 cable.

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.

BOOT58 Command File Dump

I've dumped the boot command files out of a console tape image. There are many of them, for different combinations of device and boot parameters. The listings might prove informative.

The listing file also contains the BOOT58 help text.

Here's an example of a boot command file for the RL02:
D/G 0 2 ! RL02 DISK

Update 2/28/2011

Suffered what looks like another console board failure while trying to load VMS boot images. I will take a closer look over the coming days, but the symptoms all look suspiciously like an L0004 Unibus interconnect board failure.

Update 3/6/2011

Powered up and tried again. The console problem was not evident so maybe this is a heat issue, or an issue with a poorly-seated gate array.

Update 4/8/2011

Powered up and tried again. The problem seems to recur after a few minutes of operation. Removed the RDM board - no change. Reseated the gate arrays on the L0004, L0003 and L0002 boards - no change. Ordered a new L0004 UBI board.

Miscellaneous Images

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

Related Pages

With the system basically stable it is now practical to add various peripherals to it. These steps are documented on the following pages:

Part 2 - TU80 Subsystem for the 11/750

Part 3 - LA120 Console

Part 4 - DELUA

Part 5 - Unibus Configuration

Part 6 - UDA50/RA82



Approximate Year







Thanks to Herb Johnson for helping me unload and get myself organized. This stuff is big and heavy and more than one person can deal with.

Thanks to Pat Finnegan for being the donor for this machine and for loading it onto the truck in Indiana.

Other Pages on this 11/750

Part 2 - TU80 Subsystem for the 11/750

Part 3 - LA120 Console

Part 4 - DELUA (Ethernet) and UDA50 Installation


Voltage measured on the time of year clock battery, confirming that the unit has indeed not been powered up within the last 100 hours (!)

11/750 Internet Resources

11/750's are quite well documented and many resources already exist on the internet. In addition to the documentation on bitsavers and Manx, I referred to:

Vax-11/750 Frequently Asked Questions By James Lothian

The Computer Refuge 11/750

11/750 Power Supply Issues (for pointers on dummy loads and links to power supply documentation)