01-05-2014, 01:39 AM
Personally I prefer the DPLL approach to read flux transitions.
This is what is actually used in the WD1772 and I am trying to have a behavior as close as possible to the WD1772 in my program. But in fact this is not really directly connected to the WD1772 as a PLL is always used as input to any FDC (whether integrated or external to FDC). There are numerous application notes on how to process input data from floppy drive with analog and digital PLL and long time ago I used to know well this subject when providing customer’s support for the Intel 8272 FDC!
I have modestly contributed to the debug of the VHDL model of the WD1772 created by Wolfgang Förster (http://www.experiment-s.de/en/boards/suska-iii-c/) and my code implement the same DPLL described in patent 4,780,844 http://info-coach.fr/atari/documents/gen...780844.pdf. The code was not very difficult to write but it was tricky to set the different parameters to get the good behavior. My code can handle flux for double density and high density but not for single density (this is independent of FM / MFM) but it can be adapted. In a near future I intend to release the source of the tool I am currently writing and as Jim mentioned yes the prototype already works with scp files. It provides nice graphical outputs of the input flux but the code only works for DD MFM floppy disks as used on Atari platform. According to Jim it seems you can do without a DPLL to shift bits in but I am still not fully convinced that you get the exact same result as when using a DPLL. Floppy drives / disk suffer from two types of “flux speed” variations fast and slow (simplified) that must be compensated by different mechanisms. The slow variation (usually due to motor irregularities) are compensated by adapting the clock of the DPLL and the fast variation are used to adjust what is called the inspection window. This is critical in cases of what I call border bits (bit that can be interpreted as 0 or 1) in the range close to 5µs to get accurate results. However this may be “academic concerns” because in most cases it is not so important if one bit gets detected incorrectly because by definition fuzzy bits are fuzzy!
Currently my software allow 9% variation on the input frequency as it seems to be the behavior of the WD1772 for DD/MFM but this can be changed easily for example to read damaged FD. Note that on “good FD” 9% is more than enough as the protections used on Atari only vary the clock by 5%.
Concerning the flux range one quick note: Looking at DD floppies I have never noticed any transitions below 2µs and (apart from No Flux Area where you get artificially several ms) the range can go up to few hundreds microseconds on unformatted diskettes. The histogram of fluxes reparation on unformatted diskettes seems to be influenced by the type of media used (for example DD floppy disks versus HD) …
For information the prototype of my program progress at reasonable speed currently it take either SCP or KF raw flux as input and displays all sort of nice representation of the data for example look at http://www.atari-forum.com/viewtopic.php?f=102&t=25854
Very bad input partially recovered
Speedlock protection +5% -5% variation on first sect
Disk with No flux area (in yellow close to the index)
This is what is actually used in the WD1772 and I am trying to have a behavior as close as possible to the WD1772 in my program. But in fact this is not really directly connected to the WD1772 as a PLL is always used as input to any FDC (whether integrated or external to FDC). There are numerous application notes on how to process input data from floppy drive with analog and digital PLL and long time ago I used to know well this subject when providing customer’s support for the Intel 8272 FDC!
I have modestly contributed to the debug of the VHDL model of the WD1772 created by Wolfgang Förster (http://www.experiment-s.de/en/boards/suska-iii-c/) and my code implement the same DPLL described in patent 4,780,844 http://info-coach.fr/atari/documents/gen...780844.pdf. The code was not very difficult to write but it was tricky to set the different parameters to get the good behavior. My code can handle flux for double density and high density but not for single density (this is independent of FM / MFM) but it can be adapted. In a near future I intend to release the source of the tool I am currently writing and as Jim mentioned yes the prototype already works with scp files. It provides nice graphical outputs of the input flux but the code only works for DD MFM floppy disks as used on Atari platform. According to Jim it seems you can do without a DPLL to shift bits in but I am still not fully convinced that you get the exact same result as when using a DPLL. Floppy drives / disk suffer from two types of “flux speed” variations fast and slow (simplified) that must be compensated by different mechanisms. The slow variation (usually due to motor irregularities) are compensated by adapting the clock of the DPLL and the fast variation are used to adjust what is called the inspection window. This is critical in cases of what I call border bits (bit that can be interpreted as 0 or 1) in the range close to 5µs to get accurate results. However this may be “academic concerns” because in most cases it is not so important if one bit gets detected incorrectly because by definition fuzzy bits are fuzzy!
Currently my software allow 9% variation on the input frequency as it seems to be the behavior of the WD1772 for DD/MFM but this can be changed easily for example to read damaged FD. Note that on “good FD” 9% is more than enough as the protections used on Atari only vary the clock by 5%.
Concerning the flux range one quick note: Looking at DD floppies I have never noticed any transitions below 2µs and (apart from No Flux Area where you get artificially several ms) the range can go up to few hundreds microseconds on unformatted diskettes. The histogram of fluxes reparation on unformatted diskettes seems to be influenced by the type of media used (for example DD floppy disks versus HD) …
For information the prototype of my program progress at reasonable speed currently it take either SCP or KF raw flux as input and displays all sort of nice representation of the data for example look at http://www.atari-forum.com/viewtopic.php?f=102&t=25854
Very bad input partially recovered
Speedlock protection +5% -5% variation on first sect
Disk with No flux area (in yellow close to the index)