Why different split delay when no second background loaded?

[tsu]

Hello, this ain't so newbie of a question, but I am.
Anyway, I was working on a game three weeks ago and something bugged me.
I had split the screen after 64 scanlines when sprite0 hit. At the split I enable scrolling, wait 64 more scanlines, and there I have the screen scrolling the opposite way by decrimenting xscroll. That lasts 64 more scanlines, then I turn off scoll for the rest of the screen. But the weird thing was that the wait amount for the first and the second scrolling area was not the same. And when I added the second nametable of background graphics, then the two wait times were the same.
So I guess if the second table is empy, somehow the ppu takes less time to get down?
I can post the source if this is confusing. I suspect it's well known, like for title screens that scroll on from both sides, maybe. Not using scanline irq counters.
No excuse for not searching this one. I'm sorry.

[3gengames]

That makes no sense to me. Also, you can not EVER "disable" scroll. Never. Do you mean rendering? But still, a video or something would help as I personally don't understand the problem at all.

[tokumaru]

I personally don't understand the problem at all.

That makes no sense to me.

O_o

But the weird thing was that the wait amount for the first and the second scrolling area was not the same.

Are you saying that the the amount of time you have to wait for each of the 64-scanline areas is different? Are you sure you don't have branches crossing pages or anything that could cause similar-looking code to take different amounts of time to complete?

And when I added the second nametable of background graphics, then the two wait times were the same.

If that caused the wait code to be relocated, my guess makes sense. A branch was crossing a page (adding 1 cycle to each iteration of the loop, could add to a lot of cycles in the end), but after more code was added it wasn't crossing anymore.

So I guess if the second table is empy, somehow the ppu takes less time to get down?

No, that doesn't make any sense.

When you use timed code, you really have to pay attention to page-crossing. You need to look at the binary and see where these timed loops ended up, to make sure that branches aren't crossing pages and screwing up your timing.

[tsu]

Sorry guys, it was just some redundant code.
But it makes me wonder about further page crossing problems I may have. I hope there are some compilers that will warn if large loops cross pages. Because those extra cycles may be hard to spot for other tasks that aren't visual.

[tokumaru]

I hope there are some compilers that will warn if large loops cross pages.

You can use macros for that.