Venix/86 Challenge

Posted on by

(this is a guest post by Tenox)

I’m extremely busy with some matters and unable to spend much time with computer archaeology. I would like for some much overdue projects to progress independently of myself, so hopefully the community can participate and help out.

Let’s start with Venix/86 which has been awaiting my attention for a while. I have been recently contacted by Alex aka uav1606 who wanted to get it to work. I have since decided to open this up to anyone else interested.

To my knowledge actual install media did not surface so far. However a while ago I came in to possession of a boot disk and a backup of a live system, in form of nine floppy disks which look like a tar archive. In theory it should be possible to boot the xfer disk, format a hard disk and restore the backup system to get a working system.

VenturCom Venix/x86

VenturCom Venix/x86 running on a real AT/286

I’m offering $100 prize via PayPal to the first person who will run Venix/86 on an emulator of any kind (PCE, PicoXT, QEMU, Bochs, Vbox, MESS/MAME, etc NOTE: it doesn’t have to be strictly XT emulator as long as the system works), compiles Aclock and sends me a binary + complete working virtual machine. I will also of course publish it on this blog featuring all your hard work! It will be awesome to see your progress and collaboration in the comments 😉

Everything I have is here: http://www.tenox.net/get/venix21.zip

Update #1: From Frode van der Meeren who is the owner of the floppy disks: “The disk images are not corrupted, the disks only use a different track arrangement. The disks image format arranges the tracks by cylinders, storing head 0 and then head 1, while the actual disks arrange tracks by all cylinders on head 0 then all cylinders on head 1. If you want to mount the images into something else than Venix/86 then you need to rearrange the tracks in the image file.”

Update #2: the competition has been won by Jim Carpenter! Congratulations! Jim has just received the $100 prize. I have received detailed install instructions and will post it in a follow up post 🙂

Update #3: The winning entry, how to install Venix/86 on MESS/MAME

Venix running on MESS/MAME

Venix/x86 running on MESS/MAME by Jim Carpenter

It was a real pleasure to see great community response, participation and most importantly to see Venix/x86 run again!

Stay tuned for another one 😉

