What the fastest possible x64 emulation way of OS4 today ?

@all

I have a quick question and I would be interested to know which sound card chip/driver offers the better sound experience under AmigaOs4.1 on real hardware. Is it sb128 or ac97?

In the AHI settings you can also organize the selection of channels, I'm currently using 32, but I'm not sure if the settings are correct as up to 129 channels can be set.

What is the difference here?

@All

QEMU 8.2.0 has been released and among the changes is the ability to use BBoot v0.5+ with the amigaone machine, removing the need for a u-boot bios image.

For Windows the downloadable installer is currently for 8.2.0-rc4, which will give you the same functionality apart from the bump in version number!

QEMU 8.2.0 source
QEMU Binaries for Windows (64 bit)
Instructions for Booting AmigaOS 4.1 on QEMU with BBoot

@derfs
Alternatively there are builds for Windows and macOS here as well:
Emaculation.com forum QEMU topic
Can somebody compare this with the weilnetz Windows build and check they work the same? The weilnetz builds have additional patches compared to QEMU master and was broken sometimes in the past so I used to recommend the Emaculation.com build but I'm not sure if there's a difference. I've asked this before but nobody bothered to reply so far.

@balaton

I have always used the weilnetz builds on windows and have never had an issue.

@all

smarkusg has worked a bit on Qemu and Virtio support and added them a long time ago and created a Qemu Mac M1 build that can access the native GL output of MacOs.

Unfortunately, there are no finished builds of Qemu under MacOs M1 that provide this support. I'm not even sure if there are any for Windows. On Linux it will be similar and support needs to be added.

It's not all that important at first since AmigaOs4.1 doesn't provide a driver for it. But what is interesting is that you add this line:



Qemu with Vitio support shows it as a new PCI device in SYSMon, showing that AmigaOs4.1 could handle it. Anyone who uses Qemu can check whether their Qemu build also provides this support. I'm no longer sure whether a driver will be made available for this at some time, but the possibility remains.



Big picture: https://i.ibb.co/jZNpCXy/Bildschirmfoto-2024-01-07-um-16-13-31.png

For a long time I had issues with network and audio on my emulated Pegasos 2 setup. As I have noticed that this is still mentioned at http://zero.eik.bme.hu/~balaton/qemu/amiga/aos_pegasos2.html as a known problem, I would like to share how I resolved it today.

Please excuse me if someone already mentioned that solution and I missed it. I also read the whole thread at the AmigaOneXE emulation and some stuff are mentioned there as well.

So, what I did:

First of all at qemu command I use the following for the networks and audio devices.


Have in mind that Pegasos has by default an AC97 audio card, which I am not sure if it can be removed. By using the es1370 like above, the emulated AmigaOS 4 recognises 2 audio cards. This one is a SB128. Having both of the cards, I had to go to Devs:AudioModes and remove everything except FILESAVE and SB128 files. After a reboot, I set in the AHI prefs the SB128 mode and then the sound was working fine.

Also, for the network I use the rtl8139 v53.4 which is mentioned many times by many people here that is the best working driver for Pegasos 2.

My qemu installation is v8.2.2 under Linux, as it is available on Manjaro repositories. What I mean by that is that I haven't done any specific compilation of it.

So, on my system, and based on my experience, the AC97 audio device brings conflicts with the network card on my system.

I wanted to share with you a resume of my experience in case it helps anyone in here. Again, I am sorry if someone mentioned all these, and I missed it somehow.

@walkero

Quote:

I have tested your configuration and it does not solve the network problems.

You can also reproduce it, I have tested it as follows from the Internet I have downloaded a large file 189MB and at the same time loaded data over SMB2 network from my host to the guest and the connection always breaks no matter with which audio driver or interrupt address with the Qemu Tap network or Apple Native VMNET Framework. Since both networks cannot be faulty TAP and VMNET I suspect it is a driver problem.

Currently I only see the solution that either the RTL1839 is adapted to Qemu/AmigaOs4.1, or someone writes a Virtio network driver for AmigaOs4.1, which in my opinion would be the better choice.

Thanks for the test anyway.

