@Jose

Quote:

Jose wrote: Regarding potential new users I see a huge amount of people dissatisfied with big tech these days, lots and lots of people still use Win7 for a reason, starting from Win10 on Windows has become a spyware machine... But a lot of them hate Linux. The prospect of a system that allows one to got deep in it if one wants to yet is presented in a digestible manner like AmigaOS would be appealing IMHO.. But for that we need a system that is a bit more mature in terms for SMP and memory protection...

Yep, the research shows there's a non-insignificant number of users who feel trapped between MS and Apple, and do not see Linux as the escape route. So they begrudgingly stick with Windows and/or macOS.

I'm certainly one of them. I run Windows 11 on a business laptop and on my gaming PC, I run macOS on my daily driver M2 Mac mini and my old MacBook Pro, and I run a relatively up-to-date Linux distro (currently Ubuntu Budgie 24.04) on a spare PC. Plus some Ubuntu Linux servers as VMs on a couple TrueNAS Scale home servers.

Windows is still a mess, macOS is neat but restrictive and has its fair share of annoyances, and while Linux has come a long way, it's too fragmented so it lacks software support from critical mainstream vendors.

I even tried using iPadOS on an M1 iPad Pro as my main portable for almost the entirety of 2023 (Feb - Nov). The workflows are just not ready for heavy use, and the latest iPadOS 18 does nothing to address this.

_________________
All the way, with 68k

@agami

Quote:

agami wrote: @Jose Quote: Jose wrote: Regarding potential new users I see a huge amount of people dissatisfied with big tech these days, lots and lots of people still use Win7 for a reason, starting from Win10 on Windows has become a spyware machine... But a lot of them hate Linux. The prospect of a system that allows one to got deep in it if one wants to yet is presented in a digestible manner like AmigaOS would be appealing IMHO.. But for that we need a system that is a bit more mature in terms for SMP and memory protection... Yep, the research shows there's a non-insignificant number of users who feel trapped between MS and Apple, and do not see Linux as the escape route. So they begrudgingly stick with Windows and/or macOS.

Exactly. As an amigan I don't see how Linux/Unix could have been the AmigaOS replacement after that Commodore broke: it's a diametrically opposed system to mine, and the only things in like are the new line character and the folder separator.

Not even counting that the AmigaOS had a super lightweight kernel whereas Linux is the typical monolithic monster kernel.

Paradoxically, I find Windows closer to AmigaOS.

@vox

Quote:

You are bigger x1000 guru then I was :D Bravo, you have made it! I have just tried SAM460 compiled AROS and it did not work out of box.

Thanks. Yeah, a SAM460 compiled AROS would likely crash, just like Linux would. In the least it would be held up by being designed for UBoot.

Quote:

I am glad new x1000 owner of my sold computer is indeed a developer. Gives hope more OS4 apps will use Altivec and be PA Semi optimised, and further OS4 sw working on x1000.

Yes that would be good. Good sale.

@matthey

Quote:

The PPC architecture has more performance potential than the RISC-V architecture. RISC-V is the evolution of MIPS/SPARC "classic RISC" with some improvements like code compression extension for better code density from inception, elimination of common RISC branch delay slot bad design decision, combined test/compare and branch instructions, etc. There were mistakes made though including lack of standardization with too many extensions resulting in challenging compiler support (AArch64 is the opposite with too much standard increasing core sizes), simple/weak instructions and addressing modes (PPC is stronger and AArch64 owns RISC-V in this category), false assumption that instruction fusion/folding could close the performance gap, poor big endian support (existing big endian code is common in some markets), too much encoding space reserved for future extensions and custom use reducing code density, etc. RISC-V is a better "classic RISC" improvement for the embedded market than desktop market.

Thanks for the comparison. I didn't expect PPC to come across as positive compared to RISC-V and AArch64. There's some things I think could still have been done better by keeping with the register theme. For example, an absolute 32 bit jump takes four instructions. To me that's just too much. There's existing instructions that load in high words while others reference data with low word offsets, but direct branches don't do so by jumping to a low offset from register. Instead a full double word needs to be loaded into a general register, shifted into a branch register, then branched. Even a relative branch can be +-32MB from what I read or 24 bit absolute from only one instruction but an extra 8 bits is too expensive by comparison.

Quote:

The most "common" RPi depends on the market of which about half is embedded. The target is probably something like the following.

The market I'm thinking of is the PiStorm market.

Quote:

The Cortex-A7 is a 32-bit in-order superscalar CPU core design which was replaced by the 64-bit in-order superscalar Cortex-A53. The Cortex-A7 only has a single cycle load-to-use penalty compared to the Cortex-A53 3 cycle load-to-use penalty but the Cortex-A53 has much improved superscalar multi-issue capabilities and larger caches. The Cortex-A7 low load-to-use penalty and much smaller core size could have been a better choice for the RPi embedded low power core instead of older ARM1176JZF-S and for 68k emulation but ARM has strongly pushed their newer 64-bit cores and there is more similarity between the Cortex-A7 and Cortex-A53. This would also be the category where the in-order superscalar 68060 would be with larger caches and other upgrades but I believe performance is possible approaching the RPi 4 Cortex-A72 with the benefit of zero cycle load-to-use stalls, better code density (fewer cache misses) and perfect for 68k code performance.

That looks like good reasons to chose an RPi4 for the purpose of 68K emulation above a simple "best in show" where the RPi5 will soon be sought after, once that's confirmed to be compatible with a PiStorm in what ever form.

Quote:

The performance and memory is approximately doubled while two RISC-V open hardware Hazard3 cores are included for roughly the same price.

That's interesting they introduced a RISC-V core on there as well. I wonder what caused that? That's like putting a competitor on there. Remands me of the C128 having two CPU's. Or the x86 chip with a PPC core, however that would work. Well, here again, PPC has lost out, it's even unpopular against other RISC but no one I know of tried to make PPC hacker friendly like the Pi did for ARM. RISC-V has become the funky NKOTB while PPC looks like the old school old man telling other CPUs to get off its grass.

Quote:

The basic non-stacked NOR chip has only been available since August and it already has almost as many customers lined up as A-Eon does for PPC AmigaNOne hardware.

So not many yet but they are expecting a lot more?

Quote:

I wish the 68k Amiga was as cool as RPi and AmigaNOne hardware but that failure Jay Miner made too many mistakes and the 68k, Amiga chipset and AmigaOS are trash. Trevor, Ben and ppcamiga1 are heroes for showing us PPC is the way forward.

That's funny.

Quote:

PPC is vastly superior compared to any architecture on the planet and even God himself uses PPC in heaven because of its perfection.

A Perfectly Powerful Creation?

Last edited by Hypex on 30-Sep-2024 at 05:22 PM.

@agami

Quote:

I wonder if deadw00d is considering an ARM port for AxRT. Sure, app developers would need to compile their apps for AROS ARM, but then one could have a nice and cheap Raspberry Pi 5 + AxRT mini computer. Or perhaps even run AxRT on A600GS.

You're onto something!! What about transparent emulation ala Petunia/Trance on BE...

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@AMIGASYSTEM

Quote:

You keep writing without knowing, try my AROS One distribution and you will notice that many of the "native MUI" programs run on AROS x86 with ZUNE, and if you are not aware, even on OS3 almost all MUI programs also run via "Zune" Yes you read correctly on OS3 (AfA OS) you can run MUI applications via Zune, AfA OS is nothing but AROS x Amiga. You talk about Linux as if it were a great OS, a system that nobody likes, for 30 years only 2% of users prefer it, others trash it after trying it !

AROS 68K doesn't run EA's Deluxe Music 2, hence failing the C= AmigaOS test. OS by itself is useless. Windows NT on non-x86 failed for similar reason.

EA was C='s ecosystem partner for IFF.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

