Background
The Commodore 1541 disk drive is a stand-alone computer that talks to the C64 through a somewhat slow serial port. It is based on similar technology to the C64 itself, employing a 6502 CPU, two 6522 VIA I/O chips, and only 2k of memory (the limitation of which will be discussed later). It came with either an Alps or a Newtronics 5.25" double-density floppy mechanism, both of which are functionally equivalent. This mechanism requires double-density 48 track-per-inch 5.25" magnetically-coated Mylar disks.

Tracks
Tracks on the disk are organized as concentric circles, and the drive's stepper motor can stop at 84 different locations (tracks) on a disk. However, the read/write head on the drive is too wide to use each one separately, so every other track is skipped for a total of 42 theoretical tracks. The common terminology for the step in between each track is a "half-track" and a specific track would be referred to as (for example) "35.5" instead of the actual track (which would be 71). Commodore limited use to only the first 35 tracks in their standard DOS, but commercial software isn't limited by this. Most floppy media is rated to use 40 tracks, and the drives usually have no trouble reading out to track 41, although some will bump and not get past 40. Most software does not use any track past 35 except for copy protection, but alternative DOS systems like Speed-DOS used all 40 tracks in their own DOS implementation.

CBM drives have no way in hardware to detect which track it is on, or where it is on any particular track. The software must handle these functions which leads to many of the more creative styles of copy protection. 5.25" disks contain an "index hole" which is the little hole you see diagonal to the hub ring on your disks. If you spin the disk around in the shell, you'll see that there is a hole in that, too. Other drive manufacturers used an optical sensor to detect when this hole passed by, which would signal the start of a track. Commodore didn't implement this, so we have to use marks that are written to the disk during formatting. Later copy protection implementations took advantage of this because the devices used to master original software are not typically a 1541. They could master the disk using the index hole so it was lined up perfectly. As far as knowing which track we are on, the only way to tell is again in software. Each sector on a track has a header that contains (among other things) the track number. DOS will read this whenever it needs to access a track so it knows how many times to step the motor to get there. The famous "drive-knock" is the software hack that Commodore employed to reset the drive to track 0 when we couldn't find any sectors. In this case, the motor is stepped out as far as it can go until it physically stops (causing the knocking noise) which guarantees the head is on track 0. Unfortunately, this behavior is what is blamed for the terrible drive alignment problems of the early mechanisms.

Sectoring
Tracks are further divided into sectors, which are sections of each track divided by the aforementioned software-generated sync marks. The drive motor spins at 300rpm and can store data at 4 different bit densities (essentially 4 different clock speed rates of the read/write hardware). The different densities are needed because being round and the motor running at a constant speed, the disk surface travels over the head at different speeds depending on whether the drive is accessing the outermost or innermost tracks. Since the surface is moving faster on the outermost tracks, they can store more data, so they use the highest density setting. Consequently, the innermost tracks use the slowest density setting. Because we're recording at a higher density, more sectors are stored on the outer tracks, and fewer on the inner tracks. There is nothing stopping the hardware from reading/writing at the highest density across the entire disk surface, but it isn't generally done due to media reliability, and slight speed differences between drives. The media itself is only rated for a certain bit rate at a certain speed.

Drive Internals
The drive head, at its lowest level, can only detect and create polarity changes in the magnetic flux on the surface of the disk, which is interpreted by the drive as a binary 0 (no change) or a 1 (flux polarity change). Because of the specifics of the hardware used to access this magnetic flux, the bits stored on the disk have a couple of limitations (or "features"). This flux detection circuit feeds dual 4-bit "shifters" which convert the bits (detected from the flux changes) into a whole byte (8 bits), much like a serial port does. If this circuit detects ten '1' bits in a row, it knows that it has read a "sync". This sync is what tells the software that we're about to get a series of bytes representing either a sector header or sector data right after the sync ends. An anomaly of this circuit is that it if it runs across three or more '0' bits in a row, it will clock in an extra '1' bit on each 4-bit shifter that doesn't really exist on the disk. When this happens, the drive can lose framing, meaning the data is bit-shifted after this due to our new phantom bit. It will shift a new phantom '1' into the LSB once in a while (and wrap it around) according to drive speed and other environmental factors until the next real '1' bit is seen. This data is "random" in the sense that the data is never the same twice due to drive speed (and humidity, temperature) fluctuations. A good example is when you try to read a new, unformatted disk. If you try this, you'll get "random" data caused by this anomaly in the drive hardware because there are no flux changes on a blank disk. To the 1541 hardware, this is all '0' bits. Because of this weakness of the hardware, all data is stored on the disk in an encoding system called "GCR". This encoding rules ensure that there should never be more than two '0' or more than nine '1' bits in a row in the data itself. This "feature" of the '0' bits is of course taken advantage of in some later copy protection schemes. (Rapidlok, Mindscape, and Datasoft, for example)

