Writing / Reading VRAM - noob questions

Prophet (3659)

13-12-2021, 16:49

siudym wrote:

I have no intention of bypassing the BIOS. I just wanted to know how to perform a given operation without it

There's a lot of confusion on this subject. Please note that the standard allows direct access to the VDP. There's no problem to "bypass" the BIOS in this case.

The only requirement is that the I/O port isn't hardcoded to 98h~9Bh. You must obtain the VDP read and write I/O ports from the VDP.DR and VDP.DW BIOS values, respectively. After that, you can mangle the VDP to your heart's content.

Sadly, a lot of VDP programming tutorials skip that important information and the correct way to code this, hence the misunderstanding persists.

Par siudym

Resident (39)

13-12-2021, 17:06

Is it possible to set the background in black and the border in blue? If I set the background to black, changing the border color does not change anything and the border is also black.

As for the position of the sprites on the screen - I guess the reason for the uneven positions on the 256x192px screen horizontally is the fact that it is actually 320pix?

Par ARTRAG

Enlighted (6935)

13-12-2021, 18:45

siudym wrote:

The update satbuffer code works.

I would like to change the BACKGROUND color to black, but I have no idea how it works?

CHGCLR (0062H) *1
Function: changes the screen colour
Input:
A for the mode
FORCLR (F3E9H) for foreground color
BAKCLR (F3EAH) for background color
BDRCLR (F3EBH) for border colour
Output: none
Registers: all

ld a,colvalue?
call 0062H

What is "F3EBH"? Do I need to write value in this address?

I noticed that the sprite screen position starts with X. $ 20 on the left edge of the screen. The maximum value to the right is FF and it does not reach the right edge of the screen (mode0 / screen 1)
From what I can see the XY coordinates are 8 bits so I wonder how to set the sprite on the right edge of the screen?

The way the background colour changes depends on the vdp mode. Look at the TMS9918 documents to see how its works.
The border colour, instead, will change immediately in any mode as it depends on the VDP register n. 7.

All sprites can be displaced on the X axis of 32 pixels setting the s.c. early bit clock that you find in the colour filed of the SAT. In this way they can move under the left border. Again at the TMS9918 documents to see how its works.
http://map.grauw.nl/resources/video/ti-vdp-programmers-guide...

You can also read it from here, look for MODE 1 sprites (v9938 is back compatible with the msx1 VDP)
http://www.ccas.ru/brychkov/MSX/V9938_programmers_guide.pdf

Par Grauw

Ascended (10768)

13-12-2021, 20:51

siudym wrote:

As for the position of the sprites on the screen - I guess the reason for the uneven positions on the 256x192px screen horizontally is the fact that it is actually 320pix?

No, the screen width on MSX is 256 pixels horizontally, not 320. The dot clock of MSX is different from e.g. the C64 or CGA, so it has a different horizontal resolution.

As ARTRAG said, it seems like you have the “early clock” (EC) bit set in the sprite attribute table. This bit should normally be left off unless you want to move the sprite partially into the left border. Early clock is a way to specify x-positions less than 0 (it subtracts 32 from the x-position).

Par ARTRAG

Enlighted (6935)

13-12-2021, 21:12

sd_snatcher wrote:

siudym wrote:

I have no intention of bypassing the BIOS. I just wanted to know how to perform a given operation without it

Sadly, a lot of VDP programming tutorials skip that important information and the correct way to code this, hence the misunderstanding persists.

Actually if you code msx1 programs, there is no real reason to not use 98h and 99h. All existing devices have a vdp at those ports.
The sole existing item using different ports is a cart to expand msx1 machines to msx2: it is an expansion cartridge used on msx1 machines, which in turn have a vdp at ports 98h and 99h.
Moreover, ports 98h and 99h have become standard in msxTR specifications.
So, in the end, for msx1 programs, there is not a single computer in the history of the standard (past and future) that will not accept vdp commands on those ports.
But some people on this forum has a philosophical/religious attitude toward this kind of things, so, it is up to you to decide if use port 98h/99h or waste (CPU) time with onanistic reasoning about compatibility with the next machines that Panasonic or Phillips will release from their Afterlife using different ports.
Sorry for being very direct, but this is the matter of the fact.

Par siudym

Resident (39)

13-12-2021, 22:39

Thanks. Everything is fine now I clear bit7 Attribute Table Sprite and now everything is fine on the screen (I didn't notice a, I had FF written in the fourth byte of Sprite.)

Which emulator can view the WRAM content in MSX?

Par siudym

Resident (39)

14-12-2021, 00:45

What else do need to do switch the sprite size to 16x16? (screen 1 mode)

REG1SAV: equ 0F3E0h

LD A,% 00000010
LD (REG1SAV), A

Does not change size.

According to information that I have read, MSX1 has a limit: "maximum of four sprites per horizontal line of pixels on screen."

Are 16x16 sprites counted as "FOUR" 16x16 sprites in the case of the size, or does the limit take into account 4x 8x8 sprites on the X axis? (max two spite 16x16 per scanline).

Par ToriHino

Paladin (857)

14-12-2021, 00:51

Writing to memory location REG1SAV does not do anything with the VDP (remember that on MSX the VDP is not memory mapped but only accessible through the ports as mentioned above). REG1SAV is normally used as a backup of VDP register 1 when writing to the VDP through the BIOS.

To really activate 16x16 sprite mode on the VDP you can do something like:

  ld   c,$01             ; Register in C
  ld   a,(REG1SAV)
  or   %00000010
  ld   b,a               ; Data in B
  call WRTVDP

Or, when not using the BIOS, a direct OUT to the VDP port (but take into account the other bits of VDP register 1 as well, since all will be overwritten).

Par thegeps

Paragon (1189)

14-12-2021, 01:05

Limit is 4 sprites. No matter if 8x8, 16x16, magnified or not
Writing on reg1sav you are modifying only the RAM backup reg value. Write on reg1 directly using WRTVDP (47h)
Destination reg in C, data to write in B
Don't forget to mask the bits you don't want to change

Par thegeps

Paragon (1189)

14-12-2021, 01:07

Oh, ToriHino was faster than me XD