Quote:

Unfortunately even this will not be the case because member packing in C structures also has to be the same and they can differ between architectures. PPC shared library versions of m68k libraries only work because they put special packing statements around the C structures made public by these libraries.

greets,
Staf.

Most of people here would have enough with this

Would prefer the UAE solution since its a complete one and you dont have to care which app is running and which does not. Easier to implement and much better maintained. You could run old software (even games, demos) by a seemless doubleclick, just as if there were no compatibility loss (try to run dos software on xp!). Native apps a far better so who cares about some faster emulation speed, when it needs to be emulated anyway?

Maybe a poll?

Don't forget that on big endian systems like PPC or ARM (configured as big endian) it would be possible to use transparent 680x0 emulation just like os4/morphos do.

It would be possible to make a x86-big endian version for those who prefer 680x0 compatibility over raw speed. That would be truly trasparent

Sounds like we have a couple of options:

(i) an simple integration of UAE that gets called up and run when a 68k program is double clicked on. (keeps old chipset compatibility and requires minimal programming).

(ii) Run a 68k emulator of some sort and use either existing AROS libraries or modified libraries - "Petunia clone". (loses old chipset compatibility and requires more programming than (i))


Could we have both as bounties and make user selectable?

Are there other/better options?

/rolls eyes

You cannot run 68k apps only in an 68k-emu on AROS (atleast not on x86).

Sure one could try to run them on 68k-emu+dummy-AROS, but getting that right is probraly more work than making UAE invisible.

Maybe better UAE will be something like that:http://amigos.amiga.hu/rachy/petunia.html

Quote:

I'm currently finishing off some changes to the build scripts to support cross compilation. Only native builds are supported so far however.

Quote:

Not necessarily. My idea would be to have a second copy of AROS running within UAE/it's CPU emulation. Some libraries etc. that do IO would probably be stubs that call the native equivalents, while others would be unchanged from the native version (except for the CPU they're compiled for of course). These stubs would convert the structures between the two architectures.

My main point though is that there's no need to emulate Amiga custom chips etc., and that the origianl Amiga ROM wouldn't be much use to us since the original intuition library etc. wouldn't be able to integrate with the native intuition. So the CPU emulation might be the only part of UAE that's useful for this bounty.

There is one major differnce between AROS on the one and MorphOS/OS4 on the the other side.
In order to run 68k-apps just ontop of a CPU-emu, you'd need to make sure that all system-structures are binary-compatible to AmigaOS3.x.

Doing that on AROS-X86 what require the X86-side to run in inverted endian-mode, similar to Martin Blooms gcc for Amithlon.