GPL for read/write commands

[arnoldemu]

I have made some tests to check the function of the GPL parameter in read/write commands on the FDC.

For format it defines the length of GAP#3 (0=256 btes, 1 =1 , 2=2 etc).

I tried it with read data/write data and it made NO difference with the FDC in my machine, it seems useless in these commands. I can set it to any value and it does NOTHING.
So anyone else with knowledge of the FDC can tell me if it does do anything?

The only thing I can think of, which I didn't test, was that it could affect timings especially when reading multiple sectors.

[Targhan]

If makes a difference when reading several sectors (using the Read Sector instruction with first sector = x, and last sector = x+1). In which case, strangely enough, the FDC will wait as long as it takes to read the given Gap after reading each sector.

So if you set a Gap to 255 when reading two sectors (no matter what the physical Gap really is), the FDC will skip the second because it will miss its beginning, and it will have to wait for another turn to read the sector. I still don't know why such behaviour exists .

Targhan/Arkos.

[arnoldemu]

If makes a difference when reading several sectors (using the Read Sector instruction with first sector = x, and last sector = x+1). In which case, strangely enough, the FDC will wait as long as it takes to read the given Gap after reading each sector.

So if you set a Gap to 255 when reading two sectors (no matter what the physical Gap really is), the FDC will skip the second because it will miss its beginning, and it will have to wait for another turn to read the sector. I still don't know why such behaviour exists .

Targhan/Arkos.

Yes this makes a lot of sense. I will add extra tests for this.

The Intel 8272 document is the only one that gives a reason for GPL in read/write because it says this is to avoid a "splice point".

I've not tried it yet, but I am assuming that writing sectors or multiple sectors on this fdc, will cause gap bytes to be written after the crc for the sector, and the possibility then exists here that there will be a lost sync bit at some point when the writing stops, and so to avoid this when reading you set the read GPL to skip the problem and to ensure it writes/reads the next sector ok.

I already tried changing it with write, but only for writing a single sector and it did not corrupt the id field of the next sector so I assumed it was doing nothing here.

I can check if this happens with a special track setup

[Executioner]

I already tried changing it with write, but only for writing a single sector and it did not corrupt the id field of the next sector so I assumed it was doing nothing here.

Changing the GPL for write has exactly the same effect as for a read. It will cause the FDC to miss the ID field of the next sector and have to do another complete rotation if set too large. In general, this never really matters since the sectors are interleaved, but it is of course possible to reduce the GPL and read a whole track worth of sectors in one rotation with no interleaves.