Running my OS4 games on QEmu

@LiveForItQuote:

Thanks for the explanation, then of course the 16-bit support makes more sense in software rendering.

Hi!

>If you have the option use ffplay. It should solve the problem >Qemu pegasos 2 G4 - is ns SDL2 and is based on ffmpeg.
>It should work on any Amiga.

Not in the released version probably but I will go sure to offer an update to fix this for QEmu users (probably just a replacement for the "mplayer" file which then internally calls ffmpeg ). Note you can run the videos if you start qemu with -cpu G3.

>Not everyone will buy it. It is better to make the game work on >any hardware and not make it dependent on the driver. As >@TheMagicSN wrote - it even works acrually on Qemu already.

Exactly. And there are no other options to make it work "better" on QEmu. As to speed - either it runs or it doesn't Not much options to make it faster sadly.

>A MacStudio/MacMini (ARM) does not have a DVD/CD-ROM drive. It's >like with the new XboxOne series X you can decide for it or >against it.

>You can see in my signature which hardware I use in conjunction >with Qemu and AmigaOs4.1. But that will be the least of my >problems since I still have an external CD/DVD drive lying >around that I could connect to my Mac.

I see. Have to admit I do not know much about Macs these days

But as you said yourselves an external CD will fix this, and once the CD has been written into an ISO it can be mounted by OS4 - problem solved.

And you actually do not need the CD while playing, only for installation.

>So the only problem that remains at the moment is playing the >video sequences...

Yes.

>Is MPlayer installed when you install your games?

Yes.

>Then you could simply replace it later with a version that >causes fewer problems. The option to deactivate the cutscenes >would also be an option, but that would certainly lose some of >the fun. Does it only affect the intro video sequences or all >other in-game sequences too?

For Sin definitely a later version will be used then. And it only affects the bumper video (Hyperion+Raven+Activision logos), intro video and outro video. Ingame sequences are not affected as those are in game graphics (so they are not affected), not with external video.

>When will you release your game ports for AmigaOs4.1?

H2 - pretty soon (so probably too late to change anything there on the video issue).

Sin - no idea yet, it is still pretty early in the project. Somewhen 2024 I would assume.

MagicSN

@TheMagicSN
If you're using QEMU Windows builds from weilnetz.de that are linked from the qemu.org download page you may also try the builds from emaculation.com instead which are closer to actual QEMU source and were tested to run PPC MacOS so may work better. I'm not sure though so if you try it please let us know if you saw any difference.

Currently the sam460ex emulation is the slowest other machines might be faster, the pegasos2 is likely the fastest at the moment but has some issues with SDL1 that interetingly does not happen on amigaone which is almost the same hardware so I wonder if SDL1 has some code to detect it running on amigaone that does not work on pegasos2 or there's something in the AmigaOS version that's different between amigaone and pegasos2. Within QEMU these machines are mostly using the same emulation so I don't know where this difference could come from. That it works with G3 but not the default G4 might suggest it could be something about using altivec but then why that's not an issue on amigaone which also has G4? Reproducing it on real pegasos2 is probably not easy as SM502 is not normally present on that. Maybe if there was a PCI card with SM502 it could be tried in real pegasos2 and see if that reproduces the issue. It was tested with 16bit mode of ATI card but I think those have different endianness than SM502 so maybe that's why it could not be reproduced.

One known limitation with QEMU PPC emulation is that FPU operations are slower so if your workload uses floating point a lot but there's an option to use integer math instead that might help. I wonder if this could be the reason for lower performance with the software renderer compared to running on real machine (also with software renderer on real G4 of course, comparing to GPU is a different thing and should only be resolved by having drivers that can handle 3D that Hans is working on). Is there a way to reproduce and test this with some sofrware that's freely available so we could run that as a benchmark and try some profiling to find what slows it down with higher resolutions? (Fixing the FPU problem in QEMU was considered before but it's not easy to emulate it accurately and still be fast and QEMU chose to be accurate over being fast. But now that there's the A1222+ with its own FPU issues maybe more software will avoid FPU usage that would also help with this.)

Hi!

>If you're using QEMU Windows builds from weilnetz.de that are >linked from the qemu.org download page you may also try the builds >from emaculation.com instead which are closer to actual QEMU >source and were tested to run PPC MacOS so may work better. I'm >not sure though so if you try it please let us know if you saw any >difference.

Thanks for the hint.


>That it works with G3 but not the default G4 might suggest it >could be something about using altivec but then why that's not

As it happens before even the screen opens it sounds doubtful to me to be related to Altivec but no idea.

>One known limitation with QEMU PPC emulation is that FPU >operations are slower so if your workload uses floating point a >lot but there's an option to use integer math instead that might >help.

This is not possible. All my games rely massively on FPU performance and this is not possible to change. Probably MUCH easier that they improve FPU support. And they should, really. At least for games integer math doesn't matter anymore. It is only FPU which matters. And without reimplementing the games from scratch (I mean not the port, I mean the basic code of the game) this cannot be changed. Actually I am not even sure if it could be changed then even.

I don't know what this is, all those solutions which have bad FPU things - Apollo Vampire, A1222 (well, not an issue of performance here, but an issue of ABI) and now QEmu too ?

Nobody cares how great integer math you have in your CPU - it is FPU math which matters.

"Avoiding FPU usage" ? At least with modern games (as in "games which were modern 20 years ago and everything more recent") - not possible.

Again - tell them to improve FPU performance

MagicSN

I remember on qemu-dev channel there were some patches about implementig fpu call in hardware mapping 1:1 powerpc with isa of cpu host.

