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.

[Olaf Barthel]

Originally Posted by 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).

The trackdisk.device uses a "sector gap" of 1660 bytes. I learned this from the Amiga Unix flopf.c/flopf.h source code and some spelunking in the official Amiga source code. The source code refers to the "sector gap" as "slop"

A commented 'C' version of the MFM encoding/decoding operation can be found here: https://github.com/obarthel/trackfil...ncode_decode.c

Also available is a basic data recovery program which will try to find the best version of a sector in multiple attempts, producing an ADF image file: https://github.com/obarthel/trackfil...ies/raw_disk.c

The code shows how "it" can be done, although in a pretty pedestrian and none too efficient manner (I hope it is not wrong).

I still do not understand how the original Amiga Unix flopf.c code performs the MFM encoding in just two lines. Naturally, these lines are the only ones which bear a code comment: /* aren't I clever */

[NorthWay]

Is there a measure of how much/how many percent of the cylinder can be written before the size of the head or something interferes with a theoretical 100% of the surface being used?

[paraj]

Originally Posted by Olaf Barthel

The trackdisk.device uses a "sector gap" of 1660 bytes. I learned this from the Amiga Unix flopf.c/flopf.h source code and some spelunking in the official Amiga source code. The source code refers to the "sector gap" as "slop"

A commented 'C' version of the MFM encoding/decoding operation can be found here: https://github.com/obarthel/trackfil...ncode_decode.c

Also available is a basic data recovery program which will try to find the best version of a sector in multiple attempts, producing an ADF image file: https://github.com/obarthel/trackfil...ies/raw_disk.c

The code shows how "it" can be done, although in a pretty pedestrian and none too efficient manner (I hope it is not wrong).

I still do not understand how the original Amiga Unix flopf.c code performs the MFM encoding in just two lines. Naturally, these lines are the only ones which bear a code comment: /* aren't I clever */

