After pondering the strange TeleDisk images of SCO XENIX 386 2.2.3 (released in 1988) and not being able to make heads or tails of it, I decided it was time to simply restore the TeleDisk images onto actual floppies and boot those on a real system.
This was not entirely straightforward. The images were of 720K 3.5″ disks. On a typical system, DOS is unable to format a 1.44M 3.5″ disk as 720K; I know that from experience. TeleDisk did not fare any better. It would simply not write the 720K image onto a high-density 1.44M disk (and of course I don’t have any actual 720K disks anymore, or at least not ones I’d want to overwrite). That raised two questions: why, and what to do about it?
The latter is easier to answer. Either tape over the ‘density hole’ on a HD disk, or fill the hole with a wadded piece of paper (newspaper works well). I took the latter route, fixed up two floppies, and that allowed TeleDisk to write the 720K images (and also enabled DOS to format the floppies as 720K).
Now back to the first question: Why won’t a PC format a 1.44M floppy as 720K? That should be perfectly possible, since 720K media just uses one-half the bit density. The preceding paragraph hints that it is physically possible, but something normally prevents it. Obviously the density detect hole (found opposite the write lock on HD 3.5″ floppies) has something to do with it.
In PS/2 systems, it is reportedly possible to format 1.44M media as 720K without too much hassle, with the caveat that the disks may cause trouble in actual 720K drives. In typical PCs, it simply doesn’t work. 3.5″ floppy drives have a mechanism to detect the media density; some drives can also be configured to report the detected density on pin 2 of the drive interface (HD OUT signal).
In typical PCs, the drive does not utilize the HD OUT signal as the host system wouldn’t know what to do with it, either because the floppy controller doesn’t support it or because the BIOS doesn’t. Instead, the floppy drive detects the media type and prevents the host system from reading/writing the medium unless the correct data rate is used (the 720K media use MFM encoding at 250kbps, with the disk rotating at 300rpm; the 1.44M media are very similar with the key difference that 500kbps data rate is used). In fact the data rate is how operating systems typically distinguish between 3.5″ media types—if it can be read at 250kbps, it must be a 720K disk, at 500kbps it must be a 1.44M medium.
The obvious benefit of this scheme is that a 720K (double-density, or DD) disk cannot be accidentally formatted to 1.44M; while that might be possible, data loss would be highly likely to occur sooner or later. The less obvious drawback (perhaps not even considered a drawback by the original implementors) is that a 1.44M disk cannot be formatted to 720K because the drive will prevent it.
Note that for 5.25″ high-density drives (1.2MB), the controller may need to correctly output the DENSEL (Density Select) signal on pin 2 of the drive interface. It appears that in most 3.5″ drives this signal is not utilized, or at least not by default. The drive itself is in control of media density detection, with no input from the host. The host system merely needs to select the data rate appropriate for the medium (250/500kbps).
Anyway, back to XENIX. TeleDisk restored the strange images without complaint, which confirms that there is nothing wrong with the TeleDisk images per se. Although it is questionable whether the disks corresponded to the originals; the trouble is that when sectors with duplicate IDs exist on a single track, they cannot be reliably written to. That might be a part of a copy protection scheme… then again it might not.
With the two boot floppies in hand (traditionally designated as N1 and N2), I set out to boot them on two different systems. On a Pentium II class machine, the XENIX 2.2.3 kernel panicked due to a trap almost immediately. Too new perhaps? Not sufficiently PC compatible? Who knows.
On an IBM ThinkPad (ironically a newer machine, with a Pentium M processor), XENIX got further. The kernel started up and started reading the second (filesystem) floppy. Sadly, after a while XENIX started making grinding floppy seek noises and announced that it couldn’t read a block off the disk. So that was that.
Maybe uncorrupted floppy images of XENIX 386 2.2.3 will surface eventually…