Re: [hatari-devel] TT palette bankswitching should be supported

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Eero Tamminen wrote:
> Hi,
> 
> Main thing I'd like a comment on, is my addition of
> TTPaletteSTBank variable which needs to be saved into
> memory snapshots, making them incompatible with earlier
> versions.
> 
> It's not strictly necessary to know current/previous bank
> setting, but then SDL palette would need to be synched
> every time something is written TT shifter register.

I've seen instances of PC desktop color discrepancies after
an opengl or mesa or SDL dependent application crashed.
Pick the best method that doesn't have side effects when
things go wrong.

> Which one you consider better?
> 
> 
> 	- Eero
> 
> On 02/29/2016 01:08 AM, Eero Tamminen wrote:
> > 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?
> >>
> >>
> >>
> 
>