|Re: [hatari-devel] Delayed mouse movements with TT emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
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
Besides changing this line in main.c:
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
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
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.