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

[itix]

Loved MorphOS 0.4 on my BPPC quite lot even if it was little slow.

Btw you could have included OS3 option to the poll.

[itix]

As Amigadaves poll shows so far that around 68% of voters have been using Amigas for over 20 years and 50% of voters in this poll have so far voted AROS...

50% for AROS is quite surprising but as I see there is large opportunity for AROS. It is likely that AROS is going to replace AmigaOS in high end 68k systems including WinUAE. Maybe it is what users are expecting from the future.

Tho, it is not necessarily the future. In the past OS4 was always leading whatever polls with AROS always having the last position somewhere. If the past polls were true there would be 5000 OS4 users, 500 MorphOS users and 0.0001 AROS users.

[itix]

You are forgetting that we are running under CPU emulation anyways, so you don't actually need any real MMU. You will end up duplicating all structures, but this is just part of your interface. Everything you don't interface to has to run in emulation as well.

And how it will work with 3rd party libraries and classes? If I install 3rd party 68k native UI class to system how little endian application is going to access its structures?

[itix]

I guess in your terms I am already trolling for just stating that. I have found that classic, UAE, AROS and AmigaOS4 aren't as aggressive as the blue team

I have to disagree. I know many nice fellows who are using OS4 but I also know couple of individuals who are (well were, since I havent seen those people much anymore) just lame. At some times it was impossible to talk about MorphOS without getting attacked by some strange persons. MorphOS never had such problem with other user groups.

Interestingly OS4 used to have lot problems with anyone not buying into OS4. Since then everything has luckily matured and neither MorphOS and OS4 users really care much about it anymore. On the other hand negative comments are IMO always ok. If someone doesnt like something in MorphOS he should be allowed to say it. (Kolla gets very annoying here sometimes but he is consistent with what he says. I really respect that even when he is just PITA. )

Just today somebody posted an Animation that was created to make fun about the red camp and it was neither funny nor informative.

Where? :-)

And here they are trying to demotivate AROS fans by claiming something can't be done which is actually technically feasible (a pattern I have seen more than once).

I disagree again. AROS people are nice and honest to MorphOS and so are MorphOS users and developers to AROS. But if something can not be implemented why not argue about it?

(Well, like always, there are exceptions, not everyone like everyone and sometimes people do stupid things)

[itix]

Because Piru knows that it is feasible. It´s not easy and hobby coders won´t make it work, but its feasible. The point is that neither AmigaOS nor MorphOS can support Intel chips without a major headache and AROS on first sight should have the same difficulties.

It has nothing to do with the hardware. It is only about endianess and sharing data between native and 68k applications.

But since AROS doesn´t have to care about the PPC stuff and old Amigas are comparatively slow and small they can get away with some things that wouldn´t work out for the other guys. If AROS can run on 68k, 68k can run on AROS.

Yes, I have seen UAE running on AROS. Now you can extend this so that you map Kickstart calls to native system and integrate it more. But if you wish to integrate it fully you have to figure out how to support PutMsg() (and anything remotely similar) between x86 and 68k components.

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

You mean by duplicating all system and 3rd party structures? But what if x86 application is going to write into structure maintained on the 68k side?

[itix]

The only data that has to cross the emulation/system border is the data of standard 3.1 libraries and devices.

Which fails to work when 68k native application PutMsg() to your AROS native filesystem.

[itix]

Why would it? In that case the message format is well known and easy to proxy.

So you are going to write wrappers for every known file system packet out there? Fine. Dont forget filesystem hooks, though. What are you going to do if someone wants to execute 68k native code in the filesystem context? Thanks to (maybe not so clever) AmigaOS 2.0 improvements it can be done...

