I wonder if next MorphOS major version will support 64bit and or SMP at same time.
Or it can be safer to introduce them each at once? And again do you think there will be still a PowerPC support or all these new important features will be reserved only for x86 version?
..And in the end there will be ever an ARM RPI version of MOS?

Good luck getting an answer to those questions.

(But then again, you never know… )

Thanks! 😊

64bit: maybe (many pointers will fail)
SMP: no (even AROS has no support)

>> do you think there will be still a PowerPC support or all these
>> new important features will be reserved only for x86 version?

> 64bit: maybe […]
> SMP: no […]

I think if MorphOS 4.0 (or whatever name/number will be chosen) will be for x64/AMD64, it will support both 64-bit and SMP for sure :-)

Quote:

I agree.
My hope is to see a first SMP implementation on dual/quad g5 and then later on x86.
I don't know how is difficult implement 64bit support but a solution could be add an extra flag on elf executables to run them in extended mode.

Morphos could be the first amiga like os to make it real because it's the most advanced in it's basics among others.

Hyperion claimed in 2011 that SMP wouldn't take 2 years.

I understand your point with SMP on your existing PPC. But going true SMP breaks compatibility, it's as simple as that. Not only binary compatibility, but also source compatibility. AROS had this experiment called "Silly SMP" which aimed at squeeze in SMP in an Amiga environment. A little hacky IIRC, and not perhaps the most optimal and cleanest way to implement fluid/modern SMP, but it was indeed very close to the Amiga Exec in a way (they had focus on that, rather than some clean-slate implementation using the current best science/knowledge). Small changes to sources and recompile became mandatory. Same with true 64-bit IIRC. The apps must be aware of the new boundaries, old apps assumes the traditional Amiga environment.

With compatibility broken it doesn't make a lot of sense IMHO to stick to the PPC instead of migrating to a modern CPU architecture with modern muscles and peripheral specifications. Better set the compiler to output binaries for AMD-64. Having two parallel CPU architectures going at the same time may risk spreading any remaining support from the few third party developers rather thin. Wouldn't it be better to focus all the new efforts onto a single target platform? But that's only my opinions, and again, who knows...?

Quote:

Cut the cord to the past and implement a clean-slate solution, and it can probably be done rather quick. Problem is people expecting the new system to seamlessly run old world apps. But strictly speaking it won't be "Amiga-compatible" anymore, even though it will look and behave the same at first glance.

Quote:

Morphos is evolving by little steps.
Implementing new features on existing hardware can make devs more confident porting new system into a foreign platform.
I think this strategy can make sense and at same time let enjoy existing user base with current hardware.

Quote:

I am really curious. Why on earth are we still trying to have compatibility with the dead old classic Amiga software? MorphOS working on a powerful 64bit AMD multicore system with seamless Amiga emulation integrated to the OS sounds like a perfect deal to me, rather than imprisoning ourselves in the 90's just to have compatibility with seriously old and mostly useless software.

I am an Amiga user for 30 years, but isn't it time to move on?

I fully agree with you Caterpillar

I don't! Most user-SW on MOS is Amiga68K. In case of a hard breake, there is not very much (beside that was MOS-team delivers) And I really doubt that there are so many proggers out there, to reemplement SMP-SW or write new from scratch in short time (or even long time).

Next: Whitch definitive hardware? It's not done to say let'go x64 or AMD64! Every PC and Notebook out there is different! On chip-level, there is no real "standart"! E.g. there are so many different peripherial-chips used - who writes the drivers for all of that under MOS? If there will be a plattformswitch, then only to some selected hardware - but never to those everday-PCs at you can buy in supermarkets......




[ Editiert durch Amigaharry2 10.07.2021 - 20:59 ]

Quote:

I'd say I haven't use much (any?) 68k since Scribble/FlowStudio matured to the point that I could retire GoldED

Quote:

There is no such thing as "x64 or AMD64", it is all AMD64 and has been for over a decade. As for drivers most stuff works in some sort of legacy mode, so worst case is something like running an USB3 port at USB2 speed and having to install an ancient GFX card.

Now I'm sure it is a bit more complicated like that, but not as bad as it was with older HW, like the 2001-2005 PPC-Macs we use today each requiring dedicated support in the boot.img just to get started.

> Most user-SW on MOS is Amiga68K.

That's individually different for every MorphOS user, I think. I for one have certainly way more PPC binaries on my system than m68k ones.

> I really doubt that there are so many proggers out there,
> to reemplement SMP-SW or write new from scratch in
> short time (or even long time).

MorphOS already has performance-critical software that could easily make use of hardware threads because it is ported from SMP-aware mainstream code, like WebKit or FFmpeg.

> there are so many different peripherial-chips used - who writes
> the drivers for all of that under MOS? If there will be a
> plattformswitch, then only to some selected hardware

Yes. MorphOS on x64 will only support those x64 boards that have supported chips (or expansion slots for cards with the supported chips), certainly not worse than MorphOS on Power(PC) only supporting those Power(PC) boards that support has explicitly been added for. The MorphOS team has been absolutely clear about this.

> but never to those everday-PCs at you can buy in supermarkets

