Fx3 wrote:
- Problem is... I put a check for loopy_v A12 at every PPU cc. From what you said, looks like loopy_v A12 is "ignored" when the screen is rendering..?
Correct. MMC3 does not look at loopy_v at all. It looks at the PPU bus.
In fact... this is true even during VBlank or when rendering is disabled. The PPU bus is all that matters -- loopy_v simply doesn't matter.
Quote:
If this is true, 2006/7 writes during midframe have no effect on MMC3 IRQs.
Not necessarily.
It just so happens that $2006 and $2007 update loopy_v
as well as the PPU bus. But don't let that trick you into thinking that they're the same thing.
To put this in some simple pseudo code to help drive the idea home:
Code:
//---------- on $2006 / $2007 write
loopy_v = whatever;
ppu_bus = loopy_v;
//---------- during PPU rendering
// NT fetch
ppu_bus = 0x2000 | (loopy_v & 0x0FFF);
// CHR fetch
patterntable = {0x1000 or 0x0000};
ppu_bus = patterntable | (tile << 4) | fine_y_scroll;
// --------- MMC3 logic
if(ppu_bus & 0x1000)
{
if( !(old_ppu_bus & 0x1000) )
{
// A12 rise
}
}
old_ppu_bus = ppu_bus;
Quote:
- One more: at cycles 324 and 332, does the background need to be enabled for proper A12 rising, or background or sprites is ok?
Background and/or sprites. It's all or nothing... either rendering is fully enabled (which is true if either BG or sprites are enabled), or it's fully disabled. All fetches are performed and all logic is done by the PPU when rendering is enabled. And none of it is performed when rendering is disabled. There's no in-between middle ground.
Quote:
Yet, when there are less than 8 sprites per line, the CHR fetches fetch from $1xxx, correct? Like, if there are no sprites, we'll still have 8 A12 rises..?
Correct. The fetches are still performed if there are less than 8 sprites, just with dummy values (the PPU will fetch CHR for tile $FF). With 8x8 sprites, this could be from either $0xxx or $1xxx depending on reg $2000. But with 8x16 sprites, this will always be from $1xxx.