@cdimauro

Quote:

np: #pragmas are there for this. But definitely NOT the custom language extensions.

Seems there's no singular standard for this. Given there can be differences in hashtag language of the preprocesor. But good to have matching attributes between Amiga compilers.

Quote:

No, AROS' goal was to be Amiga o.s. source-compatible for all platforms and binary compatible with the original / 68k one, and that was defined since day one.

Sounds like a lot to expect given more work is needed to ensure it works on the oldest platform.

Quote:

The problem is that after Commodore bankrupt then there was no Amiga o.s. development, and AROS was born to give it a future, whatever could have happened to the companies which owned the brand.

And also no more Amigas except for a few vaporised announcements.

Quote:

It looks like another cross-compiler. There's nothing interesting, besides that it generated code for Amithlon's platform/ABI.

It's more than a simple cross compiler. This was one of the killer features. If the OS4 code base as ported from OS3 to C, was compiled with this instead, it could have killed OS4 in the water. When this got out people wanted OS4/PPC dumped in favour of this as an official replacement, even using an older OS3, which was still current. All 'AmigaOS cannot run on x86' arguments would be DOA. It came out first, which I knew would happen, so it had a good head start on OS4 and being RTG centric was a similar solution.

It does target Amithlon obviously but it works similar to WarpOS/PowerUP, except for x86. It allows code to run natively on the x86 host while OS calls are emulated. The similarity being a faster CPU being used to run optimised code. I expected this to take over WOS/PUP since it was using cheaper non-exotic hardware that was faster overall. It was the writing on the wall. But check this readme which explains a little more on the bottom:

http://www.lysator.liu.se/~lcs/files/gg-cross/README

Quote:

Only on the 68000.

Oh, more that, the OS structures need word alignment. An example, when I started writing CIAgent to simulate CIA and resources, the CIA resource object was off alignment on OS4. I grabbed the CIA structure from an ASM book, which AFAIK, was never declared publicly. Then found I needed a #pragma pack(2) to keep proper 68K alignment.

Quote:

No misaligned load/store instructions on PowerPCs?!?

It can but it's not efficient. PPC likes data to be 32 bit aligned. So common 68K Amiga structures with pointers at 16 bit alignment and not pure 32 bit alignment are not suitable for PPC. But PPC does bloat things out. So a WORD will take up 32 bits in an object, even though it is 16 bits wide, unless it's packed to WORD alignment.

Quote:

What I proposed is different: as much as code possible should be native (e.g.: second branch) to take fully advantage of the host platform. The rest (AROS, mainly) is compiled as big-endian to make 68k applications first-class as AROS.

Ok, that would have been interesting to see.

Quote:

That's the point, since MOVBE is much faster (and more instructions like that can be executed per clock cycle).

That's good to know it is faster and worthwhile. Now days people would use it. Since it's been current for long enough.

Quote:

I've a different idea about that, since many years: I prefer to have an Amiga "virtualizer" which allows the transparent execution of Amiga applications on the host system, including a JIT. Imagine clicking on an Amiga icon file and it launches the given application which opens its window like any native application of your system.

Yes that would be cool. What is that project, Arix? It attempts to compile Amiga code so it can run on Linux native or similar. Using some kind of Aros run time. IIRC it handled all the window code so it looked like Amiga windows but encapsulated in host windows. So like Amiga on Linux. But, an Amiga program using a Linux toolkit like GTK or QT, would look strange. Amiga on Linux would also be strange, if it was transparent, and took over a border-less Gnome window with Intuition looks.

@Hypex

Besides arix you now have axrt
https://www.axrt.org/

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

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: [quote]No, AROS' goal was to be Amiga o.s. source-compatible for all platforms and binary compatible with the original / 68k one, and that was defined since day one. Sounds like a lot to expect given more work is needed to ensure it works on the oldest platform.

Not that much. AFAIK the major problem was about the (im)maturity of the Amiga support.

At the end, having (at least) a (cross-)compiler which targets 68k was already in place.
Quote:

Quote: It looks like another cross-compiler. There's nothing interesting, besides that it generated code for Amithlon's platform/ABI. It's more than a simple cross compiler. This was one of the killer features. If the OS4 code base as ported from OS3 to C, was compiled with this instead, it could have killed OS4 in the water. When this got out people wanted OS4/PPC dumped in favour of this as an official replacement, even using an older OS3, which was still current. All 'AmigaOS cannot run on x86' arguments would be DOA. It came out first, which I knew would happen, so it had a good head start on OS4 and being RTG centric was a similar solution. It does target Amithlon obviously but it works similar to WarpOS/PowerUP, except for x86. It allows code to run natively on the x86 host while OS calls are emulated. The similarity being a faster CPU being used to run optimised code. I expected this to take over WOS/PUP since it was using cheaper non-exotic hardware that was faster overall. It was the writing on the wall. But check this readme which explains a little more on the bottom: http://www.lysator.liu.se/~lcs/files/gg-cross/README

