search

MEGA65 / mega65-core

MEGA65 FPGA core
Other
239 stars 84 forks source link

DevKit: SPRPTR16 not working correctly #311

Open steph72 opened 3 years ago

steph72 commented 3 years ago

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: P1190150

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

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

gardners commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

lydon42 commented 2 years ago

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?