From both Tim’s suggestions and from a reinforcement from Agans’ Debugging book, Chapter 6, “Divide and Conquer”, they suggest to “Inject Easy-to-Spot Patterns”. And of course, I knew this from before, and I picked “AMIGA” which is truly easy to spot, but only AFTER its been decoded from MFM. I couldn’t tell looking in a hex editor whether I was seeing AMIGA or just plain junk. (because of the odd/even bit separation)
I created a test disk that had 100k of repeating 0xFF’s followed by 100k of 0x00’s. This worked well and the results of my current version of my software aren’t incredibly horrible. Obviously just enough of the sector headers are getting corrupted to make larger sections look incorrect. The bulk of the file is close. There are some problems with stuff getting shifted, and if you shift LEFT one bit from the 0x55’s you get 0xAA’s, so those two aren’t ideal choices.
I have now created a file with 200k of 0x00 – 0xff’s, ie the full ascii range. This should help me identify how exactly the data is being corrupted.
The good news is that I am still receiving a good number of sectors with my current software, and some of the sectors actually look complete! Also, at least a sector or two offset is EXACTLY 1088 bytes apart which tells me that I’m not completely off target, because my code is working in some cases.
I’ve contemplated spending time on getting the checksum working, which should be easy enough, but I’d rather see more headers and work on that stuff later.
[…] I read two different disks, one disk from years ago and my ever famous 0xFF and 0×00 disk from way back when. […]