nesdev.com

OAM is organized as 36 words of DRAM, each 58 bits in length. Each 58-bit word corresponds to an even-odd pair of display list entries: sprites 0 and 1, sprites 2 and 3, sprites 4 and 5, ..., sprites 62 and 63, secondary OAM entries 0 and 1, 2 and 3, 4 and 5, and 6 and 7.

Because merely reading a word of DRAM causes it to decay, the refresh circuitry reads a word and writing it back to the same address. But if the address it reads and the address it writes back differ, the data at the address it writes back is lost. For example, it normally refreshes the word for sprites 0 and 1 by reading the word for sprites 0 and 1 and writing it back to the word for sprites 0 and 1. But before it has stabilized, it may mistakenly read the word for sprites 0 and 1 and write it back to, say, the word for sprites 6 and 7. This means instead of sprite 0 being on one set of scanlines and sprites 1, 2, 3, 4, 5, 6, 7, 8, and 9 being on another set of scanlines, you end up with sprites 0 and 6 being on set of scanlines and sprites 1, 2, 3, 4, 5, 7, 8, and 9 being on another set of scanlines, because the data for sprite 6 was overwritten with the data for sprite 0.

Dug out my EPROM writer today and tested this on both my NES and my Famicom. I can't seem to reproduce the problem, it runs fine on both. Tried power off for various lengths of time, tried both the original ROM and the slightly modified one I just made.

So... I dunno. Only affects some systems, I guess?

@tepples:

Thanks for the explanation.

Can this problem happen anywhere or does it only happen at the start?

Because I never encountered an issue where the game randomly crashed during gameplay. It's only either at startup or not at all.

So, if the decaying and the writing back at incorrect locations can happen anytime, this is probably not the issue at hand. Otherwise, I think the bug would have occured many times in all possible situations. Because in my actual game, during a level, the game checks for sprite overflow and requires a positive result in every single frame.

If it's an issue related specifically to startup:
I guess this can be tested by simply putting all sprites on the same scanline instead of just nine and see whether the bug still happens.


Well, for the test ROM, I had to take the publisher's word for it that the error still occurs. I couldn't try it out myself.
If you promise me not to give it to anybody, I can send you the old ROM of "City Trouble", i.e. the game that I can confirm for myself has the error, so that you can see whether the test ROM from above actually doesn't have the problem anymore and the publisher told me the wrong thing or whether your game board is simply one of the more tolerant ones where the error doesn't occur as frequently.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

If you want to send me a ROM I'd be willing to test it. The board I'm using is an old RetroUSB ReproPak with old UV eproms, pretty minimal, nothing "weird" I don't think.

