Graphical glitches with N64RGB mod

[arebokert]

So, I installed the N64RGB board from Tim Worthington in to my N64, following the instructions and double checking everything.

Now that I've started the N64 I've noticed some weird graphical glitches. I see flickering pixels and general symptoms of what usually amounts to low bitrate when it is seen in video playback context. This happens no matter which game I try. Now I'm wondering, have I done something wrong or could the board/N64 be defective? I didn't want to open the N64 up and resolder all joints before I know it is likely to make any difference.

Here are some video examples (please excuse the vertical recording, I have already got that comment from elsewhere ):

https://www.youtube.com/watch?v=ONUg-dNkgQw

https://www.youtube.com/watch?v=-uJSEG6kWlQ

https://www.youtube.com/watch?v=6nghapmtuag

https://www.youtube.com/watch?v=3o-RGvwKhWM

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

I'm running the N64 through a SNES PAL SCART cable from retrogamingcables, connected to an OSSC, sync-on-luma.

Any suggestions would be greatly appreciated!

[ApolloBoy]

Check to make sure all your wires are soldered properly and if you’re using the pin adapter for the DAC chip, check that carefully as well. I’ve found that if your connections aren’t solid enough you’ll get weird artifacting like what you’re experiencing.

[borti4938]

When have you bought your modding kit?

There was an firmware update mid. November resolving a color problem, which is visible on gradients. The issue effected just a minor number of modding kits (for what ever reason).

This looks like your problem. If you have the opportunity to update your firmware (a Chinese clone USB Blaster costs just a few bugs), please do that.

http://etim.net.au/n64rgb/tech/

[arebokert]

When have you bought your modding kit?

There was an firmware update mid. November resolving a color problem, which is visible on gradients. The issue effected just a minor number of modding kits (for what ever reason).

This looks like your problem. If you have the opportunity to update your firmware (a Chinese clone USB Blaster costs just a few bugs), please do that.

http://etim.net.au/n64rgb/tech/

I bought mine in the middle of september so I guess this might be my issue. I do have an st-link v2 programmer but looking at the pinout I'm guessing it will not work.



I also have some FTDI based serial programmers, would that work?

[arebokert]

Check to make sure all your wires are soldered properly and if you’re using the pin adapter for the DAC chip, check that carefully as well. I’ve found that if your connections aren’t solid enough you’ll get weird artifacting like what you’re experiencing.

Maybe I should do this as well just to be sure.

[leonk]

When have you bought your modding kit?

There was an firmware update mid. November resolving a color problem, which is visible on gradients. The issue effected just a minor number of modding kits (for what ever reason).

This looks like your problem. If you have the opportunity to update your firmware (a Chinese clone USB Blaster costs just a few bugs), please do that.

http://etim.net.au/n64rgb/tech/

Thanks Borti. Have you updated your IGR to support this new firmware or does it have your latest code already?

I recently installed 2 N64RGB PCB's I got from Tim; and 1 of them is coming back for inspection due to a problem described here! Might try the new firmware before I rip the board out.

Maybe it's time for Tim to revisit his current parts supplier! This stuff is starting to hurt the installers with cross country shipping, etc!!!

[borti4938]

Thanks Borti. Have you updated your IGR to support this new firmware or does it have your latest code already?

From another thread: viewtopic.php?p=1291785#p1291785

I recognized it appr. a month ago and integrated it: link to the commit.
I wish he would have contacted me, but he didn't. I saw that by accident.
I also have improved some other incritical timings a few days ago.

Firmware for vieltims board has also moved to another folder of the repository such that I can share resources with my N64RGB mod: programming files for viletims are now located in generalRGBmod/firmware/output_files/viletim

Have you also seen my response to the white screen issue? viewtopic.php?p=1292295#p1292295

[unstablewarpfield]

