I did also post (a version of) this on HackerNews.
I think the software decoding technique used here is incomplete.
Consider what would happen if a data sector contained 12 * 0x00, 3 * 0xA1, 0xFE, ... then this implementation could mis-sync. On real hardware you'd have to be even more unlucky to have the CRC match -- which also isn't checked in this implementation. Using this as-is on real floppies could result in reading corrupt data. It would be possible to construct a floppy that would read correctly on real hardware and sometimes mis-read data with the current SW implementation.
The problem is that the 0xA1 bytes on the disk are special. The 0xA1 bytes are MFM encoded with a missing clock pulse -- making them "0xA1 syncs" that don't match an 0xA1 data byte. Proper clock recovery is necessary in order to detect the missing clock pulses for correct sync detection.
Based on my understanding, how the writes are done isn't quite how real hardware does it -- real hardware reads the sector header, waits for a "header gap" which, is described as where the 22 * 0x4E bytes are (these byes can get partially overwritten) and then rewrites the whole data header and data portion. Depending on the precise timing there can be trash bytes in the sector gap. I am not sure all floppy drives can switch from reading to writing immediately (page 22 of the pointed to SFB-321B PDF suggests not).
The special sync encoding and this strategy of header, sector is also present for 5.25 and early hard drives using MFM encodings, but with different values, timings and gaps.
I think the software decoding technique used here is incomplete.
Consider what would happen if a data sector contained 12 * 0x00, 3 * 0xA1, 0xFE, ... then this implementation could mis-sync. On real hardware you'd have to be even more unlucky to have the CRC match -- which also isn't checked in this implementation. Using this as-is on real floppies could result in reading corrupt data. It would be possible to construct a floppy that would read correctly on real hardware and sometimes mis-read data with the current SW implementation.
The problem is that the 0xA1 bytes on the disk are special. The 0xA1 bytes are MFM encoded with a missing clock pulse -- making them "0xA1 syncs" that don't match an 0xA1 data byte. Proper clock recovery is necessary in order to detect the missing clock pulses for correct sync detection.
Based on my understanding, how the writes are done isn't quite how real hardware does it -- real hardware reads the sector header, waits for a "header gap" which, is described as where the 22 * 0x4E bytes are (these byes can get partially overwritten) and then rewrites the whole data header and data portion. Depending on the precise timing there can be trash bytes in the sector gap. I am not sure all floppy drives can switch from reading to writing immediately (page 22 of the pointed to SFB-321B PDF suggests not).
The special sync encoding and this strategy of header, sector is also present for 5.25 and early hard drives using MFM encodings, but with different values, timings and gaps.