[hatari-devel] Mouse ungrab, palette?

Eero Tamminen eerot at users.berlios.de
Mon Jun 1 23:17:34 CEST 2009


On Monday 01 June 2009, Thomas H. wrote:
> > * adds --grab command line option for enabling mouse grabbing also
> >   from command line:
> > * ungrabs mouse when Hatari is paused (and regrabs when unpaused)
> Looks fine for me, too. Maybe just add curly braces to the if-clauses in
> main.c (since the body of the if-clause is two lines including the
> comment) ?

Done & commited with manual updates.

> > > There's also a feature to change Steem palette.  This can be used to
> > > see whether there's actually something on screen.  Would that be
> > > useful for Hatari too, e.g. for debugging DSP issues?  And how it
> > > should work?
> >
> > Any comments on the feature of forcing the default palette?
> I never used that feature in Steem, and I never missed it yet.
> Would it be sufficient to write other color values to the color register
> with the help of the debugger? Something like "w ff8240 0f 00" ?

Seems so.  As the color registers are different for:
- ST/e: 16x 12/16-bit entries, ff8240->ff8260
- TT: 256x  12/16-bit entries, ff8400->ff8500
-Falcon/Videl: 256x 24/32-bit entries, ff9800->ff9c00

Maybe it's better to have the default color register values as something
one can dump from a file to memory.  And maybe there could be a directory
like "debug", "data" or "debug-data" which contains these kind of dumps
and README with quick instructions / reason for using them?

(I would assume most things even on Falcon & TT to use ST/e compat regs 

	- Eero

PS. I noticed something strange in Videl code. ioMemTabFalcon.c:
       { 0xff9800, 0x400, IoMem_ReadWithoutInterception,
           VIDEL_ColorRegsWrite },   /* Falcon Videl palette */

0xff9800 + 0x400 = 0xff9c00.

However, in videl.c:
	#define VIDEL_COLOR_REGS_BEGIN  0xff9800
	#define VIDEL_COLOR_REGS_END    0xffa200

(latter define isn't used though.)

More information about the hatari-devel mailing list