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

[Piru]

I am sorry, but you are just wrong on so many levels.

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.

Now, AROS also has a "transparent emulator" project going on, called Emumiga. It is not done yet, but to say that it never will happen is wrong. When it is done, AROS will have exactly the same transparent emulation capabilities as OS4 and MOS, if not better.

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.

AROS, on the other hand, has something called Janus-UAE, which allows all the Amiga chipset dependent software to be integrated into the system pretty much in the same way as with Petunia or Trance.

Neither Petunia nor Trance do any kind of integration, they're just JIT engines. Janus-UAE doesn't do what OS4 and MorphOS do, far from it. Janus-UAE's integration is very limited whereas OS4 and MorphOS do no integration at all: Everything runs natively inside the host OS. No integration is required. Janus-UAE can never be as complete as running the app directly on the host.

It is a very cool solution, and maybe OS4 and MOS will get something like it in the future too.

Personally I doubt it. There are very few applications that both hit HW and would still benefit from using native screens or windows.

Of course if someone feels like creating such UAE for MorphOS or OS4, sure go ahead. Personally I don't see the point in that though.

[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.

[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.

[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).

[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).

[Piru]

Hi,

@Piru,

Excuse me for asking, but are you one of the programmers for morphos?

Yes, since year 2000 or so.

If you are do you have a morphos that runs on the AGA chipset?

Nope. MorphOS has always required a graphics card. See here for some information about supported HW: http://powerup.morphos-team.net/

[Piru]

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?

Try here: http://en.wikibooks.org/wiki/Aros/Platforms/68k_support

[Piru]

Hi,

@Piru,

Thanks for the information, always did respect you and your posting, now I am really going to have to think, do I want to upgrade the Amiga 1200 to a graphics card set which would probably set me back about $500

Considering we no longer support the classic amiga version (and it isn't possible to register it), I wouldn't recommend this option. Oh, Mac mini G4 is something like >10x faster too.

or do I want to swallow my pride and buy a G4 mini mac for about $250. Really want to see what MorphOs is about. Well got to do some heavy thinking.

No relatives or friends with a supported mac? You could safely boot those machines from the MorphOS CD to give it a try (no need to install anything, it works as a livecd then).

[Piru]

Because Piru knows that it is feasible. It´s not easy and hobby coders won´t make it work, but its feasible.

I don't consider the current emuamiga feasible. While the author asserts that "Luckily, system friendly applications are often written in ways that are pretty easy to emulate." I beg to differ. In my opinion there are serious design issues with the current emuamiga.

Please note that I am not trying to discourage anyone here. I'm just giving my expert opinion.

[Piru]

For example there a couple of hundred lines of code in the 3.1 ROMS like these...

$f8e00 bra.l $f8e04
$f8e04 rts

bra.l is 020+ so I find this rather unlikely. You possibly meant bra.w or jmp ?

$f8e00 bra.s $f8e02
$f8e02 rts

Just nitpicking, but bra.s *+2 instruction doesn't exist. ;-)