Stories
Slash Boxes
Comments

SoylentNews is people

posted by NCommander on Monday March 13 2017, @04:00PM   Printer-friendly
from the you-are-in-a-maze-of-twisty-passages-all-alike dept.

This is the third exciting installment of this ongoing saga of restoring Xenix 2.2.3c. When we last left off, we had discovered that it is possible for Xenix to boot with several sectors missing in /etc/init and that the vast majority of the data on the diskettes was intact — to the point that several more steps of the early installation completed.

post reboot, insert disk

The story thus far:

[Aside: Quite a while ago, I came across the excellent OS/2 Museum, run by Michal Necasek which helps categorize many of the more obscure bits of PC history, including a series of articles about Xenix, Microsoft’s version of SVR2 UNIX.]

If we were to get any further, Michal and I would have to dig deep into the world of teledisk, floppy disk formats, and perform some creative thinking.

Sector Detector

The first step to solving a problem was characterizing it. That meant that the data we did have was almost certainly correct and that they corresponded to the sectors that existed on the disk. Michal had earlier confirmed that the TeleDisk images of Xenix 2.2.3c at the very least were internally consistent. As he worked on the TeleDisk images, I worked on characterizing the damage on the raw images.

The raw images indicated missing sectors by filling them with 0xF6 (unformatted) and were always in multiples of 512 bytes, consistent with the size of an individual sector. As such, I needed to know where in the disks we had holes. After a few hours of tinkering, I wrote sector_detector which generated this list.

Lots of numbers, right? Well, it’s not quite as bad as it looks. By using a hex editor and comparing strings, I got an idea of what is and isn’t missing. In the case of N1, it simply looks like there are some bits of junk data at the end of the filesystem which is why the output is so noisy. As I wrote to Michal, here was my initial report on what is and isn’t there.

The report attached is based on the original Xenix disks, and not ones
I modified.

Here's the good:
 - N3, N6, and B2 are healthy out of the box
 - B1 has a missing sector your already found.

 - The large number of free blocks at the end corresponds with the end
   of a set. N3 is the last disk the system needs for minimal
   installation.

 - On the whole, we're only missing one or two sectors from each disk

 - N2's missing 0-1 is probably "intended", since that's where the
   boot record should sit. Likely an artifact of how the disks were
   made originally.

 - The other two missing sectors on N2 are both init. As we've got a
   spare copy of this, I can reasonably say we have a complete set
   of minimal images now.

Here's the damage elsewhere:
 - N5: both: ./usr/bin/[a]db (ouch)

 - X1: both are uucp, code
 - X2: doscat, data section
 - X3: 1: /usr/spool/lp/model/imagen.spp - shell script for printer driver
       2: The divider between banner and /usr/bin/newline. Not exactly
          sure how much is lost, but the XOUT file looks like its all there.
          I see the header. Filename obtained from the manifest
 - X4: /etc/sysadmin. Shell script. The missing bit is in the backup
       Xenix code (IRONY!)
 - X5: Tailing end of dc, start of calendar. Mostly the tar header.

 - I1: part of ctype or calendar. Code
 - I2: /usr/lib/mail/alias. Code
 - I3: Part of the keyboard map script

(There was also damage on N1 that I wasn’t able to characterize at the time due to the fact it was filesystem formatted, and not a tar archive. This was noted shortly later. N4 also had a missing sector which I left out of this email by accident, but that bit of recovery has an article to itself.)

As I previously noted, the first two disks have a standard Xenix filesystem + bootsector. The others are simply raw tar images. As also noted by Michal’s report, he had successfully managed to extract some information from the TeleDisk images. To understand how, we need to break for a moment and dig into the nitty gritty of floppy disk formats.

Floppy Disks: An Overview

Most of the older users here remember floppy disks of various formats, low destiny, double destiny, 8in, 5.25-inch, 3.5-inch, and more. Many fondly remember them as a simpler era, or as those infernal devices that eat your data and caused no end of grief. Fewer people understand the specifics of how floppy disks are read, written and encoded.

In a broad sense, floppies are organized in the form of sides-tracks-sectors, identical in many respects to terms used to describe hard drives that use cylinders-heads-sectors. When we think of media, there are two ways to think of it: in terms of logical addressing or physical addressing. Normally, when we say that a file lives at 0x800 on a disk, it needs to be mapped to a physical location. For devices of the era, this mapping was known as drive geometry. By knowing the geometry of a drive, one can say definitively that a file at logical address 0x800 physically resides on side 0, track 0, sector 4.

NOTE: For clarification, sides and tracks are counted starting from 0, but sectors start at 1 and represent 512 bytes. Keep this in mind if you are checking my math by hand.

