VAXmate PSU (H7270) Failure

While I was using my newly working VAXmate the other day, it suddenly failed. I had left it running for a few minutes and when I came back there was a smell and the machine was not running. I wondered at first if it might be the filter capacitors in the power supply, but if these fail the power supply continues to work.

I took the machine apart and examined the H7270 PSU and other boards for any obviously blown components. However I could not find anything. I have since looked multiple times and still cannot see any obviously blown component.

VAXmate H7270 PSU

VAXmate H7270 power supply

My first step was to see if the input is being rectified. I found 300V across the two big smoothing capacitors, so, yes, the input is being rectified. The next step was to see if the switching transistor on the primary side was switching, and to see if it is working. I found that it is not switching, but after desoldering it and putting it into my Peak Atlas Component Analyser, it seemed to be working, so the transistor does not seem to be the problem.

My attention then turned to the NE555 timer that drives the switching of the primary side transistor. It is not doing anything and I discovered that it is not getting any voltage to operate.

This means that the current sense circuit on the primary side is detecting an overcurrent condition, which is shutting down the primary side. The causes of this can be multiple, but one is that the crowbar circuit is detecting an overvoltage and forcing a short on the secondary side that triggers the overcurrent condition which then causes the power supply to shutdown.

I have been testing the PSU with no boards attached, and an old IDE disk acting as a load on the 5V and 12V supplies. According to the Technical Description only these supplies are monitored for overvoltage. Any other overcurrent would be a short in one of the other supplies.

So, I have a PSU which won’t start, despite there being no visible damage that can account for the bad smell when it failed, and despite not being connected to any other boards, and only to a known good hard disk drive. The cause seems to be that a problem is being detected that shuts it down. I only have an analogue oscilloscope, and I can’t use it to diagnose a transient condition like this one. I am going to have to get a Digital Storage Oscilloscope that can be used for transient conditions like this. I want a more modern oscilloscope anyway, so I am going to get a Rigol DS1054Z after a friend recommended it to me and after seeing a positive EEVblog review. When I have that I hope to be able to investigate further.

For reference I have reverse engineered the PSU and done a couple of partial schematics. They are probably not drawn logically as I am not an expert.

The component numbers are assigned by me as they are not marked on the board, and I have posted images of the board with the components labelled. A few component numbers are actually named in the Technical Description and I have used those numbers.


Posted in Retro-Computing | 6 Comments


I acquired a VAXmate earlier this year. The VAXmate was the successor to the Rainbow. It is PC compatible and runs MS-DOS. It was the first commercial diskless PC, although mine came with an expansion box containing a Seagate ST225 hard disk. The machine uses an LK250 keyboard, that looks very similar to the LK201.


VAXmate running Sokoban

When I bought the machine I was told that although it had the keyboard, it did not have the cable to connect the keyboard to the machine. The cable uses a 6-way Shielded Data Link (SDL) connector at the machine end, and an RJ12 on the keyboard itself. I hoped to find another keyboard or to make a cable, but I ended up leaving it for a bit.

The first job was of course to inspect it, before powering anything on. The machine is not easy to work on though. The boards are all installed around the outside of the case and interlock so that it is not possible to remove just one board at a time. In the end I found the rear and left hand (as viewed from the rear) boards could be removed as one by pulling the connectors out of the right hand board and pushing it away a bit. The capacitors all looked OK. I also had to remove all traces of the rubber feet on the main unit as they had turned completely to sticky black goo. The pictures below show the innards of the machine.

My first attempt to power on the machine went well, it powered up and tried to access the floppy disk. I didn’t have a floppy disk though. The display showed an error (60), which is presumably some kind of keyboard error.

I took the disk out of the expansion unit with the intention of trying to using the David Gesswein MFM emulator to image it. It turned out that the disk is bad and all attempts to read it failed miserably. I opened the disk up to see what is going on and it looks to me like it can’t find track 0.

I took the machine to DEC Legacy in November and was able to test it with the keyboard that belonged to someone else. This confirmed that the machine works and that the keyboard I got with it also works.

