alt Hacker NewsSo 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.
Replies
> 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.
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