Retrocomputing with a VAMP stack: VAX, Apache, MySQL & PHP

"wopr". A VAXstation 4000/90A

What to do with a VAX workstation, based on an architecture first released by Digital Equipment Corporation in 1977 and finally closed out by Compaq at the end of the last millennium?

The obvious option would be to dig out an ancient copy of VMS, or maybe an early UNIX tape, but what then? Could it run the latest Apache or screen, and how will I be able to connect it to a native IPv6 network (when we finally get there :) ?

As an alternative, lets see if a current OS and software can run on a machine with an architecture older than some of the *parents* of modern developers...

In an ideal world, with a warehouse, a personal power station, and an unlimited time budget I'd find an original VAX 11/780. Working in the real world I compromised with a VAXstation 4000/90A, which is around PC sized with PC power consumption (if not performance :)

"wopr" has a 72Mhz CPU and is packed out with 128MB of 58.5MB/sec memory (no laughing in the back there), complete with colour graphics and an 8GB SCSI drive, and probably would have cost close to £20,000 in 1992.

Now in VAX terms this is a blistering fast machine, with a raw CPU performance of 40 VUPs (40 times the speed of the original 11/780).

Now you could regard using such a "fast" VAX as cheating, I regard it as choosing to be able to write this blog entry this year, rather than in 2018...

 

Installing the OS

For the OS I chose NetBSD (for reasons blindingly obvious for anyone who knows me and pretty much irrelevant to the rest of the world).

At this point you can assume a montage soundtrack in the background and lots of split screen visual effects covering: downloading the latest NetBSD/vax 6-BETA, setting up my laptop to run mopd (DEC proprietary MOP boot protocol), dhcpd (for the boot loader to query for IP address & kernel), tftpd (for the kernel), and nfsd (for the filesystem).

The montage music fades as we're left with a screen saying

NetBSD/vax (wopr) (ttyE0)

login:

Actually this happened concurrently with a magical side quest involving trying to wire a serial console cable with:

1. An RJ14 cable which needed to be cut to fit into the VAX MMJ console (and then kept falling out)
2. An RJ25 to DB9 shell (sold as an RJ14 to DB9)... of the wrong gender
3. A DB25 gender changer 
4. A DB9 to DB25 adaptor

... to allow me to try poking the loose pins of the DB9 shell into the DB25.
This was combined with several VAX console guides on the Internet which could not agree on the numbering of the required pins, and a certain amount of profanity.

Additional entertainment was provided by the GNU compiler (gcc), which in its 4.5.3 incarnation doesn't so much compile for the VAX as throw together sequences of VAX code in the vague hope that by the time they are executed the machine has fallen into a parallel universe where they now make sense.

NetBSD/vax has now switched back to gcc-4.1.3, which implements a more conventional level of mis-optimisation issues and (very) occasional compiler crashes.

 

Selecting and installing the software

Most things seemed to compile "out of the (pkgsrc) box". I should point out that I'd been chatting to a couple of people interested in running apps on the box, hence the somewhat eclectic selection of packages. At least two of them ran Debian x86 boxes their end, which explains (at least in my mind) the X apps. Some of them actually use it as a persistent IRC client, running weechat or nirc in a screen session.

The final result (to date) is http://wopr.absd.org/. Conclusive proof that you can (more or less) run the latest software on retrocomputing systems.

For anyone still reading, benzodiazepines are available on prescription, and if you're *still* reading, here are some of the issues encountered :)

• PHP has a php_get_inf() call which returns INF (infinity)... only on VAX there is no infinity (existential concepts aside - VAX floatingpoint maths has no concept of infinity, so the PHP code tried to return 1/0, which on the VAX is a quick route to a floating point exception and a core dump). A quick patch to special case __vax__ and we're good
• cmake has an... interesting way to determine whether the current system is big or little endian. Rather than trust the system's include files, which after all are only part of the operating system and could have no idea of the processor type, cmake chooses to have a huge long special cased list of  processor defines. So __vax__ fits nicely after other notable obsolete processor such as _s390__ (IBM ESA/390) and __ia64__ (Intel Itanium)
• naim has a clever if somewhat cryptic assert() to check that its being used against ncurses rather than ncursesw. Since NetBSD ships with its own curses implementation the assert was tuned to be less aggressive. Amusingly enough this issue was also present on NetBSD/amd64, so in this case playing with retrocomputing hardware has had potentially tangible benefits for people on modern machines - you have been warned!
• xneko failed on startup, which turned out to be a bug in the "non kernel implementation of the optional polyd VAX instruction as used in the assembler libm sin() implementation", now fixed. 'nuff said
• xkobo aborted with an XFont issue on startup if the remote display was Debian. This was tracked down to selecting a font which was in the standard X11R7 distribution, but not installed as standard on Debian. It now catches missing fonts and falls back to "fixed". This has the potential to benefit any pkgsrc using Debian user worldwide... who try to run xkobo. I'm pretty sure that intersection is a null set, but... no, its a null set
• MySQL failed to build because it depended on bash... which depended on bison... which when pkgsrc tried to check for portability issues caused awk to choke on parsing the test scripts. Apparently the strtod() implementation doesn't *quite* grok VAX FP limits, causing a free SIGFPE exception with every overlarge number. Skipping the check allows MySQL to build, but MySQL 5.5.24 seems to fall over on startup after creating the databases. 5.5.25 may fix this, but as it only started to compile 22 hours ago, we're still waiting to see if it does :)
• python, irssi via glib2 and a selection of other software depends on libffi, for which there is no VAX implementation. This looks to be non trivial to fix and require a significant amount of VAX compiler-fu.

Conclusion

So there you have it, retrocomputing with Apache-2.4.2, PHP 5.3.13, Perl 5.14.2, Bash 4.2, and Screen 4.0.3. Its almost civilised...

My next task is to submit back some of the VAX patches to the various projects (rather than just leaving them in pkgsrc), to see exactly what kind of response I get.

Tune in next [some arbitrary time interval], when I hope to get X running on the VAX, try to build Mosaic, and use the VAX as a network server for a SEGA Dreamcast...


Retrochallenge 2012 - public access Dreamcast? >>