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

[ Thread Index | Date Index | More Archives ]


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

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

Mail converted by MHonArc 2.6.19+