Add support for setting CPU compatibility + cycle-accuracy,
+ FPU type + accuracy, MMU and ST blitter options.
For now this still takes into account whether underlying Hatari
version uses WinUAE core or not. That will be removed for next
release.
Several of the scripts are likely to continue working with both Python
v2.7 and v3.x still (as they haven't changed significantly in a long
time), but from now on, it's accidental, neither tested nor supported.
* wait until Hatari has finished writing its config
* check also case where Hatari didn't manage to save config
* show user error dialog on config saving issues
(Hatari didn't work or config wasn't e.g. writable)
PS. These issues may have been there since 2016 (a6b53512dc)
Without this results of resizing the Python UI window looked really
odd (menubar padded itself vertically and right toolbar added padding
to the right).
If config file had invalid paths for some of files, setting full
dialog's worth of options (including faulty ones from config file +
user changed ones) in a single [1] Hatari control API command line
would result in Hatari rejecting all the changes due to one invalid
option value.
Hatari option setting is currently one-way so Python UI doesn't know
about these errors and Hatari doesn't give any indication of them for
user either (except in console).
Therefore this commit will filter out invalid file name options from
the command line (given to Hatari through Python UI control socket).
Note that this is an issue only with (floppy, HD and TOS) image files
as Hatari socket / command line parsing validates those immediately.
It's not an issue with device files as Hatari will itself notify user
about invalid paths and it disabling corresponding device
functionality as result.
[1] Dialog options are given in one go to Hatari so that only one
reboot is needed for all the dialog option changes triggering one.
- If user cancels, config changes aren't discarded, so change text
to ignore
- Ask for config save/ignore/cancel before killing Hatari,
as quitting can't be canceled after Hatari is dead
- Scale config viewport with dialog resizes, otherwise viewing
larger number of changes is hard
- Improve Hatari kill dialog text
Resize handling requires GtkScrolledWindow functions that came in Gtk
v3.22, which is available in Ubuntu 16.04 and Debian 9 (current
oldstable) => update docs accordingly.
There's a crash if either [1] or both Python UI and Hatari are running
under Wayland, because GtkSocket supports embedding only on X11.
[1] when Weston is run under X11, Python UI (Gtk3) will default to
running under Wayland, but Hatari (SDL2) defaults to running under
X11. I assume similar thing would happen if Xwayland is running
Wayland, as would happen e.g. under Gnome desktop.
- no RTC option, instead there's new ModelType option
that includes MegaST/E (which has RTC)
- WinUAE & oldUAE support different set of CPUs
- Keep ST resolution option is valid only with
SDL1 builds
For maximum compatibility, the default mode for Hatari is now to run the FDC
at the same speed as a real ST. The option --fastfdc can be used to speed up
most FDC delays (this should works with most of the games/demos, but can lead
sometimes to incompatibilities when the programis expect some precise timings)
Eero Tamminen