I think it is best to use one single copy. After giving the copy command you can do other things like
movement. Let the VDP do his job so the CPU can do another.
When you use tiles, and copy them one by one, you have to wait for the VDP between
each tile. This means that the percentage VDP time used is the same as the percentage CPU
time. Considdering a scroll takes about all the VDP time, you don't want to spend all your
CPU time aswell.
Major downside is however no multilayer (parallax) scrolling.

and how do u figure doing that ?
*crap*

the tile thing seems the only way. dunno if RAM2VRAM copies are faster?!? (store tiles in RAM) never tested that one...

Just copy a large block from the visable page to the invisable page.
You could do this before you call your music player, this way the VDP is
busy copying and the CPU busy playing music.
And ofcourse you still use tiles the make up the levels.

@ro: And well I did mean to say to copy just a part off the screen like 1/16 in a interrupt and not
the entire screen if you might think that. But not broken up in tiles, copying seperate tiles is not
only slower it is more CPU consuming.

I see some contras

1) you cannot have background animations or parallax
2) you cannot use the VDP for border masking unless you split the block in 16 smaller blocks
otherwise you need sprites for border masking

some pros

1) you are free of using the cpu time while the VDP is coping
2) you need tiles only to compose the new column entering in the screen

and a limitation:

If the copy time excedes the frame time (1/50sec) you need to change set adjust register while the VDP is busy. This can lead to VRAM corruption as someone has already pointed out.
In order to avoid this problem you need to split the copy in 16 smaller copies (one for each step in the setadjust register).

If you have a screen 256x(192-32) each frame you could copy a tile of 16x10 and a block copy 240x10.
In 16 frames you have composed a screen of 256x160, just in time for swapping page.
:-)

In any case you cannot do one single copy for moving the whole page

Does changing set adjust also corrupt VRAM when it's done in VBlank? Or when done on a line where screen display is disabled?

Quote:

1) you cannot have background animations or parallax 2) you cannot use the VDP for border masking 3) you need sprites for border masking

1) like i stated before true, no multi-layer parallax.
2,3) not true, nothing changes about that.

I was a bit inaccurate in my first reply but I think you already see that by know.

But blindly reading the copy-speed tables and using those numbers is not that wise.
Those tables are more of an indication what the VDP can do in one single interrupt
in one single copy (correct me if i am wrong). More copy commands mean wait loops
and refilling off the regs.
I would not be suprised that the result is somewhat 2/3 off that table says.
But again i could be completely worng here. It is just i experimented in B1 8-bit color
mode (gfx9000) and ended up with 80 (16x16) tiles per interrupt (about 20 kb).
By flipping the 7 MHz switch i gained 16 tiles. So i estimate the V9990 can copy about
24 kb, but the point is by breaking up in multyple copy-commands you lose not
only CPU time but also VDP time.

I agree, the larger are the blocks the better it is.

The problem is: can the copy time go beyond the frame period ?

In my opinion no, or you get VRAM corruption (acutally there should be a
way to avoid this, but I haven't a real MSX, on the emulator things go fine)
and you MUST resort to sprites for masking the borders (the VDP is busy and
cannot be used for coping lines...)

Ever noticed the great scrollings in YS, SD-Snatcher, XAK2/Gazzel etc?
All done using tiles and, more important, 8 step scrolls! (no, they're not 1 pixel smooth scollas)
This means, building a "scrolled"screen needs to 'ave "changed" tiles copy only, no adjust and blabla. and it's quicker than all above mentioned methods. think about it. unless using the msx2+ hardware scroll, forget about the whole idea. Total Parody is a great example of what can be done but the game (scroll) is sloooooow (smooth but slow be'cos of 1 or 2 pixel scroll) which might mean BOOOOORING

@ro
About TP:

The old version of TP was halfrate (1pixel each 2/50sec without parallax)

Try my new version.

It is FAST and with PARALLAX :

1 pixel each 1/50sec for the main layer
15/16 pixel each 1/50sec for the second layer

The work in progress (not so in progress, actually I am very busy)
is on magoo's webpage.

I'm lazy... got a direct link and .dsk version? (I'm at my work now and have limited resources)

send me an email I'll send you the package

kewl, thanx.

Quote:

I agree, the larger are the blocks the better it is. The problem is: can the copy time go beyond the frame period ? In my opinion no, or you get VRAM corruption (acutally there should be a way to avoid this, but I haven't a real MSX, on the emulator things go fine) and you MUST resort to sprites for masking the borders (the VDP is busy and cannot be used for coping lines...)

When the copy time goes beyond frame period, let's say a copy is 1.5 fameperiods long,
and at the end of the copy the interrupt is enabled, then a jump is made to the interrupt.
(this jump is then not on y=212)
then again a copy of 1.5 frame is made, and this results in a 40 frames per second
scroll (on 60 hertz)

Thats what I figured out until now, Im not 100% sure if this is correct though

Quote:

Does changing set adjust also corrupt VRAM when it's done in VBlank? Or when done on a line where screen display is disabled?

If at the time the set adjust is made the copy is still being done, then YES,
there will be corruption.
So I guess this is the sollution.

loop:

First set adjust the screen, then do your copy, and
then WAIT untill your copy is done,

then jp loop

so separating the set adjust and the copy seems the most important factor in
making sure there is no corruption of VramData

anyone?

You MUST split the copy in blocks whose dimensions allows and execution time lower than a frame period.

It is a matter of organization, but it is very easy

If you do a good job in calibrating the times
you can move the set adjust register
send the VDP comand in the interrupt routine
being able to use almost freely the Z80

If you want you can also have border masking via VDP in this way.
My suggestion is to do at the beginning all the smaller
copies (like tracing the lines at the borders, coping small tiles for the new
part of screen entering the scene, etc)
and then, after, copying the large block having
in parallel the z80 working.

Do all this tuff in the interrupt routine,
do smaller VDP tasks first, and leave the large copy
for last, so your waiting time is minimized