Quote:

You once told me why your links in forum messages point to the wrong message, due the preference I have set for reading these forums, but I have forgotten what you wrote, and how I can change my settings, so I can click on the many links you use to make your point of view known. Something about threaded vs linear, or newest post vs oldest post showing up at the top of a thread.

I wish there was a fix for this forum software, so I could keep my current settings, which show the newest forum posts at the top, and what ever setting I am currently using, regarding threaded, or non-threaded reading of the forums, and still allow me to click on links of other forum posts, and not go to some completely unrelated forum thread. Before you pointed out the problem with the forum software, I was very confused by the forum posts you would provide links to, to answer questions, or make your point of view known.

For example; when I click on your link above in this forum thread, it takes me to the thread about the release of MorphOS3.10 in a week, with the post from you saying something about Cherry Darling and who works, or formerly worked for them, which to me, has nothing to do with Hyperion being responsible for any delay in the release of MorphOS3.10.

I'll switch my preferences to show the oldest forum posts first, instead of the newest posts at the top, to see if that fixes the problem.

Edit: Yep, that fixed it! What a pain in the ass though. I much prefer to have the newest forum posts shown at the top of pages.

[ Edited by amigadave 04.08.2016 - 14:16 ]

> not go to some completely unrelated forum thread

This was never the case.

Quote:

You are correct, but often it seemed that way.

Sorry this took so long...

I've been working on the trashcan functionality for a couple of weeks now. What's working is the actual backend that moves files around and does all the bookkeeping. I'm currently working on the filesystem part - the Trashcan volume already shows up in Ambient, but it's a lot more work to have this fully functional - the idea is that all trashed files will be available within the Trashcan: volume (read-only). Once the fs part is done, Ambient will need to have trash support added.

The plan is to have something ready for a betatest before the end of this year.

Quote:

Very cool.
Will test it out when you release it Jacek.

Quote:

Great news, but sad to read that it is so much more work for you than I had at first guessed it would be. I'm now thinking that your time could have been, and would still be, in the near future, better used on other parts of the OS, or on some part of the move to x64 hardware. I am sure the small amount funded for this work to be done (1/2 by me basically just to shut up some other complaining member here), was only a tiny fraction of what your time has been worth to do this work.

[ Edited by amigadave 13.12.2016 - 13:27 ]

Quote:

Hey, thanks for promoting the idea, David.
Its a useful addition to the OS and anything that adds to the utility of PPC MorphOS is cool by me.
The X64 fork will be a great addition, but I wouldn't want to see our current OS slighted in order to further development of the X64 variant.

Quote:



Good luck !

Quote:

I'd be happy to do any beta testing you want done before it is incorporated into the OS for its next release, but if you already have sufficient number of testers, I don't need it before the official release is ready.

Quote:

Reality check please: X64 MorphOS will not be an addition, but a replacement. It's silly to waste any more resources on a dead ISA.
Really. If MorphOS would have some significant resources (manpower, money) I'd be more than happy if MorphOS would also continue PPC, but unfortunately these resources just aren't there.
Priority #1 must be at least to ensure a future. And building a future on a dead and virtually abandoned ISA is - hhhmm let me phrase it this way - not the ultimatively best choice.

Quote:

Zylesea: I appreciate your input, but I'm laying down some cash for an X5000 next year. I intend to keep that around for the rest of my life, so improvements in the OS I'd prefer to use on it will be most gratefully accepted.
And, the development team is still working on improving our current OS. So, regardless of what you think, the PPC version of MorphOS isn't going away any time soon.
Right now Mark's starting to bust his ass working on the video drivers for the cards above the R500 series. I just exchanged a message with him today, and he mentioned playing around with an R600 card. So, while Andreas may have recently been harping on Bigfoot's progress with the Java JIT project, I can assure you Mark's damned busy.
Jacek, just posted what he's doing. And I f'ing really like it.
Further, I'm sure there are other developers with their own current projects.
MOST of them, no doubt PPC oriented.
Our user base is already bleeding as some users move to OS4, after all, that OS' development is finally progressing a little faster. OpenGL ES, Radeon HD video card drivers, software development promoted by A-eon...
And what are some of us suggesting?
That we sit still, throw all our effort into an X64 fork that will no doubt take years to realize, and just let the current OS stagnate?

