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.
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
More information about the cctalk