EricBall's Tech Projects

I think most of what was known about copy protection wasn't publicly documented. It was proprietary information held by companies. There were some excellent books, however, such as Beneath Apple DOS, which told you just about everything imaginable about how DOS and the Disk II drive and controller worked. By now, someone may have scanned this book. The only other public documentation I know of was written by crackers and posted to BBS's. The website textfiles.com seems to have recovered some of that.

I found "The Copy Protector's Notebook by Bruce Jones & Lane Roathe" which seems to be very detailed. Not the easiest read though.

 

One item I haven't learned yet is whether the MSB=1 for disk bytes was a hardware or software limitation. If it was a software limitation, then someone could have used the Commodore 4 and 1 coding instead of Woz's 6 and 2 coding and thus gotten ~170K of usable storage per side of the disk (instead of 140K). Over 200K per disk if you used 3/4 tracking.

I found "The Copy Protector's Notebook by Bruce Jones & Lane Roathe" which seems to be very detailed. Not the easiest read though.

 

One item I haven't learned yet is whether the MSB=1 for disk bytes was a hardware or software limitation. If it was a software limitation, then someone could have used the Commodore 4 and 1 coding instead of Woz's 6 and 2 coding and thus gotten ~170K of usable storage per side of the disk (instead of 140K). Over 200K per disk if you used 3/4 tracking.

I didn't think one could use 3/4 tracking reliably. I thought the drive head would obliterate data on neighboring 3/4 tracks? If it really worked, I imagine it would have been done often enough so I would have heard about it, but I could be wrong.

 

I don't know enough about the MSB thing to comment, but I do recall vaguely that someone managed to squeeze 18 sectors in a track instead of the usual 16. Maybe this is what you are talking about?

One item I haven't learned yet is whether the MSB=1 for disk bytes was a hardware or software limitation. If it was a software limitation, then someone could have used the Commodore 4 and 1 coding instead of Woz's 6 and 2 coding and thus gotten ~170K of usable storage per side of the disk (instead of 140K). Over 200K per disk if you used 3/4 tracking.

 

I believe Apple used the same address for the 'ready' indicator as for reading actual data; bit 7 was the 'ready' flag. That doesn't mean one couldn't have used alternate coding schemes, but Apple's GCR coding is more dense than the earlier MFM coding. Further, the 1541 used multiple data rates and I suspect that, rather than the choice of bit-stuffing method, is responsible for its higher density (the inner tracks hold 17 sectors on the 1541; I would guess Apple could put 17 sectors/track with its encoding method but doing so would reduce the allowable variation on rotational speed).

I found "The Copy Protector's Notebook by Bruce Jones & Lane Roathe" which seems to be very detailed. Not the easiest read though.

 

One item I haven't learned yet is whether the MSB=1 for disk bytes was a hardware or software limitation. If it was a software limitation, then someone could have used the Commodore 4 and 1 coding instead of Woz's 6 and 2 coding and thus gotten ~170K of usable storage per side of the disk (instead of 140K). Over 200K per disk if you used 3/4 tracking.

 

It was a hardware limitation, as in it was in the state machine. The original limitations were more stringent and the original encoding was 4 and 4, but an update to the PROM relaxed this to allow 6 and 2. 4 and 4 was still used in the prologue I believe.

 

I used to know all of this stuff like the back of my hand and have coded my own fast DOS, fast copiers, protection schemes with custom encoding quarter track arcing, Apple II viruses (dare I admit that?) and cracked more titles than I can remember.

 

I still have:

 

2 copies each of beneath Apple Dos and Beneath Apple ProDos. (Don Worth and Pieter Lechner)

Supplement to Beneath Apple ProDOS (Worth and Lechner)

'the custom apple and other mysteries' - hardware projects for the Apple II (Hofacker Floegel)

2 copies of "Understanding the Apple II" (Jim Sather) - includes amazing analysis of the Apple II hardware and chapter 9 is all about "The Disk Controller".

 

