Re: [hatari-devel] Next Hatari release?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 22 helmikuu 2013, Douglas Little wrote:
> I also find the purpose of some of the CPU control options on the UI
> unclear.

If you're referring to WinUAE CPU core ones, they're preliminary,
do you have better suggestions?

If you refer options shown for the old UAE core, could you list which
ones are especially unclear?   (They're of course documented in manual
to some extent, but that doesn't mean they shouldn't be improved :-))


> For a user, it's hard to understand the consequences of changing
> them. This seems to stem from problems with orthogonality of features
> provided by the CPU cores? It's probably a difficult job to sort out
> those issues in the cores but some of it is UI presentation - I think it
> would be beneficial to improve this if possible (if not for the next
> release then at least incrementally).
> 
> It would be nice to have an 'unconstrained' emulation mode which uses all
> available host CPU time, allowing the emulated machine to operate with
> 'variable MHz' according to the performance of the host machine. i.e. the
> emulator still counts cycles the same way but doesn't attempt to limit
> 'cycles per frame' (or however it gets capped just now to match
> 8/16/32mhz).

What emulated MHz values can be used is constrained for a reason.


> *There may be a loss of compatibility with time-critical areas (audio?
> dma? display?) but it would be very good for compiling or other
> intensive work on the emulated machine, especially if it can be toggled
> on/off with a keystroke. 

You *can* run the emulation clock faster than the host clock, just use
the AltGr-X "Fast Forward" shortcut, to disable VBL waits & screen
updates related to them [1].

VBLs are still waited at maximum configured frame skip intervals,
(otherwise the emulated mouse could be unusable and one could miss
things when screen doesn't get updated).  If your machine is very
fast, you could specify higher frame skip rate limit with --frameskips
option.

When using fast-forward mode, mouse still works OK (use middle
click to simulate double clicks), but keyboard input repeat is
speeded up, so to type some text, you need to temporarily disable
fast-forward.

(Hatari Python GUI has a button for fast-forward)


> I suppose it would need a really fast host to
> benefit but it's worth thinking about. Note that DSP emulation would
> unlikely be required in such a 'mode' so toggling that off at the same
> time as the MHz cap would probably make sense too?*

DSP cannot be toggled at run-time without emulation being reset.

When I need speed, but not DSP emulation, I just start Hatari with
"--dsp none" (and "--fastfdc on --fast-forward on") as that indeed
gives a very large performance boost.  Using old UAE core version
of Hatari for Falcon emulation gives also slightly more speed.

[1] After DSP, screen updates take most CPU, that's why they're
	skipped in fast-forward mode.


	- Eero