3 ms·

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 th

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 7mo 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 7mo 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 7mo 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 7mo ago
      Memory a bit foggy on that but weren't c64 mainboard revisions almost exclusively to make them cheaper, not better?
      - rasz 7mo ago
        Successive revisions fixed hardware bugs and added functionality like 8-pin video port in place of 5-pin one.
pizza234 7mo 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.
hagbard_c 7mo ago
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.
- Sesse__ 7mo ago
  > There are more errors in the text It seems most of it is AI-generated, without any real attempt at cleaning up errors.
- kenjackson 7mo ago
  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.
- zippothrowaway 7mo ago
  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. If this is the AI slop future, we're doomed.
  - time4tea 7mo ago
    Can confirm tape-to-tape worked 100%... it got a bit less reliable after copy-of-copy-of-copy though.

Two9A 7mo 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 7mo 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 7mo 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 7mo ago
    Memory a bit foggy on that but weren't c64 mainboard revisions almost exclusively to make them cheaper, not better?
    - rasz 7mo ago
      Successive revisions fixed hardware bugs and added functionality like 8-pin video port in place of 5-pin one.

pizza234 7mo 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.

hagbard_c 7mo ago

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.

Sesse__ 7mo ago
> There are more errors in the text It seems most of it is AI-generated, without any real attempt at cleaning up errors.
kenjackson 7mo ago
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.
zippothrowaway 7mo ago
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. If this is the AI slop future, we're doomed.
- time4tea 7mo ago
  Can confirm tape-to-tape worked 100%... it got a bit less reliable after copy-of-copy-of-copy though.