@balaton No doesn't work either unfortunately. Font is getting scrambled again when going into windowed mode and switching to windows and back to AOS4.
And as mentioned earler: When staying in SDL fullscreen (without gl=on) as well when using GTK everything also looks fine.
@Reth If it works with gtk why don't you use that? Does it unscramble when switching back to full-screen? So only shows problem in window or stays like that even after going back to full screen? What if you resize the window? The problem is probably that SDL does not handle scaling to 0.99% or just a few pixels less too well. I don't know SDL, maybe there are people here who know it and know about something that can be set for it to use better scaling algorithm.
Unfortunately it does not descramble when switching back to fullscreen. Resizing I need to check still. But with GL=on it seems sometimes it does. But with GL=on I got freezes for some seconds every ~30s, so I removed it.
GTK I did not yet use since I read somewhere it would be less performant. And I struggled with mouse pointer handling there. But will switch to it.
Update: Seems GTK has issues when using different screen resolutions while in full screen. E.g. running WB in 1920x1080 and opening an 1024x768 screen => after closing that screen WB stays in the lower resolution until switching to Window mode.
Update: Seems GTK has issues when using different screen resolutions while in full screen. E.g. running WB in 1920x1080 and opening an 1024x768 screen => after closing that screen WB stays in the lower resolution until switching to Window mode.
Does the zoom-to-fit option has an effect on that? You probably won't notice a performance difference with gtk. SDL is nice but if it does not work then not many other options left. I've heard some people had problem with mouse on Windows with gtk. Adding -device usb-mouse may fix that, if not a better option is -device usb-tablet but that needs a driver in AmigaOS which I think was posted somewhere here a while back but I don't remember when and where.
If all else fails QEMU also has a built in VNC server so you can view it with a VNC client. No need to run VNC server in the guest but that may not be very convenient so try when exhausted all other options. You can check with -display help which display backends are available in your build.
You could also try setting lower resolution in guest and use it in a window to avoid scaling.
If you're using “-device usb-storage” in QEMU (a QEMU VVFAT drive) but find the data transfer speed too slow, you can try adding a USB controller (-device pci-ohci). All you need to do is connect the usb-storage device to the pci-ohci controller. The drive may take a moment to appear in the system (in my case, it needs to be properly recognized), but the data transfer speeds alone should make it worth it. Here is my sample command line:
@smarkusg Why is that faster? Is it because OHCI needs less guest code or has better driver or something else? What if you use usb-ehci instead of pci-ohci? QEMU also has nec-usb-xhci that should emulate an NEC USB3 controller (or qemu-xhci which is almost the same but AmigaOS driver may not recognise that).
@balaton nec-usb-xhci doesn't work because AOS4 doesn't support xhci (I checked, it doesn't work) usb-ehci was faster than uhci but about half as fast as ohci. With ohci, reading was fast but writing was like uhci, but... writing to usb-storage isn't recommended, so this test might not be reliable. If you want, I can check under QEMU Linux PPC for the PEG2 system to see how things look there.
If you want, I can check under QEMU Linux PPC for the PEG2 system to see how things look there.
I was just curious what causes it to be faster. You don't have to check anything, only if you want to. As OHCI does more in the controller it's possible it's faster because less guest code or register access is needed but could also be that the AmigaOS driver for the different USB interfaces are different. OHCI emulation is less used though so more likely to have bugs and missing parts.
@joerg Which hardware would that be? There seems to be no xhci.usbhcd even in updates, only uhci, ehci and ohci. These were updated in FEUpdate3 so if there was an xhci driver I think it would be there. Maybe geennaam has an xhci driver that will be provided for Mirari but not available otherwise?
@joerg Yes it doesn't seem anything came out of that. I've found this: https://github.com/rondoval/emu68-xhci-driver Which is: 1. quite new, 2. does not work, 3. for different USB stack. I could not find any xhci driver for AmigaOS 4.
@balaton Ooooooooo !!!! Awesome, thanks 32-bit -:D I increased the memory a bit “- -device ati-vga,model=rv100,guest_hwcursor=on,vgamem_mb=128”
Here's a quick test on Apple M4 (game mode) and an old QEMU build (8.2.50) It looks like it works fine too. There’s an issue with the boot screen (also occurs with QEMU-11). I think it’s the mouse pointer? A quick test with sdl2benchmark and a not-very-reliable test using the machine’s speed system video - > https://youtu.be/RHCimfhzq-k https://zero.eik.bme.hu/~balaton/qemu/ ... ti-vga-driver-latest.html
I also checked out the QEMU-3Dfx-Voodoo-3-Port by Falke_34 It’s a bit slow but it works (only 24-bit). I think the speed issue here is that it relies on the driver from the 86Box. Within QEMU, it uses resources from the emulation. If it could be done in a thread outside of QEMU (separate threads in the system across multiple cores), it would run fast. Bravo, A-EON . I guess soon you’ll be using Virtio GPU 2D for AOS4 yourselves. It won’t be needed.
Edited by smarkusg on 2026/4/22 21:53:56 Edited by smarkusg on 2026/4/22 21:55:35
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
. I guess soon you’ll be using Virtio GPU 2D for AOS4 yourselves. It won’t be needed.