Problem is related about how powerpc fpu flags works, a full implementation slow down a lot emulation so for now all is based on soft-floats and their 100% accurate results.

Someone should really take over these patches and implement these for a full fpu emulation speed.

@TheMagicSN
Quote:
Tell whom to do that? QEMU is an open source project like the Linux kernel. There aren't people you can tell what to do. If somebody wants something to happen either do it and submit a patch or if can't do it may try to hire somebody to do it but otherwise it won't just happen. Looks like nobody cared to do either of these so far so it's still like that. I've tried before to enable hardfloat to test how much it would help and while it did run a but faster it made the current way slower and broke emulation of some bits in floating point status that probably nothing uses but breaking it is still not acceptable so I did not finish that and hardfloat remains disabled for PPC until somebody solves that it would both be correct and only use hardfloat if guest does not access these bits. We made some design how to do that but this is a bit more work that nobody wanted to put in yet. Somebody was interested once but then never came back with a patch so gave up without results.

But we don't know yet this is really the reason for running slower in higher resolutions so the question remains if there's a benchmark that shows this which I could try to profile and see what parts of emulation it uses so maybe it's something else that could be improved more easily.

There's also a possibility to use a real graphics card passing it through to the guest but that only works on Linux hosts and only with some graphics cards and it's not straight forward to set up so it's mainly for curiousity not something an average user might exploit. There were some experiments in one of the threads about it before and it could be made working but some bugs were also found which may need an updated AmigaOS kernel which isn't released yet so don't know how useful is that option other than for testing. (If you're on a laptop running Windows then it's not an option for you anyway.)

I know of course it is OpenSource

Just after the third Amiga related project where I got told "use integer math".

No. It is not an option ...

@TheMagicSN
You don't need to change any sources to disable FPU usage, simply recompile everything with CFLAGS += -msoft-float.
Of course the result will be unusable slow on any real AmigaOS 4.x PPC hardware, and I don't know if using guest softfloat is faster, or even slower than QEmu's host softfloat.

Additionally the softfloat functions in both clib2 and newlib are just approximations, not exact results, which may cause problems. Maybe clib4 has better softfloat support.

@balaton

Quote:

No, it shouldn't have code like that.

@Capehill
Where are the sources of that SDL1 version that exhibits the problem so we can check what it does? If it's the same on amigaone and pegasos2 and both use the same sm501 graphics card and CPU emulation in QEMU then how come it works on one but not on the other? Is there something different in AmigaOne version of AmigaOS vs. PegasosII version that could cause this? We should also be using the same siliconmotion502.chip driver on both and AmigaOS should also be the same on both. Still there should be something somewhere that makes it work on amigaone but fails on pegasos2 but there's nothing in QEMU to explain that so it should be somewhere else.

@joerg
Even if -msoft-float is not a solution it might worth a try just to see if it changes anything. I can't tell if guest soft float would be slower/faster/same speed as QEMU soft float because while running in the host should be faster QEMU does a lot of checks and additional processing to emulate the CPU flags so if the guest does not do that it might be faster after it was JIT compiled so maybe it could help or be the same speed at worst. But it's still a guess that slow FPU causes to most problems, it may be something else so first we should try profiling to find what causes the issue then blame FPU. It's known to be slower than real hardware but maybe there are other things with bigger impact so those could be addressed too.

@balaton

https://github.com/AmigaPorts/SDL-1.2/tree/main/src/video/amigaos4

>You don't need to change any sources to disable FPU usage, simply >recompile everything with CFLAGS += -msoft-float.

EDIT: tried it compiling the renderer with softfloat
breaks the game completely.

I see. Yeah, would be worth a check. Obviously not for H2 release, *IF* it is faster that would require a QEmu-specific update for later (if it is faster probably a softfloat version of the renderer would be enough, maybe clienteffects still).

As to the SDL crash, anyone ever tried to insert debug output into the SDL compile to find out where inside SDL it crashes ?

@TheMagicSN
Quote:You can't mix hardfloat (default) with softfloat (-msoft-float compiled) code.
Either everything has to be compiled with the default hardfloat, for example using FPU registers for float/double function arguments and results, or everything has to be compiled with -msoft-float using integer registers for float/double function argument and results instead, incl. any libraries you may be using in your games.

I did not mix hardfloat and softfloat i know you
cannot mix them.

I compiled the complete renderer in softfloat.
Renderer is a full executable (dynamic object).

Note it did not break in obvious fpu calculations but
in the image cache somewhere.

@TheMagicSN
Quote:

It does not crash just produces garbled graphics with some SDL1 apps. What's strange is this only happens on pegasos2 not on amigaone but these two machines are very much the same on the QEMU side so there must be some difference on the guest side. When booting pegasos2 kernel with debuglevel=7 I've noticed these logs:

which are the first things printed after kernel starts so probably part of graphics.library or siliconmotion502.chip as the logs from the SM502 driver follow immediately. This looks like it could have something to do with the issue (as it goes away when using -cpu g3) but don't know where these logs are coming from or if they are present on amigaone. Maybe this is something that somebody interested to find this out could start from. Anybody knows more about what these logs are and where they are coming from?

With the mplayer version I had it actually crashed, not produced garbled graphics (but have seen the garbled effect too with other apps). -cpu=G3 had it crashfree then.

@balaton

this comes from graphics.library.kmod

https://ibb.co/7ztmvY9

@TheMagicSN

Quote:

https://ibb.co/7t4S8Lj


https://www.amigans.net/modules/newbb/ ... id=144284#forumpost144284

@balaton

Quote:

These lines also appear when using amigaone in qemu.