Only to be understood as an idea...

Take the concept - Amithlon - (Linux kernel + AmigaOS emulation + corresponding Linux/AmigaOS drivers) and replace the AmigaOS emulation with - MorphOS - and you would have a MorphOS that runs on a significantly larger number of hardware apart from PPC.

Bernd Meyer has demonstrated that this is possible with his Amithlon. Fortunately, there are no license problems with MorphOS.

Wouldn't that be worth considering?

Übersetzt mit DeepL https://www.deepl.com/app/?utm_source=android&utm_medium=app&utm_campaign=share-translation

The demo bigfoot did some years ago did already "solve" the issue of getting MorphOS to run on AMD64.
Putting a Linux kernel under it would widen the HW support with little to no effort, but there seems little to no taste for that kind of shortcut in the team.

Bigger issues not solved by using Linux (wether the kernel for an Amithlon clone or a whole distro to run QEMU):
- flipping endians around wich will either break compatibility or reduce performance
- getting minimal viability for users to adopt it and developers to port their SW when both are dwindling as it is
- moving MorphOS beyond single core/31Bit

> Bigger issues not solved by using Linux […]:
> - flipping endians around wich will […] reduce performance

My impression was certainly not that Amithlon's performance loss induced by the endian flipping was a bigger issue. AMD Athlon had multifold performance of 68060, like current Intel/AMD offerings have multifold performance of fastest G5, so the performance hit would be quite negligible.

> - getting minimal viability for […] developers to port their SW

Luckily, Amithlon-style solution allows running native and non-native software transparently side by side. Native ports increase performance, but are not mandatory.

Quote:
But it already exists and its name is WorkbenchOS:
http://workbenchos.prismadigitale.it/

You can talk all the world about Amithlon or fast 68K CPUs. It does not fix the main issue of AmigaOS.

The memory limitation is 2GB, there is no real memory protection and only one core can be used properly. Even a 64GB X64 board will not remove these limitations.

It needs a new and incompatible OS to fix the real problems. You can speed up the processor as much as you want, but those issues will always be there.

>> Take the concept - Amithlon - […]
>> and replace the AmigaOS emulation with - MorphOS

> But it already exists and its name is WorkbenchOS:
> http://workbenchos.prismadigitale.it

Neither is this anything about MorphOS nor does it resemble the Amithlon concept in any way.

Quote: So, is this new OS and hardware that's needed still being assessed, or is it further along than that?

Is some form of backwards compatible MorphOS 'Classic' emulation going to be required, even if only initially, if we 'jump' to a new architecture?

Does this work require a cash injection, just a leap of faith, or something more?

Quote:

No, you just need to run multiple OS instances at the same time.

https://vimeo.com/191163338

Even on very old PCs you could theoretically easily run hundreds of OS instances at the same time.

Quote:

And how does any of those instances add memory protection, more memory or multi core support? It does not. You just get all these instances with the same old limitations and issues. You still need a new operation system, which will not be compatible with old software.

Quote:

What does your statement mean with regard to the further development of MorphOS?

Will there be two branches of development in the future?
One is MorphOS 3.x, which continues the current MorphOS on the PPC track. And MorphOS 4.x, which contains memory protection, no longer has a RAM limit, has backward compatibility through MorphOS 3 emulation and runs on other architectures.

Übersetzt mit DeepL https://www.deepl.com/app/?utm_source=android&utm_medium=app&utm_campaign=share-translation

[ Editiert durch ThorstenS 12.03.2024 - 06:36 ]

Quote:
Yes. (In theory.) Every company creates such a break of foeatures in a new branch. They don't want to break compatibility in the old branch because then they can still deliver updates in the old branch. and emulation should be fast enough these days.

In practise I have little hope. Since the announcement of MorphOS 4.x and the demo on amiga 34 we haven't heard about it anymore. It is almost 4.5 years now. bigfoot is the only person working on it and instead of completing this he writes graphics drivers for his bounty (if he has electrictiy which is the next problenm). Yes it gives him money but the general development of MorphOS is kind of stalled. we are still limited to almost 20 year old retro machines. everyone is waiting for the switch that is long overdue and does not happen.

Quote:

