Maybe you'd like to see the actual splitcode first:
_________________
$FD9A $C3
$FD9B-$FD9C LININT
_________________

JUMPER: DB 255
LININT:
DI
LD A,(JUMPER)
OR A
JP Z,LIJN
ONDER:
XOR A
LD (JUMPER),A

LD A,($F3DF)
OR 16 ;SET EI1
LD ($F3DF),A
OUT ($99),A
LD A,128
OUT ($99),A
RET

LIJN:
CALL DISSCR ;DISABLE SCREEN

LD A,255
LD (JUMPER),A

LD A,($F3DF)
AND 239 ;RESET EI1
LD ($F3DF),A
OUT ($99),A
LD A,128
OUT ($99),A

JP STARS ;LINEINT ROUTINE

at the splitline i do this:

STARS:
CALL SETPAG ;set gamepage 0 or 1
CALL SETR23 ;set verticall screen offset
CALL ENASPR ;enable sprites
CALL SETR18 ;set horizontal screen offset

ld a,2
out ($99),a
ld a,15+128
out ($99),a ;set status r#2

Poll_1: in a,(#99) ;wait until start of HBLANK
and %00100000
jp nz,Poll_1
Poll_2: in a,(#99) ;wait until end of HBLANK
and %00100000
jp z,Poll_2

CALL ENSCRE ;enable screen
xor a
out ($99),a
ld a,15+128
out ($99),a ;set status r#0

POP AF
JP $D02 ;JP INTRET return from interrupt (do all the POP's)

But in the game at the splitline I still see some fuzzyness.
Its not a perfect split.
Sometimes an extra black line, sometimes some colored dots at the splitline........

Anyone an idea how I can update my SPLIT-routine?

aaah, the good old thrashsplit stuff

what's important:
first thing on a LINEINT is to check horizontal trace to end (wait for new vertical scanline)
disable screen
do your stuff
wait for htrace again
enable screen

however, it might be that dis/ena screen will only setin on next vertical line so you don't even have to wait (I forget if thaz true)
don't use any overhead code (like "calls" in your int. make it as fast as possible.

norakomi
Your code has a huge overhead, get rid off of all that crap "di" and "call" instructions
The FIRST THING you need to do is to access to VDP!!!
Forget the others.

LININT:
ld a,(XXX)
out (99h),a
ld a,X
out (99h),a

ld a,(YYY)
out (99h),a
ld a,Y
out (99h),a

put here the crap in order to 
modify (XXX) and (YYY)!!
...

Quote:

what's important: first thing on a LINEINT is to check horizontal trace to end (wait for new vertical scanline)

why check at the beginning of the split??There are only black lines around my linesplit.

Quote:

don't use any overhead code (like "calls" in your int. make it as fast as possible.

There are black lines from y=16 to y=24 and the split is (now) being executed at line y=17.... so even if the split routine would take long (as in, lets say 4 lines), then still there should not be any problems......
hmmmm...... let me think about this one

another question:

what should i modify in my code to make another split at y=24?
Then I can have this second split do nothing more then:

ENABLE SCREEN

(however: if the problem is that sometimes the LINEINTS are delayed (because of DI outside of the int), then this would also not fix the problem)

add a new jumper on #fd9a

add a new jumper on #fd9a

the garbage around your split is actually IN your split. (use disable screen first is a way to hide the mess) whaz with that "jumper"check? vbl / lni ints are stored on differnt hooks, so why?
(better do a vdp status check to test if the lni is a real lni)

if your lineint is at y = 17, you can simply wait for y=24
you have to set the R#19, do "di" and poll S#2

While waiting you can perform some usefull task

Quote:

whaz with that "jumper"check? vbl / lni ints are stored on differnt hooks, so why?

Dunno 2B honest. I just used this piece of code. It isnt mine.
TwazzentMe

Quote:

(better do a vdp status check to test if the lni is a real lni)

polling s#2?

At lineint do in the ordert

1) set VDP registers for split screen (first thing or you get messy pageswap)
2) set r#19 = next lineint
3) di
4) poll S#1 reading FH and wait for the int
5) set r#19 = first lineint
6) end the routine

FH is the horizontal scanning interrupt flag
Horizontal scanning interrupt (which is specified in R#19)
flag. If IE1 is set, an interrupt is enabled. When S#1 is read, FH is reset.

norakomi: there's really two (easy) ways to go about splitting in this situation.

1) just use a simple line-interrupt
2) combine the line-interrupt with a poll

Since you say you have a number of black lines in the area, I'd figure the first option would do. This is probably also what you're doing. The second option is required if you want to make sure your split is vertically stable. You can check the horizontal retrace to make sure your split is horizontally stable. If the area is completely black tho, this might not be needed. Either way, make sure you set your line-interrupt to occur well before where you want the split. I'm guessing *at least* four lines, but prolly even more. If you're seeing artifacts around the splitline, make sure you disable the screen first. The neatest way would prolly be:

splitroutine:
*optionally* reset R#19 to the line where you want the split to happen (-1) and poll for FH (S#0, bit0)
disable screen
*optionally* check HR (S#2, bit 5) and wait for horizontal retrace
do your thing
*optionally* check HR (S#2, bit 5) and wait for horizontal retrace
enable screen
reset R#19 to the next line-int (if there is more than one split)

If at any point the value of R#23 was changed, make sure to take this into account when calculating the line at which your next line-int takes place.

It takes some time for the cpu to react on the line interupt that is generated. So twice a nice ex (sp),ix
might be taking enough time to enter the HBLANK period. So entering is simple... leaving requires the
use of the HR bit (with some extra wait time?).

Quote:

It takes some time for the cpu to react on the line interupt that is generated. So twice a nice ex (sp),ix might be taking enough time to enter the HBLANK period. .

what about speed differences between MSX2, 2+,Turbo R?
And what about the split method?
It seems more logic to wait for horizontal retrace