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

[ Thread Index | Date Index | More 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 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.


Mail converted by MHonArc 2.6.19+