[sebhc] Floppies, archives, and ROMs

[West, Ronald S.]

Sounds good to me. Would be interested in hearing results of any
experimentation in this area. If time permits I will try looking into this
also.

Ron


> -----Original Message-----
> From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of 
> Dave Dunfield
> Sent: Wednesday, February 02, 2005 1:24 PM
> To: sebhc at sebhc.org
> Subject: RE: [sebhc] Floppies, archives, and ROMs
> 
> 
> 
> >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
--
Delivered by the SEBHC Mailing List