nesdev.com

...and testing again City Trouble with this knowledge, I note that I can crash it on startup via reset. Even though it is consistently safe at power on for me, reset is not. (I was not testing reset before.)

So I think on some systems, the power on state will give a ~100% chance of failure of the test, and on other systems (like mine) it's ~100% chance of success.

Reset, on the other hand seems to have like a ~10% chance of failure, now that I'm looking at it! (This probability is likely consistent across a lot of systems.)

I think this is actually a sufficient explanation for the problem!

So, the rule is: Don't do anything important with sprites during the first frame?

Besides, what does the altered test ROM (where the nine sprites are laid out and numbered) show if you crash it via reset?

_________________
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

It will show 2 consecutive sprites missing from the overflow line. (The oam_reset2.nes ROM demonstrates this better though, since it shows the whole OAM not just the ones used for that overflow test.)

You can actually do the reset test on PowerPak too. I can crash your City Trouble test ROM via reset on my PowerPak. (PowerPak is perfectly fine for RESET testing, just not POWER.)

After burning an EPROM of oam_reset2.nes to test the power on state, on my NES it comes up clean on every power-on, but I'd say 50% or so of resets have 2 consecutive sprites missing. (The 2 consecutive sprites always begin on an even number, I tihnk. I neglected to mention this before.)

My Famicom also always has a clean power-on oam_reset2.nes but it seems interesting to note that it is still subject to the reset problem despite the PPU not getting a reset? That one surprises me. Why does this still happen on the Famicom? (The 2-sprite reset corruptions seem less frequent, I get clean resets more often, I think, but they still happen regularly, like maybe 25% of the time instead of 50%.)

Because the PPU gets a mid-scanline LDX #0 STX $2001, which may have the same effect on the sprite evaluation and refresh state machine as a reset.

Aha! That explains it.

