VT100 External Video Fixed

Posted on April 28, 2024 by rjarratt
External Video on VT100 Using a Video Converter After Replacing the DC012

I have been making progress on restoring the VT100 I acquired some time ago. The RAM is now OK and the keyboard interface is working. However, I was still not getting any output on the screen and I know that the NVRAM is not working. I have obtained a replacement NVRAM chip but I want to fix the video first.

When I started to look more closely, the first thing I discovered was that the fuse on the monitor board for the +12V supply was open circuit. Using a bench power supply with current limiting I connected just the yoke and gave the board 12V. There was a faint glow from the yoke and it drew about 100ma. On advice I temporarily used a 12V car bulb in place of the fuse in order to test how much current gets drawn when the monitor board is fully connected to everything. It drew about 1.4A and the voltage on the output side of the bulb was 6.9V, so there was no dead short.

I also tested the flyback transformer with a ringing tester. Most of the windings seemed OK when compared to a VT101 that I have. One of the windings still rings, but not as much as the VT101. These are the scope traces for the two flybacks:

I tried to test without the car bulb acting as a current limiter. However, the yoke filament did not glow and I fancied I could smell some burning, possibly coming from the flyback transformer, so I switched it off very quickly. I fear that one of the flyback windings may have failed, but I don’t know.

On further advice I decided to connect an external monitor to the external video output on the basic video board. I found an old LCD screen that works just about well enough with a little video converter device I have. I verified it worked first with my working VT102 and I got a display. However, when I tried it with the VT100 I did not get the expected image. On startup I got some random looking patterns, and when it had finished starting up I got a blinking column down the left of the screen. I also noticed the smell of a chip that is getting hot, but I couldn’t locate it.

I checked that the DMA was retrieving the right data from the screen RAM. This seemed to be OK and the right data was being presented to the character generator ROM. However, my logic analyser doesn’t make it easy to check the validity of the ROM outputs. I could see though that pressing keys altered the output of E10, the Video Shift Register. It seemed to me though that the DC012 was probably outputting what it was being given, as something did get displayed and it did vary a little depending on what keys were pressed.

It was while checking the data sent to the DC012 that I realised that it was E10, the Video Shift Register, that was getting hot. In fact after a few minutes it would be too hot to touch. The same chip on the VT102 does not do this. I tried replacing E10, but the new part also gets hot. I am still not clear about the cause of this.

After a while I realised that the vertical flashing bar was just the cursor being displayed and being stretched the full height of the screen. I imagined that perhaps the first line of characters was somehow being displayed repeatedly across all lines of the screen, except that the characters I typed did not appear on later lines. After asking on the Vintage Computer Federation forums for advice I realised that perhaps it wasn’t the first line of characters that was being repeated, but the first line of pixels. I tested this by typing some different characters that had pixels at the top of the character cell, sure enough those pixels appeared across the full height of the screen. So now I knew that it was the first line of pixels that was being repeated.

The next thing to do was to check the Scan Count being output from the DC012 Video Control chip. This seemed to be either all zeroes or all ones. On the working VT102 it counts up as expected. I concluded that the DC012 must be faulty. It could even be why E10 gets hot, although the DC012 does not get hot.

Turning again to the Vintage Computer Federation forums, a very generous member offered to send me two DC012 chips. I took out the old one, replacing it with a socket, noting that the DC011 was already socketed. This fixed the issue and now I have the external video working, as shown in the image at the top of this post. I noticed that E10, the Video Shift Register, is still getting very hot and the new DC012 is a little warm too.

The current situation is the following:

  • I still don’t have an image on the VT100 screen as I removed the monitor board and have taken it apart. I think the flyback transformer has failed, but I can investigate this a bit further, knowing that the video signal is now correct. I am not hopeful though, because although the DC012 was producing the wrong image, the video signal itself was correct.
  • The NVRAM chip probably needs replacing.
  • The Video Shift Register, E10, is still getting very hot and I need to work out if this is normal.

Posted in Retro-Computing, VT100 | Leave a comment

VT100 Keyboard Constant Clicking Fault

Posted on November 19, 2023 by rjarratt

In my last post VT100 RAM Fault I reported progress on fixing my VT100, getting past a RAM fault, but I left it with a fault where the keyboard constantly clicked the speaker. I knew the keyboard was OK because it works with my VT102.

The Basic Video Board communicates with the keyboard using RS232. There is a UART on the Basic Video Board and another UART in the keyboard. The firmware sends commands to the keyboard using a status byte that is described in the technical manual. The status byte controls the speaker click, the LEDs and the scanning for keypresses.

