Thread by @drtune

Anecdote: For 15 years floppy disk copy protection was fun cat+mouse hackery (Apple2, C64, Amiga; I was friends with the XCopy guys+I did 'Cyclone' hw copier) with lots of clever/complex tricks (sector sync, errors, long tracks, fat tracks, short tracks, 'weak bits' etc etc)...

and there were all these nuances to how you'd try to detect and copy them if you were a pirate, or how to prevent copying (and yet still be able to commercially duplicate disks), and I dabbled on both sides for fun and profit..

but interestingly the techniques were almost all about leveraging limitations in the disk controllers of the computers attached, not in floppies themselves; a floppy drive is standardized, a lot like a tape recorder plus a 'cleaning up' stage so it outputs 1/0 not audio...

..which go to/from the floppy controller (FDC); (Amiga, C64 and Apple had custom FDCs, almost everyone else used off standard off-the-shelf controller e.g. WD1772 chip..) and these chips all make assumptions, in their design, about how data is recorded on the disk..

and generally what you'd do with a copy protection scheme is invent some modification to the standard disk recording technique (e.g. a deliberate defect in the data in a known position on the disk) that could be detected reliably but was hard for pirates to copy w/a home computer

so early protection schemes (e.g. deliberate errors) could often be circumvented with a clever copying program that knew the right software tricks to generate the same watermark on a pirated copy, so there was arms race of exotically named pirating tools...

"Super Nibbler", "Fast Hack'em", "Maverick V5", "Renegade", "White Lightning", "RattleCopy", and many, many more; some of them even worked sometimes! - many hours were devoted to studying the dark alchemy of floppy disk piracy..

later in the day, the Amiga came out and had a very flexible disk controller - it made few assumptions about what was on a disk & did most processing in software - and rendered a lot of anti-piracy techniques obsolete; protected disks for other systems could be trivially copied

..so in the Amiga era, the arms race moved to writing disk tracks with tiny shifts in the exact timing of the bits written to disk as it span; it was possible to write disk data slightly more (or less) densely than a regular consumer computer+floppy drive would..

so the 'long track' was invented, where the disk duplicating machines (which had a special disk controller) would write the bits slightly closer together than usual on the disk; they would still read back ok, because there is some tolerance, but a pirate could not recreate this..

..the reason being that the Amiga, flexible as it was, could did not provide fine-grained control over how far apart bits were written on the disk; it could only use the standard timing (= position, when writing on a constantly rotating surface)

so long track protection became the defacto standard in the late 80s because it was simply not possible to copy such a disk with any clever software tricks.. until.. one day someone had a dumb yet brilliant idea...

which was "instead of trying to read a protected disk in the computer and then write out a copy, how about we do like tape-to-tape copying, and just connect two disk drives together, back to back?"

this is a really dumb idea and obviously won't work for a number of reasons, except that it once you overcome the basic issues, it - kinda - actually _does_ work. You can wire the output of one to the input of the other, and tell one to read and the other to record, and..

it works! And, it turns out there's an easy way to do it, which is using a simple crossover wiring dongle plugged into the second disk drive; just swaps a couple of wires, and now the second drive records what the first one reads, bypassing the computer disk controller completely

