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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 04/11/2012 13:48, Nicolas Pomarède wrote:
> 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


OK, forget it, the current acia code already takes new values of 
nCpuFreqShift into account automatically, but there was a problem when 
the emulated machine had a CPU freq (as defined in clocks_timings.c) 
different from 8 MHz.
In that case, acia timer was further divided by 4.

You can now use TT mode with correct mouse speed, and change machine 
type and cpu freq (ie cpufreqshift) without error.


Still, I think the question about Change_ApplyCommandline remains, as it 
could be useful some days.

Nicolas