I wondered if the firmware was not operating correctly, perhaps trying to signal an error. I found a wonderful page that annotates the firmware really well. It looked like perhaps the firmware was getting into a loop trying to sound the speaker. The firmware uses a counter in the BC register to sound the speaker at the start and I could see from address traces that while it is doing this the vertical frequency interrupt is occurring. The interrupt routine saves the BC register on the stack and it looked like perhaps the RAM was not working correctly and corrupting BC. However some further analysis with the logic analyser showed that the RAM was working correctly at that stack location. While tracing the execution of the firmware I also found that it is detecting an NVRAM failure.

I moved on to look at what data the UART is sending out to the keyboard. I set up the logic analyser to capture the parallel inputs to the UART (labelled XD0-XD7 on the schematic) and triggered on the rising edge of LD XD. The data I saw being sent seemed completely reasonable. It initially sent 0xA0, which clicks the speaker on start up, and then it went into a cycle of sending 0x20 with the odd 0x60, which means it is turning on the on/off line LED and scanning for key presses. This seems perfectly normal and expected.

I then used the logic analyser on the UART in the keyboard to see what it was receiving. This data did not correspond at all to what the UART on the Basic Video Board was being asked to send, it was garbage. Clearly this implicated the UART on the Basic Video Board. I checked the components between the UART output and the final output on the keyboard port and they seemed OK.

Because I have jumped to incorrect conclusions many times before I decided I would do what I could to verify this. My Rigol DS1054Z oscilloscope is capable of capturing RS232 data. First of all I made sure I had it setup correctly by using it on a working VT102. I found that I needed to set a bit rate of 7866bps, I had to set the non-default polarity, and most significant bit first. With this I was able to capture reasonable data from the VT102, although it wasn’t perfect, the timing seems to vary a bit so I got framing errors after which the data would appear wrong for a bit and then correct itself. I also checked the clock signal to the UART on the VT102, it was variable, sometimes around 126KHz and sometimes 106KHz, which I guess accounts for the framing errors I saw.

I then used the oscilloscope on the non-working VT100. The clock signals to the UART mirrored those of the VT102, but the data captured by the oscilloscope being sent down the wire was completely different.

I also tried to use a HP4957A protocol analyser, but this wouldn’t let me set a custom bit rate, so I was not very successful with it.

At this point I decided I didn’t have much to lose so I replaced the UART (marked D3-6402-9) with another one.

I am pleased to report that this cured the constant keyboard clicking. So now I have two problems left. The main one is that there is nothing displayed on the screen, I don’t see any glow from the cathode on the CRT, so possibly there is a fault on the video monitor board. This will be the next thing I look at. The other problem is the possible failed NVRAM, but I think I will look at that if I can fix the lack of a display first.

Posted in Retro-Computing, VT100 | Tagged | Leave a comment

VT100 RAM Fault

Posted on October 1, 2023 by rjarratt

[Updated 14th October 2023]

VT100 Out of the Enclosure for Repair

I acquired a VT100 a while back. It was just the video unit, without a keyboard, but I have a couple of keyboards for my VT101 and VT102, so I would be able to use it once I had it working.

My first job was to inspect it, particularly the power supply and the video monitor boards. It looked like some parts had been replaced on the PSU and there was a track that had been cut. The result does not match the schematic, but a friend has a similar situation with his VT100, so I was not too concerned. I also found that the heatsink for one of the 7812 regulators (Z2) was not properly attached with a screw, so I added a screw.

I then decided to reform the two big capacitors in the PSU. My bench equipment only allows me to go up to 60V though, which they did without issue. Given that they were OK up to that point I decided to test the PSU as a whole on the bench with an artificial load, just to be sure the whole thing was working OK. The picture below shows the connector marked up for which output is which.

The PSU tested OK for voltage and ripple. Except the -23V output which went to -31V. However, I am told that this output is pulled to -23V by two Zener diodes D2 and D3, as shown on the schematic on page 14 (B4-C4) of MP00633_VT100_Schematic_Feb82.

The apparently unused pin H of the PSU board connector turns out to lead to a cut on the track and patch wires, so there is clearly an ECO that is not shown on the schematic.

I also decided to replace the electrolytic capacitors on the video monitor board, in the interest of avoiding damage to parts that are difficult to replace (especially the flyback transformer, although I don’t know if the capacitors could cause it damage if they were bad), and also in the interest of getting a clean stable image. I did not replace the non-polar capacitor mainly because they are hard to find. I also took note of this and changed C439 from a 7uF 6V part to a 100uF 100V part.

