Question about v9990 coding

Supporter (3)

18-02-2023, 23:18

Hi I have a few questions for the v9990 experts if they could help. As some people know I'm coding the engine for the v9990 version of quigs... you might have seen the Micromachine's demo Edo and I are doing.
Currently this uses a purely software strip draw for the scroll. I use P1 Mode and have metatile system made up of 4x4 patterns, each takeing 32 bytes for the pattern data & another 16 bytes all stored in VRAM at #60000, so I get effectively 1200 metatiles in the 64 from #60000.
At the moment I'm copying the 32bytes of a metatile pattern data into CPU ram and then copying it onto one of the pattern name tables.... which obviously takes a lot of time. So I was thinking to use BMXL... Copying the 32 linear bytes (rather than copying pixels but pattern numbers) stored at a position in #60000-6ffff directly into a position on the pattern name table as a rectangle of 8 bytes wide (4 patterns) and 4 high. This is doing a corrupt screen without breaking openmsx, so maybe its my code, or openmsx or msx doesnt work with BMXL???? Its is just copying bytes after all.

Any v9990 coders better than I who can help???? Plz

.Quig_g9k_Command_BMXL:
		ld 		a,#32
        ld 		bc,CG9K_REG_SELECT
        out 	(c),a
        ld 		hl,Quig_g9k_CommandBmxlList
        ;call 	vdpwait
        ld 		bc,CG9K_REG_DATA
		;Do 21 Times
		inc 	b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi
        inc 	b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi
        inc 	b:outi:inc b:outi:inc b:outi:inc b:outi:inc b:outi	
	
		ret
.Quig_g9k_CommandBmxlList:
.Quig_BMXL_32:db		#e0				;SA bits 0-7
.Quig_BMXL_33:db		0				;SA NA
.Quig_BMXL_34:db		#1				;SA bits 8-15
.Quig_BMXL_35:db		#6				;SA bits 16-18
.Quig_BMXL_36:db		0				;DX bits 0-7
.Quig_BMXL_37:db		0				;DX bits 8-10
.Quig_BMXL_38:db		#80				;DY bits 0-7
.Quig_BMXL_39:db		#f				;DY bits 8-11
.Quig_BMXL_40:db		#8				;NX bits 0-7
.Quig_BMXL_41:db		#0				;NX bits 8-10
.Quig_BMXL_42:db		#4				;NY bits 0-7
.Quig_BMXL_43:db		#0				;NY bits 8-11
.Quig_BMXL_44:db		12				;DIVX DIVY
.Quig_BMXL_45:db		12				;Logical Operation
.Quig_BMXL_46:db		0				;Write Mask bits 0-7
.Quig_BMXL_47:db		255				;Write Mask bits 8-15
.Quig_BMXL_48:db		0				;
.Quig_BMXL_49:db		0				;
.Quig_BMXL_50:db		0				;
.Quig_BMXL_51:db		0				;
.Quig_BMXL_52:db		g9k_OPCODE_BMXL	;BMXL Command

By Trebmint61

Supporter (3)

18-02-2023, 23:45

Oh I'm aware that Quig_BMXL_40 should be #10 as its 16 pixels (or 4 words) to draw. Thanks

By pizzapower

Master (165)

19-02-2023, 06:56

Check this thread: https://www.msx.org/forum/msx-talk/general-discussion/v9990-...

In P1 mode, all coordinate-based VDP commands copies data into the pattern table only. And BMXL and BMLX won't work properly.

By assembler

Champion (414)

19-02-2023, 10:10

Hi!

I use LMMC command to write lines in PNT

Each line in PNT is 64 tiles wide and each tile uses 2 bytes, so each line means 128 bytes, the same as each line of patterns in PGT.

To write a vertical line of tiles for an horizontal scroll, you use the following parameters for the command:
R#36: X coordinate (each tile need 4 "pixels", 2 bytes). The first column of non visible tiles at the right of the screen is the pixel 128
R#37: To write in the VRAM for plane B, you must add 512 to the X coordinate, so this value is 00000010b
R#38, R#39: The VRAM where PNT is stored, in means of pixels, is at 1920 (1920*128=0x3c000+0x40000=0x7c000). You must mask the coordinate to avoid writing outside of the corresponding plane PNT.
r#40, R#41: 4, the number of "pixels" for each tile
r#42, R#43: the number of tiles to draw
R#44: 0
R#45: 0x0c
R#46: 0
R#47: 0xff

Command: LMMC

Then you only need to write to P#2 the tile info for the column.

The same idea can be used to write horizontal lines for vertical scroll.

By GhostwriterP

Paladin (683)

19-02-2023, 10:16

for BMXL use it requires a little more ingenuity due to interleaved VRAM see forum post and post

By assembler

Champion (414)

19-02-2023, 11:11

For horizontal lines, you can define a command that exceed the X limit: The command will start writing at the same Y, and X=0 when the pointer reach the tile number 64-> the tile 0

For multidirectional scroll, you must calculate if the command need to be splitted, one for the lower half and other for the upper half to avoid writing outside the corresponding PNT

By pizzapower

Master (165)

22-02-2023, 22:39

assembler wrote:

Hi!

I use LMMC command to write lines in PNT

Each line in PNT is 64 tiles wide and each tile uses 2 bytes, so each line means 128 bytes, the same as each line of patterns in PGT.

Command: LMMC

Then you only need to write to P#2 the tile info for the column.

The same idea can be used to write horizontal lines for vertical scroll.

Have you tried that on OpenMSX? I tried LMMV (rect fill) but it doesn't seem to work.

By assembler

Champion (414)

23-02-2023, 22:33

Ghost and Goblins uses that method, and yes, it works fine using LMMC in OpenMSX.

LMMV can be used to clear the PNT, as only R#46 is used to write "pixels" in 4bpp. You cannot draw a rectangle using 2 different bytes.

Remember to set R#37 to 0x02. To write in the second half of the VRAM, DX must be displaced 512px
R#46 must be 0 and R#47 must be 0xff

By pizzapower

Master (165)

24-02-2023, 16:33

assembler wrote:

LMMV can be used to clear the PNT, as only R#46 is used to write "pixels" in 4bpp. You cannot draw a rectangle using 2 different bytes.

So in case of LMMV, I must use R#46 instead of R#47? Why? If I use R#46, I need to write to layer A, so I assume it uses different DX/DY coordinates than those you used in the LMMC example? (DX=0 and DY=3961 I guess? 2040 lines in layer A + 1kb unused space between layer A and layer B + 1920 lines in layer B)

Do you know if it is possible to use LMMM to copy from VRAM to VRAM from PGT to PNT region?

By assembler

Champion (414)

24-02-2023, 22:13

assembler wrote:

LMMV can be used to clear the PNT, as only R#46 is used to write "pixels" in 4bpp. You cannot draw a rectangle using 2 different bytes.

This is not correct: I should had written "only R#48 is used to write pixels"

By assembler

Champion (414)

24-02-2023, 22:27

In P1 mode, from the point of view of commands, there are two big bitmaps of 256x2048 pixels.

The last 128 lines of the second half are the PNT (1920-2047). If you translate those pixels to VRAM address, you have 1920*128=0x3c000, and those are in the second half, so 0x3c000+0x40000= 0x7c000. This is the start address of the PNT

The first line of tiles of layer B is at Y coord 1984.

For the command to write in the second half of VRAM, you must add 512 to X coord.
You can copy from one half to the other. Just set the X of the command taking into account that: +0 for the A layer (first half) and +512 for the B layer (second half)