On Thu, 22 Dec 2005 20:36:46 +0000 (GMT)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
On Thu, 22 Dec 2005 00:26:44 +0000 (GMT)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
To get back to disk imaging, I may be stupid, but
I do
wonder if it's actually possible to write such a program to
run under linux or any other multi-tasking system.
Since it's possible under Linux or one of the BSD Unixes to
completely compile out support for the floppy controller, it
should also be possible to pull said kernel code out, and
create a (super)user-mode module application out of it to do
whatever you want with the disk controller. More of this sort
of thing should be done, in my estimation. (my two cent
opinion, I know, since I should do-it-myself).
You are, IMHO, missing the point. Under linux, you have an
ioctl() call that lets you send any ocmmand bytes you like to
the FDC. You can therefore get that chip to do anything that
it's capable of. And that call takes care of setting up the DMA
controller if you need it, making sure the DMA buffer doesn't
cross a page boundary, and all the other nasty little details.
Actually sending a ReadID command is not a problem.
The problem is that the ReadID command reads the next sector ID
to come round to the head. The only way (that I can see) to
make sure you've not missed any is to keep on sending ReadID
commands (and getting the results) until you get the same ID
again that you got from the first one -- i.e. the disk has gone
round once.
The problem on a multi-tasking OS is that your task might be
switched out half-way though this. You might therefore miss a
sector ID entirely. And how ever many times you repeat it, you
can never be sure you've not been unlucky and missed the same
one each time.
It's not difficult to boot linux in single user mode. And then to
think of it as an infinitely flexible MS_DOS type of OS. After
you've gotten the image safely stored somewhere, boot it to a time
sharing mode to move the image around and/or explore it.