Good questing, and while we are at it:

- What is the optimum GAP length for 10 sector format (Dead on Time)?

- How should the GAP length in DSK Images be interpreted? In the Dead on Time Image it's oviously bogus.

Yes these are good questions.

Markus' message is the result of a conversation we had together. He was working on improving the timing so that Orion Prime would run better under javacpc.

Following this I wrote a test program that checks the timing on a real CPC it checks:

1. if we have two sectors, c1 and c2, ordered like this: c1,c2 it checks the timing between these

2. if we have two sectors, c1 and c2, with a sector in the middle like this: c1,c6,c2 then it checks the timing between c1 and c2 (so takes into account the timing of ignoring c6)

3. if we have c1 at the end of a track and c2 at the beginning it times this (the final gap at the end of the track and the size of the data inserted before the first sector)

4. if we have 1 sector c1 at the beginning of the track and we try to read c2, which doesn't exist, find the time for this before fdc gives up.

Basically these should confirm timings we already know. And for the first two tests they were exactly as we expected.

The GAP size can be calculated based on the number and sizes of the sectors, and based on the MFM disc structure. But I can't say what is the optimal gap because this may depend on the loader and the fdc.

For each sector there is 62 bytes required + size of sector's data.

At the beginning of the track there is 146 bytes from start of index pulse.

Track size is approx 6250 bytes long. The last gap can be a variable size and fills to the end of track.

The formula for a track with all sectors same size is:

gap = (6250-146- (num_sectors*(sector_size+62)))/num_sectors

This is an approx size and assumes the last gap on the track is the same as the gap between sectors.

I don't know if there is a minimum or maximum size for this gap.

Well on a dsk, I really don't know. Yeah the values are not really meaningful, so I guess calculate a gap that seems sensible and compare it. But then this will not work correct for dsks where the gap is very important (e.g. Orion Prime).

EDIT: Another problem you have is that for some dsk, they could end up storing more than is possible on a track.

So for these... not sure yet.