New default Amiga model for WHDLoad variants going forward

[FrodeSolheim]

From time to time, the question of the default Amiga model/options for variants imported into OpenRetro.org comes up. I am open for discussing the default model for WHDLoad variants going forward.

The thing I like about the A600 model is that the emulation is cycle-exact and quite accurate, so, games should not break when updating the UAE core, while also being possible to emulate on low-end devices like the Raspberry Pi 4 . A1200 (cycle-exact or not) is less accurate, so there could be compatibility issues when updating UAE. Also, A1200 (cycle exact) is much more demanding to emulate.

On the other hand, A1200 without cycle exact is much easier on the host system (comparable to A600 cycle exact). And many WHDLoad games are patched to be less dependent on exact system timing (to work better on different kinds of Amigas, including high-end). So maybe a non-cycle-exact A1200 model as default is a good idea. Someone needs to do some testing and come up with a good config for this model - to be as compatible with WHDLoad games as possible.

* Compatible CPU or not?
* Memory cycle exact or not?
* Immediate blitter or waiting blits?
* Would it be better to emulate a slightly faster (and less accurate) A1200? I think the 68020 CPU in non-cycle-exact mode already does this though.

The goal should be to try to avoid using lots of resources (= avoid "cycle exact" A1200 if possible), so that the configs can run on an Raspberry Pi 4 in most cases, while also being highly compatible with the current set of WHDLoad slaves out there (and also be reasonable compatible when updating the UAE core from - say WinUAE 3.3 to 4.4)

I'm not sure what set of options would be the ideal base here. Perhaps someone who has run a lot of WHDLoad slaves in emulation have some input on this?

(EDIT: Should also mention that the default does not have to work for 100% of the slaves. There is always possible to add extra configuration to the database when needed.)

On reason that has been mentioned for wanting to have an A1200 model as the default is to get support for (configurable?) quit key. I'm not sure how important this is. Does all WHDLoad slave support at least a fixed quit key? If so, FS-UAE already has an option where the FS-UAE can be told about the quit key - and will inject the key press when quitting FS-UAE. So instead of reconfiguring the WHDLoad quit key, FS-UAE can be configured to adapt to the slave. But of course, this only works if the slave has a quit key at all on 68000 - which I have assumed is the case.

[jotd]

I would answer this:

- create a mantis account on mantis.whdload.de
- report slaves with missing 68000 quitkey (there shouldn't be a lot of them now)
- report slaves with speed issues when "cycle exact" isn't used.

All that benefit to real amiga owners so that's worth

[jbl007]

I'd vote for A600 non-ce plus

cpu=68010

[jotd]

you'd lose all AGA games with A600

[jbl007]

Only for the non-AGA games of course.

[FrodeSolheim]

Yes, AGA games will need A1200 or higher of course I forgot to mention that there could very well be two defaults, one for AGA and one for non-AGA. That's how it works today (non-AGA games get cycle exact A600 by default, and AGA games gets "cycle exact" A1200 by default).

A reasonable starting point for a single universal model/config I guess would be to look at WinUAE's A1200 defaults. In particular, one of the "less compatible" ones. In the middle-range there we have an Amiga 1200 with:
* CPU: More compatible (not cycle-exact)
* No memory/DMA cycle exact (I suppose this is not needed for WHDLoad games either?)
* Approximate A1200 speed
* "Wait for blitter" option is set.

Notes:
* "Wait for blitter" - This one might not need to be set since the WHDLoad slaves have generally been patched with blitter waits where needed... ?
* Fast RAM would be added as today of course, to allow for PRELOAD etc.

[jbl007]

Yeah, A1200 non-ce could cover it for most of the games. But emulation of 14MHz 020 is still too demanding for low end hardware like the pi4. On the other hand... a faster emulated Amiga will reduce loading/decrunch time for an improved game experience. In the end it really depends on the game...


What about a global default config for whdload games? The user can choose between low, mid and high in the launcher's setting depending on what the hardware is capable of.

[FrodeSolheim]

Originally Posted by jbl007

What about a global default config for whdload games? The user can choose between low, mid and high in the launcher's setting depending on what the hardware is capable of.

A big point of the online database is to give users working configurations out of the box, so ideally want the model to be set to the working one, and not leave this "problem" to the user. With a default model - and with the option to specify exceptions - presumably, users will report when the default model does not work, and then an override is specified. This is how it works today.

There is however another way, which will allow for the choice: Let users report whether a specific game/variants works with one of the few chosen models. So instead of having a single

amiga_model

option in the database, we have

works_with_a600 = yes/no

and

works_with_a600_non_ce = yes/no

(etc). This way, the user could be given the choice to use "simpler" models where they have been tested to work. Or even specify the preference to use "A600 non-ce" *unless*

works_with_a600_non_ce = no

. But it will take significantly more testing and user input to get this up and running for all WHDLoad games. Still, it is something I have been thinking about. And we would still need a recommended/default model in any case.

(I'll also do some testing with FS-UAE 4 on Raspberry Pi 4 when time permits. Last time I checked, A1200 emulation non-cycle-exact looked promising at 2 GHz.)

[jotd]

if you use whdload then you shouldn't care about all super accurate cycle exact or chipset stuff. whdload saves that hassle. Just set max speed (no JIT) and that should work for most slaves

Slaves for which a "fast" setting doesn't work should be reported.

[jbl007]

So basically what I proposed, but with the approval of the online database. I like this idea.

Originally Posted by FrodeSolheim

(I'll also do some testing with FS-UAE 4 on Raspberry Pi 4 when time permits. Last time I checked, A1200 emulation non-cycle-exact looked promising at 2 GHz.)

I recently tested in this in Manjaro Linux. Demos mostly (too lazy to play games ). Again it really depends. Sometimes it even struggles with A500 stuff if heavy chipset emulation is needed. The good thing is FS-UAE only slows down and recovers quite quickly. Amiberry get out of sync and mostly stays out of sync which is quite annoying.
DRM, wayland-native-sdl, x11-sdl does not make much difference in terms of speed. btw.

[jotd]

Demos are a different beast. Much more difficult to get some running properly with emulators or fixing them in whdload. I personally never fix demos for that reason.

[Tigerskunk]

@frode: just here to say thanks for FS-UAE.

[FrodeSolheim]

Originally Posted by jbl007

So basically what I proposed, but with the approval of the online database. I like this idea.

Yes. I should have made it more clear that it was just a modification of what you proposed

Originally Posted by jbl007

Sometimes it even struggles with A500 stuff if heavy chipset emulation is needed.

Please consider testing performance of FS-UAE 4 on the Pi 4 instead of FS-UAE 3: https://eab.abime.net/showthread.php?t=106562. I haven't tested a lot of stuff, but it seems to run A500 cycle exact well enough at least at 2 Ghz. If you have some examples of extra demanding games or demos to try out, I'd appreciate a post in this thread

Originally Posted by jotd

if you use whdload then you shouldn't care about all super accurate cycle exact or chipset stuff. whdload saves that hassle. Just set max speed (no JIT) and that should work for most slaves. Slaves for which a "fast" setting doesn't work should be reported.

Interesting, thanks for the feedback Fastest-possible mode is not reliable enough in FS-UAE 3 good gaming experience (no vsync for example), but in FS-UAE 4 this is a possibility.

Originally Posted by Steril707

@frode: just here to say thanks for FS-UAE.