Sparkly pixels

[IanSB]

User aknightin has reported on the stardot forum an issue with sparkly pixels when used with RGBtoHDMI scaler which get worse as the C64 warms up:

Despite the occasional offset issue I get a rock solid picture for the first few minutes and then some sparkly pixels that get gradually worse the longer the system is left running.

He is using a 6569R1 and this may just be a heatsink issue but I understand the other possibility is that the interface doesn't phase lock it's sample clock with the 1Mhz clock and that can result in uneven pixel sizes for every eighth pixel.

RGBtoHDMI uses a sample clock which is 8x the pixel clock and is phase locked to Hsync. During initial setup an auto calibration is run to determine which of the 8 sample points within the pixels produces the best results and the calibration info looks like this:

As you can see from the above sample points 5 and 6 have errors as that is probably the transition point between pixels so sample points 1 or 2 would be the best option for reliable sampling. This should cope with some un-evenness in every 8 pixel group as it will result in some more sample points with errors but there will likely still be a few points with zero errors unless the unevenness is severe.

[c0pperdragon]

To best test the hypothesis that there is a significant difference in output pixel width, you could use an oscilloscope and check which video signal a regular on-off pattern would produce. Using the regular palette, just write a series of " letters (quotation marks) in white on the C64 screen and probe the Y signal. Being the brightest color it is easy to find with the trigger, The pattern will actually alternate every two pixels, but you should still notice if any one pixel has a significantly different length compared to previous seven.

[c0pperdragon]

Nominally a C64 pixel should have duration of 126.87 nanoseconds. My FPGA internal clock only allows me to emmit intermediate pixel widths of 126,98 ns. So with a perfectly accurate C64 clock, every 8th pixel would be shortened to 126.1 ms. This is surely good enough to find a good middle position for any digitizing purpose.

But the question is of course which clock the C64 really produces, as this will change the calculation.

[IanSB]

I received a 6569R5 and that has similar issues that aknightin has seen with the R1:

I tried the fix suggested in https://github.com/c0pperdragon/C64-Video-Enhancement/issues/36 but that made it worse. However putting a small capacitor between pins 20 and 21 did fix it. I am currently using 100pF but will be experimenting further. This seems to be an issue with boards that use the discrete clock circuit instead of an 8701 (Mine is ASSY No.250407 REV A).

[c0pperdragon]

The discrete clock circuit really seems to be

[c0pperdragon]

[c0pperdragon]

...the common factor. I have a vague idea what may happen, but I really need some hard facts. Co

[c0pperdragon]

...ould you do the requested pixel time measurement? I would need precise times for a series of at least 10 color transitions.

[IanSB]

Using the regular palette, just write a series of " letters (quotation marks) in white on the C64 screen and probe the Y signal.

Ok I did that and measured the successive double pixel widths as follows: 256, 254, 251, 255, 256, 253, 253, 253, 256, 252, 253, 255, 257, 253, 253, 253, 257, 252 (all ns)

Also aknightin has confirmed that he is seeing the same problem as I do with the R5 chip which is actually one pixel shift of the whole line like my example above and not sparkly pixels as he originally indicated. Also his problem is fixed with 100pF across pins 20 & 21 as well.

[c0pperdragon]

So this measurement show a very good PAL signal with pretty perfect timing. But was this actually in the situation where the computer is having the startup-problem? Because I am especially interrested in the faulty conditionl

I really want to get to the bottom of the real problem, because others may have the same issue as well. Just fitting in the capacitor as a miracle fix is a bit unsatisfying. The orignal problem where this capacitor really makes sense, is when the clock signal to the FPGA board has substantial jitter (pin 20 on the ribbon cable).

Sorry for all this trouble...

[IanSB]

