Just some loose comments about the stuff above:

There are no plans to drop PPC anytime soon. There is no need to.

There is next to nothing in PPC asm. Current applications and tools, if they play by the rules, just need a recompile for a new target platform. However, due to the AmigaOS API and there are a few tweaks needed to "fix" those applications. Afterwards they can be compiled for PPC and NG.

I could do lowlevel. :) Its just no fun for me and I prefer doing something with some visible result for a change. For MorphOS the lowest level of coding I did so far is the netprinter.device AFAIR.

All team members are listed in MorphOS about. There aren´t any more.

The target platform will be choosen by the MorphOS Team and not by a few people with wishful thinking. There is plenty of work required *before* choosing a final target platform, so no need to stockpile potential target systems. The current hardware situation isn´t bad at all, which is mostly because of supporting apple hardware, which also was well planned before.

I know people claimed the MorphOS Team wasted time on the SAM460. Sales wise you are right. And it was predicted by the Team. But it had some sideeffects everyone using MorphOS right now benefits from. Huge parts of the boot process and the kernel needed to be rewritten/cleaned. Tons of bugs sitting there were found and fixed. Stuff optimised. Less memory used. So the other systems are now even more stable, have a little more free memory for applications and boot faster. Starting with the Efika and Ending with G5 Systems. It also (main reason for supporting the 460) allowed to support X5000 boards (getting it to boot) in hours instead weeks.

So in a summary it wasn´t a waste of time at all and everyone benefits from that.

Now imagine what happens when a target as different as what is next gets supported? Even there the PPC path can benefit alot.

Re - "dung" - Java, Javascript, pretty much anything related to Oracle.
"The number one programming language" - I guess they are discounting C in that equation.
Ever since Oracle obtained Solaris, their developments have been pretty underwhelming.
And I guess I'm still pissed at the "we're taking our ball and going home" attitude that lead to the dissolution of OpenSolaris.

Plus, other than Flash, Java software is related to more of my hardware crashes than any other software package.

Outside of addressing that issue, I don't see too much I completely disagree with you on.

The kernel will probably be the most difficult part of the port, since its likely to be done completely with assembly.

And I guess it would be difficult to demo a work in progress port without the core component.

Also, who is working on the kernel is anyone's guess, I try not to ask pointed questions like that anymore.

Oh, and I believe Frank did some of the work on the SAM460 port. A thorough knowledge of video drivers doesn't prevent someone from applying his talent elsewhere.

In any case, I stand by my position that the current fork should continue to receive maintenance and updates.

[ Edited by Jim 15.12.2016 - 15:14 ]

> All team members are listed in MorphOS about. There aren´t any more.

What about Chain-Q?

> SAM460 [...] (main reason for supporting the 460) allowed to support X5000 boards
> (getting it to boot) in hours instead weeks.

I'm still interested in technical details on this :-)

Quote:

I would venture to guess that adopting a board with a PCIe expansion bus involved a learning curve.
And that that experience helped with the X5000 port.

>> What "piece of dung"?

> [...] Javascript [...]

What's your grudge against this exactly (other than bigfoot's still missing JIT compiler for PPC)?

>> Frank's contribution has primarily been graphics (and audio) drivers I think, the code
>> of which should be compilable for another ISA (he may correct me on this if assumed
>> wrongly). The PPC-specific low-level code (Quark kernel etc.) was laire's work.

> I believe Frank did some of the work on the SAM460 port.

Indeed, but I still believe he mainly developed the drivers for the on-board chips (video, audio) and SoC controllers (PCI/PCIe, SATA, USB, GbE), while bigfoot mainly did the CPU core-specific adaptations.

>>> SAM460 [...] (main reason for supporting the 460) allowed to support X5000 boards
>>> (getting it to boot) in hours instead weeks.

>> I'm still interested in technical details on this :-)

> I would venture to guess that adopting a board with a PCIe expansion bus involved
> a learning curve. And that that experience helped with the X5000 port.

I don't think this is about PCIe at all. That's what geit said about the helpful similarities between the Sam460 and the X5000:

"This is what I was told about the reasons the x1000 was off the list, as it is completly different."

The X1000 does have PCIe, doesn't it? Besides, MorphOS has already been shown on PCIe-based iMac G5 about 6 years ago (so way before work on Sam460 support started).

Quote:

The X1000 never made sense to port MorphOS to (although it pains me to say that, and I would love to be able to run MorphOS on my X1000), after the announcement that the PA6T CPU's were to be discontinued, and because of the cost of each board/system (even though the X5000 isn't exactly cheap, it is slightly less than the X1000 was). Personally, even with as much as I like Trevor and admire his dedication to this community, I never quite understood why he went forward with the X5000 boards, knowing that the endeavor would not be profitable, even if it was less of a loss per unit, than the X1000 was. So, even though the SAM460's PCIe slot was not the primary, or only reason for porting MorphOS to the SAM460, it surely was an advantage in moving forward toward more modern hardware.

