[sebhc] Floppies, archives, and ROMs

Dave Dunfield dave04a at dunfield.com
Wed Feb 2 12:23:40 CST 2005


>I wouldn't recommend remembering timing rates. The controller's timing
>should be dynamic and generate each set of holes based on the dt between the
>previous index holes (after the +/-15% test is satisfied). If the next set
>are a bit different the controller generates a slightly different timing for
>them. This is obviously not the best situation. It would be better if we
>could get the real time rotational speed of the spindle, but that isn't
>available. We might be able to derrive it from the raw data coming off of
>the heads, but that would involve more drastic modifications to the drive in
>question. What we are talking about here could be in-line on the back of the
>drive, placed on the controller card, or even on the drive electronics.
>...lots of flexibility.

If you read my original posting - I proposed doing exactly that, adapting
the time based on the measured time of each rotation.

Basically, once the motor is turned on, watch for the index pulse, if
it happens within x ms (x to be determined), assume that the motors are
not up to speed yet and wait for the next one. Then, time one full
revolution, and divide by 10 to get the offset between each sector
pulse - being "faking" these pulses at offset/2 from the next index hole.
With each revolution, remeasure and adjust the time accordingly - this
insures that the device will track the drive and always present a
reasonably accurate sector hole timeing.

The problem with this approach is that it takes at least one, and up
to two revolutions before the controller begins to see index pulses.

What I proposed, is that once the device has calibrated, as long as it is
not powered down, you could "remember" the timeing of the previous access,
and apply it after the first index pulse - it would still dynamically
adjust to the drive from there on, and it would also be subject to the
guard time to insure the motor is up to speed - this reduces the latency
on subsequent accesses to a maximum of only one (and a bit for the guard
time) revolution.

Dave
-- 
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Collector of vintage computing equipment:
                http://www.parse.com/~ddunfield/museum/index.html


--
Delivered by the SEBHC Mailing List



More information about the Sebhc mailing list