Ok here is one startup problem, I am actually getting "sparkly" pixels (pixels flickering on/off due to mis-sampling in RGBtoHDMI) and this shows the following with the """"""""" test.

The double pixel cycles are alternating at approx 244ns and 223ns

I can't actually get it to left shift at the moment, even with 2.6 firmware but the above effect is also stable, power off/on and it goes away or comes back so probably the same thing.

Edit: For comparison, here is normal operation at same scale:

[c0pperdragon]

Wow! This measurement is phantastic! It clearly shows that the machine runs with a CPU clock of about 0.985 MHz, which is perfectly normal for a PAL machine. But the clock subdivider is set to about 122ns per pixel, which would be correct for NTSC, but now wrecks havoc with both the output pixel durations (every 8th pixel is 158ns long) and probably with the data sample points as well. The only way this can happen is if the system clock runs fast for a certain time before settling to the correct rate. This probably is indeed the a behaviour of your specific clock circuit.

So, I will try to fix this by changing the firmware to revert to the PAL clock settings even later after power-up if necessary.

[c0pperdragon]

I have now tried to fix this in the firmware. You can get the latest experimental version (2.8) from https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental

I did my best to not make any errors, and double and tripple checked everything. But I can not test the effect myself, so please give this a try. This should now solve sparkly pixels, screen corruption and shifted display.

Unluckily when it works for you on your PAL machines, there is no guarantee that I have not messed up the NTSC support. Even more unlucky is the fact that my NTSC machine is broken and I can not test it myself. Maybe I can persuade some user to do the testing....

[Icelvlan88]

Is it possible to have the switch do RGB 240p/component 240p/component 480p?

Thanks

On Jul 23, 2020, at 1:19 PM, c0pperdragon notifications@github.com wrote:



I have now tried to fix this in the firmware. You can get the latest experimental version (2.8) from https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental

I did my best to not make any errors, and double and tripple checked everything. But I can not test the effect myself, so please give this a try. This should now solve sparkly pixels, screen corruption and shifted display.

Unluckily when it works for you on your PAL machines, there is no guarantee that I have not messed up the NTSC support. Even more unlucky is the fact that my NTSC machine is broken and I can not test it myself. Maybe I can persuade some user to do the testing....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/c0pperdragon/C64-Video-Enhancement/issues/38#issuecomment-663130031, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APCADXO7TOOBCYRACJX7Z53R5BWLBANCNFSM4PDRW6OQ.

[c0pperdragon]

Is it possible to have the switch do RGB 240p/component 240p/component 480p? Thanks >

Sorry, but the mod can only maintain one palette at a time. The way to switch to RGB is to reprogramm this one palette. You can switch back to component by reprogramming the platte once more.

[c0pperdragon]

One more thing about the firmware 2.8: Please try it without any capacitor attached to the clock line. This is the way it is intended to work now.

[tyristori]

I just ordered USB Blaster. Will report back once I get firmware updated (My board is from VGP).

[IanSB]

I am now certain that there are two problems with the discrete clock:

1. Mistaken NTSC identification which resulted in left shift of screen and 'sparkly' pixels due to mis-sampling. This effect is static and only appears / disappears on power cycle. This appears to have been fixed by v2.8 but only limited testing so far. (I removed the 100pF to test)

2. Some other problem, possibly slightly different phase relationship between the pixel clock and the cpu clock. This causes issues that appear as the system heats up such as glitches of whole lines like above and this:

The line glitches happen on my R5 and aknightin's R1 but don't happen on my R1. I have also seen other heat related issues like flashes of garbage 8x8 pixel blocks and lines missing from sprites and this happens on both my R5 and R1. I have the composite output simultaneously displayed on another monitor and that doesn't show those effects. As those glitches are very brief, it is difficult to capture an example of them.

Most of these glitches are fixed by re-adding the 100pF capacitor but it doesn't completely eliminate the sprite issues.

Edit: Both players have a missing line or part of a line in this example:

Are there any other measurements you want me to make?

[c0pperdragon]

Lets first tackle the issue with the horizontal line glitches. Because a whole line is affected, it can basically on only some variation in the clock. No there are bascially two possibilities: Jitter and drift.

If there is an individual jitter happening at the sync edge, this would probably affect your sample points of the whole row. A jitter should be noticable when probing the CPU clock. For this, could you do a simultainous measurement of the CPU clock as generated by the VIC (pin 17) and also as it transfered (after level shifting) to the FPGA (pin 20 on the ribbon cable - you will need to unplug it for probing). The jitter may be created either by the clock generator (but your previous measurements did not show any evidence), or the VIC. The second seems plausible because it only happens with the one part.

Clock drift as second possibility is much harder to detect. It would mean that the clock is speeding up in some times and slowing down in others but keeping a fairly constant overall speed. When this happens in during a line all your sample points would of course be off. Maybe your oscilloscope can track variations in frequency, but mine surely can no. If you somehow can do that, try to measure the pixel clock input into the VIC (pin 22 if I am correct).

[c0pperdragon]

The missling sprite line is probably due to the mod missing the exact points when the VIC sends out the sprite memory addresses. In this case, it will think that there is no sprite being shown in this line.

Another interesting measurement would be the relationship between the incomming pixel clock and the outgoing cpu clock from the VIC. Maybe there is something temperature dependent happening.

[c0pperdragon]

I am not sure how much this helps, but since firmware 2.7 the FPGA board secretly outputs a pixel clock that could be used instead of an unstable original circuit. I am usng it to make my whole system more stable as I havr pretty serious jitter otherwise and my replacement RAM chips would not work reliably. If it turns out, your clock circuit is really causing all the trouble that may be an option.

[andriodious]

Sounds like a backup plan. Do you have a schematic?

[c0pperdragon]

I don't have any schematics and it is a very unofficial feature. The FPGA (starting with firmware 2.7) programms the pin 135 to output a perfect PAL pixel clock (it will switch to NTSC frequency when detecting an NTSC machine - but this is not usefull as for this you would have to drive the VIC with the external NTSC clock anyway). You can take this clock most easily from the left solder point of R24 (as shown in the picture). Solder one leg of a 100 Ohm resistor to this point and extend the other leg with a wire.

In the common case of a machine with the 8701 clock generator IC, just pull out this IC and feed the pixel clock signal into pin 6 of the empty socket. Note that without additional measures, the video signal on the original A/V connector will then be black and white only (the VIC can not create colors without the PAL subcarrier frequency).

For the more exotic case of the clock circuit with multiple ICs (which you have), the solution is not so straight-forward. As I do not have such a machine myself I can only theorize based on the available schematic diagrams. The last stage before the dot clock reaches the VIC is the U31 IC, which is unfortunately soldered down, so you can not just perform the same trick as in the other case. The signal passes through the ferrite bead FB17 before going into the VIC. The capacitor C36 seems to help in removing noise on the line. What you probably can do: Find out which leg of FB17 is connected to the VIC pin. Desolder this leg from the main board and bend the part out of the way. Solder the wire from the FPGA into the hole. If you dont want to take the board out of the case, you can as well just cut the leg of FB17 and solder the wire to the remaining stump. Contrary to the first case, here you still have working colors on the A/V output, but you may experience some dot-crawl as the subcarrier frequency and the dot clock are no longer in a harmonic relation.

If you want to try this: Good luck!

[andriodious]

Thank you, this is useful to know if I have to try it, and thanks for taking the time to explain.

With 2.8 I get sparkly pixels for the first few seconds after cold power up then these fade to a solid display. After an hour the machine still remains stable so for now I might leave as is.

One other thing I am tempted to do first, is to replace the 17.73447 Mhz crystal with a HC49/3H package part. I had display timing problems on my BBC Micro until I replaced the associated 16Mhz crystal. I guess there might me some scope for a drift in performance/accuracy after what will be 38 years in my systems case.

[c0pperdragon]

Seems to me that your crystal needs to get up to temperature to achieve correct frequency.

My guess here is that the clock runs substantially faster immediately after power-up. This also caused the previous firmware revisions to switch the clock multiplier to NTSC frequencies which messed up basically everything else. Now the firmware will still switch to NTSC, but it will switch back again as soon as everyting stabilizes.

[IanSB]

I found out what the problem is with the above glitches on the discrete clock, the 17.73 Mhz oscillator U31 is going unstable and producing a very jittery clock: Yellow is CPU clock, Cyan is pixel clock and Magenta is 17.73 Mhz clock

If I put my finger on one of the legs of the 17.73Mhz crystal (the one joined to C70) it becomes a lot more stable again so I tried a 4.7pF capacitor on that leg to ground and that had a similar effect. This isn't completely stable but access to R27/U31 is not easy with the buffer board fitted so it's difficult to do any diagnostics. I did manage to adjust R27 but that didn't help the instability.

Here's Pin 17 and the buffered version:

There are no horizontal glitches with the more stable clock but I'm still getting missing lines in sprites so any further suggestions? (The sprites are OK on the analog output)

[c0pperdragon]

This sprite DMA detection is a pretty tricky business. I already had multiple iterations with various users until I got it to work reliably on all machines. All with the exception of yous, of course. I don't want to again start changing the time for the sample points, otherwise I would break compatibility with many other machines.

First thing to do: Try with the other VIC. Second thing: You may want to attempt my above solution to let the FPGA board generate a perfect the pixel clock.

[c0pperdragon]

This stable pixel clock can also greatly help with other stability issues of the system as well. Especially the VSP trick often causes crashes on certain machines. This is very related to exact signal timing, any on my machine completely vanishes when using a better pixel clock. https://www.linusakesson.net/scene/safevsp/index.php

[IanSB]

First thing to do: Try with the other VIC. Second thing: You may want to attempt my above solution to let the FPGA board generate a perfect the pixel clock.

I tried with both my 4.7pF capacitor mod and the perfect clock mod from R24 above: With either mod, the R5 has missing lines from cold, the R1 has missing lines when warmed up.

In all cases the analog output is OK.

[c0pperdragon]

I have created an experimental firmware where the sample point for the sprite DMA detection is shifted for an additional 32ns. I have not even tested this yet myself, but you may give it a try. Use the latest beta from https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/firmware

If this helps your issue, I will have to do some thorough testing to guess if it is safe to use this for a official release. Maybe @andriodious could also try this out.

[IanSB]

That made it 10x worse

[c0pperdragon]

I have shifted the sample point in the other direction. But now this is exactly there where other users had problems with it. So even if this works for you now, I can not make it an official release. Maybe some special build just for you...

[IanSB]

That is stable on the R5 from cold which previously had missing lines from cold. I'll let that warm up for a while to see it remains stable then I'll try the R1 and report back later.

How much did you move it and could it be moved by a smaller amount?

I can not make it an official release. Maybe some special build just for you...

I suspect the problem is an interaction between the jitter caused by your asynchronous sampling clock and slightly different signal delays on different revisions of the motherboard and VIC II. (Although in this case the sampling clock isn't asynchronous as the VIC II is being driven from the FPGA)

If you want to keep a single firmware release, maybe you could make it switchable by grounding an unused pin on the FPGA as I don't mind soldering a wire to one. (If there is an unused input pin next to a GND pin then it could be achieved by bridging the two pins which might be slightly easier)

It's at times like these a bank of solder bridges connected to unused pins would be useful!

[c0pperdragon]

Yes, I have done the firmware change, so that you can activate this special sprite timing by grounding pin 95 on the FPGA. As you suggested, this is relatively easy because pin 96 is a GND.
Just make sure that you don't short any other pins. Pin 93 may actually be safe as it is unused, but 97 is an important input.

Firmware on usual location

[IanSB]

Ok here's some further results with beta 3 timing, all tested with the stable clock from the FPGA to eliminate any other variables:

R1: Some missing lines on power up which quickly stop as the chip warms up. This is the opposite to the original timing which was stable on power up with some lines after it had warmed up significantly.

R5: no lines hot or cold, compared to always lines hot or cold with original timing.

It seems to me that the optimum value is going to be somewhere between the current beta 3 timing and the original timing if you have the resolution available to make such an adjustment.

[c0pperdragon]

This 32ns adjustment is the smallest time span I have here. My logic is running at 16 times the CPU clock and I can only take samples either at the rising or at the falling edge. With your R5 you seem to be fine now.

[IanSB]

OK I'm now running beta 4 with the solder bridge and will continue testing. In case anyone else has to try this, here is a photo of the bridged pins: (Close to the U2 silk screen)

[andriodious]

Thanks folks, will try this next time I cycle round to the C64 again. Just debugging my Jupiter Ace build ATM, ironically it has a clock issue feeding the CPU exhibiting in a corrupted display :)

[andriodious]

Right, just tried the mods and beta 4 firmware and I must report all rock solid from cold startup through to warm up so far on my R1. Instead of the 'perfect clock' I fitted a new crystal instead so I think that is possibly also helping -- no sparkly pixels from cold like before. Thanks both for solving this. I haven't done extensive testing yet as I want to finish my Ace but so far so good :)

[tyristori]

Where can I get that 17.73447 Mhz crystal in HC49/3H package?

[c0pperdragon]

https://www.mouser.at/ProductDetail/ABRACON/AB-17734475-B4?qs=%2F3Qg3%252BjSQfO1WcMhhN0k%252Bg%3D%3D

[andriodious]

Just tested a bit more today and unfortunately leaving it run for 20 mins it started to show the screen glitches as before with the R1, so cold and warm OK, significantly warm == issues. This is suggesting that I'm get the similar results as Ian.

I haven't tried the FPGA clock mod yet, or the 4.7pf cap mod on the oscillator.

I'll look at the oscillator stability and try that one first.

If I still have issues with the R1, I may switch to the R5 VICII.

[andriodious]

Update to above with beta4 firmware enabled via grounding FPGA pin 95 on a 250407 rev A board:

Findings so far with different VICII versions:

• R1 with C64 clock circuit gets sparkly pixels after significant use, sprite line missing issue appears after warm-up. Sparkly pixels at startup were fixed by adding a new oscillator

• R1 with C64 clock circuit but with 100pf cap across 20-21 fixes sparkly pixels after warm-up but the occasional sprite line missing issue

• R1 with FPGA clock via 100R and into FB17 and no 100pf cap across 20-21, no sparkly pixels, occasional sprite issues avg one per minute when significantly warm -- see pic

• R5 with FPGA clock via 100R and into FB17 and no 100pf cap across 20-21, no sparkly pixels at startup, or when warm, also no visible sprite issues as with R1

I realise for the sake of science and completeness I should have tried the R5 with the C64 native clock but the ambient temperature is 34 deg. C in my shed and I didn't feel there was significant ROI by reverting the FPGA clock!! :)

HTH

[andriodious]

Good day today. C64 is working nicely and I also got my Ace repro build to boot for the first time 👍

[c0pperdragon]

All these experiments show that the clock circuitry is indeed the cause of uneven pixel clock speed. For all normal purposes this would not matter, but for pixel-perfect sampling it does. The sprite glitches are a different matter and should be fixed in the firmware. Problem is: I don't know how ☹️.

[tyristori]

Nevermind my deleted message. I got the beta4 working now. I'll report back when I've done some testing.

[andriodious]

As I have a working system now with my R5, I can send you my R1 VIC-II to experiment on on a loan basis if you are interested. It will have it's heatsink fitted as the plaster I used seems to be semi-permanent without the aid of a heat-gun.

I notice there are many 250407 boards on eBay at the moment e.g. One working board without a VICII (or PLA)

[c0pperdragon]

I will leave the issue for now, as you both have a R5 chip which seems to work flawlessly together with the mod board when using the early sprite DMA option. 6569R1 chips seem to be a complicated matter - but there are probably only few around from the very early machines, so I wait for the next actual problem before digging further into the matter.

[IanSB]

I will leave the issue for now, as you both have a R5 chip which seems to work flawlessly together with the mod board when using the early sprite DMA option

Actually I'm still getting occasional missing lines on sprites with both R1 and R5, maybe 1 or 2 a minute.

The sprite glitches are a different matter and should be fixed in the firmware. Problem is: I don't know how

Looking at the C64 service manual, there seem to be many "bodge" components that vary RAS/CAS timings to be fitted or altered in value depending on the revision of VIC II installed or even the combination of VIC II + revisions of other chips like the PLA so there probably isn't going to be a universal timing solution. If you ever do a board update I suggest adding a bank of DIP switches to unused inputs to allow timings to be varied.

As far as the occasional missing lines above, the only option left to try is another delay of 32ns in the same direction as the first one, perhaps by grounding the unused input next to the first one so a bridge across all 3 pins gives 64ns and the two exising bridged pins gives 32ns.

[tyristori]

I removed 47pF capacitor between VIC pins 17 and 20. I put a socket on U31 and I'm feeding the clock signal from FPGA to pin 7. Running firmware 2.8 beta4.

I watched demos for couple of hours and didn't notice any glitches so for me it's pretty much perfect now. Before with only 47pF capacitor I got occasional glitches and the machine was very unstable.

I still get some crashes with demos because of VSP bug. I've ordered a new crystal from RetroTech.

Btw does the trimmer resistor near the Vic do anything with this mod?

[c0pperdragon]

The trimmer is probably there to fine-tune the master oscillator to exactly 4 times the PAL/NTSC subcarrier frequency. Pixel clock is normally derived from that. When you are now taking the pixel clock from the FPGA, the mod will no longer be affected by the trimmer adjustment.