[ Edited by amigadave 15.12.2016 - 14:14 ]

>> That's what geit said about the helpful similarities between the Sam460 and the X5000:
>> "This is what I was told about the reasons the x1000 was off the list, as it is completly
>> different."

> The X1000 never made sense to port MorphOS to [...], after the announcement that
> the PA6T CPU's were to be discontinued

One could even question whether the X1000 itself ever made sense, given the fact that the PA6T discontinuation announcement preceded the commissioning of Nemo development by almost a year. But that's not what the comment you quoted is about. Geit, Jim and me have been discussing the technical similarities between the Sam460 and the X5000 and in which technical characteristic these two allegedly similar systems differ from the X1000. The differences in CPU availability play no role in this.

> I never quite understood why he went forward with the X5000 boards, knowing that the
> endeavor would not be profitable, even if it was less of a loss per unit, than the X1000 was.

There seem to exist conflicting information as to whether or not the NRE costs for Cyrus (Plus) board development are passed on to the customers (as wasn't done with the Nemo board). Do you know more? (Unfortunately, takemehomegrandma didn't answer my question when I asked him 2 weeks ago.)

I've never actually discussed the SAM460 with Bigfoot.
I think I mentioned that he said he'd been working with an R600 card a couple days ago and he did mention that he had that installed in his SAM.

I must admit I can't see much similarity between the Applied Micro Soc and the Freescale Soc on the X5000.
I wouldn't mind purchasing a SAM460 board, IF there were any available.

I discussed the idea of purchasing one quite awhile ago with David when they were still available, but never followed through with it.

>What's your grudge against this [javascript] exactly...

Well, right now issues with Java have interfered with some of the external data calls I've made under Excel, I don't like being required to rely on a proprietary software package, and as I've mentioned, I don't like Oracle's management style.

>> I believe Frank did some of the work on the SAM460 port.

>Indeed, but I still believe he mainly developed the drivers for the on-board chips (video, audio) and SoC controllers (PCI/PCIe, SATA, USB, GbE)...

And those Soc controller components may just be what Geit is referring to.
So Frank's work has been crucial, and his and Mark's work has always complemented each other.
They work well together.

And I have to admit, on a personal level, I really like Mark Olsen.
He's a good guy, easy to talk to, considerate, and damned knowledgeable.

But then, I've only had direct contact with Frank, Mark, Fab, and Jacek, and they are all pretty remarkable individuals.

BTW - Crossing threads here, but if you all are so interested in X64, why haven't I gotten any feedback regarding the announcement of Ryzen?
Its fairly significant that AMD has decided to tackle the performance market again.
And combined with their new gpus, this could be a really good basis for the NG port.

Its likely to be what I buy to replace my AM3+, FX-8300, Radeon HD7850 combo.

Quote:

Nah, I'm guessing >90 % of their code which is not based on something from the ouside is written with assumption: machine = 32 bit big endian. Look at some of the code where source code is available, like Ambient. But this things are not that difficult or time consuming to fix, just annoying. Maybe very annoying ... happens if you sort of rule out from beginning things which you think never will happen, like >4 GB RAM, big endian machines ~disappearing, ...

> I can't see much similarity between the Applied Micro Soc and the Freescale Soc
> on the X5000.

Yes, the PPC440H6 core and the e5500 core don't seem related at first glance. I think the solution to this mystery lies in the supervisor instructions implemented in the cores. Both PPC4xx cores and e500/e5500/e6500 cores implement the Book III-E (embedded) specification of the Power ISA and thus provide a basic compatibility on supervisor level, whereas the PA6T implements the Book III-S (general purpose and server) specification which makes it incompatible on supervisor level with cores based on Book III-E.
Booting an OS requires supervisor-level instructions, and the Sam460 was the first MorphOS-supported board using a CPU based on a core following Book III-E specification. So I guess this is what geit means when he says that existing Sam460 support in MorphOS allowed getting the X5000 to boot MorphOS "in hours instead of weeks".

https://en.wikipedia.org/wiki/Power_Architecture#Books

>> What's your grudge against this [javascript] exactly...

> right now issues with Java have interfered [...]

How do issues with Java make you dislike JavaScript?

> I don't like being required to rely on a proprietary software package

How is JavaScript a "proprietary software package"? OWB/WebKit's JavaScriptCore component is completely open source, and bigfoot's JIT compiler will be as well I think.

>>>>>> only laire (still active?), bigfoot and piru have the necessary skills
>>>>>> to pull off the ISA transition.

>>>>> I think you might have just slighted Frank Mariak with that statement