I then managed to obtain a keyboard cable for an IBM Model M keyboard, as this has the SDL connector on one end. Unfortunately it has a PS/2 connector on the other end and my initial plan was to butcher the cable and put an RJ12 on it. But I decided that I should not do this to a relatively rare cable. So I got a more run-of-the-mill PS/2 cable with a female connector and decided to butcher that instead as an extension plugged into the IBM cable. This failed to work. I thought that this was because it turned out that the IBM cable only had 4 wires out of 6, however I later discovered a different problem and then found that my home-made cable is in fact fine.

In the end an LK250, with the correct cable, came up on eBay, so I bought it. Sadly this keyboard did not work, nor did my original keyboard with the cable. Having checked the cable was OK I smelt a different problem.

Testing the RJ12 end of the cable with the cable plugged in, I realised that the 5V supply to the keyboard was not working. I took the machine apart and traced the 5V supply, eventually reaching a fuse (marked F1 on the board, rated 2A). This fuse was open circuit, so the fuse had blown. At this point it dawned on me that my earlier probing of signals in order to make my own cable may have caused an accidental short and blown the fuse. The position of the fuse is marked on the picture below. It was hard to desolder the fuse because one end must be connected to large 5V plane that sucks all the heat away from the soldering iron.

VAXmate Board Keyboard Fuse Marked

VAXmate Board With Keyboard Fuse Marked

Having now replaced the fuse, both keyboards work and the machine works fine. I ran Sokoban on it, although I don’t seem to be able to remember how to get it to exit from the game cleanly.

Posted in Retro-Computing | 1 Comment

MUSL Compiler Builds a Simple MU5 Program

I have been slowly working on getting a MUSL compiler that targets the MU5 emulator, with the ultimate goal of compiling the MUSS source code to run on it. The first step is to build a cross compiler that works on Windows. A while back I switched tactic from building my own Flex/Bison compiler, to hand translating the MUSL compiler into C. I completed that translation a few months ago.

I then started testing the translated compiler, parsing some sample MUSL code. I found a lot of mistranslations, of course. I also found a couple of spots where I could not reconcile the code with the way it was supposed to work. A couple of the IF statements had to be inverted, I have marked these in the translated code with “/**/” and an explanatory comment.

I translated the MUBL module too, so that it would output a form of intermediate binary code, however I think I should not have bothered. This is because, more recently, I switched to parsing very simple programs and building an actual implementation of MUTL that targets the emulator.

Today I succeeded in compiling the following  program which runs on the MU5 emulator and outputs a simple “hello world” message.

*TLSEG 0 %FFFF %00010000 0 6;
*TLSEG 1 %FFFF 0 0 6;
*TLLOAD 1 0;
*CODE 1;
    $IN I;
    FOR I < 16 DO
        %F => CONSOLE.INTERRUPT; :: Reset console interrupt bits
        0 => TELETYPE.CONTROL; :: TTY output mode

The code is naïve and relies on a tweak to the emulator not to generate an interrupt when the teletype character has been written. Note also that the built-in SIZE function does not work, I have not been able to work out how it is supposed to work yet.

Posted in MU5, MUSS, Retro-Computing | 2 Comments

Teletype Model 33 ASR Ribbon Feed

In November last year I attended DEC Legacy 2018 and as usual I took along my treasured Teletype Model 33 ASR. I hooked it up as usual to the PDP10 simulator in SIMH to run DEC’s TOPS-20 operating system. You can see it working here.

During the event I noticed that the ribbon was not feeding correctly. In fact most of the time it was not feeding at all. Resulting in fading characters as the same bit of ribbon was used over and over again. A few of us had a look, and we could see that the feed pawl was not engaging properly with the teeth on the ratchet wheels holding the ribbon spools. However, we couldn’t really see why this was happening, it was a bit intermittent. I thought it might just be a lack of lubrication, but in any case I resolved to check it when I got back home.

I didn’t look at it for a while, and then recently I asked on the Greenkeys mailing list and the ever helpful Wayne replied with a couple of emails. It took me a couple more weeks before I could look at it, but I finally did so today. Following Wayne’s advice I checked the springs. At first I couldn’t see any springs that had come undone, but then I noticed a spring  under the arm of the feed pawl that was disconnected, the two arrows in the picture below show the detached spring and where it should be attached.


I removed the ribbon feed mechanism so I could fix the problem. I attached the spring again, which was a bit fiddly, lubricated the mechanism and then refitted it. The ribbon feed now works perfectly.

