USB32 USBMSD problem of re-read diskette

[Lars]

Right now I can only say this:
what you are experiencing is a bug in the media redetermination when one diskette is swapped with another.
When I was working on it, I was seeing that exact problem until I finally got that fixed.

If Lewis claims it works for him with the very same USB floppy drive as yours then either your host controller FW/HW is not the same as that of Lewis or it is a timing issue in USBMSD.ADD (USBMSD.ADD uses a timer interrupt routine to handle command timeouts plus context hooks to offload asynchronous processing to a suitable future point in time. Both, timer interrupt routines and even more so context hooks are influenced by and influence timing. What's more, invocation of context hooks can be delayed by invocation of other context hooks, scheduled by other drivers).

[Igor]

I can say about the timer that I know that the AN software contains an error (still?) Because of which we have a crutch SET NSPR_OS2_NO_Hires_Timer=1 in the config.sys file.
Nevertheless, I tried to run this set of drivers in the system where this error is eliminated. This did not bring a positive result and the timer error and the drivers mistake are different.
However, of course, the proper processing of equipment timouts is a very important thing. And I want to note that your software, as well as Windows, successfully copes with this.

[Lars]

I do not have the same USB Floppy Drive as you have but I now did some further tests with the USB floppy drive that I have.
1) I tried it on my notebook with Win 11, Intel CPU, USB 3.x: it will never attach, no matter how often I try.
2) I tried it on my Tower PC with Win 10, AMD CPU, USB 2.x and USB 3.x: it has problems attaching. Initially I attached to a USB 2.x port which did not work. I then tried a USB 3.x port and that helped. I had to plug multiple times but it would finally come alive. Initially, it would report error that "device descriptor cannot be read"
3) I tried it on the very same Tower PC with OS/2 (and USB 2.x only): it also does not always attach but the situation is better than with Win 10. Eventually, after unplugging and replugging, it will come alive.

What I can remember from the USB floppy drive that I have is that on device attach it needs multiple "DRIVE READY" commands to trigger the drive electronics and convince the motor to spin up. That command would need to be repeated until it would no longer return with an error (naturally, you would limit the attempts to some maximum retries).

So, taking the current situation, I would believe that USB floppy drives in general are not very reliable and sometimes need quite a few attempts until they finally come alive. This is likely true on each new media insertion. And it will vary from system to system.

Since I am not a AN customer, maybe you can add that to your problem report.

Another solution would be to buy a new up-to-date USB floppy drive.

[Igor]

Of the known problems of USB devices, I only faced with the problem of electrical contact in the connection. David pointed to me a large number of USB errors and I really found bad contact in the connection. Windows reacted to him with an unstable definition of a floppy disc drive. I eliminated poor contact and now the equipment is determined stably.

When loading the driver, he gives a command to rotate the drive engine only if the diskette is inserted. Your driver performs this operation regardless of the presence of a diskette. This is a significant difference at the time of loading.
Subsequently, the AN driver does not track the fact that the diskette is removed and does not conduct the "Drive Ready" check when addressing the diskette.
If timeouts affect the work of equipment, it would be the best decision to give the user the number of repetitions, for example, through the command line key.

[Lars]

By now, I don't think it is a timing problem in the driver. It is a problem of not testing for an inserted media long enough for the drive to react. The number of retries is too low and/or the check for inserted media is not done at all places required plus the returned error info ("sense code") is not properly taken into account (the "sense code" will for example tell you if the drive is not ready, does not contain media or if the media has just been swapped and whole bunch of other potential error/status conditions). Then, for a USB floppy drive, you need some special handling regarding the fact media might not be inserted (for a USB memory stick, the "media" is always "inserted"). That is what you observed: to try and access the media when there is no media inserted will lead to that typical "rattling sound" and Windows does the same.

What I did in the past was to install "Wireshark" under Windows which contains an additional "USB capture" feature (USBpcap).
That is what I used to track what commands in what sequence Windows issues against the USB floppy drive (by using it under Windows). I then modified USBMSD.ADD to follow that sequence (as good as that was feasible), including some guesswork about necessary retries.

And regarding that it works on one system while it does not on another system: the USB floppy drive HW has some physical variation even if it is the very same model (but a different physical drive !) and that can lead to one drive needing more retries than another drive (for example). This has to be anticipated and taken into account. You just cannot test against each and every USB floppy drive on planet earth.