Quote:
There's a shop near here selling the ps3key suitable for newer systems, although delivery is on hold when you go to order one... Apart from that theres the gamut of ODE's which let you run homebrew on slims and other variants too. They will sell you a brand new ps3 with cfw installed onto it too with warantee.

I'm not very up myself on the specifics of what works where to do what as I bought a fat ps3 for 30e a few weeks back expecting it to have a ylod and need some reflow love and I'd have a tinker with whats swappable inside while I was in there, but to my amazement it works 100% even the blueray reader. For now I'm just using it as a console to blow very big impressively rendered things up for fun as the price of used games has also fallen into the toilet now they're not the latest in vogue must have thing.

What does make it attractive in some ways is that there are a awful lot of them sitting in the corners of rooms waiting to be re-purposed by some curious types. Now not the latest and greatest thing and support and releases for them are tailing off in favour of the new shiny. And aren't they in a great package to just have near the tv for a light fast os to do media browsing and stuff with?

But, I read that the discussion is resolved and its a non starter, I'm new here, I don't want to wade into politics already.

Quote:

+ IMO, breaking compatibility is worth it if it simplifies MOS moving to 64bit & multicore. Compatibility can be regained via sandbox if there is big demand for it.

+ I vote for doing 64bit + SMP before going x64.

Quote:

+1 I Vote This Also.

And...as you all know (since I habitually throw in my two cents), I'd support this on ISA change as well.
BUT, I am no longer sure an ISA change is absolutely essential and believe we could continue to develop and enhance our current OS.

Quote:

Well.. I loved older cars without too much electronics ;) They're easier to tune, fix, and use :) I already hate my 1999 car, which is too new for me. I hate I have to do complicated shutdown and reboot operations to even disconnect the battery or doing something else as simple. Must let the BSI to have time to shut down all the ECUs etc, or its software corrupts itself...... don't even touch the doors when doing it! And restarting is tricky too, you have to do it in correct sequences from the front window without opening the doors. F*ck it, I want to say :P

Sorry about off-topic, but that metaphor just brought my annoyance up again ;) I have recently apparently broken 1 euro relay in my BSI box by wire starting an another car. But BSI box can't be opened to solder the new relay, whole box would cost like 600 euros if it would be available still (but it can't be bought anymore).... only way to take box out and saw it to pieces to get to the broken relay... and then car probably won't start up anymore without some re-coding... I'd rather take simplier cars, but I'm horrified how much more electronics bloat the newer cars have :)

Maybe this goes to operating systems too.. and I just love to use MorphOS rather than over complicated Linux :)

Coding may be different case... but I also hate Linux coders who just don't care about memory allocating and releasing and just mess around trusting that there's always virtual memory and memory protection taking care of their careless mess :)

Quote:

Ah but you don't see the full picture here :) You can't have multiuser AND keep the current system file structure for instance. And once you do change the structure, old, incompatible stuff will start falling apart one way or another. If we'd focus on better SDK documentation now, MorphOS NG would have been delayed by years, which means no memory protection, etc. Gdb makes no sense in current system either since you cannot safely stop applications, even if we made sure the stop happens directly in application's code and not some library call. Things really need to happen in certain order here and for now, you'll continue seeing small improvements in the current OS.

Also, datatypes suck, imo ;) There's a reason for Reggae.

>>> I vote for doing 64bit + SMP before going x64.

>> I Vote This Also.

> I'd support this on ISA change as well.

What does that mean? Introduction of modern features *before* ISA change or only *on* ISA change?

> I am no longer sure an ISA change is absolutely essential

So back to your original stance? :-)

Quote:

It's a requirement.

Quote:

Since these features (as well as others discussed in this thread) already breaks backwards compatibility, there is absolutely no reason whatsoever to stay with PPC. It would be quite insane IMHO.

Quote:

Wrong about what?

Quote:

I never claimed MorphOS was more than "just a hobby", did I?

Quote:

Great! Do you continue to show MorphOS to outside programmers? Or have you given up on hoping that we can gain new users and programmers to the MorphOS camp?

Quote:

I understand your arguments for why most programmers would NOT want to begin any coding for MorphOS, but surely some of them are willing to look past its limitations and become MorphOS programmers, in spite of the difficulties. I never wrote that I expected large numbers of programmers (or even users) to convert to MorphOS, just that we should make some effort to find and recruit the few people who are exceptions, and would be willing to join us.

Quote:

Thanks for sharing what you consider to be essential for you to consider programming for MorphOS. It was not really part of my question, nor was listing all the arguments why we CAN'T get new programmers from outside the Amiga community to join us. This thread was supposed to be for people to give suggestions about what would help us find those few programmers (and new users for that matter), who are willing to look past the limitations, and join us anyway. That number will no doubt be very small, but every new programmer we recruit to MorphOS, the greater chance we have that this tiny niche platform and sub-community, within the larger Amiga community, will survive a bit longer.

