About PPU registers $2006,$2007

I'm stil in doubt on $2006/$2007 PPU access. Should read/write be blocked if the screen is rendering? By "rendering", does it mean "sprites OR background enabled", or even that and "scanline between 21~260th"?

You know, this is the obscure part for proper MMC3 IRQs. If I block reads/writes $2006/$2007, the MMC3 IRQ tests still pass, but games are broken.

With background rendering on:

Writes to $2006 and still work, it is how scroll splits are accomplished.

Writes and reads to $2007 work, but the state of the PPU address gets really hairy. The current address will be highly dependent on timing (the PPU will be changing it as it fetches tiles), and the address increment does very strange things (I don't think it increments properly in this state, not sure exactly what it does).

$2006 behaves as described in The skinny on NES scrolling.

"Rendering" means background or sprites is turned on and the current scanline is picture, that is, any time outside vertical or forced blank. (I don't know whether the prerender and postrender lines are "rendering" for this purpose.) I seem to remember that $2007 access during rendering increments both the horizontal part (bit 0-4) and vertical part (bits 12-14 and 5-9) of the current video memory address. See previous discussion about Young Indy and follow the bouncing ball.

Well, looks like blocking $2006 isn't a good idea, but $2007 seems to make no difference.

Preventing reads and writes to $2007 during rendering will not matter to the vast majority of games ... because the vast majority of games don't do that.

None-the-less, some games do.

If you focus on "getting games running" you are making a NES game player, not an NES emulator... If you're emulating the NES, you should be doing what the NES does. That being said, this whole $2007 issue seems pretty mystical to me, and is one of the reasons I'm glad I make NES programs and not NES emulators.

To the best of my ability to recall/decipher, reading from $2007 during rendering immediately increments the Y scroll value by 1 (one scanline) and the X scroll value by 8 (one tile) in v. t, however, is unchanged, so subsequent scanlines will only show the Y scroll. This is what happens in Young Indiana Jones Chronicles, when the cannonballs are landing, as well as what happens in Legend of Zelda on the title screen, as well as tepples's Boing 2007 demo.

Writing to $2007 does all of the above, plus causes a write to some hard-to-control location in the PPU's address space.

I thought accessing $2007 skipped a scanline when the address increment was set to 32, and it skipped to the next tile when it was set to 1. I might be wrong though, because nobody really wrote this down to my knowledge.

When you access $2007, it sends an "increment" signal to the entire register. When rendering is disabled, the carry bits are connected in such a way that it will increment by either 1 or 32, based on the increment setting. When rendering is enabled, however, the carry bits are connected in such a way that it will increment both the "H" bits and the "V" bits simultaneously, each using the logic that's used normally during rendering - normally, the rendering process will separately increment the "H" bits or the "V" bits based on what's going on.

Ah, thanks for clearing that up.

Points to Nintendo Virtual Console thing. *kisses*

Precisely. If you are marketing an emulator to publishers of classic games seeking to republish them on modern mobile platforms, you don't need more than enough accuracy to get the game running. In fact, less accuracy can be better if it helps your emulator fit in the desired power consumption envelope while retaining compatibility with the target games.

Awesome to the max! Thanks.