|Re: [hatari-devel] Delayed mouse movements with TT emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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)
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
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
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
Note that we're not that far from such a common path, a few function
interfaces would just need to be slightly updated.