Sync issue - C64 (US NTSC with 6xxx chips)

[amerika13]

Hello!

I just got done installing this mod for my c64 US NTSC model and I am having an issue with sync. I get an image, but it flickers. Neither my test monitor nor my GBS-C scaler likes the output at all. I can see the bootup screen and I can type so I know the C64 is functioning.

Here is a quick video of the issue: https://youtu.be/D48D7ZBlFV0

I have a theory so I'll ask a couple of questions.

On my model, I had a POT on R27 that apparently controls the signal on the RF modulator. It was in the way of the board I needed to install below the VIC20 so I desoldered it, attached some conductors to it and mostly got it out of the way. I made sure that there were no bridges here. Do I possibly need to adjust or even remove this POT? And if I remove, will I need to bridge anything?

UPDATE: I removed the R27 POT entirely, and now the image is more stable but still has a lot of issues.

Picture of the install.

Thanks everyone!

[amerika13]

Before anybody wastes time, I think i already see my problem.

[amerika13]

Well, that was not it. I fixed that and the pin is making a proper connection now. However, I still have the rolling image/sync issue as described above :( I inspected all of the other pins to ensure they are connected and all was well.

[amerika13]

I tested Composite and Svideo out and I get a stable image (composite pictured).

[c0pperdragon]

I guess, your problem is caused by the clock generator circuit on your specific board. In some cases the clock signal is so uneven that the mod can not properly sync to it. There is a way to solve this issue which is nicely summarized at the bottom of this thread (with a video even): https://github.com/c0pperdragon/C64-Video-Enhancement/issues/53

The real problem here is that you may have to upgrade the firmware on the FPGA for which you need an actual programming device for this (the USB-Blaster). If you obtained your board from videogameperfection.com, it most probably has the version 2.6 of the firmware which can not yet provide the necessary clock signal.

Maybe your fist attempt could be to try to actually straighten out your clocking circuit. Re-installing the trimmer pot may have some effect. Specifically the signal on the VIC-II pin 22 is crucial here. If you possibly have an oscilloscope this would be of great help here.

[amerika13]

The board was built by @bodgit and he thinks it might be revision 2.9 or at least higher than revision 2.6. I believe I have a USB Blaster handy and if I don't then buying a knockoff one is pretty cheap.

I will review the thread and see what my options are. I do happen to have a scope that I acquired a few weeks ago but need to learn.

When you say trimmer pot @c0pperdragon, do you mean R27? I have tried with it in (I connected it via some wire conductors since it was in the way), and the rolling is worse. I pulled it and it's better but still not good. Should I put it back (picture below so that we are on the same page). Thank you for the troubleshooting steps and I'll see what I can do. Much appreciated!!

[c0pperdragon]

If you want to use the mod board to generate the pixel clock for an NTSC machine, you need firmware revision 2.10 . For a PAL machine this was supported earlier since firmware 2.7

I don't have a C64 with thise earlier style clock generation circuit, so I can only guess from the schematics, what R27 is doing. It seems it is needed to fine-tune the primary clock (14.31818 MHz for NTSC). With your oscilloscope you can check at which exact speed this clock is running. This can be directly probed at pin 21 of the VIC-II. Try to tune the R27 pot to hit the exact frequency.

When you already have the proper speed there, you should also check what is going on with the pixel clock on pin 22. This is generated from the primary clock with a pretty complicated PLL circuit and I suspect this very much to not keeping its speed but varying by a noticable amount. This would explain all the reports I have received concerning this issue. It would be very nice to finally get a confirmation of this.

[amerika13]

Thank you for the info! I had some time tonight and was starting out with getting my FW up to 2.10 and I ran into a snag. I'm using Quartus 21 Lite which came with the Max 10 package by default. I did download the extra package they showed on the page, but apparently it's not needed?

I got the USB Blaster driver installed and Quartus sees it and the ribbon is connected to the board. I click Add file and I select the 2.10.pof file I got from the GH releases page and then I click start. At this point it looks like it's working. However, it gets to 4% and stops and eventually times out and fails.

I am new to Quartus so there might be some setting that is not correct? I do have the board still hooked up in the c64 if that matters. I asked around and was told that wouldn't matter and all it needed was power from the c64. So hopefully that was accurate haha.

My goal is to see if this fix actually fixes my issue since it's a bit different than what I saw in the other closed issue and video. And then I can undo it and hook up my scope and get signal timings. It would be a good first project and possibly help some others out.

[c0pperdragon]

I just opened an issue thread firmware flashing, as this seems to become an issue recently: https://github.com/c0pperdragon/C64-Video-Enhancement/issues/80

Maybe share some screenshot of your programmer version so we can get the reason of this.

[amerika13]

I was able to get my firmware updated to latest using Quartus 18.1. It programmed and verified and went to 100%.

I was then able to check to make sure that I was no worse off and I got an output. It had issues with pixels shifting all over, but it wasn't rolling like crazy.

I then did a temp wiring of the pixel clock mod and now I get the normal blue start screen but the lines of text is now a big square of moving garbage.

[amerika13]

I made a couple of videos of what I am seeing in hopes that it sheds light on my issue. Without the pixel clock mod, I get an unstable screen/graphics. If I remove POT R27, the image gets a lot more stable, but I will still get unstable graphics. If I install the pixel clock mod, with or without POT R27, I will get a blue screen where the graphics are scrambling.

No Pixel Clock mod installed - https://www.youtube.com/watch?v=PpnNtDq_JnY

Pixel Clock mod installed - https://www.youtube.com/watch?v=wuYv4613QFA

[c0pperdragon]

Looking at your picture, it seems that you are feeding the clock signal into the wrong pin on the JTAG header. You need to feed this into pin 5.

I am sorry that this specific feature (NTSC clock generation) is so obscurely triggered, but I just did not have any free inputs, so I made pin 5 to accept this additional signal possibility (toggling).

[amerika13]

Ok, so for anybody in the future reading this, pin5 is marked as below. From the perspective of the image taken in the other thread, and the video, it looked like it was one pin further down (for me anyway).

I was on Pin 7 instead of 5. I am now on 5 and I have what appears to be a perfectly stable image. So that was my problem with that!

However, on to the next problem/question haha!!

[amerika13]

Ok, so i noticed this when I first tested the mod and I had an unstable image. The colors came through, but they were off. Very green tinted instead of the blue I was expecting. I just verified this by taking a picture of the Component mod that is actually more green IRL than the image conveys, and then another image of Composite out which is the darker blue I was expecting. I do not have Red and Blue swapped incorrectly or anything like that (I swapped them around just in case).

Is this expected?

Also, another oddity I've noticed is that both Composite out and Svideo out has interference now. I don't mind this as I won't be using them, but this unit never had interference before the mod install.

Component:

Composite:

[amerika13]

BTW, I confirmed that it was not the LCD's component input and I checked against my main setups CRT. It's still pretty green.

Update:

To give a better idea of the color issues, I grabbed a game I have old footage of (recorded via svideo) and ran it on the top TV and then compared my output from the C64. As you can see, it's extremely off.

[amerika13]

OK, fun story.

Early on when I was troubleshooting stuff, I swapped my TRRS connector from the one Bodgit had sent for the one I used on my NES component out mod. The reason behind this is the one Bodgit sent had Green and Red reversed so I would get no image. I figured I'd check my NES TRRS to see if it had the same issue, and it did not. I got an image as expected (at this point I could not tell the colors all that well). Also, I did swap around the connections to make sure it was not R and B hooked up backwards. That made the colors even worse with the NES component TRRS jack with the c64.

Fast forward to exactly now, I got it all working fine by switching back to the original TRRS jack. I got to wondering if the jack itself was actually the cause of my issues above. And sure enough, it was. The original jack Bodgit sent with backwards R & G works fine.

I still have an outstanding question about Composite and S-video interference and if that is expected or not. Again, I don't actually care, but somebody else with this unit type might.

[c0pperdragon]

I guess you are noticing some moving distortion of the color.

This is caused by the fact that the dot clock and the color clock are no longer in a harmonic relationship. The dot clock is now generated by the mod board and fed into the VIC over the extra wire. The color clock comes from the C64s clocking circuit as normal. Both have their independent oscillator which do not match perfectly so you are seeing a kind of drift in the signals. You could actually try to sync the orginal clock to the mod clock by tweaking R27. This should cause the relative drift to change speed. Maybe you find a position that is least annoying.

This problem affects only the analog output and only when you are using the extra clock-mod.

[amerika13]

To be clear, Component out via the new mod is crystal clear now. The image above has distortion, but that is caused by the camera.

It's only composite and s-video that has the interference that I was describing. And it was happening before I installed the pixel clock mod.

I can adjust the R27 POT to see if that makes any difference. Again, I personally don't have an issue with it as I would only ever use composite/svideo in the future to test with if needed, but somebody reading this in the future might.

Otherwise, I believe my issue is closed. Thank you very much @c0pperdragon, @bodgit and everyone else who chipped in. It's very much appreciated!