Which OS Would Be The Best Amiga Way Forward...

[HenryCase]

And so are you.

Trance and Petunia are just JIT translators. Both MorphOS and OS4 can run 68k apps just fine without Petunia or Trance respectively.

How? I understand the transparent API calls, but how do you run 68k apps without emulating a 68k CPU? Are you suggesting PPC CPUs can understand 68k opcodes without translation?

I haven't seen much progress from this project lately. The project has seen several refactoring/rewrite cycles already and so far hasn't actually run much 68k apps. Latest download release is from 1 year ago. I wouldn't go as far as to predict that the project is in trouble, but it certainly doesn't seem to be progressing well.

Last post from the Emumiga blog was on 15th May, i.e. 6 days ago.
http://emumiga.com/
Who cares if there have been some challenges along the way, as long as it's still being worked on then it will get there, there's no technical reason I know of that means it won't work.

[Piru]

How?

Both have integrated interpretive 68k emulation.

Last post from the Emumiga blog was on 15th May, i.e. 6 days ago.
http://emumiga.com/

Yeah, but it would be more interesting to hear about the progress of the emumiga itself rather than about installing ubuntu.

Who cares if there have been some challenges along the way, as long as it's still being worked on then it will get there

The thing is, there are rather huge challenges ahead. As described by the author himself:

The procedure of setting upp mirrors between virtual memory and the
AROS memory seems really easy to do, but it requires a lot of logic to
make it running and there are many pitfalls.

For simple data structures it is quite easy, as the only concern is to
convert between endian formats.  Structures with pointers requires
more work, as the structures pointed out must also be mirrored.  The
pointer in the virtual memory structure must be a valid virtual memory
address, and in the AROS structure it must be a valid AROS memory
address.

Add to this that structures may contain other substructures and/or
itself be part of a bigger structure, that some pointers has the type
APTR or "void *" so we don't know what is pointed out, that structures
can be declared as local variables in C and thus get put in stack
memory, that memory will be unallocated or reused as something else...

This gets rather messy as soon as the amiga app (emulation side) wants to poke the structures. This does happen quite a lot. Also, I can think of several cases where the emulation could lead to a deadlock situations, especially if the messaging / waiting for response scheme is implemented as described.

Also, I'd be very interested to hear how this method will handle objects being added to system from the emulation side? For example: opening a 68k library/device/resource inside the emulation: How can this system prevent the library from being added to LibList to the AROS side as well? (Since there is no way that emuamiga could possibly support every possible library/device/resource out there, it must allow loading up 68k only components on the emulation side. Since these components are unknown beforehand there is no way emuamiga can know how to set up translation between the structures being used, nor can they be mapped to AROS equivalents). How will AddPort and the likes be implemented? How will the messaging between the emulation and the native AROS be handled?

there's no technical reason I know of that means it won't work.

That remains to be seen. There sure are challenges getting the described method to work correctly.

[Mizar]

I voted OS4 because it looks like it needed a bit more support in the poll. (Being a new OS4 owner)

However, in all truth, AROS is the way forward IMO, if nothing else than because it's open-source. Targetting x86 helps make it accessible also.

Do you run OS4 on your A1200 060/PPC with Mediator PCI busboard/Voodoo graphic card and SoundBlaster audio card?  And you also can run OS3.9 with this system config?  (awesome A1200 BTW!)

I am planning on doing a similar upgrade on my A1200, but I don't have a PPC accelerator.  So I'm wondering if I will still be able to run OS3.9 (and OS4) using a PC accelerator through Mediator also?  I've only just started checking into this Mediator upgrade possibility.  It sounds like awesome upgrade potential, but I might not yet understand how this works correctly.

[HenryCase]

Both have integrated interpretive 68k emulation.

So in other words, MorphOS and OS4 are just as dependant on emulation as AROS. The method of integration might be different, but the use of emulation is still there. Do wish you wouldn't try misleading people on this, Trance and Petunia might be just the names for the JIT interpreters but considering the context Forcie was clearly trying to get across that MorphOS and OS4 use emulation too, which is clearly true by your own admission.

That remains to be seen. There sure are challenges getting the described method to work correctly.

There are challenges in any development, especially when implementing something fairly new. Let's remind ourselves of what Emumiga sets out to accomplish:

Emumiga is a Motorola MC68000 emulator and a system interface proxy for AROS. Our goal is to run AmigaOS 3.x applications directly in AROS without emulating the Amiga chipset and without any 68000 Kickstart ROM.

http://emumiga.com/about/

Sounds similar to the transparent API calls that are used in OS4 and MorphOS to me. Are you saying that something that already exists on OS4 and MorphOS is impossible to implement in AROS, and if you are saying this why do you believe it?

[Fab]

Sounds similar to the transparent API calls that are used in OS4 and MorphOS to me. Are you saying that something that already exists on OS4 and MorphOS is impossible to implement in AROS, and if you are saying this why do you believe it?

But EmuAmiga has to deal with the endianess issue. Structures on the host (on x86 & co, anyway) are littleendian while the emulation side deals with bigendian structures.

Since all the amiga applications peek/poke in system structures, this adds quite some challenge compared to MorphOS/OS. EmuAmiga tries to resolve this in its way, but it's certainly not trivial at all, and it has to be seen if it can even work properly for real world applications (but just read what piru pasted from the author himself, it describes it much better).

[HenryCase]

But EmuAmiga has to deal with the endianess issue. Structures on the host (on x86 & co, anyway) are littleendian while the emulation side deals with bigendian structures.

