Quote:

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

yup... always wait for HR instead of using speed-dependant code. It might be necesary sometimes, but this is not one of those times. And as an added bonus: if you poll on HR most emulators will also display your split right.

Sonic: "this way it works better in emulators" should NEVER be a reason to code something differently on MSX! Emulators are supposed to emulate real hardware, making real software run perfectly, it should not be the other way round!

In ROM (from UMF) the split was 100% perfect.

Quote:

Sonic: "this way it works better in emulators" should NEVER be a reason to code something differently on MSX! Emulators are supposed to emulate real hardware, making real software run perfectly, it should not be the other way round!

It's not a reason, it's an added bonus. And emulators are right to not emulate that kind of behaviour, since you're not supposed to use timed-code in the first place. There's at least 5 different common CPU speeds out there, so timing something on pure code is not something you should do if you can avoid it. By just polling HR you make sure it'll work on 3/5/7/8 MHz and on the R800, and... as an added bonus: it'll also work on most emulators... It's not coding something in a way so emulators will work with it, it's coding something properly which has the result that (some) emulators will work with it.

Quote:

In ROM (from UMF) the split was 100% perfect.

their are many infact. just check out that great demo scene. . . or the sunrise mag for that case.

it does explain things... doesn't it?

haha,

not too much.
Ive experimented a lot, but still no perfect split.......
Ill keep on workin

it's a long way to the top if ya wanna rock'n'roll...
took the average coder ages to perfect.

just remember, using the BIOS stuff won't perfect it perfectly. close, but not perfect. gheh.

norakomi: What exactly are the problems you are having? Is the instability horizontal or vertical? If it's horizontal, it may just be a matter of polling FH properly. If it's vertical, it can be anything from a delayed response to even missed interrupts (a bad thing). At what line(s) does your split occur? Are you keeping interrupts disabled for a long time in your main program? Are you calling a music or sfx routine on the interrupt? Is anything else on the interrupt, and if so, where? Well, you get the picture. A lot of stuff can make a split unstable, and it's hard to point out what without having some details.

the main problem is horizontal instability.
At the linesplit y=20 the page0 or page1 is displayed, but at this line, there appear some dots which are flickering.
polling FH makes the split start exactly at the beginning of y=20,
but still this weird flickering (and again, this is just a couple of dots) will not go away.
I am calling music and SFX at the linesplit, but disabling this doesnt remove the problem.

Quote:

A lot of stuff can make a split unstable, and it's hard to point out what without having some details.

I understand,
I think i have to do some digging myself.
What I would like is to see some examples.
Could someone post a screensplit code (I saw a couple on the net allready) which works very well?
Because I think that if I modify my code a bit, that the split can be optimized.

A trick I often used is to leave 1 line blank at the source and start showing that blank line on LNI.

for example you're about to split screen on Y=200 where the upper part displays vram page 0 and the lower part will display vram page 1. For example you wanna use the bottom part for a scoreboard or anything.
Now this can't be done perfectly, so just start with a complete BLANK pixeled line (color 0) at Y=200 on page 1.

First thing on the LNI (y=199) is to disable screen, wait for HR then set page 0.
later enable again.

you won't have any "random" pixels flickering about . . . it's your LNI is on the right spot (read: the machine reacts quick enough)

just analyze what is happening EXACTLY. try to draw it out and you'll understand . . .

Quote:

the main problem is horizontal instability. At the linesplit y=20 the page0 or page1 is displayed, but at this line, there appear some dots which are flickering. polling FH makes the split start exactly at the beginning of y=20, but still this weird flickering (and again, this is just a couple of dots) will not go away. I am calling music and SFX at the linesplit, but disabling this doesnt remove the problem. Quote: A lot of stuff can make a split unstable, and it's hard to point out what without having some details. I understand, I think i have to do some digging myself. What I would like is to see some examples. Could someone post a screensplit code (I saw a couple on the net allready) which works very well? Because I think that if I modify my code a bit, that the split can be optimized.

Well, what you describe doesn't sound like that big a problem. First try disabling the screen as soon as you enter your split-routine. Don't forget to enable it again at the end of your split tho If that doesn't help, try waiting one line after you've disabled the screen by polling FH (both low and high).

Quote:

Could someone post a screensplit code (I saw a couple on the net allready) which works very well? Because I think that if I modify my code a bit, that the split can be optimized.

Have you red this step by step guide?
http://map.tni.nl/articles/split_guide.php#what_split

Quote:

Quote: the main problem is horizontal instability. At the linesplit y=20 the page0 or page1 is displayed, but at this line, there appear some dots which are flickering. polling FH makes the split start exactly at the beginning of y=20, but still this weird flickering (and again, this is just a couple of dots) will not go away. I am calling music and SFX at the linesplit, but disabling this doesnt remove the problem. Quote: A lot of stuff can make a split unstable, and it's hard to point out what without having some details. I understand, I think i have to do some digging myself. What I would like is to see some examples. Could someone post a screensplit code (I saw a couple on the net allready) which works very well? Because I think that if I modify my code a bit, that the split can be optimized. Well, what you describe doesn't sound like that big a problem. First try disabling the screen as soon as you enter your split-routine. Don't forget to enable it again at the end of your split tho If that doesn't help, try waiting one line after you've disabled the screen by polling FH (both low and high).

thaz exacltly what I wrote dude...

Quote:

thaz exacltly what I wrote dude...

I know, but no-one really takes you seriously...