Hi all,
(disclaimer: If I left out interested parties in the Cc, please correct)
On Mon, Jul 08, 2002 at 10:22:24AM +0200, Geert Uytterhoeven wrote:
Subject: Re: superformat does not work on m68k machines
AFAIK, this is an m68k linux kernel limitation.
Yes, I know. But fdformat is said to work, so formatting floppies should not be completely impossible.
Do you know, is anybody working on the m68k kernel floppy driver?
Nope. It works, why should anybody tamper with it?
Adding the missing ioctls to the Amiga floppy driver does not seem to make sense (though it would be easy: just add a fourth drive type for user defined parameters at the head of the drive type list, then set unit[drive].type to &drive_types[0] and modify those parameters if a matching set isn't found).
Well, once I thaught about autorecognition features for the driver. The theory was easy: After the whole track is read, enter a stae machine and read enough bytes till you can make a decision instead of assuming a specific format slected by the minors. I boggled implementing it as bitwise state machines are scary monsters to me (character based ones are bad enough ;-).
For writing, due to the nature of the amiga hardware, it is easiest to deal with whole tracks and not with single sectors (or even smaller units). So for this, I once calculated the gap lengths (which at that time PC hardware needed ;) and hardcoded them in the code for the supported formats. To get the disired flexibility here, the calculation has to be done at runtime. At least the first implemation will be prone to errors.
The trackwise operation has two effects: - it will read and write (and, along with the process, de- and encode) a whole track if only a single bit in it is written. - Formatting is easy: Write a whole track without reading it first.
I.e. a track is reformatted everytime something is written to it. (Sidenote, the amigaos trackdisk.device does the same, but I discovered only afterwards.)
BTW, there wre tools like this for the amiga to get more out of floppies. IIRC they still exists on Aminet.
Additionally, these non standard formats are not wide spread. So I decided for myself to dig into the problem when I get my first strangly formatted floppy disk. In the past five years I encountered none.
This shall not prevent anyone from implementing it. In contrast, I can offer some help with testing the stuff and answer questions about programming the floppy hardware and MFM-encoding. It is just that I do not have the time anymore to go deeper into this.`
To start experimenting, there is a special ioctl that I used for debugging that returns the content of the raw track buffer as it is read by the hardware, so you can leave the driver alone and test in user space wether the detections works. (Erorrs in user space are core dumps, errors in kernel space are oopses, errors in interrupts just freeze - YMMV ;-)
Disclaimer: I don't even know if the floppy hardware can be programmed to support arbitrary formats. Drive formats are selected by opening the corresponding device on the Amiga.
Amiga floppy hardware is very flexible. It can basically read everything (even 1541 GCR disks) and also write it. The hardware is cabable of doing DMS from/to memory (within limits), and can syncronize the sync hole. The downside of this is that all de- and encoding has to be done is software between the raw format on disk and what is presented to the upper layers.
Bye,
Joerg