Rich Talbot-Watkins wrote:I guess the other thing you need to do when trying to make a sector dump is to try reading each sector with every possible sector size, not just the one reported in the IDs. (I presume you get an error when trying to read a sector with a different size to its actual size?).
A "Data CRC error" will occur if reading with a different size, since the CRC is the two bytes immediately following the data.
I suppose you could create a 2048 byte sector which will give an accurate CRC with every read, by having the correct CRC after 128, 256, 512 and 1024 bytes.
Rich Talbot-Watkins wrote:So once you've determined each sector size, you can add up the total data size so far and keep going through the read sector IDs until you hit the track limit, though even this could be abused (by leaving a portion of the track unformatted).
Any data within a track has to be accessible via the sector headers, even if they are overread (on the 8271) so I've never seen a program which calculates the track length based on adding up the reported data sizes.
Rich Talbot-Watkins wrote:It's a surprisingly tricky problem to find loops in a set of data, but there are definitely ways you could format a disk to leave it absolutely ambiguous whether you had looped round or not (without literally comparing the sector data itself).
If you had a track with 20 sectors, 0 -9 followed by 0-9, I think that would defeat Enigma's way of computing the number, would probably upset a great number of DFSs too though.
I guess a certain number of protections would've been implemented deliberately to circumvent the different copiers that were out there.
Enigma baulks at the idea of a track having different track numbers specified in the sector headers, so just bypasses reading it... 3D pool uses this to it's advantage by having data which needs to be read contained within that track