Re: [hatari-devel] TT palette issue

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/02/2016 00:08, Nicolas Pomarède a écrit :
> Le 09/02/2016 21:24, Eero Tamminen a écrit :
>
> > 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...
>
> Hi
> when setting io traces, could you tell what you get for these movem ?
> (I don't have much time to run the demo myself at the moment)

forget above, back to your previous mail :

> 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?

The problem is indeed that ff8240 is defined as 32 bytes for TT with 
only one handler, which will not automatically split each long into 2 words.
Instead of adding separate functions names in ioMemTT.c, I think you can 
use the same block for ff8240-ff8260 and in video.c do for example :

void Video_Color15_WriteWord(void)
{
	if ( machine == TT )
		Video_TTColorSTRegs_WriteWord();
	else
	        Video_ColorReg_WriteWord();
}

for each 16 registers.

When writing to ff8400 on the opposite, you would need 256 different 
lines in ioMemTT.c, which is not very clean and maintanable. Better 
leave it as it is now and fix it in a better way later (I don't think 
there're many non working programs relying on this at the moment ?)



Nicolas