5.25 drive with sector output

[Chuck Guzis]

> 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 
per output.

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 
are dirt-cheap.

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.

Best regards,
Chuck