Ok, heres what I do.

The scorepanel is located at the top of the screen (y=0 - y=32)
then the gamescreen. (y=32 - y=212)

I scroll each interrupt 8 pixels to the left (hor. scr. reg.)
And in 7 of those 8 steps I build up the new screen in page 1.
This new screen is the same as page 0 except everything is 8 pixels copied to the left.
the 8th step is used to put the new background part at the right edge of the screen.

Ok, this works fine.....

Question, however:

I copy blocks of 248x26 pixels on each interrupt......

How big a block can I copy maximum on each interrupt.

Or, question: How many interrupts does it take to copy(8,0)-(255,212),0 to (0,0),1
using HMMM copy??????

Maybe this will help: http://map.tni.nl/articles/vdp_commands_speed.php

As you can calculate from the MAP link, you're very close the maximum already. To be honest, I doubt there is time left to update the score panel with a scroll this size.

Also take note of the issues with R#18 mentioned here: http://map.tni.nl/articles/vdp_guide.php

Q: r#18 in combination with VDP commands corrupts VRAM?
A: Yes. Never alter the contents of r#18 while executing a VDP command. Doing so will corrupt the byte the VDP command is currently processing. Doesn’t look pretty ^_^ not at all. Fyi, r#18 is the screen position adjust register, also used for limited horizontal scrolling capabilities on the v9938. A simple fix is to just wait with setting r#18 until the VDP’s CE bit indicates the current command is finished.

This is writen in the article.....
Indeed a lot of bytes are corrupted when I play on my real MSX.
Resulting in random collored dots all over the screen.
However this does not happen on the Emulators......

There are a few other things which weren't in the original article but which I would like to aim your attention at. First of all, I haven't verified this yet, but I would advise you to execute VDP commands as much as possible during the VBLANK period (right after the interrupt, which should be kept as short as possible or be executed at a later time by using a line interrupt). They should execute a little faster then.

interresting as well

One more thing.....

My scorepanel starts at y=32

should I dissable the sprites at y=212 and enable them again when y=32 to increse
the speed of the vdp's copies?

Quote:

should I dissable the sprites at y=212 and enable them again when y=32 to increse the speed of the vdp's copies?

Yep, though this is a long, long time ago I did these thingies.

Quote:

Indeed a lot of bytes are corrupted when I play on my real MSX. Resulting in random collored dots all over the screen. However this does not happen on the Emulators......

Emulators are not accurate in such detail that odd behaviour like this is emulated as well. Which is the reason why everything should always be tested on the real thing.

You may also want to set your screen height to 192 pixels by the way. You won't get that much speed difference out of it, but since the result is that your screen is now 20 lines less high, you will have to copy a lot less (2,5kB less). As an added bonus, your screen size will also pad-out nicely to 8x8 cells...

You can copy about 256 * 24 pixels per 60Hz interrupt. Whole line copies (256 pixels width) are also faster than
other block-copies since the VDP can copy the sequential RAM in 1 iteration. In the latter case it has to do some extra
math and copy line-after-line.

I made a 100% smooth full-fps horizontal screen 5 scroller (256 * 192) on a MSX2 years ago with the sprite-masking
and the R#18 offset. I used the 'set screen-height to 192 ' trick (bit 7 on R#9 or something ?) and used a screen-split
on line 191-192 to support vertical scrolling through R#23. On the screen-split I resetted the screen-height to render a
'scoreboard'.

So on every interrupt R#18 and the sprite-masks are adjusted and 1/16 of the screen is copied (to an invisible page).
Every 16th interrupt you have a complete screen copied, swap the (in-)visible pages, reset R#19 and the sprite-mask
and startover again.

But please note that such a scroll takes up most of your VDP-time per interrupt.
You also lose many sprites, but that might be fixed with an additional ' screen-split ' within a single line.

In my experience (on a P4 3.4GHz) openMSX emulates complex VDP-tricks the most accurate (by far),
blueMSX is also 'correct', but the timing is less accurate (loosing the smoothness) ...

BTW:

Quote:

Maybe this will help: http://map.tni.nl/articles/vdp_commands_speed.php

Indeed a very good article. My 256 * 24 pixels 'copy-rate' on 60Hz is from experience and is - IMHO -
the max you can get, cause I did use all the mentioned tricks (wish I read this article 10 years ago,
would have saved me hundreds of hours trying & tuning ;-) and even some more.

quote from MAP:

Quote:

... If those are the case, then the tip is: as soon as the VDP starts out displaying at line 0, you start out doing your copy's. The VDP won't catch up with you then until after 2 interrupts.

Use this tip (!!!) AND combine it with the page-swaps.

Also, when using normal interrupts (with the BIOS in place) also 'RET'-out the hooks like #FD9A and #FD9F (but do restore them on exit !).
And never ever waste 1 CPU clock-cycle in your VDP routines ! Whenever you have to 'wait' for the VDP to complete an operation try and prepare all your next steps / commands / registers. As long as your 'prepare-code' completes BEFORE the VDP does no harm is done,so why not use this 'free' CPU time ?!

... but I already mentioned this in an earlier thread on the same topic ;-)

Quote:

My 256 * 24 pixels 'copy-rate' on 60Hz is from experience and is - IMHO - the max you can get

That's mine as well. But it does include the copying op the new strip at the right.

Quote:

Quote: ... If those are the case, then the tip is: as soon as the VDP starts out displaying at line 0, you start out doing your copy's. The VDP won't catch up with you then until after 2 interrupts. Use this tip (!!!) AND combine it with the page-swaps.

It's of rather limited use actually. Since your VDP workload will in practice be broken up into multiple pieces. Which makes using half the frequency rather trivial.

Also the statement that the eye has only a sampling frequency of 24fps is BS. Or at least a gross misinterpretation of the facts. But 25/30fps for games is plenty. Just check the Nemesis series for proof.

Games are ofcourse not all about the GFX & effects, so VDP-freaking is not always appropiate,
but I still prefer a full 60Hz/50Hz 'sync' for crispy and ultra-smooth look & feel.
One could always execute the (too) heavy stuff at half the framerate, or not timed at all (no vsync).

Fine-tuning the cmd-timings is just another way to make things (a little) better.
Copying a few more/extra pixels/lines, adding just those extra pixel-effects (starfield-animation ?)
or using 64 (or more) color-rendering for extra animation/aliasing/tiling.

That kind of effects are complex to create, but don't stress the VDP and make a big difference in user experience.
The VDP time won per (line-)sync is marginal, but enough for these lightweight-VDP effects to be performed.
They should ofcourse not interfere with other operations, but that's just a matter of design & timing.

Syncing the CPU & VDP as tight as possible saves both CPU & VDP cycles and thus the effective fill/copy-rate could be higher. But it doesn't just give you a few extra pixels, it also creates new/extra opportunities which can be used.
See it like SCSI/S-ATA command-queuing, sometimes the effect is marginal, but in other cases truely noticable.

The 'main framerate' can still easily be 30fps, but you do have the crispy 60fps look & feel
and also max. efficiency at the same time. And 60fps does look much smoother.
Although the human eye is 24fps a 60fps movie will still present more detail (differences) to the eye than a 30fps movie,
it's out-of-sync ... why else would there be 100Hz TVs, film is still 24~30 fps ...

Quote:

Also the statement that the eye has only a sampling frequency of 24fps is BS. Or at least a gross misinterpretation of the facts. But 25/30fps for games is plenty. Just check the Nemesis series for proof.

IIRC the 24fps comes from the fact that you need 24 frames per second to create a decent illusion of movement. You can easily see the difference between 30fps and 60fps though, for example a scroller @ 60fps moving 1 pixel per frame is smoother than a scroller @ 30fps moving 2 pixels per frame.

@norakomi

Few facts:

1) you have 16 frames (16 positions of setadjustregister) to built the background screen.
If you build the screnne in 16 steps or more you can change setadjustregister when the VDP is free.

2) if you use blocks of 16x16 and byte copy, you can move a column of 12 blocks 16x16 and have also the VDP time for doing extra VDP processing. Using TPSET I can copy up to 4 extra 16x16 blocks (very good for parallax and background animations). If you do border masking using the VDP your extra time is spent in line copy, so your transparet blocks per colum drop to 2, but remember, in this way you do not spend sprites!

3) you can also use tiles 16x32, but I do not suggest you to use larger tiles. Larger tiles means lower flexibility in composing scenarios

Did I send you my demo on Total Parody?
AR

PS
The original Total Parody was at 25 frames per second,
I mean the new with scrolling at 50 frames per second
and parallax

PPS
If your game is space manbow like, try having different
speeds of scrolling (parallax) introducing a small offset in
the tiles of the scene that is farther from the viewer.