Zelda 2 rendering weirdness

So it looks like the Zelda 2 title screen is comprised of 2 nametables worth of data. When the title screen pops up it rapidly flips between the two images below (the actual title seems to flip between top and bottom of the screen):

I captured these by forcing nametable reads to logical tables 0 and 2.

It also happens in-game in Zelda 2 when you're in the side scrolling areas, Zelda 1 when scrolling from screen to screen (but not the equipment screen), Ninja Gaiden during sidescrolling gameplay, and on and on. Metroid, Mega Man 2, Bionic Commando and plenty of others work perfectly. Considering that only MMC1 games seem to see this and NROM/UNROM/CNROM games all run great without any hiccups at all I feel like I'm probably just missing some critical detail here.

You need to emulate Sprite Hit Zero flag in the $2002 register. Also you need to emulate atleast at a scanline level of accuracy because these games alter the rendering address at a specific time after the sprite zero hit flag is set. All 3 games you mentioned use Sprite Hit Zero. You may have the sprite hit implemented correctly but not render the screen in a way that supports mid frame scrolling changes.

Perhaps you have a problem with sprite 0 hit? There is a scroll split at the water line.

If your sprite 0 hit isn't working properly, maybe it's getting triggered at the next vblank somehow, leading you to alternate frames instead of splitting in the middle.

Well, Zelda II's title screen changes the scroll mid frame (creating a "split") in order to scroll text behind the scenery. How are you handling mid screen $2005/$2006 writes?

I do know that it's 1 scanline late, I've just been lazy about fixing it. I'll try that.

Nothing special happening there. I have the global latch for first/second writes, I'm not restricting it if rendering is disabled. Here they are:

Bah it was sprite 0. Some debugging code I did a month ago that was hanging around. Thanks guys!

It looks like sprite0 hit detection isn't working right for me in games with 8x16 sprites (that was the common factor in all of the broken games). Is there any gotchas to checking on an 8x16 sprite that I should keep in mind? I evaluate sprites as each scanline is rendered, and set the flag then.

I don't think there's any difference between 8x8 and 8x16 when it comes to sprite 0 hits. As for the timing of the hit, I imagine that the flag gets set when the first non transparent overlapping BG/SPR pixel is drawn, not when sprites are evaluated. Does anyone know if there's any delay for this flag being set?

I figured it out. My range when evaluating sprites was always assuming a height of 8 so a sprite0 hit that would occur in the lower region was getting ignored. Got it working now.