Nine sprites overflow doesn't work in the beginning
Moderator: Moderators
Re: Nine sprites overflow doesn't work in the beginning
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.
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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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?
So... I dunno. Only affects some systems, I guess?
Re: Nine sprites overflow doesn't work in the beginning
@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.
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.
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.rainwarrior wrote: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.
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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.DRW wrote: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.rainwarrior wrote: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.
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.
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.
Re: Nine sprites overflow doesn't work in the beginning
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.
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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.DRW wrote: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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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.
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.
Re: Nine sprites overflow doesn't work in the beginning
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.
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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?
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?
Re: Nine sprites overflow doesn't work in the beginning
I'm not sure whether this can be the issue, in case I'm understanding you correctly.rainwarrior wrote: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?
Have a look:
Code: Select all
; First thing to run: NMI
LDA #1
STA WaitForNmi
; NMI enabled
LDA #%10010000
STA $2000
; Game logic
@gameLogic:
LDA WaitForNmi
BNE @gameLogicEnd
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:
Code: Select all
; PPUMASK enabled
LDA #%00011110
STA $2001
; Sprite OAMDMA
LDA #$00
STA $2003
LDA #>Sprites
STA $4014
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.rainwarrior wrote: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?
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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.DRW wrote:...rainwarrior wrote: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?
Does this disprove your assumption or is there anything that I overlooked?
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.
Re: Nine sprites overflow doesn't work in the beginning
That's maybe possible, but of course I have no way of confirming or disproving this. How can such a thing reliably be validated?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Nine sprites overflow doesn't work in the beginning
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.
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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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?tepples wrote: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.
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)
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Nine sprites overflow doesn't work in the beginning
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)?
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)?
- Attachments
-
- oam_reset2.nes
- slightly modified oam_reset.nes
- (24.02 KiB) Downloaded 203 times