Posted in Retro-Computing | Leave a comment

DECstation 5000/240 With the TURBOchannel Extender

Recently I repaired the H7826 power supply in my TURBOchannel Extender. So now I wanted to get it working with the DECstation 5000/240 it came with. The trouble is, I don’t have the cable to connect the Extender to the DECstation. However, I found a 100-pin SCSI cable that works for connecting the two enclosures.

The TURBOchannel Extender also has a SCSI connector for the disks and the CD-ROM Drive. To use the SCSI devices you have to connect a separate cable. The TURBOchannel Extender cable is just used for TURBOchannel cards. In messing around with the TURBOchannel Extender I found that if I install a PMAD (network interface) card in it, this seems to prevent any other card installed in the Extender from being recognised. I have not worked out why.

I have now configured the machine as follows. In the main DECstation enclosure I have installed a PMAG-D (actually upgraded to PMAG-E as it reports a 24-bit depth, the D is only 8-bit), and TURBOchannel Extender option. In the TURBOchannel Extender I have installed just the video capture card, which Ultrix does not recognise (not surprising as I think it is an experimental card), and the RRD42 CD-ROM drive and the two RZ25 drives that came with the machine.

Sadly the RRD42 does not seem to work. It will take in a caddy and eject it when I press the button, but I have been unable to use it to read any CDs. This will have to go on my list to look at some day.

I installed Ultrix 4.5 on one of the disks that came with the Extender. Sadly the other disk gives hard error if I try to install to that one. So I now have Ultrix 4.5 running on the DECstation, using the Extender as it was intended. The TURBOchannel Extender cable is a bit redundant though as the only TURBOchannel card in it is not supported by Ultrix. I have NetBSD 1.5.3 on a SCSI disk in a Storage Expansion enclosure, I can’t really put this disk in the Extender because it is too big.

Unfortunately I do experience intermittent startup problems. Sometimes the LEDs will indicate a “memory slot 0 could not be initialized” error. Cycling power seems to resolve this.

Posted in Retro-Computing | Leave a comment

H7826 Power Supply Repaired

After a spell of concentrating on other things I have finally got round to looking again at the H7826 power supply from my TURBOchannel Extender. When I left it back at the beginning of the year I was waiting for parts for the 5019572 daughter board which controls the switching transistors. I posted the details here, including a schematic of the daughter board.

Once I had replaced the parts on the 5019572 daughter board I bench tested it in isolation. I had to make sure that Vcc was above the ON threshold which is between 15V and 17V. The board drew what appeared to be a reasonable 20mA and the 555 started oscillating. So I reinstalled the daughter board.

With the 5019572 daughter board back in place I found that the 555 was not oscillating. This was because its Vcc was 0V. It looked like there might be a blip on Vcc when applying power, but I don’t have a DSO so I couldn’t be sure. Checking Vcc for the daughter card as a whole I found that it went up to about 15V on applying power, but then it almost immediately dropped to 0V. After removing power it stayed at 0V for a bit before jumping back up and finally decaying slowly.

This told me that the daughter board was either receiving a shutdown signal or it was sensing an overcurrent. A bit more probing showed that it was the shutdown signal. I traced this to another daughter board on the secondary side, labelled 5019574.

I removed the 5019574 daughter board and reverse engineered its schematic, which is reproduced below:



I tested the board’s current draw on the bench at 5V and it looked OK. While I was at it I also reverse engineered the schematic for the 5019576 daughter board, which is right next to it, as they are both involved in monitoring for shutdown conditions. This schematic is reproduced below:


None of the parts on these two daughter boards appeared to be bad. I did replace the LM393 on the 5019576 daughter board because during testing it had appeared to get hot, but I later realised I had made a mistake with how I had connected up the board, so I may have replaced it unnecessarily. However the PSU still would not work, the fans would twitch on applying power and that was all. One of the electrolytic capacitors on the 5019574 board had measured a bit high on ESR, and it was also looking a bit brown as if it had been subjected to a lot of heat, so I replaced it. But still the PSU continued not to work.

Then I realised that I could not trace one of the tracks connecting the 5019574 daughter board to anything on the main board. The track was visible but did not seem to be electrically connected to anything. I noticed corrosion on the track (this power supply is not in the best condition). I asked a couple of friends who have this power supply to confirm where this track went. Once I knew where it was supposed to go, I soldered a wire to the back of the main board to replace the broken track.