As geit said. and with hundreds of VMs you will still have no communication between them like ARexx or copy and paste. And if a single program wants to have more than 2GB of RAM (or even 1.7GB) it cannot have it. and then all the other limitations. No Unicode in DOS for Shell and the filesystem and in the UI (only a few programs can show it and even these only very limitied). No AppIcon handling or drag and drop between the VMs. No common file system or Commodity handling. you need it extra in every VM or emulation or what you use. It even makes it much more complicated to exchange data than take the chance and finally throw away all the limits and make MorphOS 4.0 ready. but I guess we are not lucky to see it in the next five years.

Quote:

You have one instance per (big) program. If on Linux or Windows you run two copies of UAE and in first one you start "Lightwave" and in second one you start "OWB" then you have memory protection between them. Crash in one, doesn't affect the other.

In the video (with keyboard shortcuts) each time you see a new Amiga-style window appear a complete new OS instance gets "booted"/started and some program (incl. Doom 3 hw accelerated) within loaded and launched. There's only one (big) program per instance.

Code:

You can have 32 bit versions of the OS instances and 64 bit versions which you can mix however you like. You can have 10 big 32-bit programs each using 2 GB of RAM. So that already gives you more memory. 64 bit compiled programs would run in 64 bit OS instance and get you much more memory per program. 64 bit can still be same old compatible API incl. fast Forbid/Permit, etc.

multi core: between OS instances you get it for free (run 2, 3, 4 copies of UAE and Win/Linux will share cpu load among available cores. "OWB" may run on core #1, "Lighwave" on core #2). For programs themselves inside the OS instance there are multiple options: simplest for something like a raytracer is to launch render tasks as new/additional OS instances. Or have option for OS instances to be launched in multi-core safe way (for multi-core safe new programs) where necessary OS incompatibilities are activated (doesn't matter as you only run one big compatible program in it) like no Forbid/Permit (or very slow Forbid/Permit), no relying on hi-pri task never beeing run side by side with lower pri task).

Sorry. You cannot make the OS 64 bit compatible. It needs tons of work. The entire API needs a rework, as structures are currently out in the open and with all these 32 bit pointers those structures are also in every compiled application.

Most ppc software is available in C and open source anyway, so a recompile plus a few fixes should do. Only applications hacking in structures need massive changes.

So after making all changes to improve and add ALL the features, the OS can be used with UAE to get 68k stuff running. I personally only use one single 68k application, so I would not care beside of playing some old games.

I would rather drop all ends and go all in for modern stuff, than hack stuff together to get barely working stuff and don’t think we need PPC emulation at all.

> Will there be two branches of development in the future? One is MorphOS 3.x,
> which continues the current MorphOS on the PPC track. And MorphOS 4.x,
> which contains memory protection, no longer has a RAM limit, has backward
> compatibility through MorphOS 3 emulation and runs on other architectures.

Considering the personal resources, it's obvious that as soon as such "MorphOS 4.x" is released (if ever), the "MorphOS 3.x" branch will be discontinued.

> Since the announcement of MorphOS 4.x

To be fair, there never was such announcement.

> and the demo on amiga 34

...of MorphOS 3.x on AMD64.

> we are still limited to almost 20 year old retro machines.

X5000 is less than half that age ;-)

Quote:

Sure you can, see AROS 64 bit. You could not run old 32 bit apps/libs on 64 bit OS instance. Maybe that's what you mean. But you can run a 32 bit OS instance (ABox) on your 64 bit host OS (Quark/Linux/whatever). And with that run 32 bit apps side by side with 64 bit apps.

Quote:

That's also because you MOS coders from early on seem to have insisted that everything will always be 32 bit (and big endian) and even in code partly or largely based on code from somewhere else (which tried to be 32 bit <-> 64 bit and endianess agnostic) you did modifications/bug fixes/improvements that did not follow the future proofness ideas.

Gimme MopsOS AMD that runs PPC and recompiled code as fast as possible while maintaining compatibility

Gimme QuatchBox with memory protection and SMP even if it can only be used in a PowerUP style.

No half arse MultiTOS that fixes nothing

This discussion pops up again and again.

I wrote up my idea about an x64 migration 13 years ago: https://via.bckrs.de/MorphOS/q86.htm

Not much changed since then, I still think it would be the best approach:
A big endian "ABox" (with 68k Emu and flipped x86 code)
Native little endian code in some "MBox".

A bit similar to AmigaOS XL, but instead of QNX a native x64 MorphOS.

