Sparkly Pixels (NTSC) and Horizontal Glitches (PAL)

[ikrananka]

I'm aware that others have reported these kind of issues and that investigations led to various possible solutions. However, I'm not clear as to what the current recommendation(s) are with regard to the issues that I'm currently experiencing.

• C64 Fat Breadbin with 250407 motherboard
• Custom VIC-II2 NTSC/PAL mod installed with the following VIC-II chips: - MOS 6567R8 (NTSC) with heatsink - CGS 6569R5 (PAL) with heatsink
• C64 Video Enhancment bought from videogameperfection.com. - Firmware updated to v2.9

NTSC When in NTSC mode the system looks great when first powered on - nice and clear and stable. However, after a few minutes the image starts to exhibit what I think has been described as sparkly pixels and this gets worse the longer it is on. It seems to reach a peak of awfulness and then a vertical bank of flashing blocks appears towards the left side of the screen. While the sparkling doesn't get any better or worse from this point, the flashing blocks come and go every few minutes.

Here's a video showing the problem across the entire screen:

https://youtu.be/Gwcb_9T_fMY

And another one showing a close up which shows individual pixels flashing on an off. Ignore the moire effect which is an artifact of my poor camera.

https://youtu.be/IfwMiD150iY

PAL When in PAL mode the image is stable for much longer than when in NTSC mode. However, after about 10 minutes it does start to exhibit some bad behaviour. In this case the sparkly pixels seem to be more like single pixel high horizontal glitches. These do get a little worse with time but at their worst they are much less awful than the sparkly pixels in NTSC mode.

Here's a video showing the PAL mode glitches:

https://youtu.be/kahJh_lod0g

[ikrananka]

Okay, after lots of reading of the issues that seem to be related to this I've decided to give the pixel clock mod a try. Before I do though I do have a couple of questions:

1. Is it critical to use a resistor that is exactly 100 ohm with the pixel clock mod? The only ones I have readily to hand are some 100 ohm resistors with a 10% tolerance that measure 99 ohm. I can't imagine that this only make any difference but just want to check beforehand.
2. Am I correct in assuming that it really doesn't matter if the pixel clock wire connects to the input of FB17 instead of the output? This is what @tyristori did in Issue #38 but again can't imagine that this makes any practical difference either way.

[c0pperdragon]

I see you already found the relevant issue thread already. I would have recommended the pixel clock mod anyway. But I am not sure how this works together with your VIC selectior board. Maybe there is something happening with the clock generator of this board that now causes issues with the component mod. I am also a bit curious on how you actually stacked this all together.

[ikrananka]

Here's the custom VIC-II2 board I created which allows your video adapter board to be no higher than the VIC-II chips:

And here it is installed (I've since added heat sinks to the VIC-II chips):

All of this, plus heat sinks, fits inside my fat breadbin with no issues. Not sure if this stack would also fit in a thin breadbin but I suspect it would as this mod is no taller than a normal VIC-II2 mod and Perifractic sells them for the later thin C64 breadbins as well.

[ikrananka]

Okay, I completed the pixel clock mod and was wondering what are good stress tests for stability. I've seen others mention some demos, are there any particular ones that can be recommended to try?

[ikrananka]

Hmmm. It would seem that the pixel clock mod has likely fixed the horizontal glitches when I'm in PAL mode as I left the system on for 10 minutes and saw no issues. I really still need to stress test this with some appropriate demos though so looking for suggestions.

However, when I switch to NTSC mode the screen has now shifted down and I get changing garbage in the active screen area. Here's a video of the problem:

https://youtu.be/_bmP3z4p6Q8

Here's a picture of my pixel clock mod before I installed the VIC-II2 board. Note that I completely removed the SN74LS629N oscillator and installed an unpopulated socket.

This motherboard was originally an NTSC board and I know that the circuitry around the clock and VIC-II is slightly different between NTSC made boards and PAL made boards. Might these slight differences be causing the problem? Here's a table I put together some time ago:

Note that the original NTSC clock crystal (Y1) was removed as part of the VIC-II2 mod and is in effect replaced by brand new crystals located on the mod board itself with the following frequencies:

NTSC : 14.31818 MHz PAL : 17.734475 MHz

[c0pperdragon]

My test of choice for PAL mode is the "EdgeOfDisgrace" demo, as it uses nearly any trick that were ever possible with the VIC-II. With its excessive use of sprites for all imaginable purposes this also pretty well tests the compatibility with sprite DMA.

When the mod runs without problems in PAL mode with the pixel clock mid, this hints on the original clock circuit creating a wonky signal ("original" from the VIC-II2 board, that is).

The pixel clock signal from the FPGA board defaults to the frequency needed for PAL (7.88200). This will then be fed into the VIC which creates the 0.98525 MHz system clock from it. This in turn goes back to the FPGA to drive the whole processing. Also, the FPGA checks this frequency to determine which type of system it is installed in and adjusts its behaviour accordingly. This is the reason that it does not work when you switch it to NTSC, as the pixel clock is still PAL (bypassing the whole clock circuit).

To make this whole setup to work you would also need a clean pixel clock compatible with NTSC (8.18MHz). Incidentially, the FPGA board would actually produce this clock frequency if it were somehow triggered to do so. This trigger is a detection of an an actualy NTSC CPU clock in its input. But this of course will not happen as long as the VIC is running with the PAL clock also.

Maybe I can modify the FPGA firmware to switch the default pixel clock output to NTSC triggered by some input pin. You could probably take the necessary mode selector signal from the U31 socket. But I have to see if I can re-purpose any existing pins on the FPGA board.

[c0pperdragon]

After second consideration, the best approuch for your setup is to actually tackle the real issue and get the clock generator straight. When you have an oscilloscope, you should be able to see that the pixel clock is very non-regular. This is an effect of how the MOS 8701 works and how it creates the pixel clock from the 4x subcarrierfrequency without using a PLL. There have been some projects to improve this matter, using proper PLL circuits, but I don't know if this would work when switching between PAL and NTSC. This one does something like that: https://www.youtube.com/watch?v=ipQD7fEKG38

[c0pperdragon]

Also I wanted to mention, that by feeding the clock output from the FPGA into the VIC in (as you tried already) you will not get any color on the composite/s-video output on the A/V connector.

[tyristori]

I use pixel clock mod even with my 250469 board that is very prone to crashing due to VSP bug.

The aforementioned EdgeOfDisgrace demo crashes every time without the pixel clock mod.

[c0pperdragon]

Yes, having a stable pixel clock seems also to cure the VSP bug. Getting this clock from my FPGA board is a kind of band-aid, but a proper solution would replace the MOS 8701 with modern circuity entirely. The part as described at https://github.com/desaster/c64-dodgypll nearly does it. For use with a VICII2 board it would only need a possibility to switch between NTSC and PAL triggered by an electric signal. I guess adding a single transistor could already do the trick. @desaster , do you think it feasable to make an easy-to use general MOS 8701 replacement? Ideally a plug-in replacement in a form factor to fit all main boards. I think there would be quite some users that would be happy just to get rid of the VSP bug.

[tyristori]

I've heard that the SRAM based memory replacements also cure the VSP bug.

[desaster]

I actually had an issue with my home-made PLL replacement, since the board was too large to fit alongside with the VIC-II adapter board.

However, in general it should work, but I'd probably recommend getting some of the commercially available boards. They also support NTSC & PAL afaik.

My github project exists mainly to make the information open source, and could use some improvements on the actual board design.

On Thu, Dec 17, 2020 at 12:32 PM c0pperdragon notifications@github.com wrote:

Yes, having a stable pixel clock seems also to cure the VSP bug. Getting this clock from my FPGA board is a kind of band-aid, but a proper solution would replace the MOS 8701 with modern circuity entirely. The part as described at https://github.com/desaster/c64-dodgypll nearly does it. For use with a VICII2 board it would only need a possibility to switch between NTSC and PAL triggered by an electric signal. I guess adding a single transistor could already do the trick. @desaster https://github.com/desaster , do you think it feasable to make an easy-to use general MOS 8701 replacement? Ideally a plug-in replacement in a form factor to fit all main boards. I think there would be quite some users that would be happy just to get rid of the VSP bug.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/c0pperdragon/C64-Video-Enhancement/issues/53#issuecomment-747354761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2FEK4UQESVADSFPLHEFLSVHM4DANCNFSM4U5DGFIQ .

[ikrananka]

My test of choice for PAL mode is the "EdgeOfDisgrace" demo, as it uses nearly any trick that were ever possible with the VIC-II. With its excessive use of sprites for all imaginable purposes this also pretty well tests the compatibility with sprite DMA.

Great - I'll give that a go later today and will report back. Am I right in thinking that this is a PAL only demo?

The pixel clock signal from the FPGA board defaults to the frequency needed for PAL (7.88200). This will then be fed into the VIC which creates the 0.98525 MHz system clock from it. This in turn goes back to the FPGA to drive the whole processing. Also, the FPGA checks this frequency to determine which type of system it is installed in and adjusts its behaviour accordingly. This is the reason that it does not work when you switch it to NTSC, as the pixel clock is still PAL (bypassing the whole clock circuit).

Thanks - that really helps me understand better what's going on.

To make this whole setup to work you would also need a clean pixel clock compatible with NTSC (8.18MHz). Incidentially, the FPGA board would actually produce this clock frequency if it were somehow triggered to do so. This trigger is a detection of an an actualy NTSC CPU clock in its input. But this of course will not happen as long as the VIC is running with the PAL clock also.

But the VIC-II2 PAL/NTSC mod board not only switches between a PAL VIC-II and an NTSC VIC-II but it also switches between the appropriate crystal oscillators. So, when the NTSC VIC-II is selected the crystal oscillator selected is one running at 14.31818 MHz. The mod also switches the motherboard NTSC/PAL jumpers appropriately. So, when the NTSC mode is selected this basically reverts the motherboard back to a stock NTSC and disconnects the PAL crystal oscillator. So, shouldn't this set the CPU clock to NTSC and trigger the FPGA to output an NTSC pixel clock?

Here's a schematic of the VIC-II2 mod that I redrew when designing my custom board in case this helps:

Red Board Schematic - wComponent v0.1.pdf

I have an oscilloscope so can probe any lines as necessary.

[ikrananka]

After second consideration, the best approuch for your setup is to actually tackle the real issue and get the clock generator straight. When you have an oscilloscope, you should be able to see that the pixel clock is very non-regular. This is an effect of how the MOS 8701 works and how it creates the pixel clock from the 4x subcarrierfrequency without using a PLL. There have been some projects to improve this matter, using proper PLL circuits, but I don't know if this would work when switching between PAL and NTSC. This one does something like that: https://www.youtube.com/watch?v=ipQD7fEKG38

But my board is the earlier 250407 which has the four chips in the clock circuitry rather than the single MOS 8701 in the later 250425 boards. Is there a modern replacement for the pixel clock generator on the 250407 boards?

[ikrananka]

Also I wanted to mention, that by feeding the clock output from the FPGA into the VIC in (as you tried already) you will not get any color on the composite/s-video output on the A/V connector.

Yes, that's no problem - I have no desire to use the composite/s-video output. The analog outputs of both of my VIC-II chips are rather poor hence my wanting to use your video mod. The NTSC one has awful jail bars that luma fix failed to make a dent in, and the PAL once has checkerboarding with red and green fringing around characters. With your mod these issues are gone (other than the NTSC pixel clock problem).

[c0pperdragon]

Ah, yes. I didn't realize that your board has the old-style clock circuit. This is indeed extremely bad, even worse than the already pretty awful MOS 8701. So you really need a better clock. The only possibility I see now is indeed to get it from the FPGA.
Actually it would be quite simple to produce NTSC clock or PAL clock depending on some input pin. But I do not have any input pins left. I already re-purposed 2 pins from the JTAG header to trigger compatibiltiy with the 656756A VIC-II and to turn on a specific high-contrast palette for use with the RGBtoHDMI upscaler.

Annoyingly, the FPGA has plenty of pins left, but they are not exposed anywhere on the board. You would actually have to solder a wire to one of the 0.5mm pins! Also I don't want to modify the firmware in some incompatible way that would break other user's installation. But maybe I have no other idea than to create a modified firmware just for your use case. For this, the FPGA would probably need access to a jumper connection, so to speak. As the VICII2 board normally sets the mode input of the MOS 8701, this should be possible. Specifically I would need some line that is set to GND in one mode and left open (so the FPGA boad can pull it to high) in the other mode. Having this, I could make a custom firmware that expects this signal on the JTAG pin 5 to determine the initial pixel clock frequency.

[ikrananka]

Ah yes, I see now. This is kind of a Catch 22 situation with the FPGA using the system clock derived from the pixel clock to determine which type of system it is installed in, but using the pixel clock mod forces this to always be PAL as that is what is put out by default from the FPGA. I'm a little slow on the uptake here but am beginning to understand. Thanks for your patience.

So, what is needed is a custom alternative way of telling the FPGA which type of system it is installed in and this is where your jumper concept is coming from. Could this be derived from the position of the motherboard NTSC/PAL jumper? This would be ideal as the VIC-II2 mod already includes a relay switch that changes that jumper setting. So perhaps installing a wire between FPGA pin 5 and jumper point E1?

E1 is already pulled high (+Vc) when in PAL mode and pulled down to GND when in NTSC mode. Could this be what is detected by the FPGA, the voltage level of that pin?:

[c0pperdragon]

Something like this would be needed, but it is still not ideal, because the FPGA input pins can only work with 3.3 and would possibly be damaged if directly feeding 5V into them. That's way I asked about a way to have a signal that is either grounded or left open, so the FPGA can use its pull-up resistors to bring the voltage to 3.3 volts. These pull-ups are already present on pin 5 of the JTAG inputs. I don't know how your VICII2 interacts with your mainboard, but I guess you could somehow manage to make it behave in the required way. Specifically if you can make it so that for PAL mode the JTAG pin 5 gets grounded, and for NTSC mode, the pins is left open, then I guess I can make the firmware in a way to be still compatible with previous use cases (mainly the 656756A setup).

[c0pperdragon]

Oh, no,, this does not work either. This would break compatibility with PAL setups that use the pixel-clock mode. I need another solution still to make do with the limited amount of input pins (I really should have left more room for expansion here).

[ikrananka]

Understood. The VIC-II2 mod includes a relay switch that connects E1 to either E2 (PAL) or E3 (NTSC). If I were to disconnect the VIC-II2 mod board from E2 then when in PAL mode E1 would be left open and in NTSC mode E1 would be grounded. Would that work?

Seeing as I have now removed U31 and bypassed the rest of the clock circuitry with the pixel clock mod, does that now mean that the Y1 crystal oscillator is now redundant and not needed?

[ikrananka]

Oh, no,, this does not work either. This would break compatibility with PAL setups that use the pixel-clock mode. I need another solution still to make do with the limited amount of input pins (I really should have left more room for expansion here).

Nooooooooooo :(

[c0pperdragon]

Maybe this could work (a totally crazy hack now): Set up your circuit so that the JTAG pin 5 is either left open (for PAL) or connected to the pixel clock output from the FPGA (for NTSC mode). The FPGA can easily detect such a situation and switch over to NTSC frequencies.
Yes, I think this should actually work.

About your previous question: The Y1 is not used any longer as is the rest of the clock circuit.

[ikrananka]

Maybe this could work (a totally crazy hack now): Set up your circuit so that the JTAG pin 5 is either left open (for PAL) or connected to the pixel clock output from the FPGA (for NTSC mode). The FPGA can easily detect such a situation and switch over to NTSC frequencies. Yes, I think this should actually work.

About your previous question: The Y1 is not used any longer as is the rest of the clock circuit.

Thanks - that's what I thought about Y1. So the PAL/NTSC motherboard jumpers are also now redundant as they're just an input to the U30 part of the rest of the clock circuit. So this allows me to entirely remove one of the VIC-II2 mod relay switches (associated with Y1) and one half of another (associated with the PAL/NTSC jumper) which can now be used to provide the input to JTAG pin 5 (open = PAL : pixel clock = NTSC).

So, do you think that this "hack" will work with the current firmware, or will custom firmware still be required?

Is there a convenient spot on the top of the FPGA mod where I can solder a wire to JTAG pin 5? Or would I be better simply using a wire with a slide on connector that I can then easily remove if I ever want to flash the firmware?

BTW - thank you so much for all your help with this. Personally, I think that it will be awesome to be able to switch between PAL and NTSC modes with your video mod.

[c0pperdragon]

I definitely have to modify the firmware. But I guess I can make it in a way to still keep it compatible with any existing installations. So it is possible for anyone to update to this firmwre without ill effects.

I would recommend something detachable for the wiring to pin 5.

But I need to make the firmware changes and see if it still fits in the the FPGA, because it is already about 99% full or so. Will let you know soon.

[ikrananka]

But I need to make the firmware changes and see if it still fits in the the FPGA, because it is already about 99% full or so. Will let you know soon.

Fantastic - thank you 👍

[c0pperdragon]

Abracadabra. Please give the 2.10beta2 firmware a try: https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware

If this works, it will become new 2.10 release.

[ikrananka]

Abracadabra. Please give the 2.10beta2 firmware a try: https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware

If this works, it will become new 2.10 release.

Wow - that was quick 👍 I'll try and do the firmware update and hack tomorrow, if not it will be over the weekend. I'll let you know how I get on.

[c0pperdragon]

I have changed the firmeware a bit more to now also support the pixel clock mod in conjunction with a 656756A chip. For you this should be the same, but please use the firmware 2_10_beta3 instead of the beta2 so I can confidently release this.

[ikrananka]

Absolutely awesome - it works 👍 👍 👍 Thank you so much for all of you help and for being so incredibly quick with the beta firmware. I've only hooked up JTAG pin 5 with a manual detachable wire for now, but seeing as it works I'll now revise my PCB design so that the JTAG pin 5 signal passes through one of the relay switches on my PCB and so automatically sets it open or to the pixel clock.

In PAL mode I've put the machine through its paces with the Edge of Disgrace demo and also the Lunatico demo and it has performed flawlessly. Unfortunately, neither of these demos work on an NTSC system so I tried a bunch of older (less demanding) NTSC demos I had and they all worked perfectly. No signs of ANY glitches whatsoever. The quality of the image is very close to the HDMI output of my Ultimate 64 which is a huge testament to how good your video mod is.

Again, thank you for your incredible help with this. Once I get the a new PCB designed and installed I'll let you know and will post some pictures here.

Oh, one question I do have. Is the reason for losing colour on the composite/s-video output because there is now no colour clock having removed U31?

[c0pperdragon]

The VIC-II needs the NTSC/PAL subcarrier frequency input in order to produce the correct color signal. In your board, this signal was produced by U31, as you have guessed. I think you could restore the functionality of U31 in parts to at least produce the subcarrier, using the Y1. But this may collide with your plans to rework the VICII2 board.
Anyway with the subcarrier frequency generated independently of the pixel clock (which now comes from the FPGA), your analog color output will then have the dreaded dot crawl effect that plagues the ZX Spectrum, because both clocks are no longer in a harmonic relationship. So this is probably of no use anyway.

[c0pperdragon]

About your PCB: Do you really plan to make a new PCB just for this small change? Maybe you can just rewire some things on your C64 main board to achieve the same effect?

[Obiwantje]

@ikrananka any chance you can put your PCB KiCAD/Gerbers up for those of us interesting in building the same?

[c0pperdragon]

I have another idea: When you already change your PCB, why don't you fix the unstable clock issue right there and then? When integrating a proper clock generator (as being used by https://github.com/desaster/c64-dodgypll) you can make a super-convenient VICII2 board that also fixes the clocking issue on its own, even if not having the component video mod.

Installation of this will also become very easy as you will not have to modify the C64 board in any way. Just plug in the VICII2 board that will ignore the incomming clock signal to substitute it with its own. And you can probably also leave away at least one of the relais (maybe two, but I am not sure here).

[c0pperdragon]

And as this then will be the most proper solution possible, color will also work on the analog video ports.

[c0pperdragon]

For the fastest, and cheapest solution using your current VICII2 PCB, you could do the following thing:

1. Remove both quarzs from the VICII2 board and insert a wire bridge instead of the NTSC quarz (leave the PAL quarz open).
2. On the C64 main board connect the FPGA's pixel clock signal to one side of the quarz connector (best on the side where C70 is located). Connect the other side of the quarz connector to pin 5 of the FPGA JTAG header (maybe with just a detachable male-to-female jumper link)

[c0pperdragon]

You could make the installation extra "funny" by doing this instead of the above step 2:

2. Put a wire bridge between pin 9 and pin 12 of the U31 socket (thus routing the FPGA's pixel clock to the quarz connector)
3. Connect the other side of the quarz connector (where C70 is) to the JTAG pin 5 (solder the wire on side, have a female connector on the other)

[ikrananka]

@c0pperdragon Thank you for all of your suggestions. Lots to think about and so likely a project I'll work on over the period between Christmas and New Year. I would like to make the design freely available to others hence my desire to redesign the PCB and also to test it in my C64.

@Obiwantje Yes, I do plan on making the files freely available after I have completed the redesign and testing.

[ikrananka]

I have another idea: When you already change your PCB, why don't you fix the unstable clock issue right there and then? When integrating a proper clock generator (as being used by https://github.com/desaster/c64-dodgypll) you can make a super-convenient VICII2 board that also fixes the clocking issue on its own, even if not having the component video mod.

I've just been taking a look at that PLL 8701 replacement. Unfortunately, in the video, there's no mention if the clock signal is cleaner and if so what it now looks like. Also the setting of PAL and NTSC seems to be a manual affair. However, over on the Hey Birt! channel Jeff has taken that design and improved on it as well as explicitly comparing the pixel clock between the original 8701 and his replacement. His one also autodetects if the system is PAL or NTSC so that's handy. Would be great if you could take a look at the pixel clock characteristics he shows and comment if this would be suitable for use with the component video mod to avoid the sparkly pixels / horizontal glitches on those boards that use an 8701?

https://youtu.be/e5o8c656j3Q?t=1418

[c0pperdragon]

Yes, the clock signal looks perfect. Far better than what the 8701 or your current circuit would produce (of course this is the whole point here).

Unluckily for you, this replacement board will not match your C64, because you have one of the very first board that do the clock generation differently. So you could follow one of my suggestions to modify your own PCB to include the clock circuit as well. But be aware that the PLL chip is quite a tiny part (0,65mm pin pitch). It actually takes some practive to solder this.

[c0pperdragon]

Also with the availability of this brilliant 8701 replacment board, there is basically no need for a different solution for the vast majority of use cases. So there would be not much benefit for other users in include the clock IC on your board design.

The only real benefit for you specifically (when using the PLL chip instead of using the clock signal from the FPGA board) is that the analog video signal will carry color.

[ikrananka]

Yeah. I was just thinking about if this was good idea or not and I have to agree with you that with the availability of the 8701 replacement there is negligible benefit of including this on my board. I guess with the 250407 motherboards, with the old clock circuits, the benefit of having an 8701 equivalent on my board would be advantageous. However this adds cost, size and complexity to my board when an easy alternative already exists, i.e. your pixel clock from the FPGA. As the only real benefit of putting a clock circuit on my board is to add the colour clock signal back in, I just don't see this as sufficient justification. From my own personal perspective I'm really not interested in the original analog outputs. Both of my VIC-IIs produce horrible analog images (at least on LED monitors) and I will never use them. After all, that's why I wanted to install your component mod in the first place.

Now that said, I wonder if there's a simple way to take your pixel clock and generate a colour clock from it??? Just thinking aloud and not really going to pursue it unless it were simple to do.

So, at the moment I'm going to simply focus on revising my board to incorporate the pixel clock PAL/NTSC switching that I've currently got manually hacked together.

BTW - have you seen the prototype VIC-II FPGA prototype that Randi Rossi is developing https://youtu.be/HzgjMjqpOC8? Looks like this has the potential to not only provide a VIC-II FPGA replacement, but incorporates it's own PAL and NTSC clock circuits and is software switchable between PAL and NTSC. Plus with a breakout board it also has HDMI output. The future is quite exciting!!!!!

[c0pperdragon]

This VIC-II replacement project looks pretty nice. I am curious if it may eventually come to a stage where it is actually usable and what the price would be. Specifically generating a proper standard-conform HDMI signal is not easy.

About your specific use case on hand: Generating the color clock (4x PAL/NTSC subcarrier frequency) from the pixel clock is pretty difficult and basically impossible without a proper PLL chip. But if you are OK with basically any color signal, you could still use all the clock circuitry in your machine to just create the color clock, and take the pixel clock from the FPGA. This would lead to the "dot crawl" effect that is known from the ZX Sectrum.

For that, leave your PCB completely unchanged (thus it will connect the correct quartz to the clocking circuit) and do some very special rewiring on the C64 main board:

1. Leave the pixel clock wire from the FPGA to the main board exactly as it is.
2. Re-insert the U31 chip, but lift pin 7 so it does not connect to the socket (this is the dot clock output which is no longer used)
3. Remove the E2 female header (which you have previously installed to connect to the VICII2 board)
4. Cut the trace from E3 to the GND and connect E3 to the pin 5 of the FPGA JTAG header instead.
5. Connect the pixel clock from the FPGA to E1 (there is convenient via near the "PAL" marking)

This now should either leave JTAG pin 5 open (in case of PAL) or connected to the pixel clock (for NTSC).

[c0pperdragon]

One additional remark: The pixel clock generator on the C64 board will now go completely nuts because the PAL/NTSC input is suddenly carrying a clock signal. But as you don't need it anyway that should be no problem.

[c0pperdragon]

I just found a problem with the solution which you need to fix with one additional step:

6. Cut the trace between E1 and the other ICs on the C64 board. As these ICs are LS logic, they will draw quite some current on their input pins, so they will probably overcome the weak pull-up on the JTAG input, causing the FPGA to permanently run in the wrong mode.

[ikrananka]

Happy New Year :)

Now that the holidays are over, time to get back to this project. I've had a good think about your suggested modifications but am just not happy about a solution that requires traces to be cut. I'm definitely going to do some redesign of my PCB so I'm now thinking about the following:

1. Remove FB17.
2. Move the pixel clock wire from the FPGA to the main board on the opposite side of where FB17 was (this now allows me to reinstall U31 while still using your FPGA for the pixel clock).
3. Reinstall U31.
4. Keep the PAL/NTSC crystals on the VIC-II2 board as-is and associated relay (these will feed U31 to generate the appropriate colour clock as per the original VIC-II2 design).
5. Remove the PAL/NTSC jumper parts of the VIC-II2 design (E1,E2,E3 + relay) as these are only used on the pixel clock generation side of the circuit and are now redundant.
6. Connect JTAG pin 5 to one of the relays on the VIC-II2 that will either leave it open or connect it to the pixel clock.

I had a thought regarding the "dot crawl" on the original video output. Might adjusting R27 be able to compensate for that to get the pixel : clock frequency multiplier spot on, or is the dot crawl more a function of the two frequencies being out of phase (which I believe adjusting R27 wouldn't help with)?

[c0pperdragon]

I guess your modifications give the same effect as my proposals. Maybe no need to redesign the PCB, but you can get away with botching wires to existing solder contacts and by cutting away some connector pins.

The dot crawl is always present when the pixel clock is not in a harmonic relation with the color clock. In your case you take the pixel from from the FPGA and the color clock is generated in some way from its own independent crystal. So the phases will always drift apart in some way.

[ikrananka]

I want to redesign the PCB anyway as I believe some others may also want to do your mod with my VIC-II2 board.

One thing I'm curious about though is how likely it is that after installing your component video modification users will experience the sparkly pixels/horizontal glitches that then needs the pixel clock mod to fix. I'm just curious to know if this is something that the majority are likely to experience or is it something rarer than that?

[c0pperdragon]

I thing this may be a pretty common problem with this specific clock generator circuitry. Especially when using FPGA firmware version prior to 2.9. From then on the firmware tolerates the bad clock circuit a bit better, but it may still not be good enough.

[aaronnewcomb]

So, for those of us who have a 250407 board (NTSC) here are the instructions to eliminate the horizontal glitches if I understand correctly:

1. Upgrade the firmware to 2.10 or later
2. Cut the right leg of FB17 on the C64 and lift it a bit or just remove it
3. Attach a 100 ohm resistor to the right side of R24 (as you look at it from the front after installation) on the FPGA board
4. Connect the other side of the resistor to both pin 5 on the JTAG pin header of the FPGA board and the pad on the C64 where you cut FB17

Here is what mine looks like and it is working perfectly now.

[c0pperdragon]

Yes, you did it prefectly right
The main reason for this strange way of wiring up pin 5 of the JTAG header is the lack of additional input pins into the FPGA. So I had to make pin 5 accept 3 different settings: low / high / toggling. As it turns out now, this works pretty fine.