OK, I see now:

But one problem it *doesn't* have is an endian problem, since all data stored in memory has big endian byte order (unless the data is stored in an executable section). The downside of this should be obvious: increased code size and decreased performance. The good news is that you don't have to change a single source line in order to recompile your program into native ix86 code. My Amiga just got eight timesfaster ...

which is exactly what's needed!
Quote:

Quote: Only on the 68000. Oh, more that, the OS structures need word alignment. An example, when I started writing CIAgent to simulate CIA and resources, the CIA resource object was off alignment on OS4. I grabbed the CIA structure from an ASM book, which AFAIK, was never declared publicly. Then found I needed a #pragma pack(2) to keep proper 68K alignment. Quote: No misaligned load/store instructions on PowerPCs?!? It can but it's not efficient. PPC likes data to be 32 bit aligned. So common 68K Amiga structures with pointers at 16 bit alignment and not pure 32 bit alignment are not suitable for PPC. But PPC does bloat things out. So a WORD will take up 32 bits in an object, even though it is 16 bits wide, unless it's packed to WORD alignment.

I see and that's very strange, since PowerPCs were quite complicated as "RISC" processors, but still having aligned load/stores.

However, if you've unaligned load/stores then they can be used and it's all about microarchitecture (e.g.: how good is the specific implementation).
Quote:

Quote: I've a different idea about that, since many years: I prefer to have an Amiga "virtualizer" which allows the transparent execution of Amiga applications on the host system, including a JIT. Imagine clicking on an Amiga icon file and it launches the given application which opens its window like any native application of your system. Yes that would be cool. What is that project, Arix? It attempts to compile Amiga code so it can run on Linux native or similar. Using some kind of Aros run time. IIRC it handled all the window code so it looked like Amiga windows but encapsulated in host windows. So like Amiga on Linux.

Arix (and AxRuntime) is like this, but for native (AROS) applications.

My idea is different: it's about running existing 68k applications directly on any host system, perfectly integrated there. So, using the host system for handling & rending the GUI elements (but you can always have a "canvas" widget where you can draw the graphic as you want: even "Amiga-style").
Quote:

But, an Amiga program using a Linux toolkit like GTK or QT, would look strange. Amiga on Linux would also be strange, if it was transparent, and took over a border-less Gnome window with Intuition looks.

Indeed, but then... don't use Gnome.

@Hypex

Quote:

Amiga on Linux would also be strange, if it was transparent, and took over a border-less Gnome window with Intuition looks

Here is OWB running under Windows with Intuition looks - It doesn't look that strange to me, though everyone will decide for themselves.

_________________
https://www.axrt.org

@deadwood

That's what we need but for aros 68k inside aros, it would feel at home xD

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

@kolla

Thanks. According to that. With a RPi 3A+ and ID4 on 3.9 no Pi config changes needed. Nor does AB3D need any. On OS3.9.

I've downloaded the Caffeine OS, built on OS3.9, so will try that. I'm also setting one up for a friend. So will try a pure OS3.9 install. Currently left the ROM update off. I'm not sure if there was any official OS3.9 ROM or way to produce one. In my experience using patched ROMs crashes the Storm. OSS3.2 ROM may be better, but better off without OS3.9.

I don't think it's WHDLoad games that have an issue. As I have some other corruption going on. Given MonAm delays loading code and it's all corrupted something else must be going on.

@cdimauro

Quote:

My idea is different: it's about running existing 68k applications directly on any host system, perfectly integrated there. So, using the host system for handling & rending the GUI elements (but you can always have a "canvas" widget where you can draw the graphic as you want: even "Amiga-style").

Would a solution such as VAMOS (Virtual Amiga Emulator) suited to transparently run AROS 68k code?

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

@Hypex

Quote:

That sounds more ancient than Amiga 68K which lasted longer on 68K.

Adobe Premiere 4.2.x 68K was released in Aug 1996.

Mac's Adobe Premiere 5 is for PowerPC-based Macs.


----------------------------------------
@Kronos


Quote:

As always you get the facts kinda right only to then go of rail. By the time Amithlon and NG came around every NLE video HW for Amiga was obsolete with vendors either having move elsewhere (PC,Mac custom HW) or nowhere.