> I still think it would be the best approach:
> A big endian "ABox" (with 68k Emu and flipped x86 code)
> Native little endian code in some "MBox".
> A bit similar to AmigaOS XL, but instead of QNX [...]

H&P's QNX-based AmigaXL was just UAE running on QNX, i.e. there was full CPU emulation, no native code possible. Running MorphOS in QEMU on Windows/Linux/macOS is identical in concept to AmigaXL and has been possible for years (albeit only unregistered).

I know. Hence I wrote similar.
XL used QNX‘ Photon to launch programs, hence it looked like an intergrated system, albeit not different to other UAEs. Same is possible on all UAE systems and probably the default uae behaviour on most MorphOS machines.

Read my old text linked above. In a nutshell: Improve current MorphOS a little and make it (little endian) x64 and add an big endian box for legacy MorphOS stuff with big endian ABI for x64 flipped code and best with additional integrated 68k emu, ppc emu not that urgent IMHO asmost ppc apps could probably be recompiled to x64 BE.

Quote:

Actually the other way round:

What little to nothing I use in 68k can easily be pushed to UAE while there are so many little and big pieces PPC code around some of them may take some time before anybody bothers porting them.

I also don't think forcing developers to make 2 versions of non performance critical ABox components and apps will far too soon lead to them to not bothering supporting PPC.

Just to chime in here with some thoughts.
While I have not seen the code involved (its closed source after all), i dont think getting it over to x86 or ARM (which is better imho) needs to be as perplexing as people think.

All OS'es, and i would be very surprised if MorphOs was any different, has a HAL. A hardware abstraction layer. Meaning that you have top-level functionality that does not touch the low-level, platform dependent, hardware bound stuff at all. Everything above the HAL will recompile without much change.

The HAL exposes libraries that everything else above uses, so I doubt very much that the desktop itself, associated applications and so on talks directly with the hardware at all. If it does, then that is very poor coding -- and I honestly dont think MorphOs would exist if it was a "mashup" of hardware banging code above the HAL.

The HAL is the layer that deals with drivers and hardware dependent code. So it will load drivers (which in typical architectures is the *only* part of an OS that should bang the metal directly, except for the startup code).
During startup the drivers are initialized, they in turn collect info such as .. supported graphics modes, what is connected to the pci bus, the type of cpu, the amount of ram and it's addresses -- all the nitty gritty that an OS must have control over.

The OS then makes all this information available through it's system libraries, which is the AAL, application abstraction layer. Applications should never touch the hardware directly, only indirectly by talking to the system libraries -- who in turn talk to the drivers.
In some cases the lines between a driver and a system library blurs, but without the sourcecode its impossible to say anything about this regarding Morphos. But considering the body of work involved, I would imagine it's properly organized.

So -- in order to move to new hardware, you need two components: startup code first of all, and secondly, drivers for the new system. There will also be changes to the HAL since concepts that exists on PPC might not exist under ARM / x86.

Obviously this "sounds" very easy, but that is superficial. Each platform has a ton of infrastructure that does not exist on other platforms, which has to be taken into account. To be perfectly frank, moving to x86 makes little sense. X86 will be around for a long time still, but the entire market is moving towards ARM. In Asia Risc-v has more or less eroded the gadgets market already, and in 20-30 years my guess is that you will have ARM and Risc-V being dominant, while x86 will be what PPC is today. Unless Intel is struck by lightning and introduces a clean new x86 family that disregards all legacy instruction-sets for a new superset. Who knows, but ARM is where a fast, minimalistic OS such as MorphOs really could make a killing.

Then there is the Endian-ness question. Well, this will affect more or less every bit-mask in the NDK/SDK, which would mean every application would need to be recompiled. In the HAL, where bit work is used to talk to the hardware and drivers, every mask and value needs to be overhauled.
So the change will be somewhat radical.

But -- this does not need to be as dramatic as people think. ARM has instructions that can swap the bits absurdly fast. It would mean a single instruction extra per value, which would have very little impact on general performance. There are also some V7|V9 ARM cpu's that support both endians on cpu level, meaning that the firmware exposes a switch where you can chose which endian the system should use during startup. Sadly not all ARM cpu's have this, and it's very little used, so i would avoid that.

In terms of money, building up a larger userbase, I think ARM is the way to go. Yes Linux dominates the ARM market, but only because there are no easier systems to be found. The average person is perplexed by linux, and maybe 1 in 20 takes the time to read up on the filesystem and other technical things needed to use Linux properly.
A fast, easy to use and largely intuitive OS that has tons of software to offer could do very well on ARM. 68k Emulation is a bonus, if presented properly to a younger audience today.

