Developments!

The courier broke the base on the VT510, but the unit works great!

I had to fabricate an MMJ to MMJ cable. I used 6-core telephone wire from Maplins, and two normal phone jacks. Each phone jack underwent simple surgery to allow them to fit into the funny MMJ jack socket. The wires were hand-crimped into the jacks using a razorblade and a hammer. A continuity test with a multimeter on both ends of the cable proved successful, and use of the H8571-J to connect the terminal to a DS10L's serial port worked first time! Yay for small victories!

For the AlphaServer 2100 itself, Peter in Ireland has been incredibly helpful recently. He measured the voltages at the OCP connector during use:

1. 12V when system is on. 0v when system is off. 

2. 5.2V when system is on. 0v when system is off. 

3. 0V  

4. 5.2V when system is on. 0v when system is off. 

5. 0V  

6. 5.2V when system is on. 0v when system is off. 

7. 3.5V when system is on, dipping momentarily when reset is pressed. 

8. 4.8V when system is on, varying when the display changes 

9. 4.8V when system is on, varying when the display changes. 

10. 0.5V when power switch and door interlock are engaged, otherwise 2V

When I did the same, I found that my pin 7 was 0.3V, corresponding to the permanent SYSTEM RESET message on the OCP. This (to cut a long story short) allowed us to conclude that my existing two IO boards were faulty. He's been having fun himself, getting his second CPU to show up in VMS but that will come later in our story.

Shortly after concluding the IO boards were dead, the third IO board arrived and: it worked! It showed TEST CPU messages on the OCP, then TEST MEM messages! Hoorah!

Then FAIL MEM! Ah. Bugger.

I tried every combination of CPU and memory board with the new IO board, and concluded the following:

• the original CPUs are dead
• the original memory boards are dead.

The new CPU is the only one which will allow the OCP to show TEST CPUs/MEM etc. But all memory boards cause the FAIL, and the machine will go no further. 

Peter very kindly offered to send some spare memory boards (2x128MB). I have a very good feeling about these!

STOP PRESS: I've just been told there are some more AlphaServer 2100 components available in Bristol, and I'm off to pick them up today! This includes 1x B2040 CPU (5/300), 1x B2022-FA 512MB memory board, IO board, 2x PSU, OCP panel, Fans and control board, remote ports board.

With this + Peter's memory, SURELY we can now breathe some life into this thing!

Keyboard and terminal serial adapter

To complement the AlphaServer, I've acquired a DEC LK450 keyboard with a PS2 connector. It arrived pretty filthy, but cleaned up nicely, and works fine when tested on a Linux box:

Also bought a DEC H8571-J DB9 RS232 to MMJ adapter:

This will be used by a DEC VT510 which is also due soon. Hopefully it won't be here for too long before I actually have a use for it...

New CPU arrives...

and STILL no difference in behaviour. This (much less dusty) B2040 (EV5/300) CPU causes the system to behave like the non-SYSTEM RESET CPU i.e.: no OCP wakeup, no report of NO MEM INSTALLED when the memory is removed, etc. So: now two CPUs behave like this, the other shows SYSTEM RESET. Sigh.

I noticed that the replacement IO board was pretty beaten up, and finally noticed that it was actually missing a capacitor on the rear. This isn't affecting anything so far, but is now unlikely to be kept except for parts if a working system is ever forthcoming.

Wondering whether the original IO board's DALLAS DS1287 RTC clock chip had run out of juice, I scratched off enough of the epoxy covering to expose the pins and measured it: 2.80V

So, that's likely enough juice to get the system working. So WHERE is it failing?

Because the replacement IO board (B2110-AA) is so beaten up, I decided to order another IO board from Ebay. I am singlehandedly keeping the courier market alive...

If that one doesn't help things, time to look to the three remaining boards: the 54-23151-01 remote ports board, the 54-23180-03 OCP board and the 54-23260-01 fan control module.

Then there are the cables... To get the SYSTEM RESET / NO MEM INSTALLED OCP display, all that is needed is the OCP cable from the IO board to the OCP module. So that seems OK.

The disk cables can't be required to work to get the SRM running. The remote ports cable links the IO board to the serial ports, keyboard ports etc. block. This would obviously be required to view the console output (assuming it isn't being channelled to VGA, but that will come later), but I can't see it being required to be connected for SRM initialisation. Either way, I've tried it connected and disconnected, and no change.