FYI, MacroSystem sold and supported DraCos (68060) up to the year 2000.

Early year 2000s NLEs were MPEG2-based with digital video sources from FireWire.

_________________
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

@Hypex

Quote:

So it uses OS3.9. I've been wanting to install OS3.9 fresh but do we need to disable the ROM Update? I can find no where that states if that needs to be turned off or can be left on with PiStorm. I don't know how this isn't listed anywhere. Along with max transfer. These are major blockers for hardware configurations known to cause faults and no one mentions them!?

Default CaffeineOS uses AOS3.9 and it has a transfer script for AOS3.2.

Quote:

Do the games instantly crash without "turtle mode" when loaded?

Without Emu68's various "turtle modes" enabled, WHDLoad games usually wouldn't run in the intended result.

_________________
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

@pixie

Quote:

pixie wrote: @cdimauro Quote: My idea is different: it's about running existing 68k applications directly on any host system, perfectly integrated there. So, using the host system for handling & rending the GUI elements (but you can always have a "canvas" widget where you can draw the graphic as you want: even "Amiga-style"). Would a solution such as VAMOS (Virtual Amiga Emulator) suited to transparently run AROS 68k code?

Kind of, but more integrated on the host system.

And not limited to AROS, of course: any 68k code should run on it

At least OS-friendly. Accessing hardware.. can be done on some areas, but fully controlling the original chipsets requires a complete emulator, which is out of scope.

@cdimauro

I am talking about AROS because this way you have more leeway to tweak on x86 side/68k side.

And OS friendly, because in my pov there's no needed integration for games, they can simple be run on an emulation. In winuae i can even start another winuae instance with a game from within the system, although whdload is a better solution overall

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

@pixie

Quote:

pixie wrote: @cdimauro I am talking about AROS because this way you have more leeway to tweak on x86 side/68k side.

Hum. What's your idea here?
Quote:

And OS friendly, because in my pov there's no needed integration for games, they can simple be run on an emulation. In winuae i can even start another winuae instance with a game from within the system, although whdload is a better solution overall

Games are the best example of software which could run in completely independent & isolated processes: you don't need to care about the OS, other applications, AREXX ports, etc. etc.

WinUAE is the best here, because it offers the best compatibility with all chipsets & peripherals.

However, I've other ideas as well on how to better enjoy games on a host platform. But this requires much, much more work compared to the above "Amiga virtualizer" proposal for the applications.

@cdimauro

Quote:

Hum. What's your idea here?

I am not that knowledgeable, my line of thought is just that in the past we had apps that tweaked workbench to make intuition behave in a given way, visual prefs, birdie, etc.. here having access to the code one wouldn't need those, so to bring some do coherence so that both systems, like choosing from the screens available where an app open, standard file requester...

https://youtu.be/jom6UdmR92E
Amibridge here have windows inside windows for example, perhaps the 68k aros here could account for it. But perhaps such a solution wouldn't even be needed, I just would like that you didn't have two systems agnostic to each other

https://youtu.be/wK3jtVu4tRc
In this video it seems to do it pretty well
Namely aros68k integration

Last edited by pixie on 31-Jul-2024 at 11:44 PM.
Last edited by pixie on 31-Jul-2024 at 11:35 PM.

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

@pixie

Quote:

pixie wrote: @cdimauro Quote: Hum. What's your idea here? I am not that knowledgeable, my line of thought is just that in the past we had apps that tweaked workbench to make intuition behave in a given way, visual prefs, birdie, etc.. here having access to the code one wouldn't need those, so to bring some do coherence so that both systems, like choosing from the screens available where an app open, standard file requester... https://youtu.be/jom6UdmR92E Amibridge here have windows inside windows for example, perhaps the 68k aros here could account for it. But perhaps such a solution wouldn't even be needed, I just would like that you didn't have two systems agnostic to each other https://youtu.be/wK3jtVu4tRc In this video it seems to do it pretty well Namely aros68k integration

OK, got it now.

Yes, the above "Amiga Virtualizer" will look like AmiBridge, however without embedding a complete UAE.

@pixie

Yes that's what I was thinking of.

Unfortunately I can't run it. My system is too old. I'm running Linux Mint 20.3 Cinnamon with the latest updates. Although I had updated my system in recent times and transferred to an Nvme it has fallen behind again. Seems I may need to update twice as I recall there was another update after I had updated for the next release. If restoring user data wasn't such a pain I would just reinstall.

