|Re: [hatari-devel] Delayed mouse movements with TT emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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)
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.