If you want to know the Apple II disk controller, you might be in luck because I can part with one copy of Beneath Apple Dos and One copy of "Understanding the Apple II". Between these two tombs, I can't imagine any question hardware or software that could not be answered.

 

One funny thing I found while browsing the web was the mistaken notion by Woz and Andy Hertzfeld that the MAC's IWM (integrated Woz Machine) and 68000 drive software was able to do something that Apple II was incapable of, reading/decoding an entire track without any interleaving. It turns out that this feat was possible on the Apple II but you had to think outside the box (a la Supercat heh!) and dispense with the normal 6 and 2 encoding table and allow yourself to let the 6502 code decide which was the best 6 and 2 table. It was possible in 32 cycles to read and decode a 6 and 2 byte from disk. You do have to dispense with compatiblity however.

 

In fact, this was a technique used by the Locksmith fast copier, able to read standard DOS 3.3 and ProDOS disks in a single rotation of the disks without the extra overhead of storing the raw disc bytes. Since it was a copier it didn't worry about the fact that, in memory, the data bits were swizzled, as long as the got onto the destination disc in the correct place. The Locksmith fast copier was perhaps the pinacle of Apple II disk coding. Another example of how flexible Woz's design was, to be able to go beyond what he could imagine.

 

 

- David Galloway

Here's a reference with regard to what I was remembering.

 

Nybbles - about the Woz style disk controller on the MAC <-- with comments / scroll up for entire article.

I'm curious how the Apple deals with variable rotation speed when reading disks (even if data is written at one byte per 32 CPU cycles, data may be read at a rate anywhere from one byte per 31 cycles to one byte per 33). Anyone know the nasty details?

 

Also, it's interesting that Apple had a lot of trouble getting four voices on a 68000. It's possible to do stuff prety fast. Let's see...

add.w a0,d0;  Low word of frequency #0
addx.l a1,d1; MSW holds low word of frequency #1; LSB holds high byte of frequency #0
addx.l a2,d2; MSW holds low word of frequency #2; LSB holds high byte of frequency #1
addx.l a3,d3; MSW holds low word of frequency #3; LSB holds high byte of frequency #2
addx.w a4,d4; High byte of frequency #3
and.w d5,d1; D5 holds table length (power of two minus one)
and.w d5,d2
and.w d5,d3
and.w d5,d4
mov.b (a5,d1),d6
add.b (a5,d2),d6
add.b (a5,d3),d6
add.b (a5,d4),d6
mov.b d5,(a6)+

Six 4-cycle instructions (24), three six-cycle instructions (18), four fourteen-cycle instructions (56), and an eight-cycle instruction (8 ). So 24+18+56+8 = 106 cycles/sample plus loop overhead. At 8MHz, there are 363 samples so that should fit well within a 50% CPU utilization target. Freeing up a4 and d4 would not be difficult; since d7 is also free, that would allow five voices (still while staying entirely in registers). Reloading D5 each loop (if wavetables are <=127 bytes, this could be done with a MOVEQ) would allow for six voices.

 

BTW, if one unrolled the loop and didn't mind having to copy the first few bytes of each wave table after the end, one could save 16 cycles per sample on all but one of the unrolled copies pretty easily.

Thanks for the offer dj! Actually, today I found "Understanding the Apple ][" in PDF form online and I'm digging into Chapter 9. I also found a summary of the P6 state machine which flagged the MSB=1 requirement. (And yes, some parts of the sector headers & boot sectors use 4+4 to simplify decoding.)

 

