> old A1 [...] has 1GB [...] limit

Just like the Pegasos I, the AmigaOne SE/XE can take up to 2 GiB RAM. It's picky about it, though.

> that change [...] took a lot of work and complete migration to [...] PPC64 [...]

PPC32 is only 4 years older than PPC64 and has been superseded by PPC64 only in the last few years. So PPC32 and PPC64 had been lively supported by operating systems in parallel for at least 15 years without a general migration attempt.

Just to kick some reality into this thread...

While the focus of most people's attention seems to be "MorphOS on something not PowerPC", there are a few more issues at stake here. The main stumbling block is binary compatibility.

Let's start with the basics: since MorphOS is Amiga compatible, it also inherits all the design flaws of Amiga OS. One of those flaws is that all system structures are exposed to applications, and applications are not only allowed to, but often required to, directly access these system structures. Furthermore, all programs run in the same memory space and share all the same resources. These two facts combined makes it somewhere between incredibly difficult and impossible to change the layout of system structures and still remain compatible with existing applications.

Now, while you could possibly get away with MorphOS running on a little endian CPU by keeping all system structures stored in big endian format, and modifying the compiler to automatically byteswap all values when accessing such structures, such a MorphOS would still have all the limitations of the current MorphOS, it would just be running on a little endian CPU instead. Two major such limitations are the lack of 64 bit support and the lack of SMP support. 32 bit CPUs are between being outphased and completely dead already, so staying stuck in 32 bit land is not a real possibility. Modern CPUs, with the exception of some really low-end chips, are all at least dual core, and many have 4 cores or more. An OS that doesn't support this will also be firmly stuck in the past.

64 bit support would, amongst other things, mean that pointers would become 64 bits wide. This would change the layout of every system structure that contains a pointer, which would render MorphOS incompatible with every current application.

SMP would, amongst other things, mean getting rid of the 'ThisTask' field of ExecBase. This again would render MorphOS incompatible with every current application.

Given that breaking binary compatibility is a big and bold move and given that it's something we won't do lightly, and something that we don't really have the resources for, we can't address these issues one by one. We have to address them all in one go, or at the very least change the system in such a way that remaining issues can be solved without breaking binary compatibility again.

If you look at these issues as separate issues, the easiest one to tackle is actually porting MorphOS to a different CPU. By far the biggest issue making it hard to port MorphOS is the 68k compatibility. Throw that away, and you're looking at maybe a month's worth of full time work to have MorphOS ported to a different CPU. This, however, does not include the time required to write drivers for such a theoretical machine. However, as noted above, this alone will not solve the real problem(s).

So, in summary, the real problem is not getting MorphOS running on a different CPU. This is relatively easy. The real problem is the other changes that are required to make MorphOS able to make use of modern hardware.

As for the practical details, there are many ways this can be achieved. It could be that we choose to support PowerPC as well on a future MorphOS, or it could be that we don't. It could be that we decide to (and find the resources to) make a compatibility layer for current MorphOS applications. It could be that we don't. However, as per usual, we try not to announce any specifics until it's released, or at the very least until we're 100% sure we're gonna be able to pull through. MorphOS "NG", as OP calls it, is certainly no different. Unless someone slips up, specifics are unlikely to be announced or discussed in public until we're ready to demo something.

To answer the question of "is it still happening": No one, or at least I believe so, on the MorphOS team thinks there's a future in PowerPC on the desktop. That makes the path forward pretty clear: Adapt or die. The only question is how long it will take, given our rather limited resources.

@bigfoot

90 % of this can be solved by treating/thinking of AOS/MOS more as an "environment", than an operating system.

All you have to do is run multiple (maybe hundreds) AOS/MOS environments (which is extremely lightweight anyway) side by side at the same time under some real modern memory protected SMP OS like Linux or if you want even your own NonBackwardsCompatibleModernMorphosSMPOS.

In similiar way to how AROS hosted runs under Linux (or under other OSes).

So for every (or at least every "big") app you "boot" a full new AOS/MOS style environment process (depending on what AOS components the APP uses, you may also have different sized AOS/MOS environments to reduce host resource usage).

The apps end up in different host (Linux) process so are 100 % memory protected against each other.

You can mix 32 bit apps (booted from 32 bit environment) and 64 bit apps (booted from 64 bit environment) at the same time.

You get resource tracking for free (host process exits -> all resources freed).

Multi core: app #1 may run on core 1, app #2 on core 2. Not quite SMP, but still ...

A single 32 bit app may be limited to 2GByte of RAM, but all the apps together may use much more than 2 GByte.

