[sebhc] Floppies, archives, and ROMs

[West, Ronald S.]

Can't the problem of detecting a new disk be solved by limiting the range of
the uController generating the "holes?" If the index holes get more than
+/-10 to 15% away from the 300RPM spec then the controller quits generating
holes. 

This way if the operator removes a disk (however rude or not) then the
system will start generating holes when the new disk gets close to 300RPM. I
also thought about doing this but never had the time. Have been working on
an IDE board for about a year now too but work, home & college classes have
kept me from continuing. I guess its the same for everyone. Fun stuff
allways seems to come last.

Ron


> -----Original Message-----
> From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of 
> Dave Dunfield
> Sent: Tuesday, February 01, 2005 1:34 PM
> To: sebhc at sebhc.org
> Subject: Re: [sebhc] Floppies, archives, and ROMs
> 
> 
> 
> >Dave wrote (regarding simulating hard-sector pulses with soft-sector
> >diskettes):
> >>  - "Remember" the timing for up to four drives, so that 
> after the first
> >>    calibration (power on), you can begin inserting 
> hard-sector pulses 
> >>as
> >>soon
> >>    as you see the index pulse (subject to above guard time 
> of course).
> >
> >The internal drag of a particular floppy might alter the speed 
> >slightly, so
> >it might be better to compute the timing from scratch after 
> any insertion.  
> >Also remember that insertions can occur while the motor is 
> engaged (even if 
> >rude!).  :-)
> 
> Unfortunately you can't reliably detect insertions without 
> modifying the drive (if you are willing to add a lead to 
> *always* watch the write product signal of all drives, then 
> you could detect when a diskette has been inserted).
> 
> As to drag slowing the disk down ... I avoid using disks 
> which have a high drag, and have not seen much effect with 
> "normal" disks - Unless you modify the drive to perform 
> insertion detection as noted above, you would have to always 
> waste the extra revolution every time the drive motors are 
> turned on (note, you are already wasting up to one revolution 
> while waiting for the index pulse). I have no idea if the 
> software will tolerate this long a time before index pulses 
> appear or not.
> 
> Also, since I would update the timing on every detection of 
> the index hole, this would only be a concern if:
>   - A disk has just been inserted (no previous accesses)
>   - A write is occuring on the first access (read error would 
> just retry)
>   - The disk has enough drag to noticably slow the drive motor.
> 
> I think that once you have "calibrated", it would be safe to 
> begin sending the fake index pulses once you have determined 
> that the drive is up to speed and have seen one index hole - 
> but another big benefit of a microcontroller based 
> implementation is that you could easily make waiting for two 
> index pulses an option.
> 
> Regards,
> 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