H7826 Repair of Corroded Track

Wire to replace a corroded track

This seemed to do the trick! I connected a load module from a MicroVAX 2000 and now the fans spin and there are voltages on the outputs. I checked the ripple on the 5V and 12V outputs and that was good. The LED does not seem to work, but the PSU powers up a hard disk and a PMAD-A card installed in the TURBOchannel Extender, so I think it is all working.

Now I need to find a cable to connect the TURBOchannel Extender to the DECstation 5000/240. I have found a 100-pin SCSI cable which fits but I don’t know if the pinout is correct so I dare not try it.

Posted in Retro-Computing | 3 Comments

Flocoder FLIP Now Processes Its Own Source

I am at the stage with my MUSS restoration that I can process the Flocoder FLIP source code with my own implementation of FLIP written in Flex and Bison.

My MUSL compiler can’t process all the Flocoder source files yet though, for a couple of reasons.

The first is that some of the source files appear to have too many END statements. I need to look into this to see if my understanding of the grammar is incorrect. However, these problems occur in files that I don’t think I need in order to re-create FLIP, so I will defer investigation. I may hit problems again when I try to build the MUSL compiler sources.

The second is that there are some elements of the syntax that are context-sensitive and can’t be parsed with Bison without some additional work. There are actually a couple of areas where this does not currently work. First, one of the Flocoder modules declares both a type and variable with the same name. The second is where addresses of procedures are declared, these create a syntax ambiguity which needs additional semantic processing. These problems are solvable, but I have not looked at them yet.

My next steps are to start generating C code from MUSL, but I think that to do it correctly I am going to have to resolve the context problems mentioned above.

Posted in MUSS, Retro-Computing | Leave a comment

Flocoder Flip Progress

I haven’t been doing much in the vintage computing arena recently, but I have finally got around to finishing off my crude implementation of Flip. The source code is up on GitHub.

My first attempt didn’t work very well. I was not ordering the boxes well and produced invalid MUSL because I used too many labels and GOTO statements. In the end I decided to reverse engineer the original Flocoder source for Flip. I created textual versions of some of the critical charts, you can see them in the source code (doc021 and doc031). The control structures represented by the charts didn’t look too easy to turn into normal structured code without GOTOs, so in the end I decided to take the easy path and code it with GOTOs just exactly as represented in the original Flip source charts.

My version of Flip can now take doc031 from the source code and produce the MUSL source from it. Furthermore, my initial MUSL parser is now able to parse the output from Flipping doc031, without any hand modifications to the Flip output.

The next step is going to be to try processing the other doc files and check that my parser can parse them all. After that I will try to get my MUSL parser to produce C code, so that I can generate a program that implements Flip from the Flocoder source.

Posted in MUSS, Retro-Computing | Leave a comment

MUSS Source Code Now Available

I have received qualified permission to publish the MUSS source code that was recently recovered, as free and open source software. It is available here.

I have also made a bit of progress on the MUSS restoration. My implementation of FLIP is improved but still not quite there yet. I also have a parser for MUSL, which parses the output of my FLIP implementation for one of the FLIP source modules, with a little hand modification before parsing it.

I have created a page on MUSS where I will report more about MUSS and its restoration.

Posted in MUSS, Retro-Computing | Leave a comment


I have now got a crude implementation of the Flocoder Flip program written using Flex and Bison. It can take a Flocoder file from the MUSS sources and extract what I hope is compilable MUSL code. The code is on GitHub.

I am not 100% sure that the code is valid as I have taken a very naïve approach to the code generation stage. Every BOX except the start box is labelled, and every BOX ends with a jump to the next box in the FLOW sequence. It does not attempt to merge consecutive BOXes.

However, I am hoping that this is enough to take the original Flocoder source for Flip and turn that into MUSL that I can then compile. The next step, which I have just started, is to create a MUSL to C compiler that will generate C from the Flocoder source for Flip, so I can get a version of Flip working in C. If I can do that then I should be able to process the Flocoder files using the proper code for Flip and compiling those to C as well.

Posted in MUSS, Retro-Computing | 4 Comments