It's good it has a package Lintian found a few issues.

@cdimauro

Quote:

At the end, having (at least) a (cross-)compiler which targets 68k was already in place.

That would be useful. Don't know if it gets rid of the ixemul problem with cross compiling. Mostly that was an issue with porting across to AmigaOS but it always tended to mess up 68K builds.

Quote:

OK, I see now:

Yes, I'd like to know how. But I don't want to sift through all the sources to look. Suppose a good search tool could do it for me.

Quote:

I see and that's very strange, since PowerPCs were quite complicated as "RISC" processors, but still having aligned load/stores.

It mostly affects compiled objects as it defaults to long alignment.

Quote:

However, if you've unaligned load/stores then they can be used and it's all about microarchitecture (e.g.: how good is the specific implementation).

In this case it's possibly similar to AGA fetches where 64 bit alignment is optimal for best case. While PPC can read 16 or 32 bit alignment 32 bit is optimal. So, it isn't just the register restrictions causing code bloat, aligning object fields to 32 bits can cause even more with object bloat

Linux: Everything is a file
PowerPC: Everything needs a register

Quote:

Arix (and AxRuntime) is like this, but for native (AROS) applications.

Yes, very useful idea. Could actually provide the closest to Amiga on Linux idea. Eventually this could happen if [more] work was was put into an Aros distro

Quote:

My idea is different: it's about running existing 68k applications directly on any host system, perfectly integrated there. So, using the host system for handling & rending the GUI elements (but you can always have a "canvas" widget where you can draw the graphic as you want: even "Amiga-style").

I see. That's also what OS4 and MOS attempt to do. I think they do it well given how integrated it is, WRT the RTG limitations. Also similar is Amithlon which had the same aim. I see it as an AmigaOS emulator rather than an Amiga emulator since it is optimised to run 68K AmigaOS untied from the chipset as much as it can be alleviated.

A hybrid idea I had is to use UAE for main emulation, solving the chipset issue, but all OS access would be patched and go through a middle layer. So that, when a program opens a window, it is diverted to the native routine and would look host native as well. The only caveat is that it would need data protection and likely a local object, such as a window, so isolate 68K UAE memory from host memory and objects. Whilst also being able to communicate back and forth.

Quote:

Indeed, but then... don't use Gnome.

Yet another dependency. Suppose Wayland will be the latest hip window manager. There's a guy on YT who installed a recent Ubuntu on G5 Mac. He says G-nome. It sounded funny. He also said other quirky sounding things. Sounds like GIF again. Is it G-nome or Gir-nome. I just drop the G and call it nome. It's a garden figure to me, else why would they call it Gnome?

@deadwood

Yes it sits there rather well. But how does a Windows window look against it? Actually I think an average Windows window would look plain against that.

@Hammer

Quote:

Default CaffeineOS uses AOS3.9 and it has a transfer script for AOS3.2.

Must check it update is enabled.

Well I did a test. Duplicated my system to FFS. Same problems. Then tested a fresh OS39 install without ROM update applied. Works fine. This would confirm an issue in my OS setup. Something is wrong as a missing assign causes it to crash on boot. AmigaOS shouldn't be so unstable as to crash because an assign went missing. So think I need reinstall OS9 and applications.

Quote:

Without Emu68's various "turtle modes" enabled, WHDLoad games usually wouldn't run in the intended result.

I was able to run AB3D2 with default settings fine.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: My idea is different: it's about running existing 68k applications directly on any host system, perfectly integrated there. So, using the host system for handling & rending the GUI elements (but you can always have a "canvas" widget where you can draw the graphic as you want: even "Amiga-style"). I see. That's also what OS4 and MOS attempt to do. I think they do it well given how integrated it is, WRT the RTG limitations. Also similar is Amithlon which had the same aim. I see it as an AmigaOS emulator rather than an Amiga emulator since it is optimised to run 68K AmigaOS untied from the chipset as much as it can be alleviated.

That's the keypoint regarding applications: get rid of the custom chipset emulation.

Or, at least, implement it in a way that it doesn't hurt the overall processor performance.
Quote:

A hybrid idea I had is to use UAE for main emulation, solving the chipset issue, but all OS access would be patched and go through a middle layer. So that, when a program opens a window, it is diverted to the native routine and would look host native as well. The only caveat is that it would need data protection and likely a local object, such as a window, so isolate 68K UAE memory from host memory and objects. Whilst also being able to communicate back and forth.

To me games -> UAE. There's no need to complicate a project trying to support games (especially the Amiga ones, with several of them badly coded).