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.
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
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.
> 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.
That part about fast loaders bypassing the serial bus and using the user port is incomplete at best, incorrect in practice. Some early fast loaders did this but most others just used the existing serial bus connection with their own routines, bypassing the buggy kernal drivers on the drive and host side.
There are more errors in the text, e.g "the 1541 used a single-density (narrow) read/write head". No, that describes an 80-track head while the 1541 used a wider 40-track head. I stopped reading here because of these errors.
OK, someone needs to write up an accurate version. This is a fascinating topic, especially for those of us where C64 was one of our first computers. The Vic20 was my first-- I sold my computer games door-to-door on cassette... "sold" is maybe a strong word here. I sold one total.
The tape copy protection article is also terrible with nonsense like this "A copy of a Novaload tape made on a HiFi deck produced a normal-speed recording with the correct audio signal but which, when loaded on a C64, produced garbage — because the Kernal's standard tape decoder couldn't interpret the turbo encoding"
Thousands of kids in the playground with access to a tape-to-tape deck (which made Alan Sugar his fortune for Amstrad) would disagree. And the reason given is just plain wrong.
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!!
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.
reply