@Hypex

Quote:

I must give credit to Linux PPC as I've taken 32-bit apps and they ran fine on a 64 bit kernel. Somehow they got something right with 32 bit user land in 64 bit kernel space. I even tested the custom installed Ubuntu 9.04 from my AmigaOne on my X1000 and it was able to boot, at least on older kernels. I installed AROS hosted on it and tested it on my X1000. It runs great!

Very true! I still have to use multiple 32bit apps in Linux these days and they run without any issue or slowdown. Magic sauce. 😂
Even Ubuntu."sudo dpkg --add-architecture i386" and you're good to go.

Last edited by SHADES on 09-Mar-2023 at 07:37 PM.
Last edited by SHADES on 09-Mar-2023 at 07:31 PM.

_________________
It's not the question that's the problem, it's the problem that's the question.

@umisef

Well, then there should be very visible difference between UAE and other 68k emulators that don’t do chipset emulation. Can’t really say I’ve noticed.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I guess that depends on what you've been doing with it. Anything that is compute bound or latency sensitive (or both, e.g. music production) tended to work better for me in Amithlon than it did on UAE on the same hardware.

I wrote a lot of questionable code back in the day. Some of that much faster on Amithlon.

_________________
Doing stupid things for fun...

@SHADES

Quote:

Very true! I still have to use multiple 32bit apps in Linux these days and they run without any issue or slowdown. Magic sauce. 😂 Even Ubuntu."sudo dpkg --add-architecture i386" and you're good to go.

Thanks. That must have been what sauce I was missing on x64 as on PPC64 it seemed to be automatic. I was compiling some DLink router sources designed for a ten year old 32-bit server and ran into trouble with a 32-bit tool included breaking in 64 bit. There were a number of solutions posited online. I just deleted the x86 binaries to force a recompile.

@umisef

Quote:

Never mind one that only has a single 32 bit address space.

There's a very easy and simple way to work around AOS design limitations like this. Instead of running a single AmigaOS "instance" you run multiple ones at the same time and composite the screens/windows together into one place. You could easily have 100s or even 1000s of AOSes running at the same time on the same machine. At minimum each big application (paint program, workbench, web browser) would run in it's own instance.

This brings automatic other big advantages: memory protection between instances (think about running two copies of UAE on LInux. In one you run "PersonalPaint". In the other you run "Lighwave"), resource tracking (think quitting UAE on Linux"), multiple core support (Linux might execute some code of the UAE #1 process on core #1 while at the same time executing some of the UAE #2 process code on cpu core #2), etc.

An idle AmigaOS does not really take up any cpu resources/time. (See AROS/hosted running on LInux). Some Timer events going through input.device. Not much else.

You could mix 68k (UAE) and x86 (AROS) apps. 32 bit apps and 64 bit apps (x86).

Here's an older video of how this looks with some semi-rootless hacked AROS/hosted where each AROS program/game/demo (like Doom3, XaoS, Soliton) running in blue Amiga-themed "window" is a separate AROS instance/process. Running on linux desktop. AROS and Linux (shell) windows, intermixed. But only "semi rootless" (parts of each AROS screen which is not a AROS window is dynamically made transparent).

https://vimeo.com/191163338

@Georg

Dear Lord! How many instances of AROS can you even run!?
YES!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

Yes, containing and sandboxing is all the rage. Well, the typical productivity workflow often includes arexx scripts that pass data around the programs for various processing, so for that one must either run the whole workflow in one instance, or use common file system (host filesystem, typically) and network, or just socket files on a shared filesystem.

I frequently assign CLIPS: to filesystem, just for copy’n paste to work across reboots and also to share between FS-UAE instances.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

I don't have time for a full reply but I think you missed my point here:

Somehow I intended to keep it short but it bloated. A bit like a grocery trip where I only plan to buy a few things and end up spending a fortune.

Quote:

I'm not at all suggesting OS4 PPC for UAE. I'm suggesting UAE 68K is a viable market for the proposed OS4 68K version. Along with PiStorm, Vampire and just regular 68020+ machines, though it goes without saying 040/RTG is likely the minimum viable spec. The performance of the QEMU/softfloat implementation in UAE is pretty lacklustre, at least on my machines.

Well the same would apply with 68K, it's just less limiting than PPC, with UAE. But like most emulators it lacks transparency. Since common devices like USB don't show up. It's fine as a sandbox but a bit limiting for a full on environment as it is.

@Georg

Quote:

There's a very easy and simple way to work around AOS design limitations like this. Instead of running a single AmigaOS "instance" you run multiple ones at the same time and composite the screens/windows together into one place. You could easily have 100s or even 1000s of AOSes running at the same time on the same machine. At minimum each big application (paint program, workbench, web browser) would run in it's own instance.

According to an OS4 kernel developer Exec runs in an interrupt. Which is easy to see since it switches tasks inside an interrupt. But there's just a slight elephant in the room. Messages. How would IPC work if some tasks cannot know about each other?