sprite address

[hap]

Does the sprite address (0x2003) change during rendering like the bg address (0x2006) ?

I'm currently simply reading sprites from address 0 and up, that doesn't seem to cause problems, except for Akira (J). It locks up because it uses the sprite zero bit for its splitscreen effect. If I hack in a sprite_address=0 once per frame (or even nastier, in 0x2002: if (scanline==akirasplitline) status=status|0x40;), it works.

[hap]

(didn't want to open a new topic for this, as it's the same subject)

Tatakai no Banka..

This game, the Japanese version of Trojan, writes $80 to the sprite address every other frame, before doing a sprite dma transfer. This causes sprite 0 to be located at $80, which results in the sprite 0 hit being wrongly timed in-game, which results in dirty graphics (seen as flickering).

The Wiki says something about sprite 0 and 1 being fetched from the high 5 bits of the sprite address, instead of address locations 0 and 4. This would fix the problem in Tatakai no Banka, but I doubt that such behaviour happens on the real NES; looks more like a hack to get this game working, since no other games I've seen have such a problem as described above.

[Guest]

I wonder if sprite 0 hit is really a "sprite $2003 hit" instead, i.e. the address in $2003 determines the sprite that should record at hit in $2002 bit 6.

I can see why a game might load sprites at $80 every other frame, as a quick way to compensate for the eight-sprite limit imposed by the PPU.

[Quietust]

The Wiki says something about sprite 0 and 1 being fetched from the high 5 bits of the sprite address, instead of address locations 0 and 4. This would fix the problem in Tatakai no Banka, but I doubt that such behaviour happens on the real NES; looks more like a hack to get this game working, since no other games I've seen have such a problem as described above.

I assure you that it is NOT a hack - this strange behavior has been verified to occur on a real NES PPU. The Sachen game "Huge Insect" relies on this same behavior.

[hap]

It doesn't make much sense though. It would be logical to me if this applied to the whole sprite array, instead of only sprite 0 and 1.

[Quietust]

It doesn't make sense to me either, but that's how it works. If you don't believe me, you can test it for yourself.

[hap]

Sorry, I'm always a bit skeptical at first .. I believe you.

The game still looks glitchy now that sprite behaviour is fixed, but this time I blame Capcom. It's probably been ported by the same team who did Senjou no Ookami/Commando.

[hap]

Hello there hap of the past, are we still blaming Capcom?

I don't think he'll answer, so a better reason for this topic kick:

10/14/2006 - bsnes v0.018 released
[...]
Changelog:
- OAM address reset now occurs when screen display is enabled, per recent research
- ...

I see NES emulators resetting the sprite address at the start of vblank when the PPU is enabled. Could someone confirm this and/or test if disabling or enabling the PPU resets the sprite address? (considering the assumption that the SNES hardware development team contained some who worked on the NES hardware)

[blargg]

Ask and ye shall find ye hath already received heh...

Also, Google is your friend for allowing a search of the message boards here: "sprite address blargg site:nesdev.com"

[hap]

Thanks, that must've slipped my.. erm.. scrollbar.