At this point I was ready to try turning it on. Of course it was a major disappointment that there was no life from it, but I guess not totally unexpected. Nothing on the screen, no beep, no LEDs lit up on the keyboard, nothing.

I went through a number of troubleshooting steps to trace the issue, following some troubleshooting steps in the Technical Manual. I could see that the DC012 video processor control chip was permanently asserting the interrupt line and not generating any DMA HOLD REQUESTs. I wondered if this might be because the firmware hadn’t got to the point of initialising it, perhaps because of bad ROMs. I dumped them with help from my friend at 9track.net (a device to allow different Chip Selects to be used) and they looked fine, matching the ones posted here. Only one of the ROMs is posted on 9track, I dumped the other three. The all the dumps plus the disassembly of the first one are here.

After disassembling the first ROM I used a logic analyser to see if the 8080 was executing instructions correctly. I was able to see that it was following the instructions in the ROM, so the 8080 CPU is fine. I could see that it was supposed to send the self-test status to the keyboard LEDs, but for some reason these would not light up on the keyboard. One of my keyboards has a suspect cable. I wasn’t sure if it was down to that, so I put the logic analyser on the UART to see if I could see what it was sending to the keyboard. I was able to see it sending the codes to light all the LEDs, then sending codes indicating the ROM tests and finally the RAM test. It never sent another code after the RAM test, so I concluded that the RAM test was failing.

Looking at the disassembled code I found the RAM test code and could see that it writes 0x00 and then 0xAA to every location, I think it also tests 0x55. After a few false starts in trying to observe the RAM test with my logic analyser I was finally able to see the reads properly by triggering on the rising edge of the MEM RD pin on the J1 connector. This showed me that the reads stopped at a particular address, indicating that the 2114 chip labelled E51 in the schematic was returning a A when it should be returning a 0.

Initially I misidentified this because I thought it was a misread of the 0xAA, however it turned out that it was a misread after checking that the initial 0x00 could be read back, it was reading back 0x0A. It is a bit suspicious that it was always returning 0xA in the lower nibble.

Once I replaced the suspect chip the RAM test started to pass. I could also see from my logic analyser that the interrupt routine which clears the vertical frequency interrupt is invoked at 60Hz. So the RAM test is now passing.

Plugging in the keyboard, I now get a beep and the ON LINE LED lights up. However a few moments later all the keyboard LEDs come on and keyboard beeps continuously. The screen also remains resolutely blank.

Posted in Retro-Computing, VT100 | Tagged | 1 Comment

Rainbow H7842 Finally Fixed

Posted on June 29, 2023 by rjarratt
Rainbow running again after PSU repair

I previously posted about the failure of the H7842 power supply in my DEC Rainbow. I reported that after replacing some parts I was getting an overcurrent detection in the -12V output. This was under bench test conditions using a bench PSU to power the startup circuit.

I did a lot of tests, comparing a working spare with the failed PSU, but I just could not find a reason for the overcurrent detection to be wrong. Strangely, that problem disappeared after a time. It has been suggested to me that the test conditions were not really representative enough of real conditions to be reliable, and that even an increase in temperature with the arrival of spring and summer might have been a factor. I decided to ignore the problem for now as it has gone away.

At this point I could try once more to see if the PSU would now work. As a precaution I used two 100W filament bulbs in series with the mains input as a current limiter, to make sure that things wouldn’t go too badly wrong if it didn’t work. I attached a dummy load to the 5V and 12V outputs. In a working PSU this causes the 100W bulbs to pulsate and never to go very bright. However in my bad PSU they shone much more brightly, there was no pulsing and the DC outputs stayed at zero.

I checked the supply to the startup 7812 regulator. It was only about 3.5V, so there was no way that the PWM was going to work or control the chopper transistor. In the same conditions this voltage was much higher on the working spare. I wondered if perhaps the startup transformer had some shorts. This seemed to be borne out after I lifted the diodes on the outputs of the startup transformer, because they tested fine.

However, on receiving further advice, I looked at the mains bridge rectifier. On removing it I found that it had two pins shorted together. When I tested the startup transformer with the rectifier removed and also all the diodes on the startup transformer output removed, the startup transformer output was 24VAC. So the startup transformer was OK. I think the rectifier must have been shorted when the main chopper transistor blew up.

I replaced the mains bridge rectifier with a new 600V part and the power supply started to work. I tested it first with the 100W bulbs to be sure, but when that went OK I took them out. With a dummy load the PSU had reasonable ripple and the voltages were correct.

I reassembled the machine and it ran perfectly. The picture at the top is of the Rainbow running once more on its original power supply.