I have the exact same problem here. It seems to happen more to darker colors (although on the backgrounds of the Zelda OoT intro it's also very visible). I recently updated the firmware thinking this would fix my problem. Unfortunately the image still has the artifacts in it. I guess the next step is to shorten the flatcable running to the board, but is is pretty annoying Not annoying as to the point of spending the money on an hdmi board, although that seems more and more attractive if I can't solve this problem.

[Syntax]

From my experience there are 3 different types of screen noise to look out for when dealing with a N64.

Horizontal interference. This is caused by using the 3v from the N64 to power your RGB modboard. The 3v line is very noisy and you will notice that the interference changes with music even. Fix by using a separate LDO or power the board with 5v (May require a mod)

Jumping pixels - Pixels that jump in and out of existence, this is caused by crosstalk on the ribbon cable data lines and can be fixed by adding some 40-100R resistors inline of the ribbon cable.

Then lastly there's the innate noise that seems like poor compression all over your screen which seems to show up more on light backgrounds with gradients. It stops black from ever being solid black, gives your screen a fuzzy look.
This is my pet hate with N64 and there is no fix yet.

[arebokert]

When have you bought your modding kit?

There was an firmware update mid. November resolving a color problem, which is visible on gradients. The issue effected just a minor number of modding kits (for what ever reason).

This looks like your problem. If you have the opportunity to update your firmware (a Chinese clone USB Blaster costs just a few bugs), please do that.

http://etim.net.au/n64rgb/tech/

So now I have finally gotten to updating the chip with the latest firmware and can say that it made no difference at all. Do you have any other suggestions?

[arebokert]

Would you perhaps suggest that I shorten the data cables?

[NoAffinity]

This thread caught my attention. Installed the N64RGB

http://etim.net.au/n64rgb/

I have this cable:

https://retro-access.com/products/super ... nded-cable

I am getting some dancing pixels and possibly artifacting, which I believe matches the issues being discussed here. You can see in the video, everywhere that it says Mario in the background, there are dancing pixels:

https://youtu.be/apuWJC7ZnQw

I am opening up the console now, to recheck my work, but hoping to also get some validation from the community.

Separate question - this board was purchased in early May, received around 5/14. Does the native firmware include the deblur feature or does it need to be programmed? (Or maybe some of you can tell just by looking if deblur is active).

:edit: I checked all lines at the N64RGB board and don't have any shorts. Grounds are good. 3.43V power to the board. Using provided ribbon cable, per instructions under "Consoles with VDC-NUS and DENC-NUS chips", at http://etim.net.au/n64rgb/instructions-new/

[Syntax]

Inline resistors on the data lines will fix those naughty pixels.

https://i.imgur.com/NREgRPj.jpg

[NoAffinity]

Inline resistors on the data lines will fix those naughty pixels.

https://i.imgur.com/NREgRPj.jpg

Sorry if I asked a question that was already answered. Thank you for honing in on my particular problem and needed solution. ***Off to the local parts store I go***

Another question - With my cable, the sync line is continuous from one end to the other. I'm outputting sync on luma to the OSSC. Does it matter which sync connection I connect to - CS# or CS75? I tried both and there doesn't appear to be any difference, but if there is a better one to go with, I like being better.

[Syntax]

CS75.

[NoAffinity]

I cut the pads on D0-D6 and DS#. Put 75R resistors on the lines. Same result. It looks like you have a resistor on the clock line also?

If I didn't state it, this is a VDC-NUS board.

[Syntax]

Clk is probably the most important one to do it to.

I cut the small clk pad but the realised it goes nowhere.

You need to cut the big lower clk pad.

Fix your video link too so I can watch it

[NoAffinity]

Clk is probably the most important one to do it to.

I cut the small clk pad but the realised it goes nowhere.

You need to cut the big lower clk pad.

Fix your video link too so I can watch it

Thanks for confirming. I'll revisit it as suggested. Video link should be good now. I had made it private instead of unlisted. Sorry about that.

Sent from my SM-G955U using Tapatalk

[NoAffinity]

All right, I got my 20 pack of SMD 75R resistors in the mail today, and got them in place on *I believe* all of the appropriate lines. Please confirm all lines have a resistor that should, and that I don't have resistors where I shouldn't.



There seems to be no improvement. New video:

https://youtu.be/lTA7BZI5oWI

You can see the dancing pixels one the score/time text. And then at the big mario head screen, on the No Controller text, and the Super Mario 64 tiles in the background.

If I've done everything apparently right, any next suggestions?

:edit: sync output is on CS75 now, also.

[Syntax]

Do you have extra grounds or just that one on the ribbon cable?

You need a good ground.

[NoAffinity]

One on the ribbon cable, and one off the output side going to the case. Are more recommended, and if so, at which points on the RGB board and to which points?

[Makinx]

I had graphical glitches much worse than you and it turned out to be a short between 2 of the data lines. A tiny speck of solder touched the other line which I only noticed upon close inspection. The picture looks fine now and I have done none of the extra stuff you did. Maybe you have a similar problem?

Now, you say you use a PAL SNES Scart cable, but you haven't closed J1, J2 and J3. I doubt that would cause the problem but I would at least correct that.

[paulb_nl]

There seems to be no improvement. New video:

https://youtu.be/lTA7BZI5oWI

You can see the dancing pixels one the score/time text. And then at the big mario head screen, on the No Controller text, and the Super Mario 64 tiles in the background.

Those glitches in Super Mario 64 are completely normal. Here is a video of my Japanese N64 with THS7314 mod where the same happens: https://www.youtube.com/watch?v=kCorybNncmA

It even happens with accurate Nintendo 64 emulators: https://www.youtube.com/watch?v=jsIOxVs_aZw

[NoAffinity]

There seems to be no improvement. New video:

https://youtu.be/lTA7BZI5oWI

You can see the dancing pixels one the score/time text. And then at the big mario head screen, on the No Controller text, and the Super Mario 64 tiles in the background.

Those glitches in Super Mario 64 are completely normal. Here is a video of my Japanese N64 with THS7314 mod where the same happens: https://www.youtube.com/watch?v=kCorybNncmA

It even happens with accurate Nintendo 64 emulators: https://www.youtube.com/watch?v=jsIOxVs_aZw

Thank you sir for confirming that. Guess I'm chasing my tail here then. :/ Will check some other games, to make sure it's isolated to this title only. Thought I was seeing it on other titles, but this is the last one tested and what I ended up capturing, but now I guess I need to revisit it.

^^Makinx, I checked all lines to all other lines after completing the mod, no shorts. When I took that closeup of the output side (above), I thought it looked like there might be a short between CS# and ground, but checked that also, and no shorts. It's not a PAL scart cable. Jumpers are left open per installation instructions:
"All open for Gamecube SCART, Super Nintendo NTSC SCART, Super Famicom RGB21 (Japanese)."
It's actually a SNES NTSC sync on luma cable. The beefier version from retro-access, with shielded coax or whatever the upgrade is for their cables.

[NoAffinity]

I let a couple other games play, and see no issues. I let Ocarina of Time play through live capture, while simutaneously having youtube UltraHDMI footage playing side-by-side. They both look identical.

So, sorry for sounding a false alarm. But, I now have those resistors in place to mitigate any ribbon cross-talk, so that's an improvement right? Me and my OCD will now quietly drift back into the shadwos of this discussion.

[Makinx]

^^Makinx, I checked all lines to all other lines after completing the mod, no shorts. When I took that closeup of the output side (above), I thought it looked like there might be a short between CS# and ground, but checked that also, and no shorts. It's not a PAL scart cable. Jumpers are left open per installation instructions:
"All open for Gamecube SCART, Super Nintendo NTSC SCART, Super Famicom RGB21 (Japanese)."
It's actually a SNES NTSC sync on luma cable. The beefier version from retro-access, with shielded coax or whatever the upgrade is for their cables.

Ah that's okay then. It's just that you said it was a PAL cable in your first post.

[viletim]

Most graphics glitches are caused by a bad connection or short circuit between the data lines and the N64RGB board. Here's a procedure to test your connections with a multimeter.



1) make sure the Nintendo 64 console is switched off.
2) Set your multimeter to resistance mode.
3) Put the black probe on a ground pad.
4) Put the red probe on each of the data lines in turn (D0-D6, CLK, DS). Make sure you probe the pads that on the N64RGB board that are not soldered. In the picture, the ribbon cable is soldered to the DENC set of pads so I probe the VDC pads. You should measure a few mega ohms for each signal. The exact value does not matter, but it should be close between each measured data line.

