The AlphaStation 500 is a workstation from Digital, circa 1996. Mine is a 500 MHz model and has an Alpha 21164A processor (aka EV56). And the way it boots is weird.
On your common-or-garden PC, there has always been some kind of ROM chip. It holds a piece of firmware known as the BIOS. This ROM chip is available at a well-known location in the processor’s address space (remembering that any PC processor boots up in 16-bit, 8088 compatible mode, with a 1 MiB address space, just like an IBM PC 5150) and the processor just starts executing code in it after reset.
The Alpha (or at least this AlphaStation 500 – although I think they mostly worked like this) is different.
↫ Jonathan ‘theJPster’ Pallant
A great read, but a little bit over my head considering I’m anything but a programmer or developer. Still, even I managed to get the basic gist and learn quite a bit from this article, and especially the part about how the AlphaStation uses a little jumper to tell the SROM exactly which stream of boot code to send to the processor is fascinating. I’m not sure just how unusual the Alpha’s way of booting is, but I’d at least never heard of it.
Hmm. A DEC Alpha should boot straight into firmware. There were two: SRM (the “native” firmware for OpenVMS) and ARC (used to launch Windows NT). You can boot into Linux from either one of them. The system does first load the SROM as described but only long enough to find out where the firmware is and jump into it.
Perhaps the NVRAM on this machine has been wiped and it does not know where to jump.
As I recall (very rusty), the machine will also default to the mini-console if it cannot find a screen or keyboard. So, that could also be the issue.
Perhaps there is something of use in here… (it describes working with the mini-console for example)
https://manx-docs.org/collections/antonio/dec/MDS-2000-01/cd1/ALPHA/AXFRMPGA.PDF
I really enjoy the article. Reverse engineering stuff is a fun challenge if your into that sort of thing. It can be hard enough to resurrect old hardware even when nothing’s wrong. But getting hardware to work when you aren’t familiar with it and you don’t know what’s wrong is especially difficult since you lack a working system to swap components with and compare it against.
I think I have the exact same Matrox Millenium G200 card in storage and last tested it worked fine…I thought to donate it to the author until I discovered the author was in the UK. International shipping from the US is just astronomical.
I happen to have an LSI SAS card, but the model is probably very different and my guess is that it would be incompatible with the AlphaStation.
Awesome that you would send him your card but he should not really need it. An Alpha should boot into SRM (BIOS) with pretty much any PCI video card that supports VGA. Any PS/2 keyboard should do as well. As cool as the Alpha platform was, a lot of it was pretty much standard PC ecosystem fare. It is just an ATX PC with an exotic CPU.
You should be able to get into SRM even if things like storage and RAM are dead or missing. It will tell you what it thinks is wrong with the machine. You should not have to mess with serial communication unless there are no graphics. I REALLY wish he had said if he had tried another video card or not. I do not think there is anything special about the Matrox (other than it is a cool bit of Canadian high-tech history). Once you boot into an operating system, drivers will be an issue but, for getting into SRM or ARC, VGA is all you need.
The RAM is nothing that exotic either if it turns out that it is dead. Just standard ECC DIMMs.
If SRM has been wiped from Flash somehow, it can be loaded again but that will require talking over serial. That is, if it does not just boot right up with a working video card. He is obviously very capable so I am sure he must have tried another video card. Right?
I may have an LSI SCSI card out of an Alpha but I think it is differential SCSI.
LeFantome,
I don’t know what drivers are available for the OS, but it’s good to know that you could at least boot with standard VGA. Maybe it would do higher video modes with VESA like many linux distros did?
If everything really is dead as described, it would concern me that whatever killed all the components is still a danger.
Recently I was unable to boot two identical headless x86 NAS. The power came on with leds and fans full blast, but they didn’t respond otherwise over the serial header (normally it does). I couldn’t find a CMOS reset pin. I removed the CMOS battery, which didn’t help. I disconnected all drives and periferals, no help. It was only when I removed the DDR ram that it reacted differently. It failed to boot without the DDR, but once I reinstalled it everything came back to life. The thing is I don’t actually suspect the DDR in both NAS devices was making a bad physical connection – I just think some kind of reset got triggered when the bios detected a hardware change.
This solution wasn’t obvious to me, especially since I thought removing the CMOS battery would be enough, but given that many BIOS vendors revert back to stock settings when you change RAM, I guess this could be a different way to make the BIOS perform a reset.
I wonder if a similar procedure could work here. Did the AlphaStation have a BIOS that persisted settings? Something like overclocking that might explain memory running hot? I hope the author makes progress because it’s nice to get closure about what was wrong, haha.
Yes, Alpha systems had firmware (BIOS) that persisted settings. There were two. SRM was the regular firmware for things like VMS. Then there was ARC for Windows NT. There was a setting in SRM, “ostype”, that you set to “NT” to make it load into ARC. If you used Windows NT, it was occasionally an issue that these settings would be reset and you would get dumped into SRM at boot and have to configure this setting again (a show stopper if you did not know about it). All you needed for SRM to boot was VGA and a PS/2 keyboard. I think it would even boot without the keyboard.
Once in NT, you had access to all the normal Windows NT drivers. As I recall, you had about the same driver support for things like video cards and SCSI on Alpha as you did on PC. This was Windows NT 4.0 and earlier so that was not a lot but still quite a lot more than what shipped with AlphaStations. I had a cobbled together low-end Alpha system at home for a while and, other than the motherboard, it was all standard PC stuff that I had pulled out of a Pentium or even 486. It was in my old 486 case for sure.
I do not recall any overclocking options on Alpha. They were already crazy clock speeds. Alpha systems were hitting 500Mhz when 100Mhz was top end on PC. As above though, I do remember settings getting lost.
It will default to serial if the settings are missing, or if it was previously set to serial (ie it won’t automatically use a vga card just because you installed one).
Many alphas also have a set of diagnostic LEDs on the board which will light in sequence to indicate problems, sometimes accompanied by a series of beeps if a speaker is connected.
It’s more likely that some of the capacitors on the board are dead and in need of replacement. I have a couple of machines like that which don’t get to the LED flashing stage.
He detailed the jumper that selects for regular or serial boot. So, I do not think that is it.
Capacitors are a good guess. You should be able to tell by visual inspection. It is also possible that a leaking capacitor has damaged something else.