Forced blanking at start/end then scroll, expected behavior?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Forced blanking at start/end then scroll, expected behavior?
by on (#225709)
There is one thing I would like to know, mostly for academic purpose since I do not think I would use (yet) but could. Let say for example I decide to blank the lines from the end of screen, either 8 or 16 of them. What I would like to know is:

- this would technically increase my vblank time by "skipped lines * scanlines cycles", right?
- if I decide to scroll the screen vertically and there is nothing written in that part, what will occur? will it skip those lines or still show that part?

I remember testing a scroll where I had to skip scanline to "connect" the upper/top part. I'm not sure of the behavior in that case.

Ah, one more thing. Let just say I skip instead 8 scanline from beginning, would the resulting position ends up in the not-shown lower part of NTSC signal?
Re: Forced blanking at start/end then scroll, expected behav
by on (#225715)
Banshaku wrote:
- this would technically increase my vblank time by "skipped lines * scanlines cycles", right?

That's right. Disabling rendering mid-frame can cause sprite corruption on the NEXT FRAME though, so watch out for that. Someone else can give you more details (tepples?), but I believe that in order to avoid said corruption you have to disable rendering as close as possible to the end of the scanline, but before hblank starts.

Quote:
- if I decide to scroll the screen vertically and there is nothing written in that part, what will occur? will it skip those lines or still show that part?

Blanking only masks pixels on the screen, everything that existed in the name tables before continues existing, you just end up seeing less of it.

Quote:
Ah, one more thing. Let just say I skip instead 8 scanline from beginning, would the resulting position ends up in the not-shown lower part of NTSC signal?

I'm not sure I understand the question... Are you asking if the picture will be shifted down? Well, blanking those scanlines means you'll miss the automatic scroll reset (i.e. v = t) that the PPU does at the beginning of the frame, so you'll have to set the scroll the "hard way" ($2006/5 combo) before enabling rendering mid-frame. But regardless of where rendering starts and where the scroll position is, when it comes time for vblank the PPU will stop rendering and do all vblank procedures normally, it won't extend the picture just because you started rendering late.

Even when rendering is turned off, the PPU still generates a valid video signal, comprised of 262 scanlines - 240 scanlines of picture, 1 post-render scanline, 20 scanlines of vblank and 1 pre-render scanline. The only difference is that when rendering is off, the PPU will not process data from the name, attribute and pattern tables, or from the OAM, it will just render a solid color instead. If at any point you turn rendering on, the PPU will resume its data fetching/processing activities, without ever breaking the frame structure that forms the video signal.
Re: Forced blanking at start/end then scroll, expected behav
by on (#225724)
It think I should be fine with the information provided. thanks!

As for the second part, for some reason I was sure that blanking 8 scanline from beginning would skip the data but still start at scanline 0, which make no sense after re-reading what I wrote ^^;;; I guess I'm still half asleep today.