• Please review our updated Terms and Rules here

Modern USB to Floppy adapters that are NOT do-all

I'm not surprised this shook out the way it did under DOS. Why it can't read high density disks in Windows is a little more of a mystery; it may not be "drivers" per se, it could be higher level than that.

Here's a big gross document about how the "generic" USB floppy implementation standard works, IE, API details. The long and short of it is that the API for USB floppy drives doesn't emulate an actual wired-in floppy controller, it presents them primarily as a block device on par with a hard disk or flash memory stick. There's an independent embedded microcontroller in the drive that has to answer these API requests and how it responds to some of them is probably going to vary a little between controller chips; IE, some are probably going to be more flexible about "believing" what they read from the inserted floppy disk verses hard-coded behavior.

Remember, in a modern computer that supplies USB floppy support for real-mode software (IE, DOS) it's all smoke and mirrors; it emulates floppy-related INT13h calls, not a floppy controller; if you run something like ImageDisk or Teledisk the gig is totally up. So when the guy in that YouTube video asks his modern computer to boot from floppy drive there's a higher level conversation going on here; the computer is asking the floppy drive to check if there's floppy in the drive and, if so, what the geometry is, and it's left completely up to the microcontroller to figure that out. What I think is going on here is, like Chuck noted in his reply to the video, is since 5 1/4" and 3.5" high density drives both use the same data rate and track counts (and possibly because there's even a supported-by-the-USB-floppy-standard variant of 3.5" drives that turns at 360RPM, that Japanese 1.25MB format) the drive is able to pick up that, yes, there's a disk inserted, it should be using the 500kbps data rate, and it's successfully able to determine the number of sectors per track and sector size. It's thus reporting that information to the PC's BIOS in reply to the media IDENTIFY command (see the API doc) and at least with this particular combination of controller board and BIOS everything falls into place: the INT13h calls "just work", allowing the drive to be booted and read/wrote successfully.

Here's the big provisos on the DOS side that didn't appear in the video and I would bet a shiny nickel that would trip it up hard:

1: I don't think there's much of a chance if you inserted a blank disk in that thing that a FORMAT command would work. I mean, maybe, it's possible, the USB disk API allows for "custom" disk formats to be optionally specified, and maybe there's a long-shot chance that after booting from a 1.2MB disk the computer's BIOS would use the "Long-hand" format of the command so a subsequently inserted blank media would be formatted the same way as the first thing it detected, but I think it's more likely it would fall back to trying to do one of the "native" 3.5 inch presets documented in the UFI command specification.

2: I'd be *deeply* surprised if a low-density disk actually worked. I don't believe the decision to "double-step" is encoded on the disk in any form, it's implicit when a 25okbps format is seen in a 5.25" drive with the standard PC bios. If you made a custom formatted 720k "Quad-density" disk that probably would, it'd look just like a 720K 3.5" disk.

Anyway, again, that's why I think it works with DOS, because DOS isn't second guessing anything. Windows 10 seems to be second guessing either the "IDENTIFY" API results, assuming something is broken if it's not one of the standard 3.5" formats, or maybe Windows is doing something really heinous and instead of using IDENTIFY it's sending a series of MODE SELECTs to probe on its own if it's one of the few geometries it thinks are valid. If it's the latter that might explain why it *kind* of looks like it works with the low density disk, it's mistaking it for a 720k, but of course it doesn't *actually* work because the block addressing is all fouled up because it doesn't know how to double-step. (IE, my guess is that bit where he creates a tiny file and pokes at it only *looks* like it works because of write caching, it's screwing up when it physically goes to write the data.) Per Chuck's comments on the video it might actually work if he either used a 40 track drive or was trying the experiment with a custom quad-density formatted (720k) floppy. (I vaguely recall that DOS utilities to format such floppies in a 1.2MB drive exist?)

