More or less.
My screen in 192 pixel tall, my copy commands are largely executed during vblank, I disable sprites in the score bar, and try to move large areas of the screen as a single command.
The scrolling is in C and ASM, the code is few lines in files main.c and level.c
@ARTRAG, I wonder, removing the splitscreen to give more time for the blitter to run (because ajdust register wrecks blitter copy), wouldn't that give a larger display.
The whole thing combined with not drawing the tiles with blitter but with cpu port 98 from RAM, more time for the blitter for the column copy.
;some outer loops setup tile addr from nametable
14 out (c),l
14 out (c),h ;set vram addr
5 inc h ;one line down
5 exx
18 outi ;tiles stored 90 degree rotated in RAM, to port 98.
5 exx
--
61
The raw inner loop is 43 rasterlines cpu for 160 lines display.
Sacrifice some cpu time to get more VDP.
Screen 5 with 32 pixels column copy should get same display hight at 2 pixels per frame scroll speed.
;some outer loops setup tile addr from nametable
14 out (c),e
14 out (c),d ;set vram addr
5 inc d ;one line down
18 outi ;tiles stored 90 degree rotated in RAM, to port 98.
--
51
@NYYRIKKI
thanks for the video and for the music, this latter is awesome ;-)
@ frederic.markus
Roms and sources are here https://sites.google.com/site/testmsx/Home/double-buffer-in-...
@hit9918
I evaluated the idea of storing tile data in RAM/ROM but I was planning to write SAT data using the CPU while the vdp was coping the new column. Moreover my solution was working even in screen 5 without changes, while in screen 5, using the CPU for blitting the new column would imply scrolling at 2pixel's steps or a little jittering of one column.
IIRC, the adjust register doesn't wreck any blitter copy: I reset it at lineint, before starting the vdp commands, and I set it to its actual value at vblank interrupt, just before the screen starts being displayed.
All vdp commands are executed in the sum of the vblank time and the scorebar time.
Anyway, for scrolling in screen 8, the solution of having in ram/rom the tiles is definitely to be reconsidered, as it allows the use of 256 tiles of 16x16 pixels, where instead the current solution can only use the room under the border and the scorebar.
Moreover I think that your approach allows an higer degree of parallelism between cpu and vdp, as there is less "context switch" for the z80.
Moreover, building tiles can be "compressed" storing repeated columns only once and using pointers to columns
Maybe, single columns can be further compressed using RLE encoding (as I did for textures in the 3D raycaster)
BTW in your code I think you missed a dec C before outi and a inc C after it
out (c),e ; here C is port 0x99
out (c),d
ind d
dec c
outi ; here C has to be port 0x98
inc c
--- ; loop
total 61 cycles
