openMSX "sprite rivelator"

ページ 2/3
1 | | 3

If there were some quirk, the rendering would also be wrong...

I did add the 4 patterns in the corners of 16x16 sprites, it looks nice, I think. I now also implemented the EC bit.
Should I also do something with the color?

Anyway, the SAT calculation for MSX2 modes is the biggest problem now.

that's fine. i've done a post for screen 4 (as you see hoping some one could give some help.)
I do not think that color informations are so useful. It's already nice you considered the EC bit.
(sprite mode 2 has the EC bit at "scanline" level did you took into account this? [i consider a-not-so-important thing, i will already be happy with at least the y,x corner of each sprite on screen showed as a single pixel, the square box is already luxury to me] ) ;-)

about the address calculation i really do not know where the quirk is:
the sat address value is described by the A7 to A16 bits of a 17 bit address in vram those are in registers 5 and 11. So to get the base address of SAT what we need to do is multiplying the combined values of r5+r11 by 2^7, 128. this should give us the address of Y coordinate byte of plane 0 in SAT. the SCT is placed 512 bytes "before".
But it does not work....

Wiki says:

In SCREEN 4 to 6, the S7-S8 bits are ignored and S9 must be always set. So the address is obtained by the formula ((Register 5 value) - 3) x 80h.

In SCREEN 7, 8, 10 to 12, S7-S14 are used with S15-S16 of the VDP register 11. These 10 bits code the address of the start of the attribute table of Sprites as on MSX1 (see above). The address can vary between 0 and 1FF80h. Please note, S7 and S8 are ignored and S9 must always be 1.

What does it mean that some bits must be ignored? Should we assume them to be 1? Is that formular for screen 4-6 correct?
What would the formula be for 7-12? Why is it speaking about 10 bits, although S7-S16 are only 9 bits?

No bits are ignored, the ones that the application manual says must be 1 form an AND mask on the address, so if one of those bits is set to 0 the table will mirror in some shape or form.

So, how does one calculate the SAT base address for MSX2 modes?

I'm sorry, but I don't understand what your table means exactly...

Rather than taking the base address, for a good implementation which is able to deal with mirroring you’ll want to apply the AND mask between the table address and registers as shown here:

Grauw wrote:

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
```

In other words, something like this for the SCT lookup (untested but shows the idea hopefully):

```vpeek [expr (0x1FC00 | \$sct_offset) & ([vdp_reg 11] << 15 | [vdp_reg 5] << 7 | 127)]
```

And this for the SAT lookup (untested but shows the idea hopefully):

```vpeek [expr (0x1FE00 | \$sat_offset) & ([vdp_reg 11] << 15 | [vdp_reg 5] << 7 | 127)]
```

(But if you want a base address calculation then for most normal sprite usage A16-A10 should be the Sprite Colour Table base address and A16-A10 OR 0x200 should be the Sprite Attribute Table base address.)

I still don't understand how the A16-A10 map on r5/r11...

I think you mean:
` set base_addr [expr {((\$r11 << 15) + (\$r5 << 7)) | 0x200}]`
right? But still that doesn't seem to work.

OK, manuel, last version of the msx basic code: verified and working

```10 S\$=string\$(32,255)
20 FOR T%=1 TO 8
30 SCREEN T%,2,0: COLOR 15,1,1: CLS
40 SPRITE\$(1)= S\$
50 PUT SPRITE 2, (35, 18), 14, 1
60 REM IF T% = 1 THEN 100
70 IF T%<=3 THEN A!=VDP(5) AND 127 ELSE A!= (VDP(5) AND 252 OR 4)+256*VDP(12)
75 A!  = A! *128
80 IF T%=1 THEN PRINT A! ELSE OPEN "GRP:"AS #1:PRINT #1,A!;" - Y="; VPEEK(A!+8); " -X="; VPEEK(A!+9):CLOSE#1
90 T\$=INPUT\$(1)
100 NEXT T%
110 END

```

take a look at lines 70-75, T% is the screen mode.

After reading in depth the wiki i figured out that the vdp, because of color sprite table being 512 bytes long is "forced" to think as a whole block of 128bytes+512bytes=768 bytes that would be rounded up to 1K.
this means that the msx1 granularity of 128 bytes in address placement should now became a 1024 granularity.
In terms of bit this is done by considering the lower 3 bits of r5 as if they always were in this configuration "100", that's the reason of AND 252 (which means : reset lower bits, 0-1 of r5 ), followed by or 4 (meaning: set bit 2 of r5) to achieve the "100".

my implementation does not take in account the fact, ( to be verified ) that in screen modes 4-5-6 YOU CANNOT PLACE the SAT on the upper 64K. this should not be a problem.
really to me this does appear as another stupid VDP limitation. What in the hell the VDP should not use the higher bits in screen 4-5-6 preventing me to set SAT location on higher 64K if i need on a 128K machine?
Another stupid limit IMHO

Manuel wrote:

I still don't understand how the A16-A10 map on r5/r11...

I think you mean:
` set base_addr [expr {((\$r11 << 15) + (\$r5 << 7)) | 0x200}]`
right? But still that doesn't seem to work.

That’s probably because you include bits A9-A7 in this calculation. Add `& 0x1FC00` before the `| 0x200` to clear those bits.

ページ 2/3
1 | | 3