Track Gaps


The track gap handling changed in addition to the previous update. Track gap encoding is re-aligned in a way that always simulates starting the “disk” writing process from the track overlap position and running it until before the same position.

This change is only noticable with track gaps that are different from default values. Previously in such cases, the encoding was correct as data is written after the last block until the first block, while the correct behaviour is data that is written before the first block, and after the last block.

This change is mostly useful for generic MFM support, where the track gap is often e.g. ‘4e’. Previously, depending on the complete track gap size, this value could be ‘4e’ or could become shifted as ‘e4’ if read from the first block backwards and the gap size was odd. Now due to the different encoding effort it is always reads as ‘4e’ properly.