Opinion: PPC, 68080 and other [660 comments]

Page 1 of 2 **** 

Opinion: PPC, 68080 and other [660 comments] pix (last poster: hammer) Amiga scene Not wanting to start a flame war with my first post on this board, but I'm hoping to get some solid opinion on the best Amiga hardware direction to take. For where I am coming from, after experimenting with various Amiga offerings over the years, emulation options are a given. Love digital...

English Amiga Board > Main > Amiga scene

Opinion: PPC, 68080 and other

Quote:

Originally Posted by pandy71 PCIe (started with PCI) is one side of problem, another one is internal CPU latency - inability to interact with GPIO in time comparable to cycle time - this is why some vendors adding IO coprocessor or separate processor optimized to IO operation - TI has very flexible Programmable Real Time Unit and it can provide low latency https://www.ti.com/lit/sprace8 (approx 10 times lower than remaining CPU SoC) - also XMOS https://www.xmos.com/ provide solutions to achieve low latency front end for fast CPU - if you separate both then you gain possibility to use SoC's other than Broadcom (still lacking full documentation - for example video core is closed documentation).
Using PCIe or USB in isochronous mode probably will be time consuming but having multiple core CPU's this should be not a problem - you can dedicate single or two cores only to deal with isochronous mode.

Quote:

Originally Posted by hammer The goal after RPi 4B / CM4 is to be better than ARM Cortex A72 while maintaining GPIO performance, not with a lower-tier Buffee / TF1200. The supply for RPi 3A+ / 3B and 4B / CM4 is not the issue.

RPi 3A+ Emu68 has no problems passing Buffee's Ti AM3358.

Quote:

Originally Posted by Bruce Abbott 4B/CM4 seems to be good enough. Why go further?

Quote:

Originally Posted by hammer RP2040's PCIe would need to be upgraded for newer PCIe versions (lower latency), or improve RP2040's ARM Cortex M0+ @ 133 MHz with ARM Cortex A76 or higher e.g. Cortex A78C.

RP2040 is the 1st attempt to remove middleman Broadcom SoC IP dependency.

Originally Posted by hammer @ https://www.ti.com/lit/sprace8
Ti AM335x Sitara SoC has ARM Cortex A8 up to 1 Ghz, which doesn't replace RPi 3A to 4B / CM4. https://www.ti.com/product/AM3358

Reminder, Buffee / TF1200 project uses Ti AM3358 with Cortex A8 @ 1 Ghz inside OSD3358 system on package.

The goal after RPi 4B / CM4 is to be better than ARM Cortex A72 while maintaining GPIO performance, not with a lower-tier Buffee / TF1200. The supply for RPi 3A+ / 3B and 4B / CM4 is not the issue.

RPi 3A+ Emu68 has no problems passing Buffee's Ti AM3358.

Originally Posted by hammer RPi 5 with RP2040 attached GPIO seems to be the transition phase towards RPi fat SoC attached GPIO.

Quote:

Originally Posted by pandy71 At first you can use lower latency mode on current PCIe - just use isochronous mode so latencies will be reduced.
More complex CPU core means higher computational performance at a higher latency.

From NVIDIA Moderator,
Date: March 19, 2024.

"PCIe is not isochronous client, so there are no options to 
reduce latency or prioritize memory traffic from PCIe device."

Originally Posted by pandy71 So interface frontend need to be served by simple CPU offering low latency not high computational performance.

Originally Posted by pandy71 Everything is correct except one thing - BeagleBone Pocket 2 use AM6254 (quad-core A53 plus GPU) so performance is comparable to RPi4 at least, GPU performance is higher than BCM.

Originally Posted by pandy71 Perhaps - this allow higher flexibility and performance.
My point was however not comparing RPi4 or RPi5 with other SoC's but show that RPi can have alternatives.

Quote:

Originally Posted by Thomas Richter But users may not. The beauty of gadtools is (not only) the simplified interface. The beauty is that programs using it get a consistent look and feel, and a consistent GUI. This is important for usability. If you create custom gadgets (like everyone did in 1.2 and 1.3) you get the type of crappy programs you've seen under such kickstarts a lot. Like IconEdit. Not only crappy because the GUI wasn't well thought about, but also crappy because every program came with its own idea of how the GUI should look like. Compare 1.3 IconEdit with 1.3 "FED" (Font Editor). Totally different, totally irritating.

