Tidying up at the end of the week

Spot the server, printer, or cow

Spent some of today tidying up the house, and a little bit tidying up in the Dreamcast and VAX emulation world.

• Updated the Booting NetBSD/vax in SIMH howto to reflect the changes in NetBSD-6, point to the correct page for the simh pkgsrc package and misc cleanup
• Updated the NetBSD/dreamcast howto to point at the two very much easier methods of burning a Dreamcast CD
• Relaxed the timer granularity check on the SIMH pkgsrc package to allow setting the idle check on machines with HZ=100 - now emulated vax machines do not need to max out the host CPU all the time
• Fixed the configure mkstemp() check on the gxemul pkgsrc package, so it can boot full Dreamcast CD images again
• Adjusted the dc-burn-netbsd script to include a full set of devices in the release-in-root-on-cd case, and attempted to test this in gxemul (hence the previous item)

Interestingly I discovered that once the CD image was booted in gxemul attempting to mount the CD failed with the (verbose) gxemul console messages:

[ GDROM cmd: 30 20 39 fd 9c 00 00 00 00 00 01 00 (cnt=2048) ]
[ diskimage__internal_access(): disk_id 0, offset 2791911424, transfer not completed. len=2048, len_done=0 ]
GDROM: diskimage_access failed? TODO 

Given the entire ISO image was 97,910,784 bytes in size, I suspect tying to access data at offset 2,791,911,424 is unlikely to yield a happy result in any universe with congruent natural laws to our own, but just to make sure I'll try to test on a real Dreamcast tomorrow.

Looks like I'll either be hacking my dc-burn-netbsd script to determine what boneheaded bug I've added, or gxemul's dev_dreamcast_gdrom.cc. Good good!

Potential VAX gcc news (and damp dogs)

Today was not particularly productive in Retrochallenge terms - I visiting my parents and spent a large part of it digging fresh palisade roll into their garden, ably "assisted" by two dogs, one of whom tried to stand exactly wherever I needed to be, and the other just dug up random sections of flowerbed.


Fortunately it was raining continually, which should have driven the dogs indoors, rather less fortunately they were so caught up in helping me that they remained outside the entire time, finally following me back in trailing that distinctive fragrance of "damp dog"... and mud. Don't forget the mud.

I did manage to exchange email with someone who is both an expert on VAX assembler and gcc, who now has an simh NetBSD environment setup, and is investigating the possibility of fixing the latest gcc to be able to compile VAX executables which bear at least a passing resemblance to their source code.

This is definitely a Good Thing (in VAX terms), and would benefit anyone looking to compile VAX executables for any system using a recent gcc (Granted, this may be a rather exclusive club).

Oh, and I did fix a recently added reference in the NetBSD atf tree which unconditionally pointed to the gcc-4.5 stdc++, breaking the gcc-4.1 build (and I'm going to go out on a limb and guess the set of people who care about that make the group in the previous paragraph seem like a thundering herd).

eMSCPation proclamation

Diagram from MSCP patent

Tonight's Retrochallenge 2012 diversion features some MSCP code I wrote a couple of weeks ago, but have only just committed to the NetBSD source tree.

MSCP, or Mass Storage Control Protocol was designed by Digital Equipment Corporation to provide high level but low overhead communication with storage devices.

It was used extensively on PDP-11 and early VAX, and even some DEC MIPS system. Later systems tended to drift across to the then available SCSI.

At some point before the netbsd-6 branch the MSCP driver started behaving oddly (cleanups related to kernel threads). Under the quite excellent simh-vax emulator it would report (and ignore) an additional phantom device on the bus, but on at least some real hardware it would end up in a decidedly unhappy state, with the machine unable to access any devices.

Not actually having any real MSCP hardware made this a little harder to debug, but thanks to the delightfully interconnected world in which we live someone was willing to test build kernels based on diffs from me to track down the issue and confirm the fix.

The issue turned out to be an interesting interaction between the mscp_attach() routine, which iterated through the units on the bus, sending an M_OP_GETUNITST+M_GUM_NEXTUNIT message to each, and mscp_dorsp() which processed interrupts (and returned messages) from the devices. When probing for devices M_GUM_NEXTUNIT provides a very handy ability to find the next active unit - so if you have unit ids 0 and 8 you can probe for 0 with M_GUM_NEXTUNIT and get 0 back, then probe for 1 with M_GUM_NEXTUNIT and get 8 back, without all that tedious mucking about in hyperspace, - ahem, or rather without having to probe the intermediate unit ids. Once you try probing past the last unit, it loops around. The mishandling of this final probe was what gave the phantom device and much unhappiness.

So, some simple changes, a tweak to better handle non-contiguous unit ids, and an opportunity to replace a couple of gotos with a for(;;) loop, and NetBSD/vax is happy again.

The next phase is to clean up the MSCP code further to permit attaching new devices while the system is running. Ragge (the vax portmaster) is going to play with that one, but it seemed best to get my changes in the tree so NetBSD-6.0 will be guaranteed to have working MSCP code :)

