N8 EverDrive Vs. NESRGB (glitches) *now with video*

[evil_ash_xero]

I'm glad this thread has pointed people in the right direction.

What a tricky little bitch of a problem. Jason really came thru, on that one.

[fernan1234]

This happens to me with the ED8 on my NESRGB-modded original Famicom. Usually power cycling one or two times fixes it, but it is annoying. Does anyone know where the transistor that causes the problem is on a 07 motherboard Famicom?

[Syntax]

This only happens if using the original NES composite video feed for sync right? The one that shows a crappy bw image when nesrgb is on? No wonder.
Really you should be using the nesrgb composite out and if you need the original wire in switches.

If you must have the original composite video then..

Put a switch between nesrgb composite out and original composite out, switch to original and turn palette selection switch off.

Original composite video is broken the second nesrgb is turned on. (Palette selected)

[flex]

This only happens if using the original NES composite video feed for sync right? The one that shows a crappy bw image when nesrgb is on? No wonder.
Really you should be using the nesrgb composite out and if you need the original wire in switches.

If you must have the original composite video then..

Put a switch between nesrgb composite out and original composite out, switch to original and turn palette selection switch off.

Original composite video is broken the second nesrgb is turned on. (Palette selected)

Not quite... In my case the original composite trace on my AV Fami was already cut and not used and I am using CSYNC directly off of the NESRGB board, like I said the issue wasn't anywhere near as bad but was still occurring intermittently so according to what I have read I believe this to just be an interference type thing.

[Digital Dragon]

Hey guys, just wanted to say I had this issue as well on my AV Famicom with real carts 100% of the time. Removed Q1 and problem solved. Big thanks to Flex for linking me to this thread

[unmaker]

I'm having this problem with a NES-101 and Everdrive N8. Removing Q1 seems to have helped but I see the pixel noise about 3 out of 10 power cycles. I'm wondering if the sockets supplied with the NESRGB kits aren't ideal? Are there better sockets available?

[fernan1234]

A few people were discussing this issue in the new N8 PRO's announcement topic at KRIKzz's forums. This bit of information was particularly important posted by users nuu and Link83 respectively:

It sounds like this is about CPU-PPU clock alignment. There are 4 possible alignments every Famicom and NES could end up with at each boot. If you have a PPU that has this bug and speckles appears in a game you need to boot it into another alignment that works with that game by power cycling it until it works.
Soft reset will not work (not sure if any games even have this). Hard reset might work on a front-loading NES. For a Famicom and a top-loading NES you might need to power cycle since the reset button doesn't reset the PPU on those.

And

It sounds like technically the bug is in the PPU, so its not really a fault of the NESRGB or the EverDrive N8. The NESRGB could probably select a specific clock alignment/phase from the four available, but apparently different games respond better to different alignments, and some games cant be fixed at all, so I dont think locking the NESRGB into one specific alignment would really help. Its likely easier to just power the system on/off until you get the desired clock alignment (The reset button will also work on some some systems, but not all of them since Nintendo changed the reset circuitry between revisions and some models dont reset both the CPU and PPU when using the reset button)

I think the only solution really is to either get a console with a Rev.H PPU (Later models of AV Famicom, and perhaps later NES toploaders as well) which apparently fixed the issue, or patch each game to disable writes to the PPU_CTRL $2000 register:-

What I find interesting is that I think this PPU clock alignment bug seems to also affect the stock Composite video output as well:-

A total solution would need to be implemented on a future revision of the NESRGB to avoid this CPU-PPU alignment issue. There may be software/patch solutions but there may be issues with that too. Apparently certain board revisions will not have this problem, but what are IMO the best consoles (OG Famicom and NES consoles) don't have those.

[unmaker]

A few people were discussing this issue in the new N8 PRO's announcement topic at KRIKzz's forums. This bit of information was particularly important posted by users nuu and Link83 respectively:

It sounds like this is about CPU-PPU clock alignment. There are 4 possible alignments every Famicom and NES could end up with at each boot. If you have a PPU that has this bug and speckles appears in a game you need to boot it into another alignment that works with that game by power cycling it until it works.
Soft reset will not work (not sure if any games even have this). Hard reset might work on a front-loading NES. For a Famicom and a top-loading NES you might need to power cycle since the reset button doesn't reset the PPU on those.

And

It sounds like technically the bug is in the PPU, so its not really a fault of the NESRGB or the EverDrive N8. The NESRGB could probably select a specific clock alignment/phase from the four available, but apparently different games respond better to different alignments, and some games cant be fixed at all, so I dont think locking the NESRGB into one specific alignment would really help. Its likely easier to just power the system on/off until you get the desired clock alignment (The reset button will also work on some some systems, but not all of them since Nintendo changed the reset circuitry between revisions and some models dont reset both the CPU and PPU when using the reset button)

I think the only solution really is to either get a console with a Rev.H PPU (Later models of AV Famicom, and perhaps later NES toploaders as well) which apparently fixed the issue, or patch each game to disable writes to the PPU_CTRL $2000 register:-

What I find interesting is that I think this PPU clock alignment bug seems to also affect the stock Composite video output as well:-

A total solution would need to be implemented on a future revision of the NESRGB to avoid this CPU-PPU alignment issue. There may be software/patch solutions but there may be issues with that too. Apparently certain board revisions will not have this problem, but what are IMO the best consoles (OG Famicom and NES consoles) don't have those.

I had a chance to test this out. I had 2 NES Top Loaders; one had the pixel noise issue and the other did not.

Spoiler

The console on the left with a revision H PPU had the issue and the other console had a revision G PPU. According to your post I assumed the issue was the PPU revision. I swapped PPU's and the console on the left still had the issue despite now having a revision G PPU. The console on the right did not have the issue despite now having a revision H PPU. I then tried swapping OEM NES power supplies between the two and that made no difference. I also tried swapping the entire NESRGB kit and that made no difference either. I did many power cycles with each test.

Both consoles were recapped, new L78S05CV's, and Q1 transistor removed. I emailed viletim about this but he stopped replying after a few exchanges. I wasn't able to figure out what the issue is but my best guess is it's the sockets. I could have tested this by removing the sockets but it's too much work to disassemble a NESRGB kit once it's already been assembled.

[Link83]

Hmm, thats interesting. So does the board on the right never have speckles when using either the Rev.G or Rev.H PPU? If so I wonder which part is actually causing the issue. Perhaps its the CPU revision?

From the date codes printed on the motherboards i'm guessing the Rev.H PPU originally belongs to the system on the right (1994), and the Rev.G belongs to the one on the left (1993)? Which means its the 1994 system with the Rev.H CPU which isn't showing the speckles.

Perhaps this is irrelevant but I seem to recall reading that certain CPU and PPU revisions dont work well together when mismatched - you need to have matching CPU and PPU revisions in order for them to work correctly.

I guess kevtris would be the best person to ask about this, or perhaps make a thread on the nesdev forums?

[unmaker]

Hmm, thats interesting. So does the board on the right never have speckles when using either the Rev.G or Rev.H PPU? If so I wonder which part is actually causing the issue. Perhaps its the CPU revision?

From the date codes printed on the motherboards i'm guessing the Rev.H PPU originally belongs to the system on the right (1994), and the Rev.G belongs to the one on the left (1993)? Which means its the 1994 system with the Rev.H CPU which isn't showing the speckles.

Perhaps this is irrelevant but I seem to recall reading that certain CPU and PPU revisions dont work well together when mismatched - you need to have matching CPU and PPU revisions in order for them to work correctly.

I guess kevtris would be the best person to ask about this, or perhaps make a thread on the nesdev forums?

You're correct! Good eye. I mixed up the PPU's and when I took this photo I had already swapped the PPU's. The console on the left originally had the rev.G PPU and the right had the rev.H PPU.

Yes the console on the right never had speckles, no matter the PPU revision. I must have done around 100 power cycles before swapping and another 100 after swapping. As you say it could be the CPU revision. I don't have either console anymore so I can't do any further testing.