Quote:
Originally Posted by JimDrew
If you have read the patent then you should have noticed how the data separator works, and that it is setup to handle flux data and that's it. You send/receive pulses, and those are converted directly into either a MFM or GCR data, depending on how you have Paula setup. If you know anything about MFM you would know that there only certain combinations of bytes that are valid, and all other combinations are not decoded or encoded correctly from a series of pulses. It doesn't matter what provides the pulses (magnetic media or a clocked line from a microcontroller), the end result is the same.
The HRM does not go into the internal workings of the disk controller, but instead discusses the MFM/GCR modes, 2us/4us modes, etc.
You can believe what you like. I created more than 60 commercial disk copying related products for the C64 and Amiga, so knowing the exact functionality of the disk controller hardware was my daily job.  |
But there are 2 things - one i clock acquisition and second is data decoding.
Data decoding is performed by software where clock acquisition can be less strict if first, all things will be made in synchronous way (so or interface provide clock in similar way as Sybil or it will synchronize to clock - 28.xxxMHz/4 available on for example video port).
And my point was that FDD coding can be used at boot time where you have no driver loaded and later card adapter can switch to parallel I/O available at FDD port. So only boot part is slow and require FDD like emulation.
And finally - i believe You Jim, my point was that sometimes if we know lot of details then we can ignore/miss non standard solution.
Clock acquisition will work anyway (state machine with limited amount of cycles/states) - keeping short data blocks with pre-header to sync clock should be possible loop will be out of sync.