nesdev.com
http://forums.nesdev.com/

PPU operations when rendering is disabled...
http://forums.nesdev.com/viewtopic.php?f=3&t=15926
Page 1 of 1

Author:  Eicar [ Thu May 11, 2017 2:37 am ]
Post subject:  PPU operations when rendering is disabled...

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

Author:  Bregalad [ Thu May 11, 2017 3:42 am ]
Post subject:  Re: PPU operations when rendering is disabled...

1. Is wrong, no VRAM fetch happens in forced VBlank mode. Actually this is the whole point of this mode.
2. and 3. appears correct. The rest I have no idea since I'm a NES developer and not a NES emu developer.

Author:  Eicar [ Thu May 11, 2017 4:02 am ]
Post subject:  Re: PPU operations when rendering is disabled...

Ups, I guess I should have put this on the NESemdev board instead. My mistake... I guess I can't move it myself...

Speaking of point 1. I'm only talking about the tile fetching here, and not the rendering... More feedback from others are welcome :)

-Eicar

Author:  AWJ [ Thu May 11, 2017 4:53 am ]
Post subject:  Re: PPU operations when rendering is disabled...

Eicar wrote:
Speaking of point 1. I'm only talking about the tile fetching here, and not the rendering... More feedback from others are welcome :)


During forced blank the PPU doesn't access memory on its own at all. Only when the CPU reads/writes $2007.

Author:  lidnariq [ Thu May 11, 2017 11:42 am ]
Post subject:  Re: PPU operations when rendering is disabled...

Eicar wrote:
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?
Exactly
Quote:
However, since sprite evaluation is not happening on the pre-render line 261, this means that no spritedata will be output on scanline 0.
Correct.
Quote:
However, will scanline 239 evaluate sprites with Y position zero?
There's no logic for that; on scanline 239 it's evaluating sprites for the following scanline that will never be drawn.
Quote:
or will the sprite data fetching on line 261 corrupt this?
I'd say "replace" or "overwrite", but yes.

Author:  Eicar [ Thu May 11, 2017 1:27 pm ]
Post subject:  Re: PPU operations when rendering is disabled...

lidnariq wrote:
I'd say "replace" or "overwrite", but yes.

So, what sprite data is actually fetched on scanline 261? The last sprite evaluation was done on line 239, so does that mean that the result from
this is still in the secondary OAM and the eight sprite output modules? (as the secondary OAM is not cleared on line 261) Are these leftovers then
incorrectly displayed on scanline 0? (Like garbage pixels etc..) I guess most games would stay away from putting too much on the first and last 8 scanlines due to the
overscan on most CRT sets so this would probably not cause any issues anyway...

Thanks so far for all the answers!

-Eicar

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/