I wouldn't rule out that MorphOS for x64 may happen to support a board, by chance more or less, that ends up in a supermarket PC and happens to contain supported chips (or expansion slots to use cards with supported chips instead of any unsupported on-board chips).

> I'd say I haven't use much (any?) 68k since […]

Completely going without is difficult because of ARexx.

> There is no such thing as "x64 or AMD64", it is all
> AMD64 and has been for over a decade.

Yes, for 21 years regarding the ISA and for 18 years (AMD) or 17 years (Intel), respectively, regarding the implementation :-)

Quote:
Or maybe not... I think we can do it without 68k rexxsyslib.library too. You can send ARexx commands to programs without the 68k library by the RXCmd command already, and ARexx scripts can be replaced with Lua scripts (I've converted many of my old ARexx scripts to Lua).

Also old complicated ARexx scripts you may have are usually for old 68k programs that would stop working in any case :) So ARexx doesn't matter that much anyway...

But that said, there are still few 68k programs that are important to me and would be a shame to lose them... for example Magellan2 (new native open source versions are too buggy to be usable), ArtEffect, FXPaint, PPaint (I don't know if anyone will ever finish the MorphOS version), CubicIDE, AmiSSL, DCTelnet, FinalWriter, PageStream, and some other programs that I use time to time... and some shell commands and libraries too. And few games and demos...

[ Edited by jPV 11.07.2021 - 11:17 ]

> You can send ARexx commands to programs without
> the 68k library

Yes, I've always found the terms 'ARexx port' and 'ARexx command' to be misnomers because it's really a generic message port that commands can be sent to from virtually any language.

> ARexx scripts can be replaced with Lua scripts

This may be the difficult part for mere users :-)

> old complicated ARexx scripts you may have are usually
> for old 68k programs that would stop working in any case :)

Good point.

Quote:
Between the lines I also meant that forthcoming needs for (ARexx) scripts can be replaced by writing Lua scripts :) We're not out of application scripting language even if ARexx would be lost.

Quote:

Can't we just emulate them? I mean something like WHDLOpener integrated to the OS would answer many backward compatibility concerns.

I agree on focusing on a specific hardware, rather than trying to implement wide range of drivers (it is even against the whole idea). There can be even specific, pre-built boxes.

In this way, MorphOS can become a very serious and modern option for those people who buy stuff like a Pi400 or an FPGA just to receive the "Amiga feeling". And let's not forget, those boxes are just light-speed fast hardware that run dead-old software for nostalgia.

I'm just a regular user though, there might be a specific benefit that I might be missing.

"Nostalgia is a seductive liar." -George Ball

Quote:
In that kind of solution the emulated environment is isolated from the actual operating system. It can be fine for games that don't have to interact with the operating system, but for productivity applications it would be clumsy at best.

From the programs I listed, Magellan2 should have access all locations in the filesystem, should work when you drag&drop files between Ambient, Shell, etc, should be able to install global hotkeys, etc, etc which just wouldn't work when isolated into emulation. I use CubicIDE to develop MorphOS programs, so it wouldn'be able to run and compile everything under emulated environment. AmiSSL and other libraries and commands are to enhance MorphOS, they would be useless in an emulation box. Some paint programs or maybe even word processors could be a bit better experience, but still they would be limited by filesystem access, ARexx ports, they couldn't take advantage of MorphOS native system components like they do now... also clipboard sharing and stuff like that would get harder... programs would also be non consistent because GUI elements and MUI versions etc would be different on 68k emulation box. It'd just be a no-go for me and I'd have to find solutions to replace my needs by other programs and make compromises...

> Can't we just emulate them? I mean something like WHDLOpener
> integrated to the OS would answer many backward compatibility concerns.

I can speak only for myself here, but the experience of running an OS-friendly application directly on MorphOS is very different from the one running it on AmigaOS that in turn runs inside E-UAE on MorphOS. From those jPV mentioned, Magellan2, CubicIDE and AmiSSL wouldn't even make sense running them inside encapsulated emulation.


Edit: too slow ;-)

[ Edited by Andreas_Wolf 11.07.2021 - 20:50 ]

And I take my words back regarding word processors... they and DTP programs, spread-sheets etc would also be useless in an emulation box, because I wouldn't be able to print from them.

And in emulation all program windows would be stuck in the emulation window and wouldn't be freely placeable and re-sizeable...

There are just too many drawbacks in that kind of solution to be usable at all.

I'd trade these disadvantages for the ISA switch.
And I guess with an ISA switch and with a moderately modernized API some new momentum might get induced.

Sure, it would be a break and not everyone's cup of tea, but w/o the ISA switch se're doomed anyway as ppc is. Ultimatively I don#t see muchof an alternative.

I'd not want to lose the ability of being able to use some of the older "legacy" software that was "born" on the Amiga 68k Workbench era, such as, PageStream, Photogenics, ImageFX, Photofolio, MakeCD, FryingPan, etc., that I still find very useful within "Trance" of MorphOS.

So, for me, switching ISA would need to offer such capabilites, such as a 68k OS compatible emulation, i.e. "EnTrance", for 64-bit that would allow such programs to still work "inside" MorphOS, if that would be possible?