rainwarrior wrote:
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.)
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.
rainwarrior wrote:
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.)
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.
tokumaru wrote:
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?
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.
rainwarrior wrote:
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.

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.