I was scribbling up some plans for a precached MMC3 irq timing handler thingy, and something came to mind. Since the PPU is sucking the bus dry full-time when it is rendering, wouldn't that mean it's impossible for any sort of VRAM writes, except palette ram, to occur?

With the way it's eating the bus up it wouldn't make any sense to me for it to be able to read/write to VRAM during this time.

Hi,
I was wondering the same.
(Note that I do not have no real knowledge, I hope more skilled people will answer)
During rendering phases, PPU is reading from memory if background or objects are active. So if the program tries to read or write (I suppose even writes to the palette would need PPU cycles too), or objects DMA, would screw up screen rendering (you will consume ppu cycles). Is there any program designed to achieve special effect by screwing up rendering on purpose?). I also suppose that programmers were recommended not to access PPU during rendering (acces is not disabled during that time).
An emu based only on rendering scheme would not reflect the real hardware if you cannot screw it? :o(
As you can see I suppose a lot of things :o)

According to nestech.txt, writes to vram outside VBlank will cause some garbage to appear on screen.

Yeah, the key is the VRAM address ($2006 register). It's being used all the time by the PPU while it's rendering, so you can't write to palette RAM either.

Unless the program knows exactly where it's at, and set's the VRAM address accordingly.. Norix's raster demo does that.

Mm. This isn't quite what I meant. You should be able to write to palette ram during hblank; I'm just curious to if that's the *only* location where writes are valid, due to the fact that the bus is being sucked up with either the screen *or* the sprite data at all times when not in vblank. Even in hblank VRAM is getting accessed, just not through $2006's address.(or is it? Do the garbage nametable reads use the register? Documentaiton isn't very clear on this, but it would seem to imply it, thus trashing the palette argument as well.)

The corruption might be due to the address being incremented; I'm just curious as to whether or not this actaully causes a write to ram to occur. I think not.

I suppose I should have been more clear. Oh well. I'm just trying to get the remainder of the quirks sorted out at this point.. After this and fixing frame irq there's nothing left to do but mappers and bug fixing.

During hblank there are some cycles where the PPU isn't accessing memory, the 2C02 technocal doc should explain exactly when. Garbage reads do affect the VRAM address, I'm pretty sure of that.

So yeah, even writting to palette RAM will mess it up the VRAM address. (the only difference, I believe, is that reading from the palette isn't buffered so it doesn't require a throw-away read to fill the buffer)

this is because as soon as you modify $2006, you change the scroll register values. This is what was meant in NEStech as "garbage" on the screen (which is really just the incorrect playfield data).

I'm sure someone has checked this before, but to my knowledge it hasn't been documented yet. Anyway, setting aside the fact that you have to load $2006 with your valid VRAM address, trying to access $2007 during screen rendering will either result in the PPU ignoring the $2007 request (returning $FF or $40 or somthing or another), or the $2007 request will actually go through, and the fetch will interrupt a stage in the current render pipeline (causing a graphical glitch in the appropriate spot on the screen- *unless* the read is from name table RAM, and occurs exactly when the render pipeline fetches a name table byte, although this is highly speculative).

Palette RAM theoretically could be read/written during rendering, due to the fact that it's internal to the PPU. However, due to the (likely) shared bus architecture between the palette RAM & external VRAM, plus the fact that it would be impractical to have the palette RAM address loaded in the scroll counters, it could never be useful.

Anyway, there's no point in trying to do somthing with $2007 during rendering, since the scroll counters will be incrementing automatically (assuming you have your playfield enabled). So if you do need to do somthing mid-frame, it's best to either disable the screen, or wait for that small portion of time in the scanline when the PPU isn't messing with the scroll counters (and even then you'll still compromise sprites on that line if active, but this is as good as it gets).

So, the action taken is dependent upon the duty cycle at the time of read/write to 2007? No way in hell I'm emulating to that kind of accuracy. ;)

This clarifies things somewhat, at least. Time to go shuffle around some code to more accurately reflect this. Hooray.