But I think a clean break from PPC is the only way to go. Sure, cheap g4/g5's will be around for at least a decade more, but then the machines will become difficult to source. It is a shame watching a system like MorphOs, which has so much potential, limiting itself to PPC.

I sincerly hope the development team takes the plunge. It will no doubt be difficult, but if you could run MorphOS on RPI5, RockPI5 and so on -- the entire Amiga community would no doubt flock to it immediately. Which would mean income for the developers, and a viable path forward. 68k is dead, PPC is on it's last legs .. There are thousands of Amiga fans that would gladly pay to get something more modern and future proof that is not emulation.

[ Edited by wotanica 15.03.2024 - 14:22 ]

@wotanica

While I wouldn't mind an ARM port:

- MorphOS for the time being is single core and the best single core performance is in AMD64
-- closest ARM is Apple which would be a non starter
-- affordable and "open" ARM systems (rPI and the like) lag far behind

- none of the suitable ARM systems have proper PCIe so no Radeon GPU
-- what they do have is closed up GPU only supported by binary blobs

- AMD64 also has endian switching opcodes

- the AMD64 port exists in a raw state which is better than starting from 0 on ARM

- the imminent death of x86 has been prophesied for at least 35 years by now, won't happen any time soon

@Kronos
In my imaginary timeline i defined it as 20 to 30 years, so i dont expect x86 to vanish over night either. Most have also noticed that Intel especially is flooding the market ATM with affordable, cheap x86 SoC's. You can pick up an i5u with 8|16 gb ram and intel MESA for $50-$100 second hand (20 watt mobile version). I just bought 5 ThinkBox'es that i refurbish as gaming boxes for $180 with 1 year warranty, so x86 is not going down without a fight.

Single core is a problem, a complex one that touches on everything from memory management to process isolation and hypervisor modes, so yes, that wont be easy i imagine. One approach would be to thread the desktop itself, while running processes are limited to sharing a single core. Not optimal, but it would be interesting to see where that leads. I mean, node.js|deno somehow delivers acceptable performance as non-threaded runtimes, and it's async model have some synergies with Amiga's multitasking model (at least in principle, most likely not in technical terms).

The Rock PI 5 is probably the only "desktop level" Arm SoC that we have at the moment, bar Apple's M2|M3 architectures. Tests are en-par with an i5-2600, using more or less the same power (20-30 watts). I was quite impressed by it, it's miles ahead of Raspberry PI 4 (I have not done any benchmarks on PI5 yet, I am more a fan of ODroid N2+ and RockPi).

SnapDragon is coming with a new series now, made by the same people that did the M2 apple silicon. They quit apple and started their own company, and got bought up by Qualcomm. And unlike apple, their new Snapdragon will be a general purpose SoC, so there are "options" out there.

I write compilers and devtools for a living so I usually have an eye on these things, and i try to think 5-10 years into the future. And I really would like to port over my devtools to Morphos & OS4, but then I have to ask -- is it worth the 2-3 years of work to invest in the platform?

Like most things this boils down to money, accesibility (hardware etc), and demographic. While I applaud MorphOS and its developers for an amazing achievement, and I pay my license with joy, I cant help thinking that there is a lack of initiative in the NG camp lately.
I just forked out for an A1222+, just so I at least can work on that platform (and so I can say that I have supported NG through thick and thin), but I am perplexed at the lack of "vision for the future". I mean nothing negative about this, so please dont misunderstand me. I find it frustrating because I want MorphOS to succeed, grow and become the success it deserves.

As for emulation and supporting that, MorphOS could generate virtual hardware specs, hash the configurations, sign and crypt this to avoid tampering -- and offer a prefab download that includes qemu and said file-setup. QEmu is vanilla C/C++ so should not be difficult to mod it to use this special file-collection, much like Cloanto's RP9 system or vmware's virtual disks.
Heck, i would buy 5-6 licenses immediately and run these on my cheap i5 PC's so i can remote-desktop into them from my devcenter.

There are money to be made, but it requires some engagement.
I hope to see an AMD build or ARM build, I for one would welcome it wholeheartedly, and I know a lot more people that would also adopt it in a heartbeat.