LDIRVM weirdness?

Master (172)

02-01-2022, 04:48

I am writing about SCREEN4 and experimenting with different VDP registers (changing tables addresses to be exact). To draw some comparisons with SCREEN4 I am trying to make SCREEN2 use this configuration on the MSX2:

Pattern name table = 0x3800 (R#2 = 0xE)
Colour table = 0x0000 (R#3 = 0x7F, R#10 = 0x0)
Pattern generator table = 0x2000 (R#4 = 0x7)
Sprite attribute table = 0x3c00 (R#5 = 0x78, R#11 = 0x0)
Sprite pattern generator table = 0x4000 (R#6 = 0x8)

It almost works, but for some weird reason I can't write sprite patterns at 0x4000 and beyond. I am trying to use LDIRVM BIOS call (0x5c) to put sprite patterns in there, but the BIOS call writes at 0x2000 instead, messing up the pattern table. Is there an alternative to LDIRVM? Meanwhile, all VRAM after 0x4000 is set to 85, which display all sprites as vertical lines. Is LDIRVM somehow limited to the 0-0x3FFF range on SCREEN2 for some reason, even though I am running the code on the MSX2 with lots of VRAM? (Well, not really, it's just OpenMSX...)

!login ou Inscrivez-vous pour poster

Par PingPong

Enlighted (4156)

02-01-2022, 09:42

not so sure, but if i'm not wrong there are behaviours in screen 2 here for compatibility reasons.
For example, (not sure, maybe i'm wrong), the autoincrement feature of the VDP Data Port has a wrap around on 16Kb, so if you reach the "end" of 16K the next bytes goes to 0x0000 (wrap around 0-16365 addresses).

Plus when writing outside the first 16K bank an additional register should be set telling the vdp the most 3 significant bits of the full 17 bit vram address (=> 2^17 = 128K VRam).

i think the bios routine you are calling is the one designed for msx1. There is an analog routine for msx2 requiring to supply an address to use the more wider vram address range.
Look here:
https://konamiman.github.io/MSX2-Technical-Handbook/md/Appen...
and search for LDIRMV (0059H)

Par ARTRAG

Enlighted (6980)

02-01-2022, 10:15

Maybe the simplest thing to do is to follow the disassembled code
But I suspect it is limiting to 14 bit the addresses for msx1 compatibility

Par santiontanon

Paragon (1832)

02-01-2022, 12:54

I might be wrong here, but I think the MSX1 BIOS routines (LDIRVM, SETWRT, etc.) do not guarantee working beyond the first 16KB of VRAM. I am not an expert in MSX2 coding, but in the few tests I have done, I had to use "NSTWRT", which is the equivalent of "SETWRT" but with an extended address range. Otherwise, it did not work for me either.

Par Arjan

Paladin (787)

02-01-2022, 13:22

In MSX1 screen modes, LDIRVM uses the SETWRT routine to set the VRAM address, which is limited to 14 bits. In MSX2(+) screen modes it uses NSTWRT.

Par zeilemaker54

Champion (355)

02-01-2022, 19:03

LDIRMV (and LDIRVM) defaults to MSX1 behavior in screen modes 0-4. This means that the VRAM address is truncated to a 16 KB VRAM address. You can override this behavior by setting bit 3 of MODE (0FAFCH). In this case 64 KB VRAM addresses are accepted. Note also that ACPAGE (0FAF6H) can not be used in screen modes 0-4

Par PingPong

Enlighted (4156)

02-01-2022, 22:32

as said by others, my suspects were right. see this https://konamiman.github.io/MSX2-Technical-Handbook/md/Appen...
there are bios calls that work with the full 17 bit range. even a new version of the BIOS calls you are using.

Par pizzapower

Master (172)

03-01-2022, 19:59

PingPong wrote:

Which ones? NSETRD, NSTWRT, NRDVRM and NWRVRM use HL, which is 16bit, to put data in VRAM address. To access full VRAM we need 17bit addressing.

Par pizzapower

Master (172)

04-01-2022, 00:08

This page actually explains how to access 17-bit address in VRAM: https://www.msx.org/wiki/VDP_Access_Registers