Quote:

remember that when using the scroll register you also have to adjust the LNI line (it will also 'scroll') so add the amount of 'scroll' to the LNI Y position to keep it save... know what I mean?

Yes, I thought of that too. The splitline is clearly visible and always halfway the screen. Isn't it strange this split affects the background when I only change the spat-register?

Quote:

btw. you don't need to use the DI command, it's disabled when entering ISR by default

Thanks. Didn't think of that.

Quote:

>>remember that when using the scroll register you also have to adjust the LNI line (it will also 'scroll') so add the amount of 'scroll' to the LNI Y position to keep it save... know what I mean?<<Yes, I thought of that too. The splitline is clearly visible and always halfway the screen. Isn't it strange this split affects the background when I only change the spat-register?>>btw. you don't need to use the DI command, it's disabled when entering ISR by default<<Thanks. Didn't think of that.

Split on sprites do not affect the background as far as I know, are you sure you're not doing anything else ? What does the split look like BTW ?

Quote:

>>remember that when using the scroll register you also have to adjust the LNI line (it will also 'scroll') so add the amount of 'scroll' to the LNI Y position to keep it save... know what I mean?<<Yes, I thought of that too. The splitline is clearly visible and always halfway the screen. Isn't it strange this split affects the background when I only change the spat-register?>>btw. you don't need to use the DI command, it's disabled when entering ISR by default<<Thanks. Didn't think of that.

Are u sure you're having the sprite allocation tables set correct etc.

Quote:

Split on sprites do not affect the background as far as I know, are you sure you're not doing anything else ? What does the split look like BTW ?

I also updated the scroll registers in cause of a line interrupt.
But now on the sprite split line, no sprites are displayed.

Quote:

Are u sure you're having the sprite allocation tables set correct etc.

Yes, all other sprites are displayed as they should.

It works when sprites on the splitline have the same position in the spat. 8)
Stupid V9938

What I meant Sjoerd: Do you have the sprite data on the same Vram page you're displaying. 'coz that would show up the sprite data als background garbage when scrolling ->> when you scroll up you will uncover the sprite data and becomes visible.

You know the sprite data is stored, standard, at the bottom of Vram page 0 (wasn't it?!?).
What you have to do is adjust the sprite attribute tables to another vram position.

if you give me your email I'll send you some interesting articels I've written yeeeears ago explaining exactly this. (it's in dutch, but it seems SJOERD will unhide your native tongue as being dutch alright)

Quote:

What I meant Sjoerd: Do you have the sprite data on the same Vram page you're displaying. 'coz that would show up the sprite data als background garbage when scrolling ->> when you scroll up you will uncover the sprite data and becomes visible. You know the sprite data is stored, standard, at the bottom of Vram page 0 (wasn't it?!?). What you have to do is adjust the sprite attribute tables to another vram position.

Yes, I have moved the table to someplace else. The scroll is working now, I had to time the register settings better.

Quote:

if you give me your email I'll send you some interesting articels I've written yeeeears ago explaining exactly this. (it's in dutch, but it seems SJOERD will unhide your native tongue as being dutch alright)

onzegrotevriend at wxs dot nl - always ready to learn 8)

n'kay.

So, you got it working already?

I'll send ya the docs anyway

regards, ro

Thanks 8)

Quote:

Yes, I have moved the table to someplace else. The scroll is working now, I had to time the register settings better.

Did you time it with HR? And does it still work on 7MHz or R800 mode?

With a scrollsplit, I would think it's tough to get it seemless without a blanked line, without CPU dependant timing.

~Grauw

Quote:

>>Yes, I have moved the table to someplace else. The scroll is working now, I had to time the register settings better.<< Did you time it with HR? And does it still work on 7MHz or R800 mode?

No HR, just the routine I posted earlier in this thread (without the DI). Works on 3.5MHz and 7MHz. Don't know about R800.

Quote:

With a scrollsplit, I would think it's tough to get it seemless without a blanked line, without CPU dependant timing.

The sprites on the splitline use the same position (same layer?) in the two sprite attribute tables. I only tested it with the sprites to mask the border yet, but these border mask sprites are seamless now.

This thread demonstrates me that I am lucky 'cause I am still coding for the old MSX1 system, and thus, its TMS9918/9928 is so simple that you don't have to think really carefully about it. If you can pass all the video data fast, then everything is fine.

I know that it is the bottleneck of the MSX1 system, but sometimes is good to code focusing mainly in the CPU.

Kind regards,

Ed Robsy

Yeah that's funny, on MSX2 you can say that if a game runs much faster on 7MHz, it is probably badly coded, as the VDP should usually be the limiting factor, however on MSX1 it's kind of the opposite ^_^.

~Grauw

Quote:

The sprites on the splitline use the same position (same layer?) in the two sprite attribute tables. I only tested it with the sprites to mask the border yet, but these border mask sprites are seamless now.

Oh, hehe, it's a spritesplit ^_^. Oops. Well, anyways, yeah, spritesplits are easy to make seamless by multiplexing the sprites on the split ('using the same position').


~Grauw

Heh, that's a new definition of multiplexing ^^;
Just remember spritedata is read one line BEFORE the actual display line. So if you change sprite tables on the split line, the first line with sprites will be one line lower.