Hard-sector discs -- how many sectors?

Tony Duell wrote: It should work with anything that has a 34-pin Shugart interface. It supports the pseudo-Shugart interface PCs use (including the twisted wire), too. The current "Must Have" format support list is: - 8-inch: hard and soft-sector (untested, I don't have a drive or discs) - 5.25-inch: hard and soft-sector (I have a 96tpi double-sided drive and soft-sector discs, but no hard-sector ones; a 48tpi double-sided drive might also be worth testing) - 3.5-inch: soft-sector. Do hard-sector 3.5" discs even exist? Most of the drives I've looked at use the position of the spindle motor to derive the index signal, so I'm guessing "no". Theoretically the following should also work: - Amstrad 3-inch. Don't have one of these, don't feel like gutting a CPC/PCW/ to get one. I seem to recall the drives are 80 track and Shugart interfaced, though. - Zenith Minisport 2-inch. Assumption: the drive uses a Shugart interface, and you have a junked MiniSport to "liberate" the drive from. Disc formats ============ As far as disc formats go.... pick one. Any FM or MFM based format should be readable (and probably writeable too) with the standard hardware, microcode and firmware. If you want to add support for another format, you basically just have to change the microcode (which is loaded into the FPGA every time the hardware is cold-booted). MFM hard drives should also be fine, but a buffer/converter board will be necessary (to convert from differential to single-ended signalling). RLL should also work if you've got software to decode the contents of the drive. Software ======== Open-sourced, multiplatform. Should work on any platform with a libusb port -- that's Linux (kernel 2.2+), Darwin (Mac OS X), the various BSDs, and Windows 2000 thru Vista (32 and 64 bit). That's what, 95% of the current OS market? My discussions with the Software Preservation Society have turned sour, so it's not likely you'll be able to read a disc and produce a .IPF (or the precursor format, whose extension I can't remember right now) from it. I'm not even keen on adding an "IPF writer" extension given that the libcapsimage library is a binary blob. I might look into an extension to the ImageDisk format to store raw track data, but storing the relevant metadata (sample rate, acquisition settings...) might be tricky. Either way, the output formats are going to be open and documented, in the same way as the .IMD format. I think that answers just about all the questions... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/