First off, I'd just like to say how great a resource the nesdev wiki and these forums have been while making my emulator. Thanks to everyone who's put time into them.
I'd like to clarify something about the increment of the x and y components of v when reading/writing PPUDATA ($2007).
The PPU scrolling wiki page says
And 'outside of rendering' means "when neither of the sprite/bg enabled bits are set in PPUMASK ($2001)", correct?
However, I'm slightly less certain after reading the PPU Registers wiki page under the PPUDATA ($2007) section which says
I'm not sure if this means that, on a read or write to PPUDATA, the 'rendering enabled' increment (the one which wraps x/y components) should take place even if we're currently in vblank, as long as the PPUMASK flags indicate that rendering is 'on'.
The quote from the registers page reads more as advice to a nes game dev than an emulator dev. Basically, does being in VBLANK (between 241,1 and 261,1) override the PPUMASK flags or not when deciding how to increment v?
I ask because I'm seeing behaviour (in Donkey Kong) where I get a PPUDATA write on scanline 248 (during vblank), but the sprite enabled flag of PPUMASK is on, so I'm doing the wrapping increment rather than the 1/32 based on $2000.2. This is putting the value of v over $4000. I'm aware that when being treated as an address, v should be &'d with 0x3FFF as it's a 14-bit address space, but I'm not 100% clear on whether the increment behaviour counts as treating v as an address or not.
Thanks in advance for any help. If my questions are unclear in any way, please let me know.
I'd like to clarify something about the increment of the x and y components of v when reading/writing PPUDATA ($2007).
The PPU scrolling wiki page says
Quote:
$2007 reads and writes
Outside of rendering, reads from or writes to $2007 will add either 1 or 32 to v depending on the VRAM increment bit set via $2000. During rendering (on the pre-render line and the visible lines 0-239, provided either background or sprite rendering is enabled), it will update v in an odd way, triggering a coarse X increment and a Y increment simultaneously (with normal wrapping behavior). Internally, this is caused by the carry inputs to various sections of v being set up for rendering, and the $2007 access triggering a "load next value" signal for all of v (when not rendering, the carry inputs are set up to linearly increment v by either 1 or 32). This behavior is not affected by the status of the increment bit.
Outside of rendering, reads from or writes to $2007 will add either 1 or 32 to v depending on the VRAM increment bit set via $2000. During rendering (on the pre-render line and the visible lines 0-239, provided either background or sprite rendering is enabled), it will update v in an odd way, triggering a coarse X increment and a Y increment simultaneously (with normal wrapping behavior). Internally, this is caused by the carry inputs to various sections of v being set up for rendering, and the $2007 access triggering a "load next value" signal for all of v (when not rendering, the carry inputs are set up to linearly increment v by either 1 or 32). This behavior is not affected by the status of the increment bit.
And 'outside of rendering' means "when neither of the sprite/bg enabled bits are set in PPUMASK ($2001)", correct?
However, I'm slightly less certain after reading the PPU Registers wiki page under the PPUDATA ($2007) section which says
Quote:
When the screen is turned off by disabling the background/sprite rendering flag with the PPUMASK or during vertical blank, you can read or write data from VRAM through this port
I'm not sure if this means that, on a read or write to PPUDATA, the 'rendering enabled' increment (the one which wraps x/y components) should take place even if we're currently in vblank, as long as the PPUMASK flags indicate that rendering is 'on'.
The quote from the registers page reads more as advice to a nes game dev than an emulator dev. Basically, does being in VBLANK (between 241,1 and 261,1) override the PPUMASK flags or not when deciding how to increment v?
I ask because I'm seeing behaviour (in Donkey Kong) where I get a PPUDATA write on scanline 248 (during vblank), but the sprite enabled flag of PPUMASK is on, so I'm doing the wrapping increment rather than the 1/32 based on $2000.2. This is putting the value of v over $4000. I'm aware that when being treated as an address, v should be &'d with 0x3FFF as it's a 14-bit address space, but I'm not 100% clear on whether the increment behaviour counts as treating v as an address or not.
Thanks in advance for any help. If my questions are unclear in any way, please let me know.