Storing data on a floppy?

[oRBIT]

I'm nowhere near an expert on floppydisk technology and this is probably a stupid question so beware..
If you look on a floppydisk, outer tracks has obviously a larger diameter than the inner tracks. Wouldn't (in theory) be possible to store more data on the outer tracks than the inner tracks with a smaller diameter?

[pipper]

That’s what Apple drives and the Commodore 1541 did.

[alexh]

I believe the drives are CAV (constant angular velocity) and not CLV (constant linear velocity) and so information stored on the outer tracks is "bigger".

To do what you're suggesting you'd need CLV

[oRBIT]

Interesting. The inner tracks are perhaps more sensitive to errors aswell since they're smaller(?)

[Olaf Barthel]

Originally Posted by oRBIT

I'm nowhere near an expert on floppydisk technology and this is probably a stupid question so beware..
If you look on a floppydisk, outer tracks has obviously a larger diameter than the inner tracks. Wouldn't (in theory) be possible to store more data on the outer tracks than the inner tracks with a smaller diameter?

Not with how the Amiga makes use of this technology. The Amiga features no dedicated floppy disk controller and not even dedicated custom chip functionality designed for making the MFM encoding/decoding more efficient. I read that this was a deliberate decision and except for the DMA operations which move the data to/from the storage medium and the index sync, everything else is done in software alone. The MFM encoding/decoding uses the Blitter, with a disk format designed to make it efficient. One downside to this design is that the low level checksums are comparatively weak (no CRC8 for you).

The Amiga disk drive reads/writes a complete track in a single revolution. No matter which track is involved, the approach is always the same. When you write a track, it begins with the "sector gap", followed by the payload which includes information about what format the data is in, which track and sector this is, etc. and also features a low-level checksum. Addendum, some 40 minutes later (thank you, a/b!): Separate checksums cover this header information and the corresponding payload.

The further away the read/write head is from the spindle, the wider the recorded bits get "smeared" across the track The "sector gap" makes sure that there is a well-defined pattern which is a constant value that is different from how the payload is encoded. When the data is written by the hardware, the end of the track can end up overwriting the beginning of the "sector gap". This is clever, because it guarantees that no matter which track you are writing, there will always be a reliable and recognizable gap, followed by the first sync pattern which introduces the MFM data. The size of the "sector gap" shrinks and grows as needed.

Unless you use dedicated hardware, such as the floppy disk adapter which was available for "Emplant" back in the day that allowed for Macintosh 3.5" disks to be read with a standard Amiga external disk drive, you have no way to control the rotational speed of the disk per track.

[a/b]

I'll just add:
- there are 2 checksums per sector, one for header and one for data,
- you always write more than it fits on a track (but not too much more, so you don't fully overwrite the gap and then continue overwriting valid data) to ensure you fully overwrite the old data, and there are no extraneous syncwords and corrupt sectors that would throw your decoder out of sync when you are reading it.

[ross]

The write size of the "track gap" is constant per any floppy device, and depends solely on the rotation speed of the motor (neglecting the friction effects that any inserted floppy disk might add to the equation).
Between the internal and external tracks what changes is only the distance between the magnetic polarity transitions in the flux (because the writing speed of the cells is constant, as is the rotation speed of the motor).

So the internal tracks are the most 'difficult' because transitions are too close and can interfere with each other and 'move' the magnetized part on the material.
A correct precompensation can help in some cases.

About the length of the track in writing: it doesn't matter how much data is written (it can be even double the necessary!), but the important thing is that it is more than the minimum cells that can be written on the track and that the valid data is at the end of the buffer.
The best thing would be to measure this value and then dynamically add a safety margin and write that number of cells.
Since the valid data is at the end, the data at the buffer start is always part of the gap and if the valid data is less than the maximum for the track there will never be an overwrite of the valid data!

On reading the different data density is not a problem (within tolerance limits, which are in any case wide) since a mechanism called DPLL adapts the sampling point where the check for a flux changes is detected (which can dynamically change from the usual 7 CCK to 6 or 8).

'Short' or 'long' tracks are nothing more than tracks where the cell duration is greater or less than the standard 2us (and therefore 'physically' have flux transitions further or closer than normal).
The same very long track that is perfectly readable on the outer surface area may be illegible on the inner surface area.. the closely spaced flux changes severely interfere with each other. A good surface material can help.
And in fact when they moved on to HD disks they changed the material of the floppy surface.