@Kronos

Quote:

@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).

I speak of hardware from around that period, ARM hardware, ARM having native big-endian modes. Since you speak of Amithlon, I suppose you mean x86 - a whole different story.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@liquidbit
It's funny that the included graphics card is an AMD Radeon R5 230 which is old and very low spec but uses PCIe 2.0 x16.

https://www.techpowerup.com/gpu-specs/radeon-r5-230.c2576

A PCIe 3.0 x8 or PCIe 4.0 x4 would provide similar bandwidth without as many PCIe lanes. AMD has cards that don't use all the lanes but are substantially higher performance. The new AMD low end card only uses PCIe 4.0 x4 and is only 53W allowing it to be powered from the PCIe connector yet can play most PC games.

https://www.techpowerup.com/gpu-specs/radeon-rx-6400.c3813

The big brother with about double the GPU hardware doubles the lanes to PCIe 4.0 x8.

https://www.techpowerup.com/gpu-specs/radeon-rx-6600.c3696

There isn't any RISC-V or Amiga hardware that has enough CPU performance to need more than this for games. Games need strong single core performance which RISC-V and PPC cores lack. SMP is needed for more modern games as well which PPC AmigaNOne lacks. If more weak cores or threads is the answer then there is a new graphics card for you too.

China's Moore Threads MTT S80 GPU Review | A New Challenger Appears
https://www.youtube.com/watch?v=qPMptuEokPQ

It has Moore Threads and is the first graphics card to support PCIe 5.0 x16. It's easy to add more parallel performance but weak cores and threads don't scale well and don't even offer reduced power when there is work to be done. The PCIe 5.0 x16 can't help this card either. The low end Radeon RX 6400 gives better performance, is lower power and is cheaper.

The Pioneer SBC is a strange design and not so great for a desktop SBC. There are lots of PCIe lanes, SATA connectors and USB 3.2 connectors drive up the cost while it only supports DDR4. The SiFive SBCs are more balanced and practical designs which should be cheaper.

https://www.sifive.com/boards/hifive-unmatched-revb
https://www.sifive.com/boards/hifive-pro-p550

The Unmatched is already discontinued and the P550 is not out yet. The problem is that there isn't much of a RISC-V desktop market.

@kolla

But isn‘t that full big endian support missing on current ARM offerings?

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

@Kronos

The one thing which is clear, and all concerned parties appear to agree, is that change is needed. Change in both the underlying hardware and the operating system to better take advantage of the changed hardware.

You are prioritising the change to x64, supported by the preview and plan for migrating MorphOS to x86 (x64). You, as many others, want to have options and flexibility of hardware, while also keeping costs relatively low.
If there is strong project leadership to keep things from derailing, and sufficient funding, then this approach overall is better. The centralised approach.

@Karlos is prioritising software. Making improvements to the OS, even if it's AROS 68k instead of Amiga OS 3.x/4.x HPE (High Performance Edition).

Since the operating system needs to undergo changes anyway, and new layers need to be added, then why not just do that with a more standardised, performant, and relatively low cost set of hardware like the Raspberry Pi?
It keeps small and distributed teams with meager funding more focused. What David Heinemeier Hansson called "The liberating freedom of constraint". Plus, it'll make driver work within a small developer community much less of hurdle.

The bonus is that the emu68/Umilator approach provides additional flexibility as anything running on ARM in Phase 1, can transition to doing the same on x64 in Phase 2.
With enough developers, eventually there could be more "native" binaries for a specific ISA than 68k binaries relying on JIT.

_________________
All the way, with 68k

@agami

What I've observed is that a lot of NG users seem to view 68K as irrelevant at best or an anathema at worst, so I don't hold out much hope they'd want to take part in any kind of effort to standardise around 68K binary format.

You only have to look at an application devloper's response to the suggestion, "but mah APIs!". Ok, that's a given, but it's not insurmountable at all.

First, you start with the common intersection functionality, the 3.1 API that all NG purport to be compatible with. You then work out what abstractions are necessary to replace *equivalent* but *divergent* functionality. There's nothing in MUI or Reaction that couldn't be abstracted behind a common UI layer, even if you weren't able to use every possible component. All the obvious things exist. A button is a button, a window is a window, a slider is a slider. It doesn't matter that MUI renders in a different thread, these are pure implementation details that an application should not need to know about. Creating functional abstractions for things like this has been standard practise on other platforms for decades. I've been a software architect professionally long enough to know you can plug anything into anything if you really want to.

