ha! That's a neat trick indeed! The one tricky thing would be to make sure objects going through the edge of the screen do not reappear on the other side though 
"local map", is this a RAM nametable. along with it could come a faster scroll border fill.
Yes, that's another way of looking at it, another motivation for me to do it. Though one slightly tricky thing is, 17 tiles can be visible at once in the x direction when scrolled. I think I'll have to cheat a little there, to keep the local map at a convenient 16x16 size.
ha! That's a neat trick indeed! The one tricky thing would be to make sure objects going through the edge of the screen do not reappear on the other side though
Yeah, in principle, carry checks in the right places... but the reality will probably be more stubborn 
.
4: Drawing new map tiles (44.42%, 7.4 ms)
Yesterday I optimised the tile drawing code, it now takes 31% CPU time per frame (5.2 ms), which also maxes out the VDP copy speed for sixteen 4x16 tiles, so this is about as fast as it’ll get :).
It’s mostly due to optimising the tile lookup code, previously I would calculate the tile data address for every piece copied, now I calculate the position once and only increment the address between draws. (I’m not using the “local map” I talked about earlier yet.)
I also simplified the code to always draw a full 4 pixel wide column / row (16 copies) rather than breaking that up in 4 parts (4 copies). This was originally done to minimise the copying time when scrolling 1 pixel per frame, but since nowadays I scroll 2 pixels per frame anyway, with the copies spread out across two frames, there’s no reason to optimise for 1 pixel scrolling anymore.
I do have something to do in the gap of time between each 4x16 copy: prepare the next copy . Previously this preparation was taking too long, so the VDP was idling between copies. Now the CPU is done in time to keep the VDP busy.
But I don’t think there’s much time left to do anything else. Switching contexts to another task alone would probably already take more time than it takes the VDP to complete such a small copy. The copy itself takes about 0.3 ms (1074 cycles), and that’s including set-up which takes 443 cycles already.
Interesting thing about focusing copies into the blanking period. Leaves some access slots wasted though, maybe you should also try to write sprite data to VRAM inbetween the copies ;).
I myself am not starting these copies during blanking or anything fancy like that. Luckily these column copies happen in the masked 8x212 area, so they are not visible, so I can do them whenever. For tile animations I also don’t think I have to worry much about tearing.
Unfortunately the V9958 does not have a CE interrupt like the V9990 does (my no.1 wish they had)... I did consider making “copy slots” on line interrupts and processing queued copies there. It leaves the VDP a little idle, but the CPU can continue unhindered, and the idle time can be minimised by careful tuning of the split distances. However, queueing copy commands also takes extra time, plus line interrupt overhead... I may still try to do it for the larger (16x16) copies for the tile animations, but I’m not sure if it’s going to be worthwhile.