For normal disks of a given type, one can be reasonably assured of its geometry. For example, the Xenix 2.2.3c floppy disks are 720 KiB, and correspond to dumps of 3.5-inch double-density media. In drive geometry terms, that means by convention the data should be organized in the form of 2 sides, 9 tracks per side, and 80 sectors per track.

However, if one is careful, and understands the specifics of how floppy drives work, it is possible to use non-standard geometry successfully; this was the basis of most of the copy protection systems of the era that would made duplicating disks much more difficult. This functionality could be used as a form of emulation; for example, it is possible to use 5.25-inch geometry on 3.5-inch disks for cases of backwards compatibility. It can also be used to extend a disk past the 720k/1.44MiB mark; for example, Windows 95 shipped on 13 floppies, each of which contained 1.61 MiB.

When a computer talks to the floppy disk controller directly, it indicates the track or sector numbers it wishes to access. As a quirk of how floppy drives work, flat files can only represent disks with traditional geometry. Disks with a non-standard geometry cannot be accurately reproduced by a flat image file or by the standard tools of the era. Special archival tools such as TeleDisk, which knew how to directly interface with the FDC could, however, successfully image and reproduce these disks.

TeleDisk: Bane of Copy Protection

Due to the flakiness of floppies of the era, an entire cottage industry popped up of applications that could successfully copy non-DOS floppies, especially those with non-standard track geometry. One of the most common ones was a DOS utility known as TeleDisk, a shareware utility sold by a company known as Sydev, which wrote files in the form of TD0 files.

Unlike DISKCOPY, TeleDisk directly interfaced with the disk controller, and enumerated each disk’s side, track, and sector count, and stored these in a special file which could accurately represent and retain this information. TeleDisk’s custom format stores each track and sector ID in its own data block, and can represent any type of format that can exist on the physical medium. As such, it could accurately track which data was where, and could successfully map (though not reproduce) bad sectors and such when imaging a disk.

Raw images on the other hand can only accurately represent data in a linear format. Floppy disk emulators such as the one in VirtualBox must map raw sector commands to linear file locations, and can’t (easily) work with non-standard disks, and by default corresponds to a 1.44 MiB floppy disk. Recent versions of VirtualBox have some ability to do media detection based on the size of the floppy disk, while older ones allow you to override the media detection via an advanced option.

Over the years, the TeleDisk format was successfully reverse engineered and documented, and Michal had a set of tools to work with and manipulate them. From his side, he determined the following missing and duplicated data from the disks. From his e-mail:

I attacked the problem from a different angle, the TeleDisk images. Here’s a quick report:

 - Disk B1:
   - track 31, side 0: duplicate sector 6, 9
   - track 68, side 0: duplicate sector 5, 6, 7
 - Disk B2: all OK

 - Disk N1:
   - track 33, side 1: missing sector 6
 - Disk N2:
   - track 39, side 1: missing sector 6, duplicate sector 2, 3, 9
 - Disk N3: all OK
 - Disk N4:
   - track 36, side 1: missing sector 5, duplicate sector 2, 6, 7, 8
 - Disk N5:
   - track 65, side 0: missing sector 2, duplicate sector 4, 5, 7, 8, 9
 - Disk N6: all OK

 - Disk X1:
   - track 61, side 1: missing sector 8, duplicate sector 1, 2, 4, 7, 9
 - Disk X2:
   - track 68, side 0: missing sector 5
 - Disk X3:
   - track 30, side 0: missing sector 3, duplicate sector 1, 5, 8
   - track 61, side 1: missing sector 8, duplicate sector 1, 5
 - Disk X4:
   - track 65, side 0: missing sector 9, duplicate sector 1, 3
 - Disk X5:
   - track 32, side 0: missing sector 2, duplicate sector 1, 5, 8

 - Disk I1:
   - track 32, side 1: duplicate sector 1, 8, 9
   - track 65, side 1: duplicate sector 1, 4, 5, 6, 7, 8
 - Disk I2:
   - track 32, side 0: duplicate sector 1, 5, 9
 - Disk I3:
   - track 64, side 0: missing sector 3, duplicate sector 8

I *might* have missed something in case there are exactly as many duplicates as there are missing sectors on some track.

As you can see, there is a bit of a pattern. The problems are all in the track ~34 and ~64 range, plus or minus a few. When there is a problem, there are often sectors missing as well as duplicated, but sometimes there are only missing or only duplicated sectors. Problems happen on both sides of the disks.

Through comparison, we determined that the raw disk images and the TD0 files we had, corresponded to the same dump as the missing sector locations lined up with each other. It is extremely likely that the TD0 files were created first (in 1996 according to the time stamp), and then converted to flat files at a later time. As such, any attempts at locating additional data would have to come from the TeleDisk images, something that Michal managed a breakthrough on.

