Looks like using -cpu 7447 (or another one that AmigaOS recognises) enables Altivec which is disabled with the defaulr 7400 cpu (despite that also would support it). This suggests the problem may be with emulating one of the Altivec instructions. Question is which one as there are many and I don't know what to look for. Your testing with different QEMU versions shows that this is not something that broke recently thus unfortunately we can't do git bisect to find it. So more testing is needed to narrow down with which apps this is happening and what are the common Altivec operations those use. I don't have a better idea to find this. Maybe if there exist some Altivec test suite that could be tried under Linux guest or MacOS on mac99 with this cpu setting that could be helpful. Or hope that testing will be done later as I've seen some talks about that on the qemu-ppc list. In summary, until we sonehow identify which Altivec op is failing we can't do much about this.
There's also an unmerged patch on qemu list here:
that fixed one Altivec/VMX instruction but I think that's only relevant for PPC64. But ir references a QEMU ticket:
https://gitlab.com/qemu-project/qemu/-/issues/1536
which talks about some VMX test suito so it that can be run it may find the instruction with the bug. Sombody would look at that thogh,
Patch in above comment does not seem to help.
Here's video showing the problem.
I wonder if this can be specific to ARM host as both reports were from Apple silicon Macs so far.
Sorry, the bug was filed saying it happens on x86_64 which I've missd but now it's also confirmed on ARM and x86_64 again so it's not host CPU specific. One game that can easily reproduce it is Super Maryo Chronicles which uses SDL. I wonder if it depends on screen depth but this game only seems to run in 16 bit, it opens new screen when started from 8 bit mode. Maybe could be tested on MorphOS which also supports 24 bit mode.
Not sure I've found the same SDL sources that the game uses but the one I've found seems to use these Alrivec calls: vec_add, vec_and, vec_cmpeq, vec_dss, vec_dstst, vec_dstt, vec_ld, vec_lvsl, vec_or, vec_packpx, vec_perm, vec_sel, vec_sl, vec_splat, vec_st so problem may be with one of these. Since Altivec generally works, I'd expect the more common ones to be OK so maybe one of the rarely used ones like packpx are more suspect.
There seems to be some tests for some of these in gcc sources but I don't know how to run those.
After more testing now I'm not sure if this could be a bug in SDL itself and not in emulation. Some problems could be reproduced on real hardware as well and those seem to be corrected in newer SDL versions. The Super Maryo Chronicles game does not show issue on real hardware but that may be related to the display driver and can be worked around by setting 32 bpp in game options.
The intro videos in Freespace also show this problem with the 7447 CPU. With G3 they play correctly.
This may be an issue in SDL which has some problems with 16 bit modes when using Altivec as suggested by discussions elsewhere such as here: https://www.amigans.net/modules/newbb/viewtopic.php?post_id=140752 So if Freescape uses SDL then maybe try to update that if possible.
Fork
Problem with SDL graphics with cpu 7447 AmigaOS 4.x
The problem lies in the wrong graphics display. See attached screenshot.
There appear to be shadows and fine lines on the screen. The problem does not occur in emulation of the "G3" processor and the default one emulated by qemu. The problem occurs in random applications
*Tested application: - MickJT-MPlayer
- RunInUAE r8 beta 6 (e-uae-sdl included)
*Tested major versions on machine: x86_64 with linux:
- qemu-system-ppc-6.2.0
- qemu-system-ppc-7.0.0-rc0
- qemu-system-ppc-7.2.0
- qemu-system-ppc-8.0.0-rc4
ARM64 Apple M1 - qemu-system-ppc-7.2.0
- qemu-system-ppc-8.0.0-rc4
*Tested AOS4: - Amiga OS 4.1 FE
- Amiga OS 4.1 FE Upadate1
- Amiga OS 4.1 FE Update 2
*Graphics drivers (currently only QEMU SM501 Device is emulated for AOS)
- AOS 4.1 FE siliconmotion502.chip
* Still to be checked: