The problem: The floppy-disk-controller IC used in PCs is pretty high-level.

Reading the raw data on each track is not within-specs. When you attempt to read a sector, the disk-controller scans the track for a sector-ID matching your request. Thing is, the sector-ID may be corrupt, in which case it'll never be found. In which case, you can't extract that sector. Similarly-complicatedly for various reasons sector-IDs can be written to *any* value... E.G. while your physical heads may be located, physically, on cylinder 20, and while you may be reading physical head 1, it's entirely plausible that there may be a sector on that track (track 20, on head 1) that's Identified as something completely different, say Logical cylinder 1023, logical head 0, logical sector 63. If you don't know to request that ID at that cylinder on that head, then you can't use the "read sector" command to get it.

So, I don't know why, but I can't read certain sectors when I assume that the entire disk is formatted the same as the first track (10sectors/cylinder/side, marked 0-9 on physical head 0, 10-19 on physical head 1, both on logical head 0)... The error message is "sector not found."

Then, how can one extract data when a sector's ID is corrupt, or weird...?

fdrawcmd has an *undocumented* command called "read_track". I came across this somewhat randomly... But then, if you look into the floppy-disk-controller's documentation, there's a problem...

5.1.3 READ TRACK

This command is similar to the READ DATA command except that the entire data field is read continuously from each of the sectors of a track. Immediately after encountering a pulse on the IDX pin, the 82077AA starts to read all data fields on the track as continuous blocks of data without regard to logical sector numbers. If the 82077AA finds an error in the ID or DATA CRC check bytes, it continues to read data from the track and sets the appropriate error bits at the end of the command. The 82077AA compares the ID information read from each sector with the specified value in the command, and sets the ND flag of Status Register 1 to a ``1'' if there is no comparison. ...
This command terminates when the EOT specified number of sectors have been read. If the 82077AA does not find an ID Address Mark on the diskette after the second occurrence of a pulse on the IDX pin, then it sets the IC code in Status Register 0 to ``01'' (Abnormal termination), sets the MA bit in Status Register 1 to ``1'', and terminates the command.

(Intel 82077 datasheet)

So, even though it ignores the sector-ID information (unlike the read-sector command), it still *only* reads the data-fields... (and, what when the *other* bytes related to each sector are corrupt...? How would it locate the data-field if it can't even locate the sector-field?)

So the trick came from a japanese website... I had to translate it. More on that later...

The trick is simple... just tell it that the sector-length is longer than a track, and request more bytes than exist on a track.

It'll locate the first sector and begin reporting its data field, but now it thinks the sector itself is *really long* so it continues reading data *past* the actual sector-data... which just happens to include the following sector-header (as well as the CRC bytes, etc.). And... by telling it the sector-size is larger than the number of bytes that can fit on a single track, you wind-up extracting *the entire* track, as raw data. Every sector ID, corrupt or oddly-labelled, every CRC field, every gap-byte... (And, probably, some corrupt data, as well). Friggin' amazing! I've been fighting this for *weeks* (omg).

(Fhwew! I really didn't have the patience to build a custom low-level reader... for this one-off backup for a system I may never even use...)

Dunno why I had to go to Japan to find this technique... I've some theories, though... which is why I'm not linking it here. Yay!

All this because somehow apparently I acquired a unique system... If you believe my search-fu abilities, this stupid diskette appears to be the only one of its kind in the entirety of the world. Once this disk goes down (and apparently it's already begun), this otherwise still-useful and apparently somewhat unique system might-as-well be dumpstered. I'm not pro that thought. I'd hope someone will consider even one thing I've done worthy of a couple weeks' effort to keep out of the dumpster, despite maybe being a bit dated.