THAT is just stupid!
Does Microsoft stop updating its current OS while its prepares its successor?

When Geit and whoever else is working on the X64 fork show us some progress, well even then, I'm still not going to be willing to throw away the current OS.
I look forward to the X64 fork, but I'm keeping my PPCs.
And I doubt the development team is willing to just shut down the PPC fork either (and, btw guys, if you are, I have some embedded commercial applications that I wouldn't mind doing with the core of the OS - so how much do you want for it? As if...).
You don't work for decades to produce something just to ash can it.

Reality check?
The reality is that the OS is the property of our developers.
THEY, not US, say where its going and what is going to happen, AND so far I have NOT heard an announcement that the X64 fork meant the death of the original OS.
OBVIOUSLY, when MorphOS NG is ready for release, focus will shift to supporting hardware that has more of a future than our current PPC systems.
BUT, the history of this OS, what the developers have accomplished, f*ck...the personal character and the abilities of each one of these guys?
If NOTHING further became of this OS, what has been produced so far, the persistence of the development team, and their support...I find it humbling.

So, whatever the hell happens, I'll keep my X5000, update it with whatever updates come, and frankly I will be quite satisfied with it.

And THAT is my reality.

BTW - Frank, Mark, Fab, Jacek, Harry, Geit, Andre and the others I haven't had direct contact with...uh...THANKS.

[ Edited by Jim 15.12.2016 - 18:23 ]

> Andreas may have recently been harping on Bigfoot's progress with the Java JIT project

I just linked to the Leopard WebKit author who has been harping on Bigfoot's progress with the JavaScript JIT project ;-)

> I'm sure there are other developers with their own current projects.
> MOST of them, no doubt PPC oriented.

This I doubt. I'm sure most work done on MorphOS is not oriented to any ISA but written in portable, endian-agnostic C code, thus easily compilable for whatever ISA (including x64).

> Geit and whoever else is working on the XS64 fork

Geit is a high-level (application-level) coder so I doubt he is working on the transition to x64. As far as I know the backgrounds of the MorphOS team members, only laire (still active?), bigfoot and piru have the necessary skills to pull off the ISA transition.

> I have some embedded commercial applications that I wouldn't mind doing with
> the core of the OS - so how much do you want for it? As if...

I believe the Quark kernel is supposed to be re-used for MorphOS on x64, at least the portable code parts.

> You don't work for decades to produce something just to ash can it.

The vast majority of the code that comprises MorphOS should be easily recompilable for any ISA, so even if there were no further PPC versions of MorphOS as soon as an x64 version arrives, the MorphOS team wouldn't have to "ash can" the majority of the code written so far.

> The reality is that the OS is the property of our developers.

The reality is that each individual MorphOS component is the property of its individual developer, as could be seen by tokai's unfortunate departure.

>The reality is that each individual MorphOS component is the property of its individual developer, as could be seen by tokai's unfortunate departure.

Yes, that was an ugly situation, wasn't it?
Perhaps they ought to consider asking all current contributors to sign a contract that covers the rights to that code.

>The vast majority of the code that comprises MorphOS should be easily recompilable for any ISA, so even if there were no further PPC versions of MorphOS as soon as an x64 version arrives, the MorphOS team wouldn't have to "ash can" the majority of the code written so far.

Not nearly as simple a process as you assume, or we already would have seen a proof of concept demo.

>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, one of two developers who was there at the start. And Mark is pretty busy with work on the current OS, so who's that leave in your list Harry and one other developer that you don't appear to be sure is actually still working on the OS?

>This I doubt.

I don't. The best developer in the list you mentioned is already committed to several new projects for the current OS.

>I just linked to the Leopard WebKit author who has been harping on Bigfoot's progress with the JavaScript JIT project

Yeah, I know, but I enjoy needling you every once in a while buddy, and you did bring it up...;-(
Besides, I would SO like to jettison all my reliance on that piece of dung.
Java, Flash, and any other buggy, unreliable crap I've been forced to use for the last couple of decades or so.

And, as I pointed out, I'm quite impressed with what's been done so far, so when we do make this move, I'll be retaining my last PPC system (which is likely to be an X5000) as an example of the "high water mark" we reached with this.

You know, there are a few things we are likely to see before this move that will be quite neat.
Bigfoot's committed to upgrading all those Radeon drivers that were introduced after the R500s, and if he can do all that work, I'll bow to him in obeisance.
That means, that unlike the OS4 video drivers, we will have accelerated support that doesn't jump from the 9200 to the Radeon HD card skipping 3D support for a huge number of gpus.
Think about it, we have 3D support for the R300, R400, and R500 cards thanks primarily to Mark and Frank.

And other little goodies that might pop up?
That's anyone's guess, BUT they have dropped surprises on us before, and I'm almost certain that they will drop a few more, unannounced, on us before this is over.

And as to X64, yeah that WILL be cool, won't it?
BUT, if we aren't to see a large part of our current user base slowly fade away, it will pay to keep the current OS under development.

After all, as you've pointed out, a great deal of this is going to carry over into NG, or does that become NGNG?

[ Edited by Jim 14.12.2016 - 20:11 ]

> Perhaps they ought to consider asking all current contributors to sign a contract
> that covers the rights to that code.

The problem of this idea would be to determine the other contracting party. The MorphOS team is not a legal entity, so who would such contract be concluded with? Of course, any team member could simply contribute his code under a custom license that grants the usage of the code within all (or certain) future MorphOS releases. The question is if all current MorphOS team members even want to grant such license. Tokai certainly didn't. And I'm not sure the MorphOS team is in a position to demand this from its members and expel contributors who wouldn't want to comply.

>> The vast majority of the code that comprises MorphOS should be easily
>> recompilable for any ISA, so even if there were no further PPC versions
>> of MorphOS as soon as an x64 version arrives, the MorphOS team wouldn't
>> have to "ash can" the majority of the code written so far.

> Not nearly as simple a process as you assume, or we already would have
> seen a proof of concept demo.

No, we wouldn't. As I said, compiling for x64 is no problem for the majority of the code. Majority of code doesn't equal majority of effort in terms of ISA transition. The hard part is creating the small layer (relatively speaking in terms of code quantity) that the recompilable majority of the OS runs on top of (i.e. kernel and kernel-mode drivers). Or put another way: How to show a proof of concept demo of MorphOS user space code on x64 without x64-compatible OS kernel?

>> 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,
> one of two developers who was there at the start.

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.

> Mark is pretty busy with work on the current OS, so who's that leave in
> your list Harry and one other developer that you don't appear to be sure
> is actually still working on the OS?

Yes, unless there are more current team members than publicly known, among them one or more developers especially "hired" for the x64 transition. But how likely is this?

>>> I'm sure there are other developers with their own current projects.
>>> MOST of them, no doubt PPC oriented.

>> This I doubt. I'm sure most work done on MorphOS is not oriented to any
>> ISA but written in portable, endian-agnostic C code, thus easily compilable
>> for whatever ISA (including x64).

> I don't. The best developer in the list you mentioned is already committed
> to several new projects for the current OS.

I replied to (and doubt) your claim that most work that is currently being done for MorphOS is PPC-oriented. I assume that a good share of bigfoot's current MorphOS projects is not PPC-oriented, or oriented to any specific ISA at all. Or do you really believe that most MorphOS components are written in PPC ASM?

> I would SO like to jettison all my reliance on that piece of dung.

What "piece of dung"? (Sorry, I seem to have lost track.)

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 :-)