I would like to thank the people who offered my so much advice, without whom I would never have got this fixed.

Posted in Retro-Computing | Tagged | 2 Comments

DEC Rainbow H7842 Power Supply Failure

Posted on November 20, 2022 by rjarratt
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 the E3c output is high and so it is shutting down the PSU. Tony’s schematic seems to have some errors on it in this area. Reverse engineering the circuit it looks to me like E3c has the ISense -12V- and ISense -12V+ as inputs, so the comparator marked E3d on Tony’s schematic is actually E3c.

So, the problem now is that there appears to be an overcurrent in the -12V circuit. This is being detected even when I use a bench PSU to supply the Vstart signal only by applying 15V to the input of the 7812 regulator on PSU Sheet 1 (page 2 of the PDF).

Posted in Retro-Computing | Tagged | 3 Comments

PDP 11/24 Progress

Posted on February 10, 2022 by rjarratt

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.

Posted in Retro-Computing | Tagged , , | 1 Comment

DEC Legacy 2021 – Windermere, 9th-10th October

Posted on October 10, 2021 by rjarratt

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.

Posted in Retro-Computing | Leave a comment

VAXstation 3520

Posted on September 20, 2021 by rjarratt

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:

KA60 V1.2
F..E..D..C..B..A..9..8..7..6..5..4..3..2..1..0
 5   01010004  L2003    4  ?  V1.3
1 SSC     00000001
2 DZ      00031200   ?
3 NI      58610770   ?
4 SCSI    00000901
5 SYS     00000001



08-E1,P1
0B-E1,P1
08

CPU08 >>>t 50
KA60 V1.2

MID  MODTYPE     ID    SLOT ERR
 0   01010001  L2002    9
 1   01020110  L2007BA  8
 2   01010108  L2001    7
 3   01020110  L2007BA  6
 4   00000000     *     5
 5   01010004  L2003    4  ?
 7   01010002  L2004    3

CPU08 >>>t 50 0
 0   01010001  L2002    9
1 QAM     00000001  V2.0
2 TQK70   00000001  V2.0
          CSR= 00001940
          VEC= 000000B0
CPU08 >>>show scsi

 ADDR   VMB     DEVTYP  DEVNAM   NUMBYTS  REV   CHAR
 -----  ------  ------  -------  -------  ----  ----
 5.0.0  DKA0    DISK    94191-1  663  MB  0136
 5.1.0  DKA100  DISK    94191-1  663  MB  0136
 5.7            HOST    SII-A

This means that the specification is as follows:

  • KA60-AA CPU Module (L2001).
  • 32MB memory (MS60-BA, or L2007-BA x2).
  • I/O Module (L2003).
  • Graphics base module (L2004).
  • 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:

KA60 V1.2
F..E..D..C..B..A..9..8..7..6..5..4..3..2..1..0
 5   01010004  L2003    4  ?  V1.3
1 SSC     00000001
2 DZ      00031200   ?
3 NI      19210770   ?
4 SCSI    00000901
5 SYS     00000001

 7   01010002  L2004    3  ??  V1.1-B
1 GFX     20153652   ??



08-E1,P1
0B-E1,P1
08

CPU08 >>>

I added the second CPU board, moving the memory board in slot 6 to slot 5 and putting the second CPU board in slot 6. Having done that I got this:

KA60 V1.2
F..E..D..C..B..A..9..8..7..6..5..4..3..2..1..0
 5   01010004  L2003    4  ?  V1.3
1 SSC     00000001
2 DZ      00031200   ?
3 NI      19210770   ?
4 SCSI    00000901
5 SYS     00000001

 7   01010002  L2004    3  ??  V1.1-B
1 GFX     10021112   ??



08-E1,P1
0B-E1,P1
0C-E1,P1
0F-E1,P1
08

CPU08 >>>t 50
KA60 V1.2

MID  MODTYPE     ID    SLOT ERR
 0   01010001  L2002    9
 1   01020110  L2007BA  8
 2   01010108  L2001    7
 3   01010108  L2001    6
 4   01020110  L2007BA  5
 5   01010004  L2003    4  ?
 7   01010002  L2004    3  ??

CPU08 >>>

So clearly I now have a 4-CPU VAXstation!

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.

Posted in Retro-Computing | Leave a comment

DECstation 220 Progress and Failure

Posted on May 2, 2021 by rjarratt

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.

Posted in Retro-Computing | 2 Comments

Bad DSSI RF72 Hard Disk

Posted on January 23, 2021 by rjarratt

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.

Posted in Retro-Computing | Leave a comment