Re: [hatari-devel] TT palette issue (was: TT version of 4getful by gwEm crashes with newer Hatari versions)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 02/09/2016 01:08 AM, Nicolas Pomarède wrote:
> Le 08/02/2016 23:52, Eero Tamminen a écrit :
[...]
> > Additionally, my fix to the TT palette sync issue Roger reported,
> > breaks 4getful palette handling.  The reason is similar to color
> > register writes on ST, IO register code doesn't support splitting
> > long access to 2 word accesses, so current code misses every other
> > color register change when they're written with longs.
> >
> > Nicolas, should I add separate function for each ST color
> > register on TT, similarly to ST/e code, or change the ST/e color
> > register handling functions to do the work also for TT case?
>
> Is this when writing to ST palette and copying to TT regs with
> Video_TTColorSTRegs_WriteWord, or the opposite ?

The test program does just the former.  I don't have test-case
for latter (except for one from Roger, which does just one
register).


> What is the asm code that does the write to colors regs ? Does colors
> looks wrong with old cpu core or with the latest winuae core that
> doesn't bomb (or both) ?

Only thing affecting it is the handling of registers, which changed in:
	hg diff -c 84f5e208d022

I.e. converting palette entries on each register access,
instead of converting whole palette at VBL (if there were
_any_ register accesses).


> Since 68030 can do long word access, winuae cpu core will call
> the lput handler, but old cpu core will call the wput handler IIRC.

As this problem is there also with oldUAE CPU, I think it uses
long handler.

This is what the program itself does:
	$00020db0 : movem.l   (a1),d0-d7
	$00020db4 : movem.l   d0-d7,$ffff8240.w

It sets the whole palette with single .l instruction...


	- Eero