5.25 drive with sector output
cclist at sydex.com
Sat Dec 22 15:12:37 CST 2007
> From: dwight elvey <dkelvey at hotmail.com>
> Were there any 5.25 drive made with sector pulse output?
> I'm working on a controller for my Polymorphic. I have not
> software to run the board so I'm decoding the Z80 code
> that runs in its firmware.
I can ever recall having seen one, although that's not saying that
there never have been any.
It would be easy enough to make a "index/sector" detector by using a
one-shot whose period is set to more than half, but less than the
time between sectors. Since the index is placed about midway between
two sector pulses, you'd generate an INDEX if you received a pulse
and the one-shot hadn't yet reset. Sector outputs would simply be
the output of the one-shot, perhaps run though another one-shot or
ANDed with the original to provide a pulse of determinsitic length.
Which brings me to a related topic that might interest some...
I'm now beta-testing my "hard-sector synthesizer". It's all coded
into a 8-pin PIC 12F629. It operates as follows:
1) For those not necessarily caring about hard sector diskettes, it
can function as a READY/ generator--after 3 successive index pulses,
the PIC generates a DRIVE READY/. Missing a pulse after that within
a 262msec window causes READY/ to be deasserted and the cycle to
repeat. Works for both 300 and 360 RPM drives.
2) For those interested in hard-sector generation, the PIC will
synthesize index signals for 300 RPM 10 and 16 sector diskettes
(selectable by grounding a pin on the PIC) and 32 sector 360 RPM
diskettes. The choice between 300 and 360 RPM is made automatically
by the PIC based on the drive spindle speed.
3) If a hard-sectored diskette is inserted in the drive, the PIC
simply passes the index pulses along.
3) Index pulses are normalized to 1 msec width. Many 3.5" drives and
several later 5.25" drives output very long index pulses that need to
be pruned back.
4) Calculation of the position of sector pulses is based on the time
of the previous disk revolution to about 0.15 percent (I can improve
on that if needed). Since the computation is performed for every
disk revolution, drift should not be a significant problem.
The whole thing is self-contained; no external crystals, buffers,
etc. are required; only a +5 supply and a pullup (470-2.2K would
probably be fine) on the INDEX/ line coming from the drive. You
could probably stick the PIC in an 8-pin socket and "dead bug" it
into your system if you wanted to be crude. The PIC can sink 25ma
Here's the catch: I'll send out object (and source, if requested),
but I'm not going to send out PICs or program them for requestors. I
expect that there will be a couple of software updates and I don't
want to deal with the hassle of updating everyone's PIC. PIC
programmers can be constructed or purchased very inexpensively and
there are several free programmer packages out there. PICs themselves
I'm not going to post the code to a web site until I'm happy with it--
otherwise, I fear that intermediate versions (i.e. buggy) will start
ciculating and I'll never hear the end of things.
Drop me a private email if you're interested.
More information about the cctech