Graphical glitches on the Everdrive

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Graphical glitches on the Everdrive

Post by krzysiobal »

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:
Image
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?
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

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.
comradesnarky
Posts: 1
Joined: Sat Aug 15, 2020 10:56 pm

Re: Graphical glitches on the Everdrive

Post by comradesnarky »

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
Goose2k
Posts: 320
Joined: Wed May 13, 2020 8:31 am
Contact:

Re: Graphical glitches on the Everdrive

Post by Goose2k »

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
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Graphical glitches on the Everdrive

Post by aquasnake »

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;

    nmi_enable(0);
    /* 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;
    }
    nmi_enable(1);
}

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
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Graphical glitches on the Everdrive

Post by aquasnake »

IMG_0562.JPG
IMG_0564.JPG
Graphics corruption appears in the pattern table
User avatar
socram
Posts: 14
Joined: Sat Jul 04, 2020 2:51 am
Location: Valencia, Spain
Contact:

Re: Graphical glitches on the Everdrive

Post by socram »

So I am helping a team develop a cartridge for the NES and found about this bug the hard way.

I tried the stress tests both my 2C02G boards experienced the same issue with graphical corruption. This is running on a very early prototype of the cartridge with plenty of bodge wires, that is connected to Famicoms using a cheap 72 pin to 60 pin adapter.
20230929_102050.jpg
20230929_105136.jpg
However, using an earlier version of the cartridge that has a smaller footprint and some different SRAM ICs but same Flash memory, this does not happen at all.
20230928_235212.jpg
Analyzing the OAM output buffers on the PPU die using Emu-Russia's Breaks PPU book, page 96, we can see the access to the OAM write latch is gated when the BLANK signal is no longer active, blocking access outside VBlank.

Thus I decided to mod Fiskbit's oam_corruption_stress_test to wait for the end of VBlank before continuing to run the LDA loop like this:

Code: Select all

HandleNmi:
  ; Check if we have already run NMI for this frame
  LDA donenmi
  BNE togglenmiflag

  INC glitch_value
  INC donenmi

togglenmiflag:
  ; If we are still inside VBlank, this will cause another NMI to be thrown
  LDA #$08
  STA PPU_CONTROL
  LDA #$88
  STA PPU_CONTROL
  ; NMI takes some time to generate...
  NOP
  NOP

  ; Clearly we are not in VBlank anymore - clear the done flag and return
  DEC donenmi
  RTI
  
And this, sure enough, solves the corruption issue on both machines. This begs the question: how is this physically possible? Why is the cartridge affecting the PPU in this fashion? Furthermore, why does loading the glitch value on the test ROM cause the corruption, but checking for the donenmi flag here or R/W the PPU control register does not?

According to the page 30 on the same PPU document, the access to the PPU's CPU communication bus is gated, isolated and plenty buffered from the actual CPU data bus unless the /DBE pin is asserted low, so nothing going on on the CPU bus should affect the OAM.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

The oam_corruption_test_v2.nes test ROM allows you to specify a delay (the 2nd number, controlled with A and B) in multiples of 9 CPU cycles. A delay of $DB is enough to delay the hammer until the prerender scanline. It doesn't hammer different values automatically, though, unlike the stress test, so you'd need to set the hammer value yourself (the first number, controlled with the dpad). I find a hammer value of $C0 to be particularly effective. With the delay parameter, I got the same results that you did, which is that corruption only happens when rendering is not enabled. I also found that on particular susceptible consoles, corruption can happen in as little as about 1 scanline of vblank hammering. My guess is that hammering is similar to decay and as long as you have OAM evaluation refreshing the DRAM cells often enough, the values are maintained. During rendering, the time between reads is small enough that the corruption does not happen.

I'm not much of a hardware guy, so hopefully those with a better understanding can chime in, but InfiniteNESLives did some testing of this a while back and discussed his findings on Discord. I've included relevant information from those conversations below, with light editing. I think the big takeaways are that the problem appears to be caused by signal reflection, longer traces make the problem worse, termination resistors (in-series resistors of around 27-100 ohms) in the cart fix the problem, and the problem is most severe on the higher CPU data bus bits (D7 and D6 cause most of the corruption). Putting the termination resistors close to the PPU has also been tested and did not fix the problem. Also, it is suspected that the frontloader is more susceptible due to its longer path to the cartridge, but the problem has been observed on the Famicom with the FDS, so it's not exclusively an NES-001 problem.

How we get from reflections to corrupted OAM is an open question, but the Sep 3, 2021 discussion below has some speculation.
Sep 23, 2020:
infiniteneslives: Hey @Fiskbit & @Matt Hughson I got to thinking yesterday evening after our discussion on CPU data vus reflections being the cause of Sprite glitching on front loaders. The extra long trace length with front loaders makes for an even longer transmission line which could explain why the issue is only seen on front loaders. Started wondering if I could replicate the issue with my own system simply by elongating the traces going to the cart. Bananmos sent me a pass through debug board a few years ago which does exactly that.
infiniteneslives: I was able to get similar glitching when using the debug board to elongate the traces.
infiniteneslives: It seems to show up anywhere there’s sprites to get corrupted. Your character using a large number of sprites seems to just be an easy place to spot the problem to test the hardware. It’s really only a hardware design concern from what I’ve seen.
infiniteneslives: Little more evidence supporting the transmission line termination: When my board has a memory present on the CPU bus even if not in use the problem seems to disappear. I started testing with a board that had 5v PRG ROM and PRG RAm present but unused and it wouldn’t glitch like the released board which didn’t have those memories on the bus at all.
infiniteneslives: So those memories being present but disabled could be enough to better terminate the transmission line and would explain why this problem hasn’t been seen with other games using this board. (Usually the 5v PRG-ROM is present since 512KBYTE is adequate.

Sep 24, 2020:
infiniteneslives: Had some interesting findings today that correlate with your datapoint of the $C0 ZP hammer being most “problematic” at corrupting OAM. Using bananmos’ debug board to replicate the problem I installed some 27ohm resistors in parallel with the boards jumpers. So I can effectively remove and insert the series termination resistors by inserting and removing the jumper to short out the resistor.
I found that the only termination resistors that were effective at removing the OAM glitching were CPU D6 & D7. In most cases either resistor removed the glitches, but some places like A53 menu needed both resistors to fix the glitches.
infiniteneslives: I tried a number of different timing tweaks to the mapper yesterday to present the PRG-ROM data early/later in the cpu cycle and it didn’t have much impact if any. So also agrees with your test findings that use the zero page as a data bus hammer. The problematic reflections are likely sourced from the main board (SRAM) and get reflected back from the cartridge. So it’s the physical presence of the cart’s unterminated transmission line that’s the problem, not data transitions that are sourced by the cart.
infiniteneslives: It could be that consoles which are more or less problematic are due to drive strength differences of the main board RAM/CPU
infiniteneslives: Been play testing the A53v3 cart, if D5 doesn’t have a termination resistor, I get glitches very infrequently with twin dragons. Usually visible on the dragon head during the death screen.

Sep 3, 2021:
infiniteneslives: Apologies, was bored and looking through old topics. So my current theory/curiosity on this OAM corruption is if the CPU D6 & D7 traces run nearby OAM DRAM on the PPU die? I found most consoles aren't sensitive enough to this, but using the ~4 inch extender banamos gifted me was able to generate the problem on most consoles. 30-100ohm series resistors on CPU data bus resolves the issue (especially on upper nibble, and especially D6-7.) If the CPU D6-7 die traces run close to OAM DRAM cells/signals, it wouldn't be too crazy for PPUs with weak cells to be sensitive to on die cross talk from hefty reflections coming all the way back from the distant cartridge. If someone takes the time to investigate 2C02 I'm very curious to know.
lidnariq: That's a good hypothesis ... but I just looked at visual2c02 and D0 and D1 are closest to the DRAM :(
infiniteneslives: Interesting.. Suppose could be any number of items in the DRAM circuitry as well though. No clue what the write/refresh portions might look like and how far they might venture from the DRAM or CPU data.
lidnariq: On the die, each bit has its own section of DRAM, from D7 at the top to D0 at the bottom (in the orientation used by Visual2C02)
infiniteneslives: completely unfamiliar with the 2C02 layout, does DRAM happen to be block on top right? (colored mostly yellow on left, and purple/magenta on right)
lidnariq: Yes
infiniteneslives: So D6 & D7 sections are most separated from the rest of the die.. Maybe more susceptible to off die signals.? Seems like stretch...
lidnariq: I was making a pretty diagram of regions, but the top half can be divided into 9, 9, 9, and 7 rows for the bits held in D7, D6, D5, and D4
lidnariq: the traces going around the top and right from inside to out are pclk0 ("left half dot"), D0, D1, &c
lidnariq: Maybe reflections are causing voltage dumping either below or above the power rails in at D7, and that's bleeding into the power rails on the DRAM controller?
infiniteneslives: ok yeah, I was confusing D7 D6 of OAM vs CPU data bus for a min.
infiniteneslives: best theory we've got I guess.
infiniteneslives: Would be interesting to see if adding capacitance near PPU power pins would resolve the issue.
infiniteneslives: If it's noise being injected in the power, perhaps it's an indication time for a recap..? hmm.
infiniteneslives: Seems like hopeful thinking, but would be pretty good information to know if ends up proving true.
lidnariq: If that's true, fast diodes on the data lines protecting against over- and under- voltage should work as well ?
infiniteneslives: perhaps, you're suggesting diodes on the D7 & D6 CPU bus pins of the PPU right? With reflections mostly shown to be the cause of the problem, that would have shot at solving the issue regardless of the method in which the corruption is occurring.
lidnariq: yeah

Feb 5, 2023:
infiniteneslives: FWIW I’ve been using single 3.3v supply 74LVC16245 and 162245 for over a decade now without any problems on NES, SNES, & Genesis.
The 30ohm termination version (74LVC162245) resolved issues I had with OAM corruption when there’s memory behind the levelshifter requiring bidirection.
If the databus is only unidirectional (ie MMC3 input) the termination resistors aren’t needed. I’m only speaking to the NES CPU bus though.

Mar 26, 2023:
infiniteneslives: I found it on action53 carts which don’t have PRG-RAM. So the only thing on the carts CPU data bus was a level shifter.
IIRC adding a rom/ram to the cart might have stopped the issue due to added impedance.
Fix for me was termination resistors on CPU data bus or level shifters with built in 30ohm termination resistors.
infiniteneslives: You can create the issue on consoles that don’t normally exhibit the problem by putting the cart on an extender. Kind of like a long game genie.
infiniteneslives: I saw the issue on my eart EPROM/flash boards with SNROM. Zelda would glitch on the title screen if the mapper controlled PRG-ROM /CE instead of /OE (might have it backwards).
I couldn’t figure out why that mattered at the time, but now my assumption is I was changing the access time and/or databus impedance which would impact the reflections and their timing.
User avatar
socram
Posts: 14
Joined: Sat Jul 04, 2020 2:51 am
Location: Valencia, Spain
Contact:

Re: Graphical glitches on the Everdrive

Post by socram »

The reason why waiting for the end of VBlank works is because of this (extract from the aforementioned PPU reverse engineering document):
refresh.png
In red is the travel direction of the data from the CPU bus in the PPU, while in blue is the travel direction of the bit already present in the OAM for refresh purposes. When outside the VBlank, that "BLANK" is low and disables any input at all from the DB_In bus, so no matter what's in that bus, it would not affect the OAM.

But still, that does not explain why the CPU data bus signal is even getting to the PPU's CPU bus in the first place while writes are not being performed to the PPU. The thing is that the PPU uses an already protected and buffered version of the CPU data bus:
closeup.png
I'm FAR from an expert in silicon design, but from what I've seen in Visual2C02 and in that document explaining In theory, the PPU's CPU data bus is only accessible if the /DBE pin is asserted low and the R/W pin is high, else it is kept at high impedance.

That means that no matter what, the CPU data bus shall have no effect on the internal PPU data bus. Yet, as we can see, it does.
User avatar
socram
Posts: 14
Joined: Sat Jul 04, 2020 2:51 am
Location: Valencia, Spain
Contact:

Re: Graphical glitches on the Everdrive

Post by socram »

So i got out the scope and probed the CPU D0 and D7 pins. First, here it is from the cart that fails:
bad_cpud0.png
bad_cpud7.png
Here from the cart that works properly:
good_cpud0.png
good_cpud7.png
There's no any significant change between both. What I did notice though was how the R/W is reading, with both, a dangerously close to the minimum acceptable high level threshold for CMOS logic:
rw.png
Adding a pullup resistor brings higher the voltage closer to 5V but does not make any difference when it comes to OAM corruption.
User avatar
socram
Posts: 14
Joined: Sat Jul 04, 2020 2:51 am
Location: Valencia, Spain
Contact:

Re: Graphical glitches on the Everdrive

Post by socram »

Another small update - I modified the stress test to write a pattern of 0x55 0xAA 0x41 0xAA, and read back on demand pressing start. This is the contents of the OAM after less than a second:
20230929_163009.jpg
For this 2C02G PPU in particular, the affected bytes are 0x40-0x47 and 0x80-0x87, and even within those, only the upper 4 bits seem to be affected.
Attachments
oam_corruption_readback.asm
(6.63 KiB) Downloaded 11 times
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: Graphical glitches on the Everdrive

Post by coto »

I have no experience with NES other than NesDS, but given Nintendo added rudimentary HDMA on the SNES, and then fixed the HDMA design on the GBA by allowing writes of VRAM, OAM, and Palette RAM Access ONLY during HBlank and VBlank, then i'd say OAM is being corrupted because of external interrupt (of any kind) on the CPU, which takes over the clock signal fed into the OAM's refresh rate (clock signal latching), which feds also from the PPU clock signal. Hence, the missing lines are due to the open bus result. I'd bet reading the clock signal between the OAM and PPU on these faulty lines are open bus, same for Palette RAM.

So I think a tristate between the CPU and the OAM clock signal, connected to PPU /CE would fix it
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

I was reminded by lidnariq that Finny on Discord had also weighed in on this and suggested another possibility that may be responsible instead of or in addition to reflection:
Mar 26, 2023:
Finny (grievre/arreffem): Do we know that it's a reflection problem fixed by termination and not an overshoot problem fixed by dampening?
Fiskbit: I'm not sure how dampening is done. I don't know if a resistor in series dampens or not.
]
Finny (grievre/arreffem): I'm not 100% on this but I believe you increase the damping factor whether you add resistance in series or in parallel. With a simple series RLC circuit the damping is proportional to R, with a parallel RLC circuit the damping is inversely proportional to R.

This makes intuitive sense to me--if you put a resistor in the path of the signal, it will take some power from it as it travels through with higher resistance taking more power from it. If you add a shunt resistance, it will bleed off some of the current as it passes by, lower resistance = more power sapped.

I'm using kinda wishy-washy terms here.
Finny (grievre/arreffem): The concept of damping comes into play any time you have a second order diffeq involved. The step response of such systems involves solving a quadratic--if the system is overdamped, the quadratic has real roots and the step response is a pair of exponentials. If the system is underdamped, the quadratic has complex roots and the step response is a decaying sinusoid.
Finny (grievre/arreffem): It seems like he's saying: if something behind the level shifter drives the bus, it causes the problem, unless there is something in front of the level shifter even if that thing is not driving the bus
Finny (grievre/arreffem): that also seems to make sense to me since adding more stuff to the bus = adding bus capacitance, which could slow the edges down.
Finny (grievre/arreffem): Oh now I remember, I wasn't testing with pulldown resistors, I was testing with shunt capacitors and that did seem to improve it (but not enough to make them a compelling choice over series resistance)
Finny (grievre/arreffem): I honestly feel a little hesitant to call it that because it's not a controlled impedance to begin with. The whole thing is impedance mismatches. I also balk at using the word 'termination' because it might mislead people into thinking we're adding a matching resistor when it feels to me like we're just adding dampening.

The fact that added parallel impedance also seems to fix the issue makes me think it's unlikely to be the textbook case of reflection from an impedance mismatch: In that case, more load impedance in parallel seems should make the reflections worse, not better.
Finny (grievre/arreffem): Even if it is a transmission line impedance type issue, I think what we're doing is not termination. Rather, we're making the line lossy like an oscilloscope probe--by adding resistance at some midpoint of the transmission line we cause pulses going in either direction to be attenuated, which will reduce reflections even if the characteristic impedance is not matched.

My brain really wants to cause it a parasitic inductance issue rather than a transmission line impedance mismatch issue, but as lidnariq pointed out this might be a to-may-to to-mah-to situation.

Jun 17, 2023:
Finny (grievre/arreffem): Does anyone know which versions of the FDS RAM adapter tickle the reflection issue?
Fiskbit: Do the versions differ in this regard? I'd expect the console to make the difference, not the RAM adapter.
lidnariq: It's conceivable that they could have added the resistors like we did on the PowerPak, but I think that Electronics Junker's schematic doesn't show any variation there
Finny (grievre/arreffem): Differences in the chips that change their drive strength would be my expectation, if there were a difference
Finny (grievre/arreffem): I'm also curious whether it's the 2C33 or the DRAM that causes it, or both.
Fiskbit: The other notable thing with the FDS is the longer connector in the cartridge, which worsens this problem.
Finny (grievre/arreffem): I suppose the only way for me to experiment is to find a combo that actually produces the issue
Finny (grievre/arreffem): Also with respect to this, sorry to resurrect this thread especially if I already said this before: You could use an AC shunt impedance, e.g. a series R+C. If you tune the values right, it would absorb any short-timescale behavior like ringing or reflections while still allowing the data lines to hold their voltage when not driven.

Sep 29, 2023:
Finny (grievre/arreffem): I'm hesitant to say it's not reflections. Rather, it may be some sort of reflection or ringing issue that is exacerbated by a stronger driver on the line whose output impedance doesn't dampen the circuit enough
Finny (grievre/arreffem): The transmission line model and lumped element model are like wave vs particle models of light. They are equally right and equally wrong, just sometimes one is more useful.
Regarding the readback test, what I saw in my testing is that corruption was fairly consistent, and each hammer value tends to cause very specific corruption, with the most corruption happening at higher values. It takes 256 frames for the stress test to cycle through all 256 hammer values. I never looked into the specifics of exactly how the values were corrupting and if certain bits were immune; those may be interesting results.

Regarding vblank vs not vblank, are you sure that circuit should prevent this problem? Isn't that assuming a mechanism for this corruption?


coto: What you're describing doesn't really make sense in the context of NES. The OAM DRAM is inside the PPU and refreshed as a consequence of OAM evaluation during rendering; as long as rendering is enabled, OAM is refreshed sufficiently often by the PPU itself to avoid decay, and the CPU has no influence on the PPU's input clock. Through the PPU OAM registers, the CPU is able to write to OAM outside of rendering and read from OAM on revision G and H chips anytime, but the CPU is otherwise completely isolated from OAM. In these corruption tests, the CPU sets up OAM once and then never touches it again, but the subsequent activity on the CPU data bus causes decay-like behavior in OAM.
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: Graphical glitches on the Everdrive

Post by coto »

Fiskbit wrote: Fri Sep 29, 2023 4:17 pm coto: What you're describing doesn't really make sense in the context of NES. The OAM DRAM is inside the PPU and refreshed as a consequence of OAM evaluation during rendering; as long as rendering is enabled, OAM is refreshed sufficiently often by the PPU itself to avoid decay, and the CPU has no influence on the PPU's input clock. Through the PPU OAM registers, the CPU is able to write to OAM outside of rendering and read from OAM on revision G and H chips anytime, but the CPU is otherwise completely isolated from OAM. In these corruption tests, the CPU sets up OAM once and then never touches it again, but the subsequent activity on the CPU data bus causes decay-like behavior in OAM.
Your hypothesis doesn't explain why that happens under certain cartridge setups, besides, that seems to happen under older NES hardware revisions.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

Everything you quoted there isn't hypothesis, though; it's fact about how the NES hardware is structured. We also have software that proves that certain values on the CPU data bus trigger the corruption, and it has been demonstrated on many consoles with many cartridges that merely putting resistors on the CPU data lines in the cartridge fixes the problem.

Exactly how OAM corrupts from what is happening on the CPU data lines is not known for sure, and that's where I defer to the people who clearly have a much stronger hardware understanding than I (see Discord quotes above). I don't think we even have solid information yet on what official PPUs are affected by the problem, and whether it's just the PPU and cartridge that matter, or also the CPU, RAM, and board.
Post Reply