So if you wait for vblank on the famicom before disabling rendering (or just don't disable it at all) you shouldn't get any glitches after resetting, right?

Yes, this appears to be correct. (With oam_reset3.nes no sprite deletions appear to occur on reset for my Famicom, and sprite deletions definitely still occur on my NES.)


So, the thing I can't verify with my systems is whether other systems have consistent corruption on power-on. It would be useful if people could run (non PowerPak) oam_reset2.nes on various machines to see their power-on state. (Especially DRW's publisher's machine.)

tepples, you seemed to know more precisely what's happening? You mentioned corruption of specific 8 byte blocks earlier. (Do the blocks get filled with all $FF? I never seem to see stray/random sprites, just deleted ones...?)

One line of RAM (i.e. sprite pair) should get copied over another ... unfortunately there seems to be no way (other than running out of sprites) to tell when two slots have the exact same data.

Hm, with oam_reset2.nes I always see exactly two sprites missing, never more.

If a low number sprite had been copied over a later one, there should be additional missing sprites from 8-per-line dropout, right? I'm not seeing this, though.

So... does this suggest that the sprites are always copied from somewhere in 56-63? Or possibly are always copied from somewhere in the same 32-byte "quad-line"? Or... I don't know how to explain this.

I've seen missing sprite pairs as low as 02-03 and as high as 62-63... still haven't caught 00-01, if that's even possible, but I think I've probably seen them everywhere else.

Oh wait, this means it's always copying from 00-01 to the "missing" sprites, doesn't it.

(Unsure if that's because the program loads $2003 with 0 before the DMA? Can it copy from other locations?)


Edit: added another variation ROM that verifies/demonstrates that there are extra sprites on 0/1 with a diagonal organization of the sprites. In this example the top right corner 63 will always drop out from the extra 00, and the bottom left corner 56 will usually drop out (unless the copied sprite is 57+).

Sorta funny, but I guess that means if DRW had used sprite 0-8 instead of 1-9 for overflow this problem wouldn't have come up.

(I hope tepples doesn't mind that I've patched his ROM half a dozen times tonight.)

Since on my NES "City Trouble" only had problems during startup, but not during reset (except for some rare occasions), I assume the test ROM would be the same.
Unfortunately, I have borrowed the PowerPak away to my colleague, so I cannot test it in the moment anyway.


I can send him the ROM, but I don't think that's necessary because I assume we already have the answer:
The old ROM of "City Trouble" freezes on my machine, on the publisher's machine, on Memblers' machine and on one or two confirmed machines from people on the internet when they user power on.
"City Trouble" always relied on the nine overflow sprites being there.
Therefore, "City Trouble" freezing means that missing sprites occur on these persons' machines as well.

(The only interesting thing might be whether these are always the same sprites that disappear, but I don't know whether I should bother my publisher with such an issue. After all, this question which sprites disappear is too general-purpose now and not really tied to our specific game and original problem anymore.
I think Memblers would be the better tester here.)

Your machine is the exception so far since it's the only one that was tested where power on works, but not reset.


When I read various wiki entries, I was told that rendering should always be enabled and disabled in NMI anyway, so that the game doesn't start drawing mid-frame.

So, I'm surprised mid-frame writing of PPUMASK to enable and disable rendering actually came up here.

In my program, I always have a buffer value named PpuMaskValue that gets the corresponding rendering status. And then in NMI, I set PpuMaskValue to $2001. I never write $2001 anywhere else (except right in the beginning of course, when it is initialized with 0), I always use the buffer variable.


In reality, i.e. in "City Trouble", this is not just a funny oversight where I can say: "Dammit, why didn't I simply use sprite 0-8?"

Using sprites 0-8 would have never happened.

Because the only reason why I use the overflow check at all is to have an additional scanline split, apart from sprite 0 split.

In the test program, I only did the overflow check, but in "City Trouble", both checks are used: Overflow for the status bar and sprite 0 for the parallax scrolling.

So, it would have always been 1-9 because sprite 0 has its own separate purpose.
Therefore, running into the error was pretty much unavoidable for me.

In the old "City Trouble" ROM, I just kept the 10 sprites and the bit checks on the text screens for consistency's sake. So, the text screens also had those two checks, despite not needing them since text screens have no scrolling.

That's why the bug was easy to fix once I knew what caused it:

Put the 10 sprites out of the screen whenever a text screen is initailized and only set it to the correct locations when a level is initialized.

And before each of the two checks, make sure that the variable at address Sprites + 0 does not have the value $F4 (my chosen out-of-screen y position value), otherwise skip the check.

Since the game always starts with a text screen (the credits), this makes sure the game cannot freeze because of this issue anymore.

_________________
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

Important question:

Does the issue of the missing sprites only happen when rendering is enabled for the first time? Or can it also happen every time when rendering is enabled after it was disabled?

Because if it can happen anytime when rendering is turned on again, not just after the very first time, then I might have to change my "City Trouble" code again. Because this means the game could freeze whenever a level is loaded if the nine overflow sprites aren't properly set.

_________________
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

Only the first time unless you later disable rendering in the middle of the screen somewhere. As long as you only disable rendering during vblank you're safe. (You can disable just sprites, or just background mid-screen safely since both must be turned off to disable rendering entirely, or if you're very careful you can disable rendering on some part of the scanline where sprites are not being evaluated.)


Setting it to 0 just after reset is an exception to this rule. Unless you are targetting Famicom only and not NES there is not much to be gained by waiting for vblank to initially write 0 to $2001. You've got to deal with this "one bad frame" issue always with the NES reset, apparently. tokumaru was only suggesting it as a test to make sure the reset issue was caused by the thing we thought was causing it, I think.


I'm pretty certain that every NES/Famicom system should have the reset issue (excepting PAL?). It's only the behaviour at power-on that I suspect is different on other machines. (running oam_reset2.nes on them will diagnose this best)

In this case, I'm safe.


Alright, yeah, this is of course the big exception. I do this as well.


Well, I can tell you for certain that my own original front loader NTSC NES often has issues reading "City Trouble" while pressing Reset usually fixes it.
You on the other hand experienced the exact opposite: Power on is usually fine, reset usually fails.

But since this is an infrequent thing anyway (sometimes power on works immediately, sometimes reset freezes as well, different carts produce different frequency of working/non-working), I'm not surprised that different machines behave differently.

If this was an issue where one machine always does this and the other machine always does that, then it would be strange. But in our case, my NES produced all four situations (power on working and non-working, reset working and non-working) at certain points in time, so differences between different systems are not surprising to me.

And since even the cartridge itself makes a difference, maybe your development cart is another factor in the calculation. If you lived in Germany, I would quickly send you over one of my faulty "City Trouble" carts to check whether their behavior changes on your NES or whether your NES' behavior changes with the cart.

_________________
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

This really isn't something that should be affected by the cartridge.

The frequency of failure at reset shouldn't be affected by different machines either, since it should be based entirely on the timing of pressing reset within the frame. (essentially "random" timing from human input)

Only power-on has the potential to be different, in the same way that uninitialized RAM can have a "signature" of power-on tendencies. I don't think the other factors should change things.

PAL should be different, though, since it has different sprite refresh behaviour.