DevKit: SPRPTR16 not working correctly

[steph72]

In yaped32 (my 32 colour petscii editor) I use SPRPTR16 to put sprites in the $00fxxx memory range. This worked fine on my R2 prototype M65. When I got my DevKit I noticed that sprites are no longer displayed correctly.

I wrote a little test program (attached to this issue) to demonstrate the problem.

On the M65 prototype, the (correct) output looks like this:

whereas on the DevKit, only one line of the sprite is displayed:

Here is the BASIC 10 test program to reproduce the issue:
spritetest.zip

[gardners]

There is indeed something weird going on here.
The first row of the sprites comes from $F000, as expected.
But the subsequent rows are coming from $C000.
So the fetch address is getting borked somewhere.

The issue is an in-progress fix for latching sprite data source area, like VIC-II does, or continuously monitoring the sprite pointer to allow different sprite data to be selected every row, like we previously implemented on the VIC-IV, but which is not actually correct.

To select the correct VIC-II behaviour, which also works around this bug: Clear bit 3 of $D07A.

But I still need to find out the root cause and fix it.

[gardners]

Probably needs simulation and grinding through the VHDL log messages to see where the sprite fetches all happen from.

What we know is that at the start of the sprite, when sprite data offset = 0, that it is right. But then for subsequent rows, its like the sprite pointer has $0000 in it, instead of the correct value.

More investigation: For subsequent rows it has rubbish in there, because it seems that the sprite_data_addresses() array doesn't get updated sometimes for some reason.

As said, this all needs more debugging.

[steph72]

I tried the workaround with clearing bit 3 in $d07a. The good news: Sprites are being displayed now; the bad news: The first line is corrupted. The strange thing is that the corruption changes with the position of the sprite... I've attached a little clip, maybe it helps you narrow down the overall problem...

https://streamable.com/5dtndy

(yaped32 has two cursors as sprites: one is the mouse pointer and the other is the current character position)

[gardners]

I think I have found the cause of this problem now. Will hopefully synthesise a fix for it soon.

[lydon42]

Can't reproduce this on r3a board and pre release development / rom.

@steph72 could you please recheck and close this issue if it is resolved?