Differences between a "fast copier" and a "nibbler"
Copy programs have been referred to by these two different types since the first nibblers came out on the Apple II. A little more background is required in how the disk is structured to explain the difference. A track is broken up into a number or sectors, which are further broken up into a header and data portion, and each of these has a filler "gap" at the end to give the drive software time to change modes. The actual GCR data is structured like this:
SYNC (at least 10 bits of '1' in a row)
header 0 (8 bytes in DOS)
header gap (usually 5 filler bytes, longer for nibbled copies)
SYNC
sector data 0 (CBM DOS uses 260 bytes)
sector gap (usually 5 filler bytes, longer for nibbled copies)
SYNC
header1... (and on until the end of the track)
tail gap.. (unused bytes until it wraps back around to header 0)

Fast copiers
A "fast copier" reads the source disk on a sector-by-sector, normal CBM DOS level, and recreates them onto a new formatted disk. This method produces a "clean" copy of the disk, but does not copy any protection since it will ignore any sectors with errors, or any sectors that don't conform to the format explained above. It was really only used when we weren't going to try to copy the disk protection, but rather apply a "parameter" to the disk. A "parameter" is nothing more than a patch program that was run on the backup disk to remove the check for copy protection. Fast Hack'em, Kracker Jax, and later Maverick were all very popular copy programs that utilized parameters.

Nibblers
A "nibbler" works at a lower level and will duplicate the actual headers and data, whether or not they are in CBM DOS format. It does have limitations, though. First, they don't duplicate the header or tail gaps or the original sync length, but rather creates its own, so protections that hide (seemingly unused) bytes in the gaps or count sync lengths won't be duplicated. Secondly, the drive only has 2k of RAM, but a whole track is up to 8k, so it must be broken down and read in several passes, then stitched together on the destination disk. Protections that exploited this would use a sector or track larger than would fit in RAM at once, making it impossible to copy. Later, there were hardware solutions to this, such as extra drive RAM and parallel ports.

Protection Methods

Intentional Disk Errors
This protection consists of a disk error purposefully placed on a sector or an entire track, then its existence is checked for in the program. If the error isn't found, it assumes this is a copy and not an original disk. In the beginning, there were no copy programs except Jim Butterfield's "COPY/ALL" that came on the 1541 test/demo disk. This program could not reproduce these errors (and even if it could, it took *FOREVER* to copy even regular disks). Like most protection, though, it only foiled casual copiers. Early, clever crackers figured out how to scan an original disk for these and the methods for recreating the errors were not difficult. Soon after, programs like "Copy II/64" came out that could effortlessly detect and reproduce these errors which marked the end of this era. Most publishers of disk software used this method before late 1984.

Track Skew
This protection involves placing a track on the disk that is a specific skew offset from the one before it. The protection is checked by the program by stepping the heads between the tracks and checking that the exact timing is what is expected between them. If the timings are wrong, it knows this is a copy.

Fat Tracks
Fat tracks are a special case of track skew protection where two copies of a track are stored on sequential tracks of a disk with no skew, so they appear as one "fat" track. Electronic Arts used this protection from about 1984-1985, and Activision used it and called it "XEMAG" for many years. These protections stand out from most other early methods because they could *not* be copied 100% reliably even with *any* nibbler. As mentioned earlier, the 1541 has no way to know where it is on a track. Therefore, it has no way to know where it is in comparison to any other tracks on the disk. For this reason, it is impossible to reliably write these tracks out perfectly aligned with a 1541 drive. This was an idea that was greatly expanded on in future protections, but it still stands the test of time and still can't be duplicated reliably without using the index hole sensor. It is of note that it *is* possible to "unreliably" copy these, as you can just try over and over again copying just these two tracks until you happen upon "close enough" alignment for it to work. NOTE: Slowing your disk drive motor down to 298.5rpm or less seems to allow EA and XEMAG skew-protected disks to pass the protection checks.

Half Tracks
Along the same vein as fat-tracks, it was of course possible to read and write to the usually skipped "half-tracks" instead of the normal tracks, if you weren't worried about storing any data on the normal tracks. This foiled many copiers because they didn't search for and copy these half-tracks by default, so they instead got garbled, invalid mixes of the "real" data when trying to read the tracks as if they were normal. Copiers later came out that could scan for and detect these and copy them properly. There are very few titles which require half-tracks to work, but there are a couple.

Extra Tracks
This protection simply relies on using disk tracks beyond 35. Normally, copy programs default to copying only tracks 1-35, so these are missed. I am not sure why the programmers didn't extend this by default, except maybe some would lock up reading unformatted tracks, which these tracks usually are. Sometimes these tracks contained actual DOS-formatted data, but usually they were just "key" tracks. They could sometimes be nibbled, other times they could not, because they were combined with other protections.

Changed Bitrates
As mentioned above, the bitrate is normally higher on the outer tracks and lower on the inner tracks. Some disks were protected by using a non-standard bitrate on different tracks. Copiers later came out that would scan for the correct density and these disks could be copied that way.