In a few cases, the missing sectors in the raw were copied by a duplicate sector with the wrong header later in the TD0 file, and Michal was able to reassemble these bytes that way. Through that methodology, he managed to restore B1, I1,I2, and one of the sectors of N5. This gave us a (mostly) complete set of base media to work with! With these recovered sectors, the installer could now successfully run through a minimal installation:

insert disks configure timezone basic installation complete

Selecting "Continue installation" would cause it to prompt for more disks and then die due to the broken manifest on N1 and due to missing sectors on the remaining disks. However, selecting "Stop installation now" would reboot the system, and successfully bring it up in multiuser mode!

Not a bad place to be considering where we started but we could do better. In addition, with a working Xenix 2.2 system on hand, I could confirm that Xenix itself uses normal disk geometry, and wouldn’t have been able to read non-standard disks out of the box. This was collaborated by the fact that if one removed the duplicated sector IDs, and added in the missing ones, I got a total of 1440 sectors per TeleDisk file, which corresponds to what you would expect to see for a normal diskette. As such, we were looking at floppy disk corruption or (more likely) a bad dump caused by a bad floppy drive or a TeleDisk bug due to the damage being consistent in similar locations on each disk.

Interesting Coincidence

At this point, I was going to go into further details on how the Extended Utilities disks were reconstructed, when something very interesting happened. Michael posted his version of the first part of this story on the 9th. In the comments, one John Elliott dropped a link to a more recent dump of two versions of Xenix 2.2 386 taken on March 5th (the day before Part 1 went up). Unless one of the SoylentNews editors is secretly holding out on me, it’s utterly bizarre that this surfaces now.

A quick check of the disks show that they appear to be completely intact (sector_detector didn’t show any missing bits), but these are not the same dumps we were working from. After pulling the disks apart, the disks correspond to Xenix 2.2.3c or 2.2.2j for the 386PS, while our dumps correspond to 2.2.3c 386AT.

386PS in this case corresponds to IBM’s PS/2 line of computers, which were based on the MicroChannel Architecture (MCA), and not the more common ISA/AT-compatible machines of the era. As such, the 386PS disks, while bootable, panics right after startup trying to enumerate devices.

386PS kernel panic

A review of the kernel link kit shows that this kernel is *very* similar to our 386AT kernel, with the primary difference being that the HDD driver is “hd”, vs. “wd”, and a few MCA configuration files are present within the link kit for tape backup devices.

Unfortunately, to my knowledge, there is no known emulator for MCA-based PCs; MAME has support for the PS/2, but only emulates an ISA-based variant. If anyone here has an MCA based PS/2 machine with a 386 processor, it should be possible to run and install these images; if someone wants to try, drop a line below. I may also try taking these disks, and swapping the kernel on N1 for the 386AT based version to get them running.

These disks also have answered a few lingering questions we had about the sector reconstruction, but we’ll get that into that more in the next installment :)

If you enjoyed this article, please consider subscribing or gifting a subscription to help support SoylentNews.

~ NCommander

