I feel like I should note down a few of the issues I've encountered while trying to be semi-productive with V7/x86. I ran it on qemu/kvm, so maybe some of the weirdness can be traced back to those.
The disk I/O seems to be some kind of disk destroyer, causing a number of very small writes during installation. It seems to be about 20 bytes per write.
The floppy driver did not interact well with the floppy drive qemu emulates. Writing to it worked fine, but trying to read from it renders I/O errors, then writing to it may even cause the system to reboot.
/bin/tbl and /bin/refer are separate executables (instruction and data separated). During the port, support for this kind of executable was removed. refer still behaves erratically, even after recompiling as "regular" executables by removing the -n and -i flags.
/bin/login seems to have difficulties if the first login fails due to the wrong password being supplied, which is behavior not exhibited by V7 on the PDP-11. After the first failed login, no other login attempts seem to go through unless the account has no password to check in the first place. I'm tempted to blame this on qemu, but I'm not sure.
Adding vi and making the console more sane (backspace actually deleting characters instead of having to use #) were nice additions, though.
On the original V7, there are limits to that. The default characters are erase #, kill @, interrupt DEL (commonly represented as ^?).
You can change erase to ^H. You cannot change erase to DEL, which is what many modern terminal emulators send; tmux even outright forces DEL. This is partially because the interrupt character is DEL and that is hard-coded inside sys/h/tty.h. However, even after changing that, rebuilding the entire kernel with make all, changing src/cmd/{getty,login}.c to use DEL for erase, I still got erratic behavior. I'll have to comb through sys/dev/tty.c sometime and see if I can pinpoint the issue that blocks DEL for erase or if there's something in the build setup.
This has been around for a while. While quite remarkable (and I admire it), this effort, IMHO, adds little to whatever you could gain from running Version 7 on an emulator of a PDP-11. If anything, the experience using an emulator feels more genuine; you also get access to the two classic C compilers (and their source code).
It's not V7, but V6 in JavaSciript via emulation has been done twice[1,2]. aiju's code in particular would probably be fairly usable as a base if you want to build a version of V7 that runs on from an RK05 disk. V7 does have drivers for it (/usr/sys/dev/rk.c), but none of the default installation tapes have a kernel with support for it. You'd have to install V7 once, rebuild with RK05 support, copy your entire installation and the new kernel to a RK05.
Or you could code a JS driver emulator for the RP04/05/06 to plug into the code.
That's weird because I used an 11-45 with RK05s running V7.
afaicr there was an informal distribution mechanism were you could get a bootable RK05 cartridge from another site so I suppose that's how they got it going.
So I've been digging around and there's another issue. A single RK05 is simply too small at 2.odd megabytes capacity. I assume you did have multiple RK05s in there and split up the filesystem. If so, then aiju's code would probably need other intensive modifications to support multiple of them.
They had a CDC disk pack type drive for the main filesystem (80 meg I think). I guess it is possible they bootstrapped it from a disk pack from another site with the same kind of drive, although that seems a little unlikely. Perhaps the interface was compatible with RL05, something like that. The machine did have multiple RK05s but I don't think they were used beyond boot and transferring data to other machines on campus.
The disk I/O seems to be some kind of disk destroyer, causing a number of very small writes during installation. It seems to be about 20 bytes per write.
The floppy driver did not interact well with the floppy drive qemu emulates. Writing to it worked fine, but trying to read from it renders I/O errors, then writing to it may even cause the system to reboot.
/bin/tbl and /bin/refer are separate executables (instruction and data separated). During the port, support for this kind of executable was removed. refer still behaves erratically, even after recompiling as "regular" executables by removing the -n and -i flags.
/bin/login seems to have difficulties if the first login fails due to the wrong password being supplied, which is behavior not exhibited by V7 on the PDP-11. After the first failed login, no other login attempts seem to go through unless the account has no password to check in the first place. I'm tempted to blame this on qemu, but I'm not sure.
Adding vi and making the console more sane (backspace actually deleting characters instead of having to use #) were nice additions, though.