Undocumented Madness – 2.9BSD on XHomer

This is a guest post by Seal331

Since I’ve been dealing with XHomer a lot lately in order to get the two dumped VENIX/PRO versions to work, I noticed that the XHomer documentation mentions a thing called “maintenance mode” and the DEC Pro port of 2.9BSD, so I was interested.

After doing a bit of searching around I found some install notes on www.frijid.net from real hardware, so I decided to adapt these notes for XHomer and install it. TL;DR – I did it, here I’m explaining all this stuff.

Step 1 – Acquiring XHomer

XHomer is a DEC Pro 350 emulator that can run P/OS, Venix, 2.9BSD and possibly RT-11, but I didn’t get to installing the last one yet. There is a statically linked binary but, since I’m a Gentoo Linux person (but I didn’t use Gentoo for this particular install)and prefer compiling everything I can, I grabbed the source code (https://xhomer.isani.org/xhomer/xhomer-9-16-06.tgz) and quickly compiled it on my Linux box. It was pretty simple, just install a development toolchain (build-essential on Debian based systems), the libX11 development package (libx11-dev on Debian based systems) and the XShm extension which is included in libxext-dev on Debian based systems. During make it spit out a bunch of warnings but I got a working xhomer binary. Also it kind of messes the xterm settings a bit after being closed, so I’d recommend running it in a separate xterm window. Since there’s no install target in the Makefile I just copied the xhomer binary to /usr/bin, and that was it. From here on, I will assume that the XHomer binary is called xhomer and is somewhere in your PATH, if not just modify the way I run XHomer.

Step 2 – Acquiring the distribution

Thanks to the people at the same www.frijid.net site I mentioned earlier, I was able to easily piece together a distribution set. Since we don’t really rely on how many physical floppies we have with an emulator, I grabbed the recommended root disk set and the 15 disk usr set with the source code, although we won’t be compiling the kernel in this post. Maybe next one? We’ll see.

The site with the floppies is http://www.frijid.net/download/pro350/bsd/raw/ and here’s what I used for my install:

box#0/maintenance0.img
box#1/usr+k00.img
box#1/usr+k01.img
box#1/usr+k02.img
box#1/usr+k03.img
box#1/usr+k04.img
box#1/usr+k05.img
box#1/usr+k06.img
box#1/usr+k07.img
box#1/usr+k08.img
box#1/usr+k09.img
box#1/usr+k10.img
box#2/usr+k11.img
box#2/usr+k12.img
box#2/usr+k13.img
box#2/usr+k14.img
box#2/usr+k15.img
box#2/root1.img
box#2/root2.img
box#2/root3.img
box#2/root4.img
box#2/root5.img

The 3 disk usr set in box#2/ doesn’t include the source, so I didn’t grab it.
The maintenance disks are all the same, so I just grabbed the one in box#0/.
The 6 disk root set in box#0/ does include some extra dev files and something that appear to be leftovers from the development DEC Pro, but it’s missing /bin/ed and /bin/passwd, so I suggest using the 5 disk set instead.

There is also box#2/procomm.img which was labeled as containing “PRO/COMM terminal emulation” but when I mounted it to install, there was only an empty lost+found directory. Perhaps the original disk had gone bad over the years or someone accidentally reformatted it? We may never know.

Step 3 – XHomer configuration & serial port preparation

Since the maintenance (install) floppy uses a serial terminal interface over the printer port and XHomer only allows us to send its output over serial, I had to do some searching again since most PCs nowadays don’t have a serial port to use. Thanks to cantoni over at StackOverflow I managed to find instructions for using socat in order to generate a pty, which actually worked for me. At first you need to install socat (bruh) and then run “socat -d -d pty,raw,echo=0 pty,raw,echo=0”. Something like this will be printed out on the terminal:

Then we do a quick test. I use putty to connect to the pty’s output, in my case it’s /dev/pts/3. Just use the default settings for serial connection with speed 9600 and the device as /dev/pts/3. If everything goes well, you will get a blank putty terminal window. Don’t panic, the fact it’s blank is normal.

Let’s test if our serial port works. Echo something in the pty’s input, in my case it’s /dev/pts/4. For example, “echo “Test” > /dev/pts/4″. If the word “Test” appears on the screen, congratulations, you have successfully set up the pty to a point where BSD will happily talk to it when we set up the connection later. !! DO NOT CLOSE THE PUTTY WINDOW AT ANY POINT DURING THE INSTALL UNTIL WE NO LONGER NEED IT (at the initial hd boot) !!

Now we configure XHomer. At first, let’s make a disk image. BSD only supports RD51 or RD50, we’ll use RD51 as it’s slightly bigger. If you get the hard disk wrong, BSD will silently hang at boot. Here’s the command to make a 10MB RD51 disk image for use with XHomer:

dd if=/dev/zero of=29bsd.rd bs=10027008 count=1

Let’s make the XHomer config file. Note that everything after the symbol | including the symbol itself does not need to be inputed, it’s just my notes.

screen = window | make the emulator window mode
window_position = 0, 0
window_scale = 2
full_scale = 3
screen_gamma = 10
pcm = on
framebuffers = 0
serial0 = /dev/pts/4 | change to your needs, pty input
la50 = null
la50_dpi = 300
kb = lk201
ptr = serial0 | DO NOT CHANGE, we'll replace it later when we no longer need serial
com = null
rd_dir = ./
rx_dir = ./
rd0 = 29bsd.rd, 4, 306, 16 | change if not using suggested disk
force_year = 99 | fix y2k bugs by forcing year to 1999
maint_mode = on | DO NOT CHANGE, bsd install uses maintenance mode for terminal
int_throttle = off | random workarounds for clocks or older linux systems, we don't need this on new stuff
nine_workaround = off
libc_workaround = off
lp_workaround = off

Save the file as xhomer.cfg.

Now run the xhomer binary. If everything goes right, you should have something like this on your screen:

If you didn’t run the test documented above or changed the string, the “Test” string will not be in the terminal or will be some other text, this is all okay.

Step 4 – BSD install

In order to feed floppies to XHomer, you have to use the XHomer control menu. In order to get to it, press Ctrl+F1 when the emulator window has focus. The two floppy drives we need are rx0: and rx1:, these are equivalents of A: and B: in DOS. Insert the maintenance0.img disk in rx0. If all goes okay, the floppy disk picture should disappear from the display window, leaving just the DIGITAL logo. The putty window should then display something like this:

40Boot
:

(all following input is in the terminal unless otherwise stated)

If all is okay, congratulations, you have booted from the installation diskette. Now type the following in the putty window after the : symbol:

r5(0,0)rdfmt

Then, if you inserted an RD51 10MB disk in the emulator as suggested, type 0 when asked for drive type. If you inserted the 5MB RD50 instead, type 1. If you don’t know the exact disk sizes and types, refer to the XHomer documentation, specifically the Emulated Hard Disk part. The formatting shouldn’t take long, then it will dump you back in the 40Boot prompt. Now you need to boot the UNIX kernel, type this in the putty window:

r5(0,0)unix

If everything goes okay, you should have something like this now:

If you get a boot hang instead (like me), restart both XHomer and putty, connect putty back to the pty, then in XHome insert the maintenance0 floppy back and boot the UNIX kernel again. DO NOT FORMAT THE DRIVE AGAIN!!

Install time!

At first, create the root filesystem by running:

/etc/mkfs /dev/rrd0a 2240

Then insert the root1 disk in the 2nd floppy drive (rx1) and restore the root filesystem dump from the 5 root set floppies:

restor rf /dev/rr51 /dev/rrd0a

When it says “Last chance before scribbling on /dev/rrd0a.” just press Enter.
When it says “Mount volume N”, just insert the right floppy and press Enter. Volume number == floppy number in this case.

After the “end of tape” message, verify the rootfs:

/etc/fsck /dev/rrd0a

If it succeeds, create the usr filesystem by running:

/etc/mkfs /dev/rrd0c 6528

Then insert the usr+k00 disk in the 2nd floppy drive (rx1) and restore the usr filesystem dump from the 16 usr set floppies:

restor rf /dev/rr51 /dev/rrd0c

When it says “Last chance before scribbling on /dev/rrd0c.” just press Enter.
When it says “Mount volume N”, just insert the right floppy and press Enter. Floppy number == volume number – 1 in this case.

After the “end of tape” message, verify the usr fs:

/etc/fsck /dev/rrd0c

(all following input is in on the Pro display unless otherwise stated)

If everything is okay, run sync two times and shut down the emulator. Restart it with only the maintenance floppy in rx0, then type this in the terminal (NOT the Pro display):

rd(0,64)unix

This should boot up Berkeley UNIX (BSD). We’re not done yet, but it’s close.

Type the following to install the hard disk bootblock:

dd if=/rdboot of=/dev/rrd0h count=17

If everything goes okay, set the root password:

passwd root

Congratulations, you have successfully installed 2.9BSD. Here are the cleanup and hdboot prep stuff:

Bring the OS to single user mode:

shutdown +1

(you can close putty now)

Then run sync two times and shut down the emulator.

Step 5 – Booting the OS

In order to boot the OS, you need to do the following:

Open the xhomer.cfg file;

Remove the serial0 = line;

Change the ptr = serial0 line to ptr = null;

Change the maint_mode = on to maint_mode = off.

Then save, after running XHomer you should be able to just log in.

Congratulations, you have successfully installed 2.9BSD for the DEC Pro 350! Sadly it’s pretty unstable, and due to emulation issues in XHomer vi completely crashes BSD, but there’s always ed 😉

Appendix A – Transferring Files

In order to transfer the files (up to 400KB per file) you will need some additional utilities. Here’s a guide on how to install them:

(the following steps are done on the Linux host side)

  1. Grab the following files:

https://xhomer.isani.org/xhomer/BSD/f2rx
https://xhomer.isani.org/xhomer/BSD/rx2f.c
https://xhomer.isani.org/xhomer/BSD/lbn2xhomer.c

  1. Apply the following patch to lbn2xhomer.c:
--- lbn2xhomer.c   2015-07-05 07:51:19.000000000 +0300
+++ lbn2xhomer.c        2021-12-30 17:13:28.539768500 +0300
@@ -25,6 +25,7 @@

 #include <string.h>
 #include <stdio.h>
+#include <stdlib.h>

 #define SECSIZE                512
 #define SECTORS                10
@@ -66,7 +67,7 @@
   if (fptr_v == NULL)
   {
     printf("Unable to open %s\n", argv[1]);
-    exit();
+    exit(1);
   }

   fptr_x = fopen(argv[2], "w");
  1. Compile lbn2xhomer:
cc -o lbn2xhomer lbn2xhomer.c
  1. Set up f2rx for operation:
chmod +x f2rx
  1. Make a floppy image with the BSD side utility:
./f2rx rx2f.c
  1. Run XHomer and attach the generated rx2f.c.dsk to rx0

(the following steps are done on the BSD side)

  1. Grab the file from the floppy:
dd if=/dev/r50 of=rx2f.c skip=18 bs=1 count=891
  1. Compile the utility:
cc -o rx2f rx2f.c

You’re now ready to transfer files.

Short file transfer handbook:

  1. Run f2rx FILE on the host box, FILE being the file to use;
  2. Insert FILE.dsk into rx0 on XHomer;
  3. Run rx2f on the BSD side.

Appendix B – Init: no more children issue workaround

On some hosts, programs from the install floppy may randomly die with the “no more children” message. A workaround is to disable RTC mode and enable IOTRACE mode in the XHomer Makefile and recompile, leading to a much more slower (due to accurate timing) and working XHomer. After the installation, you can revert to normal settings and it should work, as the programs installed on the hard drive to not appear to suffer from the same issue.

Appendix C – Sequels

Possibly coming soon to VirtuallyFun:

Undocumented Madness 2 – Big hard drives on 2.9BSD XHomer
Undocumented Madness 3 – Custom Kernel on 2.9BSD XHomer

Multia under Thermal Camera

(This is a guest post by Antoni Sawicki aka Tenox)

DEC Multias are known for notoriously overheating. Someone even coined a term “Multia Heat Death”. The typical folklore recommendation of the time was to only run it vertically and replace the built-in fan with a more powerful one.

In modern times one can inexpensively acquire a thermal camera that attaches to a mobile phone. So why not take a peak inside the inferno.

Multia with 166 MHz CPU Under FLIR

This is how Multia looks like in a thermal camera. PS is on top right. CPU on the left. FDD/HDD bottom left.

The CPU, Alpha AXP, runs at around 60C, not great, not terrible.

Scanning up close through individual chips I found this curiosity:

Wedged between the memory chips and the power supply is a little chip that generates almost 100C. That’s a boiling temperature of water. Note the thermal image is shifted in regards to the visual part due to close range.

What does this chip do? I have no clue. Perhaps someone can help here. What I however did to it is this:

Slapped on this really nice radiator. In fact I added little radiators you can buy for Raspberry PI to all the chips generating tons of heat.

This is how the motherboard looks like right now:

I also added a tiny fan on top of the CPU. Drilled some holes in the case and of course replaced the main fan with a highest air flow I could find.

Time will tell if this resolves the heat death, but my Multia now runs much cooler with help of all the radiators and extra fans.

UPDATE in 2022:

Readers frequently asked “what about the heat death chip?“. Multia indeed has one specific chip that is a source of most of Multia casualties. According to NetBSD Multia Page the chip is 74F623 and is located on the bottom (flip) side of the motherboard.

You can tell it’s little charred. I so I went to take a peek with a thermal camera:

Can you locate it? FLIR found it immediately… Up close the chip goes above 100C:

I have added a small heat sink to it and now looks a little better!

Time will tell if it helps or not.

Confessions of a paranoid DEC Engineer: Robert Supnik talks about the great Dungeon heist!

What an incredible adventure!

Apparently this was all recorded in 2017, and just now released.

It’s very long, but I would still highly recommend watching the full thing.

Bob goes into detail about the rise of the integrated circuit versions of the PDP-11 & VAX processors, the challenges of how Digital was spiraling out of control, and how he was the one that not only championed the Alpha, but had to make the difficult decisions that if the Alpha succeeded that many people were now out of a job, and many directions had to be closed off.

He goes into great detail how the Alpha was basically out maneuvered politically and how the PC business had not only dragged them down by management not embracing the Alpha but how trying to pull a quick one on Intel led to their demise.

Also of interest was his time in research witnessing the untapped possibilities of AltaVista, and how Compaq had bogged it down, and ceded the market to the upstart Google, the inability to launch a portable MP3 player (Although to be fair the iPod wasn’t first to market by a long shot, it was the best user experience by far).

What was also interesting was his last job, working at Unisys and getting them out of the legacy mainframe hardware business and into emulation on x86, along with the lesson that if you can run your engine in primary CPU cache it’s insanely fast (in GCC land -Os is better than -O9).

The most significant part towards the end of course is where he ‘rewinds’ his story to go into his interest in simulations, and of course how he started SIMH when he had some idle time in the early 90’s. SIMH of course has done an incredible amount of work to preserve computing history of many early computers. He also touches on working with the Warren’s TUHS to get Unix v0 up and running on a simulated PDP-7 and what would have been a challenge in the day using an obscure Burroughs disk & controller modified from the PDP-9.

Yes it’s 6 hours long! But really it’s great!

Setting up DECNet on VMS 4.7

Years ago, I was given an image of VMS 4.7.  I only tested it for idle capabilities, and that is as far as I got with it.  I never used it for anything else.

But today I needed to verify my Win32 Hecnet project works, so I needed to generate some legit DECNet traffic.  Luckily I still have the VMS image, and in the prevailing years I managed to get a copy of PathWorks for Windows NT (And one for MS-DOS as well!).

So googling around, I found blinkenbone who mentions the command needed to setup some DECNet love.  Now the one thing that is strange about DECNet is that the MAC address needs to be changed to the DECNet area & node id.  Thankfully there is an online calculator, powerdog.  Since I’m just testing, I’ll put my VAX in area 1, node 1, that means the VAX MAC needs to be set to:

AA-00-04-00-01-04

So in SIMH, I just use the line:

set xq mac=AA-00-04-00-01-04

Cool.  Now I use ansicon, in the hopes it’ll make the console better, and fire up VMS.

VMS 4.7 booted

VMS 4.7 booted

And then login as system/manager

Now I can setup decnet very simply like this:

Username: SYSTEM
Password:
Welcome to VAX/VMS version V4.7
Last interactive login on Saturday, 20-SEP-2008 17:32
$ @sys$manager:netconfig

DECnet-VAX network configuration procedure

This procedure will help you define the parameters needed to get DECnet
running on this machine. You will be shown the changes before they are
executed, in case you wish to perform them manually.

What do you want your DECnet node name to be? : rabbit
What do you want your DECnet address to be? : 1.1
Do you want to operate as a router? [NO (nonrouting)]:
Do you want a default DECnet account? [YES]:

Here are the commands necessary to setup your system.

————————————————————————–
$ RUN SYS$SYSTEM:NCP
PURGE KNOWN OBJECTS ALL
PURGE MODULE CONFIGURATOR KNOWN CIRCUITS ALL
$ DEFINE/USER SYS$OUTPUT NL:
$ DEFINE/USER SYS$ERROR NL:
$ RUN SYS$SYSTEM:NCP ! Remove existing entry, if any
PURGE NODE 1.1 ALL
PURGE NODE RABBIT ALL
$ RUN SYS$SYSTEM:NCP
DEFINE EXECUTOR ADDRESS 1.1 STATE ON
DEFINE EXECUTOR NAME RABBIT
DEFINE EXECUTOR MAXIMUM ADDRESS 1023
DEFINE EXECUTOR TYPE NONROUTING IV
DEFINE EXECUTOR NONPRIVILEGED USER DECNET
DEFINE EXECUTOR NONPRIVILEGED PASSWORD DECNET
$ DEFINE/USER_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ RUN SYS$SYSTEM:AUTHORIZE
ADD DECNET /OWNER=”DECNET DEFAULT” –
/PASSWORD=DECNET –
/UIC=[376,376] /ACCOUNT=DECNET –
/DEVICE=SYS$SPECIFIC: /DIRECTORY=[DECNET] –
/PRIVILEGE=(TMPMBX,NETMBX) –
/DEFPRIVILEGE=(TMPMBX,NETMBX) –
Press RETURN to continue

/FLAGS=(CAPTIVE) /LGICMD=NL: –
/NOBATCH /NOINTERACTIVE
$ CREATE/DIRECTORY SYS$SPECIFIC:[DECNET] /OWNER=[376,376]
$ RUN SYS$SYSTEM:NCP
DEFINE LINE QNA-0 STATE ON
DEFINE CIRCUIT QNA-0 STATE ON COST 4
DEFINE LOGGING MONITOR STATE ON
DEFINE LOGGING MONITOR EVENTS 0.0-9
DEFINE LOGGING MONITOR EVENTS 2.0-1
DEFINE LOGGING MONITOR EVENTS 4.2-13,15-16,18-19
DEFINE LOGGING MONITOR EVENTS 5.0-18
DEFINE LOGGING MONITOR EVENTS 128.0-4
————————————————————————–

Do you want to go ahead and do it? [YES]:
%UAF-I-ADDMSG, user record successfully added
%UAF-I-RDBADDMSGU, identifier DECNET value: [000376,000376] added to RIGHTSLIST.
DAT
%UAF-I-DONEMSG, system authorization file modified
%UAF-I-RDBDONEMSG, rights database modified
%NCP-I-NMLRSP, listener response – Success
Logging sink type = monitor
%NML-I-RECADDED, Database entry added

The changes have been made.

If you have not already installed the DECnet-VAX license, then do so now.

After the license has been installed, you should invoke the procedure
SYS$MANAGER:STARTNET.COM to startup DECnet-VAX with these changes.

(If the license is already installed) Do you want DECnet started? [YES]:
%%%%%%%%%%% OPCOM 28-OCT-1987 15:42:37.64 %%%%%%%%%%%
Message from user DECNET
DECnet starting

%RUN-S-PROC_ID, identification of created process is 00000109
%RUN-S-PROC_ID, identification of created process is 0000010B
$
%%%%%%%%%%% OPCOM 28-OCT-1987 15:42:42.67 %%%%%%%%%%%
Message from user DECNET
DECnet event 4.10, circuit up
From node 1.1 (RABBIT), 28-OCT-1987 15:42:37.69
Circuit QNA-0

It basically set itself up.

And on the Windows NT side, I simply set itself up as node 2 in area 1.

Windows NT + Pathworks

Windows NT + Pathworks

And now I can use CTERM to connect to the VAX.

CTERM

CTERM

Nice!.  And it even works through my port of HECNet.

On reboots you have to manually start the network.  I don’t have EDT, or I don’t know where to find it (remember the gold key? ugh).

Manually starting the network

Manually starting the network

But it’s a simple command:

@SYS$MANAGER:startnet.com

And you are good to go!

Likewise shutting down is accomplished with this:

@SYS$SYSTEM:SHUTDOWN.COM

And that’s about all I know about VMS.  But it’s good to see that configuring this was pain free!

As part of the retrochallenge 2012, there is a PDP-11 running 2.11 BSD out there!

No, really!

You can get an account, just sign up here!

Sander Reiche has setup a MicroPDP-11/83 with the following specs:

So far there are FOUR users.. which means you can get in on the action for sure!

For those of you who want a sandboxed version at home, you can download my install here, which of course I touched on a while back.

For those unfamiliar, here is what retrochallenge is all about!

  1. RetroChallenge commences July 1st, 2012 and runs until July 31st, 2012.
  2. In order to qualify, computer systems must by approximately 10 years old (or older!)… in general, this means 486 or below, 680×0 and pretty much everything with an 8-bit processor, but we’ll also let you in if you have an old Cray kicking about, and exceptions can always be made for exotica!
  3. Gaming consoles and PDAs qualify if they were made in the previous century.
  4. Where appropriate, replica hardware and emulators may be used.
  5. Entrants are responsible for adequately documenting their projects and submitting occasional updates during the contest.
  6. Projects may encompass any aspect of retro-computing that tickles the fancy of the individual entrant.
  7. Winners will be carefully selected and thoughtfully chosen prizes presented (hopefully before the next challenge commences).
  8. Have fun!

Sadly I don’t have anything physical around here that really qualifies.  A G5 mac is too new, and I recently picked up a Pentium 150 based IBM Aptiva, but its too new apparently….

Three tonnes of mini computers

It looks almost religious doesn’t it?

I just received this note from the HECnet mailing list, and I thought I’d broadcast it out..

This is a shameless plug for something I and the Update Computer Club 
have been working on this spring and opened yesterday.

The exhibition "Three Tons of Minicomputers" at Museum Gustavianum in 
Uppsala, Sweden.

http://www.gustavianum.uu.se/node13

We have collected computers primarily used by the university at some 
point in time. Highlights include a Linc-8 and a DECSYSTEM-2060 with 
peripherals.

Here are some pictures from the opening:

http://www.update.uu.se/~jeppe/tmp/vernissage/

I strongly recommend anyone nearby Uppsala this summer to take a swing 
by Gustavianum. If you want a guided tour, let me know and we'll figure 
something out.

It's only open for a few months, so don't wait to long.

Regards,
Pontus.

I don’t know when I’ll be in Europe next, but now I really want to go to Sweden!

DEC Legacy Event

Well I just found out about a “DEC Legacy Event” being held in the UK. Sadly I already booked tickets to the UK *this* month not the correct one… But then who knows… 😉

From the site:

The DEC Legacy Event that will take place on the 17th & 18th April 2010 in Windermere, UK.

The purpose of the event is to bring together people with an interest in the company Digital Equipment Corporation and their legacy of hardware, software and ethos. There will be both vintage DEC computer hardware and software and more recent HP hardware and software being demonstrated at the event.

I suppose this would have been the place to get some win terminals going, and have multi-user access into a VMS system running on SIMH on an Alpha…

Oh well…

At any rate they promise to upload video from the aftermath, and they’ve got up some interesting promo pics