Disc reader project -- quick status update

On 7 Dec 2009 at 6:51, Philip Pemberton wrote: It works--the read track waits for the index mark and then begins transferring at the first DAM. If you tell the FDC that the track consists of one 8192 or 16384 byte sector, the transfer continues until that many bytes have been transfered, regardless of any subsequent index or address marks. It's worked that way since the original 8272/765-based PC controller went into a 5150. Fred probably knows where this was first exploited in a commercial product. The early versions of Harvard Presentation Graphics used a copy-protection scheme that embedded the letters "HGC" between two sectors on a 360K floppy track (as part of the inter-sector gap). Where the copy protection really kicks in is that the "Read Track" command doesn't re-sync the VCO on address marks, so write splices mess up the returned data. (FWIW, the WD17xx *does* resync on AMs when a track read is performed, as well as allow you to write a complete track (although some hex values are reserved) during a format operation. So you could conceivably rig up a Sanyo MBC-550 PC to dupe these. Or just get a CopyIIPC option board.) On a diskette produced on a write-the-entire-track formatter, such as a Formaster duplicator, everything returned by a Read Track looks great, as there are no write splices. However, a floppy produced with a disk copy program, each sector is written individually, with accompanying write splices, so even if you manage to create a format with HGC in the right place (hint: format 128-byte sectors with different length codes in their headers), it stands a good chance of not working. Depends on the modern PC. Some modern PCs do better than vintage ones. The 5150 disk controller, for example, couldn't do it, but I've got a P2 and P3 systems here that works with FM just fine. Not to mention a raft of various ISA cards--and some external adapters, such as a Microsolutions Backpack drive, or the Rancho parallel-to- floppy adapter. --Chuck