The "RKRM User Interface Style Guide" is an important book, and it is extremely helpful to create usable applications. Not only because it contains useful hints, but also because it ensures that all applications share a common look, and users feel "at home".

This was right from start an important feature of the Apple Macintosh (its strict requirements on user interface), CBM learned that relatively late, and gadtools is part of this idea. It is "the right way" of creating the user interface on AmigaOs, and the way that ensures the graphical design of your GUI fits to the rest of the system.

Quote:

Originally Posted by hammer 1. Michal Schulz already addressed RPi 5's unsuitability for Emu68 as an Amiga accelerator solution.

Originally Posted by hammer 2. Reminder, RPi 4B and CM4 already have ARM Cortex A72.

Originally Posted by hammer Cortex A76 and A78 are the 4 instructions issued per cycle improvements from Cortex A72's 3 instructions issued per cycle.

Originally Posted by hammer PCIe 2.0 and 3.0 do not inherently have an "isochronous mode".

PCIe 5.0 has an isochronous mode.

Originally Posted by hammer Michal Schulz already addressed RPi 5's unsuitability for Emu68 as an Amiga accelerator solution.

R2040's slow processing adds additional latency on top of the older PCIe's latency.

Originally Posted by hammer Emu68 is open source, do it yourself, prove it.

Originally Posted by hammer AM62xx family wasn't mentioned in your cited
https://www.ti.com/lit/an/sprace8a/sprace8a.pdf

Originally Posted by hammer AM57x has dual ARM Cortex-A15.
AM65x has a quad ARM Cortex-A53, which RPi 3A+ and 3B already have ARM Cortex-A53.

Ti's CPU selection scope does not exceed RPi 3A+'s and 3B's ARM Cortex-A53 selection, let alone RPi 4B's and CM4's ARM Cortex A72.

RPi4 has ARM Cortex A72 which is far superior to ARM Cortex A53.

The Broadcom BCM2837B0 processor's quad-core ARM Cortex-A53, as found in the Raspberry Pi 3B+, has a 512KB L2 cache.


That's not progressing beyond RPi4's ARM Cortex A72 selection.

Quote:

Originally Posted by hammer 1. During the 16-bit era, the Amiga 500 kept up with mainstream game consoles with the 68000 selection e.g. Sega Mega Drive/ Genesis.

During the 32-bit era, 68EC020 to 68030 wasn't on par with low-cost ($15 to $20) MIPS 3050 (R3000A with embedded MMU). MIPS 3050 is a poor man's 68LC040-like 1 IPC CPU solution.

On the CPU front in modern times, RPi 4B or CM4's ARM Cortex A72 slightly exceeds Nintendo Switch 1's ARM Cortex A57. Both Cortex A72 and Cortex A57 are three-issue wide ARMv8A CPU designs. With PiStorm32 with CM4 or 4B, the CPU selection slightly exceeds a mainstream game console's CPU selection.

Raspberry Pi 4 Model B ends on 01 Jan 2034.

Raspberry Pi CM4 ends on 01 Jan 2034.

Quote:

Originally Posted by pandy71 Other SoC's can be alternative.

Originally Posted by pandy71 From Amiga perspective difference will be insignificant - 10..15%?

Originally Posted by pandy71 Once again - gain from Amiga perspective probably will be insignificant.

Originally Posted by pandy71 USB support isochronous mode. Even USB2 should be capable to deal with typical Amiga system.

Originally Posted by Bruce Abbott Translation:- PiStorm 4 is plenty good enough.

Quote:

From Amiga perspective difference will be insignificant - 10..15%?

Quote:

Originally Posted by hammer Why? The Buffee/TF1200 project can cover alternative Ti SoCs.

Originally Posted by hammer RPi 3A+/3B+'s ARM Cortex A53 is a dual instruction issue per cycle in-order CPU design. RPi 3A+'s quad Cortex A53 cores have a unified 512 KB L2 cache.

RPi 4B/CM4's ARM Cortex A72 is a three-instruction issue per cycle out-of-order CPU design. ARM Cortex A72 is directly based on ARM's larger Cortex A57 CPU core. RPi 4B / CM4s quad Cortex A72 cores have a unified 1MB L2 cache.

Cortex A53 = little core.
Cortex A57 = big core.

Emu68 with stock RPi 3A+ yields about Pentium II 300 or Celeron 300A level. It can be higher with a 1.6GHz overclock. The increased voltage can reach 1.8GHz overclock.

