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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 04/11/2012 16:05, Eero Tamminen wrote:

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

Yes some changes like cpu type really require a reset.

Still, cpu speed can be changed without a reset I think (with proper 
code handling it), even if it's not a real life situation on true hardware.

As for blitter and rtc, enabling them should not give a problem, except 
they might not be used since they were not detected earlier.
Disabling them should maybe prompt the user, because it's quite likely 
the running program could try to access a removed component and crash.


> 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

Maybe we should have a common path anyway, with a possible "show dialog 
when reset needed" true/false option.

Ideally, it seems to me we should have :

when hatari starts :
 - set default params in current config
 - load config file/command line in new config
 - apply new config to current config with a parameter 
"FirstStart=true" for example, which would limit warning only to 
blocking situations.

when using the UI :
 - copy current config in new config
 - modify new config depeding on UI changes
 - apply new config to current one with FirstStart=false, which would 
show "do you want to reset" or similar dialogs.

when using the socket :
 -> same as for the UI

with a common code path to all the parameters'changes, we can then 
easily add special cases when a component needs to be 
restarted/reinitialized.
Note that we're not that far from such a common path, a few function 
interfaces would just need to be slightly updated.

Nicolas