Quote:

I will gladly donate Blackbird/Talos port of MorphOS.
For me AMD64 port have no sence ( on AMD64 there are many OSes for every type of use, and I simply have no reason use MorphOS there )

Quote:

Ok and why you do it on your Macs then? There is MacOS an Linux and NetBSD. So why you are using it with MorphOS???
Your reason is nonsens. And makes me laugh when i look at your signature.

> why would one want that?

See comment #21 for one possible answer to that question.

> it would be a dead end.

Raptor has voiced commitment to POWER10.

> let`s concentrate on the future with [...] GPU. [...] what i would like to see is not
> more drivers for every GCN Generation. Instead IMHO the MorphOS Team
> should concentrate the whole forte in [...] Polaris or Navi GPU drivers

Why Polaris (GCN4) or Navi (RDNA), but not Vega (GCN5), especially given that there are no AMD APUs with GCN4 (except on gaming consoles), while there are with GCN5? GCN4 support is what would make sense on PPC (X5000 and Sam460), as that's what's supported by OS4.

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=1215&start=184

Yes all Ryzen APUs are Vega right now. But the switch to Navi will come with Zen5. Maybe earlier with Zen4(Ryzen 5000 APUs).
So why making drivers for an old architecture then?

And some words to comment #21: We need progress. Apple is doing a 2nd switch in ISA in 15 years now. Why should we stay in the PPC niche forever and make the life harder as it needs to be???
The 68k JIT on x86 works great in UAE so i think MorphOS for AMD64 will have no Problem with 68k JIT.
PPC is another story. But i think most of the PPC Software that is used every day will get an x86 Port. And the rest i think will run good and fast enough on x86.


[ Editiert durch ThePlayer 21.08.2020 - 15:36 ]

>>> the MorphOS Team should concentrate the whole forte in [...] Polaris or Navi GPU drivers

>> Why Polaris (GCN4) or Navi (RDNA), but not Vega (GCN5) [...]?

> why making drivers for an old architecture then?

You are the one who suggested making drivers for Polaris (GCN4). I just wondered why make drivers for GPU architecture n-1 and n+1, but not for n. There may be good reasons for skipping an intermediate generation, but you've yet to explain them.

> some words to comment #21: [...] Why should we stay in the PPC niche forever
> and make the life harder as it needs to be???

As comment #21 says: transparent backwards compatibility. It may not be your opinion, or mine, or that of the MorphOS team (which is the opinion that counts ultimately), but it's a valid opinion nonetheless.

> The 68k JIT on x86 works great in UAE so i think MorphOS for AMD64 will have
> no Problem with 68k JIT. [...] i think most of the PPC Software that is used every
> day will get an x86 Port. And the rest i think will run good and fast enough on x86.

For those who hold the opinion as presented in comment #21, it's not about JIT compilation vs. interpreted emulation but about transparent emulation (like MorphOS/OS4 does on PPC) vs. boxed/encapsulated emulation (like UAE).
The publicly shown proof of concept of MorphOS on x64 does have a transparent PPC emulation and via this, also a transparent m68k emulation, but as far as we know, this is done in an Amithlon-esque way running the x64-compiled A-Box in big-endian mode on the little-endian CPU. I doubt it will stay this way for the release version, especially given that the A-Box itself will have to be replaced as the main MorphOS environment anyway if modern OS features like memory protection and SMP are to be provided.

Correct me if I'm wrong, but isn't x64 as bi-endian as PPC? After all, it has big-endian load-store instructions.

> isn't x64 as bi-endian as PPC? After all, it has big-endian load-store instructions.

Regarding PPC, there are different levels of little-endian capability: from none at all (970) over partial (60x, 7xx, 74xx, e600) to full (e200, e300, e500, e5500, e6500*, 4xx, PA6T, POWER7/8/9). See here (especially the linked PDF) and there.
As far as I can see, it's about data endianness vs. instruction endianness, where x64 implements only the former in the big variant. Whether big-endian data access is sufficient for the transparent emulation required in the case of MorphOS, I don't know.

* AltiVec in big-endian mode only

I was taken onto an alien ship.. I don't go into details what happened.. but exams were made.. my anal is bleeding for a week now. Anyhoo, when I was probed I heard two of the beings discussing about MOS4 .. I did not catch all the conversation.. all I understood was "Everything is fine, the new OS is rolling and on schedule"

Was the 2 more weeks being mentioned maybe @Hooligan ? :D

Quote:
Interesting comment.
I wrote several times, why I using MorphOs with powermacs, why can I use it on talos/blackbird/t2080... and why I don't have any reason use it on X68_64.
My reason is my reason - this is the forum, it serves for sharing opinions.
If my signature makes you laugh, it say something about your personality, not my signature.
Anyway, if you want enjoy the day without laugh - simply don't read the signatures.

[ Edited by sailor 24.08.2020 - 08:35 ]

@Sailor

The MorphOS Operating System, the environment it brings and the applications that runs in it, is what almost everyone here is interested in. Doesn’t matter if some other OS’s exists when MorphOS is what we are here for. Hardware is secondary to this (or even less important than that), *MorphOS* is what we are here for. Hardware is merely an enabler for the OS that we want, that’s all. To me, HW that is affordable, powerful and easily obtainable would be ideal for a future MorphOS. AMD64 fits right into this, it makes perfect sense, while PPC does not and hasn’t been relevant for 1.5 decades (and counting).

Quote:

Agreed 100%

From professional developer pov ppc is interesting because it is not a pc.
Making software for pc is work and cannot be a hobby because it is work.
Nice work but work.
Made mos for pc good enough to sell our customers as daily os for work.
Or leave it as it is.

> From professional developer pov ppc is interesting because it is not a pc.
> Making software for pc is work and cannot be a hobby because it is work.

That must be the reason why most professional developers make PPC software instead of "PC" software when doing hobby programming in their spare time ;-P

That’s just stupid.

When developing software you usually don’t even touch the cpu these days. It simply does not matter if the result is ppc, x86, ARM or what not.

You hit compile or type make and the stuff gets build. Unless you develop drivers there is no reason to even think about what hardware you are compiling for. The only reason you look at the CPU when coding applications is when the build does not work, because you selected the wrong target.

The fun ends or rises when it comes to the OS you are coding on or for. For me turning on Windows is a pain, so doing the same stuff on Linux is ok, while doing it on MorphOS usually is real fun.

Usually I prefer to mix stuff. Code for esp8266, compile on Linux and using FlowStudio on MorphOS to edit the source.

Quote:

> Unless you develop drivers there is no reason to even think about
> what hardware you are compiling for. The only reason you look at
> the CPU when coding applications is when the build does not work,
> because you selected the wrong target.

...or you unwittingly coded for a specific endianness and compile for an ISA/ABI that uses the other endianness, or you coded for a specific SIMD extension and try to compile for an ISA/ABI that doesn't have this (or any) SIMD extension :-)

Some people here think that main problem with cpu switch is assembly.
This is extremely stupid.
There are other more important things like endianess, drivers,
closed source software made only for x86 and arm.
mos/aros on x86/arm have to be as good as win/lnx/osx.
maybe 5% or 10% worse but no more. or it will end as worse uae.

Quote:

Price is still on the website: 1732 USD for a basic 4 core board. For a complete system it is 2500 USD+++.
This is more like server stuff, it still needs ecc memory.
Without the support of a large vendor, there will be no cheap, good spec and up to date Power(PC) cpu for consumers, just like the previous years.

I am glad the team decided to go AMD64, more choice, cheaper, up to date, new and a lot faster then the G5 from 2005 :)

So what is MOS 4 expected to be?
I hope fully PPC64 breaking the 4GB barrier, SMP too and surely having AMD64 support :D

Could I expect it to come PPC64 and AMD64 up to next year? I would skip MOS 3.x license
and buy dual (iMacG5 and PC) licenses, provided AMD64 version can work on older DDR3 style chipsets and mobos and is not just Ryzen oriented.

If we are repeating several times the same things, here is my wishlist:

MorphOS:

- support for CD/DVD connected via USB ( CDDA, ATAPI, boot*.img support for CD filesystem )
- sata.device ( for PCI SATA cards ), it recognizes only UDMA5, correct is UDMA6
- sata.device has no S.M.A.R.T feature
- SATA2 Promise ( or other PCI SATA2) driver boot*.img support
- ssh server
- CRON
- Samba server, protocol SMB v3 +
- smbfs, protocol SMB v3 +
- package manager / update tool

especially for poor little Efika 5200b:
- virtual memory, any system
- semi-DMA support for ATA ide.device ( DMA assisted PIO or something similar )
- support for 2nd ATA device

and of course, some MP support, not necessary SMP is a nice-have.

If it is possible, please for me a handbag from Prada ))

And yes, I will stay with MorphOS even if my wishlist will not be fulfilled.

> smbfs, protocol SMB v3 +

This is planned:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=13484&forum=9

> Efika 5200b: [...] semi-DMA support for ATA ide.device
> ( DMA assisted PIO or something similar )

The MorphOS team tried to use BestComm DMA for the ATA/UDMA state machine in 2006/2007 but it didn't work out. As Linux added this only in 2008 and it seems to work there, maybe the MorphOS team should have revisited the issue subsequently ;-)

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=9434&forum=11

@Andreas

I know that. And looking forward at least to smbfs.

This my list is not ad-hoc, it is copied from my MorphOS + AmigaOS wishlist, which I am updating when I am testing and benchmarking NG machines.

And with Efika ATA is problem that CPU has corrupted ATA state machine - simply it not generates interrupts when ATA FIFO overflowed/underflowed. BestComm is OK.
There was discussion about it on Powerdeveloper in the past. Now on wayback machine.

CPU ATA error is hardcoded in silicon, i.e. unrepairable.
Workarounds are: on every transport check the FIFO state, or not transfer block bigger then actual FIFO data state.
Linux "DMA assisted PIO" workaround do it the second way: Standart PIO tranfer is setted, and then driver uses BestComm DMA for reading/writing data via blocks of 512 B ( = FIFO size ).

I read, that this workaround made guys from BPlan. But these times the relations between MOS Team and Genesi was far from ideal, and maybe it is the reason why this workaround not in MorphOS. But it cannot be exact true, it is only my opinion.
And I am personally not tested linux on Efika, so I am not sure how it works.

My humble article about Efika issues is here. In Czech, of course

>> The MorphOS team tried to use BestComm DMA for the ATA/UDMA state
>> machine in 2006/2007 but it didn't work out. [...] Linux added this
>> only in 2008 and it seems to work there

> with Efika ATA is problem that CPU has corrupted ATA state machine [...].
> BestComm is OK.

Yes, that's what's implied by what I wrote. Using BestComm for this wouldn't make sense if it was BestComm that's broken, after all.

> There was discussion about it on Powerdeveloper in the past.

Yes, I read all of this back then.

> Now on wayback machine.

And also still on powerdeveloper.org.

> I read, that this workaround made guys from BPlan.

That's what Neko wrote, yes. Fact is that the official Linux kernel patch was created in 2008 by Tim Yamin who mentions previous work by Bernard Kuhn, John Rigby (both Freescale) and Domen Puncer, which are names I do not associate with bplan. Assuming that bplan's driver was a (private) Linux driver, to me this appears as there having been two distinct Linux-based efforts, whereas the MorphOS team's (failed) attempt in 2006/2007 may have been based on bplan's prior Linux driver, of which we do not know how well it worked. What is known is that the official Linux kernel patch from 2008 works well enough to have been accepted for good.

> these times the relations between MOS Team and Genesi was far from ideal,
> and maybe it is the reason why this workaround not in MorphOS.

Question is why the MorphOS team didn't undertake another attempt, this time with the working Linux kernel patch from 2008 as reference. Or maybe they did but it didn't work out either for whatever reason?

Is anything known of 3.x AMD64 or MOS 4?
While 3.x version can be "just" AMD64 port
for MOS4:
Gfx

Will driver base be expanded?
Will more gfx cards support Warp3D?
Will nVIDIA be supported?

ISA

Will only Ryzen integrated boarads be supported or more?
Will it be 64 bit?
Will it also be PPC64?
Will it support multicore on AMD64 and OR PPC64?

FS-Boot
Will it see NTFS and FAT32 drives for file exchange?
Will it support easier multiboot (LILO?) with Linux on PPC64 and AMD64?

Price
Price of AMD64 version? Price of both PPC64 and AMD64 versions, if done?

[ Edited by vox 04.03.2023 - 20:26 ]