hmmm, I could try that,
thats not even a bad idea.
At this moment I have the music and sfx on the lineint,

But Ill just disable them for now, and move the copy instruction to line int.
Ill inform you what happened soon.
(right now Im not able to check the source code on a real msx, only emulators)

Just put *everything* on the lineint. The only thing you should do on vblank is the sprite routine. You could even move that to the main loop tho. If you use two tables all you'd need to do on vblank is set the correct table. If you're gonna test on emus tho, test on openMSX. It's pretty accurate when it comes to stuff like this, and will prolly emulate the split correctly.

oh yeah... that's a smart thing to do...

howto: make an even more unstable line-int?
answer: just put everything on it

the code on a line-int should be short and sweet as it should be handled as quickly as possible... and to keep the the split steady you should keep interrupts enabled as long as possible.

This just shows how much you know about splitting. Of course you put everything on the line int, it's the biggest 'space of CPU' time where timing is not important. The period from the line-int to vblank is almost 4 times as long as the period from vblank to the line int. The logical thing to do is put all the action where you have the longest period of time. Unless of course you are suggesting running these routines before the screen-split code, but not even you are that n00b, right?

that's for me to know and for you to lose sleep over

you know it, it's one of my biggest worries

This whole conversation about what to put in the interrupt and what to leave out of it seems pretty stupid for me. Heck, if you plan the timing well you don't even need the interrupts!

The only important thing is, that you don't let the CPU to wait! You have always same amount of time no matter is it used inside or outside of interrupt. Only place you get more time is from the waits.

If you let BIOS to handle interrupts, you have a small problem: Different MSX computers take different amount of time to handle interrupts before CPU gets to your interrupt code. This causes a need to poll correct interrupt line. This means, that CPU needs to wait. How ever I don't consider this wait as "expencive". If you use custom interrupt handler, you know how much time it takes before the actual split is made, so you don't have to wait. Note anyway, that if you don't do the split ASAP the split may come too early in overclocked MSX machines.

To spot the biggest "time eaters" I recommend, that you insert routine that changes the background color before each wait and another routine that changes the color back just after the wait. This way you can actually see, how much time you are not using.

In this kind of game programming typically only screen split is needing accurate timing. Rest of the tasks just need to get done. This makes me think: Just do the split and restore of screen in interrupts and do all the other tasks outside of interrupt. Doing more tasks in interrupt only makes it harder for you to follow what is the order used to execute tasks.

The place where you most propably tend to wait is the screen build copy routines. This is because you need to start the VDP copy and wait until it is ready before you can move next tile. The most efficient way is to make routine that waits until VDP is ready and copies NEXT block to screen. (Note: Only one copy command) After that you can put call entrys to this routine between other tasks. This is quite a painfull job to do but this way you use minimal time on wait loops as CPU is most of the time doing something usefull.

Example:
	CALL COPY_ONE_BLOCK
	CALL READ_KEYBOARD
	CALL COPY_ONE_BLOCK
	CALL READ_JOYSTICK
	CALL COPY_ONE_BLOCK
	CALL CALCULATE_SCREEN_COORDINATES
	CALL COPY_ONE_BLOCK
	.
	.
	.

; All tasks are done, but screen is not yet ready.

COPYLOOP:
	CALL COPY_ONE_BLOCK
	LD A,(COPY_READY_FLAG)
	AND A
	JR Z,COPYLOOP

Quote:

In 14 steps I buildup the new background in the inactive page (page 0 or 1) then at step 15 I draw a black block of 16 pixels wide and 256 pixels high at the right. And then at step 16 I copy a piece of background (also 16x256 pixels wide) at the left.

this means that from step 1 to 14 I always do the same. But at step 15 and 16 I do a different copy (with a different duration).
Is there a way to create a backgroundscroll in which each of the 16 steps do exactly the same?

appears to be really easy. each step:

1) copy 16 lines 16 px to the left (or right, whatever you want)
2) draw line of 16 px high, 16 px wide on the left
3) like 2), but on the right
4) repeat 16 times, increase y coordinate by 16

done?