In other news since it was updated to NetBSD 6-BETA2 the Dreamcast has finished building bash & zsh and has *nearly* finished building simh. Why would I want to build a vax emulator on a Dreamcast which uses a VAX as an NFS server? Surely there could not be some strange and twisted plan afoot? We shall just have to see...

Wargames for the masses

Yesterday for Retrochallenge 2012 I wrote a little shell script to simulate the interaction with the WOPR computer in wargames. (Connect link)

It was quite incomplete, and bodged into the telnet port on the VAXstation, so tonight I polished it a little, and then a little more, adjusted the output timings, made it very generous when accepting input (so you could type "fine", rather than "I'm fine. How are you"), and finally made it go back and rewrite what the user typed in such cases to match the film.

Finally I got over-enthusiastic and put it up on github and added an entry to pkgsrc.

Notice, at no point in this process did I ask myself "why?".

Along the way I found out how easy it was to setup telnetd to automatically run a program instead of asking for login, and found a java telnet app to add to wopr's home page to make it easier for random web users to connect to the script. I also tweaked the font colour and style to better match that in the film.

Its this attention to pointless detail that is probably quite worrying.

Its like building a perfect matchstick model of a chair with a broken leg, who's only purpose is to be put on a bonfire.

Learning how to setup telnetd to autorun a program instead of login would be potentially useful... if it was 1992 and anyone still had any use for telnet.
(for reference just set the telnetd arguments in inetd.conf to "-g foo -a off -h" and in gettytab copy default to foo and replace the im= with lo=/path/to/app).

Still, after dropping into an email thread on the simh list I've submitted a request to pullup a commit from Matt Thomas' so simh will be able to detect when a NetBSD-6 vax guest is idle and save CPU cycles.

So... looked at it from the right perspective, that will reduce energy use and carbon emissions, so in a tiny way I just may have done something today which will help save the planet! ... or mabye not.


<< The only winning move is... Dreamcast virtual display - 50% off! >>

The only winning move is...

Taking a break from a playing directly with retro-hardware, last night I watched wargames and took a few notes on the interaction with the WOPR computer.

The result, lovingly crafted into a simple shell script was connected up to the telnet port in inetd whereupon three issues immediately sprung up

1. Since there is no local telnetd, the script gets to see the initial IAC command codes (called for a little sed hackery)
2. Calling 'system("sleep 0.1") from awk on an amd64 box sleeps for about 1/10 of a second. On a VAX... its more like 1/5 a second with overhead. Cue writing a small C program to handle outputting the text
3. I'm pretty sure TCP Nagle is kicking in and making the output blocky, but its late & I'll come back to that

Anyway - the result should be visible by "telnet wopr.absd.org" (If your client tries SRA login you may need "telnet -K wopr.absd.org"). It turns out there was quite a lot of interaction with WOPR in the film. I suspect I have about 60-75% of it complete (mainly towards the start), and I've tried to be relatively generous in what it accepts (checking for a matching key word rather than an entire sentence).

So, how much do you remember from Lightman's typed conversations with WOPR? telnet to wopr.absd.org and test your memory :)

