Supposedly, MorphOS is being ported to x86 – AMD64 to be more exact. MorphOS developer ‘bigfoot’:
I’ve mentioned it before, but I’ll happily mention it again: When MorphOS gets ported to AMD64, we will not be supporting Macs. AMD64 Macs have all the wrong hardware for that to make any sense. When such a time does come, expect us to support one desktop motherboard (with one family of CPUs and GPUs) and one laptop. We’ll of course make sure it’s hardware that’s actually available one way or another.
MorphOS has undergone a lot of development lately, and the currently available pool of hardware to run it on (G4-based Macs) has grown considerably. The developers have shown they are capable and willing to sustain relatively fast-paced development, which bodes well for the future. Porting it to x86 is the only possible way forward in the long-term.
No, it’s not. Or at least – not yet. He was speaking theoretically, about a possible scenario in the future. Also AMD64, as a possible MorphOS future option was mentioned years ago (pre-3.0) in a talk by Fabien Coeurjoly (of Odyssey Web Browser fame), that the team is considering other CPU options for the long run. AMD64 was mentioned along with several other CPUs, like ARM. However, either option is not really near future in any sense.
But if you like that, it’s a confirmation that MorphOS won’t go down the drain with PowerPC. But since support for more PowerPC systems is still in the queue, talking about anything else is premature at best.
Edited 2015-05-20 00:26 UTC
Well, WinUAE supports PPC emulation now, so the real question is, when is MorphOS going to support WinUAE?
100% agree. I think the long term future is UAE+MorphOS or an AROS x86 base + parts of MorphOS.
I don’t know MorphOS source code… but all the Amiga stuff that I know is pretty low level full of hacks and technical complexities… It’s not a simple “recompile for x86” thing like Unix OSes.
A 100% native x86 MorphOS port looks impossible from an economical/rational point of view. IMHO It will never happen.
There are three factors involved. Running MorphOS on x86, backward compatibility and the inherited ancient Amiga technical limitations.
It would be certainly possible (from technical PoV) to run MorphOS on any CPU, if you don’t have to obey the second, and if you don’t want to obey the second, you can start getting rid of the third. But – because of the demands of the user base and the developers themselves – it’s never that easy.
@Sergio
No offence, but you’ve come to some bold conclusions about MorphOS and you don’t seem to have much more than your own assumptions to base it on.
In MorphOS the Amiga-compatible stuff runs in a sandbox on top of a proper kernel and HAL. It’s not going to be a straight compile, but the extent of the work is something that only the MorphOS developers really know.
Sure, I don’t know the code as I said, It’s just my opinion… taking into account the small size of the team, the amount of time that simple features like WiFi support has taken in the past, the complexity of the work and the dubious economical benefit of it… I don’t see it happening (and I’m not sure if it makes sense having things like WinUAE with PPC support).
I hope I’m wrong though, I a MorphOS user myself and my PowerBook G4 begins to look like an ancient monster. But hey… I’m pretty pessimistic, sorry.
It won’t. WinUAE is not a virtual box anyway, it’s a full-fledged emulator. So if they want to run MorphOS, it’s up to the WinUAE author(s). Also it needs several ROMs to operate, with a debated legal status. It has several added limitations (for now) too, like limiting the emulated system to 128MB of RAM, and emulating only ancient VGA video chips.
If the team wanted it would be probably much easier to patch QEMU (for example) and provide some driver interface for acceleration (or a framebuffer) so the emulation and VM won’t be additionally “crippled” by WinUAE limitations. This was even demoed many years ago, when bigfoot ran MorphOS in QEMU: http://bigfoot.morphos-team.net/test/qemu.png
Don’t get me wrong, WinUAE is great, just not for this task.
I don’t know. Not one other developer contradicted him, nor reacted when people started to focus on the word “when”. Bigfoot is a core developer, he is in as deep as it goes. And his first language is English AFAIK.
Simply put, he should now what he is saying and how he is saying it.
MorphOS seems like it would be a good fit for ARM boards like the Raspberry Pi (2)…
Arm is tough, because of the different SOC’s out there. You’d also need something like Linux’s device tree to keep all the boards straight.
Except you there is no need to support all of them.
R-Pi and Tegra K1/X1 (GPU is supported by Nouveau) is enough. Everybody can afford R-PI. There are affordable dev board + some tablets and laptops based on K1.
$200-300 instead of $3700 Amiga board.
Even K1 is faster than any PowerPC and supports big-endian mode.
I am so happy and relieved to hear that their strategy is going to be much the same as their previous strategy in regards to hardware.
In a nut shell, support a finite selection of hardware combinations, in this case two, expansion cards aside.
Of course backwards compatibility with Amiga applications will be broken, but that’s what our old MorphOS machines are for anyhow. And there is always UAE, FPGA, and the real thing for the purists.
Can’t wait! Can’t wait a bit. MorphOS is very very mature!
Breaking backwards compatibility isn’t necessarily a part of the path to take. A PowerPC Amiga was the original 680×0 system with a PPC accelerator. A library was used to allow 680×0 programs to then run PPC code on the PPC, along with stubs to allow the PPC code to call system library functions. WarpOS and PowerUP were the two main ones, and I believe MorphOS is based on PowerUP. MorphOS replaced the 680×0 with an emulated 680×0 to run on PPC only systems.
For an AMD64 system, you would do the same thing – treat the AMD64 as an accelerator with a library to call AMD64 code just exactly as the PPC was handled. Then replace the 680×0 and PPC with emulated 680×0 and PPC (both of which are simple to emulate today). Recompile all your code to AMD64 instead of PPC and Bob’s your uncle! As long as you weren’t using (much) assembly language in your program (and no one does anymore), it would be dead simple to port a PowerUP/MorphOS PPC app to AMD64.
MorphOS put in a bunch of work moving the stub-to-68k library calls into native PPC calls, and moving to AMD64 would require the same kind of effort to convert to AMD64, but getting it working in the first place wouldn’t really be all that hard since most of the heavy lifting was done when PowerUP was first done. People working on that are used to the same wedges you’d need to do AMD64 from within an Amiga system.
This was easy to do between PPC and 680×0 because they were both big endian, whereas AMD64 is little endian.
This would require to byte-swap values when doing cross-endian calls, and it would get even more complex when passing pointers and structures containing pointers.
Executor does this for running 680×0 classic Macintosh software on little endian platforms, but in that case it’s easier since it’s single-threaded.
Another option would be to make the AMD64 code work on big endian memory, either by modifying the compiler (like for Stratus VOS) or writing the code aware of this.
I think amd64 has hardware support for that… since it is a biendian architecture.
Sparc64 does something similar for loads ands stores it makes it easier to write drivers for little endian devices like PCIE.
I’m not sure how applicable this since I don’t know how far amd64 carries it’s biendianess but it might work…
It simply doesn’t exist. All x86 are purely little endian.
True, endianness will be an issue, but I imagine that they’ll add a flag for little-endian structures/packets/etc, and the lack of said flag (the default for 68k/PPC) will tell the AMD64 libraries to bswap the data fields as needed. This is probably the BIGGEST issue, and kinda the reverse of what Amiga programmers are used to. For example, when I was helping work on inital ports of Doom on the Amiga, most of our time was spent finding all the places the WAD data needed byte swapping to work on the 68k/PPC. Doom for the Mac (and the 3DO, Jaguar, and 32X) didn’t have code for this, it used a special wad file that had all the data in big-endian format. That’s why Mac DOOM wad files couldn’t be used on the PC, or vice versa.
I wish Haiku some day realizes this. At the current pace, they will keep lagging behind the curve ad infinitum.
The problem of Haiku isn’t hardware support primarily.
And what is?