Hello
I just got an NTSC NES to test beside my PAL one. I just noticed that the sprite limit is 7 on this specific system. I am wondering if it is a broken PPU, or maybe a common bug among powerpak users?
I have no way to test this on a real cart, since all my carts are PAL. So only powerpak here.
It took me a while to see what it was, but I saw that something wasn't right. Sprites flickering were not as "nice" as it usually is. When I finally tried my own game Mineshaft, it was very obvious. The platforms are 5 sprites wide, and the score is 3. That should be ok unless the player sprite is on the same line. But on this particular system, one sprite of the platform edge gets invisible every time they are on the same line as the score.
I did some more tests, and found other games where the same issue is visible. This does not happen on my PAL NES.
Is this common? Anyone else seen this?
If you give me a ROM of your game, I can test it on a PowerPak with the latest code, as well as an NTSC NES and NTSC top-loader NES, using an NTSC TV (I see you're in Sweden; hejsan svejsan), although I'm not familiar enough to know what it should normally look like (any emulator you'd recommend for confirming correct behaviour?)
Hejsan svejsan!
Sure. If you play this rom, then the combined number of sprites on a line of a platform and the three digits of the score will add up to eight. No flickering is implemented in this game, so that's a good way to test it. I might write a test rom tomorrow if none is available.
The only time I saw unexpected sprite flicker in one of my projects was when I was turning off rendering early. Doing so at any time other than near the end of a visible scanline appears to interfere with refreshing the DRAM used for OAM, as sprites 0 and 1 get copied over some other even-odd pair of sprites.
koitsu: The game is MineShaft, and it works fine on my PowerPak + NTSC NES, up to at least score 189.
Download
MineShaft alone (reupload due to 403 error from fileden)
Download
MineShaft as part of Action 53 (#34, oversize BNROM)
Download
Streemerz bundle beta 3 (requires
mapper 28 plug-in)
Attached is a trivial test rom that just displays 64 non-moving 8x16 sprites, with 8 sprites together. (Unfortunately I'm too lazy to fix the tiles such that it counts LTR instead of RTL) You mean the rightmost column (00,08, &c) doesn't show up?
Thanks guys -- no sense in me testing it if it works okay on tepples' stuff. :-) Nioreh, give the test ROM that lidnariq provided a shot, see what the results are there.
Ok, here are the results from my two nes units. The same powerpak was used on both systems. So, can it really be possible for the PPU to break like this? Or can it be some bad component on the motherboard?
I get a couple sprites missing from the screen too, but not nearly a whole column missing like you appear to be getting. The pair moves after every reset, and occasionally they're all bunched up at the top or at the left. It might have something to do with what I discovered while making Concentration Room: OAM refresh isn't in a defined state immediately after reset; you have to let one frame finish rendering before OAM refresh becomes stable. The best practice is to copy OAM after one complete frame has been displayed. This happens automatically in an actual game such as MineShaft, where OAM is copied during each vblank.
I'll make a test ROM for this exact bad practice, where the user can manually force OAM to be recopied.
EDIT: Here's the test. It's bigger than lidnariq's because it includes full source code.
EDIT 2: It's not waiting for vblank before uploading the display list to OAM for the first time, but
rainwarrior fixed that.
Why aren't these tests made to display all 64 sprites properly? Is it this hard to avoid PPU quirks?
My test was specifically to demonstrate this PPU quirk. Press Select and everything clears up.
tepples wrote:
My test was specifically to demonstrate this PPU quirk. Press Select and everything clears up.
The pertinent bit of my code was
Code:
lda #>spritefixed
sta PPU_OAM_DMA
lda #PPU_CTRL_SPR_8X16
sta PPU_CTRL
lda #PPU_MASK_LEFT_SPR_SHOW|PPU_MASK_SPR_ENA
sta PPU_MASK ; enable rendering
spin:
jmp spin
I have really no idea why things are changing; I never write to $4014 after the first round.
I suppose it is entirely possible for Sprite #7 to break in hardware, but it would be extremely strange for a specific are of the die to be damaged / defective while the rest is okay.
tepples wrote:
The pair moves after every reset, and occasionally they're all bunched up at the top or at the left.
I'm so bad at actually readingThat's
really interesting, because "all bunched up" either implies OAMADDR isn't a multiple of 4, or that some of the reads from ROM / writes to OAM are being trashed. I never wrote OAMADDR, because I thought we
believed it wasn't necessary…
lidnariq wrote:
tepples wrote:
The pair moves after every reset, and occasionally they're all bunched up at the top or at the left.
I'm so bad at actually readingThat's
really interesting, because "all bunched up" either implies OAMADDR isn't a multiple of 4, or that some of the reads from ROM / writes to OAM are being trashed. I never wrote OAMADDR, because I thought we
believed it wasn't necessary…
There's at least one case which would make it necessary despite the (somewhat) known power up state: if user resets the console in the middle of a sprite DMA, the OAM address would be left in an unknown state.
There's no justification for assuming the power-up state of the NES, since it's trivial to initialize it all to a known state. It's just asking for obscure problems to skip initialization.
thefox wrote:
There's at least one case which would make it necessary despite the (somewhat) known power up state: if user resets the console in the middle of a sprite DMA, the OAM address would be left in an unknown state.
Sure. But my code only did the OAM DMA once ever. On the other hand, I'd forgotten that
rendering also causes OAMADDR to change, and a reset during rendering would explain the behavior.
blargg wrote:
There's no justification for assuming the power-up state of the NES, since it's trivial to initialize it all to a known state. It's just asking for obscure problems to skip initialization.
Sure; it's just that I'd internalized the assertion that its power-on state
was known, and therefore assumed initialization was unnecessary. (and, well, assumptions...) I know better now
lidnariq wrote:
"all bunched up" either implies OAMADDR isn't a multiple of 4
If you look at the die, it's clearly a multiple of
8, not 4 - a decoder at the top-center of the chip (between A2 and D7 for the CPU I/O interface) turns SPR-RAM A0-A2 (along with the secondary OAM enable) into eight "column" enables while another decoder in the middle of the DRAM itself turns A3-A7 into 32 "row" enables.
If
this node was somehow damaged, then sprites 7, 15, 23, 31, 39, 47, 55, and 63 would always be invisible (as in the test programs); however, the 8th sprite in each scanline always being invisible (regardless of its address within OAM) would have to be due to a flaw in the 8th sprite render buffer, such as by
this transistor being damaged in such a way as to leave it permanently switched off.
OK, finally got around to test the new rom. Here are the results. As you can see, it is very consistent in removing the eighth sprite on each scanline, so I guess I'm looking at a broken PPU
Got this NES cheap off eBay, but had hopes for it since it was untested by the seller.
Attachment:
spite8_1.jpg [ 11.39 KiB | Viewed 688 times ]
Attachment:
spite8_2.jpg [ 12.08 KiB | Viewed 688 times ]
Attachment:
spite8_3.jpg [ 12.83 KiB | Viewed 688 times ]