10 ms·
Early Copy Protection on the Apple II
- mc4ndr3 4y agoFun read! I'm having trouble understanding how a max byte read, a la ``dd`, would somehow be insufficient to yield a working digital master of an analog cassette tape.
- deleted 4y ago[deleted]
- CamperBob2 4y agoSame here. His explanation left me feeling like I'm missing something that's at once extremely simple and extremely clever. It seems to involve the observation that reading more data than the tape actually contains will return a trailing section of random noise that will fail a checksum, but that's as far as I got. (Edit: the author posted an answer to StackExchange here: https://retrocomputing.stackexchange.com/questions/143/what-format-is-used-for-apple-ii-cassette-tapes https://retrocomputing.stackexchange.com/questions/143/what-... . A single-byte checksum is appended to the tape image written by the firmware, and the software is presumably aware of what it should be. If you were to make a copy of the tape by writing too much data, the resulting checksum returned by the firmware would probably not match what the software expected. Maybe it's as simple as that?) Another point worth making when it comes to the cassette port, is that every Apple ][ essentially came with a free 1200-bps half-duplex modem. All you had to do was "just" connect the cassette in/out ports to the phone line with simple audio amps. (ISTR using the hybrid network from an old Western Electric rotary phone to do the actual interfacing.) I don't think I've ever run into anyone else who tried this, but it was an amusing thing to play with as a kid. I built two interfaces and gave one to a friend on the other side of town. It took less than a minute to send images of Suzy and Melissa from a warez copy of Artworx's Strip Poker, as I recall.
- dhosek 4y agoThe other trick was to use the tape loading routines to read audio from a cassette tape and digitize it as 1-bit audio at some low bit-rate (1.2kHz?). It sounded pretty awful and you couldn't hold much audio in RAM, but it was possible. I had a floppy with an excerpt from Led Zeppelin’s Black Dog digitized with this technique.
- CamperBob2 4y agoI remember being astonished at how realistic Vincent Price's laugh from the end of Thriller sounded when replayed using this hack. Either it didn't have enough high-frequency content to alias, or the aliases just added to the effect.
- TedDoesntTalk 4y agoI have a program on disk called Apple Rock ‘83 that has 4 of those songs, including Black Dog. The author built a quiz around the songs. The others were, I think, Eruption by Can Halen and … now I forget then others.
- pvg 4y agoDid you ever get around to posting it? https://news.ycombinator.com/item?id=28757274 https://news.ycombinator.com/item?id=28757274 I wonder how it will compare to other bits and pieces of Apple ][ sampled sound that are floating about.
- TedDoesntTalk 4y agoI posted it after reading your comment. Thanks for the reminder: https://youtu.be/RKPaacw8UHk https://youtu.be/RKPaacw8UHk
- Someone 4y agoI remember you could get a fairly high frequency (¿12kHz, maybe even 20kHz?) if you were willing to not sample uniformly. On a 6502, you would shift 8 1-bit samples into a single byte at high frequency, spend some time writing the byte, rapidly sampled 8 more bits, etc. The “write a byte” step also wasn’t constant time, as increasing the address to write to took longer when you crossed 256-byte boundaries. So, recording missed samples at predictable times. The trick was to make the playback code use the exact same timings. I think there was an article in Compute! for doing that on Commodore machines, but cannot find it.
- duskwuff 4y agoOr, even simpler -- surely you could use a pair of tape recorders to duplicate the tape, ignoring the digital aspects entirely?
- chillingeffect 4y agothe difference between 'dd' and analog tape copy is a regeneration of the write signal. In 'dd', the buffered data are written "freshly" from a GPIO into the cassette port. This results in a "stiff" or nearly perfect transition from '0' to '1' (and vice versa) because the output transistors in the chip are able to drive sufficient current into the high-impedance input of the cassette recorder's write circuitry mostly an amplifier (with a 20kHz oscillator mixed, but that's a long story) and the circuitry is able to generate rapid flux transitions and the tape can receive them. The resulting bandwidth of the signal into the write circuitry is roughly 20kHz and the resulting flux transitions in the ferrite are "sharp", "tall", brief, critically-damped, and quickly stablize on the microsecond scale. When performing an analog copy, those some excellent flux transitions are degraded at least 3 key distortions: First, there is limited bandwidth in the read circuitry. This is roughly equivalent to several low-pass or smoothing filters with various attenuations and cutoffs. They result from the original design intent of the recorder for audio, series inductance of the read head, and imperfect corrections for the frequency response of the media (think RIAA record curve). Additional distortions arise from noise, such as thermal, Schott, EMF, etc. There is also wow and flutter from the imperfections of the tape drive resulting in jitter. When the resulting imperfect signal is then sent to the write input of the cassette recorder, the flux transitions on the media are not as ideal and crisp as when a GPIO pin creates them. In general there are no regeneration stages, except for the "comparator" or differentiator in the input stage of the GPIO which reads the tape and determines at each time interval if the freshly-read bit is to be interpreted as a 0 or 1. The flux transitions may still be reliably read, but not after several generations of this process, and it will depend on the general quality of the tape recorder's electronic and mechanical components, tape quality, etc.
- VyseofArcadia 4y agoThis was addressed in the article. You could for a few copies, but eventually the signal degraded to the point where a copy of a copy of a copy ... (n times) was unreadable. To combat this you would have to either dup from master, or read in (analog -> digital) followed by a read out (digital -> analog) to make a new pristine master.
- NateLawson 4y agoIf you did a pure analog copy (dual tape deck), you had generation loss. Eventually copies of copies would have too much noise and thus persistent load errors. Additionally, in-band signals were included in the gaps between blocks that would mess with the auto gain control, causing an unreadable copy as the tape deck tried to compensate. The loader would skip over these sections during the regular load process. All copy protection relies on asymmetries between the production/mastering environment and the consumer equipment.
- josephcsible 4y ago> In this case the copy protection was not only ineffectual, it was also a nuisance because it prevented the program from running on later machines. Nothing's changed, I see.
- jakzurr 4y agoThanks for posting - love this stuff!
- Sunspark 4y agoTony Hawk when not doing ollies, was out there cracking everything.
- TheDigitalGang 4y agoYou are thinking of Tom E Hawk.
- Sunspark 4y agoYes, thank you.
- user3939382 4y agoCopy protection on my Apple II was simple for me as a kid, all I needed was a pair of scissors! Or was that to make the disk writable...
- sbf501 4y agoYou still needed programs like Copy ][+ and Locksmith. For example, common strategies were half and quarter track writes: shifting the head a small amount, which makes the disk unreadable by the system function calls, but not by its own bootloader, which is why it could run but you couldn't copy the disk with the Dos 3.3 tools (or ProDOS tools). The two programs I mentioned could be configured to offset the head, allowing you to "break" the protection.
- ddingus 4y agoThat was to make the disk writable. There was a copy protection on the Atari computers that was actually super simple. Having hacked on some games on the Apple, I decided to give the Atari machines a go, and those did a very interesting thing when loading software, and that thing was to make sound. One beep sound per sector! Ultima II was protected using the "bad sector" method. Basically, the commercial disk was mastered in such a way that a sector, or group of them, would fail to read properly. Users could not make these disks easily, and that was the protection. I was about to start disassembling the program and decided to try something: Booting the official disk highlighted a bad read some number of reads in. You could hear it. Beep, beep, beep, bfzfzfzfzf [pause], beep, beep, beep... My solution was to just open the disk drive door at the right time. Count the beeps, open door, let errors happen close door, play game. I never did begin to disassemble that game on Atari machines. :D
- NonNefarious 4y agoHa, I remember that. The more-clever Atari copy protection involved the publishers using a customized drive to write two consecutive sectors with the same sector number. The loading program would request that sector twice in succession, so as the drive head finished reading the first one it would immediately read the second... which had different contents. If you simply duplicated the disk, the drive would not read the sector twice and you'd be missing critical data. There was a chip you could install in your Atari drive called the Happy Enhancement to defeat this.
- unwiredben 4y agoIf you like this, check out the 4am collection on archive.org (https://archive.org/details/apple_ii_library_4am https://archive.org/details/apple_ii_library_4am) - the Apple II hacker posts detailed logs of their cracking techniques for each title. Here's an example of the crack note for Datasoft's Pac-Man port (https://ia600508.us.archive.org/20/items/PacManDatasoft4amCrack/Pac-Man%20%28Datasoft%29%20%284am%20crack%29.txt https://ia600508.us.archive.org/20/items/PacManDatasoft4amCr...)
- ars 4y agoAnyone remember CPS Copy II Plus? It was quite an interesting program, letting you move the disk head a fraction of a track at a time.
- sumoboy 4y agoyes. we used to modify the applesoft rom card to pretty stop the CPU, start hacking the memory to find out where copy protection routines were and patch the code. The same concepts even transitioned into the first macs for cracking and patching. Fun stuff
- rlonstein 4y agoI remember that and Locksmith, a different disc copier. As a pre-teen I was really into this and with copies of _Beneath Apple DOS_ and Zak's _Programming the 6502_ I wrote my own nibble copiers and boot sectors.
- otterley 4y ago(2004)
- js2 4y agoThere were peripheral cards for the Apple II that would snapshot memory and write it to disk. You could use these to copy most games/programs. But there were still a couple games that would periodically check that their disk was still in the drive for which this wouldn't work. Edit, oh it's mentioned on the Spiradisc page: > Spiradisc was used on Sierra's "Frogger" and "Maze Craze Construction Set" titles. It truly was state-of-the-art. My favorite trick was the way they defeated NMI copy cards, which captured a snapshot of the computer's memory after the game had loaded. The easiest trick -- corrupting your stack pointer when the game is idle, so the interrupt frame overwrites a valid return address -- was too obvious, and too easily circumvented. Instead, Spiradisc collected some information about the computer's configuration as it was booting. This was periodically re-checked. If the computer had mysteriously gained or lost peripherals, the game knew it was running on a different computer, and would bail. This meant that memory-image copies would appear to work until you tried using them somewhere else, which, as intended, had me running in circles for a few days (the copy card was in a friend's computer). https://fadden.com/apple2/computist.html https://fadden.com/apple2/computist.html
- sgt101 4y agoDoes anyone else remember : https://en.wikipedia.org/wiki/Lenslok https://en.wikipedia.org/wiki/Lenslok Elite was where I came across it.
- richrichardsson 4y agoSame, and quite often it would't bloody work!
- abrookewood 4y agoNever saw that - pretty cool (but annoying). I do remember endless time spent in the library photocopying manuals so you could answer those text challenges: "On page 46, in the third paragraph, what is the second word?"
- marcodiego 4y ago> Copying this to a new tape or adapting it for use on a disk-based system is straightforward. The easiest way to make a copy is to simply copy both stages to a new tape, without modifying either. At first I thought: So where is the copy protection? It will just prevent people who don't have double deck cassette player from copying it? You can easily write a routine to read the tape, buffer it to memory and play it back anyways." The point is: copying with a double deck system will degrade the audio so that it won't work after a few generations and writing a low level routine to buffer the tape and then play it back will make copying it only feasible to dedicated hackers. Clever.
- abrookewood 4y agoI'm still more impressed by the schemes that prevent you from just copying tape-to-tape or disk to disk. I remember on the C64 some games deliberately put read errors on the tracks, which most copy programs would ignore. If you did a disk-to-disk copy, the duplicate wouldn't boot because it was looking for the read error. I figured out I could use a sector editor to read the error from the original disk, swap them out and then write it to the duplicate - which then worked correctly.
- iKnowKungFoo 4y agoMy high school had Apple IIe computers. My classmates had been stealing my homework when they asked to play a game from my disk. My "copy protection" was to name files using Alt characters (I think), so the file name looked like "HIST 202 REPORT", but the spaces were the Alt characters. No one could copy the files after that and the class grade average tanked. :)