Halleluja! We have installed OpenVMS!

The CD ROM read errors from the previous day were down to SCSI (mis?)configuration. I had the cable attached to the storage array in two places, and I think that must have been incorrect. Removing the second connection allowed the OpenVMS 8.4 Alpha installation CD ROM to run to completion. This took a couple of hours to run, the CD ROM being a very slow unit.

Once it completed, the machine rebooted and came up by itself, offering the VERY long-awaited experience of the login prompt:

BUT, the fun's not quite over:

a) the clock on the I/O board must be faulty because it never remembers the date from boot to boot. OpenVMS prompts for the date at each startup, meaning it can't be left alone to boot. DALLAS chip surgery is required. See earlier posts for details.

b) I need to know if the EV5 CPUs have any life in them. Getting either the existing I/O card upgraded for EV5s or getting one of the several other ones I have working for EV5 is the next challenge...

c) ...

New I/O card and CPUs => SRM boot!

Over the last few months, I'd received a couple 'new' I/O cards but had no further success booting. My thinking is that perhaps *all* my I/O cards have EV4 firmware and won't boot the EV5 CPUs.

So I bit the bullet and picked up two EV4 275 Mhz CPUs from Ebay. I stuck one in, along with a VT510 terminal and voila, life!

The SRM console came up!

I viewed the devices present with show dev and saw the CD ROM showing as dka600. I put the Alpha 8.4 install disk in and was told the firmware was out of date:

I obtained the firmware 5.3 disk image and burned it on a macbook pro using Disk Utility. Selecting the defaults resulted in a successful firmware upgrade.

Having upgraded the firmware (via the CD ROM), I eagerly slapped in the install disk (also burned on the macbook pro) but found it continually causing read errors during boot. Progress, but no cigar...

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.