Is it possible to make a split screen on standard MSX hardware?
Like Screen 2 on top and Screen 1 in the half lower corner.
Imagine, screen 1 in the bottom and Screen 3 at the top.

Some graphic adventure games in other platforms could use split screen.
This should be effective for adventure or RPG games.
Is this a viable situation for MSX1?

It isn't that hard to do a screen split on MSX1. The tricky part is to know when to do the screen split. You need to either calculate the number of lines from VBLANK or use 5th sprite or sprite collision to trigger when to do the screen split. The sprite collision and 5th sprite is not very exact but the VBLANK require long regions of cycle exact code.

Hum ... This is the use for Sprites into those modes! It is triggering by sprite.
Ok, Sprite triggering should be easy.

Maybe some blank space between the two "windowed" modes. This should do
pretty 8-bit graphical games!

If it is possible to use Screen mode 3, the top should be used for displaying the characters. The
extra Sprites could triggering the action and text exhibition!

Quote:

Hum ... This is the use for Sprites into those modes! It is triggering by sprite. Ok, Sprite triggering should be easy.

The problem with triggering stuff with sprites is that you get limitations on how you can use them. If you're splitting for a status bar, for example, and it's on the bottom, something may happen in the main game window (sprites collide or more than 4 are placed on the same scanline) that will screw up the split. But if the bar is at the top, I guess you are safe.

The only problem then is that some people said that those flags may not be set on the exact scanline, but, as you said, you can have a few scanlines of "nothing", to be safe.

I didn't know you could change modes during rendering, but I guess this is a nice thing. Is it really possible to do it wthout visible glitches? I guess that if you disable rendering before messing with the mode and address registers and turning it back on after you're done will probably work ok... right?

It's a shame there is no beter way to handle timing on MSX1. Relying on timed code may be a bad idea, as someone may run your code in a system with a faster CPU...

Since you don't have any interrupts that you can use as a trigger when the screensplit should be done, you need to find another way of figuring out when to do the screen split.
The easiest is to do a sprite collision at the line where you want the screensplit and then poll the collision bit in the VDP status register.
The only drawback is that the collision bit is not set at the same time every frame. It varies up to 5 scanlines, so you may need a single colored region around the screensplit.

Quote:

The only problem then is that some people said that those flags may not be set on the exact scanline, but, as you said, you can have a few scanlines of "nothing", to be safe.

Yeah, when using sprite collision or 5th sprite this is the only solution. If the screen split is synched to VINT, you can get a more exact split, but that requires timed coding.

Quote:

Relying on timed code may be a bad idea, as someone may run your code in a system with a faster CPU...

The biggest problem is actually slower CPU's, like MSX2+ and Turbo-R, but the problem is the same, timed code is tricky. Then there are minor timing differences between MSX1 and MSX2 as well.

Never could have thought of a good reason to use a screen split on MSX1. (And still can't)
The only reason for using a split for games would be for:
- scrolling games that need a status area. (MSX1 scrolls at 8 pixels (screen1 and 2))
- different color pallete for a givven area. (MSX1 has fixed pallete)
- visual effects like water. (MSX1 hasn't got the registers needed for these effects))

If you want screen 3 gfx and screen 1 or 2 GFX in one page -> Make a routine that converts the data to screen2!!!
No need to have the CPU load of the split constanly. You only need some time converting the gfx init of the gfx.

I have a reason !!!

You could need a screen split if
a) you want more than 32 sprites in the same screen.
b) you want 32 sprites of one size and 32 sprites of another size.

Actually I cannot imagine any game, due to the 4 sprite on one line limitation, able
to manage 32 + 32 sprites on the screen....
Maybe in a demo...

Quote:

a) you want more than 32 sprites in the same screen.

Well, you wouldn't need to change screen modes for that, you'd just need to point to another sprite attribute table. It's still a split, though.

Quote:

Actually I cannot imagine any game, due to the 4 sprite on one line limitation, able to manage 32 + 32 sprites on the screen.... Maybe in a demo...

Or maybe in a game with 2 playfields, such as the split-screen mode in Sonic 2, and you'd be able to have 32 sprites for each half of the screen. And a blank space between the playfields would not look bad.

Does the MSX1 really support changing the sprite attribute table during rendering? I'm sure it would not work if the first attribute table had a sprite with that special Y coordinate that will stop sprite rendering...