Hi,
On 02/26/2016 12:54 AM, Eero Tamminen wrote:
Looking at Roger's test program (which doesn't change
any palette entries, just queries them after changing
bank), it's not enough to map ST palette writes, also
reads need to be mapped.
And as byte sized writes to ST palette entries need
to be blocked, I think I need to re-write the palette
handling so that both ST palette writes AND reads are
directed to suitable TT palette entries.
Instead of that, I decided just to copy suitable
bank of palette entries from TT-palette to ST(e)-palette
on bank switch. I also decided to use separate TT
function for handling ST color regs. The attached
patch adds one more save file variable which means
an ABI break.
The patch works fine with Roger's tester(s).
Comments?
As to byte accesses, this only prevents TT-palette
entries from being modified. As TT values are ones
set to SDL palette, the TT-register values and colors
on screen should be correct on byte accesses, just
the ST-regs are wrong (until they get updated).
- Eero
CPU core can manipulate ST palette registers directly,
but they're used just on writes, not on reads.
- Eero
On 02/23/2016 07:55 PM, Thomas Huth wrote:
Am Sun, 21 Feb 2016 22:56:14 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
Hi Roger,
On 02/21/2016 07:26 AM, Roger Burrows wrote:
On 21 Feb 2016 at 1:00, Eero Tamminen wrote:
Ah, so this isn't about ST<->TT color palette mapping,
but about e.g. 16/4/2 color modes. Both TT and ST modes?
It applies when bank-switching is active, so should apply to ST
low, ST medium, and TT medium. I originally tested just TT medium,
but I've now tested ST medium & ST low and (as per the Atari
documents), it applies to all 3.
Note that this does not apply to any other TT mode (ST
high/duochrome, TT high, TT low).
Thanks for the testing!
Could you send the test program you mentioned?
Attached patch hopefully fixes that.
You might also need to set bTTColorsSync = false in case the
application writes to the TT shifter mode register?