>>>> Frank's contribution has primarily been graphics (and audio) drivers I think, the code
>>>> of which should be compilable for another ISA (he may correct me on this if assumed
>>>> wrongly). The PPC-specific low-level code (Quark kernel etc.) was laire's work.

>>> I believe Frank did some of the work on the SAM460 port.

>> Indeed, but I still believe he mainly developed the drivers for the on-board
>> chips (video, audio) and SoC controllers (PCI/PCIe, SATA, USB, GbE),
>> while bigfoot mainly did the CPU core-specific adaptations.

> those Soc controller components may just be what Geit is referring to.

I doubt the SoC controllers of the PPC460EX are compatible on driver level with those of the QorIQ P5 (or with those of any x64 SoC for that matter).

> Frank's work has been crucial

Yes, Frank's work on supporting the Sam460 on-board chips and SoC controllers has been crucial for Sam460 support. And I believe that what was said about the similarity of the Sam460 and the X5000 means that bigfoot's work on supporting the PPC440H6 core has been helpful for X5000 support. And I also believe that between these two MorphOS team members, bigfoot is the one whose skill set is more crucial for jump-starting ISA transition.

> if you all are so interested in X64

I for one am not :-)

Quote:

No, I don't have any inside information regarding the pricing of the X5000 motherboards and complete systems, or how many of each of those items A-Eon will need to sell before they can recoup all of the design and production costs they have incurred doing the X5000 project. It just seems like an insurmountable amount to recoup, given the size of our community, and the statements and reports of A-Eon spending several hundreds of thousands of dollars, to design and produce the X5000. Sure, some of that reported investment must have included the Tabor A1222 motherboards, but the amounts mentioned still are so large, it seems to me that our community is too small to repay those amounts through purchases of A-Eon systems and motherboards. So, this is just an impression I have of the situation, not based in any facts, other than the numbers that have been reported, or stated by Trevor himself, regarding how much has been invested into design and production, plus rough guesses by myself on how much the bare components might cost and quick math to arrive at a very high number of boards and system sales, that would be needed to repay all investment monies. Even if the production cost of each system or board were doubled to arrive at the sales price (which for many products is true, but I doubt Trevor and Matthew are doing with the X5000 and A1222), it seems to me that approximately 300 to 400 X5000 complete systems would need to be sold just to get close to breaking even. Although no hard figures have been released for the number of X1000 sales, given the number of production runs, and the guessed at number of X1000's probably included in each production run, that 300 to 400 number is probably very close to the number of X1000's that were produced and sold. Are there enough users who did not purchase an X1000, plus existing X1000 users who are willing to upgrade, or add an X5000 to their collection, to reach 300 to 400 sales of X5000's? I don't know, but I am guessing that A-Eon is not doubling the production cost amount of their X5000 and A1222 systems and I believe that I am using a lower number than A-Eon's actual investment number, so both would make recouping all design and production costs harder, with higher numbers than I have noted above. I would love to be proved wrong, and have A-Eon make a profit, to help sustain their continuing work, investing in many different parts of this community, but it just seems unrealistic to me, given the size of our community, and their general tendency to want everything for little or zero cost. The number of users who are actually willing to spend thousands of dollars on a single system, is very small, and many users complain about prices for our software and hardware. Not an easy community to make a profit from, no matter how you slice it.

>> I'm sure most work done on MorphOS is not oriented to any ISA but written in portable,
>> endian-agnostic C code

> Nah, I'm guessing >90 % of their code which is not based on something from the ouside
> is written with assumption: machine = 32 bit big endian. Look at some of the code where
> source code is available, like Ambient.

Such massive endian-dependency would be worse than I thought, especially after reading geit's statements.

> But this things are not that difficult or time consuming to fix

Good to hear.

> [...] how many of each of those items A-Eon will need to sell before they can recoup all
> of the design and production costs [...]. the statements and reports of A-Eon spending
> several hundreds of thousands of dollars, to design and produce [...]. [...] some of that
> reported investment must have included the Tabor A1222 motherboards [...]. [...] the
> numbers that have been reported, or stated by Trevor himself, regarding how much has
> been invested into design and production, plus rough guesses by myself on how much
> the bare components might cost and quick math to arrive at a very high number of boards
> and system sales, that would be needed to repay all investment monies.

I think we can do some simple calculations based on what has been announced by A-Eon or said by Trevor himself:

1. A-Eon paid 1.2 million USD for NRE and manufacturing costs of Cyrus (Plus) and Tabor.
2. A-Eon commissioned production of 500 Cyus Plus boards.
3. A-Eon set a sales price of about 1600 USD per Cyrus Plus board.
4. A-Eon commissioned production of 1000 Tabor boards.
5. A-Eon announced a sales price of about 400 USD per Tabor board.

Let's see: 500 x 1600 USD + 1000 x 400 USD = 1.2 million USD

Coincidence?

Edit: statement regarding NRE costs of Cyrus (Plus)

