Hans wrote:@Maijestro Following up on this, the problem is that the emulated hardware is an SM501, which is limited to 16-bit colour output. We're lucky that the SM502 driver can handle the SM501, or it wouldn't work at all. We could get 32-bit if the SM502 were emulated instead.
This is of course very interesting and I was wondering why everyone talks about "sm502" but qemu uses the line "sm501". Since this driver already works, maybe we could add the missing part of the 32 bit output. sm501/2 should be very similar and the adjustments would certainly be done with little effort. Is there any documentation for this chipset?
You can find the written driver under: "Qemu/hw/display/sm501.c" Should you want to have a look at it.
Quote:
there any settings that you guys use for better performance? Or have things improved in the latest betas? I'm using the latest stable release (8.0.0.0).
Normally, Qemu 8 Final should work very well. Of course, the decisive factor is your hardware, the faster the better.
I'm currently using a Qemu 8.0 custom build where a ppc-hardfloat-fpu patch is included which makes the FPU emulation even faster. I could provide the build with the patches, but it has to be compiled by yourself.
Zoltan BALATON has also submitted a new "bitops" patch that will increase the FPU emulation, with luck this change will be available in Qemu 8.1.
On which hardware do you use Qemu?
I don't even dare to ask since you are developing under AmigaOs4.1, you have set up the installation under SFS?
Maybe you could also post your startup line of Qemu just so we can match it. Probably it is due to your hardware being a bit too weak.
@white is running Qemu on a Ryzen 5800x @smarkusg uses a MacMini M1 for it
My hardware is below in the signature
lg Rene
Edited by Maijestro on 2023/5/23 10:23:37 Edited by Maijestro on 2023/5/23 11:24:52
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Following up on this, the problem is that the emulated hardware is an SM501, which is limited to 16-bit colour output. We're lucky that the SM502 driver can handle the SM501, or it wouldn't work at all. We could get 32-bit if the SM502 were emulated instead.
The SM502 driver under AmigaOS4.1 is limited to 16-bit since its 32-bit mode AFAIK isn't support by graphics.library. The chip uses 4 bytes, 3 bytes for RGB, and the last byte isn't used at all. From my tests, AOS4.1 support 24-bit modes (3 bytes) or 32-bit modes (4 bytes with alpha) but not 32-bit modes without alpha. The result is that trasparency doesn't work.
I wasn't aware of that. So the SM502's blitter won't copy or use the alpha channel? That's a weird thing to do.
The chip uses a different 16-bit layer for alpha. Maybe these is a way to implemet some sort of alpha support compatible with graphic.library...
Anyway, I've a new driver version which, on real hardware (not emulated) greatly improve CPU and DMA trasfer speed.
Thanks for the valuable information, that explains a lot. Under the Qemu Pegasos 2 emulation we also tested MorphOs with the sm501 driver and there were 24 bit screens available, apparently this driver is supported a bit better there.
It confirms that the emulation of the sm501/2 works correctly and the limitations come from the guest system, in our case from the Graphic.library used by AmigaOs 4.1 which does not fully support this driver.
Your updated sm502 driver could also improve the AmigaOs4.1 Pegasos 2 emulation under certain circumstances.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@walkero >I will continue searching for a solution. I am glad that emulated OS4 environments are getting better and better.
If you are still having stability problems with your network connection, you may want to try one more thing. You may be running Amiga OS 4.1 (2008). There is a rt8139 network card driver on the board.
Now ATTENTION - the driver works only with static IP address setting!!!
You must change the IP settings from dhcpd to a static address before swapping. Check on the current driver the changes you have made and backup the old rtl8139 driver.
ip: 10.0.2.15 netmask: 255.255.255.0 gateway: 10.0.2.2 dns: 10.0.2.3 or any other you prefer (local ip-hole,open dns,google etc)
If everything works correctly - now replace the driver and do a hard reset of the Amiga. The driver is stable, but this is one of the last things you should do if you have problems with the stability of the network connection.
You may also change the network card settings in AOS itself by changing environment variables.
example
setenv save rtl8139.device/unit0 "VenderID=0x10EC DeviceID=0x8139 10Base-TX FullHalf NOFLOWCONTROL"
or
setenv save rtl8139.device/unit0 "VenderID=0x10EC DeviceID=0x8139 100Base-TX FullDuplex FLOWCONTROL"
It won't reach the nivou of your AmigaOne x5000, but the speed should still be noticeably better compared to WinUae and AmigaOs4.1 Classic under your hardware.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Thanks for the valuable information, that explains a lot. Under the Qemu Pegasos 2 emulation we also tested MorphOs with the sm501 driver and there were 24 bit screens available, apparently this driver is supported a bit better there.
Using a basic 32-bit screen isn't an issue. The problem is that hardware accelerated compositing cannot be implemented without large workarounds (e.g., copying the alpha channel to a separate alpha map). It should work okay without compositing effects, though.
Quote:
Under which system are you using Qemu since you have no window output assigned. Qemu supports:
-display sdl -display gtk -display cocoa (only available on MacOs)
It defaults to GTK. However, switching to SDL does nothing performance wise. Everything is still sluggish compared to what I'm used to. This includes loading the kickstart modules, booting, loading programs (especially anything using Qt), etc.
Quote:
You can also allocate more memory with:
-m 1024
Thanks.
Are there any easy CPU benchmarks that could be used to compare with real hardware? I'd be interested in how raw CPU performance compares to the Pegasos II (amongst others).
You could try using this libshine encoder for testing https://github.com/toots/shine The author of the Qmiga project suggested in a corenspondation , that you can just use this encoder to check the raw CPU speed .
If you don't want to compile it a couple of posts above is ffmpeg with this encoder. Here you would have to thank MickJT in general . Mostly he posts a detailed description with armpits for his compilations . Bravo and thanks !!!
Regarding your emulation hardware. I also have a laptop not new on x86. The emulation on the Appple M1 is much faster. It no longer compares the comfort of the work. Everyone knows the differences between ARM and x86 - silence , no heat, energy saving etc. x86 has its advantages and the use of ARM has its advantages. I personally am waiting for Linux kernel development on Apple Mx and a well polished distribution to fully migrate to ARM.
As for emulation and Amiga itself. I am not an expert on the subject but from what I understand a single core is used. In this case I on my Apple M1 and @Maijestro's MacStudio M1 the emulation speed will be the same. His hardware is faster overall but emulation will not take advantage of that.
Are there any easy CPU benchmarks that could be used to compare with real hardware? I'd be interested in how raw CPU performance compares to the Pegasos II (amongst others).
Hans
You could use this bench it contains several tools that directly access the cpu under the emulation and real hardware.
As @smarkusg mentioned, it currently runs really well on Mac with M1 chipset, apparently the ARM cpu is perfectly suited to handle the emulation. I have made a short video from the complete kernel boot process to the AmigaOs4.1 workbench.
And the Sortbench via SysMon, since it probably also directly accesses the CPU.
I would be interested in your benchmarks that you perform directly under the emulation to be able to determine the percentage difference between the CPUs.
I don't want to offend anyone here it's mainly about AmigaOs4.1 and not about the emulation, if you feel bothered by me just let me know and I'll stop.
AmigaOs4.1 gives me a lot of pleasure and what I tried to convey is that it can work well under certain circumstances and with the right hardware (even if limited).
Greetings
Edited by Maijestro on 2023/5/24 10:45:27
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I guess the JIT compiler is taking advantage of BI endian instruction set, pretty impressive, but not unexpected, considering the insane benchmarks seen on emu68k / r-pi’s
Native M1/M2 support be better, but its going to be lot of more work. anyhow think it’s better if focus on SMP, and ignore all the CPU options for now.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
It should. Search for "KVM" on this page, and you'll see that it's been used in KVM mode on a T2080.
For me it looks like a bit of surprise that there wasn't anyone who tried to use QEMU with KVM on something like PowerMac G5, just to see if it indeed works. Because if KVM works already for peg2 emulation, then you may have cheap "kind of x5000 just without gfx normal card" for 100-200$.
Maybe it still has some issue with KVM and os4 emulation ? Or just no one tried ?
As far as I understand, the KVM based virtual machine uses the CPU directly. This means that the kernel must be able to handle the specific CPU of the host. And I doubt that ExecSG "speaks" e6500, PPC970 or POWER9 yet.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
