details about what happens when the ppu is disabled ?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
details about what happens when the ppu is disabled ?
by on (#21438)
i have read in past forum posts that the ppu does nothing when disabled. i searched for info but couldnt find any past post. i supose i am not searching the right words.

i was looking at recoding my ppu (code clean up and reuse).

is it possible that the ppu still does everything internally except doesnt read or write to the ppu address or data bus ? (and show the color as described in other thread)

example, the ppu goes on -> off -> horizontal position 0... 63, where oam is being set to 0xff. the background would be messed up only for those pixels and resume on the correct tile ? sprites might be ok if not effected by 0xff initialization ?

example, the ppu goes on -> off -> on horizontal position 200 ... 255, where the sprites are being evaluated for range. assume that the inrange is done evaluating, would the sprite data fetch 256...320 still fetch the correct sprites ?

since the ppu is a large state machine, i was thinking that some states still operate but dont read or write externally.

what information is known about the ppu when background and sprites are disabled ?

thanks
matt
Re: details about what happens when the ppu is disabled ?
by on (#21439)
mattmatteh wrote:
is it possible that the ppu still does everything internally except doesnt read or write to the ppu address or data bus ? (and show the color as described in other thread)


OAM/NT/CHR is all accessible by the CPU when the PPU is off, therefore logically I'd assume the PPU must not be accessing any of it. It's possible the shift registers still get shifted and all the weird low-level stuff is still going, but without being able to perform new fetches to refresh itself, they would all be filled with useless garbage pretty quickly.

The PPU is also leaving the PPU Address unchanged.


Quote:
example, the ppu goes on -> off -> horizontal position 0... 63, where oam is being set to 0xff. the background would be messed up only for those pixels and resume on the correct tile ?


the BG would be screwed up a bit. The PPU updates the PPU address (the same one set by $2006) as it renders. IE: it adds 1 every 8 cycles to advance to the next tile. When the PPU is turned off, it does not do these updates, so when you turn it back on, it will start fetching tiles from where the PPU address is left at -- regardless of what scanline it's on or where in the scanline it is.

Quote:
sprites might be ok if not effected by 0xff initialization ?


No clue. I've wondered how sprites are managed when the PPU is switched on mid-frame as well.

I currently am totally guessing that the secondary OAM is filled with emptiness when the PPU is switched off so that a whole scanline is "skipped" until it gets restarted by having the PPU on from the start of the scanline. But I'm sure this is totally wrong and I have no basis for assuming this -- it's just how I'm handling it in my emu.

by on (#21449)
Uh... firstly, the PPU is never disabled. What happens is to turn off background or sprite rendering using the 2001h flags, but the PPU itself still runs, got it? Next, if mind doesn't fail, the sprite RAM, and possibly the 8-sprites-cache, have nothing, but garbage. Personally, I use FFh data as initial setup for both. Some games will write F8h data into sprite RAM on reset though.

A taste that the PPU doesn't "disable" is the background rendering when it's "disabled": if the PPU address is between $3F00-$3FFF or any mirrored area of that, that's the color it draws to the screen. Otherwise, $3F00 is the color drawn.

*bump* I might be wrong, as I'm not a NES hardware analyser. :(

by on (#21451)
Quote:
Uh... firstly, the PPU is never disabled. What happens is to turn off background or sprite rendering using the 2001h flags, but the PPU itself still runs, got it?

A more correct term would be "external bus acess disabled", because the chip itself still runs, but makes no acess to external devices via it's bus. The palette is internal to the PPU, so that's not an external acess.