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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 04 marraskuu 2012, Nicolas Pomarède wrote:
> 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

Currently emulation isn't reseted on all HW emulation changes,
reset seems to be missing on emulation changes to these:
- CPU type
- CPU speed
- Blitter existence (relevant only for ST emulation)
- RTC

I think this is a bug.


> > 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.

If the above bug is fixed, Configuration_Apply() gets reset flag
when something significant is changed, so you could do the timer
reset only on emulation reset.  But if you didn't already do timer
reset on emulation reset, I think that's also a bug...


> > 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)

Only thing that Change_ApplyCommandline() does is to parse a single string
into argv array.  On Hatari startup command line is already in argv array..

At the end Change_ApplyCommandline() calls the Change_Options() function
which:
1. Pauses emulation during configuration change
2. Call Opt_ParseParameters() i.e. the function that does the real
   work of parsing the command line
3. Shows a dialog if change was such that it requires emulation reset
4. Call CopyChangedParamsToConfiguration()

Change_Options() isn't called at Hatari startup because:
- 2) is already called at Hatari startup
- Showing dialog about reset on non-running emulation on Hatari
  startup would be idiotic
- 1) and 4) aren't done because emulation isn't running at Hatari
  startup, only after configuration is finished


> 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.

Why it affected only TT emulation at 16 & 32MHz and not Falcon (=16Mhz)
or ST emulation when it was run at those speeds?

 
> 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.


	- Eero