So basically, the Amiga floppy hardware is totally alien to what the PC uses, and presumably it has a totally separate driver. It is so different it would be pretty hard to even put a layer of abstraction over the two to make them look the same to something as specialized as a floppy formatting utility; I take it the Amiga has its own anyway. As it turns out it is nigh on impossible to read Amiga floppies using PC hardware, as the PC FDCs are sector oriented and there is no practical way to read whole tracks at a time.

The Ataris are another matter. They use variants of the same floppy controllers as the PC, and are sector-oriented, so I expect the driver is pretty similar to the i386 floppy driver. The same ioctls should be supported as well, though I haven't taken a look. So there is no good reason Superformat shouldn't work there, as long as any endian problems are sorted out.

68K-based Suns also use the same controller family as the PC, and should be similar to the Atari situation (probably likewise with 68K-based Apollo and HP stuff, if anyone still has any lying around).

Finally, there is the Macintosh, which is yet another alien beast; I am pretty sure it uses a very alien FDC, nothing like the Amiga or the PC.

So to sum it up, the CPU has rather little to do with it; it doesn't make much sense to refer generically to 68K machines when it comes to floppy hardware, as there are quite a few different ones to consider.

DCN

From: Joerg Dorchain joerg@dorchain.net

...

...

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=20 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:=20

• 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.=20

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 ;-)

...

=20 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

--V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9KVyhjY4+4PdzvOARAtXLAKCInNQaP+L1rjjLox8BUiTR49bhHgCghgHx Jie86k3n2nivjwHZLQwFQP0= =+SFV -----END PGP SIGNATURE-----

--V88s5gaDVPzZ0KCq--