4 ms·

C64 Copy Protection

62 points by snvzz 8mo ago

classichasclass 8mo ago
Ah, duplicate sector IDs. Ran into that not too long ago: https://oldvcr.blogspot.com/2023/08/cracking-designwares-grammar-examiner.html https://oldvcr.blogspot.com/2023/08/cracking-designwares-gra... V-MAX! and Rapidlok were like deep magic, though. I never successfully cracked a title with that by hand myself.
altitudinous 8mo ago
Interesting to see this stuff. I really enjoyed cracking this back in the day, just for friends, but took a different approach of using sector editors to read the code on the disk to find where the checks wer done to see if the protections were present and replacing it with NOPs ($EA), or changing BNEs to BEQs. What was more interesting was how the code that did the check was also moved about the disk, I remember seeing for a particular piece of code it did a B-E (Block Execute) on Track 5 Sector 5. I could plainly see the protection check on that spot on the disk. My young self was very excited about working it out. The puzzle of copy protection was more fun than playing the actual games. Very frequently the directory tracks (18?? I think) were overwritten but it was obvious looking over the disk to see the headers for various programs and the load start address so it was easy to rebuild. Golden times. I've coded since then, and only recently have stopped as AI has finally got better than me!!
kenjackson 8mo ago
So interesting! There was a level of creativity back in those days that we seem to not have as much nowaydays. Now things seem to be based more on math and things like signing. As a C64 user a kid one thing I didn't realize was this: "The serial bus connecting the 1541 to the C64 has a famous bug. Commodore designed it to run at ~16,000 bytes/second, but a timing error in the Kernal ROM's ATN (Attention) line handling caused it to insert extra delays between every single byte — dropping the real-world speed to around 400 bytes/second. That's roughly one-fortieth the intended speed. Commodore never fixed it in the C64's lifetime. (A workaround was eventually added for the 1571 drive, but the 1541 remained slow throughout its production run.) Fast loaders worked around this by downloading replacement code into both the drive's RAM and the C64's RAM, then communicating over the C64's User Port parallel pins instead — bypassing the serial bus completely. This gave transfer rates around 10,000 bytes/second (25× faster). " I recall the "fast loaders" and always wondered how they could get data off a disk any faster. It seemed like magic. But now I know.
- Two9A 8mo ago
  It's worse than that even: there are delays after every _bit_ transferred, due to various design decisions that were made along the way, which is why the C64's disk drive is slower than the previous computer (the VIC-20), which is slower than the one before that (the PET). I wrote about the decisions and the resulting delays for one of those 100-post Threadapalooza projects in 2024, compiled here for easier reading: https://imrannazar.com/articles/commodore-1541 https://imrannazar.com/articles/commodore-1541
  - krige 8mo ago
    > A minor rework of the board at the board manufacturers (to accommodate a screw hole, I believe) accidentally discarded the high-speed wire. oh my
    - rasz 8mo ago
      Not buying that, C64 had like 5-10 pcb revisions so spinning another one wouldnt be extraordinary, and in the mean time they could put bodges on old stock pcbs or you know, supply USERPORT cable as thats where 6526 is wired to. Original Kernal has no traces commodore ever tried to use hardware shift register, they simply left VIC20 bodge and didnt even try accommodating fixed 6526.
      - krige 8mo ago
        Memory a bit foggy on that but weren't c64 mainboard revisions almost exclusively to make them cheaper, not better?
        rasz 8mo ago
        Successive revisions fixed hardware bugs and added functionality like 8-pin video port in place of 5-pin one.
- pizza234 8mo ago
  > There was a level of creativity back in those days that we seem to not have as much nowaydays. Now things seem to be based more on math and things like signing. Copy protections nowadays are actually extremely complex - just look at Denuvo and VMProtect. I presume that nowadays there are less copy protection schemes because producing a resilient one is too complex for small developer teams.
deleted 8mo ago
[deleted]

62 points by snvzz 8mo ago

Ah, duplicate sector IDs. Ran into that not too long ago: https://oldvcr.blogspot.com/2023/08/cracking-designwares-grammar-examiner.html https://oldvcr.blogspot.com/2023/08/cracking-designwares-gra... V-MAX! and Rapidlok were like deep magic, though. I never successfully cracked a title with that by hand myself.

altitudinous 8mo ago

Interesting to see this stuff. I really enjoyed cracking this back in the day, just for friends, but took a different approach of using sector editors to read the code on the disk to find where the checks wer done to see if the protections were present and replacing it with NOPs ($EA), or changing BNEs to BEQs. What was more interesting was how the code that did the check was also moved about the disk, I remember seeing for a particular piece of code it did a B-E (Block Execute) on Track 5 Sector 5. I could plainly see the protection check on that spot on the disk. My young self was very excited about working it out. The puzzle of copy protection was more fun than playing the actual games. Very frequently the directory tracks (18?? I think) were overwritten but it was obvious looking over the disk to see the headers for various programs and the load start address so it was easy to rebuild. Golden times. I've coded since then, and only recently have stopped as AI has finally got better than me!!

kenjackson 8mo ago

So interesting! There was a level of creativity back in those days that we seem to not have as much nowaydays. Now things seem to be based more on math and things like signing. As a C64 user a kid one thing I didn't realize was this: "The serial bus connecting the 1541 to the C64 has a famous bug. Commodore designed it to run at ~16,000 bytes/second, but a timing error in the Kernal ROM's ATN (Attention) line handling caused it to insert extra delays between every single byte — dropping the real-world speed to around 400 bytes/second. That's roughly one-fortieth the intended speed. Commodore never fixed it in the C64's lifetime. (A workaround was eventually added for the 1571 drive, but the 1541 remained slow throughout its production run.) Fast loaders worked around this by downloading replacement code into both the drive's RAM and the C64's RAM, then communicating over the C64's User Port parallel pins instead — bypassing the serial bus completely. This gave transfer rates around 10,000 bytes/second (25× faster). " I recall the "fast loaders" and always wondered how they could get data off a disk any faster. It seemed like magic. But now I know.

Two9A 8mo ago
It's worse than that even: there are delays after every _bit_ transferred, due to various design decisions that were made along the way, which is why the C64's disk drive is slower than the previous computer (the VIC-20), which is slower than the one before that (the PET). I wrote about the decisions and the resulting delays for one of those 100-post Threadapalooza projects in 2024, compiled here for easier reading: https://imrannazar.com/articles/commodore-1541 https://imrannazar.com/articles/commodore-1541
- krige 8mo ago
  > A minor rework of the board at the board manufacturers (to accommodate a screw hole, I believe) accidentally discarded the high-speed wire. oh my
  - rasz 8mo ago
    Not buying that, C64 had like 5-10 pcb revisions so spinning another one wouldnt be extraordinary, and in the mean time they could put bodges on old stock pcbs or you know, supply USERPORT cable as thats where 6526 is wired to. Original Kernal has no traces commodore ever tried to use hardware shift register, they simply left VIC20 bodge and didnt even try accommodating fixed 6526.
    - krige 8mo ago
      Memory a bit foggy on that but weren't c64 mainboard revisions almost exclusively to make them cheaper, not better?
      - rasz 8mo ago
        Successive revisions fixed hardware bugs and added functionality like 8-pin video port in place of 5-pin one.
pizza234 8mo ago
> There was a level of creativity back in those days that we seem to not have as much nowaydays. Now things seem to be based more on math and things like signing. Copy protections nowadays are actually extremely complex - just look at Denuvo and VMProtect. I presume that nowadays there are less copy protection schemes because producing a resilient one is too complex for small developer teams.

deleted 8mo ago

[deleted]