Please no-one take this as an opportunity to do any weird "vs." nonsense.
We all have our preferences and reasons for them, but at the end of the day enjoying our hobbies is what we're here for, so can we please have a discussion about something that might ignite passion without getting silly? I won't pretend to be innocent with this myself in the past, but doesn't there come a point where you're just too old to be bothered with nonsense and just want to enjoy whatever it is you enjoy without needing to be an ass towards others, or have a d!ck measuring contest? The core of all our hobbies is shared. Surely we can discuss things rationally from time to time even if the topic of discussion isn't your preference?

Now, all that said and done, and Im sure most will understand why I've started this post as I did above after reading, but Im curious as to whether AROS having an integrated petunia/trance style 68k emulator for big endian targets (PPC and ARM being the obvious candidates) would make it more interesting to yourself if the API compatibility (and having native versions of many bigger name AmigaOS software already), but not being able to run 68k software without an external program doesn't scratch the Amiga itch for you?

I like AROS for what it is already and for my tastes/needs of a more modern AmigaOS based system it serves me well, but I have to admit an integrated 68k emulator and what that brings with it is something Id like to see. Plenty of cheap g5 Macs out there and even if there's no bare metal native support there's ways run AROS on hardware with full support without emulation.
I think this would be handy for core AROS development too as Im sure it'd reveal some incompatibilities with the API in the process of integration. A lack of developers in the Amiga world is always a thorn in our sides, but this is purely hypothetical.

I have a G4 eMac (1.42ghz/radeon 9700 pro) running MorphOS already, so it's not a matter of not having a system with integrated 68k emulator available to me, I'd just like to see it in AROS for relevant hardware and am curious as to whether it'd make AROS more interesting to others?
Not even asking if you'd consider changing (I think most of us as happy using what we use already), just if it'd be more interesting to you to have a play around from time to time, or even use for a few specific uses if some software happens to work better on AROS (some software just runs better on any one of the 3 post OS3.x systems sometimes), etc. ?

Cheers

@fishy_fis

I would love to see it on arm, namely to get it running on Pistorm. I also wonder how much speed would be lost to make it run big endian on x86, and if it would actually be that problematic taking into consideration the Amiga software pool and it's usage

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

@fishy_fis

Idea is good and useful, and would be beneficial for wb app compatibility.

However, some winuae/runinuae style integration would be even better

Some resources on topic
http://www.aros.org/documentation/developers/summaries/m68k-emulator.php

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

Or just let entire AROS run under 68k emulation, Emu68 on a raspberry pi or qemu on whatever else.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla: that's the solution, but it would be too limited. In fact, it works only on 32 bit architectures (even using 64 bit architectures like ARM64 or the latest PowerPCs, your have to cripple the applications address space to 32/31 bits).

It would be a great improvement to the current situation, as Emu68 has clearly shown (and it could be taken as the base for this project). But the platform is still the same: crippled and without a future.

@fishy_fis

Example, https://www.emaculation.com/doku.php/executor
A cleanroom Mac ROM and dynamically compiling 68LC040 emulator for X86 PCs.

The Executor's source code has been released.

AROS X86 needs to be modified for unboxed big-endian operations.

Last edited by Hammer on 10-Jul-2024 at 02:29 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@fishy_fis

It would make it more interesting, but probably not interesting enough because I simply don't have enough time to tinker with all the AmigaOS clones/variants. For example, I installed MorphOS on QEmu, but haven't done anything with it beyond clicking around Workbench.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@kolla

or just switch to windows or android

Last edited by ppcamiga1 on 10-Jul-2024 at 04:59 AM.

@fishy_fis

it is good idea.
Aros devs should start from aros on ppc with 68k integration like in Amiga Os 4 /MOS.
biggest Aros flaw is lack of working amiga gui.
with possibility of use 68k dll like on Amiga Os 4 /MOS
Amiga Os 4 /MOS may be dropped and we all may use aros only on ppc

@ppcamiga1

ARM also supports "big-endian" mode, hence the lower bar for unboxed 68K emulator.

AROS on "big-endian" mode RISC CPUs doesn't match the functionality of DraCo 68K only AmigaOS 3.x configuration, let alone PPC-based MorphOS, AmigaOS 4.1 FE, and A-Eon's System 54.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@fishy_fis

I actually thought about this type of thing a few years back. It looks like the endian issues are real for AROS being able to execute 68K code emulated directly in AROS itself. I recall there was some work put into this but it didn't get much further than running Dir commands in a shell.

Against x86/64 PPC hardware may seem limiting. But useful for those of use that have it or have invested in it. For people that lost interest in OS4 AROS/PPC could be a new breath of life for their machines. I've ran AROS hosted on PPC Linux. The same build worked on both my A1XE and X1000 Linux. So AROS PPC does make it quite portable. Of course, running bare bones on the hardware is better, and I recall the Sam had a port for that. So having this as a feature would be good I think. In the Amiga world having 68K compatibility has become the "killer app" of our generation. And PPC needs something exclusive to offer.

ARM could be an interesting middle man. It's natively little endian but fortunately can run in big endian. ARM is pretty much the affordable RISC solution right now. I haven't caught up with the latest AROS on ARM developments. So I don't know if there is a Pi port or what hardware it targets. But it certainly has more 'obtanium' when setting up a RISC desktop or SBC.

@pixie

An issue I could see is that the open AmigaOS design has internal structures designed for big endian and in particular 68K. And for AROS these had to be portable and even then, for any shared structure, 68K code expects to access it as big endian. So this runs deep and I could see how they had trouble supporting 68K directly.

Interesting idea for PiStorm. Would be similar to ApolloOS using AROS. But more like AmiBench native using AROS as base and emulating 68K.

