11 Jan
2006
11 Jan
'06
2:59 p.m.
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:
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...
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.
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 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... :-)