Emulating Alpha Systems with QEMU and ES40: A Practical Guide

You do not need a working AlphaServer to run Alpha software in 2026. Two open-source emulators cover most of what hobbyists want: QEMU for fast Linux work, and the ES40 emulator for running the real SRM console and the operating systems that depend on it.

Two emulators, two philosophies

QEMU and ES40 approach the problem from opposite ends. QEMU aims for speed and pragmatism. It emulates an Alpha system closely enough to boot Linux, but it replaces the real firmware with its own minimal PALcode, and it skips anything the Linux kernel does not strictly need.

ES40 aims for fidelity. It models a specific machine, the AlphaServer ES40, closely enough that the genuine SRM console ROM runs on it. That opens the door to OpenVMS, Tru64 UNIX and the BSDs, at the cost of speed and a considerably rougher user experience.

QEMU: qemu-system-alpha and the clipper machine

QEMU's Alpha target provides a single machine type, clipper, named after the ES40's internal codename. It models a Tsunami-family chipset similar to the one used on the UP2000 and CS20, with a CMD646 IDE controller, serial ports, VGA and standard PCI slots. Up to four virtual CPUs are supported.

Because there is no SRM, QEMU cannot boot from a disk the way real hardware does. Instead, you pass it a kernel and initrd directly. That makes it ideal for Linux and useless for anything that relies on the console.

Booting a Debian ports installer

The practical procedure below assumes a Linux host with QEMU installed and a current Debian ports Alpha installer ISO.

1. Create a disk image. A qcow2 file of around 20 GB leaves room for a build environment.
2. Extract the kernel and initrd from the ISO. They sit in the boot directory.
3. If QEMU refuses the compressed kernel, decompress it to a plain ELF vmlinux first. Behaviour here has varied between QEMU versions.
4. Launch the installer with the kernel, initrd, ISO and disk attached, using serial console.
5. Complete the install. The installer will complain about aboot; skip bootloader installation, since QEMU does not use it.
6. Copy the installed kernel and initrd out of the disk image and boot them directly for everyday use.

qemu-img create -f qcow2 alpha.qcow2 20G

mkdir iso && sudo mount -o loop debian-alpha-netinst.iso iso
cp iso/boot/vmlinuz iso/boot/initrd.gz .
sudo umount iso

qemu-system-alpha -M clipper -m 2048 -smp 2 \
  -kernel vmlinuz -initrd initrd.gz \
  -append "console=ttyS0" \
  -drive file=alpha.qcow2,if=ide,index=0 \
  -cdrom debian-alpha-netinst.iso \
  -netdev user,id=n0 -device e1000,netdev=n0 \
  -nographic

After installation, extract the kernel with guestmount or virt-copy-out, or loop-mount the image via qemu-nbd, then replace the installer kernel and initrd on the command line and set root=/dev/sda2, or whatever partition you chose, in -append.

User-mode emulation for builds

For compiling software, full-system emulation is not always necessary. qemu-alpha in user mode, combined with binfmt_misc, lets you run Alpha binaries inside a chroot on an x86 or ARM host. A modern host running user-mode translation will often outbuild a real UP2000 comfortably.

sudo debootstrap --arch=alpha --foreign \
  --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  unstable ./alpha-root "$PORTS_MIRROR"
sudo cp /usr/bin/qemu-alpha-static ./alpha-root/usr/bin/
sudo chroot ./alpha-root /debootstrap/debootstrap --second-stage

The ES40 emulator

The ES40 project emerged in the second half of the 2000s as an open-source effort to emulate the AlphaServer ES40 well enough to run OpenVMS. It is written in C++, models the CPU, the Tsunami chipset, an ALi south bridge with IDE, serial ports and optional network and graphics, and loads a genuine SRM firmware image taken from an HP firmware update kit.

Development slowed considerably after its most active period, and several forks have appeared to fix build issues on modern compilers. Expect to spend some time getting it to compile.

Configuration and first boot

ES40 reads a configuration file describing the machine. A minimal setup, adapted from the sample that ships with the source, looks roughly like this:

sys0 = tsunami
{
  memory.bits = 30;
  rom.srm = "cl67srmrom.exe";
  rom.decompressed = "decompressed.rom";
  rom.flash = "flash.rom";
  rom.dpr = "dpr.rom";

  cpu0 = ev68cb { speed = 800M; }

  serial0 = serial { port = 21264; }

  pci0.7 = ali { vga_console = false; }
  pci0.15 = ali_ide
  {
    disk0.0 = file { file = "disk0.img"; read_only = false; }
    disk0.1 = file { file = "install.iso"; read_only = true; cdrom = true; }
  }
}

On first run, the emulator decompresses the SRM image, which takes a while, and writes the result to the decompressed.rom file so subsequent starts are quicker. Connect to the serial port with a telnet client on the configured port and you should eventually see the familiar >>> prompt. From there, everything works as on real hardware: show dev, set bootdef_dev, boot. Our explainer on SRM, AlphaBIOS and MILO covers the commands you will need.

Linux boots through aboot exactly as described in our guide to running Linux on Alpha hardware. OpenVMS and Tru64 are more hit and miss; certain versions install and run, others trip over unimplemented devices or timing quirks.

Limits and what to expect

• Performance: QEMU is quick enough for interactive use and package builds. ES40 is much slower; an OpenVMS install can take hours.
• Firmware: neither emulator runs AlphaBIOS, so Windows NT for Alpha is out of reach. See Windows NT on Alpha and FX!32 for why that matters historically.
• Specific boards: neither emulator models the Irongate-based UP1000. Board-specific firmware quirks must be tested on real hardware.
• Licensing: the SRM image and the non-Linux operating systems carry their own licence terms. Hobbyist licensing programmes have changed over the years, so check the current situation before relying on them.
• Timing: neither emulator is cycle-accurate. Performance measurements do not reflect a real 21264A.

Commercial emulators, Stromasys Charon-AXP being the best known, exist for production OpenVMS and Tru64 workloads and are considerably more complete. They are aimed at businesses keeping legacy applications alive rather than hobbyists.

Which should you use?

For Linux development, porting work, or a quick look at the platform, use QEMU. It is maintained, fast and simple to script. For exploring SRM, OpenVMS or Tru64, or for testing boot procedures before touching real hardware, ES40 is the only open option, and worth the effort. Either way, emulation is an excellent rehearsal: you can make every mistake once in software before making it on a board that took you months to find.

Further reading on this archive

• A collector's guide to Alpha hardware: when you are ready to buy the real thing.
• Running Linux on Alpha hardware today: distributions, kernels and pitfalls.
• Support: archived API documentation and firmware notes.