16 ms·

V7/x86 – x86 port of Unix V7

57 points by beefhash 9y ago

dboreham 9y ago
Brain sets to work thinking...surely there's a JS/WebAssembly port of V7? Google says no though :(
- monocasa 9y ago
  You might be able to patch JSLinux's underlying emulator.
- beefhash 9y ago
  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. [1] http://aiju.de/code/pdp11/ http://aiju.de/code/pdp11/ [2] https://github.com/takahirox/pdp11-js https://github.com/takahirox/pdp11-js
  - dboreham 9y ago
    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.
    - beefhash 9y ago
      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.
      - dboreham 9y ago
        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.
beefhash 9y ago
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.
- Aloha 9y ago
  the backspace thing is I think configurable based on your terminal or using stty to do it.
  - beefhash 9y ago
    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.
Koshkin 9y ago
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).
emersonrsantos 9y ago
Sucessfully booted the demo image on VirtualBox after converting image, in a 32-bit machine and IDE. Resembles modern BSD a lot, as expected. EDIT: The demo image contains these games: arithmetic, backgammon, fish, fortune, hangman, lib, quiz, words and wump.
thriftwy 9y ago
Anybody got a qemu command line to run installer against blank disk image?

57 points by beefhash 9y ago

dboreham 9y ago

Brain sets to work thinking...surely there's a JS/WebAssembly port of V7? Google says no though :(

monocasa 9y ago
You might be able to patch JSLinux's underlying emulator.
beefhash 9y ago
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. [1] http://aiju.de/code/pdp11/ http://aiju.de/code/pdp11/ [2] https://github.com/takahirox/pdp11-js https://github.com/takahirox/pdp11-js
- dboreham 9y ago
  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.
  - beefhash 9y ago
    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.
    - dboreham 9y ago
      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.

beefhash 9y ago

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.

Aloha 9y ago
the backspace thing is I think configurable based on your terminal or using stty to do it.
- beefhash 9y ago
  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.

Koshkin 9y ago

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).

emersonrsantos 9y ago

Sucessfully booted the demo image on VirtualBox after converting image, in a 32-bit machine and IDE. Resembles modern BSD a lot, as expected. EDIT: The demo image contains these games: arithmetic, backgammon, fish, fortune, hangman, lib, quiz, words and wump.

thriftwy 9y ago

Anybody got a qemu command line to run installer against blank disk image?