GAP length - how to calculate?

[Devilmarkus]

Who can tell me, how to calculate the GAP length when I know Sector-size?

[nurgle]

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.

[arnoldemu]

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.

[nurgle]

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.

So how do I find out in dskwrite whether to use the GAP length stored in the dsk image or calculate my own? I guess the best option is to calculate wether the image would fit to a real disc with the stored GAP length and only calculate a new one if it would not fit otherwise. Other ideas? How did authors of other dsk tools solve this issue?

[Executioner]

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

The optimum Gap for any format is actually 1, so long as your loader can handle it and start reading the next sector immediately. If you use multi-sector read data commands you shouldn't need to interleave the sectors. AMSDOS doesn't do that, and it moves up to 512 bytes in memory each time a sector is read.

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

If the Gap in the Image is bogus there's probably not much that can be done. Either use it anyway, ignore it completely or fix it.

[nurgle]

The optimum Gap for any format is actually 1, so long as your loader can handle it and start reading the next sector immediately. If you use multi-sector read data commands you shouldn't need to interleave the sectors. AMSDOS doesn't do that, and it moves up to 512 bytes in memory each time a sector is read.

So I can write realiably to disc with aGAP length of 1? Interesting to know. I will try...

If the Gap in the Image is bogus there's probably not much that can be done. Either use it anyway, ignore it completely or fix it.

Yes, these are the options. But what do other DSK writing utilities do? Obviously they figured out a good method of doing the right thing automatically.

[Executioner]

But what do other DSK writing utilities do? Obviously they figured out a good method of doing the right thing automatically.

Probably the best way is as described a few posts above. Check to see it the sector data + all gaps is too large and if so either use a calculated Gap or a Gap of 1. The only problem with a very small Gap is that if there are not enough sectors to entirely fill the track, any remaining Sync data on the track may be found. eg. If you format the track with 18 size 1 sectors, then format with 9 Size 2 sectors and a Gap = 1, there will probably still be at least 1 size 1 sector visible at the end of the track. Increasing the Gap to the correct value causes the last sector to overwrite the existing data. The other way is to de-format the track first (by writing a single large sector which wraps over it's own Sync data).

[nurgle]

Thanks for the info!  Should be easy to implement. I just needed some assurance that the approach is correct.