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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 04/11/2012 17:44, Eero Tamminen wrote:
> > 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?

I don't think so. Changing cpu speed on the fly can be useful when using 
program that don't rely on cpu cycle exact count (gem programs for 
example). It should not cause crashes in most cases, but it could give 
strange result. It's really a "change at your own risk setting", but 
requiring a reset seems not necesary to me.

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

I think the benefit will show if we decide one day to have a better 
split between the emulation itself and the UI, in case we want to use 
more UI toolkit one day.
The logic should not be duplicated in the UI, but centralized in the 
main emulation.

Also today, trying to figure out where I should take the nCpuFreqShift 
into account to be sure it was correctly handled was quite hard to spot. 
There's no real unique place to do it.

The main start has shortcuts because it considers we're doing the 1st 
init, not modifying an already running init.

Then the UI has more functions to apply changes, with different 
behaviour (eg : changing to machine='tt' is not the same in UI and in 
commande line).

Over the year, different init functions were added and now everything is 
quite entangled, with init for hardware components, init for 
sound/graphics system, init for drive emulation on the local filesystem, 
.... all in one place, with no specific order.

I think we should have a cleaner logic, with well defined steps (inits 
that deals with the underlying OS, init for the emulated components, ...).


Unfortunatelly, I don't have time to work on this now (and I would 
expect quite a headache to sort it out ;) ), so I will leave it this 
way, unless someone wants to do it.

Nicolas