AROS 68k (original branch) has problems with old software using PAL/NTSC screens. As I understand it, old software expected to get PAL/NTSC of course, whereas Aros 68k created RTG screens causing crashes of the software. Apollo team is trying to correct that.

@Hammer

AROS 68k can be fixed to greater levels of compatibility, we just need to know SnoopDOSing what causes certain user cases not to work.
Its way more compatible then MorphOS or OS4, at least that is my experience from using all 3.

In AEROS Linux mode with JanusUAE, we have both high old compatibility and fast native AROS apps.

@Hypex

I am glad new owner is proud to have x1000 as true rarity (fastest NG and one of dozen of PA Semi CPUs in use), but I lost proud title of only such user in ex-Yugoslavia, as well as used to pintch local Linux community that could not believe that modern Linux can be driven on anything but x64 :D

@Agami @Pixie

I am all for deeper integration of ARM Linux and this ScalOS :D Or offering it publicly as additional GUI toolkit

Last edited by vox on 30-Sep-2024 at 04:43 PM.

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

Hypex Quote:

Thanks for the comparison. I didn't expect PPC to come across as positive compared to RISC-V and AArch64. There's some things I think could still have been done better by keeping with the register theme. For example, an absolute 32 bit jump takes four instructions. To me that's just too much. There's existing instructions that load in high words while others reference data with low word offsets, but direct branches don't do so by jumping to a low offset from register. Instead a full double word needs to be loaded into a general register, shifted into a branch register, then branched. Even a relative branch can be +-32MB from what I read or 24 bit absolute from only one instruction but an extra 8 bits is too expensive by comparison.

Engineering is the art of compromise. The original ARM architecture was simple and had less than half the GP registers of most other RISC architectures. This resulted in small and low power cores but weak performance. With fewer GP registers, the code density should have been better but it wasn't which was especially bad for low memory bandwidth common for small cores as instruction fetch used too much of the memory bandwidth. ARM wanted to improve their code density and they looked to the leading code density RISC architecture which was SuperH to create Thumb and then Thumb-2 ISAs. They improved on the code density and used fewer registers which retained the small core advantage and added the code density advantage. This gave them the 32-bit embedded market after the 68k and SuperH (68k dominance ended because Motorola replaced the 68k with poor code density and unfriendly for humans PPC and SuperH had performance/scaling issues related to the 16-bit fixed length encoding which Thumb-2 solved). Thumb performance was still weak though. Many years later, silicon improvements allowed for higher performance embedded hardware and ARM didn't have performance. ARM looked to the RISC performance leader which was PPC and copied it with improvements to create AArch64. It is similar to but an improvement in almost every way over PPC leaving little reason for the high performance PPC embedded niche to continue. ARM needed about 17 years to surpass the performance/MHz of the CISC 68060 CPU with a similarly pipelined CPU core. PPC cores had dominated ARM cores in performance/MHz for longer although with upgraded silicon. At the same time, PPC had lost the battle for the desktop market to a higher performance/MHz CISC x86(-64) architecture. AArch64 has become more CISC like than PPC to not only scale up to the growing high performance embedded market but perhaps to try an assault on the desktop and server markets. The x86-64 architecture still has some performance advantages over AArch64 but it also has decades of baggage affecting competitiveness. The AArch64 standard ISA includes many integer instructions perhaps surpassed by only x86-64, FPU and SIMD unit with more GP registers than PPC due to standard SIMD unit. This is good for performance but very much limits how small the cores can be and how low the ISA scales (the A1222 FPU was sacrificed to try to scale PPC lower and AArch64 is fatter than PPC). AArch64 code density is about half way between PPC and Thumb-2 (or 68k) code density which is mediocre for embedded use and worse than the 68k, SuperH and Thumb-2 32-bit embedded leaders. Granted, AArch64 is a 64-bit ISA which reduces code density but most embedded cores don't need 64-bit addressing and many would prefer smaller lower power cores, a smaller footprint and a lower price. ARM has kept Thumb ISAs around for MCUs where AArch64 can't scale kind of like Motorola allowed the 68k to survive as ColdFire below where PPC could scale. The PPC601 and PPC603 sold into both the embedded and desktop markets improving the economies of scale even though the 68060 had superior performance so its wings were clipped. Poor low end PPC CPUs for both the desktop and embedded markets did much to damage PPC's reputation and poor code density was one of the reasons.

