It is currently Wed May 22, 2019 5:52 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Jan 09, 2019 1:55 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 214
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.


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 2:43 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8367
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 3:04 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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.


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 5:38 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11348
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 6:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7461
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 8:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21392
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed Jan 09, 2019 11:04 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
@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.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 1:16 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11348
Location: Rio de Janeiro - Brazil
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.

Quote:
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?


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 1:45 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8367
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 1:52 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
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.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 1:54 am 
Offline

Joined: Thu Nov 24, 2011 7:16 am
Posts: 210
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.

_________________
Projects:
Shadow of the Beast (port)
The Sword of Ianna
The Banketh - The Video Game

My website: RetroNES


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 12:06 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
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.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 1:07 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8367
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 5:49 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 71
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 77 times
Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 1:12 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8367
Location: Seattle
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.

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group