Roll on the next IO board...

DALLAS DS1287 chip examined

Following the directions on the excellent: http://www.mcamafia.de/mcapage0/dsrework.htm page, I  exposed the internal pins on DALLAS DS1287 RTC chip on the spare IO board to see if the battery had died. It measured a healthy? 2.89V (should be 3.00V). So I suspect that's not the problem on this board. I used a craft knife, cutting away carefully at the pin positions until I exposed enough to cut them.

New backplane arrives...

...and no change in behaviour. Poop.

Meanwhile, I've had some interesting conversations with Peter from Ireland who also has an AlphaServer 2100 (among other items), and he's filled me in on a couple of things plus described some of his own issues:

• PSU labels: the top LED is labelled AC OK and the bottom LED is labelled DC OK.
• SYSTEM RESET only appears very briefly after the reset button is pressed

• His machine previously had some power/fan issues, which would sometimes lead to nothing appearing on the OCP at power up, and no boot. This was normally fixed with another power on. Subsequently replacing the IO board appears to overcome this, but the CPUs and memory have also been changed since then.

• Running an EV4 4/275 CPU module with an IO board running EV5 firmware leads to "FAIL I/O_00 0004" being displayed on the OCP. (I think this is also what you see when the FSL firmware boots, but I'll need to recheck the docs).

• He has 2x 5/300 CPU modules, which both register OK in SRM, but his VMS currently only sees one. Both pass with P (rather than F for Fail) in the SRM tests, but whichever one is in slot CPU1 results in the ID of ?????-? being shown. 

• Like a previous suggestion from a reader of this blog, he has suspicions that the IO board could cause problems if the battery/realtime clock had died. On the IO board, this is the DALLAS DS1287 and he wonders if perhaps surgery such as this could solve it? 

I have ordered 1x 5/300 CPU module from Ebay thinking that this is the next most likely component to have failed. If it turns out to the be the battery on the IO Boards, then hey, I'll have 3x CPUs for VMS to ignore.

Rust-B-Gone

The computer with a water feature.

After 2 balls of wire wool, half a bottle of vinegar and most of the skin of my fingers, the rust is almost entirely gone from the rear and card cabinet:

Shiny!

Shiny! 

Shiny!

In other news, the new PSU works fine along with one of the old ones in dual mode. Huzzah! Also, a replacement backplane on its way from Ireland. Let's see if that makes a difference. The backplane, that is, not coming from Ireland.

If that doesn't have any change on the system behaviour, I think we're going to have to have a difficult conversation with the CPU modules.

'New' IO board arrives...

But gives exactly the same results: CPU A shows SYSTEM RESET, CPU B shows nothing. Hmm.

So what other circuit boards do we have in play that can be replaced?

Card Cabinet:

• 2x 5/300 CPU boards (known difference in behaviour, but both get warm)
• 2x 512MB boards (system knows when both are missing)
• backplane board
• already swapped-out IO board (2 boards, exactly the same behaviour - I suspect the boards are OK)
• Remote Ports board (serial, keyboard, etc. I missed this off the earlier list of components. However, I get the same OCP display regardless of whether this is connected or not.) 

Front cabinet:

• Fan Control Module board (fans spin OK and don't cause system shutdown)
• OCP board (Display works, Power & Halt buttons have LEDs which work. Reset button measured for switching behaviour) 
• StorageWorks bay (can likely be completely ignored until the SRM boots)

The visible rust damage is much more pronounced towards the rear of the machine. So is corrosion damage more likely to be on components towards the rear? The backplane board doesn't seem to do very much, other than provide IO and expansion slots, but there's at least one large chip on there. Each of the above components has been removed and had its connectors cleaned at least once. The exception being the backplane, which only has receiving slots that I can't work out how to clean... Perhaps it's time for a gentle compressed air dust blower for the backplane. Other than that, time for a replacement?

One other angle could be the cables. Ignoring the EISA cable to StorageWorks, and the IDE? cable to the floppy, the IO board has two main cables: the OCP connection, and the Remote Ports connection. We know the OCP cable is good enough to enable the OCP to display NO MEM INSTALLED and SYSTEM RESET, so current assumption is that it's probably OK.