NTSC Video Issue After C64R MK2 is Powered On For Extended Time

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.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Five hours of PAL VIC-II 8565R2 later, I feel pretty confident that this PLL instability or whatever is only happening with NTSC VIC-II chips and it does not appear to be related to power supply.

  • Hi

    I'm having the same issue, after about 45 minutes of usage, the image on the screen turns monochrome and after about one and a half hours later, I stop getting feedback all together (screen freezes). I know that the system still runs because I am able to hear sound on my speakers.

    The issue comes up much sooner if I just reset the machine (both on epyx fastload reloaded cartridge and dedicated power switch) after the issue occurred for the first time. I have to wait a longer period of time before the image output is again stable for longer periods of time.

    I have mainly been playing games on the system, it'sva long list with which I'm not going to bother anyone.

    At the moment I have a NTSC VIC-II connected to an active S-Video to VGA converter which is then connected to a VGA LCD.

    I have a PAL VIC-II as well but the image on the LCD flickers when I use it, I suppose it has to do with the 60Hz refresh rate of the LCD and the 50Hz output of the PAL VIC-II. I have not tested if the monochrome image or freeze issues occur with the PAL VIC-II though, the flickering of the screen doesn't make for a enjoyable experience with the machine.

    Further I am using your official power adapter, an original breadbin keyboard and Pixelwizard c64c case, the chips themselves on the board are either new or new old stock, I can provide a list of these if required.

    Finally, I do have a theory about why this issue happens: the chip overheats somehow. That said, it does not happen with the same chip on an original breadbin C64 board. I swapped the VIC-II on that one and ran some demo for more than four hours, no monochrome image, no freeze. I even put the breadbin board in the same Pixelwizard c64c case and ran the test again, same result. This, according to me, means that the C64R-MK2 would be at fault for the aforementioned overheating problem.


    Sorry for the long and explicit message but I thought that a deeper description of the issue and debugging steps taken would serve better to diagnose the problem.


    Thank you and have a nice day,

    Ralph

  • Update

    Since my last (and very long) post, I've installed heatsinks on the VIC-II as well as on the CPU. These are small aluminum units with a height of 5mm. Sadly the issue persists, after about 45 minutes the display image turns monochrome. I've exchanged the display as well, no effect either


    Ralph

  • The voltage appears OK, so the next step would be to measure ripple. Maybe a friend around who has an oscilloscope?


    absolute512: While temperature is most likely an influencing parameter, it's certainly not the temperature of the VIC-II chip, but something around the PLL on position U23, about "north-east" of the Xilinx chip. My current idea is to move the NTSC operation into a slightly different VCO range. Yet another thing on my long todo-list...

  • While I don't have a C64RMK2 on the dev desk, you could just place your finger on the chip and see if the wiggle goes away.


    I believe it'll be required to either exchange one of the resistors around that chip, or (if I'm lucky) just to add one on top. I need to work that out - I have a rather long list of stuff that I need to look into, and I had almost no time to work on any developments during the past five weeks. This will change now, as my other business doesn't require that much attention any more.

  • The voltage appears OK, so the next step would be to measure ripple. Maybe a friend around who has an oscilloscope?

    I asked a friend with an oscilloscope and he basically told me he does not do unpaid development work for other people's projects.


    Jens, are you suggesting that the ripple from the power supply is causing this behavior? Because there are a number of people in this thread including most recently @absolute512 using the official power supply and reporting the same kind of problems with NTSC VIC-II chips.

  • A quick ripple measurement on the supply voltage is not exactly "development work". The person could have just said "no". Give me a few days until I have finished work on Indivision ECS V2, then I'll turn to this NTSC issue, again (yes, I've tried to reproduce it twice already, failed, but I'll give it another try).

  • A quick ripple measurement on the supply voltage is not exactly "development work". The person could have just said "no". Give me a few days until I have finished work on Indivision ECS V2, then I'll turn to this NTSC issue, again (yes, I've tried to reproduce it twice already, failed, but I'll give it another try).

    Hi Jens, I'm only repeating what he said to me. I ordered your official power supply just now, however. So we can see if that makes a difference. Looking forward to seeing what you determine. Thanks!

  • Hello Jens, I received the official Commodore power supply in the mail and tested it again with an NTSC VIC-II in my Commodore 64 Reloaded mk II and had the exact same problem after several hours. I took some video again:


    https://www.youtube.com/watch?v=hF4iDUFw7XY

    Just to be thorough, ever since I posted that video 5 hours ago, I have been running the same C64 Reloaded mk2 machine with the PAL VIC-II in it and have had no problems at all. So I can confirm it's definitely just the NTSC chip still.

  • With the NTSC chip, the PLL will run at a different frequency - a higher one, which may get instable at higher temperatures. I'll do a few measurements to see if a simple fix will take the PLL into a different working range.

  • I could purchase some sort of heatsink, I don't mind. I'm programming on the device during the weekends and it's really annoying to have to shut down the device every so often and wait for it to cool off.

    Which chips would have to be cooled? Just the PLL or some of the other chips around it as well?

    Thanks

  • Finally had the time to do measurements; I've put the C64RMK2 on the dev desk on friday when everyone left here and left it sitting in a closed case, running since I've left the office. I still don't have the same wiggle here, but just a stable picture. So now I measured the VCO control voltage on the PLL, which is abount 3.6V on NTSC and about 2.5V on PAL. While this is perfect for PAL, it may get a little high for NTSC operation, given that components have tolerances in the field.


    So I've carefully moved the center frequency of the VCO circuit by reducing a resistor value. The resistor on question is R32, near the PLL chip U23. If you want to try this modification, you will NOT need to remove this resistor, but merely add a 100k resistor in parallel. Putting that high value in parallel will reduce the overall resistance from 3.3k to about 3.2k, and this will result in the VCO control voltage to drop to 3.2V, which gives more headroom for regulation and component tolerances.

    Note: The resulting 3.2k ohms and the VCO control voltage of 3.2V for NTSC is just a coincidence. There is a correlation, but no coherence or even identity.


    For PAL operation, this mod will result in reduction of the control voltage to about 2.0V, which is well in the safe operating range of the chip. If you're interested in measuring the actual control voltage on your board, please use a high-impedance probe between GND and pin#9 (bottom-right pin) of U23.


    So while I still did not reproduce the issue here, I am very confident that this will bring all PLLs in the field into a stable operating range over all temperatures. As usual: Don't change anything on your board unless it's not working properly (aka "never change a running system"). Please report back if this resolves your issues.

  • Hi Jens, I don't have the resources or skill to do this kind of modification. A local technician has offered to do the work for $40. I mean we are essentially having to pay to correct a flaw in the original design. Assuming this works, is this something that is going to be corrected in future production runs of the motherboard?

  • $40 is outrageous for a 20-second modification. It's not like he's responsible for the result. I'm willing to pay him $15 is he writes a proper invoice (for example through PayPal), and give you another bit of money to do the driving. If he refuses, we'll just wait for tomxp411 to come back with his result.


    Assuming this works, is this something that is going to be corrected in future production runs of the motherboard?

    We may do the mod to the boards that we still have in stock, yes. However, this requires more testing, also on PAL.

  • Jens, is there any update to this issue? I purchased MK2 a while back, but had the same issue and ended up selling it to someone that used it for PAL exclusively. I would like to order the board again, but need NTSC working properly...