Sprite color table SCREEN5

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).

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.

Sorry, but 2 years later, I'm still confused ...

OK, the sprite attribute and color table address should be considered as a 1024 byte block, with attributes occupying the upper 512 bytes. With that in mind, 6C00h for colors and 6E00h for attributes should be correct addresses, right ?

Well, it does not work.
Garbage on screen.

	     -----------------------------------------
(*)  R#5     | A14| A13| A12| A11| A10| 1  | 1	| 1  |
	     -----------------------------------------
	     -----------------------------------------
     R#11    | 0  | 0  | 0  | 0  | 0  | 0  | A16| A15|
	     -----------------------------------------

We know that A9 is significant and used in the calculation of the address, but not A8 or A7, even if they're set to 1. Therefore, the formula to calculate valid addresses are :

SPAT = number x 1024 + 512
SCOL = SPAT - 512

And after that, I calculate the register values :

byte	low (SPAT/128) or 111b	; R#05 | sprite attribute table (low)
byte	high (SPAT/128)		; R#11 | sprite attribute table (high)	

SPAT @ 6E00h gives $DF for R#5.
Correct ?

Can someone help me to get it to work ??

void	Set_SAT(uint8 SAT_Page) 	__z88dk_fastcall __naked
{
 SAT_Page;
__asm
	ld	a,	l
	rlc	a
	rl	h
	rlc	a
	rl	h
	rlc	a
	rl	h
	
	or	#7
	ld	l,	a
GetSATReady:
	in	a,	(VDP)
	and	VDP_CE
	jr	NZ,	GetSATReady            

	ld	a,	l
	out	(VDP),	a
	ld	a,	#0x80+5
	out	(VDP),	a

	ld	a,	h
	out	(VDP),	a
	ld	a,	#0x80+11
	out	(VDP),	a
__endasm;
	Table.SAT=((long)SAT_Page*1024)|((long)512);
	Table.SCT=Table.SAT-(long)512;
__asm
	ret
__endasm;
}

BTW: 3 LSB is significant too on MSX2. For example you able masking sprite colors by groups 8, 16, 32 different color masks

I don't know what I'm doing wrong ... I can set up a sprite table anywhere above 10000h, and have things working, but if it's an adress below that, the VDP puts itself in some fucked up mode that shows only garbage. I would understand absent sprites, or wrong patterns, but here, the whole screen is messed up.

Once again, my example is setting

. SPAT at 06C00h (27.1024)
. SCOL at 06E00h (27.1024+512)

This translates for the VDP in those values:

. R#05: DFh / 1101_1111b [per calculation: 6C00h/80h=DCh or 111b = DFh]
. R#11: 00h / 0000_0000b

I can confirm using BlueMSX that it is those values which are loaded in the registers. This is the garbage that I get on screen. Disabling the sprites through the debugger does not change anything. Furthermore, what's strange is that it seems that none of my transfer to VRAM have got through. It's just as if the VDP had "hanged" and freezed. See picture below.

EDIT : I just tested it on OpenMSX and it DOES work! It only shows a problem on the sprite patterns.