Okay, finally solved with Mountlist mentioned above, everything worked. Now AROS One Hosted can display all media “CD-DVD-PenDrive.” The empty folder was because the volumes contained many files and you have to wait.

In the screenshot, you can see the 3 Shared items, DVD, Pendrive, and Windows Sharing!

With AROS One 64Bit and the Mountlists posted above today, I managed to mount both the DVD and the Perndrive, but I can only see the folders! No files!, see screenshot

I took inspiration from a working Mountlist posted by Mazze, see Link

My question is whether this Mountlist only works on native Linux, and does not work if installed on VMware !


https://ae.aroswo...pic=971.15

I don't know if emul.handler can mount any host directory or it just mounts the "main" AROS directory as System:.

@deadwood

I am trying to mount a CD/DVD on AROS One Hosted Linux (Linux installed on VMware). This is the mount list. What is wrong with it?

FileSystem = emul-handler
Device = CDX:/Media/amigasystem
LowCyl = 0
HighCyl = 0
Surfaces = 1
BlocksPerTrack = 1
DOSType = 0x454D5500
Activate = 1

I also tried changing the path:

FileSystem = emul-handler
Device = CDX:/Media
LowCyl = 0
HighCyl = 0
Surfaces = 1
BlocksPerTrack = 1
DOSType = 0x454D5500
Activate = 1


CDX=Name Volume on Wanderer

Path CD/DVD:
/media/amigasystem/AROS Live CD/

Btw, one of the trouble is slowness, so I compared it to qemu-i386 running i386 hosted AROS with gdb and it's slow there too and the slowness there (it's much newer sources than those of AROS PPC build from 2013) triggered AROS bug. Often it would freeze during "boot". Sometimes crash. Reason is that x11gfx hidd in some places misses the LOCK_X11 / UNLOCK_X11 protection when calling X lib (or X support lib) functions. Like here:



All this host (Linux) X11 function calls need this protection to make sure that there is never multiple such calls happening at the same time (like by AROS task A and AROS task B), because this Linux X libs know nothing about AROS Exec tasks and they may internally have some of their own (pthread?) locks/mutexes for Linux multi-threading support maybe. And if these Linux side locks ever have to "Wait()" it's big trouble. On the Linux side there is only 1 AROS thread. Also they aren't internally protected against AROS Exec task switches.

See "arch/.unmaintained/m68k-linux". It probably only existed/worked in the very early AROS years when sources were not yet so big. Later m68k machines probably were to slow to build AROS. Maybe cross compiling hosted was never done or was never supported or maybe even today is not supported.

But Linux is Linux. There should be very little difference between different cpu versions of Linux hosted AROS version. Mostly just the sighandler/sigcore stuff used to implement the task switching (in AROS hosted it works by poking the LInux signal context structure where Linux stores cpu registers/context when a Linux/Unix signal is handled. So that when the signal handler is left, it may jump into another AROS Exec Task).

It could be the begining of the Arosthlon!

Do we have a m68k hosted target? I thought we only had native for 68k.

No, I was just curious if it would work. I tried also to use gdb with it (you need to run qemu with "-g 1234" and then in external gdb do "target remote localhost:1234") and there is some trouble with it.

68k would be more interesting (and a faster to emulate cpu I guess) than PPC.

Pretty interesting! QEMU seems to be quite a versatile platform. Are you planning on resurrecting ppc-hosted AROS?

... works with qemu user emulation. Mythical 68k hosted Linux version which existed in early AROS days should/may work too, if it was resurrected/fixed?

Qemu user emulation only emulates CPU, no hardware. It's basically for running linux programs compiled for one cpu on a linux distribution which is actually for another cpu. Like a big endian ppc linux program (like "AROS hosted") on a little endian x86_64 Linux computer.

In case of 68k you could then run, test and debug 68k AmigaOS - not just 68k AROS - programs on AROS hosted on Linux in same way as AROS i386 or x86_64 programs.

To test AROS PPC hosted what I found was an old archive: "AROS-20131123-linux-ppc-system.tar.bz2". Newer builds maybe do not exist. In addition you also need Linux PPC dynamic linker and libs stuff otherwise a "PPC program" cannot run on another cpu. So I took (old) "ubuntu-12.04-desktop-powerpc.iso" and mounted that iso file in Linux. Inside that there is "casper/filesystem.squashfs" which needs again to be mounted. After that you can tell "qemu-ppc" to pick up those PPC linker/libs stuff from the directory where "filesystem.squashfs" was mounted to with "-L <directory>".

As it is at the moment you cannot use the normal x86_64 version of "qemu-ppc", You need to compile a 32 bit (i386) version of "qemu-ppc": The reason is that the AROS ppc is a 32 bit program and the emul.handler filesystem of it uses 32 bit versions of Linux' opendir/readdir/etc. and qemu-ppc (being normally compiled as a 64 bit program) cannot convert 64 bit offsets/etc. of readdir64/etc. down to 32 bits.

Compiling 32 bit verison of qemu-ppc from qemu sources:



You may need to install missing 32 bit versions of some libs and developer (header) files, first. Here (OpenSUSE Leap) I also had to fight with "libpcre2-8" where a package which contains "/usr/lib/pkgconfig/libpcre2-8.pc" filie did not seem to exist, so I created that file myself by looking at "/usr/lib64/pkgconfig/libpcre2-8.pc".

Then AROS PPC hosted should run after extracting "AROS-20131123-linux-ppc-system.tar.bz2" to some directory and then doing:



Here on a old i5-4590 it "boots" in about 3 to 4 seconds and is pretty fast. Colors are all wrong (yellowish), because of endianess problem in AROS x11 hidd.