RISC-V is more comparable to the ARM Thumb ISAs with likely a little larger cores due to usually more GP registers and similar or possibly a little better compressed ISA performance but inferior code density. The best opportunity for RISC-V is below where AArch64 can scale but above Thumb and where 64-bit is needed which is why RV64IMC is the most popular ISA variant and a de facto standard. RISC-V is customizable and royalty free allowing other mostly low end embedded opportunities as well. I doubt RISC-V will ever be a performance threat to AArc64 without an ISA change in the same way ARM was not a performance threat to PPC until an ISA change.

Hypex Quote:

That looks like good reasons to chose an RPi4 for the purpose of 68K emulation above a simple "best in show" where the RPi5 will soon be sought after, once that's confirmed to be compatible with a PiStorm in what ever form.

I'm not sure it will be worthwhile for the majority of PiStorm owners to upgrade to the RPi 5 because of heat and power concerns. Emulation often has full time high CPU utilization which may send the RPi 5 SoC into melt down, especially in more common wedge Amigas.

Hypex Quote:

That's interesting they introduced a RISC-V core on there as well. I wonder what caused that? That's like putting a competitor on there. Remands me of the C128 having two CPU's. Or the x86 chip with a PPC core, however that would work. Well, here again, PPC has lost out, it's even unpopular against other RISC but no one I know of tried to make PPC hacker friendly like the Pi did for ARM. RISC-V has become the funky NKOTB while PPC is looks like the old school old man telling other CPUs to get off its grass.

The RPi Foundation may have been seriously considering the low price royalty free RISC-V advantages over ARM, at least before ARM Holdings became a partner and shareholder of the RPi Foundation.

https://riscv.org/news/2019/01/ab-open-article-raspberry-pi-foundation-announces-risc-v-foundation-membership/ Quote:

The Raspberry Pi Foundation has announced its membership of the RISC-V Foundation at the Silver Member tier, offering support for the instruction set architecture on a software – though not yet hardware – level. The original Raspberry Pi launched in February 2012 as a low-cost single-board computer (SBC) primarily targeting the hobbyist and educational market and based around a Broadcom BCM2835 single-core Arm system-on-chip. Originally developed for set-top box use, the Broadcom chip boasted surprisingly powerful graphics but a weak, 32-bit processing core – something the not-for-profit Raspberry Pi Foundation has sought to address in more recent releases, eventually settling on a 64-bit quad-core Arm Cortex-A53 IP. Now, though, the Foundation has announced that it is joining the RISC-V Foundation. “We’re excited to have joined the RISC-V Foundation as a silver member,� the Raspberry Pi Foundation posted to its Twitter account. “(We’re) hoping to contribute to maturing the Linux kernel and Debian port for the world’s leading free and open instruction set architecture.�

It is odd to add RISC-V cores with inferior performance and code density to the ARM Thumb SoC MCU. MCUs have limited transistor and power budgets. RISC-V cores are small and can be power gated off so the biggest disadvantage is the relatively small transistor increase. The gain is the cheapest RISC-V core available and increased sales to fans and developers who want cheap RISC-V hardware. It keeps RISC-V fans from feeling betrayed by the RPi Foundation and ARM Holdings too. The RISC-V core design in silicon could help debug the design so it could be an option later for deeply embedded purposes by the RPi Foundation. Having more options and control over your destiny is a good thing.

It is interesting that the RISC-V cores support RV32IMAC+ instead of the more popular de facto standard RV64IMC. Perhaps 64-bit is wasteful for low end embedded use? They still did use more transistors to support the (C)ompressed encoding but then RISC-V is as fat as classic RISC without the compression, fatter than AArch64.

