Using a 3.5" 720k disk...
chrise at pobox.com
Mon Apr 20 12:26:13 CDT 2009
I made no attempt to solve this problem for 5.25" media. I went straight
to the 3.5" domain simply because the drives are still readily available
and I have a large stock of the media.
I have tested my solution only with the Heath H-88-1/H-17 hard sector
controller too... so it's possible that that controller is less sensitive
to any speed variation the drive may be introducing. Soon, I'll be
trying a 16-hole variation with a very old Micropolis controller (for
the 1015-II drives) and we'll see if the reliability is repeatable.
I did consider leaving the drive selected all the time, with the motor
running and then continuously watching the speed and using the previous
rev to time the next... but in the end, it seemed I didn't need that
complexity and I am able to let the drive spin down when MOTOR ON goes
false and it still seems to work.
In any case, I make no claim of a universal solution here... just
something that works for the H89 and eliminates a dependancy on the
10-hole 5.25" media. I've got two 3.5" drives in half-height 5.25"
adapters sitting in the same opening as the one full-height 5.25" drive
used to occupy and it looks and works pretty good.
On Sunday (04/19/2009 at 03:17PM -0700), Chuck Guzis wrote:
> On 19 Apr 2009 at 20:13, Philip Pemberton wrote:
> > - If you add something to sync to the index marks and generate a
> > hard-sector "emulation" index pattern from that, you can't put a HS
> > disc in that drive
> Not so--it'd work the same way my PIC solution does--while it's
> sampling the drive speed (and not passing index pulses) it's looking
> for sector holes. If it finds them, it hangs back and allows index
> pulses to flow through. If it sees an index pulse every 166/200 msec
> or so, it knows to start generating sector pulses on the next rev.
> > What about just detecting the speed of the input index pulse? If
> > they're turning up faster than, say, once every quarter-second, then
> > bypass the index-pulse multiplier. Basically have a multiplexer that
> > allows the output to be sourced from /Index_In, or /Index_Generated.
> Exactly what my PIC code does. But the base issue is really the ISV
> characteristics of the drive's speed control. Direct-drive 3.5"
> drives are probably much better than old 5.25" belt-drive drives. I
> suspect that consistent speed control issues may have originally
> been the reason for NEC specifying 8x512 format for a "360K"
More information about the cctalk