I'm finishing up my FPGA NES core now, and it appears to be 100% accurate, except for what happens when 2003h isn't 00h before rendering is enabled.
I've read the wiki about this matter and it says this:
I can interpret this in at least two possible ways.
Is rendering started at (address & 0f8h), so that writing 87h to 2003h before rendering results in the sprite order of:
or is it more like this?
So that sprites 32 and 33 are effectively shown twice?
...
On consultation with Q in #nesdev just now, he said that it appears to follow the second ordering where in the example case, sprite 32/33 are
shown twice effectively.
This effect apparently can vary and change between resets of the console, and possibly PPU revisions, and other unknown factors.
Thoughts? comments?
I've read the wiki about this matter and it says this:
wiki wrote:
This register (2003h) also seems to affect Sprite 0 Hit, though it is not yet understood exactly how it does. The upper 5 bits of this register seem to select which SPR-RAM data is used for sprites 0 and 1 (instead of the first 8 bytes of SPR-RAM), though actual behavior varies between resets.
I can interpret this in at least two possible ways.
Is rendering started at (address & 0f8h), so that writing 87h to 2003h before rendering results in the sprite order of:
Code:
32 (acting as sprite 0), 33 (acting as sprite 1), 34 (Acting as sprite 2) ....
63, 0, 1, 2, 3, 4, ... 31 (acting as sprite 63)
63, 0, 1, 2, 3, 4, ... 31 (acting as sprite 63)
or is it more like this?
Code:
32, 33 (acting as sprites 0, 1 resp), 2, 3, 4, 5, ... 31, 32, 33, 34, ... 63
So that sprites 32 and 33 are effectively shown twice?
...
On consultation with Q in #nesdev just now, he said that it appears to follow the second ordering where in the example case, sprite 32/33 are
shown twice effectively.
This effect apparently can vary and change between resets of the console, and possibly PPU revisions, and other unknown factors.
Thoughts? comments?