Last edited by matthey on 30-Sep-2024 at 06:22 PM.
Last edited by matthey on 30-Sep-2024 at 06:21 PM.

@vox

Quote:

AROS 68k can be fixed to greater levels of compatibility, we just need to know SnoopDOSing what causes certain user cases not to work. Its way more compatible then MorphOS or OS4, at least that is my experience from using all 3. In AEROS Linux mode with JanusUAE, we have both high old compatibility and fast native AROS apps.

I'm aware of JanusUAE. Without C= KickStart ROM, JanusUAE with AROS 68K ROM couldn't run Deluxe Music 2. JanusUAE has similar limitations to other UAE.

Last edited by Hammer on 01-Oct-2024 at 11:06 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@OlafS25

Quote:

OlafS25 wrote: @Hammer AROS 68k (original branch) has problems with old software using PAL/NTSC screens. As I understand it, old software expected to get PAL/NTSC of course, whereas Aros 68k created RTG screens causing crashes of the software. Apollo team is trying to correct that .

FYI, AmigaOS 3.9 (CaffeineOS) P96 RTG can run Deluxe Music 2 without any issues.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Engineering is the art of compromise. The original ARM architecture was simple and had less than half the GP registers of most other RISC architectures. This resulted in small and low power cores but weak performance. With fewer GP registers, the code density should have been better but it wasn't which was especially bad for low memory bandwidth common for small cores as instruction fetch used too much of the memory bandwidth. ARM wanted to improve their code density and they looked to the leading code density RISC architecture which was SuperH to create Thumb and then Thumb-2 ISAs. They improved on the code density and used fewer registers which retained the small core advantage and added the code density advantage. This gave them the 32-bit embedded market after the 68k and SuperH (68k dominance ended because Motorola replaced the 68k with poor code density and unfriendly for humans PPC and SuperH had performance/scaling issues related to the 16-bit fixed length encoding which Thumb-2 solved). Thumb performance was still weak though. Many years later, silicon improvements allowed for higher performance embedded hardware and ARM didn't have performance. ARM looked to the RISC performance leader which was PPC and copied it with improvements to create AArch64. It is similar to but an improvement in almost every way over PPC leaving little reason for the high performance PPC embedded niche to continue. ARM needed about 17 years to surpass the performance/MHz of the CISC 68060 CPU with a similarly pipelined CPU core.

ARMv4T(with MMU) @ 120 to 133 Mhz competed and beat 68000 @ 33 Mhz to 66 Mhz based DragonBall in the handheld market. MIPS and ARM competed hard in smartphones market.

The smartphone market separated from the embedded market which is a safe space for ARM and Qualcomm.

Intel released X86 SoCs for Android smartphones and is usually 1 gen behind ARM competitors.

Microsoft has a second chance at handheld devices via growing handheld gaming PCs with healthy competition from AMD's Strix Point and Intel's Lunar Lake SoCs.

Quote:

PPC cores had dominated ARM cores in performance/MHz for longer although with upgraded silicon.

There are other considerations for ARM's smartphone safe space i.e. performance/watt.

Quote:

At the same time, PPC had lost the battle for the desktop market to a higher performance/MHz CISC x86(-64) architecture. AArch64 has become more CISC like than PPC to not only scale up to the growing high performance embedded market but perhaps to try an assault on the desktop and server markets.

Qualcomm Elite X was rebuffed by Intel's Lunar Lake's superior MS Office battery and IGP performance.

https://www.youtube.com/watch?v=QB1u4mjpBQI
PCWorld: Did Intel Just Save x86?
Laptops tested:
Dell XPS 13 9350 - Intel Core Ultra 7 258V (Lunar Lake)
Dell XPS 13 9345 - Qualcomm X Elite X1E-80-100
Dell XPS 13 9340 - Intel Core Ultra 7 155H
Asus Zenbook S 14 - Intel Core Ultra 9 288V (Lunar Lake)
Asus Zenbook S 16 - AMD Ryzen AI 9 370
Asus Zenbook S 14 - Intel Core Ultra 7 155H
Microsoft Surface Laptop 7 13" - Qualcomm Snapdragon X Elite X1E-80-100

