Some time ago I collected a DECstation 220. This is the machine that succeeded the Rainbow. It uses an Intel 80286 processor and is DOS compatible. Mine, being a European version, has Olivetti parts inside.

The person I got it from used it networked to a MicroVAX 2000, apparently booting it off the MicroVAX 2000 using an early version of Pathworks called PCSA. He actually had two of these machines, he stripped one of them for parts and kept them as spares, disposing of the case. Very forward thinking.

My first attempt at powering it did bring up a screen of self test diagnostics, although it only appeared after a while. It displayed a pass for CPU, ROM, Memory Refresh and Keyboard Controller, but then it hung. I power cycled it but got nothing further out of it. When I opened it up I found some serious battery leakage had occurred.

I removed the battery and cleaned it all up, using a little bit of lemon juice to get rid of some of the blue stuff that would not otherwise come away. The result was this:

I have since bought a new battery and installed it, although I know a lot of people think that batteries should not be replaced as they will leak one day too. However, the clean-up did not resolve the problem, the leakage had done damage. The spare board also had leakage, which didn’t seem so bad, I cleaned that up too, but it didn’t work either.

I was at the point where there were no beeps, there was no video signal and the keyboard lights would come on and stay on. I put it away for a while and came back to it again recently, with a view possibly to passing it on to someone else. The trouble is I find it difficult to let a problem like this go. So I got my logic analyser out and found that the 80286 was getting a RESET every 10us. I then realised that the BIOS ROM Output Enable (OE) signal, which is active low, was never going low enough (it went to no less than 1.8V). I found that a transceiver driving the OE signal was being told to do the wrong thing. I eventually traced this to the battery damaged area where a damaged track was preventing a 74F04 (marked U97) from connecting to the transceiver. I soldered a patch wire in place (badly, I am not good at this). After I did this I found that the ROM OE signal was driven correctly and the ROM started showing sensible activity and the RESETs stopped.

This did not fix it though. There were still no beeps and no video output. I think at this point the BIOS was running but in a loop waiting for something to happen that didn’t happen.

More probing with the oscilloscope showed that another chip in the leak damaged area was behaving oddly, the signal was “blurry” and it looked like a grounding problem. In fact I found that the GND pin was not connected to GND on other chips. I tacked a patch wire to ground the chip.

Now when I applied power I got a beep, and the keyboard lights would also go out rather than stay on. But there was still no video signal.

I once again got the oscilloscope out and checked other chips in the damaged area for odd signals. I found a 74F573 (U45) that had inactive outputs when the inputs were active, and that were active on the spare motherboard. So I replaced that, in doing so I damaged a pad and had to add yet another patch wire. This did not change the result.

I found that another chip was behaving oddly too in the damaged area. This was a 74LS164 shift register (U60). It’s clock was permanently high, I struggled to trace its source, so I just went ahead and replaced it. However, I later traced its clock to a parallel output on an Intel 8742, so I think it may be related to the keyboard control, which I would expect to show up as a keyboard error in the POST. So I don’t think this is the problem.

However I noticed some odd signals on the data pins of the 8742, which after passing through multiple 74LS125 transceivers came to be connected to the data pins of the 80286. I could not tell though if the signals were coming from the 80286 or going to it. I don’t really know whether a signal like the one below is normal or not. Update: The display is 2V/div and the timebase is about 0.1us/div (can’t actually remember), the input was set to DC. The probe was set to 10x in order to keep its effects on the signal down.

This is where I am up to. I am now a bit stuck and I will ask on the classiccmp mailing list for advice.

Update: Some responses I got suggested it may just be transmission line effects and/or periods of bus idle, although I didn’t give enough information about how the oscilloscope was set to allow reasoned interpretation. I think the next step would have to be to use the logic analyser to get an address trace, match that to the ROM dump I have, and try to work out what the BIOS is doing. But I am not sure I have the enthusiasm to do all that work.