The badges are on their side because this was installed in a vertical enclosure.
A couple of days ago, I received a request to format some RX50s in one of my Rainbow machines. So, I got this one out to check that it still works. I was happy that it just powered up fine. I went off to search for some RX50 diskettes to check the floppy disk drive with. When I came back the machine was silent. It had powered itself off. There was a vague burning smell and the circuit breaker on the back had popped.
Not knowing if there was perhaps a short in the machine or a problem in the power supply, I disconnected the fans, the floppy disk drive, the hard disk drive and, probably foolishly, I applied power again to see if the machine would work. At this point there was a bang and a flash in the power supply.
On opening up the H7842 power supply I found that one of the transistors had completely disintegrated. It looks to be the main switching transistor.
Given that before the transistor blew up there had clearly been another failure somewhere else, I tried to find the original failure. There were no obviously damaged parts, so I just probed around near the transistor for any parts that were open circuit or short circuit. I found a diode connected to the base of the transistor that appeared to be short circuit. So, I decided to lift one end to check it. As I de-soldered one of the leads, the diode broke in two. So clearly the diode was either damaged by the failure of the transistor, or it was the cause of the failure. This is the diode:
Tony Duell has reverse engineered the schematic for this power supply here. The transistor that failed is the one on sheet 2 labelled BUV48A and the failed diode is the one connecting the base of the transistor to the transformer and in parallel with a 2.7R resistor. I obtained a replacement BUV48A. I couldn’t identify the diode, the markings looked like they said “D610” but I couldn’t be sure, so after advice from the cctalk list, I replaced the diode with a UF4007. I also discovered that the 7812 regulator (sheet 1 of the schematic) had failed, so I replaced that too.
On further advice, I tested the control board in isolation by using a bench power supply to put 15V into the 7812 regulator mentioned above. On a working PSU you can see the PWM (Control Module Sheet 2 on the schematic) producing a signal that turns the chopper transistor on and off and the current draw from the PSU is about 87mA. However, the PWM was not producing a signal on Output A and the current draw on the bench PSU was about 140mA. Furthermore the 5.1V reference voltage was actually 9.75V. So the PWM was faulty and I replaced this with a UC3527AN.
Despite replacing the PWM, it still did not operate. I discovered that the Shutdown pin on it was being asserted. I traced this to an LM339 comparator (E3 on Control Module Sheet 1 of the schematic). The output was incorrect given the inputs.
I replaced the comparator. However, one of the outputs is still incorrect and this is currently where the puzzle lies. The output marked E3d on the schematic should be 0V, instead it is 4.6V. Both inputs are close to 0V, and very similar to the voltages on a working PSU.
If I lift the 4K7 pull up resistor on the E3d output. When I did this the current draw went down to 87mA and the PWM operated correctly. However, the resistor tests correctly at 4K7. A voltage of 4.6V would make sense if the diode was always on. I lifted the diode connected to the output of E3d and that also tests correctly as a diode. As the two components on the comparator output seem to be correct I am not sure what the problem could be to cause the comparator to have a high output because that would only seem possible if the pull up resistor was shorted or the diode was shorted, neither of which seems to be the case.
A few years ago I was given a PDP 11/24, followed a few months later by the cabinet and two RL02 drives. Not long after, once I had first tried the PSU with a dummy load, I attempted to power it up with just the CPU (M7133) and Unibus Map Module (M7134) installed, no memory. It worked right away and I got a console prompt. Sadly though, after entering a couple of commands on the console, there was a slight click and the machine powered itself off.
The H7140 PSU had failed, and a long saga began. This is a very complex PSU (for me at least). I had a lot of help from the ClassicCmp community. It turned out that the Bias and Interface board was not supplying 5V to the control logic. One of the first things I did was to replace the 555 timer, which had failed, when I powered it on again there was a bang and more stuff broke. I made various attempts to fix it over the years, but then put it to one side.
Recently I was told of a company, not far from me, that repairs power supplies, including vintage stuff. So, having realised that this was a repair that was probably beyond me, I decided to take the plunge. The PSU finally came back to me a couple of weeks ago, unfortunately having suffered some damage during shipping, partly because I had not put back the covers before sending it off.
During previous attempts at repairing the PSU I have had it partially working and I noted a smell from somewhere in the CPU enclosure when it was powered up. Inspecting the boards I noticed a rather mottled looking capacitor on the M8722 memory board:
I replaced this and the one next to it with 40V rated ones as I couldn’t find axial ones rated at 20V or 30V (they seemed to be marked with both voltages). I also replaced the air filter at the front of the CPU enclosure, as it was crumbling.
I reassembled the machine with the M7133, M7134 and M8722 modules and with the newly repaired PSU. When I powered it up the fans turned but no LEDs lit up on any of the modules. The DC ON light was flashing, suggesting the voltages weren’t right. Furthermore a red LED on the M8722 was on and the burning smell came back. I powered it all off and traced the smell to the M8722, it seems to be coming from some other capacitors rated 8uF, they all measured about 5.5 on the ESR meter except one that measured 0.8 (the middle one in the picture below). My guess is that the odd one out has failed short and is pulling down the DC voltage, causing DC ON to flash and the module to show the red LED.
With the M8722 removed the smell goes away and the DC ON light is steady. So the M8722 is faulty. However, none of the LEDs on the M7133 light up either, which suggests the M7133 is not happy too.
A few days later, I decided to connect a terminal to the Serial Line Unit (SLU) to see if there is any life in the CPU still. While doing so I fixed a few problems with incorrect screws, so that it all re-assembled properly with the proper covers fixed correctly. However, the power supply then failed to switch on at all. I didn’t hear the relay click when I closed the circuit breaker. This also happened when I was first trying to repair it a few years ago. I think there may be a dry joint in the input assembly, and perhaps the movement from when I tried to sort out all the fixings affected the bad joint.
So I have now sent the power supply off once more to the company that repaired it, to see if they can find the problem in the input assembly.
After a long wait we finally got to do the next DEC Legacy this weekend. It was started in 2010 and is run on a semi-regular basis and it is something I look forward to every year. There were fewer people this year as some people could only attend remotely, but it was great to see many familiar faces.
MicroVAX II with VT220, Teletype and VAXstation 3520
As usual, the first thing I saw was Matt’s van:
Matt brought a PDP 11/84 which was of course the star of the show:
Matt’s PDP 11/84 With RA60, RL02s and RK05
The Back of Matt’s PDP 11/84
RA60 Drive and Disk Pack
Matt’s PDP 11/84
I decided to bring less stuff this time because I always bring too much. So I kept it to the following:
A MicroVAX II with a VT220 terminal.
A Teletype Model 33 ASR connected to SIMH running TOPS-20.
A VAXstation 3520, configured as a 3540.
A DEC 2000 Model 300 (aka Jensen).
The David Gesswein MFM emulator.
I first got the VAXstation 3520 going. I have installed PHIGS and ran the demo program. Craig showed me some of the DEC Windows example programs. It was interesting to see how the ICO program really slowed down when the PLAID program was also run and made a bit bigger. It was an amazing contrast to see the same ICO program running on the Jensen, where it ran massively faster.
Later I ran my user mode DECnet router on my laptop while Matt run a SIMH VAX router on his laptop and we networked from my VAXstation to his PDP 11/84 running RSX. Matt has a program written in Coral that draws fractals using ReGIS. We ran it from a DECterm session on my machine and it displayed perfectly. Sadly I didn’t get a picture of this. To get to this point we had to get around the fact that the machine didn’t seem to see the network. On Matt’s suggestion I toggled the thinwire/AUI selector switch and that seemed to do the trick.
I ran the TOPS-20 emulation on my laptop and connected it to Teletype using reverse Telnet via a DECserver 90M and a Westermo Current Loop converter. We ran some simple programs in BASIC-PLUS-2.
My MicroVAX II would not start up. I found that the RD54 was not spinning up. I tried various taps on it to make it go but nothing worked. Craig suggested twisting it in a circular motion and this did the trick. After that the MicroVAX II ran nicely.
Bob brought an RD54 to give me. He said it has RSX on it so I brought along the David Gesswein MFM emulator in order to image the disk first. The disk seemed to work first time and we imaged it. I will try the disk in a PDP 11/73 I have at home.
Chris and his Dad spent a lot of time with Jensen trying to find out why his wasn’t working by comparing it with mine, which does work. Mine wouldn’t start at first, it seems the disk was not spinning up. Again Craig worked his magic and got it spinning. In the end it seems Chris’s machine had a combination of bad RAM and bad SCSI cable. We didn’t get it fully working, but I think they know how to get it working now. I learned from Chris’s Dad that the Jensen is called that because one of the managers responsible for it was mad on cars and had a Jensen!
The event was livestreamed, I think the links are here:
Stream from Day One
Stream from Day Two
Thank you Mark for organising this year after year and for arranging for some interesting talks. I am looking forward to seeing more people in person next year and maybe I will be able to bring my PDP 11/24.
I have just acquired a VAXstation 3520. This is a 2-processor machine, but I got a second processor card with it from another partially complete 3520 to make it a 4-processor machine and really this makes it a VAXstation 3540.
I booted it up to the alternate console and used the console to list the configuration. This is what I got:
Q-bus Adapter Module (L2002) with TQK70 controller attached.
2 RZ56 SCSI disks (663MB each).
It doesn’t list the graphics output module (L2005), but an L2005-AA is installed. I also have an L2005-AA from the partially complete 3520, so I have a spare if needed. After reseating the L2005-AA I get this instead:
Now it was time to install VMS. At first I installed VMS 7.3 from a CD-ROM because I had some networking difficulties to net boot it. The installation procedure recognised the machine as a VAXstation 3540.
However, I then checked what the contemporary version of VMS would have been. The machine was released in January 1989 (wikipedia) and according to this the version of VMS should be 5.1-1. The closest I have is VMS 5.4, so I decided to install that.
This time I decided to try to get the networking to work so I could install VMS 5.4 over the network. I had a problem with thinwire (which is too slow anyway) so I tried thickwire. This is where I had an unusual problem. Normally on an AUI connector on a front panel, the connector is male and has the sliding clip. This one is male but has the protruding lugs instead. This meant I couldn’t connect it to my AUI-RJ45 adapter, nor could I connect it to the thickwire cables I have. I had to take the lugs off the adapter, and then I could use it. This worked for a while but then stopped working while copying some data from the boot node.
In the end I had to use CD-ROM again. I used the alternate console to install VMS 5.4, and I now get this:
$ SHOW CPU/FULL
CPU type: VAXstation 3540
Multiprocessing is ENABLED. Streamlined synchronization image loaded.
Minimum multiprocessing revision levels: CPU = 3 FBIC = 1.
Default CPU capabilities:
QUORUM RUN
Default process capabilities:
QUORUM RUN
PRIMARY CPU = 08
CPU 08 is in RUN state
Current Process: *** None ***
Revision levels: CPU = 5 FBIC = 1.
Capabilities of this CPU:
PRIMARY QUORUM RUN
Processes which can only execute on this CPU:
*** None ***
CPU 11 is in RUN state
Current Process: *** None ***
Revision levels: CPU = 5 FBIC = 1.
Capabilities of this CPU:
QUORUM RUN
Processes which can only execute on this CPU:
*** None ***
CPU 12 is in RUN state
Current Process: *** None ***
Revision levels: CPU = 5 FBIC = 1.
Capabilities of this CPU:
QUORUM RUN
Processes which can only execute on this CPU:
*** None ***
CPU 15 is in RUN state
Current Process: SYSTEM PID = 0000008E
Revision levels: CPU = 5 FBIC = 1.
Capabilities of this CPU:
QUORUM RUN
Processes which can only execute on this CPU:
*** None ***
$
So it recognised a VAXstation 3540 with 4 CPUs.
For the network interface problem I swapped the I/O module and the I/O panel to see if I could get the it to work, but it didn’t work at all. I put back the originals and they worked again, but I think they might be a bit suspect.
Next I tried to get the graphics working, instead of using the alternate console. I tried with an old Viewsonic LCD display that supports sync-on-green, but I couldn’t get any output. Then I realised that I didn’t have the graphics cover installed, and the graphics frontplane seems to have earthing contacts all around its edges. With the graphics cover installed I was able to get an image and I booted into DECwindows. However, the image quality was too poor for the text to be readable, although the monitor does match the spec of the VR295 monitor at 1280×1024 pixels. I think it is a sync issue and in text mode there is some coloured ghosting of the characters.
The diagnostic LEDs on the graphics frontplane also show a value of 2, this seems to mean a faulty expansion module, but this may be normal as there is no expansion module.
I recently turned once again to trying to get the DECstation 220 working. I have the original motherboard and a spare one. Both had battery damage and neither one works. The spare actually works less well than the original but many of the tracks seem to be in better condition, so I have been able to use it to partially reverse engineer the schematic, which I have been incrementally improving as I go along.
I last looked at the machine in 2017 when I left it with a corrupted video. I had discovered that it is a re-badged Olivetti M250-E and that there was a jumper which allowed me to install a VGA card in one of the ISA slots. I obtained an ISA VGA card that used the same chip, a Paradise PVGA1A.
This however gave me the same corrupt video pattern I was getting before. At least this suggested that there is no fault with the VGA side of the motherboard.
A friend found a service manual for the Olivetti M250. This says that the POST puts out a code on the parallel port. I found this to be the case here too (remember this is the later M250-E). It was putting out 0x49. This means that it is passing checkpoint 9 but failing on checkpoint 10, which is a simple test for the 80286 protected mode. More on this later because I first wanted to fix the video output.
The video output was corrupt because there were no writes to the video memory. This seemed to be because the MWRN signal on the PVGA1A chip was never going active. I traced this to a 74LS125 chip (labelled U204). I had previously replaced this chip because it seemed to be faulty, but I now discovered that one of the pins was not properly soldered. After fixing the soldering I started to get video output and this is what I got:
So it was now stalled on the simple protected mode test. I think this is the state of the machine when I first received it and powered it on.
So now I needed to resolve the protected mode test failure. The test involves setting protected mode, checking the machine status word to see that it is enabled, and then returning back to real mode. It seemed implausible that it could be failing to write the machine status word as the CPU is running, so it could only be the reset back to real mode that was the issue.
After asking around on the cctalk mailing list, I discovered that the 286 cannot exit protected mode without a reset. Therefore, the test is writing a marker value to the CMOS non-volatile memory to tell it after the reset that it was doing the protected mode test, and then it provokes a reset through some trickery with the peripheral controller. The peripheral controller is an Intel 8742 (labelled U10). Eventually I found a broken track between the peripheral controller and one of the custom gate arrays (it is called a GA99 and is labelled U4). After repairing the track it got past the protected mode test:
As can be seen from the screenshot, I got a failure further into the POST. I sometimes also got random different errors, such as
I can press F1 on the keyboard and get past the various errors. The best I can get is this:
I tried connecting the floppy disk drive but it just hangs on the check for floppies. It could be a faulty floppy disk drive as no lights came on. I haven’t looked into this much because of all the previous errors, which I want to fix first.
I have not been able to resolve the other errors despite fixing a few more broken tracks. My suspicion is that the Chips and Technologies 82C206 is not being addressed properly when the CPU tries to read and write to its various registers. I tried my logic analyser (HP1630D and HP1630G) on the 82C206 to see if it tries to read or write the DMA Page Registers. After fixing one address line trace I can see it use the XA lines to address 0x80, 0x84 and 0x86, which suggests that line XA0 on the 82C206 is not connected correctly. I did some testing on the XA0 line, which is again driven by the 74LS125 chip marked U204, but it seemed to be operating correctly. Of course, I cannot exclude that other address lines are incorrect making it look like it might be trying to access the DMA Page Registers when in fact it might be something else.
I started to look at the other address lines, but then the machine started getting this:
Unrecoverable Power-Up Error
And it would not even beep on power up.
So after several weeks of trying, I have given up on this machine. I have a partially reverse engineered schematic should anyone want it.
I have a number of RF72 hard disks. These are 1GB DSSI disks (DEC rather grandiosely called them Integrated Storage Elements, or ISEs). Most of them work well, but I have one that will not spin up. The console firmware in a VAX 4000-500 does not see the disk if I do SHOW DEVICES. I decided to see if I could work out why it won’t work.
Faulty RF72
I have removed the drive module to see if I can find a fault that I can fix, the picture of the board is below. The drive module uses a Motorola 68000. The blue connector on the right connects to a ribbon cable coming from the head-disk assembly (HDA) for the actuator and read/write, and the 8-way socket half way down the board and towards the left supplies power to the spindle motor. The power is driven by the large MPM3003 power transistors that can be seen at the top of the board. There are a lot of surface mount components, if one of these turns out to be faulty then I could be stuck as I don’t have the means to replace them reliably.
Faulty Drive Module for RF72 DSSI Disk
Clearly the disk has not been treated well because one of the locking clips on the DSSI connector on the left of the drive module is missing. There are some dents and scratches on the HDA itself too. The shock mount assembly is also distorted, so it must have taken a heavy blow.
RF72 With Physical Damage And Distorted Shock Mount Assembly
In order to be able to test the disk on the bench I needed to get power to it. These disks do not use the normal 4-pin Molex connector used in PC disks. Instead they use a 5-pin connector, a friend identified it as part of the Molex Mini-Fit range. The 5th pin is “Power OK” signal and appears to be a 5V signal. So I made the little cable below to connect the disk to a standard PC power supply. Note that the 5V pin on the PC side goes to both the 5V pin on the DSSI side and also to the 5th pin to provide the Power OK signal. I tested this cable successfully on a known good RF72 disk drive.
Male PC to Female DSSI Adapter Cable
Having got the drive module on the bench I did some tests and found the following:
One or two of the electrolytic capacitors have a fairly high ESR, but I found this to be the case on a known good drive module too.
When I apply power there is a click as if it is trying to spin up the disk but the fault light comes on immediately and nothing else happens.
The bad drive module will not work if I put it in a working RF72. It fails in the same way.
The drive module is not sending power to the motor. Looking at the power transistors (MPM3003), there is no signal on the gate pins.
There is clock activity on the MC 68000 on the drive module.
A possible issue with the obvious physical damage is that the ROM could have become unseated. So I re-seated it, and while I was at it I took the opportunity to dump the ROM, the image is here. There is a timestamp in the image of 17-MAY-1991 10:12:41 at address 0x6830. The re-seating did not make any difference.
I have not tried putting a known good drive module on the HDA of the bad disk just in case something in the HDA is damaging the drive module.
Clearly more investigation is required, I think the CPU could be working because the Ready LED does come on briefly and you can hear an attempt to start the disk. Possibly the DSSI interface is not working because the drive module is not being recognised by the VAX console firmware.
A few years ago I acquired a KDA50, which consists of 2 modules, the M7164 and the M7165, an RA72 disk, two RA70 disks, an RA60 disk drive, an operator control panel (OCP) and some big cables, with one I/O bulkhead for installing disks and controller in separate cabinets.
KDA50 M7164 Module, with W2 and W3 jumpers lifted
KDA50 M7165 Module, with W2 and W3 jumpers lifted
RA72 SDI Disk
RA70 SDI Disks
RA Operator Control Panel
I/O Bulkhead and Internal SDI Cables
External SDI Cables
KDA50, SDI Disks, OCP and Cables
The controller and the disks use SDI, the Standard Disk Interconnect, which was part of the Digital Storage Architecture, and allows controllers to connect to large system disks (large for the time anyway). SDI allowed disks to be connected via long cables, so the disks could be housed in separate cabinets. SDI encoded signals serially, so it seems to be an early pre-cursor to SATA. SDI appears to date from the early 1980s.
I decided fairly quickly that I was unlikely ever to have the time and resources to get the RA60 going so I passed that on to a friend. The other stuff sat in my pile for a long time and I kept promising myself I would look at them one day. Well one day finally arrived a couple of days ago and I decided to get everything out and see what works.
To begin with I brought the disks in from the cooler storage area and allowed them to warm up to ambient temperature overnight before doing anything with them at all. I first decided I would see if the disks spin up when powered up outside the machine, by connecting them to a regular PC power supply. The disks did not spin but I saw some LED activity. I was not too disheartened because I thought that perhaps they might need to be connected to the KDA50 controller before they do anything, and that did indeed turn out to be the case. It turns out that they really need to be attached to the KDA50 controller before they will do anything.
So I needed to get the KDA50 installed in a machine. I wasn’t sure which machine to use. I decided to try the VAX 4000-500, mainly because it is handy. This turned out to be a poor choice. I think when I first got the KDA50 I may have installed it in this machine and it appeared to work, it displayed a cycling pattern on the LEDs of both modules, which indicates that it is not talking to the host yet. This turns out to be normal until you actually boot an operating system.
However, before installing the KDA50 again I decided to check the KDA50 User Guide. I found that both boards in the set have two jumpers, W2 and W3 that are supposed to be removed in a Q22/CD slot. I checked the enclosure manual for the VAX 4000-500, it is a BA440, and all the slots are Q22/CD. Having not checked for this before, I asked on the VCF forums for advice. The jumpers are present by default, presumably because the KDA50 is for an older generation of VAXen with a serpentine Q-Bus. I think I may have been lucky the first time, possibly because I had a TK70 with a dummy card in the CD slots before the KDA50. Unfortunately the jumpers are soldered in and not the type with a header, so I had to desolder them. Rather than remove them completely though I desoldered only one of the leads, lifted the link while bending it out of the way and finally putting a little bit of insulating tape over the holes left behind.
With this done I installed the boards in my VAX 4000-500, I got the cycling LEDs and the following from the firmware console:
I think the “?” for the UQSSP Disk Controller is because there was no actual disk attached.
The next step was to connect the disks. It was at this point I realised that the BA440 enclosure isn’t really designed to be used with SDI hardware. There are no molex power cables to get power to the disk drives, there is nowhere for the OCP to go and no connection for the OCP to the CPU. The VAX 4000-500 requires a separate enclosure for RA-series disk drives, this is confirmed in the manual. I realised that I would have to switch to my MicroVAX 3400, which is housed in a BA213 enclosure. I hadn’t switched this machine on for quite a long time, so I was a little concerned as to whether it would work. I needn’t have worried, it powered up fine.
I installed the KDA50 in the MicroVAX 3400. I then had to remove the DSSI disks, the DSSI media faceplate and the DSSI OCP before I could install the RA72. The problem was how to get power to the RA72. The RA72 uses 4-pin molex power connector, and the 3400 uses DSSI power connectors “natively”. The TK70 tape drive uses a little adapter cable (part number 17-01937-01) to convert from DSSI to the ordinary 4-pin power connector, so I took the TK70 out. Sadly it meant I could only test one disk at a time because I couldn’t find a splitter cable. Finally I installed the RA OCP and connected it all up, with the disk connected to the KDA50 by Port A. Unfortunately I don’t have the RA media faceplate and I didn’t bother to remove the internal cables from the I/O bulkhead at first, so the setup looked a bit ugly but it was functional:
I am not entirely clear about all the buttons on the OCP and without a media faceplate I don’t have the labels to know for sure. The OCP is shown in Table 1-4 of the BA213 manual. The bottom button halts the CPU and puts you back to the firmware console.
When I powered it on I got the following from the firmware console:
This was very encouraging and I was able to boot VMS from a boot node and verify that the disk is OK.
I tried the two RA70 disks next. I had to swap the mounting rails round though so that the end of the disk with the SDI and power connectors faced the front of the machine. One of the disks worked and one did not. The curious thing is that the two RA70 disks showed up in the console like this:
>>>sh uqssp
UQSSP Disk Controller 0 (772150)
-DUA33 (RA70)
and like this:
>>>sh uqssp
UQSSP Disk Controller 0 (772150)
-DUA64 (RA70)
I don’t know where the names DUA33 and DUA64 came from. I know the firmware has some SET HOST/DUP commands, I have used them with my DSSI disks to change things like that, but those commands don’t work with this controller and disk combination, not even if I try SET HOST/DUP/UQSSP. I feel it must be possible but I don’t know how.
The MicroVAX 3400 is back to using the DSSI disks, but the KDA50 is now permanently installed in it too. I would like to find the RA media faceplate for the BA213 enclosure that goes over the OCP. This is part number 70-24534-01 and is also described as a ‘BA213 RA DISK OUTER PLATE ASSY’. I would also like to find a couple of 17-01937-01 adapters to convert the DSSI power connectors to standard 4-pin power connectors.
Recently I fixed the power supply of my VAXmate, but found that there was a problem on the monitor board, which may be what caused the power supply to fail in the first place. My suspicion immediately fell on the flyback transformer, which is a common failure in vintage screen displays.
I removed it and tried doing a ring test on it to see if there are any shorted coils. Here is a picture of it, with the pins numbered, as close as I can tell, according to the description in the Figure 14-4 of the Technical Description.
VAXmate flyback transformer from the monitor board with pins numbered
My probing with a multimeter suggests that pins 1-2-3-7 form one winding, and pins 5-6-8 form a second winding. This does, however, correspond to the pin numbers shown in the Technical Description.
My ring tests showed good ringing between the following pin pairs:
1-2
1-3
2-7
3-7
5-6
5-8
Where the ringing looks like this:
Good ringing from the flyback transformer
I also saw some poor ringing between the following pin pairs:
2-3
1-7
6-8
Where the ringing looks like this:
Poor ringing from the flyback transformer
I can’t be completely sure that the poor ringing means the transformer has failed because I don’t know how the transformer has been wound, and it could be a low number of turns in the particular part of the winding.
I have a MicroVAX 3100 Model 95 that I acquired some years ago. At 32 VUPs it is one of the faster MicroVAXen.
From the front with RX33 and TZ30
Showing 32MB of installed memory
Some time ago I stopped using it because memory modules would suddenly stop working. At the time, I checked the power supply and some of the voltages seemed to be a little out of tolerance, in particular the output marked as 5.1V seemed to be producing 5.3V. I put the machine to one side because at the time I had little knowledge of repairing power supplies.
Recently I decided to take another look at the power supply with a view to getting the machine up and running again, given it is such a comparatively fast machine. I checked the ripple on the outputs but what I saw were spikes. The spikes seemed to reduce in amplitude after a few seconds. It turns out that I was measuring the ripple with poor technique, but I don’t know what the original ripple was now, because I replaced the majority of the electrolytic capacitors before realising my error.
I decided to replace any vaguely suspect electrolytic capacitors, which included the two big smoothing capacitors as one had a high ESR and the other appeared to be bulging slightly. I discovered that one of these would not fully discharge, which I found when I tried to measure its ESR after having had it powered on. Thankfully the meter had some protective diodes, which now need replacing.
After replacing the suspect capacitors I excitedly put it all back together, only to find that it would not power on. It turned out, that following some other sparks I managed to get from the not fully discharged smoothing capacitor I had ended up frying the UC3842N pulse width modulator. Fortunately I had a spare on hand (UC3842AN), replacing it fixed the power supply, and also seemed to resolve the problem of the capacitor not discharging.
Sadly, I also managed to break the connection to the power LED out to the front of the PSU, so now I won’t have that working.
After resolving my measurement mistakes the ripple on the 5V and 12V outputs was about 20mV and the voltages seemed to be right. So I put the machine back together again.
Unfortunately it seems that one of the memory modules is not quite right because the firmware reports an error:
KA51-A V2.6, VMB 2.1
Performing normal system tests.
74..73..72..71..70..69..68..67..66..65..64..63..62..61..60..59..
58..57..56..55..54..53..52..51..50..49..48..47..46..45..44..43..
42..41..40..39..38..37..36..35..34..33..32..31..
? Test_Subtest_40_06 Loop_Subtest=00 Err_Type=FF DE_Memory_count_pages.lis
30..29..28..27..26..25..24..23..22..21..20..19..18..17..16..15..
14..13..12..11..10..09..08..07..06..05..04..03..
16 MB RAM, SIMM Set (0A,0B,0C,0D) present
Memory Set 0: 00000000 to 00FFFFFF, 16MB, 32768 good pages, 0 bad pages
Error: SIMM Set 1 (1E,1F,1G,1H)
SIMM_1E = 16MB ?? SIMM_1F = 16MB SIMM_1G = 16MB SIMM_1H = 16MB
Memory Set 1: 01000000 to 01FFFFFF, 16MB, 0 good pages, 32768 bad pages
Total of 32MB, 32768 good pages, 32768 bad pages, 112 reserved pages
Tests completed.
However, VMS seems to think everything is OK.
$ sh mem
System Memory Resources on 10-MAY-2020 13:24:53.80
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (32.00Mb) 65536 21316 42491 1729
So I am hoping the machine will now work reliably.
In previous posts I have been describing my attempts to find a fault in the H7270 power supply of my VAXmate. After a long time studying and testing it I finally found the fault. It was a shorted diode (marked D24 in my reverse engineered schematic) on the secondary side that was part of the +28V supply to the monitor board.
The reverse engineered schematics are here. Note that they probably still contain errors, especially on the secondary side.
H7270 Primary Side
H720 Secondary Side
The pictures with the part labels are here.
VAXmate H7270 Power Supply – Primary Side With Parts Labelled
VAXmate H7270 Power Supply – Secondary Side With Parts Labelled
The problem was that the power supply did not appear to start at all. There was no blip of the fans, no clicking from repeated attempts to start etc. However, with an oscilloscope it was possible to tell that it was attempting to start, but shutting down after only about 20ms, with the SCR (D19) on the primary side detecting an overcurrent. The trace below was taken by lifting R32 and powering the UC3842N (E3) from a bench power supply with the mains still coming in through the AC inlet. It shows the SCR triggering.
However, I am not clear why the SCR was taking so long to trigger, in the trace the 15V peaks on the Q1 source have been going for about 15ms, so quite why it triggers the SCR only after that time is not really clear to me. It seemed to me that the peaks on Q1 source were not causing the SCR to trigger, but it turns out that they must have been the cause.
There didn’t seem to be any problem on the primary side, so on the advice of several members of the classiccmp mailing list I checked the secondary side more carefully. It was clear that the secondary side crowbar was not getting triggered, because this is the trace:
I desoldered and tested the rectifiers on the secondary side, and they tested fine. However, the +28V supply for the monitor board uses a rectifier constructed of discrete diodes (D23 and D24), and it turned out that D24 was shorted. I have replaced both of them to be safe.
It was a bit of a problem to get to the failed diode because it is under the large heatsink. I had to remove the heatsink, but I ended up doing it twice and the second time ended up damaging the vias a bit, so I didn’t completely remove it.
I also replaced capacitors C54, C55 and C56 in the secondary side as they had a high ESR, two of these are part of the +28V supply. Along with a few others that had a marginal or high ESR.
The complete list of replaced parts on the PSU is in the list below:
C10, C33, C50, C51, C54, C55, C56, all because of a high ESR.
D24, the shorted component.
D23, just in case as it is paired with the failed D24.
E3, a UC3842N, replaced with UC3842AN, but only due to errors damaging the original.
I was a bit concerned as to why D24 had failed. As it drives the monitor board I examined it. I could not see any visible damage, and it does not appear to present a short circuit. I checked the electrolytic capacitors on the video module and I found 5 where the ESR is marginal. They were all 15uF 16V parts, and they are marked in the picture below. Number 4 has a better ESR but I decided to replace it anyway since all the others have become marginal.
VAXmate Monitor Board With Replaced Capacitors Marked
I reassembled the machine and powered it on. It made some reassuring beeps and a few lights came on, but there was no image. A few moments later I noticed a burning smell, so I quickly powered it off. It seemed to me that the smell was coming from the monitor board, so I disconnected it and powered the machine on again. It seemed to work (apart from the video display of course), the diagnostic LEDs did not indicate an error, the floppy disk drive was accessed and it seemed to react to keypresses. There was no more burning smell.
It is clear that something has failed on the video module that caused the power supply to fail. It seemed as if the burning smell may have been coming from the flyback transformer. If that is the case then I suspect that this machine will never work again as I am unlikely to find a new flyback transformer. I took the monitor board out again and another physical examination does not show anything visibly wrong. I wasn’t completely sure that the EHT lead was making good contact with the anode of the CRT though.
I would like to acknowledge the help of all of the following people from the classiccmp mailing list for helping me to find the problem in the power supply. In alphabetical order they are:
Matt Burke
Rob Doyle
Mattis Lind
Plus others on the mailing list who preferred not to be named, but they know who they are.
Rob's Old Computers 