It is currently Sat Dec 16, 2017 8:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Thu May 11, 2017 2:37 am 
Offline

Joined: Wed May 04, 2016 12:43 am
Posts: 8
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


Last edited by Eicar on Thu May 11, 2017 4:14 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu May 11, 2017 3:42 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7317
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Thu May 11, 2017 4:02 am 
Offline

Joined: Wed May 04, 2016 12:43 am
Posts: 8
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


Top
 Profile  
 
PostPosted: Thu May 11, 2017 4:53 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
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.


Top
 Profile  
 
PostPosted: Thu May 11, 2017 11:42 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu May 11, 2017 1:27 pm 
Offline

Joined: Wed May 04, 2016 12:43 am
Posts: 8
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: MLX and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group