If two data lines measure a bit low (~ 10%) then there may be a short between them. If one measures open (infinite resistance) there may be a bad connection on this line, at the N64RGB end, at motherboard end, or a break in the cable. If a data line lines measures significantly low, there may be a fault on the N64RGB board (damaged input). All data lines should measure open (infinite resistance) when the ribbon cable is not connected.

[viletim]

Inline resistors on the data lines will fix those naughty pixels.

https://i.imgur.com/NREgRPj.jpg

Installing resistors like this will not help at all. If it did they would already be on the board.

The problem is the data lines are fast digital signals and the cable is a transmission line. It would be hugely beneficial to attempt to impedance match the two to prevent signal reflections. This can be done by placing the series resistors on the motherboard end of the cable only. It's physically very difficult to mount resistors here with the cable supplied. Instead, I recommend just keeping the cable as short as possible. It's not ideal, but seems to work OK in practice.

From my experience there are 3 different types of screen noise to look out for when dealing with a N64.

Horizontal interference. This is caused by using the 3v from the N64 to power your RGB modboard. The 3v line is very noisy and you will notice that the interference changes with music even. Fix by using a separate LDO or power the board with 5v (May require a mod)

I measured the 3.3V rail at the N64RGB board on my console earlier this year and found the noise was minimal (link). Even so, as a precaution I've since increased the value of the four decoupling caps from 100n to 1u.

[Syntax]

Can happily send you my n64 and the board I purchased from you if you'd like to prove yourself wrong as the resistors did fix my pixel issue.

I always value the opinion of a professional like yourself Tim but when Borti suggested I fit the resistors as a fix I did only that and it fixed the problem. Nothing else was changed.


The same board shows a different ohm reading on blue output compared to green and red. I think it's the 3rd time I've mentioned this but no one seems to give a .....

[borti4938]

Practice vs. Theory:

I always value the opinion of a professional like yourself Tim but when Borti suggested I fit the resistors as a fix I did only that and it fixed the problem. Nothing else was changed.

Installing resistors like this will not help at all. If it did they would already be on the board.

Instead, I recommend just keeping the cable as short as possible. It's not ideal, but seems to work OK in practice.

Fitting the resistors on the modding board has just a very minor effect but in practice it helps a bit; yet not always.
Same with the lenght of the cable; the length does not have an influence the characterical impedance of the cable and thus does not change the reflection coefficient at all in theory.

This can be done by placing the series resistors on the motherboard end of the cable only. It's physically very difficult to mount resistors here with the cable supplied.

Why are no resistors then on the flex cable you designed long time ago for the MAV-NUS? This was a big chance to add them.

This is how it looks like with my solution:

(please ignore the UltraHDMI flex cable below)

Additionally I have installed ferrit beads on the modding board.
(My boards have resistors at the input, which I now replace with ferrit beads on a picky N64 installation where the PLL were loosing lock from time to time)