> Even if the production cost of each system or board were doubled to arrive at the sales
> price [...], it seems to me that approximately 300 to 400 X5000 complete systems would
> need to be sold just to get close to breaking even.

I think they need to sell all 500 produced Cyrus Plus boards to break even (incl. recouping of NRE costs).

> Although no hard figures have been released for the number of X1000 sales, given the
> number of production runs, and the guessed at number of X1000's probably included in
> each production run, that 300 to 400 number is probably very close to the number of
> X1000's that were produced and sold.

Based on the numbers revealed by Trevor, there were at least 400 Nemo boards produced and sold. My personal guess is 600 to 800 boards.

[ Edited by Andreas_Wolf 08.02.2017 - 23:37 ]

Quote:

And if you meant me: I am not too interested in X64 as a technology per se. I am interested in fast, affordable and easily available hardware. If there is Intel or AMD in it, I don't care too much. If it's x64 mid class or x64 high class, I don't care too much. If the boards supported are made by Fujitsu, HP, Apple, Asus - I don't care too much. As long as it will be generally fast, easily avaialble and not insanely priced.

What I care about is newer and more powerful machines than now (significantly more RAM, significantly more cpu power) while keeping a relatively sane price for the hardware.

>>> if you all are so interested in X64

>> I for one am not :-)

> And if you meant me: [...]

I didn't ;-)

> significantly more RAM

My PowerMac G5 can take up to 8 GiB RAM :-)

Quote:
While I chimed in in your reply I didn't ansered you, but Jim.

Quote:

8 GiB is too little
But i guess you know anyway what I intended anyway.
You are right regarding the RAM, that there are supported machines where technically a rather sufficient ammount of RAM is installable. The 8 GiB of a G5 will be okay for the next couple of years, but with current MorphOS this ammount is not usable to the full extend, but limited to some 1.x GiB.

The thing, and you know that pretty well (and IIRC agreeing to tha, toot), is that MorphOS PPC 32 bit has some limitations that will not get overcome w/o breaking some compability level. And while breaking compability anyway, take the opprtunity to switch ISA to a more future proof ISA than PPC is.

Ah, 8 GB works for me, while I currently have AM3+ system, and before that I had 32GB in a dual Xeon system, but anything past 16GB seems pointless as its pretty much never used (by ANY OS) in a desktop setting, and 8GB is pretty functional.

And X64, yeah I don't like it either.
I've NEVER really cared for Intel.

But we play the tune market forces dictate.

BTW - I just sent a lengthy dress down on the fact that I blame this at least in part on IBM, to a Raptor Engineering tech in my statement as to why I was pulling my support for Talos (basically, TOO f'ing expensive).

So...here we go! 68K>PPC>and finally concession that we need to turn to the "darkside", aka X64.
I'm OK with that (Vader always appealed to me more than Luke anyway).

> X64, yeah I don't like it either. I've NEVER really cared for Intel.

x64 (aka AMD64) is being implemented by AMD as well.

> I just sent a lengthy dress down on the fact that I blame this at least in part on IBM, to a
> Raptor Engineering tech in my statement as to why I was pulling my support for Talos
> (basically, TOO f'ing expensive).

This takes the same line:

"Raptor has also faced problems getting support from some members of the OpenPOWER Foundation. It wasn’t, for example, invited to the OpenPOWER Summit in Europe a short while back. As that summit focused on HPC and new university wins it would have been ideal as a funding push. One of the reasons for that is the lack of awareness inside IBM of the project. Last week Enterprise Times asked a number of people inside IBM about this project and drew a complete blank. That is bad news for IBM and for Raptor. IBM has tried to keep the OpenPOWER Foundation at arms length. This is to stop it being seen as an IBM project. For companies like Raptor who are doing something different this is where it needs to do more."
https://www.enterprisetimes.co.uk/2016/12/15/crowdsourcing-power8-motherboard/

Quote:

Thanks, that post was enlightening.
WTF were they thinking?
We know from past inquiries (about the Cell BE) that IBM likes to qualify all uses of their products and prefers to work in partnership with companies that use IBM components.
I think they tend to think that products using their silicon represent IBM as well as the company designing and selling the products.
Stranger still is that if they had worked with IBM they might have received some technical advice and assistance.
After all, IBM wants outside parties involved in Power 8 and 9.

Status update:

TrashcanFileSystem is now complete. Making good progress on Ambient integration.

Quote:

Thanks for the update Jacek.

Enjoy your New Year's celebration and stay safe (away from other drivers, who may be too drunk to be driving).

Here's to more fun with MorphOS in 2017!

Quote:
Right on dude!

[ Editiert durch ernsteiswuerfel 28.12.2016 - 19:23 ]

It's been released. You can find the download link in the news section.

Please test this version and report back if you have encountered any problems.