What the fastest possible x64 emulation way of OS4 today ?

@Reth

Quote:

For the Display Manager GTK you can use “-display gtk,zoom-to-fit=on” this will solve your problems.

You can also tell Qemu to switch the machine to full screen on startup. I do this myself when I use Qemu because I don't want to see everything that happens in the background.

."-display gtk,zoom-to-fit=on –full-screen"

Unfortunately now I am getting another error when trying to copy files to the exchange directory to have them in windows:



Next to that it seems whatever I copy into the share drive from AOS4 side does not occur on Windows side anymore.

Any idea what might be wrong here?

@Reth

For this I would need to know the line you passed to Qemu and where the share folder is located under Windows.

Otherwise there is a first class tool called WormHole, I haven't tested it myself under Qemu because I use SMB2 for file transfer which works fine.

WormHole has to be started under AmigaOs4.1 and of course under Windows, if it works you have a very fast way to transfer data. Unfortunately Wormhole cannot handle several files at the same time, so it is best to pack everything beforehand.

Here you can get some information about WormHole

https://www.amigans.net/modules/newbb/viewtopic.php?post_id=153599

@Reth
You have too much of something in the shared folder. It's not meant to be used as a general file exchange just a way to quickly share a few files such as updates for install or setup files. For copying large amount of data use a network share, ftp, scp or something like that.

IC. Thank you. So far it worked fine so I thought it might be usable like a normal folder. After that problems it never worked again - even after a restart of QEmu which is really strange.

I can use FTP as a workaround though.

@Reth
That it's not working even after QEMU restart should not happen. Maybe something broke in the folder you're sharing. If you can still reproduce it and can run QEMU under debugger (which needs gdb on the host): just adding gdb --args before the qemu-system-ppc command then enter run from (gdb) then you could get a backtrace with bt after it stops on the assert to see where exactly it's failing. That could be reported on the QEMU list, bugtracker or at least here. QEMU should at least give a better error than just the failed assert but it may be hard to check everything that's why the assert is there.

@Reth

Quote:

The UFAT share folder is limited to 500 MB, I think that will be the reason why you can't use it with Qemu anymore. Delete the content once and try again.

As Balaton already wrote, the share folder is not recommended for data transfer, it should only be used to easily copy the kickstart directory from the guest to the host.

The size limit was not reached yet - but maybe it has a file number limit. I deleted all files within that folder on both sides and now it is working again. And it does not seem to like .zip files.

Thanks for all your helps.

Unfortunately AOS4.1FE seems still to suffer from lots of freezes though - with usage of Codebench and without, especially when writing to the exchange USB drive. I can reliably reproduce complete QEmu crashes with a certain sequence of accesses.

@Reth
If you can reproduce a QEMU crash getting a backtrace by running QEMU under gdb and get the backtrace when the assert fires and reporting that to QEMU would help or at least file a ticket with how to reproduce (it if it's not specific to AOS4 as people won't be able to try that only if it can be reproduced with more commonly available guests).

Not sure whether it can reproduced otherwise since it incorporates accessing the USB exchange from AOS4 side.

@themamboman
Reply from the topic “VFIO passthrough results”.
https://www.amigans.net/modules/newbb/ ... id=154385#forumpost154385

Quote:

I'll have to check, I used to compile under completely different things u-boot-sam460-2015c under QEMU for my own needs.
Uboot works under QEMU but was never checked for GPU passthrough.
ACube is an exception in the AOS4 world where it makes the u-boot source available (according to the licence).

I'll let you know. For now I am testing and looking for problems with amigaone GPU passthrough ok ?

I have updated and reorganised my pages at qmiga.codeberg.page to make it easier to follow and navigate and also added a page on VFIO passthrough (that I'm sure will need to be updated later but it's a good start). Maybe you can find some answers there to some questions.
QEMU 10.0.0 now tagged, binaries will be updated in a few days and announced but if you already have rc4 it's the same except the version number.

Ok, meanwhile I tried different settings and parameters. So result is when being on SDL even after starting in full screen - as soon as I switch to windowed mode (e.g. to be able to get to another Windows Program) the output in some windows on AOS4 gets scrambled.

Here an example of the compilation output window of Codebench:

@Reth
What QEMU version are you using and where did you get it from? What qemu options do you use?

@balaton
Quote:
Thanks a bunch ! Your guide about VFIO passthrough more than enough to start for sure. After reading it want to make some best-possible os4 emulator by taking Ryzen 7 9800X3D, which is 4.7GHZ base freq for single core, mean pretty good emulation speed for os4, and then will put RadeonRX in to have a passthrough with. It probably still can't beat my x5000, but should be something good enough.

@themamboman
Quote:

I did a quick check.
It looks like something is working in QEMU SAM. Uboot initialises my Radeon HD.
I think @Balaton wrote that SAM emulation doesn't support PCI Express. Maybe as a regular PCI it is somehow recognised.
There's also a bug with BAR.
I don't have much time to set up a test system.

here a video - > https://youtu.be/CHzspuWMgog

@kas1e
There are still a lot to be understood about this so it's not guaranteed that getting the fastest machine and GPU will result in fastest emulation. But you and Hans could better find out more about it if you test it and hopefully we'll also see the results of that at one point. Fixes can be sent to QEMU too, contribution is open. Currently it seems RadeonHD 7000 (and similar era) cards may be the best option and if older cards work those may also be interesting but that's untested yet. With RadeonRX there might be more problems but let us know if you try if that works too.

@smarkusg
With the firmware included in QEMU this could be a problem:
u-boot-sam460ex/board/ACube/Sam460ex/init_radeon.c line 216

In newer versions this is moved to board/ACube/common/init_radeon.c and changed a bit but still has onbus < 2 and seems to expect a bridge in that case and looks at BAR1 instead of BAR4 which can be a problem if the card does not have the expected BARs.

So I think it won't work with the default old firmware in QEMU with newer RadeonHD that has 64bit BARs. Updated U-Boot may be better but I did not check it and not sure it's prepared to handle a RadeonHD on PCI, only if it appears behind a bridge which was probably added for Sam440. I intend to update the sam460ex firmware in QEMU at one point mainly to fix the USB issue and could also improve PCIe emulation to make that work but it's some work I had no time to finish yet.

(I've only left the old firmware in QEMU because that's what I started with and it worked and I did not update later because aCube sold the binary and I did not want people to try to get it from QEMU instead which may not work on real machine as it had additional patches and would spoil aCube's business. While I think software should be free I also respect those who respect the rules and contribute back.)

@balaton

I downloaded it from here: https://qemu.weilnetz.de/w64/2025/qemu-w64-setup-20250416.exe

Parameters are:

qemu-system-ppc -M pegasos2 -m 2048M -accel tcg ^
-kernel bboot/bboot -initrd Kickstart.zip ^
-rtc base=localtime ^
-cpu 7447 ^
-vga none ^
-device sm501 ^
-device rtl8139,netdev=net0 -netdev user,id=net0 ^
-drive if=none,id=hd,file=hdf/hd.img,format=raw -device ide-hd,drive=hd,bus=ide.0 ^
-drive file=fat:rw:Exchange,id=ufat,format=raw,if=none -device usb-storage,drive=ufat ^
-cdrom isos/Peg2_AOS4.1FE.iso ^
-boot order=c ^
-display sdl,full-screen=on ^
-serial stdio

@Reth
Why do you have -cpu 7447 and -boot order=c in that command? It's not related to the issue but -boot does nothing and -cpu likely not needed either.

We have already discussed that default scaling of SDL may not be too accurate. Does it work better with -display sdl,gl=on,full-screen=on ?