Graphical glitches on the Everdrive

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Posts: 790
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Graphical glitches on the Everdrive

Post by krzysiobal » Wed Aug 05, 2020 3:02 am

I tested the `oam_corruption_stress_test.nes` ROM against different PPUs on my own Flashcart and here are the results (all the tests, except the one with UM6561 were done on the same console, with the same CPU - just the PPU and crystal resonators were altered):

No bugs:
RP2C07-0 (OMM 2X) - PAL PPU
UA6538 (9210) - found in Dendy clones
UA6528P (8911S) - from aliexpress - I bet this is just ordinary UA6538 with chinese-faked label as it needs 26.601712 MHz crystal and emits 50Hz video
TA-02NPB (9234) - Rinco Thompsonic Dendy famiclone #1
TA-02NP (9229) - Rinco Thompsonic Dendy famiclone #2
UA6528 (9201) - NTSC famiclone

Two sequential random tiles are mising on powerup, but the corruption does not go any further:
UA6538 (9009) - from aliexpress, I call it the pre-mid-'90 release
UM6561 - single chip based famiclone (IQ502)

True OAM decay - sprites are randomly appearing as time flows:
RP2C02G-0 (9M3 54) - NTSC PPU

The first conclusion is that I finally nailed the difference between UA6538 pre-mid-'90 and after-mid-'90 - the latter one is bug-free.
Second surprise is that UM6561 is based on the old, buggy version
Third suprise is that the "real" OAM decay bug appears only in original NTSC PPU, and not in its Dendy clone (UA6528)


I am sceptical about pulling the CPU data bus. I don't see any reason why this is connected. My flashcart does not affect anything when emulating NROM, it does not add any extra code during run. The Famicom has 330pf + 30pf on PPU/CE to ground, while NTSC NES does not, maybe that's the reason?

Posts: 199
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit » Wed Aug 05, 2020 8:02 pm

Thanks for the update and for results on so many PPUs! I've only tested this on NTSC consoles so far. The results vary from unit to unit, but are fairly consistent on a given unit. Some NTSC units appear to not be affected by the problem at all.

Regarding the resistor fix, I think there's pretty strong evidence that this at least mitigates the decay problem:

- The PowerPak had sprite problems that sound like this issue that were fixed with 100 ohm resistors on the CPU data lines (PowerPak recall for resistor fix and instructions for the fix).
- The original Everdrive N8, which does not have resistors, has the problem, while the new N8 Pro, which has 100 ohm resistors on every pin, hasn't in the testing so far (resistors seen here along the bottom).
- The FDS RAM adapter apparently has this same sort of problem, which has been found to go away with a 4.7 kilo ohm resistor to ground on each of the CPU data lines (Glitchy sprites on FDS).
- A hardware project I've been working on, which does not have these resistors on the current development board, triggers this same decay problem when running the test ROM.
- Now your cart, too, which does not have the resistors.

The best guess I've seen for why resistors would matter is that they reduce signal reflection, which could be affecting the PPU via the pins it has on the CPU data lines.

The 2 missing sprite tiles on reset is likely the issue covered by my oam_flicker_test and oam_flicker_test_reenable test ROMs (in this and the following post), where disabling rendering outside of vblank on certain dots will cause corruption of one OAM row when rendering is enabled again. I think it's reasonable to assume the bad state that triggers the corruption persists across reset, and it explains this result perfectly (including the affected tiles sometimes being moved to a weird location, which can happen if rendering is enabled again outside of vblank). As far as official hardware, this issue is probably only present in NTSC PPUs E-0 through H-0, though we don't have comprehensive test coverage yet. This shouldn't be affected at all by the cart hardware and I should probably make a new version of oam_corruption_stress_test that works around it.

Posts: 1
Joined: Sat Aug 15, 2020 10:56 pm

Re: Graphical glitches on the Everdrive

Post by comradesnarky » Sat Aug 15, 2020 11:00 pm

krzysiobal wrote:
Wed Aug 05, 2020 3:02 am
The Famicom has 330pf + 30pf on PPU/CE to ground, while NTSC NES does not, maybe that's the reason?
I've been experiencing graphical glitches with the Everdrive as well. I have a front loader NES with an NES RGB that I installed, rev. G PPU. I've tried just about everything to attempt to fix the issue and came across this thread. I saw this and thought "voila!" but that isn't the case, unfortunately. I added these caps to my NES to see what would happen and bizarrely enough the Everdrive started crashing at fairly random intervals.
- The Everdrive crashing seems to have been related to the Blinking Light Win, not the caps.

EDIT: So, I found a solution to my problem. It does seem that the differences lies in a change between the Famicom and the NES. I was searching to see if anyone had done a breakdown on changes in how the PPU is connected between the Famicom and the NES and I found a really, really exhaustive breakdown from a thread where people were doing the old style RGB mod with a PlayChoice-10 PPU. This post mentions the 330pf/30pf caps to ground on the /CS line, but I also noticed he mentions a 68pf cap to ground on /RD that is present in the Famicom and PlayChoice but NOT the NES. I didn't have a 68pf cap so I grabbed a 51pf cap from another NES that I had and wired it up and all glitches are gone.

User avatar
Posts: 107
Joined: Wed Dec 11, 2019 9:38 pm

Re: Graphical glitches on the Everdrive

Post by Goose2k » Tue Oct 13, 2020 8:09 pm

I just got this issue on a commercial game for the first time: Might Final Fight. As usual, the same cart worked fine on my top loader. This is a system which has seen the issue on a few homebrew carts (Action 53, krzysiobal's cart).

Anyway, not sure if that adds anything, but just wanted to mention it.

User avatar
Posts: 134
Joined: Fri Sep 13, 2019 11:22 pm

Re: Graphical glitches on the Everdrive

Post by aquasnake » Fri Oct 16, 2020 9:00 pm

Banshaku wrote:
Tue Jan 08, 2019 8:42 am
I had a similar bug before and it was because the OAM was not initialized properly and you would see some residual data at at startup. It could be the cause here.

Code: Select all

void clearsprite(void)
    unsigned char i;

    /* sprite init stuff */
    for(i=0; i<64; i++) {
        ppu_oam[i].x = 0xFF;
        ppu_oam[i].y = 0xFF;
        ppu_oam[i].attr = 0xFF;
        ppu_oam[i].pos = 0xFF;

the inition value is 0xFF not zero. if dont want to display sprites, just set all Y coordinates to 0xFF rather than disable the sprite rendering

Post Reply