By maybe you can help me with a side quest. One of the disk copiers I remember from the early 80s was one which could copy a disk (on a 128K //e) in just two passes (more like one and a half). The one bit I do remember was it billed itself as "Fast-Ass Disk Copier - No Shit"; which was terribly amusing to a 13 year old. (It was also damn fast and handled almost anything I got my sticky fingers on.)

 

Ahh... those were the days. I had my boxes of disks (my mom worked in the Radio Shack computer store so I got ones which wouldn't format right); double side punched, of course; filled with games that had trickled down through the school system.

By maybe you can help me with a side quest. One of the disk copiers I remember from the early 80s was one which could copy a disk (on a 128K //e) in just two passes (more like one and a half). The one bit I do remember was it billed itself as "Fast-Ass Disk Copier - No Shit"; which was terribly amusing to a 13 year old. (It was also damn fast and handled almost anything I got my sticky fingers on.)

That would probably be the Locksmith 5.0 fast copy. Normally you had to boot Locksmith and select it via a menu, which then loaded the fast copier. But before long, crackers made it into a standalone binary and probably hacked in their own text. It was amazingly fast on my //c. It also was awesome at recovering bad disks. A bed sector would be read up to 9 times, and if it didn't read it, it would write zeros to that sector on the destination disk so you could open the file once again.

 

To be sure we're talking about the same thing, the above filled the screen with the disk sector map as it copied.

That would probably be the Locksmith 5.0 fast copy. Normally you had to boot Locksmith and select it via a menu, which then loaded the fast copier. But before long, crackers made it into a standalone binary and probably hacked in their own text. It was amazingly fast on my //c. It also was awesome at recovering bad disks. A bad sector would be read up to 9 times, and if it didn't read it, it would write zeros to that sector on the destination disk so you could open the file once again.

 

To be sure we're talking about the same thing, the above filled the screen with the disk sector map as it copied.

Yep, sounds like the same thing. I'd forgotten about the bad sector retry, but that also sounds familiar.

For those interested, it's all there in Chapter 9 of "Understanding the Apple ][". The MSB=1 is a requirement of the Read Sequencer (and also simplifies the 6502 read disk code). What's interesting is the Write Sequencer could care less; it just shifts bits to disk.

 

Which brings up an interesting point w.r.t copy protection; namely it's possible to write to disk anything which can be read, but not vice-versa. If the converse were true, then copy protection would simply be creating disks with data which could be read, but not written. (a la the GameCube which used an area not readable by a standard DVD or writable by a standard DVD writer.)

By maybe you can help me with a side quest. One of the disk copiers I remember from the early 80s was one which could copy a disk (on a 128K //e) in just two passes (more like one and a half). The one bit I do remember was it billed itself as "Fast-Ass Disk Copier - No Shit"; which was terribly amusing to a 13 year old. (It was also damn fast and handled almost anything I got my sticky fingers on.)

That would probably be the Locksmith 5.0 fast copy. Normally you had to boot Locksmith and select it via a menu, which then loaded the fast copier. But before long, crackers made it into a standalone binary and probably hacked in their own text. It was amazingly fast on my //c. It also was awesome at recovering bad disks. A bed sector would be read up to 9 times, and if it didn't read it, it would write zeros to that sector on the destination disk so you could open the file once again.

 

To be sure we're talking about the same thing, the above filled the screen with the disk sector map as it copied.

 

Locksmith 5.0 was the best. Now the one you had "Fast-Ass Disk Copier" was probably one of many pirate versions of Locksmith 5.0 where they broke out the disk copier from the suite of tools (and of course re-labeled it). Locksmith 5.0 was about $100 and many people just wanted the copier, so it was probably a missed opportunity for them not to sell it seperately for cheaper (of course it would've still been pirated).

 

Locksmith 5.0 is the set of routines that can read and write entire tracks at 1:1 interleave. The encode/decode is done during the 32 cycle read/write loops instead of just wasting time with pha/pla etc. Back in the day, I disassembled and commented the routines but I've since lost that. I had it in mind to find the code again and disassemble it again and publish it because it's genius seems largely forgotten.

Also, it's interesting that Apple had a lot of trouble getting four voices on a 68000. It's possible to do stuff prety fast. Let's see...

 

I don't remember the precise details but a friend and myself created a four voice player for the 68000 (on the Atari ST). We took some shortcuts in quality that Apple wouldn't have allowed. One of the coolest parts that I recall is that we used a single 32 bit value to hold two 16 bit voice pointers. Two words gave us 4 voices. An early form of SIMD if you will.

 

I'll try to dig up the code and/or recreate it perhaps.

 

We also simulated hardware wavetables (since the ST had none) by dedicating an address register to point to the wavetable in RAM and therefore the interrupt routine was very light-weight. It seems obvious now but all the routines we had seen before did the mixing in the interrupt routine.

I found "The Copy Protector's Notebook by Bruce Jones & Lane Roathe" which seems to be very detailed. Not the easiest read though.

If you have any questions, just ask. It's been a while, but I can probably answer some questions

Locksmith 5.0 is the set of routines that can read and write entire tracks at 1:1 interleave. The encode/decode is done during the 32 cycle read/write loops instead of just wasting time with pha/pla etc. Back in the day, I disassembled and commented the routines but I've since lost that. I had it in mind to find the code again and disassemble it again and publish it because it's genius seems largely forgotten.

Just as an aside, the code to read the disk & decode the nibbles at 1:1 was extremely complicated...not nearly as simple as that statement makes it seem. It was difficult enough to get a full track read and decoded at 2:1 in DUP. I tried to follow all the way through their code and never did get a 100% understanding of what they were doing ... of course by then I was moving on from writting 5 1/4" drive routines so I didn't give understanding it a full effort

Which brings up an interesting point w.r.t copy protection; namely it's possible to write to disk anything which can be read, but not vice-versa. If the converse were true, then copy protection would simply be creating disks with data which could be read, but not written. (a la the GameCube which used an area not readable by a standard DVD or writable by a standard DVD writer.)

Actually not quite true in practice, since many of the later copy protection schemes used custom hardware to write the data. For instance some EA games were protected by having a write head that was larger than normal (from 2x to 1.5x depending on the title) and which could not be written by a standard Disk ][. With a lot of trial and error, and knowing in advance what was required, one could "fake" the writes to a degree that the checking code would accept (but the data on the copied disk would still not actually match the original disk).

 

Similar uses had two drive heads, either in sync or out of sync (ie, one head 3/4 track away and 1/2 track behind). Another scheme that may or may not have used custom hardware was "perfect tracks" where the data on the disk was written in such a way that the last bit of a track completed writting just before the first bit of the track. It was possible to re-write the data, but it took special code and typically dozens to hundreds of writes to recreate.

Actually not quite true in practice, since many of the later copy protection schemes used custom hardware to write the data.

 

The easiest form of custom hardware would be a recoded MPU chip. Given that an MPU-chip programmer could be built with a socket, 16 switches, eight LEDs, about 30 resistors, a transistor, and a battery, the monetary investment required for someone with the expertise to design such a thing would be pretty slight.

 

As noted above, a recoded MPU chip would allow the writing of pulses that were not multiples of 8 MPU clocks in length. I haven't studied the state diagram fully, but I don't think the stock MPU design would allow for that. The write heads are either off, write-plus, or write-minus; I don't think one can switch between write-plus and write-minus except at multiples of eight MPU cycles, and I don't think switching between "off" and the other states would occur cleanly enough to guarantee predictable results.

 

If I were trying to design a protection scheme, my approach might be to hack the MPU so that it could be thrown into a state where the CPU controlled the output phase directly. Or I might wire one of the annunciators into the disk controller and "AND" it with the D7 signal of the shifter. This would allow the CPU to easily generate phase transitions that were either 14 MPU clocks in length (seven cycles) or 18 cycles in length (nine cycles), both of which would be read as "10" by the disk controller, but could be distinguished by the time required to read them.

The one bit I do remember was it billed itself as "Fast-Ass Disk Copier - No Shit"; which was terribly amusing to a 13 year old. (It was also damn fast and handled almost anything I got my sticky fingers on.)

 

I would have been one of those 13-year old kids.