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

niconii
Posts: 219
Joined: Sun Mar 27, 2016 7:56 pm

Re: Graphical glitches on the Everdrive

Post by niconii »

Fiskbit wrote:I'm actually planning to do some OAM decay testing in the near future; I'd like to get an idea of how long it takes before decay occurs and how it tends to decay. Beyond just understanding it better, I'm curious if it could have utility (could it reasonably be used as a source for randomness?).
Early Famicoms and NESes don't let you read OAM at all, since OAMDATA ($2004) is a write-only register on those consoles, so even if it were a decent source of randomness, you wouldn't be able to use it on those consoles.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Graphical glitches on the Everdrive

Post by lidnariq »

On the 2C02{A/B/C/D/E} you could theoretically still use sprite 0 hits to track decay.

But even then, the 2C07 never fully disables refresh and DRAM decay doesn't happen there.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Graphical glitches on the Everdrive

Post by Sour »

Fiskbit wrote:As far as emulation goes, for development, having realistic decay timings seems pretty important.
To be fair, I don't think anything beyond "the RAM will never decay in less than X milliseconds" is really necessary (and even then, I would expect this to vary to some extent from one unit to another?) And I don't believe OAM DMA needs to be run to preserve OAM RAM during lag frames? The PPU's regular rendering should keep the OAM refreshed, afaik.
Fiskbit wrote:though the debugger breaks on decayed reads even when sprite rendering disabled, which is of questionable utility and makes the feature pretty useless for this Chicken of the Farm ROM because of so many false positives
This can be considered a bug - there's no reason to break the debugger because the PPU read a decayed byte if sprite rendering is disabled (unless the byte was read through OAMDATA) - I'll fix this.

In terms of existing licensed/bootleg games, it can probably be assumed that the majority of them do not have decay-related issues and are not affected by OAM decay. "Proper" OAM decay emulation is probably not really possible since it's a physical phenomenon that is essentially random - it's kept as an option in Mesen to help homebrew developers and romhackers, but since it would likely reduce compatibility with older romhacks/homebrew/etc, I don't really plan on ever enabling it by default.
lidnariq wrote:But even then, the 2C07 never fully disables refresh and DRAM decay doesn't happen there.
Speaking of which, I discovered yesterday that nocash's Magic Floor game actually is affected by OAM decay (which makes sense since he most likely built it on a PAL NES). I had kept the decay option turned on after posting that screenshot and for a little while, it got me convinced that I had somehow broken the mapper's emulation with the code refactoring that I was doing.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Graphical glitches on the Everdrive

Post by tokumaru »

I didn't know that the PAL NES never stops its OAM refresh cycle, even when rendering is off... Does that mean that the typical first program everyone makes for the NES (draw a background, set the palette, DMA the sprites and turn rendering on, without any regard for PPU synchronization) is very likely to end up with corrupted sprites?
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Graphical glitches on the Everdrive

Post by rainwarrior »

Realistic decay timings would involve simulating the temperature of the chip since it turned on, and probably also accounting for the temperature of the environment around it. A room temperature setting on an emulator would be interesting, ha ha ha.

I think there was a story about Nintendo demonstrating a baseball prototype and using a can of compressed air to cool the PPU to keep the decay bug from showing in the demo.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Graphical glitches on the Everdrive

Post by tepples »

rainwarrior wrote:I think there was a story about Nintendo demonstrating a baseball prototype and using a can of compressed air to cool the PPU to keep the decay bug from showing in the demo.
That or it was a story by Andrew Davie on the NESdev Yahoo! Group about proving to Nintendo that one of the consoles used for lot check on The Three Stooges was malfunctioning.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

@Nicole/lignariq: Yeah, earlier hardware not supporting $2004 reads is an unfortunate limitation, for sure. lidnariq's sprite 0 trick is a neat workaround I hadn't thought of before.


@Sour: The lag frame case I was talking about was specifically with sprite corruption I observed during lag frames with Zelda being run on an Everdrive, which was fixed by using a different AC adapter. Whether this was an issue with faster decay or not, I don't know, but mitch3a's problems only being noticeable on Everdrive definitely makes me wonder.

Defaulting to decay-off seems reasonable particularly given the older homebrew constraint.


@tokumaru: My understanding based on results from this thread is that PAL enables OAM refresh during scanlines 24-69 to prevent decay during PAL's longer vblank period, during which OAM is not accessible by software (this is why it's wise to do OAM DMA first on PAL-specific software before other vblank work). It does this even when rendering is disabled. Whether you get decay on PAL with rendering disabled depends on whether the rest of the frame is long enough for decay, which seems likely to me given that it's a much larger time window than what this forced refresh was added to cover.

If you did OAM DMA with rendering off on PAL with no regard for timing, there's a nontrivial chance it would overlap that forced refresh region, which I would expect to cause corrupted sprites.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Graphical glitches on the Everdrive

Post by tokumaru »

Fiskbit wrote:@tokumaru: My understanding based on results from this thread is that PAL enables OAM refresh during scanlines 24-69 to prevent decay during PAL's longer vblank period, during which OAM is not accessible by software (this is why it's wise to do OAM DMA first on PAL-specific software before other vblank work). It does this even when rendering is disabled. Whether you get decay on PAL with rendering disabled depends on whether the rest of the frame is long enough for decay, which seems likely to me given that it's a much larger time window than what this forced refresh was added to cover.
According to the wiki, there's forced refresh after 21 scanlines of vblank, but also during the visible part of the picture, even if rendering is disabled. This means that OAM decay *never* happens in PAL systems, because except for those 21 scanlines, OAM is constantly being refreshed.
If you did OAM DMA with rendering off on PAL with no regard for timing, there's a nontrivial chance it would overlap that forced refresh region, which I would expect to cause corrupted sprites.
The problem is that apparently the forced region is most of the frame (291 scanlines out of 312, or 93% of the time), so there's a huge chance that the typical beginner's program (which does a single OAM DMA whenever) will not work correctly on PAL. Has this ever been reported by anyone before?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Graphical glitches on the Everdrive

