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!!
Sprite Evaluation - Need Some Help
Moderator: Moderators
Re: Sprite Evaluation - Need Some Help
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.
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.