Well, this wasn’t as easy as I first imagined.
There are some issues:
1> By the time you’ve detected the 4489 4489, it’s too late to do much about it. This is because I’m writing one bit at a time, and once you’ve seen the 4489, it’s already (probably) shifted. There’s no way to compensate for the shift because adding 0’s (for instance) to fill out the current byte will screw up the decoding on the PC, because the PC looks for the 4489 as a guide to when to start decoding. You end up with something like 4489 (but shifted), then some binary 0’s(to properly shift the data), then the start of the sector 0x55 (for the FF identifier). This few extra 0-bit’s of shift data screws up the decoding.
2> Then one might say, don’t start recording until you are properly shifted. Sure you lose the first track, but just record extra data. This sounds good on paper, but once you hit the gap, the bit-shift is different. Now you have to detect the gap, which requires decoding the sector header and looking at the sector offset, and then counting from there.
3> I think post-processing within the SX sounds good, but implementing a block-shift(which rotates around the edges) in memory can’t be easy. While I think my SX and the memory is fast enough to make this feasible, it has the same problems of detecting multiple shifts within the data and correcting for them.
I think it’s worthy to note that Marco Veneri when writing AFR decided (I believe) that doing a one-time shift fix was impossible and instead wrote a number of routines to find the shifts, and then routines to extract bit-shifted data from the byte array. I can’t believe that he wouldn’t have preferred a one-time fix routine, and then operate on just the data.
With this being said, I think it would be advantageous to do this on the SX because this eliminates a bunch of routines on the PC. If I can do it with little headaches on the SX, then I think thats the right way to do it.
I just haven’t stumbled on the right way yet.