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

[ Thread Index | Date Index | More 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
by Main_Init().

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


Mail converted by MHonArc 2.6.19+