Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
57 user(s) are online (29 user(s) are browsing Forums)

Members: 2
Guests: 55

Antique, emeck, more...

Headlines

 
  Register To Post  

« 1 ... 67 68 69 (70) 71 72 »
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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?

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@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

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@balaton

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

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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:

-device virtio-gpu-gl-pci


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.

Resized Image

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

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Site Builder
Site Builder


See User information
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.
-device es1370,addr=0x08 \
    
-device rtl8139,addr=0x09,netdev=nic \
    
-netdev user,id=nic,hostname=pegasos-os4 \


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.

Follow me on
Ko-fi, Twitter, YouTube, Twitch
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@walkero

Quote:
So, what I did:

First of all at qemu command I use the following for the networks and audio devices.
-device es1370,addr=0x08 \
    
-device rtl8139,addr=0x09,netdev=nic \
    
-netdev user,id=nic,hostname=pegasos-os4 \




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.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Site Builder
Site Builder


See User information
@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.

Follow me on
Ko-fi, Twitter, YouTube, Twitch
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@walkero


Quote:

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 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

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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.

-device rtl8139,netdev=en0 -netdev user,id=en0


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

-device rtl8139,netdev=network01 -netdev vmnet-bridged,id=network01,ifname=en0


Edited by Maijestro on 2024/3/23 17:29:50
Edited by Maijestro on 2024/3/23 17:30:34
Edited by Maijestro on 2024/3/23 17:32:06
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
@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

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
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:
[_impl_InitCodeTesting module SmartFilesystem 1.290 (21.1.2011AmigaOS4 PPC (cJoerg Strohmayer <j_s@gmx.de>
[
_impl_InitCodeInitializing module SmartFilesystem 1.290 (21.1.2011AmigaOS4 PPC (cJoerg Strohmayer <j_s@gmx.de>
 [
_impl_InitResidentInitializing rom tag SmartFilesystem V1 (priority 79), init 0x014B3C20
[_impl_InitResidentInit function of SmartFilesystem V1 returned 0x6FF9F0C0
[_impl_AddTaskAdding Task 0x6FDF4620DH1/SmartFilesystem 1.290  (0x6FD58210)
[
RePostSignalReposting signals for task 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
[
RePostSignalDone reposting signals for task 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
# Then it stops running and other tasks are scheduled
[RePostSignalReady task is 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
[
RePostSignalReady task is 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
[
_impl_SetTaskPriChanging DH1/SmartFilesystem 1.290  priority to -10
# it's still there when modules are listed
[_impl_InitCodeTesting module SmartFilesystem 1.290 (21.1.2011AmigaOS4 PPC (cJoerg Strohmayer <j_s@gmx.de>
[
modulesinitModule Kickstart/SmartFilesystem
[RePostSignalReady task is 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
[
RePostSignalReady task is 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
# but then seems to just go away without any notice
[_impl_RemTaskRemoving 0x6FDF4620 (self) = DH1/SmartFilesystem 1.290 
[_impl_SuspendTaskSuspending self (DH1/SmartFilesystem 1.290 )
[
RePostSignalReady task is 0x6FDF4620 (DH1/SmartFilesystem 1.290 )
[
ReaperTaskTerminating task DH1/SmartFilesystem 1.290  (0x6FDF4620)

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:
[_impl_OpenResourceOpenResouceFileSystem.resource
[_impl_OpenResourceOpenResouceFileSystem.resource
[_impl_AddTaskAdding Task 0x6E488200DH1/SmartFilesystem 1.290  (0x6EC51A60)
[
_impl_AddTaskTask 0x6E488200ETask 0xFFF93C10Context 0xFFFAE7C0
[_impl_AddTaskStack bottom 0x6F1DF038Stack top 0x6F1E3024Stack pointer 0x6F1E2FF0
[_impl_AddTaskTask added to ready list
[
_impl_OpenResourceOpenResoucenewfilesystem.resource
[_impl_SetTaskPriChanging DH1/SmartFilesystem 1.290  priority to -10
[_impl_SetTaskPriChanging USB FD fkt start priority to -10
[_impl_RemTaskRemoving 0x6E488200 (self) = DH1/SmartFilesystem 1.290 
[_impl_SuspendTaskSuspending self (DH1/SmartFilesystem 1.290 )
[
_impl_RemTaskFreeing tracked resources
[_impl_RemTaskDone freeing resources
[_impl_RemTaskRemoving 0x6E488800 (self) = USB FD fkt start
[_impl_SuspendTaskSuspending self (USB FD fkt start)
[
_impl_RemTaskFreeing tracked resources
[_impl_RemTaskDone freeing resources
[_impl_SetTaskPriChanging USB Fkt Init priority to -10
[_impl_RemTaskRemoving 0x6E488B00 (self) = USB Fkt Init
[_impl_SuspendTaskSuspending self (USB Fkt Init)
[
_impl_RemTaskFreeing tracked resources
[_impl_RemTaskDone freeing resources

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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
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:
00009 : USB FD fkt start 0    FindSegmentStackSize("<untracked>") [13uS]
00010 USB FD fkt start o.k. = [execOpenDevice("usbsys.device",0,0x6E38AD60,0x00000000) = [99uS]
00011 USB FD fkt start o.k. = [execOpenLibrary("massstorage.usbfd",0) [84uS]
00012 massstorage.usbfd o.k. = [execOpenDevice("usbsys.device",0,0x6E38A6E0,0x00000000) = [109uS]
00013 massstorage.usbfd :        [execCloseDevice("usbsys.device") [18uS]
00014 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/DOSNAME",0x01F38FD0,32,0x00000000) [16313uS]
00015 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/CX_POPKEY",0x01F38FF0,128,0x00000000) [11931uS]
00016 DH1/SmartFilesystem 1.290  0    FindSegmentStackSize("<untracked>") [16uS]
00017 DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("dos.library",39) [40uS]
00018 : 
DH1/SmartFilesystem 1.290  FAIL = [execOpenResource("newfilesystem.resource") [13uS]
00019 : 
DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("expansion.library",51) [15uS]
00020 DH1/SmartFilesystem 1.290  :        [execCloseLibrary("expansion.library") [16uS]
00021 DH1/SmartFilesystem 1.290  :        [execCloseLibrary("dos.library") [23uS]
00022 Mounter Companion Process o.k. = MountDevice("DH1:",MDT_FileSystem,0x6F3E4E48) [44203uS]
00023 USB FD fkt start :        [execCloseLibrary("massstorage.usbfd") [23uS]
00024 USB FD fkt start :        [execCloseDevice("usbsys.device") [9uS]
00025 USB Fkt Init    :        [execCloseDevice("usbsys.device") [14uS]

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.

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just popping in
Just popping in


See User information
@balaton

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

Max Tretene, ACube Systems Srl, Soft3
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


See User information
On pegasos2 where it recognises the same USB driver with SFS I get:
00020 USB Fkt Init    o.k. = CreateNewProc("USB FD fkt start") [324uS]
00021 USB FD fkt start 0    FindSegmentStackSize("<untracked>") [10uS]
00022 USB FD fkt start o.k. = [execOpenDevice("usbsys.device",0,0x6E4B64E0,0x00000000) = [37uS]
00023 USB FD fkt start o.k. = [execOpenLibrary("massstorage.usbfd",0) [41uS]
00024 massstorage.usbfd o.k. = [execOpenDevice("usbsys.device",0,0x6E4B62A0,0x00000000) = [48uS]
00025 massstorage.usbfd :        [execCloseDevice("usbsys.device") [20uS]
00026 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/DOSNAME",0x02331B50,32,0x00000000) [919uS]
00027 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/CX_POPKEY",0x02331B70,128,0x00000000) [2629uS]
00028 : 
DH1/SmartFilesystem 1.290  0    FindSegmentStackSize("<untracked>") [7uS]
00029 : 
DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("dos.library",39) [17uS]
00030 DH1/SmartFilesystem 1.290  FAIL = [execOpenResource("newfilesystem.resource") [6uS]
00031 DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("expansion.library",51) [3uS]
00032 DH1/SmartFilesystem 1.290  :        [execCloseLibrary("expansion.library") [11uS]
00033 DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("intuition.library",39) [10uS]
00034 DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("utility.library",39) [3uS]
00035 DH1/SmartFilesystem 1.290  o.k. = [execOpenDevice("timer.device",1,0x6E1E6790,0x00000000) = [27uS]
00036 DH1/SmartFilesystem 1.290  o.k. = [execOpenDevice("timer.device",1,0x6E1E6760,0x00000000) = [13uS]
00037 ramlib          o.k. = [execFindResident("diskcache.library") [35uS]
00038 : 
ramlib          o.k. = [execOpenLibrary("newlib.library",3) [8uS]
00039 : 
DH1/SmartFilesystem 1.290  o.k. = [execOpenLibrary("diskcache.library",3) [172140uS]
00040 DH1/SmartFilesystem 1.290  o.k. = [execOpenDevice("usbdisk.device",0,0x6E1E67F0,0x00000000) = [40uS]
00041 DH1/SmartFilesystem 1.290  o.k. = [execOpenDevice("usbdisk.device",0,0x6E4873F0,0x00000000) = [18uS]
00042 DH1/SmartFilesystem 1.290  FAIL = [execFindPort("SFS DosList handler") [29uS]
00043 DH1/SmartFilesystem 1.290  o.k. = CreateNewProc("SFS DosList handler") [314uS]
00044 DH1/SmartFilesystem 1.290  FAIL = [execFindPort("SFS DosList handler") [7uS]
00045 SFS DosList handler 0    FindSegmentStackSize("<untracked>") [8uS]
00046 SFS DosList handler o.k. = [execOpenLibrary("dos.library",39) [12uS]
00047 SFS DosList handler FAIL = [execFindPort("SFS DosList handler") [6uS]
00048 : 
DH1/SmartFilesystem 1.290  o.k. = [execFindPort("SFS DosList handler") [9uS]
00049 : 
DH1/SmartFilesystem 1.290  o.k. = MakeDosEntry("

00050 : SFS DosList handler : o.k. = AddDosEntry("
Test")
00051 : DH1/SmartFilesystem 1.290  : o.k. = [exec] OpenDevice("
input.device",0,0x6E4872A0,0x00000000) = 0 [36uS]
00052 : DH1/SmartFilesystem 1.290  :        [exec] CloseDevice("
input.device") [4uS]
00053 : Mounter Companion Process : o.k. = MountDevice("
DH1:",MDT_FileSystem,0x6EF81E48) [307566uS]
00054 : USB FD fkt start :        [exec] CloseLibrary("
massstorage.usbfd") [19uS]
00055 : USB FD fkt start :        [exec] CloseDevice("
usbsys.device") [4uS]
00056 : USB Fkt Init    :        [exec] CloseDevice("
usbsys.device") [159uS]
00057 : USB Fkt Init    :        [exec] CloseDevice("
usbsys.device") [6uS]

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:
00001 USB Fkt Init    0    FindSegmentStackSize("<untracked>") [35uS]
00002 USB Fkt Init    o.k. = [execOpenDevice("usbsys.device",0,0x6DEE0B50,0x00000000) = [136uS]
00003 USB Fkt Init    FAIL Lock("PROGDIR:",SHARED) [47uS]
00004 USB Fkt Init    o.k. = Lock("LOCALE:",SHARED) [19731uS]
00005 USB Fkt Init    FAIL Open("LOCALE:Catalogs/english/sys/usbclasses.catalog",OLD) = [0x00000000] [5957uS]
00006 USB Fkt Init    FAIL Open("LOCALE:Catalogs/english_UTF-8/sys/usbclasses.catalog",OLD) = [0x00000000] [26235uS]
00007 USB Fkt Init    FAIL Open("LOCALE:Catalogs/english_US_ASCII/sys/usbclasses.catalog",OLD) = [0x00000000] [26573uS]
00008 : 
USB Fkt Init    o.k. = CreateNewProc("USB FD fkt start") [993uS]
00009 : 
USB FD fkt start 0    FindSegmentStackSize("<untracked>") [13uS]
00010 USB FD fkt start o.k. = [execOpenDevice("usbsys.device",0,0x6DEE06F0,0x00000000) = [93uS]
00011 USB FD fkt start o.k. = [execOpenLibrary("massstorage.usbfd",0) [86uS]
00012 massstorage.usbfd o.k. = [execOpenDevice("usbsys.device",0,0x6DEE0D50,0x00000000) = [191uS]
00013 massstorage.usbfd :        [execCloseDevice("usbsys.device") [18uS]
00014 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/DOSNAME",0x01F38FD0,32,0x00000000) [21212uS]
00015 massstorage.usbfd FAIL GetVar("USB/FD/MassStorage/CX_POPKEY",0x01F38FF0,128,0x00000000) [7537uS]
00016 DH1/SmartFilesystem 1.277  0    FindSegmentStackSize("<untracked>") [17uS]
00017 DH1/SmartFilesystem 1.277  o.k. = [execOpenLibrary("dos.library",39) [40uS]
00018 : 
DH1/SmartFilesystem 1.277  FAIL = [execOpenResource("newfilesystem.resource") [13uS]
00019 : 
DH1/SmartFilesystem 1.277  o.k. = [execOpenLibrary("expansion.library",51) [14uS]
00020 DH1/SmartFilesystem 1.277  :        [execCloseLibrary("expansion.library") [15uS]
00021 DH1/SmartFilesystem 1.277  :        [execCloseLibrary("dos.library") [7uS]
00022 Mounter Companion Process o.k. = MountDevice("DH1:",MDT_FileSystem,0x6FD7DE48) [46215uS]
00023 USB FD fkt start :        [execCloseLibrary("massstorage.usbfd") [24uS]
00024 USB FD fkt start :        [execCloseDevice("usbsys.device") [11uS]
00025 USB Fkt Init    :        [execCloseDevice("usbsys.device") [87uS]

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.


Edited by balaton on 2024/4/7 17:02:28
Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Not too shy to talk
Not too shy to talk


See User information
@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.

00001 Mounter         o.k. = [execOpenDevice("sii3112ide.device",0,0x6793C610,0x00000000) = [203uS]
00002 Mounter         o.k. = LockDosList(DEVICE|READ)
00003 Mounter         o.k. = FindDosEntry(,"DH0",DEVICE) = "DH0" [20uS]
00004 Mounter         o.k. = FindDosEntry(,"DH1",DEVICE) = "DH1" [36uS]
00005 Mounter         o.k. = FindDosEntry(,"DH2",DEVICE) = "DH2" [32uS]
00006 Mounter         :        UnLockDosList(DEVICE|READ)
00007 Mounter         o.k. = DismountDevice("DH1:",0x00000006,0)
00008 : 
Mounter         o.k. = [execOpenDevice("input.device",0,0x66F7D1E0,0x00000000) = [123uS]
00009 : 
Mounter         :        [execCloseDevice("input.device") [9uS]
00010 Mounter         o.k. = LockDosList(DEVICE|READ)
00011 Mounter         FAIL FindDosEntry(,"DH1",DEVICE) = "" [34uS]
00012 Mounter         :        UnLockDosList(DEVICE|READ)
00013 Mounter         o.k. = MakeDosEntry("DH1",0)
00014 Mounter         o.k. = [execOpenResource("FileSystem.resource") [22uS]
00015 Mounter         o.k. = AddDosEntry("DH1")
00016 DH1/SmartFilesystem 1.293  : -----> PRIVATEInternalRunCommand(""ARG:"")
00017 DH1/SmartFilesystem 1.293  1    GetSegListInfo(0x00702659 [""], ) [16uS]
00018 : 
DH1/SmartFilesystem 1.293  0    FindSegmentStackSize("") [55uS]
00019 : 
DH1/SmartFilesystem 1.293  1    GetSegListInfo(0x00702659 [""], ) [13uS]
00020 DH1/SmartFilesystem 1.293  o.k. = [execOpenLibrary("dos.library",39) [55uS]
00021 DH1/SmartFilesystem 1.293  o.k. = WaitPkt(0x00000000)
00022 DH1/SmartFilesystem 1.293  o.k. = [execOpenResource("newfilesystem.resource") [16uS]
00023 DH1/SmartFilesystem 1.293  o.k. = [execOpenLibrary("expansion.library",51) [26uS]
00024 DH1/SmartFilesystem 1.293  :        [execCloseLibrary("expansion.library") [6uS]
00025 DH1/SmartFilesystem 1.293  o.k. = ReplyPkt(0x676B5054,R1=0,R2=103) [ACTION_STARTUP 0] [23uS]
00026 DH1/SmartFilesystem 1.293  :        [execCloseLibrary("dos.library") [6uS]
00027 DH1/SmartFilesystem 1.293  : <----- PRIVATEInternalRunCommand(""ARG:"") = [103 (0x00000067)]
00028 : 
Mounter         FAIL DeviceProc("DH1:") [20169uS]
00029 : 
Mounter         o.k. = [execOpenDevice("input.device",0,0x66F7D0C0,0x00000000) = [115uS]
00030 Mounter         :        [execCloseDevice("input.device") [14uS]
00031 Mounter         :        [execCloseDevice("sii3112ide.device") [14uS]

Go to top
Re: What the fastest possible x64 emulation way of OS4 today ?
Just can't stay away
Just can't stay away


See User information
@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.

Go to top

  Register To Post
« 1 ... 67 68 69 (70) 71 72 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project