Foxie wrote:Since upgrading to v2.1.0, I have a performance problem. Previously, I always had prefetch mode and cycle exact mode enabled. This was OK when emulating a TT or Falcon. As of v2.1.0, enabling either (or both) of these options slows my i7 to a crawl - I only get a few frames per second.
I have a couple of questions. Do "cycle exact" and "prefetch mode" have any effect on 68000 emulation? Or is it 68030+ only?
Also, is there any way to enable/disable these options on the command line? I use a launcher script for Hatari which allows me to select a pre-defined machine configuration. I'd want to enable cycle exact and prefetch on an ST, but disable it on a Falcon/TT.
I have also noticed that with cycle exact and prefetch disabled, NVDI won't run on the Falcon. The system locks up at boot.
Cache emulation got more accurate in Hatari v2.1, and it's enabled by default, that slowed down "cycle accurate" emulation a lot. There were similar improvements also with MMU emulation, but that doesn't have much perf impact. Both caches and MMU are 030+ specific features, so they don't affect 68000 emulation.
On Falcon, cycle-exact is mainly needed by some of the demos, for better CPU<->DSP sync. Unless you run timing sensitive demos, just disable cycle-exact, maybe also prefetch mode for 030+ emulation. On command line you can do that with: "--cpu-exact off" and "--compatible off".
For more information where cycle-exact is needed, see the Hatari compatibility list:https://hg.tuxfamily.org/mercurialroot/ ... ility_list
(If you notice something in the list not to be up to date, please comment on Atari-forum or hatari-devel mailing list.)
Note: there have been similar complaints also from other Mac users, but Hatari 030+ cycle-exact emulation works fine for me on Linux with my old i3 CPU. v2.1 takes more CPU, but it's a problem only when something is taxing also DSP emulation.
Foxie wrote:Also, another unrelated problem: the mouse speed appears to be slower in this release (on OS X). I can no longer move the mouse from one side of the screen to the other without moving outside the emulator window. I seem to recall there is some way of adjusting this?
On Hatari side there have been no changes that should affect that. Hatari v2.0 was probably built with SDL v1, and Hatari v2.1 *is* built with SDL v2. All the OS specific backends in SDL were AFAIK re-written for v2 (which uses now GL for scaling application output) -> I think any mouse change would be due to libSDL version change.
You'll probably know this, but you can use mouse grab keyboard shortcut or fullscreen to make sure mouse keeps within Hatari window.