Having been a member of TUHS since early on, I'd been playing, off and on, with the v6 distribution from Ken Wellsch running under SIMH. Enjoying this, I added a couple of MicroPDP-11/23 systems to my stash, and stuffed them into a corner of my hobby room, along with a suitable collection of spare boards, disks, etc, with an idea of porting v6 to that platform. That was over twenty years ago.
Over the years, I've bought and read the Lions book, and I've had lots of fun with 2.11BSD on my 11/83 systems, but I've been eyeing those BA23 cabinets with the 11/23 systems in them from time to time. Then, in December 2020, Noel Chiappa posted a message on the TUHS list saying how it really wasn't all that hard to get v6 to run on an 11/23. So...
In the TUHS archives, there are, in addition to the above mentioned images of the original UNIX v6, a set of images Tim Shoppa rescued from the University of British Columbia, where they ran a modified copy of the system on an 11/23 with RL02 disks. After getting that running under SIMH, I started digging for good starting points for getting an MSCP bootstrap and disk driver into it.
What I ended up with is based on the MSCP driver that Rick Macklem adapted from 2.9BSD to get that OS to run on the DEC Pro-350. I had to modify it quite a bit to get it working, first on SIMH, and, later, on the physical hardware -- so any bugs there now are probably mine, not Rick's. The boot sector is a mixture of the rauboot.s from 2.11BSD and the fsboot.s from v6, with the @ prompt and kernel choice ripped out, so it'll fit in a single sector. It now loads /unix only.
Along the way, in addition to the Lions book, and documentation from DEC, I found the information published by Noel Chiappa to be immensely useful. There are hints about the differences in the 11/23, and I'm really looking forward to using his notes on improving v6 while I continue to play with the OS.
Do note what he says about csv.s in the "improving v6" link, and download and install his version. This'll prevent a debugging headache when you try to use a function returning a long, and get garbled data from it.
Booting and running fine on simh, and on real hardware. Dropping it into the Wellsch v6, (which is identical to the one supplied to TUHS by Dennis Ritchie), is no problem, provided the "new C compiler" found in the UBC distribution is installed; the driver needs that because of its use of longs and unsigned ints. That could probably be fixed. It works equally well added to the system source kit in the UBC distribution. My 11/23 is currently running a system comprising the original v6 distribution, but with the enhanced kernel and new toolchain from UBC.
It supports just one controller. I suspect going for two would make it too big to fit a PDP-11 without separate I and D space anyway. Slightly more irritating is that it can only use physical disk block (sector) numbers that fit in a signed 16 bit integer. This may be something I've done to the driver, or an inherent limitation in v6, or maybe both. I haven't had time to study it yet. I'm toying with the idea of going through all of the v6 sources, and fixing all the "use a pointer and pretend it's an unsigned int" hacks, seeing as I'm using the new C compiler already. As it is, mkfs will create a file system that stretches beyond block 32767, but afterwards, df hangs, and icheck fails. That's as far as I've gotten.
The MSCP driver is in two files, ra.c and ra.h. The former is the driver proper, while the latter is the MSCP structs and constants. The boot sector is rauboot.s.
Note that the driver has information on partition sizes hardcoded into it, using the old BSD values:
struct rasizes {
daddr_t nblocks;
daddr_t blkoff;
} ra_sizes[8] = { /* Setup for RX50, RD51, RD52 and RD53 disks */
9700, 0, /* A=blk 0 thru 9699 (root for 52 & 53) */
17300, 9700, /* B=blk 9700 thru 26999 (52 & 53 only) */
3100, 27000, /* C=blk 27000 thru 30099 (swap 52 & 53) */
-1, 30100, /* D=blk 30100 thru end (52 & 53 only) */
7460, 0, /* E=blk 0 thru 7459 (root 51) */
2240, 7460, /* F=blk 7460 thru 9699 (swap 51) */
-1, 9700, /* G=blk 9700 thru end (51, 52 & 53) */
-1, 0, /* H=blk 0 thru end (51, 52, 53 & RX50) */
};
I figured that using something that was compatible with other early
Unix implementations on the same hardware would be a good idea. The
bootable image I'm making available (see below) contains a unix
kernel ready for running off an RD52 or RD53 /dev/ra0a, expecting to
have /dev/ra0c (blocks 27000 through 30099) available for use as
swap. Don't install it on something where that's not OK. Actually,
don't install this on anything that already contains anything you'll
mind accidentally losing; it's very lightly tested code.
As long as you have the new C compiler (e.g. the one from UBC) installed, the driver is a drop-in, and gives you MSCP support on hardware v6 will run on. Put the two files in /usr/sys/dmr/, compile the driver (ncc -c -O ra.c), add it to the library (ar r ../lib1 ra.o), and you're ready to configure and build kernels using it.
Before building a kernel, it must be configured. I have a patch to mkconf.c, which is all that's needed. Configure and build a kernel in the usual way.
The boot sector is built just like the other single source boot sectors: as rauboot.s; strip a.out; cp a.out /usr/mdec/rauboot. Here's a patch to the run script.
Note: the executable header is left on rauboot as installed under /usr/mdec/. mkfs needs to see it, and removes it before installing in sector 0 of a disk. To install it there manually, e.g. using dd, you'll have to skip the first 16 bytes of the file; the header must have been removed for the disk to be bootable.
The new files are a drop-in fit into the UBC distribution, as well, and you can easily figure out from the above what to do. However, as that system is already set up to be able to run on an 11/23, and they used a different method for configuring kernels, there's a more comfortable way to configure it.
In /sys/conf/ on the UBC system, you'll find a configuration script and a companion awk program that have been used to prepare kernel configurations and makefiles for building. Clearly, this wasn't done on the actual 11/23, as while there is an awk there, it's not able to do this job, because shoe-horning awk into a system without separate I and D spaces means hobbling it to the point where this configuration script is asking too much of it. However, by pulling the relevant files out, and running awk on another system, configurations can comfortably be prepared, and the small files generated moved back to the 11/23 for the actual kernel building.
Incidentally, for moving small files back and forth, since I have the serial console of my physical 11/23 in a window on my workstation, I use uuencode and uudecode to copy and paste. The bootable floppy image, below, has the binaries.
Here's a patch to the data files with the device information, to bring them up-to-date with the actual UBC system, and add the ra driver to them. I've also packaged the configuration files I used for my RX50-as-ra1 and RD52-as-ra0 kernels, along with the generated files from the config runs on them.
A few more changes are still needed, though:
The initial setup and installation on my physical 11/23 was done by booting from RX50 floppy, and also using the RX50 drive to move files back and forth. As I have a 2.11BSD system with RX50s in it, that was a really simple solution for me. The floppy needs to be booted from MSCP device 1 (DU1, RQ1), as the kernel in /unix on it expects to mount /dev/ra1a as root, and have the last 200 blocks (50KW) of the floppy available as swap space. You'll find proto files in /etc/ on the floppy that I've used to make file systems on floppies and on my RD52 disk.
Here's the RX50 diskette image, ready for booting off RQ1 in SIMH, or DU1 in a physical 11/23.