V9990 & tilemap scrolling

Prophet (3586)

02-07-2019, 14:04

Hi, i'm not an expert in V9990 cmd engine. I'm wondering if it is easy to move the nametable in P1/P2 on a charater basis using VDP commands. What i need is something like:
COPY (XST_CH, YST_CH)-(XEND_CH, YEND_CH) TO (XDST_CH, Y_DST_CH)
where
XST_CH & YST_CH are the source top left coordinates (in charaters not pixels!)
XEND_CH & YEND_CH are the source bottom right coordinates (in charaters not pixels!)

XDST_CH & Y_DST_CH are the destination coordinates (in charaters not pixels!)

Basically a rectangle move applied on nametable.

How can accomplish this using v9990? (I know, v9990 had scroll registers but i cannot use them for my purposes)

By Grauw

Ascended (9486)

02-07-2019, 14:40

The manual says in P1 the bit map configuration is based on 256 dots in the X direction, so I think the command engine there works similar to the V9958 in pattern modes.

This would mean you can use BMLL command for full screen shifts of the character table (like a VDP LDIR / LDDR), but I don’t think it’s possible to do this within certain x/y character coordinate bounds. (On the other hand, you can use the x/y bounded commands for tile updates/animations.)

By PingPong

Prophet (3586)

02-07-2019, 15:36

Grauw wrote:

The manual says in P1 the bit map configuration is based on 256 dots in the X direction, so I think the command engine there works similar to the V9958 in pattern modes.

Quote:

(On the other hand, you can use the x/y bounded commands for tile updates/animations.)

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?

By Grauw

Ascended (9486)

02-07-2019, 16:52

I think it is 1), just like on the V9958. I’m thinking so because the tile data is also oriented as screen 5 bitmap data (rather than 128 sequential bytes), so it would make sense if the commands also operate based on this bit map configuration. I can’t say for sure though since I glossed over the application manual and didn’t see this case noted explicitly, so I think it’s left implicit from that sentence about the bit map configuration in section 10.1.12. It for sure doesn’t change behaviour based on the VRAM area accessed.

In the end the difference between 1) and 2) is just what the command uses as the screen width / stride unit, and I expect it is 256 / 512 and not 32 / 64. This difference means it is either made easy to manipulate name table data, or to manipulate pattern table data. Since copy commands are most useful for bulk data manipulation, it would be more useful for it to work on pattern data. Updating the name table is fairly light on the CPU already + there is a scroll register, it is also generally more random-access, and can of course still be manipulated with the BM**-commands.

But it is of course easiest to just try it out yourself to confirm :).

By PingPong

Prophet (3586)

02-07-2019, 16:55

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

By GhostwriterP

Hero (556)

02-07-2019, 17:24

well, xy to linear and visa versa are two commands that do not work properly in P1, at least I never managed to . regular copy (LMMM) just works fine, just put the coordinates correctly (i.e. 2 bytes / 4 pixels aligned - since name table is 16 bit per tile). Although, there is some emulation issue in openMSX that it does not always update the name table when using command engine, guess some emulation code optimization implemented? But on real thing it works OK.

No experience with P2, that is something you need to test yourself (on real hardware, do not trust openMSX just yet )

By Manel46

Hero (602)

02-07-2019, 18:10

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.

By PingPong

Prophet (3586)

02-07-2019, 18:22

Quote:

regular copy (LMMM) just works fine, just put the coordinates correctly (i.e. 2 bytes / 4 pixels aligned - since name table is 16 bit per tile).

But they work on a different x screen width so i think cannot work on nametable scrolling
Or i'm wrong?
can you make an example on how to setup the command registers based on my requirement in the first message?
I cannot figure how to setup registers.

By GhostwriterP

Hero (556)

02-07-2019, 20:42

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.

By GhostwriterP

Hero (556)

02-07-2019, 22:12

whoops, messed up reg 40 and 42, these values should be swapped .

By Grauw

Ascended (9486)

02-07-2019, 23:31

GhostwriterP wrote:

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.

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.