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