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 16:05, Eero Tamminen wrote:
> > Why it affected only TT emulation at 16 & 32MHz and not Falcon (=16Mhz)
> > or ST emulation when it was run at those speeds?
> 
> Don't know, maybe because falcon mode used winuae's cpu ? I don't think
> this really matters now it's fixed.

I ran all the tests with old UAE CPU core, not WinUAE one.


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

Does the speed change have any effect on CPU caches etc?

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

Prompting is done for anything that causes reset.  If user doesn't
OK, changes are discarded.


> because it's quite likely
> the running program could try to access a removed component and crash.

IoMem.c stuff seems to set RTC registers to IoMem_VoidRead/Write when
RTC isn't enabled i.e. it doesn't bus error, reads just get 0xff.
I don't think this needs reset.

Blitter access on ST without one gets bus error though.


-> I.e. CPU type change and Blitter change on ST should cause reset?


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

You also need to check that all HW uninit functions called by
CopyChangedParamsToConfiguration() work properly when they're called
before *any* of the HW or other init functions have been called
by Main_Init().

Besides changing this line in main.c:
	Configuration_Apply(true);
to:
	Change_Options(true)

This change just adds extra code.  I don't really see the benefit,
but feel free to propose a patch.  :-)


	- Eero