The only real trick involved is "pressing record" at exactly the right moments; because the disk tracks are circular, if you leave the record on for too long, you start overwriting your own data (or too short and you don't copy enough data).. so this fancy looking software...

..is pretty much a glorified tape operator doing overdubs; it looks at the data coming off the source disk and tries to figure out when the exact moment to start and stop recording on the copy... its job is to figure out where the gaps are between the data..

I remember when I heard of this; a friend told me he'd heard about a thing for the Atari ST where you cross-wired the disk drives; it sounded so laughable.. after I stopped laughing I tried doing the same thing on my Amiga, & got it to not only work, but copy long tracks..

this was huge deal; I turned up at a 'demo party' (ok, mostly piracy+drinking) and people went _nuts_ about it; had to get a taxi to local electronics store to buy parts to make more dongles, was sitting in party soldering them up nonstop, later the X-Copy folks sold it for me..

was interesting example of a transformative idea that sounded totally ludicrous at first; "There's no waaay... Surely it won't work, or if it does someone would have done it already... ok ok let me try this.."

.. so the 'disk to disk copier' was not without flaws; one of which was that, like noise on analog tapes, each generation of copy got slightly degraded; the timing of each bit shifts a little each time it's read and written, so a 3rd/4th generation copy may not work...

..plus, because you have no control over the relative speeds that the source and destination disks are spinning (nominally 300rpm, but slight variations between disk drives) made the software timing harder to get right, some pairings of drives worked better than others...

..so this hack, great fun as it was, was not quite the holy grail of piracy because it's _still_ possible to make an uncopy-able track, by exploiting a weakness in our disk-to-disk copying device...

..which - although I never saw it implemented - is this; disks have an index hole punched in them which is read by an optical sensor, outputting one pulse per spin of the disk at a specific place. This pulse is read by the disk controller..

and _may_ be used by the disk controller - it's bonus information. You can use it to tell how fast the disk is spinning (timing it), or you can use it as a marker to tell you when to start and stop writing data to the disk (the original intent), however it fell into disuse..

because disks rapidly transitioned to 'soft sectoring' where the start and stop points of data on the disk is signalled by special sync patterns in the data, not by a physical hole in the disk: better solution in several ways; the rotational position of the data is arbitrary e.g.

so.. on the Amiga and ST it's perfectly _possible_ to write your data with a fixed alignment to the index hole and it might look like this (images from tinyurl.com/y3gpwlnw btw) .. but not required, and the disk duplicators didn't like it, b/c each disk takes longer to write..

..perhaps surprisingly, software on disks was duplicated by just having long rows of these machines; typically they span the disk at 2x normal speed, because throughput was everything. If you wanted a fancy disk protection, you had to convince your vendor to write custom..

..scripts to configure these machines to write your odd/unusual format; they also had to be able to read the data back to verify it. This was a PITA and you generally got told to "get stuffed" by grouchy factory guy..

..if you configure these machines to write each track's data aligned to the index hole on the disk, the machine runs slower because it has to wait for the disk to rotate each time..

so anyway the secret to a properly uncopyable track (in that era) was to make it both a long track (cannot be written by regular software, have to use the drive-to-drive dongle) and _also_ aligned with the index hole... The protected software would verify both attributes were ok

..and this was very hard to copy with the dongle, simple because when drive-to-drive copying a track, you have no control over the relative rotational positions of the source and destination disk - they're spinning independently, at slightly different speeds, so they drift..

so even though the source track might have started at the index mark, the realtime copy you're making will just have to start wherever the destination disk is. It's frustrating for the copying program, because it can _see_ the index markers from both disks and it knows they're..

not aligned with each other, but there's not a lot it can do about it... except (a) leave the disks spinning, measure their relative positions and _wait for them to drift into sync_ before copying the track.. or (b) try to bump them into alignment by pulsing the spindle motor..

i.e. you can try momentarily turning off-and-on-again one of the the disk drive motors, and it should slightly slow down, causing that disk to slip a little relative to the other one...

..so this was fun times, writing code that attempted to juggle two spinning disks ('like spinning plates') trying to nudge them into sync (and predict when it will happen) so you can carpe diem and copy the track with the right alignment.. This could take.. a while to happen..

...so that was about the end of the floppy disk arms race that I witnessed; the world moved away from floppies, .. but then in 2008 - long after obsolescence - it occurred to me that it was now possible to make the holy grail of disk copiers, with a $5 microcontroller..

..the perfect floppy disk copier wouldn't have any of the specific weaknesses that were previously exploitable; you make something that can precisely read the position of each bit on the disk, and then write it back with precisely controllable timing...

this being a floppy disk drive, 'precisely' isn't all _that_ precise in modern terms, on a spinning Amiga disk the data bits are nominally 2 microseconds apart, so something with a timing resolution about 50x that is appropriate to see/recreate the nuances of disk protections...

..so you want some sort of data recording/replay system that can resolve timing to about 40ns (25Mhz) which is easy on a modern microcontroller using hardware timers. You end up with a USB peripheral which can read and write any floppy disk format or protection whatsoever...

/end. Hope that was interesting to some. Stay safe!

Bonus: if you plot inter-bit timing of any normal MFM disk bits, you get 3 distinct 2us-spaced stripes(1st image); if you zoom in on the protection track of "Dungeon Master" for AtariST, there is something unique+crazy (2nd), ..zoomed in (3rd). Credit: tinyurl.com/y45ltrmc

Bonus #2: The Amiga was approximately the RTL-SDR of its day, in terms of floppy disks - within some constraints it gave you near-raw access to the underlying medium.

The 'three stripes' image is what you see for _any_ standard disk data, no matter what the data is; the stripes correspond to MFM bits "11" (bottom) "101" and "1001", with a standard 2us clock. Those are the only valid timings for any possible data.. unless you're Dungeon Master

We talk about bits on the disk, they're actually changes in the magnetic polarity (a change is a '1' bit). This is the analog signal from the drive read head (just a coil). It gets amplified and shaped into digital pulses by the floppy drive.