For data bits a and b (in that order), the clock bit for b is: a NOR b (i.e. 0 except for two consecutive 0's).

((d0 << 1) | (d0 >> 1))

computes "a OR b" aligned in the clock bit positions (and 0's for the data bits), the bitwise negation makes that NOR. Almost there except we now have 1's in all the data bit positions. That could be corrected by masking with ~mask, or like the code is doing oring with mask before the NOT.


I.e. instead of the more obvious ~C & ~M, it does ~(C | M). (De Morgan's law)

[ross]

Originally Posted by Olaf Barthel

The trackdisk.device uses a "sector gap" of 1660 bytes. I learned this from the Amiga Unix flopf.c/flopf.h source code and some spelunking in the official Amiga source code. The source code refers to the "sector gap" as "slop"

Well, I don't know if it's "slop", but it's technically wrong for 22 sectors/track
Why 1660 bytes? This is a selected value because it is 'certainly enough', but not with a defined logic.
Or at least it is not specified in the sources, so it is surely a value seen 'somewhere else' and 'if it worked it still works'.
And if the logic is that "enough is enough", why wasn't it doubled in the case of the 22 sectors? [note: I didn't look at the code but only read the comments]

If I know the duration of a cell, how many cells a sector requires, what is the rotation speed of the floppy and what is the maximum tolerance that I am willing to support as a difference for the speed, I can define and calculate the gap perfectly.

But since here we are working with mechanical systems and subjected to various analog problems, even a somewhat random value is fine

[ross]

Originally Posted by NorthWay

Is there a measure of how much/how many percent of the cylinder can be written before the size of the head or something interferes with a theoretical 100% of the surface being used?

Amiga can do a great job in this case since it has perfect and total control over reading and writing and practically all the cells of the track are usable (except for a few bits on the last word written).

So over 99.9% is usable

But I don't know if I understood your question well..

[Thomas Richter]

Originally Posted by ross

A correct precompensation can help in some cases.

There are values where the trackdisk.device could change that value, however, from the default values, this logic just does not seem to be effective. This said, I found little documentation on how "precompensation" actually works, i.e. what it performs physically.

[ross]

Originally Posted by Thomas Richter

There are values where the trackdisk.device could change that value, however, from the default values, this logic just does not seem to be effective. This said, I found little documentation on how "precompensation" actually works, i.e. what it performs physically.

It all boils down to the fact that physically signals that are too close together tend to distance themselves on the magnetic surface (it's the reason for the impossibility for coupled '11' for 2us cells DD floppy), and the problem is accentuated in inner tracks.
Sometime it help to reduce this effect to write the '1' center position x_ns closer, so when they move a little they are just at the right position.
Amiga can do this using x as a multiple (as usual) of the CCK.
Unfortunately it doesn't always have the expected effect or work at all.

EDIT: it's not known how Paula does this, but it probably 'anticipates' the normal setting of '1' in the bit-stream by x CCK.
The effect is possibly visible with a logic analyzer or similar.

[Thomas Richter]

Thanks, helpful. I still wonder what the physical effect is here, but never mind, at least it explains what Paula is supposed to do with this information. Given that it is actually not used, it is probably not overly helpful. Had anyone actually tried to play with this and see how it affects reliability?

[ross]

Originally Posted by Thomas Richter

Had anyone actually tried to play with this and see how it affects reliability?

Yes, I tried playing with it in the 80s and it had some effect with non-RLL(1,3) encodings (that is, better reliability with certain cases).
I didn't notice anything for normal MFM encodings (but I don't think it hurts to use it on the inner tracks).
in any case the DPLL in reading masks the problem..

But the effect should be visible even now using raw grabs with greaseweazle and similar where sampling is done at much higher rates than 2us, and where cells are at a better distance if precompensation is used in the inner tracks.

[Olaf Barthel]

Originally Posted by paraj

For data bits a and b (in that order), the clock bit for b is: a NOR b (i.e. 0 except for two consecutive 0's).

((d0 << 1) | (d0 >> 1))

computes "a OR b" aligned in the clock bit positions (and 0's for the data bits), the bitwise negation makes that NOR. Almost there except we now have 1's in all the data bit positions. That could be corrected by masking with ~mask, or like the code is doing oring with mask before the NOT.


I.e. instead of the more obvious ~C & ~M, it does ~(C | M). (De Morgan's law)

Thank you, this makes sense to me. As usual, what made me curious was the comment with its perfect trigger of "this is a puzzle, let's see how long it will take you to figure it out". So, why was this a clever solution? Maybe because the code comment emphasizes it

In the solution which I came up with, I attempted to go for "readable", with examples of what the operations performed will produce, without trying to be clever.

[Olaf Barthel]

Originally Posted by ross

Well, I don't know if it's "slop", but it's technically wrong for 22 sectors/track
Why 1660 bytes? This is a selected value because it is 'certainly enough', but not with a defined logic.
Or at least it is not specified in the sources, so it is surely a value seen 'somewhere else' and 'if it worked it still works'.
And if the logic is that "enough is enough", why wasn't it doubled in the case of the 22 sectors? [note: I didn't look at the code but only read the comments]

Yes, you are correct. The 1660 bytes need to be doubled for the 22 sector/track case and the "raw_read.c" code will do this if the TD_GETGEOMETRY command reports this number.

The 1660 bytes must have been arrived at by setting parameters for how much data should go into a single sector, within the constraints and tolerances for the 3.5" disk drives and also how stable the clock governing the DMA operations is for the interval in which the entire track must be read.

For a single MFM-encoded sector, that makes sector header + 512 bytes payload = 2 * (32 + 512) = 1056 bytes. For 11 sectors per track, that would be 11968 bytes. Adding 1660 yields a total of 13628 bytes. Those extra 1660 bytes make up 12% of the total 13628 bytes. Unless I made a mistake there, 12% seem like a lot.