Re: [hatari-devel] Delayed mouse movements with TT emulation

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 04/11/2012 12:43, Nicolas Pomarède wrote:
> On 04/11/2012 11:17, Eero Tamminen wrote:
> > Hi,
> >
> > On sunnuntai 04 marraskuu 2012, Uwe Seimet wrote:
> > > with TOS 3.06 (resolution TT high) when moving the mouse there is a
> > > considerable delay now, which actually makes the mouse unusable. The
> > > mouse pointer is moving just like in slow-motion, while the actual (host
> > > system) mouse is already at a completely different position.
> >
> > I see that too.  And it's not just with TOS v3, but also TOS v2
> > and EmuTOS (v0.8.7) suffer from the same problem under TT emulation.
> >
> > Mouse is completely unusable both in TT mono and color resolutions.
> >
> > It doesn't happen with Falcon emulation or ST emulation using 32Mhz 030,
> > i.e. it's TT emulation HW which doesn't anymore seem to be wired up
> > correctly.
>
> Hello
>
> What CPU freq do you use in TT mode ? It seems 32 and 16 are causing
> problems, not 8 MHz.

The problem is related to changing the cpu freq ; this change is not 
propagated to the ACIA, so it keeps a frequency relative to a 8 MHz CPU.

I think the best place to take this into account would be in :

1) Configuration_Apply, near M68000_CheckCpuSettings

2) Change_CopyChangedParamsToConfiguration


Limitation with 1) is that we don't know the previous value of nCpuFreq, 
so this would force a reset of the ACIA timers each time we enter config 
screen, even if cpu freq does not change, which is not very clean.


In 2), we have current and changed config, so we can check if cpu freq 
changed. Only problem is that CopyChangedParamsToConfiguration is only 
called from the gui and Change_ApplyCommandline. But 
Change_ApplyCommandline is not called when Hatari starts and parses the 
command line, only from control.c when using sockets to control Hatari.

Is there any reason why Change_ApplyCommandline is not called from 
main.c (only Configuration_Apply is called) ? It would allow to apply 
specific code when the command line option differs from the default 
value (thus handling cpufreq which is modified when 'tt' mode is selected)


Nicolas