30 thoughts on “Venix/86 Challenge”

    • Indeed, xfer worked no worries in PCEm.

      Sadly I couldn’t see a way of mounting the second floppy from xfer, which would have made life a fair big easier.

      If you prep a hdd image with the xfer disk, then somehow mounted the hdd image, you could then untar the backup to it.

      • soviet-pc. narod. ru (remove spaces) here are PC AT & XT emu with possibility to mount two images at time, floppy or hdd, but while xfer was running it’s mount tells only “. not found” & so on. Also it “can” mount a directory like a hdd, but in RO-mode. i stopped my experiments after ancientfs crashed my mac in to “gray stop sign”.

  2. Whoa a contest! And I’m moving aaaaargh!

    Also… lol

    .Hi Mom!
    .Kick Me
    .I’m really the next process down
    .Hi Kids!
    .This space for rent
    .Singin’ in the rain….
    .I am but a Cog in the Wheel of Life
    .Look out!!! Behind you!!!!!
    .Looking for a good time, sailor?
    .I don’t get NO respect…
    .Augghh! You peeked!
    That leaves you $%d in debt
    that leaves you broke
    — You are now Solvent —
    I can’t understand that
    panic: bad monopoly descriptor: orig = %d

  3. Seems the backup is broken. I can bruteforce the untarring of the data from the xfer boot disk, but I guess that the data is too much corrupted, or something like that. I might also be using that tar command wrong.

    Here’s something I did:

    mkfs /dev/w0.sys 55456
    mkdir mnt
    mount /dev/w0.sys /mnt
    cd /mnt
    tar xf9 /dev/rf0

    The commands I copied from the wizard thing, the number in mkfs is what was suggested by the Winchester hard disk utility. Basically, I was able to one-shot make a FS, mount it, then using tar in it.

    The result is the same than if you follow the steps in the wizard.

    Here’s the steps I follow with the wizard, parts in brackets are elided or comments:

    Do you wish to prepare the winchester hard disk […] y
    Part I
    Are the default winchester partitions acceptable? y
    Part II
    Do you wish to create the user area? y
    WARNING: There is a VENIX file system already on the user area. Do you wish to continue? [If you retry] y
    Do you wish to check for bad blocks on the user area? n [It’s just slow]
    […]
    Remove the XFER floppy and insert USER 1 floppy in drive 0.
    Press ‘return’ to begin the tar extract to the winchester.

    Here is what I’m doing, and it’s possibly wrong: Insert BACKUP1.IMG, press return, hit a SOFT ERROR, press I until it beeps and asks to insert floppy 2. Repeat for every floppy disks it asks. Here’s the number of times I had to hit ignore: (1: 29, 2: 4, 3: 0, 4: 2, 5: 2, 6: 1, 7: 2, 8: 15).

    It should have asked for a total of 8 floppy disks.

    Then, insert back XFER as asked.

    The user area should be complete.

    Part III
    Do you wish to create the system area? y
    […]
    Remove the XFER floppy and insert SYSTEM A floppy in drive 0.
    Press ‘return’ to begin the tar extract to the winchester.

    Well, here’s where it’s a bit weird. You do the same dance, try to extract stuff… It asks for SYSTEM A, then for “floppy B”, which I’d assume would be “SYSTEM B”. If you do the math, BACKUP 1 through 9 makes 9 disks. We used 8 for User, then are using one for SYSTEM A. There is no SYSTEM B. Just for fun, I continued using the same floppy, to see how many SYSTEM disks it wants. It wants A through E; 5 floppies.

    If I understand properly, and the backup was not full of soft errors, we’d need 13 floppy disks.

    I looked at the floppies, it seems that 1 through 8 are for the user area, and the last one, 9, looks like it could be any one of the 5 system disks.

    Here’s a random thing I did, looked at the first couple of bytes in all floppies:
    https://gist.github.com/samueldr/8ed2f6b895c4d72bc065

    BACKUP1.IMG has a ./ directory entry, but looking, with xxd still, at the file, it looks like all directory entries are for /usr.

    BACKUP9.IMG might not be SYSTEM A, but another one as, I might be wrong, I believe the first volume from the archive would also have the ./ directory entry. It also does not have the ./bin/ directory entry, but has many entries under it. It has ./lib/ and ./dev/ with a couple device nodes.

    There is also a crude file listing in the gist. I think, though I could also be wrong on that matter, that entries in the tar files are all aligned, this alignment makes it easy to peek without parsing the file at the filenames.

    It might be possible to salvage many things from the backups, they might not even be broken, it might be the emulation that does weird stuff. I just wasn’t able with PcEM to do anything with them.

    Oh boy was that a ramble. If you need more infos about what I did, do ask, I’m mainly grasping at straws here.

    Closing notes, or: TL;DR:

    Even if the backups were good, it seems we’re missing 4 backup disks from the system files. We seem to mostly have the 8 backup disks from /usr/.

    Random notes:

    I am pretty sure the number in the tar command is the amount of disks to process, and when followed by a dash, the tar output will use letters instead of numbers.

    When manually untarring the data from the backups with the xfer disk, I has a couple files. I believe they were mostly the same files I had when untarring using gnu tar or bsdtar on my linux box.

  4. The backup images are either weirdly interleaved or somewhat corrupted (or both): between valid data blocks, there are blocks of constant 0xf6 and block with “pieces” of :”something” that contains microemacs-like commands.

  5. They seem to be interleaved; upon dropping each second 15 sectors (halving the files) everything (that remains) seems to be aligning nicely. Of course this doesn’t mean that the file contents are correct, just that the next header is in the expected position. Nevertheless, that is *very* strange. At first the impression was that maybe that version of TAR would first fill-up one side of the disk and then the other. Alas, no.
    I have written a quick and dirty C program just to check the tar format alignment, and so far, besides the few bad tracks the interleave seems to be the biggest problem.

      • I posted that comment last night (EET), it took a while to appear (the update was not visible at the time). I’m glad that my intuition proved correct, however, the trouble is that the second side doesn’t seem right. I havent’t tried running on emulators, just looking at .IMG files. I can extract all but the last file from side 0 of each disk, and at least the text ones look right. I can’t check the binary ones, of course. However, if I try continuing on side 1 they don’t look right… I think I got it!
        (answer in next post, I have to check!)

      • That’s it! The pattern is all the tracks from side 0, then *backwards* from track 80 from side 1. It makes some sense, why move the heads 80 tracks in the middle of the operation?
        So yeah, I can confim that the backup disk are fine, everything can be extracted using regular tar from the images, once they are properly arranged.

      • Thanks for the great challenge. Now, if I would only know the filesystem structure, I could build the virtual harddrive without bothering with XFER 🙂
        By the way, @samueldr – as was stated in the first message, this is not a software distribution (or installation kit), but only a backup of a running system, I believe that XFER is having trouble with that.

  6. Got it!

    I’ve got a virtual hard drive properly partitioned and booting. All backups restored perfectly. And aclock seems to be running flawlessly.

    Some quick pictures: (hope I got all the links right)
    https://s3.amazonaws.com/jim02762/Venix/aclock/0004.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0005.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0006.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0007.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0008.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0009.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0010.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0011.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0012.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0013.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0015.png
    https://s3.amazonaws.com/jim02762/Venix/aclock/0016.png

    If Tenox would shoot me a private e-mail I’ll get the HD image and aclock binary to him.

    This was fun.

    Jim

    • You can always talk to ESXi without vcenter, but a client that doesn’t need flash?!? Now we’re talking!

      Too bad the site is down, maybe it’ll be fixed later.

    • Unfortunately, after “Part I” I always get this message (on PCEM, on real XT, AT…):
      “Are the default winchester partitions acceptable? Yes
      System = 64776 blocks
      Swap = 750 blocks
      Temp = 0 blocks
      User = 0 blocks
      AT Timeout waiting for 80 to be 0
      At drive failed to go not busy

      Error on the Winchester, unit 7
      AT Drive never went ready
      while writing block number 0. Status 00
      “

      • On PCEM generic 386 with ~33MB HDD (CHS = 512,8,17) it doesn’t have any trouble there. On real 286 with 80MB Caviar I partitioned it without trouble (during my experiments; I did not yet install it on the real HW).
        It seems that VENIX uses BIOS for HDD access, so unless you go crazy with disk size (30MB is quite enough) there shouldn’t be any problems on that side. Indeed, on QEMU it doesn’t work, but on PCEM it works fine. I have not tested other emulators.
        As I said, CGA was just because I didn’t bother to download VGA roms at that time; it’s not relevant. You do need an AT-class computer (real or emulated) because the BACKUP disks are 1.2MB and XT didn’t have 1.2MB drives.

    • WOW! Thank you so much for this. I think the challenge is long over for Venix/86 but this definitely deserves a gold medal of some kind! 🙂 I will see if I can install it on Qemu or 86box. Thanks again!!!

Leave a Reply