To be practical, and I've said the same for an OS4 port, I think a "native" big endian port for x86/64 would be needed. What I mean is a deep compilation where it only emits big endian specific instructions. IIRC cdimauro told me about an earlier Intel x86 compiler that was designed to port big endian code bases to x86.

I think the same would be needed today. For almost decades now x86 has had specific big endian instructions; not just indirectly with BSWAP, but directly with MOVEBE, since some Core series. So, there really is no excuse, time for language compilers to catch up!

And on that note, GCC recently acquired an attribute to set storage order. So GCC is one of the few compilers that can be told a structure is big endian. There would be some limitations as variables may not be able to hold this attribute. And all structures would need to be marked as such so all structs would need to be assigned as a "struct_be" type. It would also limit it to GCC. But since big endian specific isn't portable (nor the opposite) I don't see this as a big problem. I wonder if this can actually help to fix the Linux amdgpu driver so it works on big endian again.

@Hans

That reminds me of what people post about OS4 that don't see the point of it or never used it, and make comments about it being pointless to buy an expensive computer, just so you can move icons around all day on Workbench. I don't know what these people do on their own computer, and perhaps they just shifted icons around all day on their Amiga then played games, but I certainly do more, than shift icons around Workbench on OS4!

@fishy_fis
Unfortunately AROS hasn't a direct emulation of 68k like MorphOS and AmigaOS4, it must be done using UAE, the problem is that the AROS team is very little, and now they are fixed the bugs, perhaps a solution will be that some team from MorphOS or AmigaOS4, share solutions for AROS, but this is just an idea.
Because Amiga is a hobby, although sometimes one can question it as you have done for those you have described.

@Templario

Pardon?
Did you read what I wrote before you responded?
I know AROS has no integrated 68k emulator. That was nigh on the ENTIRE point of the post. Its in the thread title even. I also said its purely hypothetical and that developers are in short supply and mentioned 3rd party software is needed for 68k emulation.

I don't understand your response. Why are you telling me the very things I wrote while ignoring other things I wrote just so you can tell me about them?

You do understand how conversations work right? :)

@fishy_fis

perhaps this is something like that:
https://amiga-news.de/en/news/AN-2010-06-00053-EN.html

https://github.com/moggen/emumiga

@fishy_fis
Well, I see that you write, I read your previous speech amd well, your answer is the same that you wrote.
Only here I tryed to give the push to AROS and the othe teams can collaborate but, I'm sorry if my suggestion bother you, well, I see that in this forum never change the things...

@cdimauro

Quote:

cdimauro wrote: @kolla: that's the solution, but it would be too limited. In fact, it works only on 32 bit architectures (even using 64 bit architectures like ARM64 or the latest PowerPCs, your have to cripple the applications address space to 32/31 bits)..

Going 64Bit would negate the whole point of this thread.

With the way the Amiga API works, you have to decide, 32(31 really) or 64Bit?

Little Endian or Big Endian.

4 possible choices, 4 systems that may be widely source-code compatible but couldn't run any binary from the other 3.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Hypex

Quote:

Hypex wrote: @pixie An issue I could see is that the open AmigaOS design has internal structures designed for big endian and in particular 68K. And for AROS these had to be portable and even then, for any shared structure, 68K code expects to access it as big endian. So this runs deep and I could see how they had trouble supporting 68K directly. Interesting idea for PiStorm. Would be similar to ApolloOS using AROS. But more like AmiBench native using AROS as base and emulating 68K. To be practical, and I've said the same for an OS4 port, I think a "native" big endian port for x86/64 would be needed. What I mean is a deep compilation where it only emits big endian specific instructions. IIRC cdimauro told me about an earlier Intel x86 compiler that was designed to port big endian code bases to x86.

Correct. It's Intel's Bi-Endian compiler: https://www.intel.com/content/www/us/en/developer/tools/biendian-c-compiler/overview.html
Quote:

I think the same would be needed today. For almost decades now x86 has had specific big endian instructions; not just indirectly with BSWAP, but directly with MOVEBE, since some Core series. So, there really is no excuse, time for language compilers to catch up!

BSWAP is Stone Age: MOVBE is the way to go in this case.
Quote:

And on that note, GCC recently acquired an attribute to set storage order. So GCC is one of the few compilers that can be told a structure is big endian. There would be some limitations as variables may not be able to hold this attribute. And all structures would need to be marked as such so all structs would need to be assigned as a "struct_be" type. It would also limit it to GCC. But since big endian specific isn't portable (nor the opposite) I don't see this as a big problem. I wonder if this can actually help to fix the Linux amdgpu driver so it works on big endian again.

Another GCC extension...

Anyway, this way you need to change all relevant parts in the source code to add this new storage attribute: it doesn't work, because there's too much work.

Ideally you should take Amiga sources as they are and compile them for x86/x64 in a way where the compiler by default assumes big endian for all data accesses and generates the proper MOVBE instructions. But this requires time as well (e.g.: patch GCC or LLVM).

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: @kolla: that's the solution, but it would be too limited. In fact, it works only on 32 bit architectures (even using 64 bit architectures like ARM64 or the latest PowerPCs, your have to cripple the applications address space to 32/31 bits).. Going 64Bit would negate the whole point of this thread.

No, I was just saying that the proposal doesn't work on 64 bit architectures and you're stuck on 32-bit ones.
Quote:

With the way the Amiga API works, you have to decide, 32(31 really) or 64Bit? Little Endian or Big Endian. 4 possible choices, 4 systems that may be widely source-code compatible but couldn't run any binary from the other 3.

There's no question that 32-bit & big endian are needed / set has the system default.

However, a 64 bit architecture still allows to do the same and gather some advantage (e.g.: using the >4GB space as RAM: or RAD:, or for caching filesystems' blocks in memory).