"Signatures" in the Header, Sector, or Tail gaps
As mentioned above, when a disk is copied with either a fast copier or a nibbler, the gap data is not copied directly. Copiers would commonly just fill this space with 0x55 bytes. Gaps are "inert" bytes, meaning they aren't normally used as data, but just a space filler that is ignored by DOS. There are some protections that check for specific bytes here, or even the length of the gaps, and know they're a copy if it's different. This protection can be copied with hardware solutions that either extend the RAM in the drive to 8k or add a parallel port so it can read and write the entire track in one pass.

Long Sectors
As mentioned above, the drive has only 2k and can't fit an entire track in RAM, so it must be broken down into 4 parts and stitched together on the destination disk. If you make a sector longer than will fit in RAM, it can't be copied with a normal 1541. This can be copied with hardware solutions that either extend the RAM in the drive to 8k or add a parallel port so it can read and write the entire track in one pass.

Custom Formats
These usually depend on the long sectors trick above to be successful, but they also entail changing the way that GCR is interpreted in a custom DOS. If you write your own DOS, you can use your own disk format entirely, ignoring common sync, gap, header, and data conventions altogether and use whatever you want. You only have to adhere to the GCR limitations of sync and no more than two '0' bits in a row, but even that didn't stop later innovations.

Long Tracks
Normal drives spin at ~300rpm and can "write" data at the highest density up to about 7700 bytes per disk track. However, the drive can "read" more than that, within some margin of error depending on motor speed. Some protection took advantage of this and put more data on the track than could be written back out at the normal speed, making it difficult to copy. Some copiers would "trim" the data in as non-destructive way as possble (reducing sync length and gaps) and it was also possible to slow down the disk drive to foil this, but usually these disk relied on a combination of other protections as well. A good example of this is the later Epyx Vorpal protection/loader.

Sync Counting
A sync mark must be at least ten '1' bits long to signal the drive hardware that we're about to see GCR data. However, sync marks are usally much longer than this (40 bits) and have no limit to their length. When copying a disk with a software nibbler, sync has to be reproduced rather than copied, since it is more like a "signal" than actual data stored on the disk exactly. For this reason, the length of a sync is also somewhat dependent on drive speed and will vary a little. Some protections count on this and measure the lengths of the sync, or the occurances of sync on a track, to see if they match, and know they're a copy if they don't. Microprose used this method on some disks, and in fact "trimming" the sync will fail the protection checks.

Track Synchronization
We mentioned above that the drive doesn't use the index hole, so lining up the tracks on the disk is nearly impossible on the 1541. Since disks weren't usually mastered with a 1541, but rather with machines that could do track sync based on the index hole, protections took advantage of this in different ways. They would move to a halftrack or the next track in the middle of reading to see if the data that should be there exists. If it doesn't, it knows that it's a copy.

Bad GCR/Unformatted/"Weak Bits"
We mentioned before that if the drive sees 3 or more '0' bits in a row, it clocks in a random '1' bit occasionally. Single occurrences of this sequence won't always make it lose framing, it will return a "random" byte, but more than a couple in a row will result in the drive losing framing and reading these "random" bytes until it sees the next real '1' bit. Most nibblers can't duplicate this, so protections checked a byte purposefully on the disk somewhere and if it reads the same thing over and over, it knows it's a copy. Later copy programs did try to reproduce this-- Burst Nibbler detects and writes a 0x01 byte in their place, which is enough to fool most software into working. It is also worth noting that this is the same thing as unformatted tracks, so you'll see this a lot when imaging in new disks. Since the disks aren't usually duplicated on a 1541, and the tracks aren't always as long as they could be, the machine leaves unformatted data on the end of all the tracks, causing a lot of software to appear to have these on every track, and making it difficult to verify the tracks from disk to disk, since the bytes will be different from sample to sample. I have several disks from Synapse that have unformatted parts on all the tracks, and none of the tracks above 25 are formatted at all! I've seen this used in Rapidlok (all titles), later Microprose disks, and Datasoft (Bruce Lee, The Goonies, Mr. Do!)

Signature (Key) Tracks
This protection is seen from time to time and revolves around a track being mastered in a non-standard way. It can be all sync '1' bits (which we call a 'sync-killer' track), unformatted (or all '0' bits), filled completely with some other byte, or filled a special byte sequence like EA's PirateSlayer, or a combination of all of them. These tracks generally foil most all copy programs because they either cannot handle all or long sequences of '1' or all '0' bits, or they are just read incorrectly/out of framing. We can remaster most all of these with our development version of 'nibtools'.

No SYNC
One of the meaner protections that came about used tracks on the disk that had *no* sync marks. Most copiers cannot read these tracks and just detect them as empty. The later Epyx Vorpal loader uses this technique.

"SpiraDisc"
This protection name hails from the Apple ][ and isn't exactly the same, but similar. It is found on one commercial disk that we've seen- "Bounty Bob Strikes Back". The data on the first 14 tracks or so are written half on the regular track, and half on the next half-track, all aligned perfectly. The game loads by stepping out to track 1, beginning the load, then stepping a half track at a time all the way in until the game is loaded. If any deviation in time from where it expects the data to be and when is found, it fails. I've never been able to make a working copy. Jim Drew of UU developed a custom copier for the SuperCard+ board that is able to copy this protection, but it's really more of a custom "remastering" program.