I have a nostalgic itch for DEC things. So at RetroFest 2025 in Swindon I was handed this very dead AlphaStation 500 in case I might be able to revive it. Although, looking at the previous owner’s account, my chances are very slim indeed.
Frankly, having taken a look inside, I can’t blame it for having no will to live. The quality of design and attention to detail is abysmal. Things always feel it when they are not designed with love.
As you may recall, Alphas have eight bootstrap images in ROM, which is called Serial ROM (SROM) because the images are serialised as bit streams. The image to load at reset is selected by fitting a jumper to one of a series of eight jumper positions on the mainboard. One of them is a normal boot image, the others are for diagnostics.
On the AlphaStation 500, these jumper positions are numbered J11…J17 and J19. For whatever happened to J18, the board designer obviously thought it was alright. Who cares. Let’s just assign random designators, nobody’s going to diagnose this thing anyway.
To really drive this point home, the jumpers are located so as to make them inaccessible:
Squeezed tightly between the RAM and power connectors, they sit directly underneath a partition wall. Compare that to the DEC 3000 AXP, designed just three years earlier:
DEC 3000 Model 800 AXP SROM selection jumpers
Diagnostic LEDs have been a ubiquitous feature of DEC computers since the PDP series. Their purpose is to indicate start-up progress and failures before the console output is available. This could be a simple row of 8 red LEDs that you’d read in binary, or a pair of TIL311 hexadecimal digits for that sophisticated high-end look.
The AlphaStation 500 has got neither. Why bother? If it ain’t working, toss it in the bin — such was the design trend at the time. Or better yet, give it to a scrapper so that the bloody thing gets the treatment it deserves and will never surface again.
In an ironic twist of fate, though, the 500 got those signals broken out onto a pin header connector compatible with the Flamingo LSM — Lights and Switches module. Was it really cheaper than 8 surface mounted LEDs?
Now, my other Alpha just happens to be a Flamingo. I borrowed its LSM, plugged it in, and it worked. It shows DE when I switch the machine on. So there is some life in this AlphaStation.
Here is the LSM connector pinout when viewed as in this picture, i.e. with the front of the machine pointing to the right:
| bit 0 | bit 3 | bit 5 | bit 6 | GND | GND | GND |
| bit 1 | bit 2 | bit 4 | bit 7 | +5V |
I believe bit 1 is on pin 1 on the connector. The two unlabelled pins above are for the HALT button on the Flamingo.
Bits [7..0] represent the diagnostic code at 5V TTL levels so can be sampled with a voltmeter or a logic analyser.
The machine is equipped with two Dallas modules: a DS1287 real-time clock and a DS1225AD-150 nonvolatile SRAM. Each has a non-rechargeable battery cell inside the package.
In a strong FU message to the owner, these are soldered onto the mainboard. Not socketed, like on earlier machines. So what do you do in 3–5 years when the batteries go flat? That’s right — toss it in the bin! Have you got a computer system with a non-socketed Dallas module? Leave a comment below!
The year is 1996. DEC has less than two years to live. Top management is frantically selling off assets to make what’s left of the company palatable for Compaq to swallow. Quick, cheap, and with a PCI bus — that must’ve been the design brief given to the handful of engineers still lingering about after a series of layoffs. Poor and sad AlphaStations rolling off the production line struggle to understand why they were made at all.
Okay, digression aside, let’s see whether we can find out what’s wrong with this machine. It stops with the DE code on the diagnostic LEDs. According to AlphaStation™ 500 Series User Information (P/N EK-ALPH5-UI.B01), it’s the second step of the initialisation sequence:
It hangs without detecting an error, as errors would have displayed their own codes in the E0–FF range. I’ve probed RAS and CAS signals on the memory but have seen no activity. So either the fault is in the CPU/system interface, or there’s more going on than what the documentation implies.
SROM image number 7, which can be selected by jumper J19, is described as a ‘No init mini console’. With that, we could expect to see some output on the SROM debug port J24, as long as the code truly does not attempt to initialise anything.
Alas, neither Jonathan nor I could see any activity on the TX pin. However, another owner of a dead AlphaStation 500 advised us that we’d missed a crucial step. In order to set the baud rate, the SROM code needs to know the CPU clock frequency. On some Alphas, it is hardcoded. On AlphaStations, the normal procedure is to initialise the Dallas RTC periodic interrupt at the rate of 1024 Hz and measure the CPU clock off that. The DS1287 RTC sits on the X-bus, which is attached to EISA, which is in turn attached to PCI, which is behind the Digital Semiconductor 21172 core logic chipset. So pretty much the entire system needs to be initialised for the CPU to be able to find out what frequency it’s running at.
Obviously, the ‘No init’ console would not be called “no init” if it had to do all that. Instead, it times the CPU clock off the RX signal on the SROM debug port. The operator should type ‘U’ (55 hex), which would send a series of alternating zeros and ones, acting as the time reference for the SROM code.
Indeed, the no-init console springs to life on receiving the ‘U’:
Bret SROM V2.05 000003ea MHz Console SROM>
This tells us two things.
Bret SROM V2.05 000001f5 MHz Console SROM>
Okay, we seem to be getting somewhere…