It would be "interesting" to see if a different OS like Linux is willing to let 1.2MB floppy disks work. (Or even if older versions of NT-brand Windows don't second-guess.) But it still remains that I seriously doubt the USB controller itself properly "knows" what kind of drive is attached, it just happens to be willing to deal with what it sees from already formatted disks. An interesting experiment would be to boot DOS from "something else" (a hard disk partition or whatever) and see what Norton SI identifies the *empty* floppy disk as; I'd venture it either wouldn't see it at all, or it would say it's a 1.44MB floppy because that's going to be the default when the IDENTIFY command is run on an empty drive. Only reason it's showing as 1.2MB is the real-mode USB floppy driver is returning the inserted media size as the drive capacity.
 
Last edited:
The USB97FDC document talks about using the USB floppy controller with tape. The USB97FDC2-01 document mentions the idea of custom firmware to handle vertical recording (i.e. 2.88 MB drives). I think with a copy of the source code for those drivers adapting to other standard drive models would be relatively straight forward. Of course, I have yet to find a copy of the drivers so the possibility of being wrong is quite high.
 
Truth be told, as interesting as the USB97FDC chip is, nowadays, it's probably much easier to take a commodity FDC, some SRAM and a minimally-USB capable MCU and work out your own device.
 
Something else to chuck out there: there's a USB floppy formatter program for Linux, "ufiformat":

https://github.com/tedigh/ufiformat/

For Linux that specifically lists the high-density 1.2MB format (80/2/15/512) as an option, IE, it can instruct (at least some) standard USB floppy drives to format a disk like that. (See "ufi_format.c"). This thus indicates that it's not particularly remarkable that, again, at least some USB floppy drives have sophisticated enough formatting detection algorithms to see the format of a 1.2MB floppy and report it correctly.

Honestly, I kind of skimmed the YouTube video a little bit, did he say he ever actually tried the drive on a *different* modern OS, like Linux? (Or heck, even MacOS or something.) My guess is, given the DOS results, that the reason Windows doesn't work specifically is a quirk in either the Windows drivers or some higher-level element, like some guy at Microsoft specifically deciding that a floppy drive returning some oddball geometry indicates some kind of attack or other problem.

It might also be interesting to see if Linux plus ufiformat could actually *format* a disk in that thing.
 
I've used ufiformat in the past, but not recently. Success depends on what the USB drive supports. Some, for example, are smart enough to do dual-speed operation(300/360 RPM) and format NEC98 floppies (8*1024/2/80) (1.23M).
 
Eudimorphodon said:
Windows 10 seems to be second guessing either the "IDENTIFY" API results, assuming something is broken if it's not one of the standard 3.5" formats, or maybe Windows is doing something really heinous and instead of using IDENTIFY it's sending a series of MODE SELECTs to probe on its own if it's one of the few geometries it thinks are valid
Click to expand...

What is this "IDENTIFY" API of which you speak? There is no such thing in the USB Mass Storage Class UFI Command Specification which you referenced.

The Windows SFLOPPY.SYS driver used for USB floppy drives uses the READ FORMAT CAPACITIES 23h command and looks at the Capacity List returned by the drive and tries to match the Number of Blocks and Block Length fields of each entry in the Capacity List against a small table of known floppy disk types. The list of matching types will be returned by the SFLOPPY.SYS driver in response to a IOCTL_DISK_GET_MEDIA_TYPES request. Higher level code uses that list to determine which choices are available when formatting a floppy. When the SFLOPPY.SYS driver receives a IOCTL_DISK_FORMAT_TRACKS request from higher level code the requested MediaType must be in the lists of known floppy disk types that were matched against the Capacity List returned by the drive. The FORMAT UNIT command is used to format the floppy with the Number of Blocks and Block Length fields of the Format Descriptor set to the values of the matching entry in the Capacity List.

The Windows SFLOPPY.SYS driver really just relies on the USB floppy drive recognizing the format of the currently inserted media and doing the right thing of mapping the Logical Block Address in READ and WRITE commands to physical tracks and sectors. If the USB floppy drive doesn't correctly recognized the format of the currently inserted media on its own, the Windows drivers aren't going to try to do anything magical to try to make things work.
 
I suppose I should have been more precise instead of generalizing (IE, making up “IDENTITY” as the actual command name because I vaguely remembered IDE drives have something like that.) In the document I linked above there is described the “flexible disk page” data structure (page 26) which can describe in detail all the geometry variables for a floppy disk. (Heads/sectors/cylinders/sector size/data rate/etc.) It appears that this data can be both read and written. (IE, you can read this data to set the geometry of a mounted floppy is, or you can, say, supply it before issuing a FORMAT command.) The document also talks on the previous page about shorthand “media type codes” and enumerates three special presets referring to the three “normal” formats for 3.5” floppy drives, and a forth option which is “whatever it is currently”.

As is demonstrated in the YouTube video we’re talking about the drive *does* seem to identify the format of an inserted 1.2MB floppy just fine when it’s being driven by the BIOS compatibility shim in the poster’s PC. Windows, however, refuses to see the same high density disks. (It does “see” low density disks, but treats them incorrectly, no doubt because the usb controller has no clue about double-stepping.) So based on your knowledge of the Windows floppy driver, why would this difference in behavior exist? My theory basically boiled down to the Windows driver doing a MODE SENSE command and not liking what it saw in the flexible disk page (or a READ CAPACITY, maybe, and not liking the size?) while the BIOS driver just rolls with whatever geometry is returned.
 
The Windows SFLOPPY.SYS driver used for USB floppy drives might only use the MODE SENSE 5Ah command to look at the WP Write Protected bit in the returned Mode Parameter Header in response to a IOCTL_DISK_IS_WRITABLE request from higher level software to determine whether the currently inserted media is writable or write protected.

The SFLOPPY.SYS driver used for USB floppy drives doesn't use the MODE SENSE 5Ah to command to look at the Medium Type Code returned in the Mode Parameter Header, and doesn't look at any fields returned in the Flexible Disk Page, nor does it use the MODE SELECT 55h command to try to change any of the fields in the Flexible Disk Page.

The SFLOPPY.SYS driver simply expects the USB floppy drive to have enough intelligence itself to use its own vendor specific internal algorithms to correctly identify the format of the currently inserted media, and return correct values in the Last Logical Block Address and Block Length In Bytes fields in response to a READ CAPACITY 25h command, and to do the correct mapping from the Logical Block Address field of a READ(10) 28h and a WRITE(10) 2Ah command to the correct Track, Head, and Sector values appropriate for the format of the currently inserted media.

If a USB floppy drive controller that is normally only used for 3.5-inch floppy drives by default only expects 8, 9, or 18 sectors per track for standard 3.5-inch floppy formats (and maybe 21 sectors per track if it supports DMF) and that controller is attached to a 5.25-inch drive, and it needs the host to send a MODE SELECT 55h command to change the Sectors per Track field value to 15 to work with a standard 5.25-inch floppy 1.2MB format, that isn't going to happen with the standard Windows SFLOPPY.SYS driver.

The operation of the SFLOPPY.SYS driver used for USB floppy drives is all based on the USB floppy drive hardware that actually existed and was available for testing in the Windows 2000 timeframe, and it hasn't really changed since the Windows 2000 timeframe.

Without doing some investigating with a similar 5.25-inch hardware setup as was used in the referenced YouTube video, I'm not sure what it would take from the software side of things to make that hardware setup work as desired when attached to a Windows system.
 
gslick said:
The SFLOPPY.SYS driver simply expects the USB floppy drive to have enough intelligence itself to use its own vendor specific internal algorithms to correctly identify the format of the currently inserted media, and return correct values in the Last Logical Block Address and Block Length In Bytes fields in response to a READ CAPACITY 25h command, and to do the correct mapping from the Logical Block Address field of a READ(10) 28h and a WRITE(10) 2Ah command to the correct Track, Head, and Sector values appropriate for the format of the currently inserted media.

If a USB floppy drive controller that is normally only used for 3.5-inch floppy drives by default only expects 8, 9, or 18 sectors per track for standard 3.5-inch floppy formats (and maybe 21 sectors per track if it supports DMF) and that controller is attached to a 5.25-inch drive, and it needs the host to send a MODE SELECT 55h command to change the Sectors per Track field value to 15 to work with a standard 5.25-inch floppy 1.2MB format, that isn't going to happen with the standard Windows SFLOPPY.SYS driver.
Click to expand...

Yeah, so... that's the question, because it seems at least from the behavior displayed in the video that the drive *does* have sufficient intelligence to identify the format on an attached high-density 1.2MB floppy drive well enough to satisfy the BIOS. (In the video you can see that the BIOS thinks there's a "1MB" filesystem on the attached drive, it can boot a DOS disk, and the booted DOS can successfully read and write the mounted disk.) It seems pretty unlikely to me that the PC's BIOS is sending a MODE SELECT to the drive forcing it to try a 15 sector format. I mean, I guess it's not impossible, but why would it? (My expectation would be personally that the BIOS would be *dumber* than the Windows driver, not smarter.)
 
