The Apple II's disk controller could easily write "flaky bits" in software. By telling the controller to write three or more consecutive zero bits, you'd produce a sector that read back unpredictably. So your copy protection scheme would be to turn off sector checksums and then read your test sector a few times in a row. If the sector came back identical each time, then you were likely a copy rather than an original.

After reverse-engineering the verification code in a few different games, I wondered how the publishers produced those weird sectors. I called them "weak bits," coincidentally, because my theory at the time was that they modded the disk head to write the bit weakly so that it couldn't distinguish a one from a zero during readback. A friend at school had a copy of Don Worth's Beneath Apple DOS, which absolutely blew my teenage mind. Until reading that book, I didn't think that any single human could understand and clearly explain a complex system so thoroughly.

Interesting, I didn't know the Apple II's controller could write the combined data and clock bits. That's unfair :) I was also pointed to this Twitter thread where it is explained that they wrote Mr. Do weak bits with a hacked up Commodore 64 drive controlled by an Apple II!

https://twitter.com/JBrooksBSI/status/936476972611334147

I've also been referred to this which definitely belongs here. It's a write up of fairly advanced weak bits usage on the 1984 Apple II educational title "Kingdom of Facts".

https://ia800600.us.archive.org/2/items/TheKingdomOfFacts4am...

It's much simpler than weak bits, but I remember one of the Ultima games for DOS had a track with a small sector embedded in the middle of a long sector. So from the point of view of the controller after decoding, there were more sectors than could be written onto a track.

All the copy protection did was decrypt itself, read the starting address of the executable from a sector on that track, and jump to it. My fix was to just stuff that address back into the executable header. (I had actually purchased the game, I was just tired of having to insert the floppy every time I ran it off of the hard drive.)

This reminds me of "weak sectors" as used in the infamous SafeDisc and related CD protections, which exploit a digital aspect of the media (EFM encoding) to create an optical equivalent of a https://en.wikipedia.org/wiki/Lace_card :

https://web.archive.org/web/20090603002402/http://sirdavidgu...

I remember Dungeon Master on the Atari ST having fuzzy bits. There was also another game, I can't remember which that instead of locking up or not loading on detecting that the fuzzy bits were not fuzzy (and hence it was a copy) changed the gameplay so that the end boss was unbeatable.

The Atari had a lot of copy protection approaches[1]. No wonder, with the floppy controller being so flexible.

[1] http://dmweb.free.fr/files/Atari-Copy-Protection-V1.4.pdf

Doesn't Dungeon Master put you in a room without exits if you use a copy? I think it did this one level in or something like that?

Fabulous explanation of how they did copy protection in the old days. I remember the 8271 well. I'm not sure why they used such an old chip with the BBC B, as it was quite expensive. The WD1770 was better and cheaper.

1770 upgrades were extremely common for the BBC Micro. (They are, astonishingly, still made.) The B+ and the BBC Master came with a 1770 by default.

I preferred the NEC µPD765 though. Higher density.