C64 compatibility

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
Don't Panic. Please wash hands.
  • My apologies, I expected to find an answer online but I haven't been able to.


    Although the C64 was my primary computer from 1982 to 1990, and still my favorite of all time, I never got into the hardware specifics. Can someone clarify the difference between a "64 -cycle" and a "65-cycle" C64? I found one forum that said it was a difference in the VIC-II chips, and that "6567R8 and newer, like the 8562" would work.


    Is that accurate? Are there breadbin C64s (pre-C64C) that would work with the TC V2?


    Thanks

  • 64 cycle (6567R56A) VICII was the first VICII that was released in the US (so its NTSC). This type of VICII is kind of rare, and it will cause problems with many C64 games, it has the "sparkle" problem, and perhaps other issues. If you ever stumble about this type of VICII, store it at a safe place, don't use it :) Only the first batch of C64s in the US had these, i think.


    All other (NTSC) VICII that came after that are 65 cycle, so yes, also classic breadbin style C64s (most of them) have them.


    As for compatibility with the Chameleon, the 64 cycle version is NOT supported (we don't even have one of these) - but as said, this is no problem in practise, as most (NTSC) C64s you will find are 65 cycle anyway.

  • 64 cycle (6567R56A) VICII was the first VICII that was released in the US (so its NTSC). This type of VICII is kind of rare, and it will cause problems with many C64 games, it has the "sparkle" problem, [...]

    It's not the VIC-II:


    Sparkle was widely attributed to bugs in the video chip that was the heart of the system, but in fact it was caused by a ROM chip of which 3 million were in service with no problems in other types of system, including the hit arcade video game Asteroids. Commodore engineers themselves first looked for the problem in the video chip. It took them three weeks to spot the ROM chip as the source of the defect, Charpentier said. "The problem was a random event - it didn't happen all the time. We thought the video chip was for some reason seeing wrong data. We didn't even suspect it could be the ROM. Finally we put the logic analyser on it and tracked it down." The ROM, which Charpentier and his group has designed years earlier, had a special precharging circuit to make it run faster, but the circuit made it sensitive to spurious signals. The video circuitry and the 6510 microprocessor alternated in controlling the system bus, and when control passed from one to the other, voltage spikes were sometimes generated.


    "It just happened that we hit the exact timing," Charpentier said. "If the spike had been a few nanoseconds shorter or longer, it wouldn't have been a problem. The spike was just wide enough that the ROM saw it as a valid address. It would ignore the next address request and give the video chip wrong data." Since the ROM contained the C64 character set, the screen display would be littered with random slices of characters.


    According to Nelson of Epyx, "This confetti interference-looking stuff on the screen, glowingly referred to as sparkle, has an extremely un-nice property: it causes hardware collisions - the sprites believe it really exists." Since the sparkle was causes by inappropriate data few to the video chip, it triggered the circuitry responsible for checking whether the movable display objects - sprites - were overlaying background objects on the screen. So software that depended on collision sensing to control the movement of objects on the screen would go berserk when confronted by sparkle.

  • Thanks for this quote! It indeed confirms that the VIC is part of the problem, as it's the timing master in the C64. If it hands over the bus at a slightly different time (which later revisions probably do), the character ROM will work fine in the same setup, hence the urban legend "VIC has sparkle problem".


    The text even implies a workaround and an auto-detect: You can detect it with sprite collisions that shouldn't be there, and you can work around it by using a video bank without the character ROM (copy character ROM to RAM wil hide the problem).