Okay so maybe there's a better way to do this but nobody I know has ever had a solution for it that actually works, and I now have one that's tested and works on multiple machines.
Here's the problem: You have an old PC - let's say, 386 to Pentium class - that has an IDE interface, so you'd like to do file interchange with a modern PC by just pulling the hard drive out and plugging it into a USB adapter. Or, you want to use a Compactflash to IDE adapter to give the machine an "SSD." So perhaps you try plugging the drive or CF card into your modern PC, you format it, copy over DOS or Windows install files, plug it into the old PC... and it won't read.
Or, you plug the drive or card into the PC, partition and format it, set everything up from floppy or CD, and it all works great. Then you pull the card or drive, plug it into your modern PC, and you're able to read the files with no trouble. But then you write something to it, and suddenly it's unreadable by the old PC; it just sees a "non-DOS partition" and you're screwed.
From what I understand, this is because...
In the early days of hard drives, data was located on a disk with a set of physical coordinates known as CHS, or Cylinder/Head/Sector. An entry for a given file in your disk's FAT table might say the file is at 103/2/50, and that literally told the machine "to get this file, move the head in 103 tracks, wait until it spins around to the 50th sector in that track, and then start reading from the third head."Obviously this was arcane and unsustainable, especially once hard drives started doing internal bad-sector remapping and other such tricks, and clearly it doesn't apply to SSDs at all. So at some point, Logical Block Addressing was introduced, which is incredibly simple: you locate files by a number from 0 to the maximum number of sectors on the drive. Done. When you want to retrieve a file, you tell the drive "give me sector 1953782" and its own firmware figures out how to get that.
The problem is that PCs didn't adopt LBA instantly. I have a Dell GM5133 here, a Pentium 133 from 1996, which still uses CHS. You can look in the BIOS and it lists cylinder, head and sector values for each drive, and even has landing zone and precomp values. These are even more details about the physical reality of the drive which (if I remember correctly) had been obsolete for nearly a decade even in CHS-based drives at this point.
My understanding breaks down here a little bit. I've been told that after a certain point, FAT began tracking file locations in both CHS and LBA, for backwards compatibility, and In Some Way this leads to confusion. You install your software on the old PC and it uses CHS for everything; plug it into your modern PC and it happily reads the redundant LBA values and reads the disk; or it reads the CHS values and converts them to LBA, and all is well.
But then you write something, and it either populates nothing in the CHS fields (because who does that anymore?), or it calculates CHS values based on dead reckoning which disagree with what the old PC was using. Remember that with a CF card, or even any real spinning disk larger than... a gig or something? Those CHS values are made up and fake anyway.
So in short: Your PC writes out a new FAT, and it's skewed over by two bytes or whatever. Now the disk is trashed as far as the old PC is concerned.
So, here's the thing: I'm sure that CHS>LBA conversion has a normal algorithm, and if modern OSes would just do it, there'd be no problem. Maybe Linux does or something, I don't know, I haven't tried it, I don't have time for that. I'm working from Windows and I needed a solution there. Surely whatever is being done when I write a file with CHS addressing to a CF card with no cylinders or heads at all can be replicated easily.
And then I noticed that 86box, the PC emulator forked from pcem, lets you choose CHS values for a disk image manually. So I tried the following:
- Partition and format a CF card in the old PC, through a simple 40-pin adapter
- Make a note of what the BIOS reports for CHS values
- Plug the card into a reader on my modern PC
- Use any raw imaging tool (I used DiskImager) to rip the CF card to a file
- Load the image as a hard drive in 86box, using the same CHS values
- Boot the VM.
- Make whatever writes I need to make
- Shut down the VM
- Write the image back to the CF card with e.g. balenaetcher (it deals best with windows' irritating open file handles)
I tried this, and it worked perfectly on the first try. It just... worked. I was able to install an OS inside the VM, copy over all utilities and drivers I needed, write the image out, and then boot straight into the OS in the old PC.
You don't need to partition/format the drive in the old PC; just plug it in long enough to get the CHS values. Machine's too old to autodetect? If it's an old hard drive, the values will be in the datasheet. If it's a newer one... no comment. And if you're doing the CF card thing, buy a WD Silicondrive on eBay; they're "true ATA", and have documented fake-CHS values in their datasheets.
In almost 20 years I have NEVER found a solution for this that worked. A cleaner workflow would be nice; the best way to get files into the image in bulk is to inject them into a CD image, load that in the VM, then copy everything over; I wish I could just use A Program, but I don't know of anything that can be trusted to actually do the CHS math. Suggestions accepted; this is absolutely a "the best way to get the right answer is to give the wrong one" situation. But the above process does work, I've now done it with two different machines, and that beats nothing.
