@Kronos

I refer you to your own signature:

Quote:

We don't need good ideas, we haven't run out on bad ones yet

It's all time that could've been spent moving away from PPC's event horizon.

_________________
Doing stupid things for fun...

@Karlos

Sure plenty "bad ideas", but nothing I could have done about it.....


Point is core members of the MorphOS team are pretty free to do what they want.

Thats how we got the initial port to the MacMini, the PowerBooks and G5s.
Thats also how we got dual screen support, updated 3D drivers and the under the hood stuff needed to make Wayfarer/IRIS possible.

Thats why Bigfoot could do that tech demo and thats why he could resume it whenever he feels like it.

In 68k land we have a situation where the only ones allowed to work on the OS aren't interested in "über fast" Amigas and are bound to a restrictive license controlled by a toxic entity.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

As someone who used to run Linux and build binary packages for both big- and little-endian, on the exact same hardware… I don’t recall any performance penalty on big-endian.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Kronos

Quote:

In 68k land we have a situation where the only ones allowed to work on the OS aren't interested in "über fast" Amigas

They don't need to be. 68k AmigaOS is already Uber fast under emulation. I'd pitch 3.9 running on amithlon on any supported machine in the last 10 years to PPC/NG any flavour. Sure you don't have those fancy 3D graphics and what not, but there's no reason a modern reincarnation couldn't add them. There could be lots of interesting other ways to leverage multiple host CPU cores rather than leaving the unprepared guest OS to do it.

There's nothing Uber Fast about PPC anymore anyway. You want the best performance out of a PPC in 2024? You need SMP, just as you would on x64 or ARM.

_________________
Doing stupid things for fun...

@kolla

The swizzles! Won't anyone think of the swizzles?

_________________
Doing stupid things for fun...

@Karlos

It's not the question wether AOS can run on "über fast" fake HW, it is the question whether the OS will utilize it within modern features.

Modern features that would overwhelm an 68020-060 with or without a Z2 GFX card, hence they don't get added to AOS3.2.

Adding them via 3rd party patches and tools might work, but thats fracturing the target systems just as bad as 68k vs PPC.

@kolla
Things for sure improved as back in the Amithlon days running BigEndian code (with Martin Blooms compiler) about halved the performance compared to the fully native LittleEndian modules (unlinked, unstripped Linux executables).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Amithlon/PiStorm isn't fake hardware. It's just hardware. And as hardware it's every bit as legitimate as PPC/NG from the perspective of 68K application software. Who gives a crap about the 5% of the runtime of any compute bound application might spend making native system calls? (Exceptions are things like codecs and datatypes, the OS is just in the background).

That you can imply comparison between Amithlon and say UAE (which *is* entirely soft emulated and thus "fake" hardware) makes me seriously wonder if you ever actually did use it. Amithlon had a virtual 68K accessing real physical hardware and reacting to real interrupts etc. As does PiStorm.

_________________
Doing stupid things for fun...

@Karlos

It acts like it has an 68k which it hasn't, hence its "fake".

Wether the rest of the HW is "real" aka accessed natively does make quite a difference but once you have to route the binary blobs and or host OSes the lines get blurry.

Point is AOS3.2 is designed with real 68k CPUs and real legacy HW in mind and it runs on PiStorm&Co little more then by accident.

Which means when writing any application you can't rely on features that may only be available via 3rd party stuff. Sure might not matter for everything, but it is for sure easier to code when the bottom end is a 400-600MHz Efika or Peg1 with 128MB and a Radeon 9250.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

It acts like it has an 68k which it hasn't, hence its "fake".

PPC/NG. Your words, not mine.

Quote:

Point is AOS3.2 is designed with real 68k CPUs and real legacy HW in mind and it runs on PiStorm&Co little more then by accident

No, it's by the hard effort and dedication of the developers who maintain compatible and performant 68K emulation implemented well enough to *host* the entire OS and all of it's software.

Last edited by Karlos on 17-Dec-2023 at 12:08 PM.
Last edited by Karlos on 17-Dec-2023 at 12:06 PM.
Last edited by Karlos on 17-Dec-2023 at 12:04 PM.

_________________
Doing stupid things for fun...

@Karlos

"I have nothing but respect and admiration for the devs working on it, also 4.x, 3.x and the multitude of AROS related projects. It doesn't mean I can't or won't question what I see as poor decisions."

Great point, and I agree. I think we just disagree on timing.


@Karlos and @Kronos

I think it would be nice sure if someday we get new hardware, but I would rather they finish up loose ends and more importantly solve the spreadsheet and accounting software missing software.

I will certainly look to you both for much more knowledgeable understanding and selection as to what platform to move to.

But, if you loose 68K JIT than you don't have a complete solution ready to go. The only solution is to emulate 68k or rabbithole (probably won't be since the MorphOS codes right to metal.).

So I agree with both of you, I also agree with the Team to keep hammering away at the OS and solutions and adding features/software.

You then have the easiest time with the code dependencies using all the same stuff.

I would bet, that if someone pulled together 100k, it might change their trajectory because they have an incentive to deviate from the roadmap.

@Matt3k

Quote:

I think it would be nice sure if someday we get new hardware, but I would rather they finish up loose ends and more importantly solve the spreadsheet and accounting software missing software.

I don't think there is much of an overlap between those that could and would do a spreadsheet and/or accounting app and those that could/would/will push MorphOS onto a new architecture.....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

What's wrong with Google Sheets for your general spreadsheet needs anyway? Presumably wayfarer handles it?

_________________
Doing stupid things for fun...

@Kronos

Agree, those are my selfish wants

@Karlos

I can't stand the big tech companies and the cloud. Wayfarer does work with a Libre Office container on my NAS, but Turbocalc has a much better experience being a native app. So I usually convert to .XLS and just use that.



@Karlos and Kronos

I think to make it a reality, we would need to see how much could be raised. I get a sense that there would be a lot of people interested, but who knows. I was frankly surprised that one person gave 10K to Bigfoot just to get drivers updated.

@Matt3k

Quote:

I can't stand the big tech companies and the cloud

Also: Uses old hardware manufacturered by one of the big tech companies in order to run a browser based on an engine the same big tech company forked from KDE/KJS...

Nah, really stickin' it to the big tech bros there man

Last edited by Karlos on 17-Dec-2023 at 03:47 PM.

_________________
Doing stupid things for fun...

@Karlos

Too funny

Yeah, I guess I still need remnant of big tech. Atleast MorphOS hits the metal.

@Matt3k

Well, any software hits the metal in the end. If you are running 68K code on trance, any hot traces get translated to native code. Only a pure interpreter has a software layer permanently in the way.

_________________
Doing stupid things for fun...

@Karlos

Agreed, I just don't like to do it on a layered OS that has to rabbit hole to do anything. Seems like faking it more to me anyways...

@liquidbit

Yes absolutely, I would support it. RISC-V is being developed constantly.

_________________

@Matt3k

All reusable software tends to be layered. You call a gadget method, it calls a methods of intuition, graphics etc. Those in turn call ever lower level things like layers, drivers and eventually memory management and so on.

Even the code within an application is layered, never mind the callgraph through an OS call. Generally when an application is performance bound by the OS it's due to IO rather than the various indirection of system calls.

_________________
Doing stupid things for fun...

@Matt3k

If you really want to try a close to the metal OS, may I recommend MenuetOS on x64?

https://www.menuetos.net/index.htm

_________________
Doing stupid things for fun...