@Maijestro
I agree with you that a Virtio-net driver would be the best solution. As I explained in my post, this is what I did and seems to work on my system. This might not work for everyone because it seems to be influenced by many things, and a lot of software is involved.

It might even stop working for me in the following days, but yesterday I tried playing streaming radio in AmigaAmp from a very specific station, while I was using Odyssey, and that worked fine. Before those changes, even only streaming the radio was breaking the network in less than a minute.

I wanted to share it, in case this is helpful for someone.

@walkero


Quote:

I see what you mean, it's similar here, sometimes I can stream IMP3 chat and mods or watch Odyssey/YouTube for up to 1 hour, but as soon as the network is heavily loaded, upload/download/SMB/FTP server connections always drop within minutes, you should test that.

Another quick example, the Sam460 machine does not use Ac97 and yet the network breaks down just like the AmigaOneXe/Pegasos2 machine. This can't be a coincidence.

Believe me, I have really tested everything, because I use AmigaOs4.1 daily and the interrupted connection bothers me a lot.

Do we have a way to debug the network under AmigaOs4.1?

There is someone on Os4Welt who wants to look into the network problem and maybe we will be lucky that either a Virtio network driver will be written or the RTL8139 will be made more compatible with Qemu/AmigaOs4.1. I'm keeping my fingers crossed that something will come of it

@walkero

Amiga-News has reported about your "Workround", at the moment there seem to be only problems under Linux and MacOs. Under Windows the network seems to run stable and there are no packet losses when pinging.....strangely

Edit: Currently I use this line with ac97 is relatively stable download streaming with Mediavault works and only very rarely does the network fail. But when FTP/SMB2 connections are added it breaks down within 2-3 minutes.



When using VMNET it is sometimes even worse here the network already breaks during download and streaming with Mediavault

@all

I just wanted to point out that I started the virtual RTL8139 driver under Qemu with debug output and recorded the debug output. This is the internal Qemu RTL8139 driver and not the AmigaOs4.1 driver because it cannot be debugged.

Under AmigaOs4.1 I used the RTL8139 version 53.4 and 53.6 and recorded every session of this driver with the logs until I lost the whole internet/network connection.

Maybe someone would like to take a closer look or can help with tips, maybe it shows something that is missing in the virtual RTL8139 driver that the real driver of AmigaOs4.1 driver does not expect. It is also possible that these protocols show nothing at all why the connection breaks. If you compare the two logs you can see that the AmigaOs4.1 RTL8139 driver version 53.6 loses the connection much earlier than version 53.4.

What we already know is that the virtual Qemu driver uses C+, but we don't know for sure if the AmigaOs4.1 real driver uses it and therefore there are problems.

AmigaOs4.1 RTL8139 version 53.4: https://www.mediafire.com/file/k3aedmr ... L8139Version53.4.txt/file

AmigaOs4.1 RTL8139 version 53.6: https://www.mediafire.com/file/mhb1qic ... L8139Version53.6.txt/file

@walkero

On Os4Welt the user "Cyborg" was so kind and adapted the RTL8139 driver 53.6 for Qemu, you should also test this driver under Linux, I hope this will solve your problems with the network.

I have already tested this driver under Mac Qemu/Pegasos2 AmigaOs4.1 and for the first time I have an absolutely stable internet connection. I just wanted to let you know.

Source: https://www.os4welt.de/viewtopic.php?t=2749&start=200

I have tried to find out why SFS does not work on QEMU sam460ex but since it does not log any error it's hard to see what happens. I've tried booting with debug kernel and logging enabled and it seems that SFS starts. (During startup it seems to look for PCI bridge to determine what system it's running on. It checks Mai Logic Articia S for amigaone, the bridge in 460EX for sam460 and a Pericom bridge that I don't know which system uses.) It seems a task for the volume is added but then after some other tasks are run it just exits for unknown reason. That's all I could find out and don't know how to debug this further. A shortened log excerpt is:

Does anybody know what the above mean and how it could be traced to find out why it stops? This was during boot, maybe I should try attaching a disk with an SFS partition after boot and see if it could be traced better that way but I don't know how to debug these under AmigaOS and don't have suitable setup for that so it's more work than I'm willing to do now.

It does the same when attaching the disk as usb-storage after boot:

so it seems to exit for some reason when trying to detect a volume but it does not tell why. At least the kernel module seems to be loaded and "working" but it cannot handle volumes.

So when a USB disk with an SFS partition is attached an SFS task is spawned but then it seems to exit. How to trace what it tries to do? Is there an strace equivalent? Something like SnoopDOS but maybe that only traces DOS calls and not what SFS calls at that point. If we can identify where SFS stops maybe we can find what's missing or different on emulated sam460ex which breaks it but I don't know how to do that under AmigaOS.
The kernel logs don't give enough info and using higher log levels generate too many unrelated logs that obscure the SFS task logs.

@balaton

I guess Snoopy would be the logical tool under OS4.

http://os4depot.net/?function=showfil ... ility/filetool/snoopy.lha

You can customize (via the menu) which function calls you want traced and which not.

Best regards,

Niels

Yes, I've also found that on AOS4 one should use Snoopy instead of SnoopDOS I've tried to get some logs of attaching a USB drive with an SFS filesystem on it:

There's a FAIL while trying to open newfilesystem.resource but it still goes a bit further checking PCI bridges and exits somewhere after that. Without knowing what it tries to do it's hard to tell so I hope @joerg can remember something or check it and give some hints otherwise I'd need to do more experimenting. Also I'm not sure what else to enable in Snoopy to get more useful logs.

@balaton

There is a Pericom 8150B PCI Bridge on Sam440ep mini-itx and flex boards, maybe it's testing it ?

On pegasos2 where it recognises the same USB driver with SFS I get:

Maybe this gives @joerg or sombody else an idea at what point it could fail so we can check that further.

Edit: SFS version 1.277 from Aminet seems to only search for amigone PCI bridge so it does not seem to have sam specific code but still exits the same as above:

So maybe it has nothing to do with sam specific parts but something in generic code does not behave on emulated PPC440 than on real machine? As there's no crash report or any error given I have no idea how to find where it stops.

@balaton

Here is my output when using mounter to try and mount DH1: in QEMU.

DH1: is a SFS partition on the same drive as the FFS boot partition.

Hopefully this can add extra data to point people to the issue.

@balaton
No idea what the problem could be, and currently I neither have the time nor motivation (since it works on real hardware) to create a debug version to find out why it fails on QEmu.
Just some notes about the logs:
- Old versions of SFS and/or diskcache.library, for example the one on Aminet, included at least 3 different bcopy/memcpy/memmove() and bzero() implementations I did for the different CPUs, for example on G2+G3 CPUs it used the data cache instructions (DCBA where available, DCBZ as replacement on the other CPUs, DCBT and DCBTST), on G4 the AltiVec streaming instructions, and something different on 440/460 I don't remember any more (but obviously not in the Aminet version yet because it doesn't check for a Sam4x0).
The reason for the hardware checks was to determine which implementation of the bcopy() and bzero() functions should be used on the current hardware. Some of my optimized bcopy() and bzero() functions were added to newlib.library, and later moved into the kernel (IExec->CopyMem[Quick](), IUtility->SetMem(), etc.). Other developers contributed optimized functions for other systems, IIRC my AltiVec code was replaced by a better implementation from another developer, and the Sam4x0 kernels use the DMA engine of the SoC for very large copies instead.
Current SFS versions (Enhancer Software) don't include those CPU specific functions any more but use the kernel functions instead, which should (not sure about X1000, X5000 and A1222) now include different code optimized for each of the supported systems, and I probably just forgot to remove the, now useless, hardware checks.
I don't remember if version 1.290 still included my system specific functions, or already used the kernel functions.
- IIRC newfilesystem.resource is created by SFS or JXFS when the first SFS or JXFS partition is mounted and has patched some exec.library and dos.library functions (IDOS->DoPkt(), IDOS->SendPkt(), IExec->PutMsg(), etc.) to add my FS API to it (basically still the old AmigaOS 0.x-3.9 one, but avoiding up to thousands of task switches per second by executing most of the filesystem code in the task of the caller instead of sending messages to the filesystem task doing the work and sending a message to the calling task with the result again, resulting in huge speed improvements).
If newfilesystem.resource is there already the dos.library patching is skipped.