Re: [hatari-devel] Palette register handling in TT emulation

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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.


	- Eero