Rendering enabled after the end of VBlank x Sprites

[Bregalad]

EDIT: Another clear advantage of blanking the top instead of the bottom (specially when using 8x16 sprites), is that sprites can can move smoothly at the top, something that leaves only the left side of the screen with sprite issues, and if that really bothers you, just hide the leftmost 8 pixels as the PPU allows it, and you get perfect sprite movement.

You can also clip sprites proprely by setting 8 transparent highest priority sprites where you want sprites to clip. In fact I guess you have time to switch all sprite banks in, and then all BG banks in next scanlines (since fetches are done one scanline eariler) without getting much glitches. Disabling the screen and hoping for it to scroll correctly when you enable it back is dangerous. You have to make sure you enable it before HBlank if you do this. Also, I have no idea how the scrolling counters behave if BG is off but sprites on. I guess they incrase only if BG is on, but all docs only mention the case where everything is off, or if everything is on.

The screen is right-adjusted on my PAL TV, all lines are visible, but there is no extra border either. I guess maybe the leftmost one or two pixels are hidden, because the 'S' of the 'SCORE' word in Castlevania III, which is in the first column, seems a bit deformed/weird and is almost clipped.

[tokumaru]

You can also clip sprites proprely by setting 8 transparent highest priority sprites where you want sprites to clip.

Yeah, but wasting sprites seems wrong...

In fact I guess you have time to switch all sprite banks in, and then all BG banks in next scanlines (since fetches are done one scanline eariler) without getting much glitches.

This works better when the BG uses 2 2KB banks, because there is time in HBlank to switch in 2 banks, but not 4. In my case anyway, there is no such thing as "sprite banks", because sprites also use tiles from the background side, meaning that some sprites would be visible during that scanline while others wouldn't, and that's just weird.

Disabling the screen and hoping for it to scroll correctly when you enable it back is dangerous. You have to make sure you enable it before HBlank if you do this. Also, I have no idea how the scrolling counters behave if BG is off but sprites on. I guess they incrase only if BG is on, but all docs only mention the case where everything is off, or if everything is on.

You are right. I decided to keep it simple and have all rendering enabled from the start and never disable it again. It's all working pretty nicely now:

Everything uses transparent patterns until scanline 14, when the IRQ fires. Then I have both sprites (which are still 8 pixels tall at this time) and background fetch tiles from $1000 (which is divided in 2 2KB banks). This gives enough time to load the 4 1KB banks to $0000 during scanline 15, because no one is using those tiles.

Then I wait until HBlank, where I change the height of the sprites to 16 pixels (so that they are properly evaluated during the next scanline) and have the background tile be fetched from $0000, so the background is already displayed on scanline 16. During scanline 16, the 2 2KB banks are loaded, so sprites are only displayed on scanline 17.

I guess I'm not bothered by the fact that there is a full scanline after the border with no sprites at all, because everything is much more solid now, the time while the border is being displayed is already being used to process the next frame and it works just as fine in PAL mode, because timing is not so critical now. I'm glad with this solution.