Btw, isn't that Linux "Docker" stuff somewhat similiar in concept?

@Georg

A hosted MorphOS is a major turnoff for me.

@bigfoot

I just hope "die" isn't considered an option.

And as for me I wouln't mind a "clean slate" solution if that means you go wild and crazy and fix all those design flaws and make the system completely modern. It's not like our PPC machines will die in the process. Let them handle the legacy stuff. Then if this new MorphOS catches on you can work on legacy emulation.

My 2 cents.

We could imagine that Morphos could be ported to X64 or ARM64 but the main problem is how to assign this huge task
to a very limited staff......
As i see Haiku and Aros have huge problems even on X64

My bet is because a, they are very unfocused and b, because they don't have a finished operating system to work on. Especially Haiku.

Quote:

It already is hosted on top of Quark. If it wasn't for the exclusive resource (gfx hw, storage, input, ...) grabbing of the ABox you probably already could run multiple instances of MorphOS at the same time. Just move some more lowlevel stuff out of ABox into Quark threads/services/whatever.

The difference to AROS hosted is probably quite small.

But Quark is a kernel.

@bigfoot

Tanks for taking the time to white that answer!

Quote:

+1


Quote:

+1 again

Quote:

I think the task could range from "entirely realistic and doable for the current developers" to "huge, time consuming and difficult to achive" depending on how you actually define "MorphOS NG".

Quote:

Not really, quark is a micro kernel, thus not an OS in itself. You can't campare it to Linux, where the kernel kind of *is* the OS. The fact that almost all OS components, drivers, file systems, SW etc shares the same memory space (something that obviously is against a true micro kernel concept) does not reduce it to an "environment" that is hosted on top of another OS. Quark *is* a MorphOS component, and AFAIK there are actually a few MorphOS "service threads" that runs in their own Quark memory spaces (or "boxes" if you like) alongside the "A-Box".

@Georg: Seems you have ignored the problem of communication between processes.

Quote:

MorphOS Exec core (taskswitching etc.) is "hosted" and not really native. When using MorphOS do you notice this?

If some more components where hosted what disadvantage would that cause? Apart from the "hosted == non native == almost like emulated == evil" feeling.

For example if filesystems/storage drivers where moved out of ABox into host OS, MorphOS could get mostly immune to many of the evil things that bad/unstable apps/libs may do inside ABox causing filesystem corruption.

Quote:

For communication the hosted OS would use whatever features the host OS/kernels provides for IPC.

If Linux apps/processes A and B (or Windows apps A and B, or Mac app A and B) want to communicate, it's the same "problem" they have, too. But they all have some way to do this for things like drag&drop, copy&paste, etc.

On the AOS/MOS side it may require some things to be more complicated than it uses to be at the moment. Or there may end up having to be some limitations. Or you may loose some feature alltogether.

When using Linux/MacOS/Windows what AOS/MOS feature that requires communication between processes do you miss and think is difficult to make work on such kind of OSes (big isolation between processes)?

Quote:

Thank you for answering. i guess most ppl actually are aware that an ISA switch is more than just the ISA but would rather require the big change. As I wrote a bit above my impression is that the time for that big switch/cut is probably best about now. MorphOS is pretty mature, the top ppc hardware by Apple still not too old, easy to obtain and with power enough for many things, but only little more poential. Here and there you feel the age already, the RAM limit is annoying at least for massive browsing and speed is cpu power is quite okay fr many things, but the more the merrier.
In short: situation now is rather nice, but with forthgoing time that will change. Hence I'd say use the remaing comfort time (the time the ppc Macs cater us rather well) for the switch that will require quite some time.

I still like the approach I outlined a few years ago: http://via.i-networx.de/q86.htm . Lot of work though and easy to outline when it's not my job to actually implement and code it .

