dvik: Malaika does not change patterns or color definitions during ingame stage, as every possibilities for each tile are pregenerated and preloaded to VRAM pattern and color definition before the stage starts, independly for each bank, in order to use different "tilesets" in different banks at the same time. At Malaika, just the name table and the sprite atribute data is transferred during the ingame... this way every time I make a transfer to vram I transfer the same amount of data no matter the frame.

Your GnG approach can't work that way, as you have lots of more tiles out there: so I guess you redefine patterns while the ingame, and at each 8 frames you really scroll the name table too. What I can't imagine is how you can transfer that much data into the vram every frame: and moreover, how don't you get a slower frame each 8 frames, because of transferring the name table definition each 8 times?  , and how you still have room for the game and enemy logic for every frame?. Man, your code should be really efficient in order to work that way! :god:

Actually, 8 pre-programmed sets of 32 tiles for a smooth1-pixel scroller. The thing is that each bank has an independant definition, that's why there are more than 32 tiles there (for example, those tiles being a cloud in the upper banks are the green grass at the bottom bank). Remember that this is not a mixed mode, but normal SCREEN2, so I have independant bank definition for my tricks' pleasures

Veijo, does, your original concept about GNG , use screen 2 or as dvik one are you using a hybrid mode?

OK, i've done some experiments about scrolling. Let's me explain.
I start with pure screen 2 and i have all the tiles loaded, changing only the name table.
I start in the leftmost position say, x=0 (charater position,not pixel position)
Every 8 pixels scroll (my example is only forward scrolling but can be adapted), i reload the same table as in position x=0, only shifted 1 char left. Plus i redefine the changing tiles (because of the scroll the in-going tiles from right maybe are new shapes).
With the dvik patterns i've found that during scrolling only 1 to 5 tiles must be redefined, and some tiles became unused because they go out of screen.

The point is that instead of redefine 100 char tiles, i only redefine the new tiles that are from right to left.
In the worst case an entire column of tiles (24) need to be redefined, however pratice showed me that only 5 tiles can vary between physical name table scrolls.


The z80 have all the info to quicly modify only the tiles needed, because the work of determine witch tiles change is done on a PC that takes a full map bitmap image, scan this and generate tiles info.
Thus every name table scroll, the z80 overwrite the unused tiles patterns and colors with the new from right, and do also the name table scroll

There is an advantage:
You do not need to keep all the tiles of an entire map to a maximum of 64 different tiles. Only at a specific x charater value you are costrained to 64 tiles. when the screen scroll, new incoming tiles (24) will substitute the tiles that are unused.
Of course the n. of tiles on every screen *must be* less or equal to 64, but the number of tiles in the global map is unlimited.

Pratically, during scrolling, when a tile is unused, is replaced by a new tile that comes on screen because of the scroll.
In my example, because of the limited amount of tiles involved i also change colors, not only patterns.

There is a diadvantage:
When designing the map you must ensure that the number of different tiles never exceed 64.
For example if you use all 64 tiles at x=0 and for x=1 you have 3 tiles that become unused and 5 that became new, you end up with 64 - 3 + 5 =66 tiles. Not good. However this was (with dvik tiles) never happened.

64 are the 256 tiles available on msx1 divided by 4 (assuming 2 pixel smooth scroll) different tile versions, one for each 2 pixel scrolled tile.

the idea is simple: look at this nametable layout:
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
.....

say for example that the tilenumber of 'A' is 0
and tilenumber of 'B' is 1

when x = 0 you only have tiles 'A' and 'B' on screen, because 'C' is on immaginary column 33.
when you scroll one charather left, the entire column of 'A' disappears and the tile pattern for 'A' is changed to reflect the image of the pattern 'C'. Plus the nametable is also updated. The tilenumber of 'B' does not change between scrolls is always 1. Instead the tilenumber of 'A' is 0 and is overwritten by the pattern of 'C' when the scroll takes place.


Problems arise when you have, for example one disappearing tile and two new incoming tiles and you have already used all 64 tiles. You will end up with 65 but is not possible because 65*4=260, that is greater than 256.

Hope is clear now,

Sorry, i've forgot to mention this.

64 x bank, assuming 2px scroller, (256/4) or in your example that is 1px scroller (as you said) 256/8 = 32 x bank. (not considering the blank tile, for simplicity)
anyway if you want (and i find it) i can send you a small demo.