Observations
about the floppy interface in NT/2K/XP are accurate. The
native floppy driver is hard-wired to expect Microsoft-format floppies,
even to having the boot sector information being critical. (Try clobbering
a boot sector and then reading an otherwise valid diskette--you'll get a
general failure). Sydex has quietly made a tidy side business of licensing
a kernel mode floppy driver for NT and 2K/XP (in addittion to Win9x VxDs)
to firms needing CP/M (using a DLL interface) or other direct access
(driver access) to "alien" diskette types. We're currently working on a
Vista driver. Operations like "sync to the index hole and read a bunch of
IDs nonstop" are atomic functions with the driver.
While this will keep most of our customers happy for the short term, I
expect that floppy-less Windows PCs will shortly become the rule. We're
actively investigating the possibility of a USB add-on floppy drive that
will be able to handle most formats. I also anticipate that FDC chips will
become rare birds, so implementation of some sort of FDC through software
of FPGA would seem to be the wise course. I've investigated downloading
special firmware into floppy USB chips, such as that used on the Teac
FD-05U, but Teac has not been forthcoming on the controller chip details
being used in any particular model.
Stuff like this makes me *SO* glad that I don't run any m$ crap later than 98,
and that I run mostly linux, not to mention not having gotten rid of any of
my CP/M boxes...
I expect that Linux would have similar issues. Basically any OS which uses
protected mode will likely disallow application program direct access to
system resources, and not expect interrupts to be generated from elsewhere.
Any general purpose multiprocessing OS, will likely have issues with real-time
critical operations as well.
I was corresponding with someone trying to get ImageDisk running DOSemu
a while ago, and ran into some of these issues. I pointed out at that time that
the only "proper" way to do a program like this under Linix or any other
"real"
OS would be to put the analysis function and flexibility to read foreign formats
into the floppy driver, where you do have direct access to the hardware, and
each phase/operation can be initiated in hard real-time by the interrupt
generated by the completion of the previous phase ... this is exactly what
Chuck is describing with regard to his enhanced drivers.
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools:
www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html