Did your publisher test the test ROMs or just the game? (I'm just wondering if anyone has independently verified the test ROM to hang in the way you expect.)

I'm a little disappointed nothing unusual happened with the test ROMs for me. I was hoping to learn something new.

The publisher told me that he also tested the test ROM and that it produced the same error. But I have no way of confirming this.

If there's a way to set the Power Pak to "load a specific game immediately and skip your own menu", I could see whether all of this can be reproduced with a PowerPak.

I'm sending you the "City Trouble" ROM in a few minutes.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

I believe some people have tried replacing the menu software to automatically boot a game at power-on, but it still needs to program the FPGA and copy the game from the CF card to its RAM. There's no non-volatile storage available to execute the game's code immediately.

Having been given the City Trouble test ROM, it has no problem starting up on my NES or Famicom.

So... it's at least consistent with the test ROMs for me in that it's a "negative" result. So... I dunno, all I can say is the problem may not extend to all NES units, or maybe not to all boards? I dunno.

That was the result I was hoping for. If "City Trouble" had frozen, but the test ROM not, then the publisher's test would have been false and the posted test code wouldn't actually have included the issue to analyze.

Memblers was able to recreate the issue with "City Trouble". Maybe he could check the test ROM. I still have one message to him that he hasn't replied to yet. When he gets back to me, I can ask him.

Besides, I assume it's more "the issue doesn't appear on all boards" instead of "the issue doesn't appear on all NES units". I'm pretty sure if you tried my faulty cartridge of "City Trouble" on your NES, you would see the issue because the two cartridges already produced different results on the same console.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

The other thing I'm noticing is that in your City Trouble game the first $4014 write occurs like 10 frames after power on. Even in the test example, it's a good 4 frames before the test is done.

Like, maybe this has nothing at all to do with "PPU warm up", or any period of time really, but instead just what happens on the first frame with rendering on. Garbage left in the sprite system at power on that normally gets flushed out on the first rendered frame? (This is probably the first time anyone has ever tried to use the sprite overflow flag on the first frame?)

You mentioned that PAL is not subject to this, which I think has been established always does some sort of sprite refresh even when rendering is off?

If you can, get my variant ROM posted above tested on a system where it fails, and see if there's any visual indication of and of the 9 sprites missing?

I'm not sure whether this can be the issue, in case I'm understanding you correctly.

Have a look:
Before enabling NMI, I set the boolean WaitForNmi to 1 (true). Then I enable the NMI.
As long as WaitForNmi is 1, the game logic (which includes the overflow check) is skipped completely.
I.e. the game logic doesn't start until NMI has actually run for the first time.

And in NMI, the PPUMASK is set and the sprites are always updated anyway:
So, as far as I see, the overflow check cannot suffer from any garbage data because it is guaranteed that all sprites are written to OAMDMA before the overflow check is done.

NMI, not the game logic, is always the first thing that gets executed due to the WaitForNmi variable being initialized with 1 and the game logic checking:
if WaitForNmi != 0 then goto gameLogicEnd

Does this disprove your assumption or is there anything that I overlooked?


I can ask my publisher to do this, sure.
Although I was hoping that someone on the forum has the equipment to do quick tests. The publisher always takes a while until he gets to it.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

I wasn't talking about garbage in the OAM data. I was talking about some internal state of the sprite system that somehow causes sprite overflow to fail on the first frame, something you can't actually initialize via code, but has to be flushed by the process of rendering a frame.

I'm reminded of how turning off rendering at an unlucky point during the visible frame will corrupt the appearance of sprites on the next frame. Maybe the power-on state of the sprite system is in a similar way.

That's maybe possible, but of course I have no way of confirming or disproving this. How can such a thing reliably be validated?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

I noticed similar strange behavior after pressing the Reset button during development of Concentration Room: two sprites were missing from the logo of the Party (since replaced with that of Hombon). This was an early version that cold-opened on the story, from before I added the title screen.

Try OAM reset, then press Reset a few times to see what drops out. If sprites 02-09 ever drop out, then there's a chance of misbehavior of the sprite overflow flag.

This ROM seems to do the OAM DMA around scanline 80 of the third frame, and then finally enables rendering via $2001 maybe 12ms later. That interval by itself should be subject to OAM decay. Is it supposed to test anything else besides that?

I don't think OAM decay is the issue at hand... shouldn't any test we do make sure to rule it out? (i.e. it would be a very good test if it executed OAM DMA during vblank along with the initial $2001 enable)

Here's a modification of tepples' OAM reset ROM to do what I said (i.e. wait for vblank and synchronize OAM turning on and first frame of rendering, eliminating OAM decay)

There's a huge difference in behaviour for the two of them, for me:

1. In this new patched version, on some resets exactly two consecutive sprites are sometimes missing (seemingly randomly selected; sometimes none are missing).

2. In the original, on each reset, often two consecutive ones are missing, sometimes others are missing in addition to that, and sometimes the whole set of sprites is messed up.

So I think in the original we had two things happening together, one being OAM decay (from that long interval before rendering is turned on) on top of the corruption due to being reset in the middle of sprite evaluation? In the patched version I think it's demonstrating just the corruption from reset.

...and what this might suggest is that the first frame of sprites are not 100% reliable after reset, and I think on some systems it might have the same problem on power-on (i.e. having a somewhat consistent power-on state for that system that reliably corrupts in the same way, but unique to that system)?