3 ms·

IIRC, they were all defeated, except for the burn a hole in the disk and try to write to it copy protection mechanism. It was more a matter of which bit copy s

IIRC, they were all defeated, except for the burn a hole in the disk and try to write to it copy protection mechanism. It was more a matter of which bit copy software had the right profile to be able to copy the tracks. Back when I was doing a lot of copying disks, I remember it was really important to get the drive speeds right for a given profile. That way the you could dead reconing style copy for a partial track once the drive sync'ed to some known pattern that was fully on the starting track. These copies obviously didn't work 100% of the time, but generally a few tries would yield a working copy. I personally used Copy][ Plus as my primary utility and vaguely remember writing little "scripts" (more a few bytes of hex codes IIRC that described which tracks to read, and how to do quarter stepping/etc) to describe how to copy spiral track disks. Although frequently, I remember it being easier to try one of a number of other bit copy utilities first.

colanderman 8y ago
> the burn a hole in the disk and try to write to it copy protection mechanism Uhh, mind elaborating on this?
- _russross 8y ago
  I remember this was a protection scheme, but I don't remember who used it. They would use a laser to burn a small hole in the disk. At load time, the program would attempt to write to the sector with the hole and then read it back. If it succeeded, they knew it was a copy. Basically, they created a disk that could accept writes everywhere except a certain sector, something you could not replicate with even a perfect copy.
  - buserror 8y ago
    Yes and that was VERY easily defeated too -- you just had to take the floppy, very carefully align the synchronization hole with your copy, and take a pinhead and make your own little scratch in the same place. It was a bit silly to be honest -- this was the easiest copy protection to bypass!
    - hota_mazi 8y ago
      That won't work, because the actual disk inside the sleeve will never be aligned the same way your copy is. The protection is not the hole in the sleeve, it's the hole in the disk. For example, the garbage reads would happen on track 12, $230 bytes after the $D5 $AA $96 marker. Good luck physically reproducing this. These protections are trivial to remove in code, though.
      - buserror 8y ago
        You clearly have never looked at a floppy before making "that won't work" comments, but floppies have a sync hole that is aligned. And having made multiple copies like that, I know very well it worked pretty well as a method -- it's very likely why that method never became the 'uncopiable' it was claimed to be when it came out.
        StillBored 8y ago
        The apple ][ didn't have the hardware to read the sync hole (much less a sensor to detect where the head was, hence the clatter on reset as the head bangs into the endstop). That was part of the magic, each sector had a sync field and then a few bytes and a track/sector number. That is of course why its not just a simple case of locating where the burned hole was relative to the sync hole because the "physical" location of a sector offset on the disk would normally vary from disk to disk (or for that matter from track to track) or format to reformat.
        hota_mazi 8y ago
        I have seen many floppies, but you don't seem to know how the Apple ][ encodes bytes on the floppy because of the Disk 2 limitations. See my remark about the $D5 $AA $96 marker, and if you want to learn more, look up "6 and 2 encoding".

colanderman 8y ago

> the burn a hole in the disk and try to write to it copy protection mechanism Uhh, mind elaborating on this?

_russross 8y ago
I remember this was a protection scheme, but I don't remember who used it. They would use a laser to burn a small hole in the disk. At load time, the program would attempt to write to the sector with the hole and then read it back. If it succeeded, they knew it was a copy. Basically, they created a disk that could accept writes everywhere except a certain sector, something you could not replicate with even a perfect copy.
- buserror 8y ago
  Yes and that was VERY easily defeated too -- you just had to take the floppy, very carefully align the synchronization hole with your copy, and take a pinhead and make your own little scratch in the same place. It was a bit silly to be honest -- this was the easiest copy protection to bypass!
  - hota_mazi 8y ago
    That won't work, because the actual disk inside the sleeve will never be aligned the same way your copy is. The protection is not the hole in the sleeve, it's the hole in the disk. For example, the garbage reads would happen on track 12, $230 bytes after the $D5 $AA $96 marker. Good luck physically reproducing this. These protections are trivial to remove in code, though.
    - buserror 8y ago
      You clearly have never looked at a floppy before making "that won't work" comments, but floppies have a sync hole that is aligned. And having made multiple copies like that, I know very well it worked pretty well as a method -- it's very likely why that method never became the 'uncopiable' it was claimed to be when it came out.
      - StillBored 8y ago
        The apple ][ didn't have the hardware to read the sync hole (much less a sensor to detect where the head was, hence the clatter on reset as the head bangs into the endstop). That was part of the magic, each sector had a sync field and then a few bytes and a track/sector number. That is of course why its not just a simple case of locating where the burned hole was relative to the sync hole because the "physical" location of a sector offset on the disk would normally vary from disk to disk (or for that matter from track to track) or format to reformat.
      - hota_mazi 8y ago
        I have seen many floppies, but you don't seem to know how the Apple ][ encodes bytes on the floppy because of the Disk 2 limitations. See my remark about the $D5 $AA $96 marker, and if you want to learn more, look up "6 and 2 encoding".