|Re: [hatari-devel] Palette register handling in TT emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 01/07/2016 01:26 AM, Roger Burrows wrote:
I'm working on improving TT video support in EmuTOS and I'm using Hatari 1.9
under Linux for testing.
I was trying to understand the interaction between the ST(e)-compatible palette
registers and the TT palette registers, so I wrote a test program and ran it on
my TT. It seems that (assuming the bank# in the TT shifter control is 0), the
first 16 TT palette registers map directly to the ST(e)-compatible registers,
and vice versa.
You tested that setting TT color registers updates also ST color
registers? Hatari doesn't emulate that...
If that's correct, then I think that Hatari is doing it wrong. When I write to
e.g. 0x00ff8242 (ST palette register 1), the word at 0x00ff8402 (TT palette
register 1) isn't updated immediately. Similarly, writing to TT Palette
register 1 doesn't update ST palette register 1 immediately. This is different
from real hardware.
What means "immediately"? Right after instruction writing to ST palette
register? On next HBL?
Note that Hatari's current Videl emulation (used also for TT screen
drawing) doesn't take into account palette changing during VBL, only
what the palette is when VBL happens.
So visually palette matters only once per screen update, at which
point Hatari syncs ST palette to TT one and then that to SDL palette.
However, at least in theory it's possible that some code depends
on setting ST palette and then elsewhere checking for TT values.
So, if you can confirm that writing *either* ST or TT color value
immediately sets also the other color value, I can provide patch
to fix it, but I don't have test code to verify it works fine.