Thanks again, Dave!

[Scott Stevens]

On Wed, 11 Jan 2006 17:07:15 -0500
"Roy J. Tellason" <rtellason at blazenet.net> wrote:

> On Wednesday 11 January 2006 12:16 pm, Dave Dunfield wrote:
> > > > 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.
> 
> Yes.  There are some folks who are using linux to do realtime control,  but it 
> takes some kernel hacking,  and I am not up on the details of what needs to 
> be done to accomplish this at the moment.  Look on linuxcnc.org for more info 
> on that...
> 
> > 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.
> 
> I haven't gotten into programming under linux to this extent,  but I'd guess 
> so.  There's "user space" and "kernel space",  and all sorts of other things 
> to consider.  At this point in time there are _so_ many apps that I find 
> useful that I haven't yet gotten around to poking around on the programming 
> side of things...   :-)
> 
My feeling on the matter is that when a computer is being used to
image and/or salvage data off of non-native disks, it is being
used as a piece of test equipment, not as a general purpose
computer.  As such, it's 'legitimate' to run it as root, dig deep
into the driver hierarchy and kernel, etc.  A lot of the real
power of a diskette imaging/analyzing system will be deep within
the system.  So making distinctions between 'user space' and
'kernel space' might be interesting, but ultimately are
irrelevant.  A piece of test equipment is designed for a specific
purpose, and a computer repurposed to something like this will be
as well.