Hello, All.
I'm taking into consideration to write a game with smooth horizontal scroll.

In order to achieve this goal, i've planned this way to do, and i need to ask you if it's possible.

take into consideration please:
- I work in screen 2 using the first 2/3 of the screen, two sections of 256 tiles each one.
- I do the scroll using prepared tiles in ram, shitfted by 1 bit each set
- I need a large number of scrolling tiles, 128 for each part of screen (first 1/3, second 1/3)

My solution:

I have the 256 charater set splitted into two subset of 128 chars, called subset1 and 2

a) at first VBLANK i write the name table with charater codes using the first 128 chars on screen. (subset 1)
b) then, in the active area i blit the subset2 (that is not displayed) with 1 pixel scrolled data (128*8=1024 bytes)
c) the next VBLANK i write the name table, enabling the subset2 wrote before at (b)
d) i do the same of (b) but with the subset1
e) goto (a)

at each vblank i need to execute steps (a) or (c) in the vblank period, then (b) or (d) after the vblank period.

Now, taking in consideration that i need to work with 2/3 of the screen, i need to write at each vblank 2*128 bytes (name table)
outside of vblank i need also to write 128*8 = 1024bytes by blitting data. Sections are the two screen2 top sections so i need to write additional 2048 bytes.


Now, i ask to all, it's possible with msx1 I/O vdp limits?

2.5K should be ok if you get timing right.

I don't think its doable the way you describe it. If you're blitting the new tiles in the display area you need to blit 2048 bytes at 28 CPU cycles per byte. This requires 2048 / (228 / 28) = 252 scanlines. The bg map can be blitted faster, 18 CPU cycles per byte is doable with unrolled loops in non display area. So blitting the bgmap will take 512 / (228/18) = 41 scanlinest then you also have some control code so the real numbers are a bit higher even with unrolled loops.

On a 50Hz PAL system you may fit it but it doesn't leave much CPU for other tasks. You can also move some of the tile blit into non display area and save some CPU cycles but its still quite tight.

I think you need to go to either lower number of tiles like Malaika or to do mirrored mode like the GnG demo. Both has advantages and disadvantages.

Quote:

I don't think its doable the way you describe it. If you're blitting the new tiles in the display area you need to blit 2048 bytes at 28 CPU cycles per byte. This requires 2048 / (228 / 28) = 252 scanlines. The bg map can be blitted faster, 18 CPU cycles per byte is doable with unrolled loops in non display area. So blitting the bgmap will take 512 / (228/18) = 41 scanlinest then you also have some control code so the real numbers are a bit higher even with unrolled loops. On a 50Hz PAL system you may fit it but it doesn't leave much CPU for other tasks. You can also move some of the tile blit into non display area and save some CPU cycles but its still quite tight. I think you need to go to either lower number of tiles like Malaika or to do mirrored mode like the GnG demo. Both has advantages and disadvantages.

@Dvik:Maybe could be done by using 1 vblank to do the first 1/3 and a second to do the second half?
(Lowering the fps and increasing the scroll at 2pixels per frame)
in this way i have to move only 1024 bytes+bg map..

Yes, lowering the fps is of course another solution. How you choose to split the tasks over the two frames doesn't matter that much. You could do all vdp blitting in one frame and game contol in the other, or do some blitting in both frames. The important thing is to blit all of the bgmap in the same non-display area to avoid flickering.

About the VDP issue, note that you can replicate the character sets of banks 1 & 2 leaving the bank 3 "standard"
Moreover you can replicate only the shape of the tiles in bamk 1 & 2 leaving all the color definitions of the 3 banks as "standard"

This can help, as you do not need to update colors if you want only orizontal scrolling, moreover in this way
you can have the same tile with different colors depending if it is in bank 1 or 2
Consider that, if you plan some parallax, you colud have different speeds of tile update

some tiles could scroll slowely while others could be faster, so you can limit the # of tiles to update at 50Hz

The way we deal with the 50/60Hz problem in our new game (which is quite CPU intensive) is that we use the last 20% of every frame in 50Hz to low priority tasks that don't need too quick updates and in 60Hz we combine all these low priority tasks in every 6th frame (which is fully dedicated to the low prio stuff and doesn't do any of the things done in the other 5 frames).

This has some other benefits too. The game will run at the same speed in both 50Hz and 60Hz and you'll get full utilization of the CPU. The only limitation for you is of course that your blitting routines need to be adjusted to 60Hz but in reality this is not an issue since you most likely have other tasks that needs 20% of the cpu.

Quote:

Moreover you can replicate only the shape of the tiles in bamk 1 & 2 leaving all the color definitions of the 3 banks as "standard"

I just tested on my $1200 Yamaha CX5M and mirroring the tiles also mirrors the sprites locates in the top 1/3 of the screen, so if you use mirroring I'd recommend you to not use sprites (at least in the top 1/3 of the screen)

does it happen even if you replicate only the shapes?
does it happen even if you reploicate only the first two banks only?

It does happen if I replicate only the shapes (which is unfortunate since the GnG demo does just that).

I haven't tried to replicate only the first two banks though. My guess is that the sprites will be mirrored from the top 1/3 to the second 1/3 but not to the lower 1/3.

I was hoping that having a $1200 machine would help but apparently money doesn't solve everything.

Quote:

I was hoping that having a $1200 machine would help but apparently money doesn't solve everything.

*LOL*

Yes.. a true running gag has been born with this serial number madness.. ^^

Quote:

I think you need to go to either lower number of tiles like Malaika or to do mirrored mode like the GnG demo. Both has advantages and disadvantages.

Can someone explain to me how the mirroring of tiles work ?
I'm just curious about learning that trick

@PingPong If you need to update also color table then it will not work anymore in 1 interrupt (total 4.5K) but as I said without color table (2.5K) you should be fine. I suggest that you design the order of blocks so that you don't need to update color table. How ever with 128 blocks that might be quite hard. The 2 colors / 8 pixels limit makes it hard anyway.

If you want to blit 128 tiles and the bgmap you need to transfer 2 * 128 * 8 + 2 * 256 = 2560 bytes.

There are 228 CPU cycles per scanline. During display area you can only write to the VDP once every 28 CPU cycles. During VBlank you can out as fast as you want but you probably need to use outi which takes 18 cycles.

So the maximum number of bytes you can transfer in one 60Hz frame is

192 * (228 / 28) + (263 - 192) * (228 / 18) = 2462 bytes.

So you actually won't be able to fit everything into one frame unless you limit your game to 50Hz only.

(You also need some loops and other logic which will reduce the bandwidth a little bit)

The best is probably if you copy the tile data (2048 bytes) on even frames and the bgmap together with the game logic on odd frames. This gives you some room for running e.g. PT3 replayer on every frame.