This article is based on [work][3] by [astr0baby][4]/[DoktorCranium][5] and his twitter screenshots. His guide is quite sparse, which I try to improve with this one. [astr0baby][4] does a lot of cool emulation stuff, his twitter is full of screenshots of his M1 Macbook running all kinds of legacy operating systems, from AIX to OpenVMS to MorphOS on whatever old CPU you can think of. Here is how the end result of this guide looks: ![openttd][31] > Modern OpenTTD and browsing on NetBSD on Alpha! If you're interested in Alpha emulation or running OpenVMS, check out [AXPbox][6] or read [this page][10] for more information on available emulators. AXPbox [can boot][12] the NetBSD 9.1 installer, but it doesn't install yet, due to disk emulation issues. If you get it working with 9.2 or the current NetBSD development release, please let me know! There were earlier attempts to use QEMU Alpha emulation, [here is a guide from 2014 on running Debian][27]. However, Debian [dropped the Alpha architecture] [28] after version 5.0 (lenny), so NetBSD is our only modern option. And maybe Gentoo, but I'm unsure of that. Tru64 will not run on QEMU currently. The Alpha machine QEMU emulates is based on the Alpha DP264 platform, this is probably best known as the basis of the Compaq AlphaServer ES40 and Compaq AlphaStation ES40 systems, although a number of other AlphaStations (e.g. XP900 and XP1000), AlphaServers (e.g. DS10 and DS20) and OEM boards (e.g. AlphaPC 264DP and API UP2000) were also based on it. ([via][30]) I can't even do a `cat /proc/cpuinfo`. The NetBSD specific `cpuctl identify 0` command reports `CPU identification not implemented for this architecture`. With `dmesg` you get some info, but not much: dmesg | grep MHz [ 1.000000] 6600 family, unknown model variation 0x1400, 250MHz, s/n QEMU Here's a screenshot of NeoFetch in the QEMU console: ![neofetch][41] This guide is also available for [AXPbox][40], the other open source DEC Alpha emulator. #### Article changelog * 2021-08-27: Added `openssl speed` and `sysbench` benchmarks * 2021-08-20: `pkgin` works again, repo issue fixed. Updated section in article accordingly. * 2021-08-19: Added a few responses from Jason's mailing list answer regarding kernel / emulation. ### Patching and building QEMU Due to not all patches [being upstream][2] you must build QEMU yourself. This process is rather simple, as you would expect it is nothing more than getting the source code, applying the patch and the regular `./configure` followed by `make`. To install all required build dependencies on Ubuntu, use the following command: apt-get build-dep qemu The patch file is rather small, which is why I can share it here. Place the below contents in a file named `alpha-mmclock-qemu.patch`: --- qemu/hw/rtc/mc146818rtc.c.orig 2020-10-01 00:56:55.574093880 +0000 +++ qemu/hw/rtc/mc146818rtc.c 2020-10-01 00:58:40.326479896 +0000 @@ -155,9 +155,15 @@ static uint32_t rtc_periodic_clock_ticks { int period_code; +#if 0 + /* + * Real hardware sets the PF bit rergardless if it actually + * raises an interrupt. + */ if (!(s->cmos_data[RTC_REG_B] & REG_B_PIE)) { return 0; } +#endif period_code = s->cmos_data[RTC_REG_A] & 0x0f; @@ -944,6 +950,7 @@ static void rtc_realizefn(DeviceState *d } s->periodic_timer = timer_new_ns(rtc_clock, rtc_periodic_timer, s); + periodic_timer_update(s, qemu_clock_get_ns(rtc_clock), 0, true); s->update_timer = timer_new_ns(rtc_clock, rtc_update_timer, s); check_update_timer(s); The manual process to build and install QEMU from the latest release is on [the official site][7]. You can keep an eye on [the source file mx146818rtc.c git log][1] to see if the patch process is still required. As of writing this article, it is, the latest commit there is `2021-05-13 Philippe Mathieu... hw/rtc/mc146818rtc: Convert to 3-phase reset (Resettabl...) (fae5a0420754453beca3407250899254fb6745a1)`. I'm building git commit hash `bd44d64a3879bb6b0ca19bff3be16e0093502fac`, but if you notice that the git log of the above file is different, skip the patch/checkout step and let me know if I need to update this article. Clone the QEMU source repository: git clone https://gitlab.com/qemu-project/qemu.git Navigate into the source folder: cd qemu Checkout the specific commit I used when writing this article: git checkout bd44d64a3879bb6b0ca19bff3be16e0093502fac Apply the patch: patch -p1 < alpha-mmclock-qemu.patch Output should look like: patching file hw/rtc/mc146818rtc.c Hunk #2 succeeded at 934 (offset -16 lines). Initialize all git submodules: git submodule init git submodule update --recursive Start the actual build process, first the configure step, for speed of compilation specifically for the Alpha architecture only: ./configure --target-list=alpha-softmmu Followed by make to start compilation. Replace `-j8` with your amount of CPU cores: make -j8 No `make install`, since I suspect you already have qemu installed and just want to test out stuff. This build, due to being configured with a specific target, will only work with that, not "regular" QEMU as provided by your distro. Make will take some time, when it is finished compiling, you should have a binary named `qemu-system-alpha` inside the `build` folder: file build/qemu-system-alpha Output: build/qemu-system-alpha: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc41c3dfc1d574362343dbe4f8d06ad1f72806a6, for GNU/Linux 4.4.0, with debug_info, not stripped If you run the binary, you should see a black window with a green text greeting you (`Hello`): ![screenshot qemu][11] I had some configure errors (for example `ERROR: Program 'keycodemapdb/tools/keymap-gen' not found`) that were the result of the `git submodule update` command failing. I had to reset all submodules and try again with the following commands: git clean -xfd git submodule foreach --recursive git clean -xfd git reset --hard git submodule foreach --recursive git reset --hard git submodule update --init --recursive ### Installing NetBSD The installation process runs as usual once it's booted up. You use an interactive installer to install NetBSD, but to boot, we must provide the kernel to QEMU manually. The kernel file for installation is different from the one for "regular" use. #### Downloading the ISO and kernels Check [the following directory][8] for the current version of the latest `current` ISO, in my case `NetBSD-9.99.88-alpha.iso`. Download the ISO: wget https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.88-alpha.iso Note: If the version number changed, the above command will return a 404 error and you must specify the new URL yourself. More information on how the `current` (development/daily) builds work can be found [here][9] on the NetBSD site. I asked on [the mailing list][35] why the kernels should be provided to QEMU outside of the installed disk, this is what Jason had to say: > The Qemu "bios" (palcode-clipper) for its Alpha emulation does not contain any of the I/O callbacks implemented by real DEC SRM firmware. Nor does it contain any of the CLI implemented by real DEC SRM firmware. As such, there is no way to use a boot loader program to load the kernel from the file system in the emulated machines disks. Download the two kernel files, start with the one for installation: wget http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/alpha/installation/instkernel/netbsd.gz Uncompress it and rename so we know which one is which: gunzip netbsd.gz mv netbsd inst-netbsd My file is for 9.99.88, yours may differ: file inst-netbsd Output: inst-netbsd: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), statically linked, for NetBSD 9.99.88, stripped Same for the one for regular use: wget http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/alpha/binary/kernel/netbsd-GENERIC.QEMU.gz Extract it: gunzip netbsd-GENERIC.QEMU.gz File information: netbsd-GENERIC.QEMU: ELF 64-bit LSB executable, Alpha(unofficial), version 1 (SYSV), statically linked, for NetBSD 9.99.88, not stripped I asked what the difference is between the installation kernel and the regular QEMU kernel file on the mailing list: > GENERIC.QEMU is exactly the same as GENERIC except that it has the kernel symbol table injected into it for use by the in-kernel debugger (and, eventually, the in-kernel linker for modules, once I finish implementing all of the necessary relocations for Alpha). #### NetBSD Installation Create a disk file which the installation will use: qemu-img create -f qcow2 disk.img 20G Start QEMU with the following command to start the installation: ./build/qemu-system-alpha \ -m 1024 \ -kernel inst-netbsd \ -drive file=disk.img,media=disk,format=qcow2,index=0 \ -drive file=NetBSD-9.99.88-alpha.iso,media=cdrom,format=raw,index=1 \ -net nic \ -net user,hostfwd=tcp::2222-:22 Change the ISO filename if the version number has changed upstream (`NetBSD-9.99.88-alpha.iso`). If you haven't applied the patch, the install will boot but hang with an error regarding the clock: ![screenshot rtc error][13] Otherwise, you will be asked what type of terminal you're using and the installation will start as you're used to: ![screenshot installer][14] Continue on with the interactive installer. I'm not covering the entire installation process since there are no special things you need to do (like the qemu patch above). ![screenshot installer][15] I choose a full installation (not minimal or without X11), installed to disk `wd0` using the CDROM as source: ![screenshot installer][16] I also setup networking during the installation, as well as enable SSH and mdns: ![screenshot installer][17] Here's the summary: ![screenshot installer][18] Once you're done installing, shut down the VM with the following command: shutdown -p now ### Running NetBSD Once NetBSD is installed, the command to start qemu is different, since we're using a different kernel file and we're telling NetBSD which drive to boot from (`wd0`). This is the new command: ./build/qemu-system-alpha \ -m 1024 \ -kernel netbsd-GENERIC.QEMU \ -drive file=disk.img,media=disk,format=qcow2,index=0 \ -drive file=NetBSD-9.99.88-alpha.iso,media=cdrom,format=raw,index=1 \ -append "rootdev=/dev/wd0" \ -net nic \ -net user,hostfwd=tcp::2222-:22 If you do get questions asked during boot, just press ENTER to accept the defaults. If all went well, you should be able to login to your fresh new shiny Alpha NetBSD: ![screenshot netbsd][19] Networking works out of the box as well: ![screenshot netbsd][20] Awesome, well done. For the final part, we're going to install and setup TigerVNC so we can play around with a GUI. #### Connecting via SSH to NetBSD The QEMU VM is started with the option `-net user,hostfwd=tcp::2222-:22`. This means that on you local machine, port `2222` is forwarded to port `22` on the VM. To SSH into the NetBSD machine (assuming networking is setup and working), you can connect to that port on localhost: ssh root@127.0.0.1 -p 2222 I had to allow root login (`vi /etc/ssh/sshd_config`, `PermitRootLogin yes`, `service sshd restart`), which in this case, for this local test machine not directly exposed to the internet, is not a security risk. ![SSH][25] If you're unable to install packages (for whatever reason), you can use the built-in features to have a GUI via SSH and Xnest. See [my other article] [38] how to do that. ### Setup X11 and VNC (GUI) X is installed by default, but crashes with a segfault if [you run it][33] on the QEMU VGA console (`X -configure`, then `X -config /root/xorg.conf.new`). Therefore, we're going to use VNC, which does run and is quite fast and usable. The `tigervnc` server is not included in the installation, which is why we start with setting up the package manager and installing a few packages. A screenshot of the segfault: ![x11 crash][23] #### Installing binary packages (pkgsrc) Assuming networking works, we can use [the usual way][32] to install binary packages. How amazing it is that NetBSD provides binary packages for Alpha, compiling them would otherwise take very long. Type the following commands in the shell to install the binary package manager: PATH="/usr/pkg/sbin:/usr/pkg/bin:$PATH" PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages" PKG_PATH="$PKG_PATH/NetBSD/alpha/9.2/All/" export PATH PKG_PATH pkg_add pkgin Update the package sources: pkgin update After that, you can install tigervnc: pkgin install tigervnc **When writing this article, there was an issue with the repository, the index file was corrupt. The below section covers that, but you can probably skip it if you're not interested in NetBSD's packaging system. You can continue with the section `TigerVNC Configuration`. After sending a message on the `port-alpha` mailing list, [John fixed the repository][36].** In my case, `pkgin update` gave an error, `pkgin: Short read of pkg_summary: truncated bzip2 input`. This seems to be a [corrupt file][21], which I cannot fix from here. I did however saw on the directory index, that there also was a gzipped version (not bzip2), `pkg_summary.gz`, but I could not find a way to get that file instead of the bzip2 file. `pkgin` is a handy wrapper that mimicks `apt/yum`, but underneath it uses `pkg_*`, as far as I know, which we can also do manually. The repository URL is setup after we've exported the variables earlier, so you should be able to just do: pkg_add fetch You can also specify the entire URL to a package: pkg_add ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/alpha/9.2/All/fetch-1.9nb1.tgz For the exact filename you can [browse the web index of Alpha packages][22]. You can also use `ftp` to download the package, then install it locally: ftp -i ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/alpha/9.2/All/fetch-1.9nb1.tgz pkg_add ./fetch-1.9nb1.tgz That will however still connect to the network to fetch dependencies, so if you're doing this offline (lets say via an NFS share), you might run into issues there. Install the `tigervnc` package: pkg_add tigervnc It will fetch some dependencies and should install correctly: ![vnc install][24] ### TigerVNC configuration Configuring tigerVNC is simple since most configuration is already done via the package. Start by setting up a VNC password: vncpasswd Enter the password twice: Password: Verify: Answer no to a view only password: Would you like to enter a view-only password (y/n)? n Start the VNC server: vncserver Output: New 'netbsd.alpha.raymii.org:1 (root)' desktop is netbsd.alpha.raymii.org:1 Creating default startup script /root/.vnc/xstartup Creating default config /root/.vnc/config Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/netbsd.alpha.raymii.org:1.log To connect to your shiny new awesome desktop, you must use SSH to forward a port. Disconnect your SSH session and reconnect with a new flag for a local port forward: ssh root@127.0.0.1 -p 2222 -L 5901:127.0.0.1:5901 This forwards port 5901 (VNC port for display `:1`) on your local machine to port `5901` on the virtual machine. After logging in, you should be able to use any VNC client to connect right away: ![vnc yay][26] How cool is that? A modern NetBSD with a graphical desktop on a CPU architecture (Alpha) running in QEMU, with networking. After rebooting, you need to enter the `vncserver` command again to start VNC. You can also setup a service to autostart at boot, but I'm not going to cover how to do that in this guide. You've gotten this far on a weird CPU emulation article, I bet you that you're very capable of figuring autostarting VNC out yourself. For some more fun, you can install a browser (`netsurf` or `dillo`, firefox or chrome are not available as packages) or a game (my favorite, `openttd` is available as a package including the free graphics `openttd-data`). OpenTTD is quite playable. Not very fast, but a small map seems to run okay. It even seems `xfce4` packages are available in the repository, so you could deck out a full featured desktop. I've tried installing it, but after 18 hours or so, it's still running. Netsurf took just as long, and it seems to be the installation of GTK that takes so much time. As Jason says on the mailing list, it might be related to disk IO: > Yikes. I'll need pkg install experts to weigh in on this. It's entirely possible that it's bottlenecked on the disk emulation. I'm working on getting VirtIO to work on alpha so hopefully we can speed disk and network access up a little. If there is any software you do want to run but not available as a binary package, compiling it yourself (or letting `pkgsrc` do it for you) is always an option. ![openttd][31] I managed to compile `python2` via `pkgsrc`, the `cvs checkout` of `pkgsrc` took a day or so to complete: ![python2][37] The setup of `pkgsrc` for source compilation is documented on the NetBSD website but this is the process I used, if you want to try it out: cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-2021Q1 -P pkgsrc cd /usr/pkgsrc/lang/python27 make fetch-list | sh; # fetch dependencies make NO_CHECKSUM=yes make install If you get any segfaults or `internal compiler errors` during building, my experience is that those go away if you retry the build. (Do a `make clean` first). Below is an example error message, which did not occur when I retried the compilation: mv -f .deps/loadapi.Tpo .deps/loadapi.Po gcc -DLOCALEDIR=\"/usr/pkg/share/locale\" -DLIBDIR=\"/usr/pkg/lib\" -DINCLUDEDIR=\"/usr/pkg/include\" -DHAVE_CONFIG_H -I. -I./glob -I/usr/include -I/usr/pkg/include -O2 -mieee -D_FORTIFY_SOURCE=2 -I/usr/include -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c during GIMPLE pass: cddce main.c: In function 'main': main.c:1066:1: internal compiler error: Segmentation fault 1066 | main (int argc, char **argv, char **envp) | ^~~~ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See