Sorry if this reply seems a bit terse: I spent 20 minutes writing it up only to find that, of course, Ctrl-W closed the window instead of deleting a word and for whatever reason the forum did restore my auto-saved draft.
Again, are you saying you know better than the person that wrote the formatter?
Clearly not, since I don't see anywhere that the person who wrote that formatter is claiming that the 1200 KB format is a standard format. I think it's just you doing that here.
Maybe it’s a “nonstandard” format in your book...
Well, my book doesn't matter much; what matters about what standards is what
the standard says (in this case, the
UFI Command Specification from the USB Implementers Forum), and it gives a very clear list of what the three standard formats are. Let me give you
a link to it a second time. You really should give it a read; it's enlightening.
...but a random floppy drive I didn’t go out of my way to seek out...
Oh, well if a random drive supports it, it must be standard, right? No matter what the standards document itself says!
...*and* a system utility for Linux supports it out of the box.
That's a little more interesting, as we'll see in a second.
Just to keep terminology straight, a
capacity, as used in the UFI standard, is a (block count, block size) pair; this is what you send to the USB FDD when asking it to format a track. I'll call the heads/tracks/sectors/sector-size tuple a "layout," and reserve "format" as just the verb for formatting a track.
Also, from the source code of the ufiformat utility:
Code:
static const int geometry[][5] = {
{ 1440, 80, 2, 18, 512 },
{ 1232, 77, 2, 8, 1024 },
{ 1200, 80, 2, 15, 512 },
{ 720, 80, 2, 9, 512 },
{ 640, 80, 2, 8, 512 },
{ 0, 0, 0, 0 }
};
Well, yes. So how much of the code beyond this did you actually read? Examining that more closely is interesting, as well as leaving me somewhat less impressed by this program.
So they've gone and hard-coded the three standard capacities (which is not ideal, but probably acceptable), as well as two non-standard ones that are probably good guesses. But still, given that they can get this information from the drive using the "read format capacities" command (which they already use to find a default format capacity or—with what look like some dodgy hacks—to check a specified format capacity), why the hackery?
One truly annoying thing about this is that you can format only to capacities in the list above; if your drive supports other capacities you are SOL. They
could just ask the drive for its capacities (which they already have the code to do), and they can get the track/heads/sectors/sector-size/etc. information from the drive itself (for the current media—when formatting, they'd need to format track 0 and then get a track count with a mode sense command requesting the flexible disk page), so my guess is that they just reckoned it was too much work to be worthwhile and the above did a good enough job.
It would be nice if they could even
display all the capacities a drive supports formatting. That shouldn't be difficult at all given that they already have the read format capacities command implemented right there.
github.com