Both Qualcomm Elite X and Intel Lunar Lake are on TSMC's 3 nm process node.

AMD needs to move into TSMC's 3 nm process node.

On UL Procyon Office 365 Battery Life "best efficiency" in minutes
Dell XPS 13 9345 - Qualcomm X Elite X1E-80-100 = 1207 minutes (20.11 hours)
Dell XPS 13 9350 - Intel Core Ultra 7 258V = 1295 minutes (21.58 hours)

------------
Cinebench 2024 multi-threads, higher is better,
Macbook Pro 14 M3 = 693
Macbook Pro 14 M3 = 658

Asus Zenbook S 16 - AMD Ryzen AI 9 370 = 982
Microsoft Surface Laptop 7 13" - Qualcomm Snapdragon X Elite X1E-80-100 = 869

Framework / Core i71360P = 557
Asus Zenbook S 14 - Intel Core Ultra 9 288V (Lunar Lake) = 620
Dell XPS 13 9350 - Intel Core Ultra 7 258V (Lunar Lake) = 561

PS; Cinebench 2024's AVX-512 support is at a very low amount.
https://chipsandcheese.com/2023/10/22/cinebench-2024-reviewing-the-benchmark/
Cinebench 2024 makes little use of vector compute. Most AVX or SSE instructions operate on scalar values. The most common FP/vector math instructions are VMULSS (scalar FP32 multiply) and VADDSS (scalar FP32 add). About 6.8% of instructions do math on 128-bit vectors. 256-bit vectors are nearly absent, but AVX isn’t just about vector length. It provides non-destructive three operand instruction formats, and Cinebench leverages that.

------------
Blender 4.1 Barbershop CPU cycles, lower is better.
Asus Zenbook S 16 - AMD Ryzen AI 9 370 = 1458

Asus Zenbook S 14 - Intel Core Ultra 7 155H = 2455
Asus Zenbook S 14 - Intel Core Ultra 9 288V (Lunar Lake) = 2884
Dell XPS 13 9350 - Intel Core Ultra 7 258V (Lunar Lake) = 3139

Microsoft Surface Laptop 7 13" - Qualcomm Snapdragon X Elite X1E-80-100 = 3429

PS; Blender 4.1 supports Zen 5's AVX-512.

Last edited by Hammer on 01-Oct-2024 at 11:52 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@thread

I'm only holding on to a G4 Mac mini 1.5GHz because of MorphOS. The PowerBook G4 has developed a severe case of screen backlight flickering, and I have given up on finding a 2GHz+ PCIe G5 Power Mac, for too many months now my auto eBay search has yielded zero results.

The moment MorphOS shows the next major version of the OS running on x64 or ARM64, it is definitely a final and not so fond "Goodbye PowerPC" from me.

Oh wait, does a PS3 count? I gave up the Xbox 360 a long time ago but I still have a running PS3.
I need to test how much PS3 emulation has improved and see if it can run a few of those exclusive titles.

_________________
All the way, with 68k

@Hammer

yes

but who cares?

most want to play games so whdload is important. And that works f.e.

amiga fans creating music on amiga is certainly a small minority

@OlafS25

Quote:

amiga fans creating music on amiga is certainly a small minority

Oh I don’t know about that. People who create music on Amiga may not define themselves as Amiga fans, hanging around on lame forums arguing about could or should have been…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

It was specifically the musical capabilities of the Amiga that got me into it first. You couldn't buy a better sampler/sequencer for the price back then. Much was made of the ST's inbuilt midi but even if you found the cost of a midi interface too expensive, you could build your own for not very much - a couple of optoisolators and some other passive components and you were good to go.

_________________
Doing stupid things for fun...