01-04-2014, 06:12 PM
He already did. If you join the forum on www.atari-forum.com you can see the results. It proves that the SCP hardware is substantially better at imaging disks too. The image quality is much more accurate due to the higher resolution and not having the read data rounded and shifted signal edges that the Kryoflux board has.
Yes, you have the right idea. The bands are well defined, even when bits have shifted. If you use a window comparator like I use in my flux conversion routines for GCR and MFM, you can make data that is normally unreadable, now readable. My comparator window is set to +/-15% of the band. That is pretty narrow still, so I could go wider and that is one of the things I plan on implementing in the data recovery function. The disk controllers typically have a <10% comparator window. You don't need to do the PLL simulation because you have the raw flux data available to you and we don't care about clock and data bits, we simply rotate as necessary to syncronize the data when write splices occur. Unlike the Amiga where full tracks are written, the ST (just like the C64 and 1581) looks for the sector header and writes the sector data, so it generates a write splice. The WD1772 used in the ST parses the flux data as it comes in looking for the sync words to appear (448944894489, decoded as A1/A1/A1) and syncs the data to that, which fixes the issue with all of the write splices.
Here is a link to the comparison of SCP vs. KF.
http://www.atari-forum.com/viewtopic.php...25#p243037
Yes, you have the right idea. The bands are well defined, even when bits have shifted. If you use a window comparator like I use in my flux conversion routines for GCR and MFM, you can make data that is normally unreadable, now readable. My comparator window is set to +/-15% of the band. That is pretty narrow still, so I could go wider and that is one of the things I plan on implementing in the data recovery function. The disk controllers typically have a <10% comparator window. You don't need to do the PLL simulation because you have the raw flux data available to you and we don't care about clock and data bits, we simply rotate as necessary to syncronize the data when write splices occur. Unlike the Amiga where full tracks are written, the ST (just like the C64 and 1581) looks for the sector header and writes the sector data, so it generates a write splice. The WD1772 used in the ST parses the flux data as it comes in looking for the sync words to appear (448944894489, decoded as A1/A1/A1) and syncs the data to that, which fixes the issue with all of the write splices.
Here is a link to the comparison of SCP vs. KF.
http://www.atari-forum.com/viewtopic.php...25#p243037