We’re used to there being an array of high-end microprocessor architectures, and it’s likely that many of us will have sat in front of machines running x86, ARM, or even PowerPC processors. There are other players past and present you may be familiar with, for example SPARC, RISC-V, or MIPS. Back in the 1990s there was another, now long gone but at the time the most powerful of them all, of course we’re speaking of DEC’s Alpha architecture. [JP] has a mid-90s AlphaStation that doesn’t work, and as part of debugging it we’re treated to a description of its unusual boot procedure.
Conventionally, an x86 PC has a ROM at a particular place in its address range, and when it starts, it executes from the start of that range. The Alpha is a little different, on start-up it needs some code from a ROM which configures it and sets up its address space. This is applied as a 1-bit serial stream, and like many things DEC, it’s a little unusual. This code lives in a conventional ROM chip with 8 data lines, and each of those lines contains a separate program selectable by a jumper. It’s a handy way of providing a set of diagnostics at the lowest level, but even with that discovery the weirdness isn’t quite over. We’re treated to a run-down of DEC Alpha code encoding, and should you have one of these machines, there’s all the code you need.
The Alpha was so special in the 1990s because with 64-bit and retargetable microcode in its architecture it was significantly faster than its competitors. From memory it could be had with DEC Tru64 UNIX, Microsoft Windows NT, or VMS, and with the last of which it was the upgrade path for VAX minicomputers. It faded away in the takeover by Compaq and subsequently HP, and we are probably the poorer for it. We look forward to seeing more about this particular workstation, should it come back to life.
mv5+, a vax that is (mostly) pin-compatible with an alpha, boots by loading a serial eprom into its cache and jumping to it. i once wroye a forth that lived entirely within the nv5+ cache. it could predict which cache line would be clobbered by a ram access, squirrel that lone away in registers, perform the access, then restore itself. this allowed me to explore that “mostly”.
for even more fun, the serial rom pins vecome general-purpose i/o once the cache is loaded. by bit-banging a uart on them, i had a vax running forth using only the processor, eprom, and rs-232 transceivers. there was a couple of kilobytes left in the cache to write programs in.
A friend ran his web server on a Dec Alpha. The win was, buffer overflow exploits were not targeted at Alpha, so immunity through obscurity.
I was a Unix system administrator at NASA Goddard Space Flight Center in the early 90s and we ran the first instance of http://www.nasa.gov on a DEC Alpha. It was very fast!
So fast it could emulate x86 faster than the contemporary x86 cpus could run it, at the time the alpha came out.
I don’t think anyone was emulating x86 in that era. they were more commonly cross compiling for x86 on the alpha, because they would be done in a day where native hardware would take a week.
Using SoftPC, Windows NT on RISC emulated x86 instructions for NTVDM and WoW (DOS/Win3.1 sub systems).
Windows NT 3.x was on 286 level, NT 4 on 486 level. AFAIK.
I once ran a demo on such kit where I stalled a ZX Spectrum emulator running inside a pc emulator and played manic miner 😊
You think wrongly. Google FX!32, which did this for alpha. Emulation, plus an almost Rosetta-style binary translator.
FX!32 on the alpha pretty much JIT’d the x86 code and that made it really fast. Not faster than native, but definitely fast enough to run things that weren’t doing number crunching like office suites and whatnot
There was a PC emulator with my Acorn A310 in 1988 – the first computer with an ARM processor. I used it to run WordStar and Lotus 123!
We had some of these as engineering workstations at Synopsys, part of a hardware for software trade we did back in the 90s with HP/Compaq. This was to help support the DEC Alpha port of one of our EDA tools at the time.
It was fast, and I wanted one because if that… but what was with that massive disc changer for data access? It felt like using a tape library would be faster. Not that I’m really complaining, having the access at all was incredible, so thanks to you and your team for that.
We a couple of DEC Alphas on loan to run SolidWorks on.
They were awesome, but the VAR wouldn’t let go of them. He was semding them from customer to customer to try, only to have the rug pulled out from beneath him when they ceased production.
Mine was to test Pro/Engineer. No one used the workstation, so I added a second Digital network card and reused it as a Linux firewall by using Redhat Linux 5.2.
Wow, brings back memories. Back in the 90s, I was factory trained DEC Alpha admin. We were using the platform as our DB server and it was ridiculously fast. Miss those days of so much innovation, however short lived some were
A lot of the chip engineers behind Alpha went to AMD to work on Athlon, so the Alpha lineage is, to a certain extent, still alive. Most notable was Jim Keller.
And he is now at Tenstorrent, doing really cool things with RISC-V.
I applied for a job – my dream job! – there, but sadly Fate or more specifically their hiring dept had other ideas. Ah well.
I heard some of them went to Cavium to design the Octeon
The first version of Verilator got developped by the DEC Alpha team.
Wilson Snyder, the current maintainer of the tool did work at Cavium.
Now helping Tenstorrent.
If it takes 30 minutes to boot, it isn’t unusual.
He shouldn’t dismiss the PCI cards as dead just because they don’t work in a PC. Possibly they just have different code on their ROMs (or flash) that is Alpha-specific, and isn’t recognized by PCs.
If they can’t be used in modern computers then how are they different from e-waste?
They can still be used by people with old computers.
I vividly remember John Maddog Hall demoing 64 bit Linux on Alpha at NIH Bethesda Linux user group meet in 1995, organized by Prezemek Klosowski. It was so blazing faast.
“My old computer can’t run win11, it’s ewaste!”
If it does run Win10, it is e-waste.
Alpha’s were interesting in that respect. There was a fairly minimal 80(3?)86 emulator in the firmware so it could emulate the bios roms and initialise pci cards without needing them to have an alpha specific rom on them
I picked up a Alpha Server in 1999. I tried putting an Nvidia PCI card in it, but it couldn’t POST with it. A different ATI card did work though. It was exactly that. The little shim layer that handled x86 PCI init couldn’t execute the code in the Nvidia ROM.
The G200 should have a normal PC ROM and the LSI card I think doesn’t have one. But neither is allocated any resources by the Plug and Play BIOS on my PC so pretty sure they’re dead.
I hope he’s seen this manual: https://web-docs.gsi.de/~kraemer/COLLECTION/DEC/ek_alph5_ui_b01.pdf
which identifies J4 as the CPU diagnostic port
And this manual: http://www.zx.net.nz/computers/dec/astn200/doc/ek-pcdsa-ti.pdf
which identifies the pinout for a possibly similar port
The first manual indicates that (one of) the serial port(s) is used as a console when a graphics console is not available. It also indicates the meanings of various boot status codes, but doesn’t say where those codes might be output.
I’ve read both. It’s unfortunate there’s no Technical Info for the 500 though.
I knew of Vax systems where I worked in the 80s that were used to develop a global mapping application. It was quite impressive. It tracked all sorts of business information.
“Conventionally, an x86 PC has a ROM at a particular place in its address range, and when it starts, it executes from the start of that range. The Alpha is a little different, on start-up it needs some code from a ROM which configures it and sets up its address space.”
Modern computers do much the same thing. When most* CPUs come up, ram doesn’t work nor does the rest of the computer. the initial stages of the bios flash have to get the cpu hardware configured, set up cache-as-ram to get a workspace (in the olden days you had to do all the memory link training algorithms completely out of the cpu registers), perform memory link training and various other calibration, then copy more of the rom into ram and often have to do a lot of the same stuff for PCIe and other busses and hardware. only THEN can you load more of the bios rom into ram…….and reach real mode, the realm of the 8086. then you or the os (which you have to search for and load, and which itself is loaded in stages) have to work your way through the history of the x86 platform, enabling everything from the A20 gate through to 64 bit mode.
*amd has pushed ram init down into the platform security processor these days. those cores might even boot directly into a 64 bit address space
Sometimes i wonder how much of that legacy is still in the Van Gogh, the SoC in the Steamdeck, that i daily-drive as my main rig with Ubuntu. o.o
There’s also a different method, using processor registers.
Diagnostic ROMs for IBM PC (5150/5160) worked that way, I think.
They had used the registers as tiny working memory, essentially.
Writing code that works without functioning RAM is an art on its own.
I mentioned that, from the era before cache-as-ram. coreboot deprecated their cpu-only compiler a few years back as they no longer support any platforms without cache-as-ram.
In the first few generations of AMD Opteron (K8), much of the CPU SoC init happened in one enormous microcode instruction that lived in ROM.
K8 used point-to-point Hypertransport to connect CPUs together and CPUs to peripherals like southbridges and PCI/PCIe bridges. To make this fabric architecture work, each CPU had to discover neighbors and figure out the system topology without hardcoded cues like straps or EEPROMs at each socket.
To do this, the boot microcode mega-instruction would bring up all HT links and handshake with neighbors. If all the neighbors were coherent (other CPUs), or non-coherent (chipset) and do not have attached BIOS flash, then the CPU would mark itself as an application processor (AP) and go into an idle state waiting for further instructions from elsewhere on the fabric. If a CPU found a neighbor that was noncoherent with a BIOS ROM attached, it would become the bootstrap processor (BSP), copy the first part of the BIOS into icache, and start execution. BIOS would then do its own fabric discovery and wake up any APs to start memory training.
IIRC there was patch space in the efuses for microcode just in case there was a bug in the mask ROM microcode.
There were TWO different firmwares on the DEC Alpha and two distinct corresponding ranges of hardware.
SRM console on the serious DEC Alphas for Digital Unix, VMS and Linux over a serial line to a terminal, as God intended. No graphics hardware. Real F*cking computers.
ARC firmware for Windows NT on the lower end hardware as I recall but we never used it.
I admin’ed many AlphaServers and a few Digital Personal Workstations in the mid-late 1990s. We had a couple test hosts running Linux64 and they were wicked fast. The only comparable hardware and systems at that time was Silicon Graphics.
Open systems (Linux, BSD) eventually prevailed but now there’s little alternative to sht Apple Mac and PC x86 hardware. How sad.
That’s the second level. The SROM is the same for both.
I remember installing Ultrix on one of these from tape when they were new. That was fun. I think it took me several attempts and several days to get it working.
I had an Alpha for about a week. It came into the university surplus, and man were they fast! I had a 266mhz 21164 (if I recall correctly), which was a 6 or so year old system at the time, and a I think 900mhz AMD Duron as my main desktop (maybe.a 1 year old CPU). (Both running Linux). The Alpha cleaned the Duron’s clock, it was like twice as fast even though it was at under 1/3rd the clock speed. Unless you did video playback, then the Alpha used about 1% CPU time and was seriously probably like 20x the speed at video decoding (and yes, the Duron was new enough to have MMX and 3DNow, it had the ‘best’ instructions available from both Intel and AMD at that point for that kind of thing. The Alpha didn’t have a fixed purpose MPEG decoder or anything, they just choose their add-on instructions to speed up video and 3d stuff VERY well apparently.)
Gah I forgot to say why I only had it a week. To avoid acusations of grabbing the good stuff, we’d have items out for a week or two (university surplus was open 1 day a week) before we could purchase it. I did that. A week later someone came in and REALLY wanted it quite badly so I sold it to them.
Probably the best Unix platform I have ever used. True64 could do hard real-time stuff out of the box. I built HWIL simulations based on True64 & VME Alpha SBCs that are still running 24/7 after many years.
My first thought was this might be cost savings, as there were no 64-bit ROMs then (to my knowledge) so DEC would have had to have multiple narrower ROMs in parallel. However, if it’s just used to set up a parallel ROM in a later stage, that blows that theory.
I’m sure there’s a good reason, just not apparent to us.
I had one on my desk because it was used as a caption generator in TV studios, with it’s application running on Windows NT. I added an external remote control to it (using an Acorn Risc PC!).
NT on the Alpha didn’t seem any different to that on the much cheaper Pentium and that’s probably why it failed.
Similarly in another role we benchmarked Solaris on Sparc v. Windows NT on Intel and again the Intel won. At this point there was a performance war between Intel, AND, Cyrix and the speeds were increasing rapidly to the point where the other architectures couldn’t keep up – lacking the volume of the x86.
Arm beat Intel hands down on power consumption which is how they did do well.