I am not delusional to think that MorphOS will surpass any mainstream operating system, or to even become a serious threat to Linux, but I believe that we could grow our numbers of users and programmers, if we would only work at promoting MorphOS in a more efficient manner.

Hey Dave!

You've started a thread, were you claim, that "almost no developers want to join to our community".

Then a developer writes (Eliot) his resons/claims against MOS... Then you become rough against him! Why?


A just quetly mention (what I already did), that everybody should take his/her part of improving MOS... (instead of writing huge articles into threads like this... but don't get me wrong)!
Not everybody can program, but there are many different things, what could be done by anybody: Creating professional looking wallpapeers, finding/converting icons, writing docs, etc.
If somebody tries MOS and see a living community, maybe will join more likely. And, the bigger community is a double win: The developers receive more cash and maybe the joined people also could do something precious for the community!

Quote:

Sorry if I have offended anyone with anything I have written, but I don't see how anything I have put into this thread could be considered "Rough" toward any other member. I agreed with most of what Eliot wrote, but pointed out that what he was stating did not provide any positive suggestions, which was the point of this thread. To get suggestions on things that might be able to help gain more programmers, not to state the obvious reasons why most outside programmers do NOT want to code for MorphOS.

Please quote what messages I have written that you think are "Rough" against any other member. I think you mistake my intentions, or you have assumed some alternative meaning from what I have written.

Quote:

Once I realized that the ISA change meant I'd be maintaining yet another system (because I am not giving up on PPC MorphOS), yes.

What will we have once we move and jettison legacy compatibility?
Hard to tell.
If it starts with a micro kernel and remains tight and compact, I'll be there.

Hey, it's all ok from point of view.
I just wrote what I and other developers are missing in the current MorphOS version.
But I really like it, otherwise I won't use it, show it to other peoble, go to user/developer meetings, ..

Besides programming/job, I have got an family and other hobbies. So there really not much time
to learn programming for MorphOS. So a good API documentation in HTML/PDF/... would be the first
step.


[ Edited by eliot 16.08.2015 - 06:01 ]

@amigadave:

Sorry.. probably I misunderstood you.

Quote:

Something like Haiku-OS?

Quote:

But complete enough to use? ;)

No really, I am curious what we will have.
What we won't have is OS3.1 system calls.

So, what functionality will be added (not removed)?

I'm all for increasing memory addressability and maybe even a 64 bit OS.
But at what cost?

> what functionality will be added (not removed)?

"SMP, memory protection, 64Bit support, virtual memory"
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=9204&forum=11&start=14

> I'm all for increasing memory addressability and maybe even a 64 bit OS.

Don't both go hand in hand anyway?

> But at what cost?

"Loosing the compatibly to all thirdparty PPC and all 68K applications, which aren´t in development anymore. It also will split the user/market once again. [...] In the result we would get a totally incompatible MorphOS system that [...] has no applications beside the ones provided by MorphOS developers itself."
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=9204&forum=11&start=14

Quote:

No, frankly I would just be satisfied with one extra bit (moving from 31 bit to 32 bit addressing).

64 bit would be nice, but I am still using several devices that are "only" 32 bit.

Thanks for the other info, Andreas.

This is going to be a great adventure.

And if I can secure an X5040, I will have an great legacy system for our original OS (although our current best, a G5 with an R500 based video card, is by no means a slouch).

> X5040

I also would have liked this name better, but they decided for X5000/40 :-)

http://www.a-eon.com/?news=08-01-2014

Quote:

Ugh! Great! An even longer name.
Personally, I would have liked Amiga 5000, but they do not have the rights for that and it would offend the purists.

So...we are talking about the AmigaOne X5000/40.
And Amiga OS 4.1 doesn't support SMP (with Amiga OS 4.2, whenever that actual occurs, only supporting two cores) and MorphOS also not supporting SMP (with no stated plans to do so until an ISA change...but then we can't predict what our developers might do).

> Amiga OS 4.2, whenever that actual occurs, only supporting two cores

Why should the multicore support of fabled OS4.2 be restricted to 2 cores? The Hyperion article linked to here and there mentions no such restriction.

Quote:

I was just repeating what I had heard one the web, but obviously I could be wrong.
"fabled", eh? Good choice of words.
Should they pull it off, it would suck not having SMP under a version of PPC MorphOS.

The only news about 4.2 every three months or so is "it's going to be insanely great" and "we are not even close to finished". In that order.

Quote:

Yeah, three months, two weeks, whatever they take it can't be as long as it took to release initially.
And even if they manage to reach their goals, I'd still prefer our alternative.
We just won't look as good as we do now in comparison.

Quote:

+1