Hey,

Can I say that I am heavily anxious to see an x86 MorphOS :D One huge advantage of having an x86 MorphOS is the ability to finally port WINE into MorphOS and this will open huge libraries of games and applications from Windows right into MorphOS which is superb! MorphOS would be truly BETTER than Linux in terms of an alternative operating system. Running WINE in MorphOS would be even easier and much funner than running it in Linux and best part of it all...it could be a layer in the next release of MorphOS that you can treat running any windows applications or games as if it is in Windows directly itself. Just double click it and you will not even see or feel WINE is doing the works in the back-end it will look like it is a native MorphOS application and you can even have customized icons.info as if it is ported to MorphOS directly!

Quote:


WINE is NOT perfect.

WINE is a bit Interlinked with Linux and Win DLLs and not an easy thing to port.

I would rather have Libre Office for MOS then Wine.

x86 MOS will NOT run on everything.

Have all these in mind, enthusiasm is understandable.

Check out this one to see why even a port to "x86" would not solve this easily: https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=11537&forum=12#124232
So what you in fact need is MINE, not WINE. MINE as: MorphOS is not Windows. Because if you just want to port WINE then you also need to have Unix/Linux functionality in MorphOS. This will bloat up MorphOS. I don't want that.

And better don't wait for MorphOS x86. x86 was replaced by AMD64, x64.

> what you in fact need is MINE, not WINE. MINE as: MorphOS is not Windows.

Actually, that would be MINW ;-)

Wine cannot run many Apps.
Wine on macOS for Example, is not very useful.
The only Game running on macOS-Wine I have found so far, is Trackmania Nations Forever.

Most of us want MorphOS x86-64 badly. I don't care about a Wine type solution at all. If it happened, great, but not something I need. If we need Windows that bad on the same box, we can dual boot.

WINE just wraps to Linux functions. The functionality has to be there in the underlying OS, which it isn't and never will be on MorphOS or any Amiga-like OS.

The clue's in the name.

Wine
Is
Not an
Emulator

WINE is nonsense.
Use Linux and a MorphOS VM

Hmm what a good idea, for start , using

Hmm what a good idea, for start , using a morphos wm inside of a minimal linux system with xen or other vitualisation, so we need only one driver for soundcard , one driver for graphic cards, a bit like in aros hosted....and with a small effort we can use linux apps inside morphos, so devs can take the more time they have to develop native and fantastic software.
It can be amasing in fact

Morphitlon?

Sounds cools, but I doubt thats they way the team wants to go, well maybe if the *nix underpinnings were as hidden and still integrated as they are with OSX.

I won't hold my breath, heck I want even hold my f#### ;)

https://twitter.com/chainq/status/1183005691482652672
https://twitter.com/chainq/status/1183013352706101248

Quote:

This is fantastic news!

It boots kind of slow though? Is it running native or is it the PPC version running emulated?

Looking forward to hearing more details about this...

I’ll answer myself, as I actually read what chainq wrote now:

“Do not draw conclusions from the boot speed. It is a very early version, and it is throttled by debug logging in the background.”

And indeed:

“natively on AMD64”

Still looking forward to more info though. Like is it true 64-bit? SMP?

Truly incredible and awesome! I can't wait to hear more about it as it progresses.

Wow, Mos on amd64 with integrated gpu would be a real game changer.
Having an up2date Webkit with Java script Jit and the system is usable again for daily business.
Good to see that the Mos devs going to amd64 instead of arm.

[ Edited by eliot 12.10.2019 - 16:56 ]

If it has memory protection, unix compatybility and good drivers, it may be usable.
Otherwise it will end in vb.

Quote:

Well the kernel has already memory protection. Within the ABox it won’t be possible.
There needs to be a new box and new api.
ixemul is already there, but better posix support would make conversions of
existing software more easy.

[ Edited by eliot 12.10.2019 - 17:30 ]

Also:

Quote:

Just quickly popping in to mention a few things...

... Boot-up speed is not indicative of general performance.

It had up till now been running on some older AMD64 hardware at home that I could neither bring along nor repurchase, so I bought this brand new system and still needed to port the existing MorphOS-on-AMD64 to this newer hardware. I literally only finished the port to this specific hardware enough to boot to Ambient this morning while at the show, and the whole boot-up process is full of debug code and debug output that makes booting very slow.

If you discount the relatively slow AMD64 BIOS startup, and the relatively slow network booting that I'm doing, then once the debug code and debug output is removed, the actual MorphOS bootup process is as fast as you'd expect it to be.

... This is not a finished product.

It's more a demo of some components of a future MorphOS NG system, in particular the new kernel that will power it as well as the PowerPC emulation that will ensure compatibility with existing software. So for now it's just a fun demo, please don't interpret it as more than that.

Let me just make this clear: This is basically a demo that's made up of components that are being developed with the goal of eventually reaching MorphOS NG. Not everything is there yet, but with what's there, it was possible to build this demo.

... AMD64 is a CPU architecture, not a specific CPU

Just because this seems to cause confusion from time to time. AMD64 is the name of the 64 bit CPU architecture commonly used in PCs. GNU calls the same CPU architecture "x86_64" and Microsoft calls it "x64". Although this hardware is indeed AMD hardware, it's not necessarily tied to AMD.

... What is "native"? :D

The kernel that powers this system is a new kernel written by yours truly. In the demo system on display here, it is (of course) running as 100% native AMD64 code and, yes, in 64 bit mode. The kernel also runs on both PPC32 and PPC64, and again as native 64 bit code on the latter.

The current demo system - and may I remind you that this is just a demo - runs a mixture of native AMD64 code and existing PowerPC code.

@Leo

That’s strange. It would mean that not only has a AMD64 version of 68k Trance been developed, but also a version translating PPC binaries. I don’t believe that really. Seems like a lot of work, and for questionable gains. It doesn’t seem plausible to try retaining binary compatibility with a 32-bit big endian platform on 64-bit little endian hardware. Besides, it was said back when AMD64 was first announced in 2011 already that work on 64-bit code would commence, and someone of the developers (bigfoot?) said here on Morphzone that it (a “MorphOS 4.0” or what it will be called) wouldn’t even be source code compatible (although requirements of modifications to code would be kept to a minimum). A migration to AMD64 would be a great opportunity to move on from the 31-bit A-box binary compatibility. Like AROS.

I think there is some confusion here. Maybe it has something to do with it actually being MorphOS 3.12 (version number seen in the video) compiled for AMD64, and not actually the new “NG” version?

@takemehomegrandma

Please read the comment posted right before yours :)

> PowerPC emulation [...] will ensure compatibility with existing software. [...] The current
> demo system [...] runs a mixture of native AMD64 code and existing PowerPC code.

Very interesting. How is the endianness difference handled?

@bigfoot

Thanks for the info, and thanks for doing the demo as well! Impressive!


Quote:

Got it!


Quote:

It would be interesting to hear about what this will be? The ambitions and goals, broadly speaking at least. Please?


Quote:

So the Amiga binary compatibility will remain? Will this mean that the whole MorphOS NG will have a 31-bit addressing limitation, single core, etc? Or that you are actually developing new stuff outside the “A-box”? If so, how will new and old stuff work together? Like applications, drivers and other resources on either sides of the box wall, how will they interact?

Well it obviously will be similar as multiple running instances of AROS hosted. With "outside" compositor of each of the instances' windows/screen bitmaps to make it look like it is one single "thing". This way endianess or 32 or 64 bitness of the single instances can be mixed however you like.