Re: [hatari-devel] TT palette issue

[Thomas Huth <th.huth@xxxxxx>]

On 11.02.2016 00:31, Nicolas Pomarède wrote:
> 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 ?)

Alternative idea: Use one handler, and in that handler check for
nIoMemAccessSize == 4 ... in that case you have to handle a write to the
register after the current one, too.

 Thomas