V9990 & tilemap scrolling

Hi, what is clear to me is the behaviour in gfx modes of the commands. it is almost identical of V9938.

But P1/P2 modes causes me a lot of confusion about x/y based commands.
I see two alternatives:
1) x/y commands continue to works as in v9938 bitmap modes. they see the screen regardless of nametable, only as an array of pixels from left to right and top to bottom. the nametable is a trasparent concept for those commands, but they WORK ON PIXELS DATA not on nametable data.
2) x/y commands works on nametable and NOT on pixels data so the screen space is 32 or 64 units per 26 units (or so).
they do NOT MOVE PIXELS DATA instead they move nametable bytes.

What is unclear to me is : (1) or (2) ?
Can anyone give me some explanation?

thx, i can confirm, (1) briefly looking at openMSX source code implementation. It uses template specialization to differentiate the command. but there is no difference in what is doing. Effectively it does manipulate the screen as an high level array of pixels colors.
Probably the best thing i can emulate what i need is to issue two commands:
byte move from x,y to linear
then
byte move from linear to x1, y1
thxs

From the manual:
http://msxbanzai.tni.nl/v9990/manual.html

Physical mapping: Addresses 00000-3FFFF in VRAM0 and 40000-7FFFF in VRAM1. P1.
00000-3FDFF (Sprite) Pattern Data (Layer A)
3FE00-3FFFF Sprite Attribute Table
40000-7BFFF Pattern Data (Layer B)
7C000-7DFFF PNT(A) - Pattern Name Table (Layer A)
7E000-7FFFF PNT(B) - Pattern Name Table (Layer B)
Pattern Data is layed out like a 4bpp bitmap with 256 pixel width, cut up in 8x8 patterns. Pattern 0 1st line starts at 00000, Pattern 0 2nd line starts at 00080 etc., Pattern 1 1st line starts at 00004 etc., Pattern 32 1st line starts at 00400 etc.
Sprite Pattern Data is shared with background Pattern Data, but 16x16 Patterns are used.
The Name Table describes the entire Image Space, each Pattern is specified by a 16 bit value.

The difficulty of doing what you want is that really the patterns are 8x8 pixels, taken alternatively.

In P1 mode the name table is 64 tiles wide = 128 bytes and bit map vram layout is based on 256 dots hence 128 bytes.

The Y coordinate start at 7*256 + 128 for PNT_A and 7*256 + 192 for PNT_B

For let say screen size 32x24 tiles tile scrolling by using copy, it would need to be set up like:

COPY (SX, SY)-(NX, NY) TO (DX, DY)
(note that SX has high and low part denoted as SXH:SXL below)

scrolling horizontal: COPY (2:4,7:128)-(31*4,24) to (2:0,7:128)
move all tiles 1 tile to the left
Source (SX,SY)
R#32 = 1*4 (offset 1 tile in x, since 16 bit = 4 dots)
R#33 = 2 (must be 2 to because name table in bank B)
R#34 = 128
R#35 = 7
Destination (DX,DY)
R#36 = 0
R#37 = 2 (must be 2 to because name table in bank B)
R#38 = 128
R#39 = 7
Size (NX, NY)
R#40 = 24
R#41 = 0
R#42 = 31*4
R#43 = 0

R#44 = 0
R#45 = 12 (pset)
R#46 = 0 (prohibit writing to bank A)
R#47 = 255 (allow writing to bank B)

scrolling vertical: COPY (2:0,7:128+1)-(32*4,23) to (2:0,7:128)
move all tiles 1 tile up
Source (SX,SY)
R#32 = 0
R#33 = 2 (must be 2 to because name table in bank B)
R#34 = 128+1 (offset 1 tile in y, since 1 line is 1 row)
R#35 = 7
Destination (DX,DY)
R#36 = 0
R#37 = 2 (must be 2 to because name table in bank B)
R#38 = 128
R#39 = 7
Size (NX, NY)
R#40 = 23
R#41 = 0
R#42 = 32*4
R#43 = 0

R#44 = 0 (direction +x +y)
R#45 = 12 (pset)
R#46 = 0 (prohibit writing to bank A)
R#47 = 255 (allow writing to bank B)

For P2 the name table is 128 tiles wide = 256 bytes and bit map vram layout is based on 512 dots hence also 256 bytes.
Therefore I suspect it should be possible and work in a similar way as for P1, but have not tested this.

Now, I suspect for vertical scrolling above example will work. For the horizontal scroll it may not. This because of some pipeline feature in the cmd engine of the v9990, as discussed in some other topic on this forum...
But if you can avoid overlap, by means of double buffering, it should be OK.

Ahhh GhostwriterP, good point! I hadn’t considered that the name table is 2 screens wide!

That’s pretty cool , that it adds up conveniently after all.