There 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).
I 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.
yes. 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
My 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. :)
> 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.
I'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.
Never 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?"
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.
Same 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-... . 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.
The 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.
I 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.
I 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.
I 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.
If 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.
This 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.
the 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.
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
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.
I added this one to my 810. Screwed it up when I did it myself (note: 1st time ever soldering should not be done on your one and only disk drive) and got the folks at Happy to fix my botched job. The chip was really interesting: it basically gave extremely low level access to the drive to copy protected disks, but it was also leverged by their "Warp" disk operating system which was both faster than the Atari system and also was able to read wonky disks that the regular drives hiccuped on.
I still have my 800, Trak drive, and Commodore 1702. Mint condish. The 1702 needs to be re-capped, though, for sure. Last time I tried it, the shape of the picture was wonky.
> 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 found a "funny" like that with an Ensoniq Mirage that had been fitted with a PC floppy drive. "Modern" PC floppy drives use a /DISKCHANGE pin that goes low when a disk is in and "chucked" on the motor spindle but the head hasn't moved off the end stop. As soon as the head moves, /DISKCHANGE goes high. "Old fashioned" Shugart drives use the same pin for /READY, which is low when there's a disk in the drive and the motor is at speed.
The Mirage software checks for /READY at the start of any disk read or write, but once it's running it doesn't bother. It just keeps going until every sector is read, whether the disk is ready or not. If you pop the disk out halfway through a read, eventually it'll fail because it can't find the sector, not because the disk is no longer ready. If you use a PC floppy, it'll start to read the first time you put a disk in, but any subsequent ones will fail because the head has moved so /READY is no longer low.
So what was happening was it would boot, <CLUNK TUNK TUNK TUNK TUNK TUNK TUNK TUNK TUNK TUNK TUNK> as it zeroed the head and read in ten tracks, then sit there flashing ".n.d" meaning "No Disk" when it tried to load the first sample, because it loads the OS, does some internal tasks, then loads a sample off the disk. The head has moved, the disk is no longer ready, it thinks you've got no disk in. Worse, because the software expects a bunch of things to be loaded into RAM, pressing more or less anything except "LOAD" will crash it as it reads garbage where it should read jump tables.
So, for quite a while now, I let it load the OS, then in the half a second it's clearing RAM and tuning the filters, I hit the eject button and pop the disk back in. One day I'll either get the right drive, make an adaptor for the drive, or patch the OS to solve the problem ;-)
Operator addendum: plz eject disk and quickly insert again...
I have an old laptop with some dev tools on it that also runs XP. I use it lightly and it has a bad fan.
Set to entirely passive cooling?
Nope. BIOS wants to see the fan spin, so...
Sitting near that laptop is one of those computer air cans. At power on, wait about a second, shoot fan with air, BIOS sees spin, system check passes and just don't run the machine past passive cooling limits.
Most copy programs would ignore those bad sectors and so they wouldn't be on the copies. But you could actually use a sector editor to write the bad sectors to copied disk and that was usually enough to make them work.
So I think you are referring to the notch on the side of the disk. If it was present the disk was writable, if not then read only.
It was common to write-protect a disk using a small sticky label, folded over the notch. From memory, disks came with these labels.
We also found out you could add a notch on the other side, and use the disk upside down (ie as a second disk) thus doubling the storage value of each disk. All magazine materials explained why this was a bad idea, lead to data corruption etc, but it worked well and so we ignored the warnings.
This became so popular that I remember owning a punch literally made for this exact purpose. It positioned the disk in the right place and cut a perfect square notch. So this practice was wide-spread enough that someone actually designed and produced a tool to do it.
But yeah, in the early days, we used scissors (very carefully).
Any chance you still have the punch? I got a box of double sided disks that were intended for a double sided drive, so only had notches on one side... Would be lovely to notch 100 disks the easy way.
There are still some stores that sell these "floppy disk notchers" [1] if you're feeling really nostalgic for authentic vintage units, and occasionally they'll pop up on the usual auction sites. Or you can 3D print yourself one these days [2]. I was too poor to get a real notcher, so made do with an X-acto knife and a cardboard template I would create over and over. By the time I could afford a notcher, the muscle memory was etched into my fingers and hands, and I never bothered to get one.
You 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.