And we are only at DOS. Lets play a little with my favorite MUI/Zune. This monster allows executing event hooks inside UI code. If you wish to use native Zune here you have to add wrappers for all hooks from 68k side. It can be actually done (I have done it... for another project...) but real fun starts when you wish to support custom classing. Zune objects are actually nothing but data structures. Parent and child objects (which could be 68k or AROS code, you never know) are called via DoMethod() calls. And DoMethod() call is not an OS call but it is simple call in amiga.lib or inlined to application so you can not easily trap calls to AROS code. I dont know how AROS implements DoMethod() so it could be easy to trap calls to 68k code again... and it will be slow because on every context switch you dont have to change only one data structure but data of every object in Zune application (objects have pointers to other objects so every referenced object must be translated to right endianess).

(Needless to say it will be much easier have one native Zune implementation and another Zune implementation for 68k applications.)

The only problem with PutMsg() would be message formats Emumiga doesn't know about and where it is ambiguous whether or not a specific value should have the endianness changed or not.

One could send a dos packet where data is the packet structure itself...

If planning to support arbitrary *new* m68k software calling arbitrary *new* AROS code, this might be an issue, but what would be the point of supporting that?

The 68k code will never know is it calling 68k or native AROS code. It just assumes everything is 68k.

Thanks to OS 2.0 API design 68k code could be executed virtually everywhere in AROS userland. You can have filesystem hooks, you can have layer hooks, you can have input handlers, you can have interrupt handlers. The system also allows peeking into system lists, library bases, initialize system structures your own and modify them at will. You can edit your message port structure and changes are immediate.

If only supporting m68k software interacting only with AROS versions of software available for 3.1, then the set of possible software is for all intents and purposes pretty much finite and unchanging and it's just a matter of how adding mappings as/when problems are found with specific applications.

What I am afraid that when you add mapping for one data structure it contains pointer to another data structure you have to map as well.

I won't speculate about whether or not current Emumiga does it the right way, as I haven't read the code, but this is by no means an unsolvable problem.

If we had unlimited resources we would have conquered the stars already :-P

[itix]

Exactly the point! Emumiga is intended for old binary-only stuff. New applications are hopefully open sourced and/or running natively on x86 AROS.
Emumiga relies totally on that AROS is implementing AmigaOS3.1 close enough.

Does it work with applications using BOOPSI subclassing?

[itix]

As for handling the hooks, again, why do you think this is even a problem? It is no different from handling any other part of the system - you need to trap any attempted read/writes from/to the "host" and translate appropriately. Tedious, sure, but not much more.

If you think it can be done in filesystem context, ok. I was thinking it would be too slow and thought about implementing ExAll() emulation in Emumiga. My mistake.

But more importantly, since the number of possible applications is small and finite, if there are any particularly troublesome applications you can add workarounds for that specific application.

This is a shortcut for rewriting a subset of applications - it doesn't need to be perfect. It needs to work for the m68k applications a reasonable number of people still care about and where it's not easier to port an existing alternative application instead. For the rest there's UAE.

There arent that many applications indeed. But dont assume people wont try all kind of exotic applications.

I think a lot of those of you that think this is so hard are massively overestimating the scope of this.

I think you just dont know Amiga software very well. If AmigaOS design was kept easy and simple like it was in Kickstart 1.3 it could even work. In release 2.0 Commodore developers really screwed it up.

We don't need Emumiga to be able to run every legal m68k Amiga app - the only reason to do that would be just to say you can -, just ones already in existence. We don't need Emumiga to even be able to run all of the ones in existence, only the ones that people want to be able to run regularly on AROS with tight integration.

So Emumiga will be tailored for each application? My wish list would be very short: Blacks Editor because it is still the best text editor for Amiga. AmiNetRadio and dynAMIte could be nice to have, too. I can not remember any other useful 68k applications/games anymore.

There's no doubt Emumiga will be a lot of work, but even if you have to add manual workarounds for a lot of the applications in the "interesting" set, it'd still be feasible.

When working on OS4Emu I added manual workaround for every known hook in MUI (this because ABI is different in MorphOS). If you love that kind of stuff, nice. I can compile list of MUI hooks if it is any help with Emumiga development.

It's fairly simple to automatically create thunks to handle this. I've written enough compilers with custom object systems to have done far nastier things than that.

