Hi!
I'm trying to find some solid information about what parts of the PPU are still active when rendering is disabled. When I say "disabled" is mean when both bit 3 and 4 in $2001 are cleared.
Looking at the Ntsc_timing.png it doesn't say which operations are affected by disabling the rendering. I've tried to look at several PPU implementations, both they all differ in some way from each other.
Here are my assumptions:
1. All VRAM fetches (background and sprites) ALWAYS happens regardless if rendering is disabled or not (light brown boxes).
2. Skip PPU cycle on odd frames does NOT happen when rendering is disabled (green box).
3. All v (loopy_v) updates (inc hori(v), inc vert(v), hori(v) = hori(t) and vert(v) = vert(t)) does NOT happen when rendering is disabled (red boxes)
4. Clear vblank flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
5. Clear sprite 0 hit flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
6. Clear sprite overflow flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
7. Set vblank flag on line 241 ALWAYS happens regardless if rendering is disabled or not (green box)
8. Secondary OAM clear (cycle 1-64) does NOT happen when rendering is disabled
9. Sprite evaluation (cycle 65-256) does NOT happen when rendering is disabled (or on line 261)
10. I'm also not sure about how the sprite output modules are filled from the secondary OAM. It was mentioned somewhere that they are implemented using some counters and shift
registers. Does this mean that each sprite output unit is filled with a counter that corresponds to the x position of where the sprite data should be outputed, and that this counter
is decremented for each rendering cycle? And when the counter reaches 0 it will eat bits from the shift register and output it? Are these sprite output units running when
rendering is disabled? If not, they could output old sprite data on one scanline if rendering is suddenly turned on in the middle visible scanlines (0-239). I guess these output modules
reset themselves after the pixeldata is output (make sense if they are implemented with a counter and 2 registers containing the pixeldata (hi and low bits) of spritedata)
11. And one more thing.. during sprite evaluation on scanline S, this means that a sprite will be "in range" if the sprite's Y position is: S >= Y && S < Y + sprite_height. This spritedata will be rendered on the next scanline S+1, this is the reason why sprites show up one scanline too late right? However, since sprite evaluation is not happening on the pre-render line 261, this means that
no spritedata will be output on scanline 0. However, will scanline 239 evaluate sprites with Y position zero? or will the sprite data fetching on line 261 corrupt this?
I know this was a lot of questions, but I'm not able to rest until my PPU emulation is perfect.... I guess I won't be resting for quite some time.....
-Eicar
I'm trying to find some solid information about what parts of the PPU are still active when rendering is disabled. When I say "disabled" is mean when both bit 3 and 4 in $2001 are cleared.
Looking at the Ntsc_timing.png it doesn't say which operations are affected by disabling the rendering. I've tried to look at several PPU implementations, both they all differ in some way from each other.
Here are my assumptions:
1. All VRAM fetches (background and sprites) ALWAYS happens regardless if rendering is disabled or not (light brown boxes).
2. Skip PPU cycle on odd frames does NOT happen when rendering is disabled (green box).
3. All v (loopy_v) updates (inc hori(v), inc vert(v), hori(v) = hori(t) and vert(v) = vert(t)) does NOT happen when rendering is disabled (red boxes)
4. Clear vblank flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
5. Clear sprite 0 hit flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
6. Clear sprite overflow flag on line 261 ALWAYS happens regardless if rendering is disabled or not (green box)
7. Set vblank flag on line 241 ALWAYS happens regardless if rendering is disabled or not (green box)
8. Secondary OAM clear (cycle 1-64) does NOT happen when rendering is disabled
9. Sprite evaluation (cycle 65-256) does NOT happen when rendering is disabled (or on line 261)
10. I'm also not sure about how the sprite output modules are filled from the secondary OAM. It was mentioned somewhere that they are implemented using some counters and shift
registers. Does this mean that each sprite output unit is filled with a counter that corresponds to the x position of where the sprite data should be outputed, and that this counter
is decremented for each rendering cycle? And when the counter reaches 0 it will eat bits from the shift register and output it? Are these sprite output units running when
rendering is disabled? If not, they could output old sprite data on one scanline if rendering is suddenly turned on in the middle visible scanlines (0-239). I guess these output modules
reset themselves after the pixeldata is output (make sense if they are implemented with a counter and 2 registers containing the pixeldata (hi and low bits) of spritedata)
11. And one more thing.. during sprite evaluation on scanline S, this means that a sprite will be "in range" if the sprite's Y position is: S >= Y && S < Y + sprite_height. This spritedata will be rendered on the next scanline S+1, this is the reason why sprites show up one scanline too late right? However, since sprite evaluation is not happening on the pre-render line 261, this means that
no spritedata will be output on scanline 0. However, will scanline 239 evaluate sprites with Y position zero? or will the sprite data fetching on line 261 corrupt this?
I know this was a lot of questions, but I'm not able to rest until my PPU emulation is perfect.... I guess I won't be resting for quite some time.....
-Eicar