Chuck Guzis wrote:
On 8 Dec 2009 at 18:13, Eric Smith wrote:
The data separator has to deal with a lot more
than just the variation
in drive speed. That variation has long-term and short-term
components, and it also has to deal with the bit shifting that isn't
completely avoided by write precompensation.
Indeed, as I pointed out ISV can be much worse than CSV.
ISV = Instantaneous speed variation. I've read the primarily cause of it
is jacket friction. Any other causes you know of?
CSV = What's this one? Is it CONSTANT speed variation? Comma separated
values keep ruining my google searches (Yes, I've tried -delimited in
the search.) Is this the same as MSV, motor speed variation?
I've seen ISV and MSV all over the place, but I don't think I've seen
CSV....
I would expect that one could do considerably
better, particularly when it comes to error recovery. For example, a
traditional data separator, when it hits a "glitch" in the middle of
data is more likely than not to interchange clock and data in the
stream. A software algorithm can work through the "glitch" and
reduce data loss to a much lower level. Similarly, corrupted IDAMs
usually result in a "Sector not found" type of error on traditional
gear, where the placement of the IDAM and its data might be inferred
using a clever software algorithm.
I've spent quite some time coming up with some neat ideas regarding
exactly this type of stuff. I have some stuff implemented, but others
are just ideas swirling inside my head.
In other words, instead of being "as good
as" a regular floppy
controller, one could be considerably better.
Exactly! And this has been my goal from the beginning.
Given that the goal of a floppy reader is recovery of
recorded
information, what is an adequate sampling rate? My own guess is that
after real-world factors have been taken into account, that 8x is
probably more than safe. But I would be interested in hearing
arguments to the contrary.
Let me play devil's advocate. 8x500kbps would be 4mhz. Which means
that your samples are every 250ns. But the pulses come from the drive
are usually 250-300ns wide. _You could potentially miss one._ Now the
pulse WIDTH is fixed and doesn't matter, so it's not like you need
multiple samples per pulse, but I would just have to wonder about pulse
placement accuracy. (ie when did that pulse really occur, did it happen
at t=500ns, or t=750ns) Seems like a huge difference to me.
The resolution of my timer is 40ns and I've had a fair bit of success
with my reader. I'm not trying to imply my 40ns is the gold standard or
anything, just pointing out that 40ns samples seem fine.
--Chuck
Thanks
Keith