Despite promising myself that after I'm done with Snoopy Calendar and Venix/86, my next post won't be related to virtuallyfun, there has been yet another impossible to avoid challenge! As usual, an obscure system that I knew nothing about. However, it is an Unix system, so there are some things that are known by default. First things first: get the floppy image to boot. The challenge page states "[...] made some modifications to get them to boot on VirtualBox". It seems that since then, Oracle has made some modifications to VirtualBox so that it no longer boots, instead failing with "cannot open root device", although that's only a floppy so far.
Next try was QEMU (it's quite handy) - it flashed some text and then a blank window.
PCem with TVGA would start OK then garble the text. Apparently it did work, only the video memory was garbled. I remembered that 1. TVGA was just a little bit different at the time1 and 2. PCem also emulates a Tseng ET4000 VGA. Once this was selected, surprise, the picture was fine. However, there is another problem with PCem. Despite detecting and partitioning the drive without a problem, it stops with an error when "Checking for bad sectors in the UNIX System partition..."
After various experiments to get rid of that error I concluded that it might be a timing problem and went for the real thing. That is, a 386 with 5.25" floppy. This would also allow me to eliminate any potential problem with conversion from IMD to raw, because I wrote the floppy with IMD. However, this 386 has a Trident VGA card inside, so... tough luck - the image is again garbled.
Two more tries (a Cirrus VLBus on a 486 and a PCI S3 on a Pentium) have the same problem. Now I'm thinking that maybe I should have tried the other diskette image (WYSEBASE.IMD) too, but I doubt it would have made any difference, the kernel from tape is different and shows the same problem. I think it might be possible to reconfigure the kernel though.
When thinking what emulator to try next, getting desperate enough to think "where did I put those old Virtual PC kits?", I remembered bochs. Maybe it will have an older VGA and also not have problems with the HDD. I don't think I ever used bochs before, but I heard about it from a friend that is/was into OS building. Surprisingly, bochs' Slackbuilds page doesn't list any dependencies (quite rare, these days). I always like that. While it's compiling I play a little more with the real hardware (the other 2 tries above). Running bochs gives the same "blank" display as QEMU but this time with a clarifying message:
02292337304i[XGUI ] charmap update. Font Height is 16
So that's what's going on. And having a debug message on this, I gather there must be some possibility to de-activate this. Alas, no. All searches return various discussions from back in 2002 when probably this feature was developed. Nevertheless, bochs allows me to see what's on the screen by using its snapshot tool. A little cumbersome, but at least I get to see it not complaining about bad sectors. This gives me an idea. Apparently all that was stopping PCem from proceeding with creating the filesystem was that check. What if I use "blind" bochs to create the filesystem and take over from there using PCem? Around 10 snapshots later I have a bootable HDD image with only a single partition for root and usr (just in case) that has enough to continue installation from either tape or floppy. And indeed it works in PCem. I also made a clean copy of it, thinking I might trash it in my further experiments.
The above heading seems quite absurd, right? I'm talking available programs. When booting from HDD the installation script can't easily be stopped (by Ctrl-C, say), while the one on floppy is only too happy to drop me to the prompt, I try and continue installation while booting from floppy. Tenox has already given a good pointer for using tape images so I only need access to a minimal Unix in order to do more or less the same. The installation filesystem is slightly less than minimal.
# ls ls: not found # cat cat: not found # echo * INSTALL INSTALL2 LABEL addparts bin core dev etc mkfs.data mnt readfloppy shlib tmp unix usr yes # echo bin/* bin/-sh bin/chgrp bin/chmod bin/chown bin/cp bin/cpio bin/dd bin/ed bin/expr bin /find bin/ln bin/mkdir bin/mv bin/rm bin/sh bin/sleep bin/stty bin/su bin/sync
I looked around the bootdisk image for the installation commands and everything was in plain sight. The relevant command is:
CPIO -icmduB < /dev/rct/c0s0n > /dev/null 2>&1
(a little above in the script /bin/cpio is copied to /bin/CPIO)
I padded the 00001 section with a few K to make sure it would fit with the HDD geometry and then:
I resisted the temptation to reboot from the HDD and see how it works with this partial restore. I was going to do this right. I extracted all the sections in a temp directory under files with:
for i in ../0000? ; do cpio -icmdu <$i ; done
That would extract the entire structure in a directory on my machine. I also created a directory for aclock and copied all the sources there to have them handy (this was a small mistake, old UFS has 14 characters filename limit so the names were truncated).
The script I saw on the bootdisk also ran a lot of other commands to setup devices, runlevel scripts and so on. I copied the whole bunch of commands into a file (h_inst). I noticed that chroot is available under etc/ - that would come in handy.
find | cpio -oc >../nt.cpioCreated a "new tape" file that I again padded with 512K of zeroes, just to be safe and not care about geometry.
Using the "clean" HDD image from an earlier step as first HDD and my padded "nt.cpio" as secondary HDD I booted (PCem) from the WYSEBOOT floppy, stopped the installation process, got to the shell and then:
# mount /dev/dsk/0s1 /mnt mount: warning: <rootus> mounted as </mnt> # cd /mnt # cpio -icmduv </dev/rdsk/1s0 <SNIP> # sync # etc/chroot /mnt /bin/sh # ./h_instThat would execute the "after restore" installation script that starts with a trick question, "Enter your terminal type:". What to answer here? vt100 seems safe, although since it's about the console implemented in Wyse the question seems kind of superfluous.
After the succesful login, I notice the 14 characters filename problem and identify the proper aclock to compile. The K&R version seems to compile fine, but on running it hangs after drawing half a clock. It does this no matter what machine I choose to emulate, it always hangs at the same point.
I try the same hdd image on the (invisible ink) bochs and I see that aclock runs fine on it. Time to dig deeper into the charset problem. Not noticing that bochs has a curses mode I modify the sources to ignore charset changes, rebuild it and it works! Sort of. The clock is running way too fast, but I'm already worried about priority for the challenge so I shoot a quick e-mail to Tenox, just in case.
I then look at the bochs configuration in detail and notice that the Clock & CMOS options configuration menu, where I can set Synchronisation method to realtime (from none) and also Sync RTC speed with realtime: yes (default no). After that the clock is running fine, so I send another mail and post a comment on the challenge page. Something else I noticed was that for some reason Ctrl-C would not return me to the terminal (although it would stop aclock). Remembering DOS days I try Ctrl-Break and it works, returning to the shell. Nice of bochs to pass Ctrl-Break through.
Being now at ease with the challenge, I look for ways to improve things. Sometime during the above frentic search for solutions I thought about using MAME/MESS as well and started a compile on it. It's taking a while (I think it passed the hour mark). In the meantime I make some more tries with PCem and notice that in fact the system clock in PCem is not advancing. Each date invocation returns the same time. Well that explains the hangs (it also would hang on shutdown, not only running aclock).
When building of MAME/MESS is finished, I set out to finding the "at386" and "at486" packages and notice that the default VGA card for those packages is the same Tseng ET4000 that I knew worked in PCem. A quick hdd conversion (chdman createhd -i wyse_1000_16_63.img -o wyse.chd) and configuration later, my hdd image proves to be working in MESS. However, MESS doesn't seem to be able to use 2 HDDs for a machine, so while it can be used to run the system, it can't be used for installation.
Only at this point I realise that both bochs and QEMU have a curses mode. Of course, in curses there would be no charmap problem. Indeed, when trying the currently built image, it works fine in both cases.5
The next improvement is avoiding to use the script copied from inside the BOOT image. I instead modify the boot image to restore from second HDD insted of tape. This results in the install script running correctly (and asking for root password).
# shutdown -y -g1 Shutdown started. Mon Sep 21 19:35:12 PDT 2015 Broadcast Message from root (console) on awyseclk Mon Sep 21 19:35:12... THE SYSTEM IS BEING SHUT DOWN NOW ! ! ! Log off now or risk your files being damaged. # INIT: New run level: 0 The system is coming down. Please wait. System services are now being stopped. cron aborted: SIGTERM ! SIGTERM Mon Sep 21 19:35:18 2015 ! ******* CRON ABORTED ******** Mon Sep 21 19:35:18 2015 Print services stopped. The system is down. Reboot the system now.
1 The reason I remember this is because 20 years ago I had to run the DOS Z80 emulator with -xv option for
"400-line VGA (for some Tridents)".
3 sync; sync; reboot (on old SCO Unix box, perhaps others as well). I don't know if so many syncs are really needed (the last one should be enough) but their install script is full of them, so I play it safe.
4 ...All right, Gordon. Your suit should keep you comfortable through all this.
5 My version of QEMU (2.3.0 compiled from slackbuilds a while ago) seems to be having some problems with storage. I noticed it happening with DOS guests and now it's happening with Wyse as well - rare random read errors from the virtual HDD. Switching to qcow2 format from raw doesn't help. Fortunatelly the newest version (2.4.0) seems to work fine.