MS drivers may be the best drivers for MS's purposes. Getting fewer support calls from users accidentally creating a disk in a format that can't be widely used may be more important than supporting the relative handful of us that want to use those oddball formats. The older USB floppy drives list more formats as being available with the Win9x drivers than with the XP drivers.

Recreating the whole stack for USB floppy support (including firmware on the drive) always looked like a lot of work to produce something that could only read common 5.25" formats.
 
Just for laughs I pulled out my generic rotgut USB floppy drive to try a few experiments with Linux. Running the "-i" switch in ufiformat indicates that the 5.25" 1.2MB format is an available option distinct from that Japanese "1.25MB" format.

Code: 
$ sudo ufiformat -i /dev/sdb
vendor: Y-E DATA
product: USB-FDU
write protect: off
media type: 2HD
status block size kb
formatted 2400 512 1200
formattable 2880 512 1440
formattable 1232 1024 1232
formattable 2400 512 1200

Attempting to low-level format a disk with this works:

Code: 
$ sudo ufiformat -f 1200 -v -V /dev/sdb
format on device=/dev/sdb, size=1200
geometry: track=80, head=2, sector=15, block=512
done

I also formatted a disk with the normal 1.44MB format, and there's a clearly distinct difference in the pitch of the motor so it appears that even this "unremarkable" drive supports switching between 300 and 360RPM. I slapped a format on the disks with mkdosfs and verified both sizes would mount under Linux. That done I downloaded some DOS install disks from (the usual sources) in 1.44 and 1.2MB sizes and DD'ed them to the respectively formatted floppies before unplugging the drive from the Linux box and doing some more experiments.

