The "holy grail" of Floppy Drives

[cjs]

TLDR: We seem to be in (rather violent) agreement about the facts of the standard. You seem to be upset that I'm pointing out that the 2400 block, 512 bytes/block capacity is non-standard (as far as the UFI spec goes), but agree with me that it's not in the spec. You may be happy about the way the ufiformat program makes up geometries rather than querying them; I'm not; that's a matter of opinion that I can't disagree with on a factual basis.

...and here you are, jumping down my throat because I’m telling you that there’s stuff that exists outside the standard.

No, I'm just annoyed because I feel you jumped down my throat when I said your drive supported a non-standard capacity.

I fully agree with you "that there's stuff that exists outside the standard." I call these "non-standard" things, and, when I said you were using a "non-standard (at least as far as the spec goes)" format, that it's format that exists outside the standard was exactly what I meant. I'm not really sure how to make that more clear.

But if explaining that "there's stuff that exists outside the standard," i.e. agreeing with me (knowingly or not), was what you were attempting, I admit that my reading of your actual words, "Again, are you saying you know better than the person that wrote the formatter?" didn't pick up that subtlety.

(And no, I don't know if I know better than the person that wrote ufiformat. I do know that I disagree with some of the choices they made when writing it.)

(And now you’re bitching about what a bad job someone did writing a utility.)

I didn't say that they did a bad job, unless you take "so my guess is that they just reckoned it was too much work to be worthwhile and the above did a good enough job" to be, "they did a bad job." I did say that I'm personally annoyed that the tool doesn't do what I thought it did; if that upset you, I will in the future try to suppress my personal feelings a bit more and stick to the facts.

Did you read that stupid document you keep waving around and bawling about?

Yes.

The “Read format capacities” command doesn’t return a geometry, it returns a structure with number of blocks and block size. (Tables 32 and 34.)

Correct. As you say, it returns a list of capacities, as defined both in the standard and explicitly defined earlier in my post.

It can also return a single byte capacity descriptor which, sure, you’re right, only has three translations in the chart, if that is the hill you really want to die on making this incredibly stupid argument of yours, whatever, but…

I assume the "single byte capacity descriptor" is the Descriptor Code. No, I have no wish to die on that hill because the single-byte capacity descriptor has never been part of my argument.

I think you've gone and misread what I was saying, and upset yourself doing so.

then get a track count with a mode sense command requesting the flexible disk page

...this dumbass suggestion of yours would require making an “inquiry” command a destructive act.

Well, doing that kind of inquiry would certainly be part of a destructive act, yes. I thought it was pretty clear there when I said, "when formatting, they'd need to format track 0 and then get a track count with a mode sense command" [emph. added]. I think again, you've misread and got yourself upset about something I never said.

It would be nice if they could even display all the capacities a drive supports formatting.

Again, dude, read the the f’ing manual, it only returns block numbers.

Well, to be more precise, (block count, block size) pairs. Which are the "capacities," in both the UFI terminology and in the definitions of terms I was using that I wrote earlier in that very post.

Those capacities, not geometries, all all I'm asking for, as you can see by my use of the phrase "display all the capacities" above. Again, you're getting upset over something I never said.

(And it also appears it edits the list it returns based on the mounted media; IE, it won’t say what DD formats it supports if you have HD media mounted.)

Yes, I just noticed that. Plus, with no media it will return only "a Maximum Capacity Descriptor denoting the 1.44 MB format." Annoying. Still, it would be nice to be able to get the formattable capacities for whatever medium is in the drive.

You still need a translation table to make those human readable.

Well, that's a matter of opinion. Personally, I feel something along the lines of "1200 KB (2400 × 512b blocks)" or "1440 KB (2880 × 512b blocks)" is quite human readable.

And your wish to show geometries for formattable capacities is laudable, but, as you appear to have seen can't be done within the standard. (At least, not without going and formatting things, probably using several different media.) Which is why I didn't ask for it.

At least it can show the geometry of a diskette in the drive, and it certainly would be nice if the program would do that.

Of course you may be saying that the program should do what it's doing, which is make up some geometries that match the non-standard capacities. Which, again, I suppose is a matter of opinion, but I prefer software that is as transparent as possible about the device it's talking to, because I find that avoids confusion.

(And to feed back in to the format command, which does ask for *tracks*; you need to know based on the format capacity you’re asking for whether to stop at 77 or 80, see the thing about format descriptors on page 17. Although, sure, you could write a track and then do the media sense thing to have the drive tell you a number…

Correct, which is exactly why I suggested that. (That's what you got so upset about above.) I'm now unclear, though, whether you feel this is still a "dumbass suggestion."

...but if you hate tables so much you could save the trouble of the media sense command *and just do the math* to suss out how many tracks of X sectors equals Y blocks?

But how do you know how many sectors/blocks per track you have?

I mean, this whole thing you’re doing here is just stupid. An extra USB command is the *least* efficient way to do this.)

Well, for you, sure, perhaps efficiency is more important than correctness, especially when you can save a fraction of a second during a relatively rarely used format routine that takes many seconds to run. I prefer a different trade-off.

Anyway, I’m done with this. Maybe support for this “1200” format *isn’t* strictly in the standard....

That's not a "maybe." You've read the standard; it's absolutely correct that the (2400 block, 512 bytes/block) capacity is not in the standard, anywhere. I don't understand why you're so upset by this. It doesn't seem relevant to anything interesting. The only relevance, really, is, "Oh, yeah, that's why I misunderstood what capacity and geometry you were talking about in an earlier message."

Again, you’re a smart guy, I’ve been really impressed with the quality of some of your posts and your technical knowledge, but this is ridiculous.

I think you want to go through the exact technical points I'm making and think about what you're really getting upset about here. If you don't like some of my non-technical snark, fine, you can say so. I've had my share of snark from you in this thread and others; I'm willing to let it pass because I know people get a bit emotional sometimes. You might consider doing the same, though of course it's your choice.

Personally, I think if you go through my words again, but with the (difficult, I know) assumption that we're in agreement about what's in the standard, you'll find that we don't have much to argue about. This comes out in things you criticising a (clearly misread) suggestion in my post and then making the exact same suggestion yourself a few paragraphs later.

 

[Eudimorphodon]

Correct, which is exactly why I suggested that. (That's what you got so upset about above.) I'm now unclear, though, whether you feel this is still a "dumbass suggestion."

I will ask you one question, with a bit of follow-up: what is the least common multiple of 77 and 80?

I’ll save you the trouble, it’s 6160. That is the *smallest* number of sectors *per side* that could be divided up into two “valid” geometries of, yes, 80 and 77 sectors, respectively. We happen to know that the two sector sizes we would realistically ever encounter are 512 and 1024, so… I ask you, will 80 512 byte sectors *fit* on any standard PC floppy disk format supported in HD floppy drives? No? Would it even fit on an ED disk (which so far as I’m aware has never existed in USB form)? No.

To cut to the chase here, even the smaller 77 number won’t fit on a 360 RPM HD floppy even if you used 128 byte sectors, which are the smallest NEC 765 compatible disk controllers support. It’s 20% more per track than 8x1024 with eight times the sector gaps needed. You might *just* squeeze it on in 300 RPM mode, but even then you’ll be packing more data *and* more sector gaps than any real format.

*IF* the standard was more flexible then maybe you’d need to do this more dynamically, but… have you ever thought that maybe the devs who wrote that software based their table on what they actually *saw* when testing it on real floppies? Do you have a floppy that supports other formats? How many have you tried? Is this a big problem you’ve discovered? No?

That's not a "maybe." You've read the standard; it's absolutely correct that the (2400 block, 512 bytes/block) capacity is not in the standard, anywhere.

TLDR: We seem to be in (rather violent) agreement about the facts of the standard. You seem to be upset that I'm pointing out that the 2400 block, 512 bytes/block capacity is non-standard (as far as the UFI spec goes), but agree with me that it's not in the spec.

You know what? We don’t agree on this. I agree that the standards document only has three formats listed in the descriptor code table and the 80x15x2 isn’t one of them, but when I said “there are things outside the standard” I meant that in a neutral sense in so far as I don’t actually *know* if this 1200k capacity is “nonstandard” or just “undocumented”. Standards have gray areas *all the time*, and the fact that the format command takes that capacity struct (which needs to match one the drive returns on its list of supported capacities) suggests they *did* anticipate the possibility of needing some wiggle room.

In short the standards doc you came in here to wave around and tell me to read in an insulting tone is ambiguous in several important respects, and there are clearly some significant gaps in how they implemented it. (If the format command needs to go track by track then why doesn’t the supported formats list include a geometry section in addition to/instead of block count? If they really didn’t want any format to be possible other than those three in the descriptor code table then why doesn’t the format command just take a single byte format code instead of that big clumsy struct?) Standards docs suck. Always.

And also, to be clear, I was taking as read based on the previous discussion that *maybe* this “1200” format might be “rare”, but you know what? My sample size is ONE. I have no idea at all how common it is for “three mode” floppy drives to list this as an option. How many usb floppy drives have you, or anyone else who might be reading this, actually queried to see what supported formats ufiformat lists? You say it’s not a standard PC98 format, that’s fine, but Y-E Data at least thought it was common enough to burn into the firmware of their drives, and the Linux devs who wrote that utility saw it often enough to put it in their table. So far as I know every usb floppy that supports 3-mode has it, I was simply relating *my experience* with a drive that offered it. Which ultimately ends up here:

There is no freaking need to jump in and nitpick the hell out of everything. You came out swinging with your PDF to jump on your assumption that I’d somehow F’ed up and failed to notice that DD must have left tracks off the end of my DOS disk experiment (which it didn’t) , and when I responded that, no, apparently there *is* a format for 3.5” disks that, whether you want to call it a “standard” or not, is well known enough to have ended up in floppy drive firmware, in a unix utility, and on multiple Wikipedia pages that *will* perfectly match a 15 sector 80 track 5.25” image you decided to turn this into a string of insults implying I was too dumb to know what “standard” means because it isn’t explicitly laid out in your precious pdf.

We get it, you wanna be the bestest smartest never wrong boy in the room, and if it takes being an insulting bully to take that crown you’re all in. May I humbly suggest you chill the heck out? We *could* be here to learn interesting trivia from each other instead of playing this infantile game of gotcha.

 

[cjs]

You know what? We don’t agree on this. I agree that the standards document only has three formats listed in the descriptor code table and the 80x15x2 isn’t one of them...

Then you do agree with exactly what I said originally (emphasis added):

Oh, I see; you had a drive that provided a second, non-standard (at least as far as the spec goes) 1.2 MB format for format as well as read. That wasn't quite clear to me.

I was merely trying to explain why I'd misunderstood your previous post. I have no idea why you are attacking me immediately after that post with comments like,

But, you know, the guys who wrote the format program might not have as authoritative knowledge of the subject as you always do.

Again, are you saying you know better than the person that wrote the formatter?

I appreciate the further technical discussion, from which I've learned a lot, but your desperate need to convince me of....well, I'm not even sure what (that I must call something not in the standards document, "standard"?) and continued anger about this, mystifies me.

You came out swinging with your PDF to jump on your assumption that I’d somehow F’ed up and failed to notice that DD must have left tracks off the end of my DOS disk experiment (which it didn’t) , and when I responded that, no, apparently there *is* a format for 3.5” disks that, whether you want to call it a “standard” or not, is well known enough to have ended up in floppy drive firmware, in a unix utility, and on multiple Wikipedia pages you decided to turn this into a string of insults implying I was too dumb to know what “standard” means because it isn’t explicitly laid out in your precious pdf.

Well, I suppose that's one way of interpreting it. I've explained several times now, including again at the start of this post, that what I meant there was I was wrong about the format being used (because I had assumed it was a format from the standard), you were correct, and still your rage increases. It looks to me as if you're just looking for something to be angry about.

We get it, you wanna be the bestest smartest never wrong boy in the room, and if it takes being an insulting bully to take that crown you’re all in.

I wonder if there's anybody else in this thread that this might apply to.

 

[cjs]

As far as some comments on the technical side:

If the format command needs to go track by track then why doesn’t the supported formats list include a geometry section in addition to/instead of block count?

I do not know. It seems odd, but perhaps they reckoned that you should just format the first track and then query for the trackcount. Or just format tracks until you get an error. The inability to provide geometries for formattable capacities might be related to quirks of the particular hardware that people were already using at the time. I do agree it's certainly not ideal.

If they really didn’t want any format to be possible other than those three in the descriptor code table...

If you're claiming that I believe that, no, that's entirely wrong. If you believe that, well, I can't find anything explicitly saying that no other formattable capacities should be possible, but they should went to a lot of work to create an interface that would make it possible.

How many usb floppy drives have you, or anyone else who might be reading this, actually queried to see what supported formats ufiformat lists?

One effectively. Both my Toshiba and my Fujitsu support this, but both are based on the exact same chip, at least, and I would bet same mechanism. (They appear to use the same case moulds.)

  idVendor           0x057b Y-E Data, Inc.
  idProduct          0x0000 FlashBuster-U Floppy
  bcdDevice            4.01
  iManufacturer           1 Y-E DATA

...but Y-E Data at least thought it was common enough to burn into the firmware of their drives...

I don't know that I'd go that far with it. Perhaps it's not common at all, but they thought it was quite usefulin some circumstances. (I certainly do.) At any rate, I'm not too interested in speculating for the reasons for it being there; it's there and that's enough.

...and the Linux devs who wrote that utility saw it often enough to put it in their table.

Again, this seems to me to be reading too much into it. Even if they saw it only once, they would still have to put it into their table to be able to format even a single diskette using that capacity. (As I said before, this is one of my complaints about the software: it will print the formattable capacities available for particular media, but not let you actually format any that are not in its hard-coded list.)

 

[Eudimorphodon]

Two small comments:

1. I’m done caring, but I did Google some datasheets, and so far every datasheet I’ve found that explicitly says their controller/drive supports 360 RPM formats and details specifically what formats are included says it does this 15 sector format. It would be more convincing to say it’s a nonstandard format if it didn’t turn out every “3-mode” floppy drive you can buy actually supports it.
2. FWIW, there are some breadcrumbs indicating this might be a format supported by DOS/V and the Japanese versions of Windows 9x, but I can’t find supporting evidence in English so I’ll leave it at that. It would make a certain amount of sense that versions of “generic” DOS sold in a country with millions of disk drives jumpered to run at 360RPM might support something like this, but that’s a just-so story I’m not going to defend… again, other than to point out that there must be some reason these drives support it.

Again, standards: they don’t always make complete sense. Maybe, just maybe, that table of capacity descriptors isn’t all inclusive of every format allowed. It *looks* that way in the text, but maybe it more correctly should be taken as shorthand for “HD 300RPM”, “HD 360RPM”, and “DD 300RPM” and whoever made the table erroneously put the most popular format in each category as its canonical description?

Pulling that out of the air, but unless you feel like going out and buying every USB floppy you see to check if you can find one that’s 3-mode but doesn’t support that mode our sample is currently 3-0 in favor of it being a “standard”, or at least “de facto standard”, option, on drives that aren’t massively handicapped.

Re: the previous post, I’m sorry, maybe I should not have gone nuclear, but I nonetheless resent the underlying assumptions of this whole exchange. I said in my post that you reacted to by telling me “it must have only worked because…” that a disk I imaged this way was “natively readable”; IF I had done something boneheaded like dd-ing a disk image with 512 byte sectors to one with that 1024 byte 77 track format, sure, it would have “fit” (it’s a few k bigger, after all), but it wouldn’t have *worked*. And, well, obviously I didn’t explain this, but I *did research* to learn about this 360 RPM mode, and that included reading this exact standards doc looking to see if there were some API for programming custom formats. (Which there isn’t.)

You are continuing to nag about what a standard means despite the fact that your own floppy drives are providing evidence that maybe your “plain reading” isn’t inclusive of all the facts. Why? How many drives would you need to look at to change your mind? It therefore *very much* seems like you simply cannot stand to be wrong in your assumptions.

 

[cjs]

FWIW, there are some breadcrumbs indicating this might be a format supported by DOS/V and the Japanese versions of Windows 9x...

Well, and let's not forget that that's the standard layout for 5.25" HD diskettes. I can imagine that there are use cases where it would be handy for software that wanted to do sector reads from that geometry to be able to substitute a copy on a 3.5" USB floppy, instead. (Backup programs come to mind.)

Maybe, just maybe, that table of capacity descriptors isn’t all inclusive of every format allowed.

I have always firmly believed it's absolutely not the list of "allowed" capacities/geometries, but the list of required capacities/geometries, i.e., the minimum the drive must support to be compliant. Did you misread my position on this? Is that this source of all this argument?

...our sample is currently 3-0 in favor of it being a “standard”, or at least “de facto standard”, option, on drives that aren’t massively handicapped.

Fine. Your definition of the "standard list of capacities" includes capacities not listed in the standard. I fail to see why you are so set there must not be an interpretation of "standard" as, "what's in the standards document," especially when I go to the trouble of actively distinguishing that I'm saying exactly that in the post that triggered you. Again (emphasis mine on the bit you seem to keep ignoring):

you had a drive that provided a second, non-standard (at least as far as the spec goes) 1.2 MB format for format

You are continuing to nag about what a standard means despite the fact that your own floppy drives are providing evidence that maybe your “plain reading” isn’t inclusive of all the facts.

My plain reading includes all the facts just fine. My drives support not only the two standard HD capacities, but a third non-standard (as far as the specification is concerned) one. I don't look down on that capacity as something awful because they decided to go beyond the bare minimum specified in the standard; to the contrary I'm very pleased to have it. For all I know, virtually all USB floppy drives support that capacity, which is fine; that still doesn't mean that any that don't are missing a standard format, as stated by the spec.

Why? How many drives would you need to look at to change your mind? It therefore *very much* seems like you simply cannot stand to be wrong in your assumptions.

And on which assumption am I wrong? (Check the "I have always firmly believed..." paragraph above before you answer.)

 

[krebizfan]

The SMSC USB97CFDC which was used in a number of early USB floppy drives had a very flexible set of capabilities. I wish I had known about it when it was on the market. The possibilities for some alternate USB floppy drives concepts would have been made much easier if all that is needed is to tweak existing firmware. Later USB to floppy interface chips seem to have been simplified considerably.

SMSC PROVIDED SOFTWARE FOR USB97CFDC
SMSC provides the following for the USB97CFDC:
I.
Program firmware with the following features:
(a) Supports 640K, 720K, 1.44M, 1.2M Windows J, 1.2M NEC DOS 6.x formats.
(b) Supports USB Mass Storage Class compliant drivers from Apple and Microsoft as well as SMSC’s
Windows 98 driver.
(c) Supports USB Mass Storage compliant bootable floppy BIOS.
(d) 4ms Seek times.
(e) USB 1.1 compliance, including low power device class SUSPEND mode operation and power control of
disk drive.
(f) Disk drive feedback of readiness upon power re-application (optional).
(g) Option for using drive media density sense output (HDO#) pin to prevent attempts to format 2DD disks as
2HD.
II.
USB Mass Storage Class compliant driver for Windows 98.

External Program Memory Interface
- 32K Byte Code Space (Supplied Firmware
Requires 16KB Memory)
- Flash, SRAM, or EPROM Memory
�
4KB Internal Buffer SRAM for High Performance
Operation
�
Optional External Cache Memory
- Up to 16K x 8 External SRAM may be Used for
Custom Tape/ Drive Applications

 

[Eudimorphodon]

but a third non-standard (as far as the specification is concerned) one.

Last time: this is pathetic. And I can prove it to you with the plain text of that godforsaken document you are so f-ing in love with.

Your entire argument about this format being “non standard” is based on the contents of table 35, 4.10.2, which lists those three specific *geometries*. I speculated maybe that *could* be a mistake and that byte code was actually intended as a “media type” indicator. Well:

Look at table 17, section 4.5.3. There’s the “same” table, IE, a list of parameters associated with the same attribute, but here it is defined in terms of raw unformatted capacity. In other words, the standard defines the same freaking thing two different ways, and your entire case about this being a “non standard” format is based on the table that’s actually clearly counter to how this attribute is used?

Edit: or, as I outline below, the alternative interpretation of this table is it’s a mandate that a fully compliant drive *must* at minimum implement these formats, but… standards are riddled with “musts” and “mays”, this stupid argument is all about whether anything that’s not a “must” is “nonstandard”. I’m sorry, that’s wrong and not how standards work.

I fully expect yet another utterly schizophrenic response to this explaining how your take on this is completely the correct one in every regard, but whatever.

Edit: one last point: in my very first post on this (oh what a sweet and innocent time) I did take for granted that maybe the contents of that table were prescriptive and it could be odd that my drive supported this other format. The one thing you’ve completely succeeded at with this position of yours is driving utterly home that standards documents are riddled with booby traps that can trick you into making stupid assumptions. I’m sure your comeback, again, is going to be that the standard demands that the minimum set of format descriptors must be the contents of table 35, and I dunno, maybe that’s how it’s intended, therefore any other format supported by any drive is “nonstandard” (I mean, that’s been your whole argument the entire time), but… the other way to interpret it is as long as a drive *has* these three entries as formattable capacities it’s “standards compliant” as long as nothing else it can do violates the terms of the document. (Supporting different media types, adding custom api calls, whatever.)

I agree to disagree on whether a thing can be “standards compliant” and still offer features beyond the bare minimum specifications if it puts an end to this.

 

[Eudimorphodon]

The SMSC USB97CFDC which was used in a number of early USB floppy drives had a very flexible set of capabilities. I wish I had known about it when it was on the market. The possibilities for some alternate USB floppy drives concepts would have been made much easier if all that is needed is to tweak existing firmware. Later USB to floppy interface chips seem to have been simplified considerably.

That is the aggravating/sad thing about the usb floppy API; it would be awesome if it had one more function call that would allow you to soft-load a custom definition to the supported format table. The structure of the format command has a bunch of “reserved” bytes that reads like they may have intended more flexibility in directly specifying geometries, but in the end it’s neutered down to just a track number and a format specification blob (that’s an LBA size, not a CHS geometry) that has to match a format burned into firmware.

The wildcard here is this format specifier would also have to augment the table the microcontroller driving the disk drive references to auto detect the format of an inserted disk and set up LBA translation properly. I am actually curious how robust that is, generally.

Hypothetical example: PC-DOS 1.x used 8 sectors a track. DOS 2 upped that to 9. Later versions of DOS format have a /8 switch to make disks compatible with MS-DOS 1.x, but several sources say that the physical format command still low-level formats 9 sectors, it just sets the media descriptor byte in the boot sector to the one used on 8 sector floppies and otherwise writes the high level format using a CHS geometry ignoring that extra physical sector. My question here is this: if you formatted a DD floppy with the /8 switch, creating a “640k” floppy which *should* be possible to read with PC-DOS 3.x because they added explicit geometry fields which override the media descriptor byte to the boot sector, would the LBA translation mechanism used in the firmware of these controllers set up LBA translation properly? If they just count physical sectors they see spinning the disk the answer seems like it would be “no”, because it’s going to insert that unused sector every nine blocks. But if it *does* work by looking at the media descriptor byte that would make format detection OS specific; if it were formatted with an OS that doesn’t use PC DOS boot sectors it wouldn’t be able to suss it out.

Or maybe this example isn’t just hypothetical, because all the datasheets for USB disk controllers say they support a “640k” Japanese disk format. How do they tell the difference between this and 720k? Counting physical sectors, or reading descriptor bytes?

 

[cjs]

I really, really have no idea why you continue to attack me about this. I simply said (though not as well phrased), "Ah, I misunderstood which capacity you were using because the one you are using is a capacity not listed in the standard." Do you object to any part of that?

Or is it my particular phrasing at the time, "non-standard (at least as far as the spec goes) 1.2 MB format" (by which I meant "capacity," of course), that you object to: I'm not allowed to use the word "non-standard" to describe capacities not listed in the standard, even with that qualifier?

...the other way to interpret it is as long as a drive *has* these three entries as formattable capacities it’s “standards compliant” as long as nothing else it can do violates the terms of the document.

Sure: not only do I agree, but support that position which is why (also all along) I have believed that your drive is standards-compliant and have never said otherwise. (After all, implicit in the design of the standard is capacities not listed in the standard; that's why I interpret what's in the standard as a minimum set.)

I agree to disagree on whether a thing can be “standards compliant” and still offer features beyond the bare minimum specifications if it puts an end to this.

No need to agree to disagree since, per above, we've always been in full agreement there.

You know, given that I have to keep pointing out areas where we agree and you think we disagree, it might be worth going back over whatever it is you're currently upset by, but re-read it starting with the assumption that I agree with you on everything, and see if reasonably charitable interpretations of my words in that light still are saying things you think they're saying. Because I'm really at a loss to figure out how this whole thing is anything beyond a drastic misreading of a side comment about the particular capacity you were using not being listed in the standard.

 

[cjs]

And now back to the technical discussion:

The structure of the format command has a bunch of “reserved” bytes that reads like they may have intended more flexibility in directly specifying geometries....

Yeah, I'm not sure about that: it looks to me as if all the commands are 12 bytes long, perhaps either for USB reasons or for Mass Storage Class reasons.

...and a format specification blob (that’s an LBA size, not a CHS geometry) that has to match a format burned into firmware.

That's kind of the Achilles heel of the whole thing: capacities (which might more intuitively be called "formats") are specified by only number of blocks and block size, which rather elides a lot of information about the format.

...because all the datasheets for USB disk controllers say they support a “640k” Japanese disk format. How do they tell the difference between this and 720k? Counting physical sectors, or reading descriptor bytes?

My guess about the "640K Japanese format" would be that it's actually 8-sectors per track, since that's what a number of Japanese machines used on 3.5" DD (Fujitsu FM77, NEC PC-6801, etc.). But I wouldn't put too much money on that, since this is probably also tied up in all sorts of PC-world stuff.

However, it's easy enough to work out: format a 2DD diskette to the 1280/512 capacity and check it out in a Greaseweazle or similar device to see what it actually put on there.

...table 35, 4.10.2, which lists those three specific *geometries*. I speculated maybe that *could* be a mistake and that byte code was actually intended as a “media type” indicator.

That seems reasonable, since that byte code is actually called a "Medium Type Code." Though it appears that this is a sense of "media type" that "the format of the diskette" since they use separate media types for two formats (NEC 1.25 MB and PC 1.44 MB) that use the same physical media (HD 3.5" diskettes).

I also note that they say the $93 and $94 codes are UFI-specific, but the $1E is not. Is that used somewhere in non-USB floppy systems? It doesn't match any of the media descriptors listed here.

Look at table 17, section 4.5.3. There’s the “same” table, IE, a list of parameters associated with the same attribute, but here it is defined in terms of raw unformatted capacity.

Yeah, I'd noticed that. "1.6 MB unformatted" is clearly not being used in the sense of what the physical media can hold, since "1.6 MB unformatted / 12,362 bits/rad" and "2.0 MB unformatted / 15,916 bits/rad" are on exactly the same physical media.

So I guess they must be talking about the overhead of the format, I.e, how many bits are stored if you include all the index data, gaps, and so on. If I do a quick calculation using 120 bytes of overhead per sector, I get 11,653 and 14,484 bits/rad respectively, which isn't too far off. (That's, (bytes per sector + sector overhead) × sectors per track × 8 bits/byte ÷ 2π rads/track.)

I'm not sure if it's relevant to anything one can do with the drives, though. Are those Medium Type Codes actually connected to anything outside the UFI standard?

 

[Chuck(G)]

Yeah, I'm not sure about that: it looks to me as if all the commands are 12 bytes long, perhaps either for USB reasons or for Mass Storage Class reasons.

The USB mass storage class is essentially a wrapper around the SCSI mass storage class. Shares the command set, etc. Also explains the limitations and peculiarities of the device (e.g. device is assumed to be uniform in format and accessed by relative block address).