However, doing it properly involves planning, layering abstraction and writing software that only optionally makes use of features unique to a given environment but not depending on it. Unfortunately this is also an anathema to many Amiga coders; the idea that there are some additional cycles will be lost between the button click and it arriving at the application in some platform independent way, or the extra bloat involved. Much easier to focus directly on your preferred platform and be as lean an mean as possible. I get it, but it's oldschool thinking. Ironic, really.

It all takes effort and cooperation.

_________________
Doing stupid things for fun...

@community

From the discussion I conclude that the majority of people want a low-end hardware solution than a killing machine!

I respect that, so maybe the middle ground is a faster raspberry pi.

By looking on the net I saw a new Pi5 that just came out... https://www.raspberrypi.com/products/raspberry-pi-5/

Can that CPU host a GPU this time? the previous version didn't.
( I have a bunch of these btw, and I never thought to run EMU, as I use them for security network stuff).

We really need a hardware that it can use a GPU.

Is this maybe the next Amiga cell that we need for the year 2024 ?

Just wondering...

@agami

Quote:

agami wrote: Since the operating system needs to undergo changes anyway, and new layers need to be added, then why not just do that with a more standardised, performant, and relatively low cost set of hardware like the Raspberry Pi? It keeps small and distributed teams with meager funding more focused. What David Heinemeier Hansson called "The liberating freedom of constraint". Plus, it'll make driver work within a small developer community much less of hurdle.

a) lots of code working on Radeon cards, vs non on the rPI binary blob
b) some code working for AMD vs none for ARM

Even if we ignore that, AMD does give why much headroom AND low end options even if it is just the B450 chipset that gets supported.
As such it would last much longer before the need for more arises again.
With rPI you get what you get supporting rPI5 may need extra work and noone knows what will change with rPI6 other that it still won't touch the single core performance of a lowest end AMD CPU that fits into that B450 board.

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

@Karlos

Quote:

Karlos wrote: @agami First, you start with the common intersection functionality, the 3.1 API that all NG purport to be compatible with. You then work out what abstractions are necessary to replace *equivalent* but *divergent* functionality. There's nothing in MUI or Reaction that couldn't be abstracted behind a common UI layer, even if you weren't able to use every possible component. All the obvious things exist.

Sure the obvious things do exist, which is good enough to do trivial GUIs (which one could just do with MUI3.8 since thats pretty much a given anywhere Amiga).
Lots of things end up non trivial and if you wanted to catch them all you would not only create bloatware for real (which then won't run good enough on real Amigas) and need lots on manhours to implement it. Since noone has invested the manhours to implement even the trivial parts....


In reality it would make much more sense to port an existing open source toolkit and place it directly on top of Intuition/Graphics, but thats to close to YALD at least for my comfort.

Which is the reality, far less "heavy" SW has been released for über-fast 68k in the past 20+ years compared to PPC NG and I just don't see that changing no matter how "good" your arguments get.



Also, since you love to suggest MenuetOS....

So you want to use an obscure OS running a GUI-TK that is neither ReAction nor MUI and run that on a rPI?

May I suggest the OG of anything ARM?

And yes getting into RiscOS does sound far more interesting than dealing with an 68k FrankenOS that may still rely on IP owned by Bunny Voldemort.

Last edited by Kronos on 18-Dec-2023 at 02:32 PM.

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

@Karlos

"What I've observed is that a lot of NG users seem to view 68K as irrelevant at best or an anathema at worst, so I don't hold out much hope they'd want to take part in any kind of effort to standardise around 68K binary format."

For me it has everything to do with the reality of what is and what I can use today to do my work and have some fun.

So the software that does the work, happens to run on MorphOS. It also provides a good experience in general with functionality and stability and cost/value of ownership.

The reality of today is that software on 4.1 and 3.x is well, very primitive in comparison if you can even do the task at hand to begin with.

Back when I was a consultant, clients chose software solutions on functionality that would get the job done best within budget, they didn't care what the hardware, network it ran on, OS was underneath, database was below, and it was coded in. As a user that wants to use an AmigaLike solution for work and some fun, it makes sense.

So if there was good suite of software available on 3.x or 68k, that ran well. I would be open to adopting that, provided it did it better than what I have today. I did try a few years back running them all, so I did do my research before doubling down and updating Mac PPC hardware and moving on...

Last edited by Matt3k on 18-Dec-2023 at 04:27 PM.
Last edited by Matt3k on 18-Dec-2023 at 02:53 PM.

@Kronos

Quote:

Also, since you love to suggest MenuetOS.

Only for people that think being close to the metal is the only way to roll :)

I have tried it though, it's certainly... Different.

_________________
Doing stupid things for fun...

@Kronos