So... long and short of it, at least in this case Windows 10 seems to actually work just fine with the 1.2MB floppy. It mounts on the desktop, I can pull files off of it, and I can also create a small text file on it without obviously corrupting the disk. I also tried booting from the disk and, likewise, seems to work fine, I can at least get to the first page of the MS-DOS 6.22 installer. (It crashed with a "memory allocation error, cannot load COMMAND, system halted!" when I hit F3 to exit the installer, but I doubt that's the disk's fault.) The 1.2MB floppy also mounts fine in MacOS if I plug the floppy drive into that. By all appearances if your USB floppy drive's firmware is able to detect the format and map it to something it "knows" then, yeah, should work.

Based on that I take back the speculation that Windows just generically hates "odd size" floppy drive formats, I can't think of a material reason why logically at least this setup should look any "different" than having a physical 1.2MB floppy drive hooked up in place of the 3.5" mechanism if the drive controller is working well enough to suss out the detection. (Like it appears in the video the drive *is* doing when running the BIOS driver.)

I would really like to see the "ufiformat -i" output from that YouTuber's drive now. The direction I'm speculating in now is that their drive controller's firmare might actually be dumber than this YE-DATA drive, in that it doesn't explicitly support the "1200" size so when it replies to a "READ CAPACITY" it's returning something that Windows can't suss out (but again, DOS doesn't care). It looks like "READ CAPACITY"'s return data is just the number of logical blocks times size, maybe the drive is groking the sector size/count per cylinder correctly but multiplying that by 77 instead of 80 because that's what it does for 360RPM disks?

(By contrast, my drive *does* seem to know about the concept of an 80/2/15/512 disks and reports a "correct" number which Windows is happy with?)
 
... just for completeness' sake, I also tried formatting a disk with that Japanese "1232" format, and it worked fine to create the FS on the Linux box, copy a file to it, and then plug the drive into the Windows 10 machine and read it off. So apparently US Windows 10 doesn't mind floppies with 1024 byte sectors. Curious, can normal US DOS versions read these? (I don't have a DOS machine with a physical high-density floppy drive set up at the moment.)
 
Generic US-market MSDOS wont handle the 1.23 format with 1024 byte sectors. (On a much earlier thread, we went through the why and wherefore). However, long ago, I produced a driver, NECSYS that could do just that by blocking/unblocking the 1024 byte sectors to 512 byte ones:

Sydex NECSYS - A Diskette Driver for NEC 9801 MS-DOS Diskettes
Version 1.05

March, 1997

This diskette contains the following files:

NECSYS.SYS - Device driver for NEC diskettes
NECSYS.TXT - Plain text documentation for NECSYS
NEW.TXT - What's new in the current release
README.TXT - This file

Please consult the printed documentation for NECSYS for installation and
operation information.
Click to expand...

If you use NECSYS for formatting, it even inserts the appropriate 1,024 byte boot sector for the PC98.

Of course, Japanese MS-DOS handles these just fine--and most versions of NT since about NT 4.0 can handle them. The 3.5" version even reads (but not formats) just fine in an LS120 under NT or a system equipped with a 3-mode drive and controller.
 
Eudimorphodon said:
... just for completeness' sake, I also tried formatting a disk with that Japanese "1232" format, and it worked fine to create the FS on the Linux box, copy a file to it, and then plug the drive into the Windows 10 machine and read it off. So apparently US Windows 10 doesn't mind floppies with 1024 byte sectors. Curious, can normal US DOS versions read these? (I don't have a DOS machine with a physical high-density floppy drive set up at the moment.)
Click to expand...

The Windows SFLOPPY.SYS driver used for USB floppy disk drives is aware of the NEC 1.23MB format. There is a defined F3_1Pt23_1024 constant for that format in the MEDIA_TYPE enum in the Windows winioctl.h header file.

The driver will return that media type in reponse to IOCTL_DISK_GET_DRIVE_GEOMETRY and IOCTL_DISK_GET_MEDIA_TYPES requests from higher level software if there is an entry in the Capacity List returned by the drive in response to a READ FORMAT CAPACITIES 23h command that matches the Number of Blocks and Block Length fields for that media type.

Code: 
    // Blocks  BlockLen CanFormat H   T  B/S S/T
    {0x0004D0, 0x0400,  TRUE}, // 2  77 1024   8  1.23 MB F3_1Pt23_1024 (NEC)

    // Cyl      MediaType       Trk/Cyl Sec/Trk Bytes/Sec
    {{77,0},    F3_1Pt23_1024,  2,      8,      1024},
 
Chuck(G) said:
Generic US-market MSDOS wont handle the 1.23 format with 1024 byte sectors. (On a much earlier thread, we went through the why and wherefore). However, long ago, I produced a driver, NECSYS that could do just that by blocking/unblocking the 1024 byte sectors to 512 byte ones:
Click to expand...

I assume this driver does rely on the 3.5" drive that's installed being able to switch between 300 and 360RPM? On a machine with a "normal" floppy controller that controllable in software or do you have to physically rejumper to speed setting on the drive to use the driver?

Anyway, yeah, I guess until I saw it work I was wondering if support for that in Windows NT-onward was region locked or something since I'd never encountered a floppy with that format in the flesh. (No good reason I can think of *to* lock it, but, you know, weird things happen.)
 
Depends on the motherboard and controller. I've seen boards that support 3-mode floppies and those that don't. And yes, the drive has to bring out the signal for 300/360 operation. Of course, there's nothing stopping you from bringing out an external switch.

For my own use, I just have a couple of external drives permanently jumpered for 360 RPM use. A lot of old Japanese PLCs use that setup (e.g. Mitsubishi/Mazak).
 
Hello,

Just to throw this out there, the Adafruit folks have been working on floppy drives connected to Arduino-based controller boards (particularly Raspberry Pi Pico), and making the result show up as a USB block device.

It’s a github project Adafruit_floppy

You can follow the progress on their blog Here

-Crawford
 
ajacocks said:
The Applesauce FDC is not a generic USB FDC, but it does a fantastic job reading and writing a ton of formats. There is only Mac software, so far, but Windows and Linux support is coming. I run mine from an Arch host, using Mac OS in a VM, on VirtualBox.

- Alex
Click to expand...
Similarly there are the FluxEngine and GreaseWeazle which both are not really generic USB access but with their own software can read and write disks as a whole. FluxEngine I think supports Mac Linux and Windows and supports the GreaseWeazle. Not sure what the GW supports natively. GreaseWeazles are easily found preassembled. FluxEngine is more DIY where you solder a header onto a commodity SBC (Cypress PSoC5LP CYC8CKIT-059) which is usually available for $10 but are wildly overpriced now due to supply issues. The downside is that the PSoC5LP is only really programmable from Windows, but once programmed it should work with anything.
 
Funny enough, I own one of these weird USB 1.44mb drives, and it can image multiple format 3.5" diskettes with zero issues ( don't think it will do 2.88). I use it primarily to backup and write older Mac diskettes/images and to write bootable dos diskettes and image old games. It reads and writes at 2x which is nice. I use winimage for imaging/writing.

Here is some information on the drive...

It's made by a company called Smartdisk. Model no FDUSB-M.

Under that is another more generic model no - YD-8U10.

A quick look on eBay shows quite a few up for sale. I do know it was created for G3 iMacs, but has zero issues in windows. If wanted I can can open it , to reveal it's magic ( what chip(s) it's using )
 
Last edited:
You must log in or register to reply here.
Back
Top