move sprite patterns to other address

Page 1/2
| 2

By inchl

Supporter (15)

inchl's picture

20-12-2019, 23:58

I am trying to move all sprite related tables (patterns, attribute, colors etc) to vram page 1 in screen 7. Sadly I doesn't work and it is driving me nuts. Somehow updating vdp registers 6, 10 and 11 to use bit16=1 does seem having any effect.
I wonder,... is it even possible?

Stephan

Login or register to post comments

By Manel46

Hero (554)

Manel46's picture

21-12-2019, 00:44

Yes you can. Do it like this:

;TABLAS SPRITES EN P1
;DIRECCIONES 0F000H+10000H,0FA00H+10000H. TABLA COLORES 1FA00H-512 AUTOMATICO
 LD C,5
 LD B,0F7H ;11110100B+11B ;ATRIBUTOS B14,13,12,11,10,9,8,7
 CALL 47h
 LD C,6
 LD B,00111110B ;PATRONES 0,0,B16,15,14,13,12,11
 CALL 47h
 LD C,11
 LD B,00000011B ;ATRIBUTOS 0,0,0,0,0,0,B16,15
 CALL 47h

By inchl

Supporter (15)

inchl's picture

21-12-2019, 12:36

Thanks,
Why is reg 5 filled with #F7 and not #F4 ?
#F7 will put the attribute table at #1FB80.... or am I wrong?

Stephan

By Grauw

Ascended (9055)

Grauw's picture

21-12-2019, 13:09

Check the V9938 manual, page 93 (pdf page 104). In sprite mode 2 bits 0-2 (A7-A9) must be set to 1, if you don’t the sprites will mirror. The SAT address is specified by A9-A16, the SCT by A10-A16. This masking of bits is also needed for some other V9938 registers (e.g. name table base), so be sure to pay attention to this in the manual.

The reason is that sprite mode 2 added the SCT, and its address is linked to the SAT, so they are really treated as one big 400H-byte table. Registers 5 and 11 specify the base address of this combined table (let’s call it “SACT”), with bits 0-2 (A7-A9) masked to 1 because of table size exceeds them. The SCT will be at +0H this “SACT” table addres, and the SAT at +200H. It may be easier to think of it this way.

By Manel46

Hero (554)

Manel46's picture

21-12-2019, 13:24

Yes. In the manual it is clear.

By inchl

Supporter (15)

inchl's picture

21-12-2019, 16:11

Thanks, that helped a little bit.
I guess my problem is somehow more complex than I described. I wanted to move the sprite tables to vrampage 1 because it seems some sprite artefacts appear on screen when disabling en enabling the sprites in mid screen -AND- doing vram page toggling at the same time. I wanted to enable the sprites only for those lines where a sprite-cursor is located.
I was trying this technique to make use of a faster vdp for copy-commands when sprites are disabled except on those screen areas were a sprite was required (the cursor).
The artifacts only appear when vram page 1 is displayed or when running in openMSX :-(

Anybody a suggestion?

Stephan

By Metalion

Paragon (1132)

Metalion's picture

21-12-2019, 16:58

Grauw wrote:

Check the V9938 manual, page 93 (pdf page 104). In sprite mode 2 bits 0-2 (A7-A9) must be set to 1, if you don’t the sprites will mirror. The SAT address is specified by A9-A16

And beware that A9, although it must be always set to 1, is indeed used in the address computation.
I did not know it, and It drove me nuts for a while in an old project.

By inchl

Supporter (15)

inchl's picture

21-12-2019, 17:24

So even if its set, it should be ignored for the calculation?

By Metalion

Paragon (1132)

Metalion's picture

21-12-2019, 18:26

No. You must always set A9 to 1, and it is used for the calculation.

By inchl

Supporter (15)

inchl's picture

21-12-2019, 18:35

Ok,... Stil does not solve my real problem.
What does switching vram pages have to do with sprite display?
Will post my progress in this q&a... I might solve it myself.

By inchl

Supporter (15)

inchl's picture

24-12-2019, 00:06

Problem solved,....
Clearing the first 3 byte on each scanline on which the sprites become enabled fixed it.
Somehow I think the sprite pre-fetch data was full of gargabe/undefined data which caused the artifacts (sprites were disabled and therefore no fetch took place). Clearing the first 3 bytes on each specific scanline somehow has impact on the content of this vdp buffer holding the pre-fetch data of sprites. After some testing I noticed that the bitpattern of the artifacts correspond to the bitpattern of the first 3 bytes on each scanline..... all very strange, but now it works!

Stephan

Page 1/2
| 2