I heard about axpbox and was excited to replace one of my VAX nodes with something more modern, and on Alpha besides. I've heard alot about Alpha, but never got to use it. QEMU doesn't support OpenVMS installs on its Alpha emulator, so this was my first chance to experience Alpha. Around 2pm on a Saturday I got the files, built the emulator, and read all I could on the topic. At 6pm I filled out the example es40.cfg, which was not accepted by the emulator at startup. So, I used the built-in configurator at which time it promptly deleted my config along with the work that went into it. There was no delete nor backspace in the configurator. Instead, it outputs a garbage character with no way to erase it.
Worse, it generates non-working config files. After 5-6 restarts I got a typo-free config. Editing by hand again, I removed the extra serial line and the system started up. I would be revisiting that config file many times. The management console is over telnet, simulating a serial line. This gives the feel of the usual VMS operator's console.
Partition 0, Memory base: 000000000, size: 020000000
initializing GCT/FRU at 1c8000
Initializing pka ewa
Memory Testing and Configuration Status
Array Size Base Address Intlv Mode
--------- ---------- ---------------- ----------
0 512Mb 0000000000000000 4-Way
512 MB of System Memory
Testing the System
Testing the Disks (read only)
Testing the Network
AlphaServer ES40 Console V7.3-1, built on Feb 27 2007 at 12:57:47
P00>>>show dev
dka0.0.0.3.0 DKA0 RZ58 2000
dka100.1.0.3.0 DKA100 RZ58 2000
dka200.2.0.3.0 DKA200 RRD42 4.5d
dva0.0.0.1000.0 DVA0
ewa0.0.0.2.0 EWA0 AA-00-04-00-0D-04
pka0.7.0.3.0 PKA0 SCSI Bus ID 7
P00>>>
Long story short, both VMS and axpbox crashed more times than I could count. GUI, no GUI. RAM in the megabyte range or gigabyte range. High speed CPU, low speed CPU, IDE disks or SCSI disks. S3 graphics which were supposed to work better but didn't or Cirrus graphics which were not supposed to work but did work somewhat, or none at all. Icache or none. Multi-core or not (don't try to run more than one). Approaching 11pm I was running out of gods to pray to and small animals to sacrifice, but got the install to start. It's slow, painfully slow: after a command is entered it takes 30 - 120 seconds or more for the system to respond even on a Ryzen 8 core machine. For comparison, MicroVMS 4.6 under SIMH's microvax2, a far less capable machine and much older, could run circles around it. The install took over two hours and I'm being generous. Likely it was closer to three hours. That would make it the longest install I've ever done in my lifetime. After midnight, I got a SYSTEM login, typed "dir" and the system crashed. Trying to configure DECnet, I noticed you can't run DECnet (issues #39, #84 on github) because it crashes the system. The GUI doesn't work in any useful way (no graphics device found with DECwindows).
%SET-I-INTSET, login interactive limit = 64, current interactive value = 0
%DECW$DEVICE-I-NODEVICE, no graphics devices found.
%%%%%%%%%%% OPCOM 3-FEB-2024 15:09:09.67 %%%%%%%%%%%
The graphical display is in place of the telnet/serial line combo you'd be using otherwise. Since you can copy/paste (via Linux's Selection ability) with telnet/serial line but not the "graphical" command line, I'm not sure why you'd want to use it. It makes entering licenses much harder. End day one.
Next evening, I tried again with a second OpenVMS Alpha 8.4 ISO set (one was HP and one VSI, ALPHA0842L1.ISO) and all SCSI disks. Same problem, but the SCSI disks may have worked better, or it might have been the placebo effect. Or maybe it was my wishful thinking as my dreams of running Alpha began to slip away? The disks kept going offline and then back online, with a long pause every time.
%SYSTEM-I-MOUNTVER, TEOSTR$DKA0: is offline. Mount verification in progress.
%SYSTEM-I-MOUNTVER, TEOSTR$DKA0: has completed mount verification.
%%%%%%%%%%% OPCOM 3-FEB-2024 15:08:23.02 %%%%%%%%%%%
Device TEOSTR$DKA0: is offline.
Mount verification is in progress.
%%%%%%%%%%% OPCOM 3-FEB-2024 15:08:23.05 %%%%%%%%%%%
Mount verification has completed for device TEOSTR$DKA0:
But the real deal breaker was, no matter what I connected with (telnet, kermit, xterm, urxvt, screen) or what I tried to force the terminal to (set term /device=vt200 or vt100 or even vt10), the terminal always either came up 'unknown' - which means you can't edit text files with either /edt or /tpu - or it spews garbage and you still can't edit. Not even clearing the screen (type/page nl:) worked. After some testing, I did find setting env TERM=vt220-8bit cool-retro-term would get me at least a VT100 (and on a retro-amber screen as well!) so that I could edit a file.
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1
Username: system
Password:
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1
[c\Z[0ct interactive login on Monday, 29-JAN-2024 11:03:25.30
%SET-W-NOTSET, error modifying OPA0:
-SET-I-UNKTERM, unknown terminal type
$ type/page nl:
$ edit /tpu test.txt
%TPU-E-NONANSICRT, SYS$INPUT must be supported CRT
$
The last project commit was to a readme file 6 months ago, and the last code commit was 8 months ago at the time of this writing. I'm guessing the project is dead. I don't write this to complain, but rather in shock and disappointment because the various guides I read (like Raymii's) make it seem like axpbox is a mostly working emulator with a rare bug when it's in fact the opposite: a mostly bugged emulator that rarely works.
If you've looked at the pictures from the above link you might be confused, as it appears to be working and with networking as well. But, look closer and you'll see it's the usual Xephyr setup (displaying on a remote Xserver, likely Linux) and not axpbox's GUI that is being displayed. Furthermore, it's using TCPIP and not DECnet nor LAT. I didn't see the point of attempting to setup TCPIP with axpbox in such a state so I didn't try.
DECnet will configure, and there's an example, but it crashes when you try to start it. Maybe it requires Phase 5, the one no one knows how to use (or does use), along with Phase 4. Even still, what about the github issues confirming my findings?
@startnet
**** OpenVMS Alpha Operating System V8.4 - BUGCHECK ****
** Bugcheck code = 00000215: MACHINECHK, Machine check while in kernel mode
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: TEOSTR
** Highest CPU number: 00000003
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: TEOSTR$DQA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
**** Starting compressed selective memory dump at 5-FEB-2024 00:05...
I'm fine with no GUI: it's OpenVMS after all, an OS known for relying on the command line. However, you are not going to get far without editing a config file and an OpenVMS node without DECnet, its native networking, is about as useful as a car without wheels. For these reasons I decided not to proceed further with the install at this time.
Axpbox is the start of a good emulator, but is not ready for regular use at this time. The project maintainer doesn't seem to be making any updates. When I posted this somewhat negative, yet honest comment on another site, my comment never appeared. I'm not sure if this is an oversight, or a delay in moderation, or if the webmaster doesn't allow negative comments.
Hopefully this review can save you 12-36 hours of time only to end with a non-working system. In any case, have fun with axpbox - just don't expect a usable OpenVMS node. (es40.cfg in HTML comments for reference)