Emu68 with stock RPi 4B yields about a Pentium III 750 level. It can be higher with a +2GHz overclock, and can reach 3GHz with voltage increase and good cooling. My PiStorm32+RPi CM4 has a 2.1 GHz overclock without a voltage increase (warranty status is still ok). No problems rivaling 1.15Ghz SAM460ex or 1Ghz G4 AmigaOne XE(memory subsystem is rubbish).

Amiberry with RPi 5 (ARM Cortex A76) can brute force and beat the Emu68 + RPi CM4 (ARM Cortex A72) combo.


Wrong.

I have RPi 3A+, RPi 4B and RPi CM4.

Originally Posted by hammer Prove it.

In USB 2.0, isochronous transfers, designed for real-time data like audio and video, have a latency of 1 millisecond (ms) for Full Speed and 125 microseconds (µs) for High Speed.

The requirement is nanosecond range, NOT microseconds.

1 microsecond = 1000 nanoseconds

-------------------

Originally Posted by hammer For PiStorm32's current release, RPi 4B / CM4 is enough, but the planning is for "next gen" releases.

The original 16-bit PiStorm CPLD officially supports RPi 3A+ and Zero 2. RPi 4B can work, but not guaranteed. My original 16-bit PiStorm

Originally Posted by hammer If the Amiga platform is properly backed by better-funded investors, it should be ARM. PowerPC e5500 @ 1.4Ghz/T1040's 170 euros are too expensive for a modern A500-style reboot. Looking at the Nintendo Switch 2 hardware level.

Quote:

Originally Posted by Promilus Is that the same between A53 vs A72 PiStorm? No it is not. So why do you assume it suddenly will come to barely noticeable in A76 vs A72 when runnin 68k JIT?

Quote:

Originally Posted by pandy71 My point was NOT on particular product but on general principle - there are multiple SoC's with capabilities same or better than those from BCM.
TI SoC's equipped with PRU may replace FPGA/CPLD in software.
Other SoC's need some FPGA/CPLD to interface with 68k bus.

Originally Posted by pandy71 Once again - you are bonded to one, particular SoC family from BCM and one family of products based around BCM SoC's.

But there are others SoC's offering other options, also higher clock and perhaps better memory subsystem - search for benchmarks - RPi solutions are not the best ones - they are OK - definitely most popular - that's all.

Originally Posted by pandy71 Seem you are confused - you need some FPGA/CPLD to interact with real 68k bus so this part can be transparent from SoC perspective.
You have like 48..56 I/O's at least to deal with - you need some frontend for such complex SoC's like modern ARM based - I/O latency, interrupt overhead etc.

Quote:

Originally Posted by hammer For PiStorm32's current release, RPi 4B / CM4 is enough, but the planning is for "next gen" releases.

The original 16-bit PiStorm CPLD officially supports RPi 3A+ and Zero 2. RPi 4B can work, but not guaranteed. My original 16-bit PiStorm CPLD "Rev B Max II" is working with RPi 4B.

The incoming PiStorm16 FPGA officially supports up to RPi CM4.

If the Amiga platform is properly backed by better-funded investors, it should be ARM. PowerPC e5500 @ 1.4Ghz/T1040's 170 euros are too expensive for a modern A500-style reboot.

Quote:

Originally Posted by Bruce Abbott Pathetic. We barely have CM4 and Amiga fans already want more. When will it end?

Originally Posted by Bruce Abbott If it works it's good enough - better than Amiga accelerator cards often used to be back in the day!

Originally Posted by Bruce Abbott I agree. RPi has everything we need including volume production. Other similar SoC's could do the job too. PPC is only of interest to OS4 fans.

Quote:

Originally Posted by Bruce Abbott I agree. RPi has everything we need including volume production. Other similar SoC's could do the job too. PPC is only of interest to OS4 fans.

Quote:

Originally Posted by hammer Cite a cheap Ti SoC with better than RPi 4's Cortex A72.

Originally Posted by hammer That's just noise.

Originally Posted by hammer You're confused. Go argue against Michal Schulz and Claude. Claude has identified PCI 3.0's 125 ns improvement as path way for RPi 5.

Quote:

Originally Posted by pandy71 It has poor 3D without chance to be fully open source (means no chance for native Amiga drivers). Video decoder in BCM is master ruler of the whole SoC and it is not open sourced at all.