Second,
I've noticed that the drive seems to mis-seek on occasion.
[...]
I assume you are aware of that any software driver for the RL drives
needs to read the headers to verify that they are on the right track,
after doing a head select (or rather a change in which head you have
selected), and do a new seek if on the wrong track. Repeat until on the
right track.
Essentially, seeks on the RL drives are not reliable, and you must
always first check that you are on the right track before doing anything
else.
I would almost suspect your controller is just fine in this aspect.
(This is documented in manuals, if you read enough.)
Johnny
oops... That makes me feel a lot better. I did design my controller to take the
difference of the commanded track vs the observed track and send it to the drive, but I
didn't know it was somewhat unreliable as to which track you will land on. That's
consistent with most of the data "corruption" I've seen. Random tracks have
duplicate data in them, but it's miraculously solved when the next track is addressed
or when I move off of and return to that track. That's because my FPGA always uses
the last observed header to do its track difference calculation, but it doesn't check
that the resulting seek is executed by the drive correctly. The micro controller serving
as the USB interface assumes that it will be returned data from the track it requested,
which has proven to be false.
Those references to square root generators and kick pulses in the RL02 design documents
scared me a little and should have clued me in that this isn't 100% deterministic. Oh
well.
Regardless, thanks for the info!
Christopher