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

[vidarh]

Anyhow, an observation in regards to the AROS votes...

I've a strong feeling none of these guys have ever used MorphOS in the long term. You would not believe how well polished this OS is. I mean really!!!

As someone who voted AROS: It doesn't matter how polished MOS is. My reason for voting AROS is that it's open source.

[vidarh]

Anyone claiming AROS will run on "any old PC you throw together" is completely insane.  AROS is pretty decent once you find the "magic solution" of what it works on HW wise, but I've never seen a more finicky mess of an OS.

Box 1 - AMD X2 4200/7800 card.  Aros doesn't see the SATA side at all.  Try and run off IDE HD's, AROS just locks up.

Box 2 - far newer machine, Intel quad core extreme, nvidia 9800.  Gfx card issues with AROS, but SATA works fine.

Put gfx card from box 1 into box 2, box 2 works half assed, but has wild banding and screenmode issues.  Give up, go buy beer and throw the CD away for another 6 months.

It's only a few years since Linux was pretty much in the same situation with. It's down to getting enough developers to get more driver support, which will take time.

In the meantime, yes, you need to be careful about what hardware you pick *or* run AROS Linux hosted without a windows manager (which will make the AROS window run without any window borders etc.), which will run everywhere Linux will.

AROS 68k seems interesting, but still comes back to the fact I don't like using legacy Amiga HW, simply due to its' age.

Well, Natami and FPGA Arcade will take away the "age" issue.

[vidarh]

Bloodline: Is it as good as WorkBench 3.1 or better? Also, how's it work with the resources? How does it run on a stock A600? Is it fully compatible, is the speed I'd expect from WB 3.1 intact, or would I need something more like an 030?

Likewise, how does it handle with something like a 50to80Mhz 060 with 32 to 64Mb or RAM?

It's very much a work in progress and full of debugging stuff and lacking lots of optimization still, and it's still slow. If you want to help send bug reports, try it.

Otherwise hold off at least 6-9 months and ask again - it went from not working to a decent state in about that time.

[vidarh]

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

No, but it can support every known one, and since the set of m68k software is fairly static I doubt that will be that much of a problem as long as a smart method of defining translation mappings for new libraries is added.

A lot of things that are "impossible" for the general case are fairly manageable for the restricted case of handling a, for most intents and purposes, mostly unchanging set.

[vidarh]

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

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

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.

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

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.

[vidarh]

X86 is the only mass produced CPU we have

If you mean to claim that it's the only mass produced desktop CPU we have it might open for discussion, but to claim it's the only mass produced CPU is flat out wrong.

Even if we were to pretend that MIPS, SuperH and PowerPC doesn't exist for various reasons, there's still ARM, which sells is vastly greater quantities than x86.

[vidarh]

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?

No, I'd suggest supporting the known packets *with known uses* by *known apps that people still care about*. There aren't all that many, and the mapping is fairly mechanical and can to some extent be automated (you'd need to describe the fields, but there's no need to manually write all the code).

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.

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.

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

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.

For apps that people rarely if ever run or want to run other than the occasional trip for nostalgia and/or that doesn't need any form of integration (like most games and demos), there's no point - Janus UAE is sufficient.

This isn't like Wine where there are millions of apps that people want to to run, and where tons of apps are still actively developed for the Win32 API that are not being made available for Linux, and that drives people to want and expect Wine to run "everything" (even then: I for one have noticed how the interest in Wine has waned since virtualization meant that people increasingly only care about Windows apps that they want tightly integrated with the rest of their desktop)

There are "only" about 30000 m68k archives on Aminet that are even *potential* candidates (when you've excluded MOD's, demos etc.). Beyond that there are a few thousand commercial applications at most. I don't know how many of those are still interesting enough to care.  Games (barring possible "workbench games") are outside the scope of Emumiga.

My guess is that 5000 packages that would be even worthwhile for Emumiga to target would be seriously overestimating it, given that a ton of those 30000 either won't be code, will be various old versions, utilities that plain doesn't make any sense anymore, apps that nobody uses, apps that are open source and better handled by porting/recompiling for AROS etc., or apps that have already been ported.

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.

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.

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.

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

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.

[vidarh]

Hmm... not sure why you think that no-one still uses all these old apps anymore, I do, every day...

Bloodline has already addressed UAE + AROS m68k being able to run "everything". But let me just address the point above:

No, I don't think no-one uses *most* of these apps anymore. Sure, there are plenty that *are* being used, and those would be great to support.

But I'm willing to bet that even you are not using 30000 m68k applications on a regular basis.

If nothing else because a huge amount of them are redundant (multiple versions, multiple tools that does the exact same thing) or have been obsoleted by newer m68k apps, or not even apps, or have hardly been downloaded.

E.g. in the util/app category, to pick one at random, there are archives that have only been downloaded 2-3 times since they were uploaded in '95/'96. Given that a lot of the time people will download files just to check things out, and the number of users that have fallen off since the 90's, we can safely assume that a fairly substantial number of applications with downloads even in the hundreds are not being used by *anyone* anymore.

On top of that, in that category alone, a bunch of the archives are catalog files, and there are umpteen different generic app icons that does almost exactly the same, and a bunch of different versions of the same apps.

This is pretty much par for Aminet. In other categories you'll also find tons of icons, graphics, documents etc. mixed in with the applications.

So for starters the actual number of unique applications is far lower than 30k, and of those the actual number of applications with unique functionality is far lower than that again, and only a subset of  those are still being used by anyone simply because there are so many that overlaps and so few users left.

Even then, there's no point in Emumiga handling them if none of the people using those applications have any interest at all in running Amiga on a non-m68k platform, as on m68k they'd be able to run them straight on AROS m68k or AmigaOS..

That's why I think that the actual number of applications there'd be any point at all for Emumiga to support (as opposed to UAE which has as a goal to be a faithful emulation, or AROS m68k, which should work as documented, both which should aim to be able to run far more) is somewhere well below 5000.

[vidarh]

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.

My point about scope is that the number of applications that it needs to support is fairly manageable. It doesn't need to support every possible "legal" thing an AmigaOS app can do simply because not every permutation of legal things are actually being done by existing, still useful AmigaOS applications.

So Emumiga will be tailored for each application?

I don't think that's the goal, but if it's *necessary* I don't think anyone would object to it. That's the point.

 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.

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.

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.

Of course you can. Any AROS code that's made "visible" to the m68k code would need to be "mapped" into the m68k apps address space. It's then absolutely trivial to make the m68k emulator detect when the m68k core tries to access an address that would bring it into AROS code.

 Nothing is going to tell you 68k code is trying to call AROS BOOPSI dispatcher code.

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.

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?

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.

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.

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.