Sprite color table SCREEN5

Paladin (980)

12-12-2018, 21:27

Hi,

I have loaded in VRAM the attribute table and the color table for a given spriteset in SCREEN5. I know the SPAT is correctly positioned because when I change the X,Y value directly in the VRAM (BlueMSX debugger), the sprite moves.

The color table is 512 bytes before the SPAT, and therefore I have loaded my color values there. But ... nothing happens. All I get is the shape of the sprite, but with even lines white and odd lines blank. Even if I change the values directly in the VRAM, nothing happens ...

What am I missing here ?????

R#0 : xxxx100x
R#1 : xxx001xx
R#2 : 00011111

R#6 : $30 => patterns at $18000

R#5 : $C0
R#11 : $03 => attributes at $1E000 and therefore colors at $1DE00

By Grauw

Enlighted (7683)

12-12-2018, 22:43

Your problem is that you don’t set bits to 1 which must be:

Bits 0-2 of R#5 must be 1. See pages 40 and 93 of the V9938 application manual.

Bit 2 specifies A9 and must be 1, this means the attribute table must be at 1E200H and the colour table at 1E000H. Only steps of 400H are possible, and you can’t have them at the addresses you specified.

Bits 0-1 must also be 1.

(This is how the application manual describes it; another way of looking at it is that in sprite mode 2 the colour table and SAT are one unit of size 400H, with the SAT occupying the top half. Registers 5/11 specify the base address of this whole unit. As with all base addresses, bits lower than the table size must be set to 1 or it will mirror.)

By Metalion

Paladin (980)

13-12-2018, 16:15

Thanks for pointing me to the problem ... I did not know the first 3 bits of R#5 were always set at 1.
However,$1E000 is a perfectly valid address for the sprite attribute table.

SPAT address = R#11 x 1024 + R#5 >>3 x 1024

Therefore, $1E000 can be obtained by R#11 = 3 and R#5 = 24 << 3 OR 111b = 192 OR 111b = 199

So my calculation were correct except for the fact that the first three bit were to be set at 1. Having the first three bits at zero must have put the VDP in a defective mode, and that would explain why the SCOL table was not working while the SPAT was effective (X,Y position and patterns were working).

By Grauw

Enlighted (7683)

13-12-2018, 18:40

Since A9 must be 1, 1E000H is not a valid address. You will have some kind of mirroring I think, likely the SAT overlapping with the first 80H bytes of the SCT so the colours need to be specified at 1E000H as well. Pretty sure it was like this...

If you're not testing on a real MSX, make sure to at least test in openMSX as well...

By Metalion

Paladin (980)

13-12-2018, 19:17

I understand what you're saying, but it's not that clear in the manuals whether the A9 bit is significant in the address calculation or if it is set at 1 but masked. I just tried with R#11 = 199 and it's still not working ... No sprite at all, now.

If A9 is significant, then R#11 = 199 would put the SAT at $1E200 and the SCT at $1E000.
I'll try to do something there.

EDIT : it works ! ... So it means that A9 bit must be set at 1 but is indeed significant for the SAT address.

By wouter_

Champion (403)

13-12-2018, 20:20

This (internal) document in the openMSX source tree describes what happens when bits that should be '1' according to the V9938 application manual are nevertheless set to '0'. Like Grauw already said, there is indeed some kind of mirroring.