(In other news I upgraded the Dreamcast to NetBSD-6, which went fine apart from the fact I'd forgotten the kernel had been set to prompt for a root device, which meant my decision to run a final reboot *after* leaving the office was... unhelpful)

<< Retrochallenge mission accomplished. Need new mission! Wargames for the masses >>

Retrochallenge mission accomplished. Need new mission!

So this morning's Retrochallenge 2012 activity was reuniting the Dreamcast with the VAX and setting the VAX up to act as a dhcp and NFS server to the DC (copying the config from home).

Sundry small sysadmin tasks later (adding swap, users, mounting /home from the vax, installing some binary packages and starting a build for the latest PHP (don't ask)), and there was just time to break for the pre-9am coffee.

So, what do we have:

• wopr - an 128M VAXstation 4000/90A acting as a NFS server to
• orac - a 16M SEGA Dreamcast with sh3 CPU

Both have user logins and run web servers (wopr with PHP). orac has also run X (640x480 with a composite video to VGA adaptor is not a pretty sight).

Both have a 'falken' login which runs the standard NetBSD /usr/games/wargames script (the password *is* the obvious one :)

So, what next for Retrochallenge 2012:

Some thoughts:

• The wargames script really could do with being a little more faithful to the movie. Per character delay, more interaction, prompting for Global Thermonuclear War or even a nice game of chess :)
• Turning this into the worlds strangest honeypot. I have a sparc classic with two network interfaces which could act as a monitor, but what apps and accounts should be on the target VAX & Dreamcast machines? Samba? some hugely vulnerable web apps?
• Running an sh3 emulator on the VAX & a VAX emulator on the Dreamcast?
• Adding as many alternate architectures to the cluster as possible. Partial marks only for using VPN connections to alternate locations

Or... something else?

Your suggestions wanted!
<< Dream a little cast of me... THE ONLY WINNING MOVE IS... >>

I'll give you my dmesg when you take it from my cold, dead hands

Tonight's (rather quick) NetBSD/vax retrochallenge change was to disable kernfs from the install kernel & include dmesg in the crunchgen binary.

The installer images for most NetBSD ports already do this, and there is something quite offputting in any *BSD system, no matter how cut down in seeing "dmesg: not found"

Net effect is a slightly smaller image, and of course the ability to drop to a shell at any point and type dmesg... just like $deity intended.

As an added bonus I took the opportunity to add dhcpcd to the vax installer image, because frankly life is too short to be manually entering IP addresses...

The more eagle eyed among you will notice the dmesg image above is both a xterm screengrab, and obviously from a simh-vax emulator. This is because tonight I am far from my vax, and the edit-build-test cycle is a lot more convenient run locally on my Thinkpad.

Fear not, these changes will be run on real iron too... << NetBSD/vax moves to MAXPARTITIONS 16 Dream a little cast of me... >>

NetBSD/vax moves to MAXPARTITIONS 16

Image courtesy of Computer History Museum

This is RetroChallenge 2012 month, and as my Dreamcast and VAXstation are still many miles apart I decided to finish off switching NetBSD/vax from 8 to 16 partitions per disk.

Turned out to be quite simple to do - once I remembered to check that the boot blocks would need to be adjusted to handle the larger disklabel.

Of course given the average disk size in use on a VAX is likely to be on the order of dozens to hundreds of MB there may not necessarily be as many obvious uses for more partitions, but to quote a *nix saying "Here is rope. Do stuff".

Copy of the message sent to port-vax to inform users of the change:

For all you staring at that RD52 and wondering how to make full use of
its capacity with only seven partitions, your solution is here!
No more will you have to nest devices to allow you to create 15
separate 2MB partitions, now NetBSD/vax has been extended from 8
partitions per device to 16! (*)

(*) Also works for devices greater than 31MB!

After updating current all existing /dev nodes should be unaffected,
just run MAKEDEV to gain access to the additional partitions.

Commit message:
- Increase MAXPARTITIONS for vax from 8 to 16, using the standard NetBSD
  mechanism to ensure all existing /dev nodes continue to work
- Adjust boot block layout to fit additional partitions
- Adjust number of inodes on install media

<< Retrochallenge 2012 - public access Dreamcast? I'll give you my dmesg... >>

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? >>