>>we saw x86-64 version working a few years ago, It wouldn't be so strange.
Sure but how realistic is it to expect a (public) release this year? (take a look at the topic of this thread)
>>It makes no sense to upgrade if there's no support. Following your logic we would still be using a500 >>without mem expansion because there's no need to upgrade as most users have a500 and not ppcs with morphos.
Again "wishes" vs "expectations". Most current users are on PowerBooks, MacMini (+a few iMac) were a GPU upgrade is impossible and others are on AGP based systems where such upgrades are an issue. RadeonHD-AGP on G5 seems to be hit and miss, PMac G4 even worse (I couldn't get it to work) Pegasos impossible (they all seemed to keyed for AGP3.0). PCI cards do exist but would be expensive and slow.
Sure could be done, but should it really be a priority?
>>Powermac g4/g5, x5000 and future x86-64 would benefit from It. You don't need a new binary format, >>you'll need to upgrade your applications so these uses async processes and to use updated libraries >>that support AMP. It makes sense for reggae for example and probably for number crunching applications >>that don't interact with the OS. With single core cpus It will be yet another process, just like now.
Most important rule here: no half measures As in everything done in that direction needs to be done in a way it won't create extra hassle down the line. Sure you could do it in a way that allows such threads to just run alongside ABox, but what would be the gain? You'd still be limited to 2GB of RAM (maybe it'll kinda work with 4GB on G5/X5000) and most G4 users won't see any performance increase on their single CPU systems. But you did create yet another API that needs to be supported in future updates.
So no any "SMP" API needs to be fully 64Bit and have some "modern" features like memory protection. If those can run on the same core as the ABox, nice. If not you have further restricted the user base, and even this user base would only get limited performance gains.
>>Even if emulated It would be much better to have MorphOS running on cpus from 5 years >>ago than going to the dumpster to find 20 year old macs. A pitiful rpi4 runs m68k code more >>or less like the fastest g5.
Apart form Apple's Rosetta all PPC EMU range from bad to dumpsterfire, so unless the team puts a lot of work in it will not reach good performance even on fastest Zen5 core.
>>AROS does It. Compatibility with old apps wouldn't be expected. No half measures !!!
If the team decides to really go for AMD it needs to be sensible with it's limited resources. I mean it boils down to about 5 guys who could any of these lower level tasks.
As such any work on PPC should only be done if it can be easily be transferred over to AMD.
My list of priority (which is just the rambling of a guy who won't be doing any of it):
- get the old demo into a useable state even if on super specific HW - expand that HW support to a whole class of CPUs and motherboards (1st beta may appear here) - get non essential onboard stuff working (USB3, NVME, Sound etc) - define basic APIs for "SMP" and 64bit - push basic support for newer GPU cores (any APU would be the long term goal here) - create "user" API on the 64bit side allowing for pure QBox apps - select specific laptops for full support (we are way in the future here)
Upgrades to the PPC ABox would still be made by developers outside the "kernel group".
If on the other hand AMD is silently cancelled, then sure go nuts on obscure PPC stuff.
