Thanks again, Dave!
chenmel at earthlink.net
Wed Jan 11 16:59:34 CST 2006
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
More information about the cctalk