[martyb here. I don't know how many here recall, but when SoylentNews got started over three years ago, it took some up-front money to get servers spun up, domains registered, etc. NCommander put up personal funds towards that end and he has not yet been paid back even one cent. Once we have our operating expenses covered, it would be really nice if we could start repaying him. Several people have subscribed multiple times and/or offered more than the minimum subscription amount in the past — quite frankly, without their generosity, this site would have folded long ago. Please accept my heartfelt thanks to all who have contributed to the site. I continue to be humbled by the generosity and wisdom I see shared on our pages. Thanks to you all. ]

Related Stories

Restoring Xenix 386 2.2.3c, Part 1 65 comments

One of my favorite hobbies is both retrocomputing projects, and the slightly more arcane field of software archeology; the process of restoring and understanding lost or damaged pieces of history. Quite a while ago, I came across the excellent OS/2 Museum, run by Michal Necasek which helps categorize many of the more obscure bits of PC history, including a series of articles about Xenix, Microsoft’s version of SVR2 UNIX.

What caught my attention were two articles talking about Xenix 386 2.2.3c, a virtually undocumented release that isn’t mentioned in much if any of the Santa Cruz Operation's (SCO, but see footnote) surviving literature of the time. Michal documented [1], [2] his efforts at the time, and ultimately concluded that the media was badly corrupted. Not knowing when to give up, I decided to give it a try and see if anything could be salvaged. As of this writing, and working with Michal, we’ve managed to achieve approximately 98% restoration of the product as it would have existed at the time.

Xenix 386 booted with uname

I’m going to write up the rather long and interesting quest of rebuilding this piece of history. I apologize in advance about the images in this article, but we only recently got serial functionality working again, and even then, early boot and installation has to be done over the console.

* - SCO in this case refers to the original Santa Cruz Operation, and not the later SCO Group who bought the name and started the SCO/Linux lawsuits.

Read more past the fold.

Xenix 2.2.3c Restoration: No Tools, No Problem (Part 2) 38 comments

When we last left off, with the help of the excellent Michal Necasek of the OS/2 Museum, we had gotten the damaged Xenix 2.2.3c past the first hurdle of installation, and directly into a post-reboot crash, the cause of which (at the time) I suspected was another emulation failure.

*

Needless to say, I needed to get past this. At this point, I have been examining the raw images as best I can, and figuring out how the installer comes together. After a few experiments, I managed to determine a few basic facts about how Xenix is installed when booting from N1/N2:

  • Coming out of reset, the Xenix kernel loads from N1, prompts for the "filesystem floppy" and starts /etc/init or /etc/inir coming out of IPL
    • Init prints the "Entering System Maintenance Mode" line.
    • Inir is used for running fsck, if necessary. Afterwards, it starts init.
  • Initially, the system starts /usr/lib/mkdev/hd which does the following
    • Format the Xenix partition, create slices, and mount the hard drive under /mnt
    • Compile the keyboard configuration files so the language selection sticks past reboot
    • Create a few device nodes manually
    • Cpio is used to copy a list of files from N2 to the root partition.
    • /profile.hd is copied to /mnt/.profile
    • Install a boot sector to the MBR of the hard drive and configure the bootloader for HDD booting
    • The hd script does the initial language selection, followed by fdisk
  • After the completion of the script /.profile is run as the system tries to bring up the root prompt which reboots the system after prompting that N1 should be re-inserted after the boot prompt.

So with knowing what the installer is trying to do, it was time to try and get down and dirty with it.

Xenix 2.2.3c Restoration: Xrossing The X (Part 4) 11 comments

Last time — with the help of the excellent Michal Necasek of the OS/2 Museum — we talked about mapping the damage within the existing Xenix 386 disks and successfully got the system to the end of installation.

*

For those new to the series, I recommend you catch up with the previous three articles:

  1. Restoring Xenix 386 2.2.3c, Part 1
  2. Xenix 2.2.3c Restoration: No Tools, No Problem (Part 2)
  3. Xenix 2.2.3c Restoration: Damage Mapping (Part 3)

Unfortunately, at this point we had exhausted the data we could successfully recover from the TeleDisk images, so now it was time to think laterally in our quest to restore viable installation media. Back in Part 2, I posted the disk headers from each disk indicating what it was and where it was in the set:

./tmp/_lbl/prd=xos/typ=386AT/rel=2.2.3c/vol=N03
./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=B02
./tmp/_lbl/prd=xos/typ=n86/rel=2.2.2c/vol=X01

And also noted that there was a slight version mismatch (2.2.3 vs 2.2.2). What I didn’t point out was the type was different: n86, vs 386AT; Xenix speak for “generic x86” vs. “386 AT”. As Michal and I discussed it, I realized there was another place we could go to find sectors.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 0) by Anonymous Coward on Monday March 13 2017, @04:14PM (8 children)

    by Anonymous Coward on Monday March 13 2017, @04:14PM (#478476)

    Since my comment on the previous part [soylentnews.org] might get missed because it already left the main page, let me re-ask:

    Why is this in Meta? It's neither about this site, nor about the software driving this site, nor about the people operating this site. Adding random stuff to Meta degrades its usefulness.

    • (Score: 0) by Anonymous Coward on Monday March 13 2017, @04:35PM (1 child)

      by Anonymous Coward on Monday March 13 2017, @04:35PM (#478482)

      If you were to argue that posts about people running the site should have a different nexus from posts related to the site itself or rehash, that could make sense, but you seem to think the combination of those in meta is okay, just that somehow this isn't that, and it's really puzzling. How isn't it about the people running this site? You do know NCommander is one of the people running it, right?

      • (Score: 0) by Anonymous Coward on Monday March 13 2017, @05:04PM

        by Anonymous Coward on Monday March 13 2017, @05:04PM (#478506)

        This is not about NCommander, this is about running Xenix on a virtual machine on a modern computer. It is in no way relevant to the story that it was NCommander who spent the effort to get it running.

        Anyway, it should be clear that in this context "about people running this site" means "information about those people that is relevant to the site". If NCommander explained that in the next half year he would not have time for this site, that would be relevant information about NCommander that belongs in Meta. On the other hand, if NCommander decided to learn Perl 6, that wouldn't belong on Meta, unless he planned to rewrite Rehash in Perl 6.

    • (Score: 3, Informative) by FatPhil on Monday March 13 2017, @04:51PM (2 children)

      by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Monday March 13 2017, @04:51PM (#478498) Homepage
      I kinda agree, it's more a "journal" nexus, it's community member generated content rather than stuff trawled from outside. And this is not to be taken as a complaint at all, this is a fun bit of forensics.
      --
      Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
      • (Score: 0) by Anonymous Coward on Monday March 13 2017, @05:16PM (1 child)

        by Anonymous Coward on Monday March 13 2017, @05:16PM (#478516)

        Note that I don't complain about the article; I complain about it being in Meta. Note that the only time you are likely noticing that it is in Meta is when you specifically open up Meta to find site-specific posts (as I did today to add a comment on the latest post about the site update, to add a comment about the size of the "+"/"-" boxes). And it is exactly in that situation when you don't want to search through unrelated content.

        If people think community member generated content needs to be in a nexus other than main page, then a new nexus could be created for it. Anyway, the "Answers" topic also consists of community member generated content (with the exception of the latest story in this topic, [soylentnews.org] of course), but none of them is (nor belongs) in Meta.

        • (Score: -1, Troll) by Anonymous Coward on Monday March 13 2017, @09:55PM

          by Anonymous Coward on Monday March 13 2017, @09:55PM (#478654)

          If people think community member generated content needs to be in a nexus other than main page, then a new nexus could be created for it. Anyway, the "Answers" topic also consists of community member generated content (with the exception of the latest story in this topic, of course), but none of them is (nor belongs) in Meta.

          Thank you for your most valuable and learned opinion. I will archive this in the place [iacpublishinglabs.com] reserved for such wonderful pronouncements.

    • (Score: 2) by martyb on Monday March 13 2017, @08:02PM (2 children)

      by martyb (76) Subscriber Badge on Monday March 13 2017, @08:02PM (#478608) Journal

      Strangely enough, when I reviewed the first article in this series, I noticed it being slated for the Meta Nexus and meant to inquire about that with the intention of changing it to the main page. Got caught up in changing other things and never got back to it. My bad. You raise a valid point in that this series has nothing to do with the site itself which I would characterize as things such as: down time for maintenance, report on why the site was down, site upgrade, site governance, etc.

      I would concur with the assessment that it does warrant a different nexus in that it is original content for the site. Will mention it to the rest of the editors and devs to see what we can come up with.

      In the meantime, I have updated the existing articles in this series to be on the main page nexus, and the upcoming article(!), as well.

      Thanks for calling this to our attention!

      --
      Wit is intellect, dancing.
      • (Score: 0) by Anonymous Coward on Tuesday March 14 2017, @11:34AM (1 child)

        by Anonymous Coward on Tuesday March 14 2017, @11:34AM (#478866)

        Thank you for fixing this issue.

        BTW, can a story be in several nexuses at once? For example, assume writing a community review: This would obviously belong into the Community Review nexus, but it would also be original content, and thus should logically be in that new Original Content nexus. Or consider some original content about politics. That would belong both in Politics and in Original Content.

        • (Score: 2) by martyb on Tuesday March 14 2017, @05:08PM

          by martyb (76) Subscriber Badge on Tuesday March 14 2017, @05:08PM (#478992) Journal

          Thank you for fixing this issue.

          You're welcome! Thanks for mentioning it!

          BTW, can a story be in several nexuses at once? For example, assume writing a community review: This would obviously belong into the Community Review nexus, but it would also be original content, and thus should logically be in that new Original Content nexus. Or consider some original content about politics. That would belong both in Politics and in Original Content.

          And, yes, as far as I know, one story can be listed in multiple Nexuses/Sections... at least the User Interface (UI) for editing stories permits it, but I have not actually tried it. Of course, it naturally follows that I did not think of that until I was updating the last of Xenix stories. :(

          --
          Wit is intellect, dancing.
  • (Score: 3, Interesting) by Runaway1956 on Monday March 13 2017, @04:35PM (1 child)

    by Runaway1956 (2926) Subscriber Badge on Monday March 13 2017, @04:35PM (#478484) Journal

    points up at the images in the submission ^ which can obviously be done after all

    What will those crazy devs come up with next?

  • (Score: 2) by FatPhil on Monday March 13 2017, @05:22PM (10 children)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Monday March 13 2017, @05:22PM (#478519) Homepage
    "... some bits of junk data at the of the filesystem ..." needs an "end"

    "... past the 720k/1.44MiB mark; for example, Windows 95 shipped on 13 floppies, each of which contained 1.61 MiB."
    720/1440 KiB (exact) - 1440KiB is ~1.406 MiB (approx). No idea what the exact for W95 was, but almost certainly a ratio 21/18 higher (a sectors per track change).

    (Oh, episode 2 mentioned "9" as being something apart from sectors per track, maybe tracks per side or something, and if the articles are to be preserved for posterity, which they should be, then that should be corrected.)

    I remember we ran Xenix as a server in my first job out of uni (1992, I guess), and that my boss was an old hoarder, but I suspect even he doesn't have the Xenix floppies lying around still, as he has a wife who values storage space more conventionally.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 0) by Anonymous Coward on Monday March 13 2017, @05:29PM (2 children)

      by Anonymous Coward on Monday March 13 2017, @05:29PM (#478523)

      I don't know about Windows 95, but OS/2 shipped with specially formatted disks that had a higher capacity than with normal formatting.

    • (Score: 1, Interesting) by Anonymous Coward on Monday March 13 2017, @06:14PM

      by Anonymous Coward on Monday March 13 2017, @06:14PM (#478543)

      The term "hoarder" is bandied about too much these days. Actual clinical hoarders live in filth- food wrappers, empty cups, bio-hazard, etc. It's not funny nor cool nor hip to misuse terminology.

      That said, I, like many I know, am not a minimalist, and I happen to have 2 sets of Xenix 2.3 floppies.

    • (Score: 2) by LoRdTAW on Monday March 13 2017, @07:11PM (4 children)

      by LoRdTAW (3755) on Monday March 13 2017, @07:11PM (#478579) Journal

      There was a tool for formatting past the 1.44MB limit. After a little research I found one called FAIZ SuperFormat. Apparently it uses extra space used by the file system for storage. My guess is there is a specific amount of disk reserved by the FAT through a standard format which is significantly reduced using such tools. Probably limits the amount of files/dirs but for compressed installers, not an issue.

      Source: https://groups.yahoo.com/neo/groups/freeware-news/conversations/topics/867?source=1 [yahoo.com]
      Excerpt:

      This is a freeware developed by yours truly. Themain object behind the project was to increase the available disk space . The software changes the way files are stored on the floppy .It utilises some of the space used by the file system to increase the storage space to 1.72 MB.

      • (Score: 3, Informative) by SomeGuy on Monday March 13 2017, @07:58PM (1 child)

        by SomeGuy (5632) on Monday March 13 2017, @07:58PM (#478603)

        If you look at how bits on a disk are physically organized, you may notice that there are "gaps" between each sector.

        Here is an example of one disk where the physical location is graphically mapped so you can see it:
        http://lucasm.cf/?mju0n [lucasm.cf]

        The reason for these gaps is that timing variations can cause a floppy drive to write beyond the expected end of the sector, and overwrite the beginning of the next sector. Placing some gap between each sector helps prevent that.

        In fact, the above image has visible timing "wobbles", suggesting it may have been written on an older belt-driven floppy drive, where such gap would have been VERY important. An image from a newer direct motor drive would usually show sectors much more lined up.

        Anyway, formatters on IBM PCs could instruct the BIOS and FDC to format using less gap, and squeeze in extra sectors, but increasing the risk of write errors.

        For some uses, this risk is acceptable. And for write-protected distribution media, this is a non-issue.

        Some drives could also handle a few extra tracks, but that trick was not globally reliable.

        There were a number of DOS formatters that could create such disks. Maxi disk, FDFormat, and NFORMAT are a few others that come to mind.

        On top of reducing the sector gaps, these could indeed reduce some of the overhead used by the FAT. Specifically they could use larger cluster sizes (fewer cluster entries in the FAT) and a lower number of maximum files in the root directory. Which, again, while not ideal for general use, was often ideal for distribution media where each disk only contained one big ZIP.

      • (Score: 2) by FatPhil on Monday March 13 2017, @08:01PM (1 child)

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Monday March 13 2017, @08:01PM (#478607) Homepage
        On my Atari ST, I would regularly squeeze more than 720 KiB out of my floppies (the same techniques applied to high density disks too). The easiest 2-3% gain was just to use tracks 80-82, they almost always were accessible. Often you could bump up the tracks up to 10 sectors rather than 9, which was an 11% gain. However, that didn't always work. I think there were ways of changing the sector size too, and that would give you less overhead because of fewer gaps between sectors, but the problem with that was that the OSes didn't know what to do with anything that wasn't 512B sectors. All in all those FDCs were very adaptable. Amiga were the guys who pushed it the furthest, I think they got 880KiB from the same floppies that DOS was getting 720KiB out of. FAT wasn't the most efficient FS in the world, so indeed there was some chance of increasing the storage by using something incompatible. As a store of raw blocks of data (such as data disks for a game), who needs an FS at all, you don't need anything more clever than a CPIO archive.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by NCommander on Tuesday March 14 2017, @03:22PM

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday March 14 2017, @03:22PM (#478946) Homepage Journal

          Going beyond standard media limitations was generally an exercise of the drive itself vs. the FDC; even the PC AT could theoretically go beyond the standard limitations via the commands in the FDC. A drive built "within" tolerances should always work with standard gap sizes, but if you decreased the tolerance, it was possible to get more out of your floppies. Notably, this was more a problem for writing rather than reading due to the very write tolerances a read head has to manage. A double-destiny (720 KiB) floppy should be able to physically store 1 MiB of data. Macs of the era generally ran them at 800 KiB.

          --
          Still always moving
    • (Score: 0) by Anonymous Coward on Thursday March 16 2017, @03:24PM

      by Anonymous Coward on Thursday March 16 2017, @03:24PM (#479836)

      Man, you forgot a very big one:

      Most of the older users here remember floppy disks of various formats, low destiny, double destiny, 8in, 5.25-inch, 3.5-inch, and more.[..]

  • (Score: 3, Informative) by drussell on Monday March 13 2017, @05:47PM (9 children)

    by drussell (2678) on Monday March 13 2017, @05:47PM (#478535) Journal

    I have some actual MCA PS/2s around here. I 'm pretty sure at least one of them is a model 55SX which should work and I think I have an older model 70 which should be 386DX somewhere in one of the stacks the garage. :)

    I'll take a look at what I have later this afternoon and I know I have at least a couple working HDDs that have that silly 72-pin card edge connector for the PS/2s on them and would be happy to try booting it up if you PM the disk images or a link to where I can find them to my e-mail address that is linked to this account.

    • (Score: 2) by LoRdTAW on Monday March 13 2017, @07:34PM (1 child)

      by LoRdTAW (3755) on Monday March 13 2017, @07:34PM (#478591) Journal

      I used to have a working MCA 286 until the great purge. I still kick myself for doing that but you can't keep everything.

      • (Score: 2) by NCommander on Monday March 13 2017, @10:21PM

        by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Monday March 13 2017, @10:21PM (#478663) Homepage Journal

        For that MCA 286, you would need a 286PS release of Xenix, which I'm not even sure existed; if it did, no known copies exist on the internet. Because the system accesses the hardware in protected mode and bypasses the BIOS, it needs specific drivers for the MCA drives. This is why the the 386PS release can't be run in VirtualBox. OS/2 and Windows simply included both on the same medium, but Xenix released two different versions of the operating system.

        --
        Still always moving
    • (Score: 3, Informative) by jimtheowl on Monday March 13 2017, @09:52PM (6 children)

      by jimtheowl (5929) on Monday March 13 2017, @09:52PM (#478651)
      I have a working PS2 model 95 that currently boots into FreeDOS. It has 2 full height 1G SCSI drives and a working Intel EtherExpress card with the memory almost maxed out.

      I would be willing to spend a weekend or two on this and exchange notes.
      • (Score: 2) by NCommander on Monday March 13 2017, @10:44PM (5 children)

        by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Monday March 13 2017, @10:44PM (#478677) Homepage Journal

        The 95 might be too new; Xenix 2.2 386AT at least goes belly up with greater than 504 MiB HDDs, though that might work properly with the MCA hard drive. We recovered a serial number for the PS2 version and the media can be found through the links above.

        drussel: Pinging to get your attention.

        --
        Still always moving
        • (Score: 2) by dry on Tuesday March 14 2017, @04:25AM (4 children)

          by dry (223) on Tuesday March 14 2017, @04:25AM (#478760) Journal

          SCSI drives usually didn't use CHS addressing and at least on OS/2 were one way of getting past the various IDE drive limits. There may have been translation happening somewhere.
          What about if you played with the geometry? It is possible to go to 2 TBs (actually slightly less) with CHS addressing, I have a 1TB drive that works fine with OS/2 using

          Controller:2  Port:1CB8 IRQ:12  Status:OK BusMaster Scatter/Gather
            Intel ICH9 SATA host (8086:2926 rev:02) on PCI 0:31.5#1
            Unit:0 Status:OK SMS:16 LBA BusMaster 3.0GBit/s BPB
            Model:WDC WD10EZEX-75M2NA0                    01.01A01
             OS2:log   phys   BPB/BIOS   IDE:log   phys     Total Sectors
            C  60321  65535                65535  16383   Avail 1953525168
            H    255     16        255        16     16   OS2   1953495585
            S    127     63        127        63     63   % Used     99.99

          • (Score: 2) by NCommander on Tuesday March 14 2017, @05:24AM (3 children)

            by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday March 14 2017, @05:24AM (#478770) Homepage Journal

            Unfortunately, Xenix doesn't support SCSI out of the box. A few editions appeared to have support for it (likely non-x86), but it's not in this version. The support is listed in the "master" file however.

            scsi 0 0137 014 scsi 0 28 28 1 4 0 0 0 0

            This file has a list of basically any hardware Xenix supported at some point, Apple Lisa ProFile harddrives are listed for example, as are some X.25 network adapters (which required a specific connectivity kit to be installed, otherwise the kernel is only linked in w/ a X.25).

            The underlying problem is that "raw" CHS addressing can only represent up to 512 MiB of space, but due to implementation issues with the spec, the last track isn't usable, limiting it to 504 MiB. Operating systems that used BIOS for disk I/O could get "translation geometry" which basically converts data blocks from the old format to the new format and other blackmagic to make it work. Notably, Windows 95 could resort to BIOS disk access methods in a pinch if absolutely necessary which lets it work on some devices it won't otherwise support. Due to the fact that Xenix is a true protected mode operating system and don't use the V8086 mode on the 386, it can't talk to BIOS. The first generation fix for the CHS problem allowed drives to use LHA addressing of various sizes which bumped the size limit up to 8 GiB, then 1024 GiB, and then higher.

            Non-IDE drives on Xenix (such as a MCA HDD) should theoretically be able to go beyond the 504 MiB; there's no inherent limitation in the OS that prevents it from going to that point, it's just Xenix of this vintage pre-dates basically all the large drive extensions added to ATA over the years.

            The osdev article on CHS discusses this somewhat more in-depth: http://wiki.osdev.org/ATA_in_x86_RealMode_(BIOS). [osdev.org]

            --
            Still always moving
            • (Score: 2) by dry on Tuesday March 14 2017, @07:21AM

              by dry (223) on Tuesday March 14 2017, @07:21AM (#478801) Journal

              OK, thanks for refreshing my memory, been a while since thinking about this.

            • (Score: 2) by RS3 on Tuesday March 14 2017, @07:34PM (1 child)

              by RS3 (6367) on Tuesday March 14 2017, @07:34PM (#479094)

              Actually most SCSI controllers, with system-level BIOS ("visible" in 1st meg. real-mode memory map), honor standard AT (MFM/RLL) system BIOS calls, so no special drivers needed. And you can toggle DOS (legacy) CHS translation- certainly in most Adaptec controllers. (I have some SCSI controllers which have no system-level BIOS, and are only recognized by OS drivers- not recognized by generic motherboard BIOSes.) At various companies I worked for 23 years ago we used SCSI (mostly Adaptec but also Mylex) and ran DOS, Windows (3.x and 95/98), OS/2 "Warp", Novell 3.x, Linux, ... all on the standard AT BIOS calls. You get faster performance if you have OS drivers (rather than BIOS calls).

              Some SCSI controllers (and many other hardwares) were (are) supported in Xenix. You had to have a driver diskette, on which were object modules for your device, and you would go through a painful process of exchanging diskettes while the OS re-linked the kernel modules, adding in your new driver(s). Novell 2.x did this too. Novell 3.x became modular, like Linux did later on. Somewhere I probably have diskettes with Adaptec and some other .obj modules, and they might be somewhere online too. At least that's what I remember from 24 years ago when I probably last ran Xenix...

              • (Score: 2) by NCommander on Tuesday March 14 2017, @09:13PM

                by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday March 14 2017, @09:13PM (#479139) Homepage Journal

                CHS translation only works if your kernel talks to the BIOS. Xenix directly talks to the the I/O port interface for ATA; that's why we had to patch it to be less idiotic back in part one to get it work on modern hardware. There's no support for V8086 mode, and Xenix setups the GDT very very early in boot. I've never seen a SCSI controller that actually emulates the hardware ATA interface; they generally just hook the BIOS controller which is good enough for almost everything else. DOS and Windows could always do BIOS calls if necessary, and I think OS/2 just took "ship the kitchen sink" approach to HDD management, but I never tried to load it on a SCSI drive.

                When you're talking to the hardware directly, you have to setup the LBA blocks yourself. With Xenix, you get a link kit which lets you rebuild the kernel with whatever object files you want and map function calls to major/minor numbers and there's a set reserved for a SCSI controller and such. As such, you could build a new kernel with SCSI support and then boot of it, but its not included in the box here.

                --
                Still always moving
(1)