VDP9938 Sprite table registers

Rookie (26)

02-07-2021, 22:38

Hi All,
I've been trying to figure this out for the last few days and I wonder if someone can help.
Basically I'm trying to calculate the sprite pattern base address as VRAM base + (VDPregister6 * 0800h)

with sprite base register (reg6) having the value 0x1F then the sprite base should calculated as 0x1f * 0x0800 = 0xF800

Fine so far, until I find that the actual sprite pattern data is stored at location E0D0, and displays fine on the crt screen.

how can it be possible that the sprite data can be stored outwith the sprite pattern memory and still be visible?

is there some kind of bit masking being applied by the hardware on register 6 before the hardware works out the base address of the sprite pattern?

Any help would be appreciated.

Regards

!login ou Inscrivez-vous pour poster

Par Grauw

Ascended (10707)

02-07-2021, 23:26

Depending on the screen mode some registers indeed require some bits to be set to 1, which are considered as AND masks rather than base registers and should be considered as 0 when calculating the actual address. I wrote about it earlier here and here.

However for the sprite pattern base this is not the case, since the table is the same size in every screen mode, every bit in the register is always used and does not need to be masked.

One thing to consider though is that if sprites are set to 16x16 size, the pattern number needs to be multiplied by four. That doesn’t explain what you describe either though.

The final logical conclusion I can come up with based on the information you provide, is that something else sets the sprite pattern table base register to a different address, or you made a mistake while determining the actual sprite data address.

Par M2X_E1

Rookie (26)

06-07-2021, 23:14

Hi Grauw, thank you for responding to my post, apologies for the delay in responding.

I recall reading your posts on the AND masks, i found these very useful and it helped solve a puzzle in the vram mirroring when i was rendering mode4 graphics on the vdp (screen5 msx).

I've a strange feeling that something might have corrupted the vram data, I will have another look at this and post any findings which may be useful.

Thanks again!

Par M2X_E1

Rookie (26)

04-12-2021, 15:25

I noticed my earlier post, been a while since i was able to work on this.
suffice to say the problem was specifc to my own application, i had the wrong vram register values.

For interest. i had taken a kingsvalley 2 screen dump and loaded it into vram, and also made a copy of the display registers too (at a later time). However, later noticed that the registers were constantly changing back and forth on the emulator, pointing to different pages in memory, where the data may also have been alternating. I just resampled all of these again at the same time and it worked fine.