Quote:

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

I did,
Id be happy if someone would post some of their own code here.
I know everyone uses a different splittechnique, and I can learn a lot about my own code,by looking at someone elses.

There's really no 'technique', it's basically doing a number of OUTs in a certain sequence. What those OUTs are is completely dependant on what effect you're trying to achieve. If you tell me what exactly the split needs to do I could tell you what to out to the VDP, but you prolly know that yourself already...

How about this:

while (!HR) {}     // Split generated halfway HBLANK. Finaly here somewhere in Display Pr.
                   // So just simply wait for start HBLANK
Disable screen

Do your VDP stuff here...

Now it will get 'tricky'. There are a number of options:
1 - Exit and use another line split to set enable display, same as above.
2 - Now where the code is finished (try and fail) and use a single "while".
3 - Use something like the code below.

if (!HR) {
  while (!HR) {}
} else {
  while (HR) {}
  while (!HR) {}
}

Enable screen

ret

Scanning for the start of HBLANK and not for the end is what I think the thing to do.
But the above stuf is all theoretical... still I am sure it will work.

Quote:

1 - Exit and use another line split to set enable display, same as above.

yes, I was thinking this exact same thing, and have been trying it out.
Not yet with the desired results, but I see what you mean !!
Some strange things happen when r#18 is used within the split, and when sprites are disabled.
Im not quite sure what it is, but
enabling/disabling sprites or screen, and using r#18 altogether can be tricky !!

You don't have to 'exit' to do that. It's perfectly normal to use a polling split within a line-interrupt routine. All you have to do is disable line-ints, reset #19 to the desired 'exit line', and start polling FH (S#1, bit0). Once it goes high, enable the screen and setup the next line-int (if any). That's how I do most of my splits, use a line-interrupt to 'arrive' like 4 lines before the line I want the split to occur, and then reset R#19 and start polling. That's only required if the split *must* occur at a certain line though. The situation you described (a number of black lines before and after the split) wouldn't really require such a technique.

Quote:

Quote: thaz exacltly what I wrote dude... I know, but no-one really takes you seriously...

point taken...

Hey norakomi, if you still want to discuss that screen-split issue, join us as #msx on the rizon network when you have some time. I also made you the ISR we talked about on the fair.

Thanx Sonic !!

I'll be there soon (got a bit of a flue, so I'm going to relax a bit)

Hey Sonic,

That last file I send you looked fine on Bluemsx,
On a real msx though, the split still wasnt perfect.
I played a bit with the code and I found that the ' type ' of background scroll I use,
was the cause of the split not working fine.

If I dont scroll the background, but just increase the horizontal and vertical screen offset on
each int, then the split looks perfect.

I didnt alter anything in your code, but still it's not perfect with the type of scroll I'm using.
Somehow it feels like I have to change the scroll-code, and not your split code....

in the end he will join a real development channel for help

Scrolling up and down alters the line number, so the bug could be in the line int position determination code.

no its not, because even without the vertical scrolling the problem is still there.

It has something to do with this:

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.

The split problem is as follows:

When I dont do all the above mentioned copies, (but only alter horizontal and vertical screen offset) then the split looks perfect.

With the copy instructions the split doesnt look perfect at the split line.
(you see flickering dots at the split line, also at the omplete left and right borders)

This could be a problem of DI / EI and bios calls.
Avoid any bios call and work without interrupts enabled.

Do this test: disable any interrupt, avoid bios calls and
put in the main loop a polling for the bit of S#0 that says that a vertical interrupt has occurred.

When you get the bit call your current Vint routine.
This is a definitive solution to any starnge behaviour has you have the full controll of the z80
and you can work with cycle accurate precision.

Quote:

in the end he will join a real development channel for help

Funny, I don't see anyone in the real development channel offering to write an ISR/split routine for him. In fact, I don't see those real developers doing anything other than talking crap. Perhaps those real developers should spend less time talking crap and more time coding?

Quote:

The split problem is as follows: When I dont do all the above mentioned copies, (but only alter horizontal and vertical screen offset) then the split looks perfect. With the copy instructions the split doesnt look perfect at the split line. (you see flickering dots at the split line, also at the omplete left and right borders)

I don't think the actual copies are the problem. Most likely the problem is waiting for those copies to finish. Have you tried moving these copies to the line-interrupt hook instead of VBLANK?