C64-Video-Enhancement
C64-Video-Enhancement copied to clipboard
c0pperdragon
Sparkly Pixels (NTSC) and Horizontal Glitches (PAL)
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:
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.
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:
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:
- 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.
- 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.
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.
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.
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?
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
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.
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
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.
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.
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.
I've heard that the SRAM based memory replacements also cure the VSP bug.
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 [email protected] 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 .
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.
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?
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).
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.
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?:
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).
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).
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?
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 :(
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.
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.
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.
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 👍
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.
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.
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.
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?
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.