Post by lidnariq »

Fiskbit wrote:My understanding based on results from this thread is that PAL enables OAM refresh during scanlines 24-69 to prevent decay during PAL's longer vblank period, during which OAM is not accessible by software [...] Whether you get decay on PAL with rendering disabled depends on whether the rest of the frame is long enough for decay, which seems likely to me given that it's a much larger time window than what this forced refresh was added to cover.
You would think that. And yet ... decay hasn't been observed on 2C07 ever.

So it can't just be evaluating OAM = refreshing DRAM during those specific scanlines.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

Interesting. So, the wiki references this thread where thefox couldn't get OAM decay to occur on PAL, citing this as the source for having 20 safe scanlines (which was considered approximate). I don't know if that's also the source for the statements about refresh occurring everywhere but early vblank or not. Looking at the thefox's results from Sour's tests again, with rendering disabled, there were tests and test runs where reads outside of vblank worked, and ones where they didn't. It looks like we never got clarity on why this was the case, so there appears to be further room for research here.

These tests did refine the measurement of the safe vblank region to the first 24 scanlines, however, which is good because that is large enough to cover the length of NTSC vblank.
User avatar
Diskover
Posts: 219
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: Graphical glitches on the Everdrive

Post by Diskover »

A few years ago, when I was programming The Banketh, I also had a series of graphic and sometimes ROM problems that proved my progress.

In the PC emulator it worked correctly. When I was recording on PRG and CHR on the board, it also worked correctly. But when I put the ROM in the SD and threw it in the Everdrive, errors appeared.

In the end it turned out that the ROM was not recorded correctly in the SD that it used and the solution was to change SD.

Once this was done, the ROM already worked well in the Everdrive.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

I ran thefox's oam-decay-test.nes on my Everdrive and found the results pretty interesting. If I provide no input at all (so rendering is enabled, but OAM is not being rewritten each vblank), I lose 2 sprite tiles (tiles 48 and 56), usually at the same time, after about half a second, and then 4 more (tiles 26, 38, 46, 54) simultaneously at about 3 seconds, and occasionally another (tile 50) a little later. These results are pretty consistent. I also often have a gap of 2 missing, consecutive tiles immediately after reset, though never when opening the ROM from the Everdrive menu, and which 2 tiles seems fairly random.

If I hold A to induce decay, then the tiles scramble and eventually disappear, as expected, except for sprites 0 and 1, which remain untouched even after substantial time without rendering (1+ minute).

I asked someone with video capture to run the test on his own console+Everdrive and the results are similar to mine, but the tile loss with rendering enabled is even more extreme than on my hardware. This clip shows tile loss while rendering is enabled, as well as the 2 missing tiles on reset. This other clip shows decay from disabling rendering, with the same behavior of tiles 0 and 1 remaining after everything else has disappeared.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Graphical glitches on the Everdrive

Post by lidnariq »

Fiskbit wrote:except for sprites 0 and 1, which remain untouched even after substantial time without rendering (1+ minute).
This is actually as expected... "pclk0" never stops, and one of the rows of DRAM is always selected. So one row's worth of data, which if OAMADDR is 0 is the eight bytes for sprites 0 and 1 and the first byte of secondary OAM, won't lose its value when refresh is disabled.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Graphical glitches on the Everdrive

Post by Fiskbit »

lidnariq: Thanks, that makes sense!


I threw together my own OAM decay test because I wanted to gather more information (in particular, adding a numbered graphic for every possible sprite tile ID so they don't just disappear when the ID decays). Curiously, the unusual behavior I encountered with thefox's test is not present with mine: tiles aren't lost when rendering is enabled, and all of the tiles are present on reset [Edit: The tile IDs also don't change, as far as I can tell; there is no apparent change in properties for any tile]. I'll have to dig into his test to figure out what is functionally different.

My NMI loop is pretty different (disables NMIs after first triggering), but I had a more traditional setup along the way that didn't seem different at all. The one major difference between these tests that I'm currently aware of is that mine reads input in a tight loop, enabling and disabling rendering immediately regardless of where we are in rendering the current frame. Sprites 0 and 1 are not always the ones to be unaffected by decay, which I presume is because of this difference in timing.

I've attached the test in case anyone wants to play with it or look at the source.
Attachments
oam_decay_test_fiskbit.zip
(48.07 KiB) Downloaded 457 times
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Graphical glitches on the Everdrive

Post by lidnariq »

Fiskbit wrote:The one major difference between these tests that I'm currently aware of is that mine reads input in a tight loop, enabling and disabling rendering immediately regardless of where we are in rendering the current frame. Sprites 0 and 1 are not always the ones to be unaffected by decay, which I presume is because of this difference in timing.
Yeah, OAMADDR is known to be left at whatever random value when you disable rendering.

We've found that disabling rendering at the "wrong time", even if there are no sprites on that scanline, will corrupt OAM ... at least on the 2C02. I don't know about the 2C07.
nesdevwiki:Errata wrote:Turning rendering off in PPUMASK ($2001) before the PPU has finished evaluating sprites for that line (x=192 for lines with no sprites, x=240 for lines with at least one sprite) can corrupt OAM, leading to sprite flicker.
Post Reply