Sprite Attribute Table bits 7&8 in Sprite Mode 2

Par aoineko

Master (129)

Portrait de aoineko

17-01-2021, 18:45

Hi,
In Sprite Mode 2, it is requested to set bits 7~9 to 1 in the VDP register R#5 which manages the location of the Sprite Attribute Table (SAT) in VRAM.
From what I have read (and according to the OpenMSX debugger), in fact, only bit-9 really counts in the calculation of the SAT address.
Changing bits 7 & 8 does not change the SAT address, but changes the colors displayed on the sprites.
Could someone tell me the exact role of these two bits?
I didn't find anything in the V9938 documentation.

!login ou Inscrivez-vous pour poster

Par Sandy Brand

Master (225)

Portrait de Sandy Brand

17-01-2021, 19:19

The V9938 Programmers Guide (revised) doesn't give much more info, but at least seems to confirm what you found:

Bits A7 and A8 are marked with X, which probably means they don't do anything.
Bit A9 is show to be set as 1, so that would probably have some affect on where the SAT will be located when the bit is set to 0.

Par Grauw

Ascended (9687)

Portrait de Grauw

17-01-2021, 19:45

On the V99x8, bits of table base addresses which are required to be set to 1 perform an AND operation on the table look-ups. Setting them to 0 forces those address bits to be always zero causing the table look-ups by the VDP to mirror. The most obvious use for this is in screen 4, to reduce the four pattern tables down to a single one (r#4 bits A11 and A12).

For the SAT base register, if you set bit A7 and A8 to 0 it does not affect the attribute table lookups, since it is 128 bytes and only uses A0-A6. But if you set bit A9 to 0 it moves the table down by 512 bytes to be in the same location as the colour table. That is why it must be set to 1.

The sprite colour table which uses the same base register is 512 bytes, and thus makes use of A0-A8. Setting A7 and A8 to 0 forces bits 7 and 8 of the lookup address to be 0, meaning the colours of sprites 0-7 are mirrored to (shared with) sprites 8-15, 16-23 and 24-31. Setting A9 has no effect since for the sprite colour table it is already always 0.

Par Sandy Brand

Master (225)

Portrait de Sandy Brand

17-01-2021, 19:58

Ah yes, internally the VDP does -512 by just 'setting bit A9 to 0', so I guess that would mean the SAT and sprite color tables would just end up at the same location in VRAM if you don't set bit A9 to 1 yourself?

I didn't know about the sprite color mirroring. Probably not very useful outside of maybe demo programming, but still cool to know Smile

Par Grauw

Ascended (9687)

Portrait de Grauw

17-01-2021, 20:36

A maybe clarifying illustration;

Sprite attribute table (mode 2):

Internal:    1   1   1   1   1   1   1   1   0   0  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#5 r#11:  A16 A15 A14 A13 A12 A11 A10  A9  A8  A7   1   1   1   1   1   1   1

Sprite colour table (mode 2):

Internal:    1   1   1   1   1   1   1   0  a8  a7  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#5 r#11:  A16 A15 A14 A13 A12 A11 A10  A9  A8  A7   1   1   1   1   1   1   1

Screen 2/4 pattern generator table:

Internal:    1   1   1   1 a12 a11 a10  a9  a8  a7  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#4:       A16 A15 A14 A13 A12 A11   1   1   1   1   1   1   1   1   1   1   1

Screen 2/4 colour table:

Internal:    1   1   1   1 a12 a11 a10  a9  a8  a7  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#3 r#10:  A16 A15 A14 A13 A12 A11 A10  A9  A8  A7  A6  A5   1   1   1   1   1

Screen 5/6 pattern name table:

Internal:    1   1 a14 a13 a12 a11 a10  a9  a8  a7  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#2:       A16 A15 A14 A13 A12 A11 A10   1   1   1   1   1   1   1   1   1   1

Screen 7/8 pattern name table (note r#2 is shifted):

Internal:    1 a15 a14 a13 a12 a11 a10  a9  a8  a7  a6  a5  a4  a3  a2  a1  a0
             &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &
r#2:       A16 A15 A14 A13 A12 A11   1   1   1   1   1   1   1   1   1   1   1

Par aoineko

Master (129)

Portrait de aoineko

17-01-2021, 20:21

Thank you for the info.
I wondered if those bits could be of any use.
It's not easy to see a situation where they could be usefull.
Perhaps if you want to often change sprites colors it could make sense to use a smallest color table.
Or we can leave these bits at 1 and deal with it. ^^

Par Grauw

Ascended (9687)

Portrait de Grauw

17-01-2021, 20:37

Indeed, I can imagine a situation where it is useful to reduce VRAM bandwidth for updating the sprite colour table. If you have set up the sprites so that sprites 0-7, 8-15, 16-23 and 24-31 use the same 8 colour settings, you only need to write 128 bytes instead of 512 to update all the sprite colours.

However, that’s quite a specific situation.

Par aoineko

Master (129)

Portrait de aoineko

18-01-2021, 09:22

Grauw wrote:

A maybe clarifying illustration;

Very clarifying Smile
Thanks
Perhaps you could add it to MSX Assembly site and/or on the MRC wiki

Par Metalion

Paragon (1343)

Portrait de Metalion

18-01-2021, 13:14

Grauw wrote:

A maybe clarifying illustration

Splendid, Grauw.
Thank you.