Hmm? Do you realize how often OO application are going to have context switch between 68k and AROS native code? You can not even figure out when 68k code is calling native AROS code because it is nothing but jsr() to a pointer. Nothing is going to tell you 68k code is trying to call AROS BOOPSI dispatcher code. This is not only Zune/MUI related issue but concerns all BOOPSI driven applications and classes.

This problem is related to 68k hook implementation. BOOPSI dispatcher is an extension of struct Hook -- if there is any chance that 68k code could call your BOOPSI dispatcher or hook function you are in trouble.

Just ask how many problems the OS4 dev team had with their MMU driven context switch code. It never worked properly and they went to trap based implementation. Since AROS can not use traps I dont see how this could be handled at all.

But back to data endianess problem. How do you can really know what kind of data structure there is behind Object pointer? Depending on object type its data structure extension is different. Are you going to detect data structure format based on its pointer + allocated space for object?

(Obviously naive endianess swap in 68k emulation code can not work because data could be written to the disk for example.)

Since the m68k side is emulated, you can easily lazily mutate data first when it's actually needed on the m68k side. Will it be slower than "just" emulating everything in UAE? Maybe, but frankly it doesn't matter with the performance of modern x86 hardware.

Anything that executes 68k code faster than real 060 is already enough and 020 level of performance is still acceptable. It could be an issue in the operating system code i.e. when executing layer hooks where multitasking is suspended.

[itix]

And *this* is the point. While I'm sure there are people who use many, many more m68k apps, the total number that people actually use is still fairly limited.

But seems you can only run simple clock application nobody really need...

I really like Emumiga approach because it tries to bring something new, explore and research. But seeing even very simple data structure like MsgPort (only 40 bytes) has limited support I dont feel confident it is feasible for large applications.

Yes, the m68k emulator would, because it would know that the target address of a JSR etc. is an address that corresponds to a function exported from the host environment, rather than m68k code. This bit is trivial.

It would know when 68k code is calling AROS native code but it would not know how to map 68k params to AROS native code. If you look at hook definition you will find out it is (almost) always standard. However, with DoMethod() call it is more complex because it is a vararg call. You know, DoMethod(obj, method_id, param1, param2, ....) where parameters are pushed to stack and pointer to params is placed in register A1. You can map 68k register to native AROS but what to do with parameters in the stack?

In theory you could always swap endianess of parameters... but how many parameters there will be? You can check method_id but it is not unique. There is no terminator nor there is any number in front of parameters indicating count. Keep track of AROS native objects so you could actually match method_id? Maybe... could work if you dont include Zune.

You could also subclass BOOPSI classes so neither 68k or AROS code would never call directly real dispatcher but go through emulation dispatcher first. However, you have to support large number of methods and tags here...

Btw similar problems will appear with CallHookPkt() (nice vararg call) but you are left without subclassing option.

This only ever matter if it's a data structure "exported" from AROS to m68k. The subset of data structures that are worth exporting *and* that m68k code would legally try to access is limited, because it is limited to only libraries that are used  by m68k code *and* where it makes sense for the m68k code to call the AROS native version of the library rather than a straight m68k version. They don't *need* to be able to call the AROS native versions other than where it impacts integration.

Library wrappers are easy. Call AROS, done. Call AROS, done. Call AROS, done.

E.g. you don't strictly *need* it to be able to call the host version of Zune, for example (while it might be desirable), since Zune doesn't need to run in a single context for all applications in the system.

If you run another instance of Zune in 68k context then things get easier indeed. The same probably should be done to datatypes.

There's a tradeoff between how complicated you make it vs. how tight integration is really necessary - the less integration, the closer you get to the Janus-UAE model. The more integration, the more work to translate data structures etc.. It's not either/or.

More or less Emumiga is stripped down UAE. In other words there is 68k CPU emulation and modified Kickstart image. It does not matter how library call are processed as long as parameters and results are kept in big endian mode.