Since all the amiga applications peek/poke in system structures, this adds quite some challenge compared to MorphOS/OS. EmuAmiga tries to resolve this in its way, but it's certainly not trivial at all, and it has to be seen if it can even work properly for real world applications (but just read what piru pasted from the author himself, it describes it much better).

What the author will be looking for is the most elegant way to solve the endianness issue. 68k apps already run on x86 in emulation, the only question is how little emulation is required. Even if the endianness issue is not solved then the author can at least achieve feature parity with MorphOS and OS4 on any big endian arch that AROS supports (PPC, ARM in big endian mode).

At this stage with Emumiga, we already have a coded proof of concept (Amiga clock). The developer is currently refining his development environment and coding approach (chose to switch to C++ for example). After the development environment is stable I imagine we'll see more work being done on researching the best emulation approach for Emumiga to take. Your questions will be answered then.

[Piru]

But EmuAmiga has to deal with the endianess issue. Structures on the host (on x86 & co, anyway) are littleendian while the emulation side deals with bigendian structures.

Not only that, but the structures themselves are different: Different alignment, different data types, sometimes different order for the fields, or some missing/extranous fields.

As I see it there is no way for the emuamiga to expose emulated resources to AROS side unless if it knows how to translate between the structures. The only way to handle this would be to present different views of the system resources to the emulation and the host system. But doing this would add inconsistency (for example ln_Succ in various lists would be different if some nodes were to be skipped. Just think of a library expunge function performing inlined Remove() on the library node...), and I frankly can't image any way to handle this in a way that would be safe, or that would even work consistently.

I've also wondered how the changes in the host system will get propagated to the emulation side: As far as I can tell any change in the host environment must appear immediately on the emuamiga side as well. As I see it this would require hooking all possible host operation that might change any of the objects currently mapped between the emulation and the host. Alternatively every memory access in the emulation would need to go thru code that does translation as needed.

These are just simple examples I could come up. In reality things get much more complex.

[Piru]

Even if the endianness issue is not solved then the author can at least achieve feature parity with MorphOS and OS4 on any big endian arch that AROS supports (PPC, ARM in big endian mode).

Nope. See my previous post.

At this stage with Emumiga, we already have a coded proof of concept (Amiga clock).

Amiga clock is trivial and isolated application. The only interface it has is a window. Real life applications are much more complex and interact with the host environment in various complex ways.

[XDelusion]

But Amiga clock is the program most die hard Amiga users use the most. What else could we possibly need support for?


Bottom line for this discussion. MorphOS works now, and is very affordable. EmuAmiga and all this this speculation about what AROS will grow into...

...is still something in the future, and judging by it's record of slow development, a long way off.

[HenryCase]

Nope. See my previous post.

Eh? If these issues are so insurmountable how does MorphOS get around them? Anything that MorphOS can do on big endian machines, AROS will be able to do on big endian machines, end of. The question is, how much can the isolated emulation be stripped away on little endian machines. Those questions are as yet unanswered, but even if some emulation overhead can be removed then the effort will still be worth it.

Amiga clock is trivial and isolated application. The only interface it has is a window. Real life applications are much more complex and interact with the host environment in various complex ways.

Of course it's trivial, it's just a simple program. I respect that more complex programs will present new challenges, but let's see what can be done. If new features are discovered they can always be copied by other Amiga platforms if the core developers choose to do so.

[Piru]

Eh? If these issues are so insurmountable how does MorphOS get around them?

MorphOS has binary compatible structures (same endianity, same padding etc). PPC and 68k see exactly the same OS resources. There are of course numerous extensions and new functions but they were created carefully in order to maintain backwards compatibility.

Anything that MorphOS can do on big endian machines, AROS will be able to do on big endian machines, end of.

Last I heard AROS is not interested in full binary compatibility on big endian systems other than 68k. Even if such compatibility would be added you'd still need to add the CPU emulation and the required infrastructure (it's somewhat different from what emuamiga is doing). It certainly is possible but quite some work (aros 68k effort is a good start).

[HenryCase]

Last I heard AROS is not interested in full binary compatibility on big endian systems other than 68k. Even if such compatibility would be added you'd still need to add the CPU emulation and the required infrastructure.

AROS developers are free to work on whatever they want, provided they don't interfere with the goals of the project (at which point a fork is necessary). Seeing as the goals of AROS do not rule out developments like Emumiga then they are free to continue. I'm surprised I have to explain this to someone of your supposed intelligence.

[Piru]

I'm surprised I have to explain this to someone of your supposed intelligence.

I'm surprised you thought you needed to.

While it certainly is possible to replicate MorphOS kind of emulation on big endian systems, emuamiga isn't it (even when running on big endian systems).

[J-Golden]

I voted Aros after reading what everyone was saying about it but when I wen to its source forge page, they barely mention using it on classic hardware.  Where can I find info about the AROS ROMs and "Amiga Classic" specific stuff?

[TheBilgeRat]

Not to be much of a blue troll, but I am surprised that OS 4.1 is slightly ahead of morphOS.

[Karlos]

I always like the Amithlon big-endian-memory-model for 68K emulation on little endian architectures. For x86 you will naturally lose some performance doing the byteswap for every 16/32/64-bit access (although emulation various memory to memory moves would not need it) but you have such a huge performance starting point (especially now) that I'm quite sure it would outperform currently available PPC-based amiga compatible systems.