Implemented sprite cache + some bugfix

[gyurco]

Now it worth to watch Titan 2 again!

[harbaum]

Will test it asap ....

[harbaum]

Looks great! I see rain :-)

Anyway, the latest changes have broken the sprite test. But that shouldn't be too hard to fix. I'll have a look tomorrow.

[gyurco]

And a landing spaceship :)

The sprite masking and overflow test rom still green for me.

The timing still sucks towards the end, but nearly all features implemented. However there are some artifacts in some scenes (e.g. the rotating Overdrive 2 logo), maybe still a bug in the 128k mode (but that's very simple already), or the SDRAM controller/cache has an issue.

[harbaum]

The sprite test only fails in vdpsim ... odd

Maybe i now need to fill the sprite cache? Currently VRAM is "just there" and thus probably no sprite cache is filled.

[gyurco]

That's possible, because only VRAM writes fills the cache now, the static data is not used at all. Maybe filling VRAM like the CRAM, via data transfer? That can be also used to exercise the data transfer engine.

[harbaum]

According to http://md.squee.co/VDP the sprite cache is filled on every VBLANK. I'd assume that it's filled from VRAM and not by CPU/DMA writes. This makes a difference if the location of the sprite table changes since the cache contents will then not be updated in your current implementation but it would if this happens in VBLANK from VRAM.

Anyway, i've updated vdpsim to write the sprite attribute table through the cpu interface and the test now passes again.

[gyurco]

That's wrong in that Wiki. It's a good information source, but you have to be cautious, there are mistakes in it. As the Titan 2 tech doc says:

The VDP has an internal sprite cache that caches the Y and size/link fields of each sprite in order to quickly determine visibility of sprites without having to access VRAM. This is implemented as a write-through cache - the moment a write to VRAM occurs the VDP checks whether it goes to the current location of the sprite table, and if it does and affects an Y or size/link field then the respective cache table entry is updated. And this is the only way of updating the cache, moving the sprite table address will NOT update cache contents (so contents of the cache and underlying memory will differ). Also, this mechanism is sensitive to the entire 128 KB address range even in 64 KB mode, so when setting bit 16 for the sprite table address but not for the Write/DMA target address (or the other way round) the sprite table in memory will get updated but the cache won’t.

[harbaum]

I just checked what blastem does and it it also fills the cache from writes.

I wonder if this could be used on a 64k setup to place the sprite attribute table outside the 64k address range.

Edit: No it can't since not the entire attribute table is stored in the cache but only Y and size/link.

[gyurco]

Yes. I wonder why they didn't use an on-chip RAM for the whole table, why just the half of it. And the VRAM part of the cache is actually not used at all.