Sprite Evaluation - Need Some Help

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
Anes
Posts: 702
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Sprite Evaluation - Need Some Help

Post by Anes »

Well, my emulator never had "sprite evaluation" phase well implemented.
So now i want to implement it well.

1) If we have that 1-64 cylces the sprite buffer mem is initialized to 0xFF.
What i don't understand why 2004 returns 0xFF.
I think that its not pretty much useful no emulate in a exact way since its not "seen" by the rom code. But i only mention the thing that i don't understand.

2) 65-256 phase
The thing is not clear for me. It says "in odd cycles that is read from OAM" and "in even ones that is written to secondary OAM".
I have confusions: i don't know if it should take 8 ppu cycles per sprite (due to odd/even, i mean 4 cycles for "reading" and 4 for "writing".
Or maybe in one cycle even and then in one cycle odd does the the 3 steps reading from primary and writing to secondary.

The wiki says that the pattern is taken from software (is that right) i mean reading and writing to 2004.

I post all this becuse im continually receiving errors in blargg's test:

Detatais -> "#3 Disabling rendering shouldn't clear flag"
Im not clearing flag when rendering is off!!

SPRITE OVERFLOW TIMING -> "#2 Cleared too late"
This one, as it says is pure spr ovl timing and i think it could be fixed when i do a proper sprite evaluation, since its the phase when the flag is SET.

Help!!
ANes
ap9
Posts: 43
Joined: Sat Jun 01, 2013 11:55 am
Location: Maine, U.S.A.
Contact:

Re: Sprite Evaluation - Need Some Help

Post by ap9 »

Accurate sprite evaluation is one of the challenging parts of the PPU because it's buggy. In fact, one of the very first things it does on a scanline is considered a bug — copying an 8 byte block within sprite RAM from offset (reg2003 & 0xF8) to offset 0.

The reason why 2004 returns FF during cycles 1-64 when rendering is on is because that's when it's filling the secondary RAM with FF, and outside of evaluation and on even cycles it connects the OAM latch lines to secondary even when not writing, so it's basically reading that.

For evaluation — dots 65-256 — it's 2 cycles for a sprite out of range and 8 in-range. Each byte copy is split up into two cycles: read from primary on the odd cycle, write to secondary on the next even cycle. It always attempts to copy the first byte to the secondary buffer; it just skips copying the rest when out of range, and has writes disabled when secondary is full.

Once the secondary buffer is full, there's another bug that, while it continues to find sprites, when a sprite is out of range it increments another step anyway within the lower 2 bits of primary reading address as if it just started copying, so it basically steps 5 bytes instead of 4 (at least until the lower 2 bit copying offset wraps).

The overflow flag is persistent enough that it's only cleared at the beginning of the evaluation line after VBL.
User avatar
Anes
Posts: 702
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Re: Sprite Evaluation - Need Some Help

Post by Anes »

Very good explication ap9. Much clear now :D
ANes
Post Reply