The last time I used RiscOS, it was on a RiscPC, circa 1994 (maybe 95?). Back then it was quite something to behold. High colour display, antialised fonts. The overall user experience was unusual to say the least. I did quite like the way the save menu worked, naming the icon in the menu then dragging it where you wanted. I was less enamoured with the memory control stuff, that felt like micromanaging the OS.

There was a pentium card for it and an emulation package that ran windows in a window on the host display. It probably wasn't that efficient but it seemed neat at the time.

Last edited by Karlos on 18-Dec-2023 at 04:11 PM.
Last edited by Karlos on 18-Dec-2023 at 04:01 PM.
Last edited by Karlos on 18-Dec-2023 at 03:52 PM.

_________________
Doing stupid things for fun...

@Karlos

68k software is mostly at least 20+ years old.
68k is not important.
real 68k will be nice. but I may live without it.
real cpu no pc is more important in 2023.
it is last thing that still makes amiga fun.

@ppcamiga1

https://youtu.be/gvdf5n-zI14?si=ie462Y6Sz_A2pInI

PPC has never been fun, not really. Show me someone that enjoys PPC assembly language and I will show you a person from one or more Euler sets of "blatant liar", "never actually used it", "doesn't know what fun is" and "misunderstood the question".

It's functional. It works. It has some interesting operations. That's the highest nerd praise I can give it. It's fun if you manage to produce better code than the compiler did, but you mostly won't because the bottleneck will usually be elsewhere.

I mean it was a decent performance step up on classic machines but everything it does worth a damn is written in C and so it can be replaced. And the time for that passed ages ago already.

Let's be realistic about what PowerPC is and always was. The disowned ginger stepchild borne of a layby tryst between enemies, each desperately grudge banging the other to conceive something that will give them some semblance of ongoing relevance in a world captivated by the inevitable, Borg like rise of x86.

Last edited by Karlos on 18-Dec-2023 at 07:43 PM.

_________________
Doing stupid things for fun...

@Kronos

Quote:

Kronos wrote: @kolla But isn‘t that full big endian support missing on current ARM offerings?

Yes, “full” BE32 is legacy only supported up to ARMv6, with v7 and up only BE8 supported. The difference is that with BE32 both code and data is big-endian, while with BE8, code is little-endian while data remains big-endian. Since we don’t havr tons of native legacy big-endian ARM code to worry about, only big-endian data (68k code is also “data” from the viewpoint of an emulator) it doesn’t matter much.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@ppcamiga1

OS4 is outdated and buggy, Roadshow for OS4 is outdated and buggy. Why bother.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

liquidbit Quote:

From the discussion I conclude that the majority of people want a low-end hardware solution than a killing machine!

It's not that Amiga users want low end hardware but rather that the AmigaOS is more competitive on low end hardware and the Amiga user base needs to be expanded with low cost hardware to survive. Low end hardware can be surprisingly powerful and benefit from standardization like the original Amiga or a console.

liquidbit Quote:

I respect that, so maybe the middle ground is a faster raspberry pi. By looking on the net I saw a new Pi5 that just came out... https://www.raspberrypi.com/products/raspberry-pi-5/ Can that CPU host a GPU this time? the previous version didn't. ( I have a bunch of these btw, and I never thought to run EMU, as I use them for security network stuff).

The RPi 5 and RPi 4 CM only support PCIe Gen 2 x1 which is poor. There are Linux drivers for some cards but many problems.

You can use external GPUs on the Raspberry Pi 5
https://www.youtube.com/watch?v=BLg-1w2QayU

I tested EVERY graphics card on a Raspberry Pi!
https://www.youtube.com/watch?v=l9dItRUjQ0k

There is still a performance boost from the PCIe gfx card but that is because the integrated GPU is so weak, especially compared to the CPU performance in the RPi 5. The PCIe Gen 2 x1 is only the hardware interface between the CPU and GPU. 3D scenes and games which fit in the GPU memory may take longer to upload to the GPU but then play at full speed. Still, PCIe Gen 3 x4 would be more reasonable for Amiga level to RPi 5 level of CPU performance. The lowest cost option, which also provides standardization advantages, is just to provide a better integrated GPU. The RPi Foundation is currently using smart phone SoC (CPU+IO+GPU) chips where they have a limited choice of GPUs and PCIe lanes. They have started designing their own low end SoC chips ($1 USD RP2040 in RPi Pico) so they may eventually bring out higher end SoCs with features more appropriate for a desktop and/or embedded use.

liquidbit Quote:

We really need a hardware that it can use a GPU. Is this maybe the next Amiga cell that we need for the year 2024 ? Just wondering...