Zylesea got a point. I can't remember any time MorphOS had a better reputation in the general Amiga world than now. This is thanks to great updates, the laptop support with 3.0, OWB (and it's port to AmigaOS 4 which must have embarrassed HE a little) and the G5 port that gives us yet again the fastest machine (the X1000 didn't have that position for long).

I'm not saying that we need the actual port anytime soon. But maybe, just maybe it would be a good move to announce that the port is being worked on, even if it's just in the planning stage. It would most probably raise a lot of interest among the people who have been waiting for this and they are many.

I do understand bigfoots objections too. This is a huge task and time and resources are scarce. We have hardware now in plenty, they don't cost much, are well supported and they are not "ancient" yet (just a little old).

So I have conflicting feelings about this. On the one hand I want the ISA shift ASAP, on the other hand I don't want the Team to direct resources away from their current work plan since it's going so well as it is. You can't eat the cake and have it.

But if the Team have a suggestion of what we, the users, can do to speed up development I would be happy to hear it. Maybe doing the Haiku approach and have a bounty that will pay one developer one months worth of full time salary at the time working on a specific task. Or whatever. I want to help however I can.

And before I finish this long rant, I want to assure the Team that we do not bother you with this over and over again because we think you do a poor job. We bother you because we really really like MorphOS. This is a huge sign of appreciation for all your hard work. Just don't forget that.

That's it. I will stop bothering you now and let you get back to coding

> OWB [...] port to AmigaOS 4 [...] must have embarrassed HE a little

Why? Mind you, TW is not and never was an HE project.

True that, but it was ported by one of the Friedens, a core developer, and that does reflect back on HE nevertheless. But more importantly, the release of OWB source code was seen as a jest of good willl from our camp.

Quote:

I don't know about that... there are too many bad examples when something has been announced too early. And announcing this kind of thing would probably stop current sales and lots of people would start waiting "the next gen".. and we've seen how that goes, they wait until they get bored and keep using completely other systems while they could have been using and offering the support for current generation (and that way for the future too) happily for years. I don't know if we can cope with the loss in users if people start waiting something which probably comes only after 5 years or so...

In the Amiga World we have seen so many
Vapourware cases. It was frustrating, so
It's just one good thing about the MorphOS Team
they don't promise, they publish new versions.

I'm a happy ppc user.
The OS is nice and utilizes the hardware
at maximum.

It's obvious ppc has no future,
AROS made it possible on x86,
why not MOS?

IMHO, 68k compatibility must be thrown out.
I want memory protection and stability.
Programs could be recompiled for the new OS version.

@jPV

That's a good point.

Quote:

Not too sure about that. I think it could also have the contrary effect. Seeing a "secured future path" could encourage to join the MorphOS community now. Thing required would be that MorphOS NG would be as close as possible similar to current MorphOS.
Avoiding vapour announcements and broken promises is mandator though.

I just want to say this. (Some I might have said before.)

It would be nice to sometime in the future release a version of MorphOS which adds the memory protection and the support for multi core processors. There are PowerPC devices with multi core processors, even if they are old and end of life... or used, such as the PowerMac G5? Doesn't this mean that there could be PowerMac G5 with Multi Core Processors out there with MorphOS installed onto them, but not supporting the processors?? This is why I think they should be supported, even before an ISA switch. I think that the Multi Core Processors and Memory Protection is more important than the ISA switch. Yes I might be crazy.

And another reason is I think they are much, much more important compared to the 68K support. Continuing to drag this along is making MorphOS look embarassing. Just put it into an emulator, and / or port it to the MiniMig, if you desire the native 68K software support, with no need for emulator.

In conclusion (of this segment of the post), the Multi Core Processings need to be supported eventually. Didn't I read somewhere in these threads there are new Hardwares that all have multple processors?

I beg you to never make MorphOS hosted onto Linux. I use MorphOS to get away from Windows, OS X, and especially Linux.

I'd like an ARM or MIPS support, but if the ISA differences these days really are negligible, ...

I am not necessarily against X86 hardware support sometime in future, but the hardware must be affordable and not an overpriced Intel "Mac". I love portable computers, so I must have laptop. And I know that this is an impossible request, but I don't want to see PowerPC support completely dropped. If only MorphOS supported multiple ISAs.

Even sillier, I would like to see MorphOS pre-installed onto hardware.

Don't annonce anything. I like surprises. and I hate disappointments.

Thanks.



[ Edited by In_Correct 15.11.2014 - 03:02 ]

I think MorphOs is fine and there is no real need for MorphOS NG. You could redesign the complete OS, add memory protection, 64 bits support etc, but what would you (user) do differently after that?

From my perception, the OS is limited (as was the amiga) but it does what I expect it to do. Can I do my work on MorphOS? No. Missing are really good productivity tools, missing is decent task management (if an application really hangs and ignores a break signal, having to restart the system is so 1970) and there are many things that have become standard in all operating systems. Its a choice to adept or not adept good things from other systems.

Do we really need more and better applications? Obviously not, a lot of people probably have a second and third machine for serious work. So why change the engine of the car, if nobody is really going to drive 120 Mph afterwards.

I think the MorphOS devs are doing a great job, they keep MorphOS a nice hobby system, that I can play with.