|Re: [hatari-devel] TT palette issue|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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...
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 :
if ( machine == TT )
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 ?)