The problem with small desktop SBCs with PCIe is that they usually cost several times what a SBC with integrated graphics cost. For example, the SiFive RISC-V Unmatched SBC had a cost of $665 USD.

https://www.crowdsupply.com/sifive/hifive-unmatched

A SBC also using U74 CPU cores but with an integrated GPU costs $89.99 USD on Amazon right now.

https://www.amazon.com/VisionFive-RISC-V-StarFive-JH7110-Quad-core/dp/B0BGM6STN8

The integrated GPU outperforms the RPi 5 GPU while the U74 cores have performance between a RPi 3 and 4. The RISC-V SBC has more balanced CPU and GPU performance, likely uses less power than a RPi 4 (no fan needed) and likely uses fewer transistors than a RPi 4 giving a cost advantage. While many desktop like users would rather have more performance, the SBC is practical for embedded use which increases economies of scale and is very important for RPi hardware as well. It may be possible to produce the SiFive Unmatched SBC with PCIe for less but the CPU performance is weak for low end desktops, fewer SBCs are sold for embedded use at the higher cost, RISC-V desktop support and drivers are not mature and there is practically no RISC-V desktop market. SiFive is working on a higher performance OoO CPU core and upgrades to the SBC to become more competitive but they are chasing a market where it becomes very expensive to compete. SiFive was valued at over $2.5 billion USD in 2022 and they don't have the capital to compete in the high end OoO CPU desktop market yet. Producing a small SBC with relatively simple in-order CPU cores likely costs less than $10 million USD and is within reach of small businesses. A low cost 68k Amiga SBC would unify much of the Amiga market which has divided and is being conquered but development would require some of the Amiga related small businesses to unite. That is the real Amiga problem as Amiga hardware disappears despite a retro 68k Amiga resurgence. Where RISC-V has good hardware and no market, the 68k Amiga has a market but no good hardware.

Last edited by matthey on 19-Dec-2023 at 02:32 AM.
Last edited by matthey on 18-Dec-2023 at 08:17 PM.
Last edited by matthey on 18-Dec-2023 at 08:10 PM.

@kolla

Quote:

OS4 is outdated and buggy, Roadshow for OS4 is outdated and buggy. Why bother.

The only way to fix it is to have more users that you can't simply expect to be satisfied with the state of it.

The only way to have more users is to make it more accessible and not hugely expensive. Nobody but a fool pays top dollar for a broken system running on hardware that will likely die and be irreplaceable.

The only way to fix that it so target affordable hardware people won't feel completely ripped off over when they get a WIP system that's still rough around the edges but has mor chance of being supported.

This is all blindingly obvious in a mirror universe where people fully appreciate the folly of PPC and aren't firecly loyal to a particular hardware architecture.

_________________
Doing stupid things for fun...

@Karlos

Quote:

There was a pentium card for it

Are you sure about that?

I do remember it being "only" 486 and Wikipedia agrees with me adding some Cyrix CPU into the mix.

At the time ( C= dead, no savior yet in sight) I was thinking about jumping unto that ship but lack of funds made that a non starter....

But back to "topic":

The misconception seems to be that 68k is x times bigger than anything PPC/NG. Which might be true but only until you realize who splintered that part of the community is.

People who are just interested in running WHDLoad games, people who want to write OCS games, people who just want to tinker with period correct retro HW&SW.

And than the people who want 68k to be some kind of NG rreplacement who are again splintered into factions.

None of the factions has a clear leadership or vision which might even be considered a benefit of some kind but for sure isn't attractive for people who just want to use such a system for real and neither for developers who want create non-retro SW.

I'd say if you were to try to build a team around a project "modernized and fully useable AROS based 68k system on rPI" and you would end up with less active contributors as MorphOS has.
Same if you replace "AROS" with "AmigaOS3.x" only that it would be a slightly different group.
Replace rPI with Vampire or UAE and again some small group with a few reoccurring faces.

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

@Kronos

Quote:

Are you sure about that?

I'd be lying if I said yes but I have a strong recollection of it being a pentium, maybe 60MHz or thereabouts.

It wasn't my machine, I was a potless student at the time I first saw it. Was the "family pc" or a fellow uni mate, who's mum worked in education where the platform still held considerable sway.

I really remember liking the modular design and I was familiar with RiscOS from college which also largely used Archimedes at that time.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: The RPi Foundation is currently using smart phone SoC (CPU+IO+GPU) chips where they have a limited choice of GPUs and PCIe lanes.

Not really:

https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712

If they used a smartphone chip (even a low end one) they would have a much much better GPU.

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