Thanks again, Dave!

Roy J. Tellason rtellason at blazenet.net
Wed Jan 11 17:07:15 CST 2006


On Wednesday 11 January 2006 05:59 pm, Scott Stevens wrote:
> 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.

I would tend to agree with this.

> 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.

Maybe relevant in terms of what you have to do while programming,  though.  
Just a guess,  as I haven't ventured there yet.

> A piece of test equipment is designed for a specific purpose, and a computer
> repurposed to something like this will be as well.

Yup.

Only problem is,  I really don't have enough room here to stick another 
machine dedicated to reading CP/M disks,  so I guess one of my other boxes is 
going to have to do...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin




More information about the cctalk mailing list