RPi5 only an incremental upgrade over RPi4 under Emu68k ?

[VladR]

RPi5 boards are slowly hitting the market. I found out only yesterday that the CPU used is just a minor upgrade over the one in RPi4 (from the perspective of EMU68k, e.g. ignoring VideoCore for our purposes):

|Board |      CPU      |  Clock  |   OC  |
------------------------------------------
|RPi3  |  Cortex A-53  |  1.4 GHz|
|RPi4  |  Cortex A-72  |  1.8 GHz| 2.5 GHz
|RPi5  |  Cortex A-76  |  2.4 GHz| 3.0 GHz
------------------------------------------

Anybody already got an early board and ran SysInfo under EMU68k?

Current OC looks stuck at 3.0 GHz: https://www.tomshardware.com/news/ov...raspberry-pi-5

[Kin Hell]

Originally Posted by VladR

RPi5 boards are slowly hitting the market. I found out only yesterday that the CPU used is just a minor upgrade over the one in RPi4 (from the perspective of EMU68k, e.g. ignoring VideoCore for our purposes):

|Board |      CPU      |  Clock  |   OC  |
------------------------------------------
|RPi3  |  Cortex A-53  |  1.4 GHz|
|RPi4  |  Cortex A-72  |  1.8 GHz| 2.5 GHz
|RPi5  |  Cortex A-76  |  2.4 GHz| 3.0 GHz
------------------------------------------

Anybody already got an early board and ran SysInfo under EMU68k?

Current OC looks stuck at 3.0 GHz: https://www.tomshardware.com/news/ov...raspberry-pi-5

Don't have one myself but will be after a CM5 if they're released for a CM4 Board.

It's not just the CPU speed here but the I/O via the Pi5's new SouthBridge Chip....

@ Mod's....

Can you slip this post into the "Pistorm32 showcase thread" please?

https://eab.abime.net/showthread.php?t=115573

[derSammler]

Does Emu68 even run on the new Pi5? I doubt it has support for it already.

Not that it's really needed. Even with the Pi3, Emu68 is more than fast enough. :-)

[Kin Hell]

Originally Posted by derSammler

Does Emu68 even run on the new Pi5? I doubt it has support for it already.

Not that it's really needed. Even with the Pi3, Emu68 is more than fast enough. :-)

Support??

The Architecture of the Pi5 should be the same as 3 & 4 other than the SouthBridge implimentation which hugely speeds up I/O @ Linux Level.

Why are folk always doubtful about life & what goes on around them??

AmigaDOS was a cut down version of UNIX & then we had Linux which runs on an Amiga. Emulation of the 68xxx chipset was just a matter of progress like WinUAE.

Jump on the bandwaggon, grab the bouncing ball of life & run with it!

[Promilus]

Dear VladR - is the clock frequency the only thing that matters? Guess again. Cortex A72 (RPi4) overall performance with the very same clock as Cortex A53 (RPi3) is over 50% higher. Similar thing happens with Cortex A76 (RPi5) vs Cortex A72. Now ... the real question is whether 4 core A76 is good enough for RPi5 ... Considering the biggest rival has the same 4 cores of Cortex A76 plus 4 cores of Cortex A55 and in full version (not S one) PCie 3.0 4x ...

[klx300r]

Originally Posted by derSammler

Does Emu68 even run on the new Pi5? I doubt it has support for it already.

Not that it's really needed. Even with the Pi3, Emu68 is more than fast enough. :-)

+1 my 3A+betters my CS-MKIII 060 in my A4000 speed wise in almost all facets and is almost as compatible and for me stability and compatibility is way important than raw speed

[ptyerman]

Originally Posted by Boing-Ball

Nah.. Pi4 all the way! Sorry but the 2 x speed difference of a Pi3 especially on the FPS RTG games seals it for me….

Biggest problem there is that the Pi4 doesn't work for most people who are running the original Pistorm or Pistorm 2k, neither is it officially supported. Support info is try it and see, if it works "great" if not "tough!

[nikosidis]

It all depends on your needs. For most Pi3 is more than enough. What I like with Pi3 is no need for fan.

[ptyerman]

Totally agree. I have a Pi3a in my A2000 and it flies! Plays all my music files including FLAC, same with video, plays everything I throw at it as long as it has a supported codec. The RTG fps games I leave for my PC's where they were intended for.

[VladR]

Originally Posted by Promilus

Dear VladR - is the clock frequency the only thing that matters? Guess again.

But that's the only discussion we can have, unless you have Sysinfo benchmarks that can show the following:

1. Difference between using single core, 2 cores, 4 cores
2. Repeat Step 1 for A53, A72, A76
3. Repeat Step 2 for Base clock, 10% OC, 25% OC

Originally Posted by Promilus

Cortex A72 (RPi4) overall performance with the very same clock as Cortex A53 (RPi3) is over 50% higher. Similar thing happens with Cortex A76 (RPi5) vs Cortex A72.

Sysinfo benchmarks from under Emu68k, please. Show me that the architectural ARM improvements directly translate to your quoted 50% improvement in MIPS.

Originally Posted by Promilus

Now ... the real question is whether 4 core A76 is good enough for RPi5 ... Considering the biggest rival has the same 4 cores of Cortex A76 plus 4 cores of Cortex A55 and in full version (not S one) PCie 3.0 4x ...

A rival ? You mean - like, in a laptop/mobile space ?

Who here on this board truly cares for the performance of this thing for non-Emu68k use case? Its outside-of-amiga real-world performance is -at best- beyond pathetic compared to the fastest CPUs out there, as it's not even attempting to compete with Intel/AMD, given the target market.

[Promilus]

As I said - it's too early to say RPi5 will be capable of actually working with PiStorm in the first place. And yes - since A72 vs A53 performance in native code directly translated to emu68k performance with big enough JIT buffer it's pretty obvious A76 vs A72 does the same. The real problem is RPi5 has all i/o over pcie internal bus which complicates things for PiStorm. Pistorm works only on RPi because of how older chips handle GPIO. PCIe introduced some significant latency (despite overall devastatingly high throughput) and most likely RPi5 won't be fast enough (gpio-wise) to handle 68k interface emulation. And if it could've been easily handled through pcie then every f.. ARM SBC with free PCIe lanes could potentially be of use with the project (but unfortunately is NOT!) PiStorm guys will check it deeper once they get their hands on RPi5 boards but initial impression is not particularly optimistic. So before making some a thread of RPi5 performance with PiStorm maybe wait to confirm whether that board is even feasible... And no - by rival I mean RK3588 solutions. We're - after all - talking about relatively cheap SBCs...

[pandy71]

Originally Posted by Promilus

And no - by rival I mean RK3588 solutions. We're - after all - talking about relatively cheap SBCs...

Is there any datasheet/documentation for RK3588 comparable to RPi BCM SoC's (on overall it should be better but everything is in details, for example you can have 8 cores but if they are limited by internal throughput then you end in similar to CHIP bandwidth limitation).

[Promilus]

Regarding RK3588 - there's TRM with only around few thousand pages... but that's beside the point.
RPi5 has GPIO through RP1-C0 chip which takes over most i/o interfaces like spi, i2c but also handles "general purpose" functionality. And works with the main SoC through PCIe. So in the end if you can get this one to work there's absolutely no real obstacle to just dump all 68k interface functionality to FPGA which works as PCIe peripheral to ANY ARM SBC out there with PCIe interface (and maybe not only ARM SBCs). But this is also the one solution PiStorm guys already did discard as unfeasible in the past. So I guess if they do deliver RPi5 based PiStorm they might be stepping on a minefield of their own success (with bunch of ppl asking to support their risc-v, x86 or exotic arm boards with pcie interfaces).

And as for performance issues you present - irrelevant for emu68 which is inherently single threaded which makes core count unimportant for this particular usage but in multi threaded apps - despite being much slower than performance cores - those additional efficiency cores working alongside perf. cores DO improve performance.

[VladR]

Originally Posted by Promilus

As I said - it's too early to say RPi5 will be capable of actually working with PiStorm in the first place. And yes - since A72 vs A53 performance in native code directly translated to emu68k performance with big enough JIT buffer it's pretty obvious A76 vs A72 does the same. The real problem is RPi5 has all i/o over pcie internal bus which complicates things for PiStorm. Pistorm works only on RPi because of how older chips handle GPIO. PCIe introduced some significant latency (despite overall devastatingly high throughput) and most likely RPi5 won't be fast enough (gpio-wise) to handle 68k interface emulation. And if it could've been easily handled through pcie then every f.. ARM SBC with free PCIe lanes could potentially be of use with the project (but unfortunately is NOT!) PiStorm guys will check it deeper once they get their hands on RPi5 boards but initial impression is not particularly optimistic. So before making some a thread of RPi5 performance with PiStorm maybe wait to confirm whether that board is even feasible... And no - by rival I mean RK3588 solutions. We're - after all - talking about relatively cheap SBCs...

That's - uhm, disheartening
But, thanks for the insight. I may have jumped to early conclusions about feasibility of simply recompiling the code for A76 target ...

I was thinking of skipping RPi4 completely and just getting RPi5, but I guess I better get something that is proven to run RTG, after all. It's not like obtaining another RPi is breaking a bank exactly...

[pandy71]

Originally Posted by Promilus

Regarding RK3588 - there's TRM with only around few thousand pages... but that's beside the point.

Well... Detailed DS may help substantially if you are doing something non-standard (like in circuit hw emulation).

Originally Posted by Promilus

RPi5 has GPIO through RP1-C0 chip which takes over most i/o interfaces like spi, i2c but also handles "general purpose" functionality. And works with the main SoC through PCIe. So in the end if you can get this one to work there's absolutely no real obstacle to just dump all 68k interface functionality to FPGA which works as PCIe peripheral to ANY ARM SBC out there with PCIe interface (and maybe not only ARM SBCs). But this is also the one solution PiStorm guys already did discard as unfeasible in the past. So I guess if they do deliver RPi5 based PiStorm they might be stepping on a minefield of their own success (with bunch of ppl asking to support their risc-v, x86 or exotic arm boards with pcie interfaces).

True but also seem FPGA's with embedded core like Zynq may be the best approach for MC68K HW emulation.

Originally Posted by Promilus

And as for performance issues you present - irrelevant for emu68 which is inherently single threaded which makes core count unimportant for this particular usage but in multi threaded apps - despite being much slower than performance cores - those additional efficiency cores working alongside perf. cores DO improve performance.

No doubt on this but once again - any SoC without hard time capability (like PIO in RP2040 or PRU in TI or FlexIOin NXP) need to use FPGA so FPGA with embedded hard uP core seem to be most optimal solution.

Btw - isn't XMOS solution seem to be viable alternative to FPGA approach?

[Promilus]

Originally Posted by pandy71

Well... Detailed DS may help substantially if you are doing something non-standard (like in circuit hw emulation).

sure, but lack of documentation ain't stopping PiStorm guys from introducing e.g. fully accelerated 3D. It's manpower. Trying to bite another SoC is the same - lack of manpower to use other chips. There's no one capable of rewriting current emu to work on other hardware than RPi3/4/zero2. Despite the fact other chips do have good enough documentation.

True but also seem FPGA's with embedded core like Zynq may be the best approach for MC68K HW emulation.

Yes and no. Yes - because it's fully integrated hard processor with FPGA around so you could easily offload everything amiga interface related to FPGA, built whatever memory interface you need and whatever peripherals. But... ZynQ 7000 is Cortex A8 ~600MHz. That's rather old ARM core and obviously lacking in performance. That's also the only ZynQ actually being affordable for masses. Those FPGAs which has newer ARM hard processors are really expensive and hard to get by hobbyist. Also those ARM cores are still not nearly as fast as the one in RPi4. Not to mention RPi5.

No doubt on this but once again - any SoC without hard time capability (like PIO in RP2040 or PRU in TI or FlexIOin NXP) need to use FPGA so FPGA with embedded hard uP core seem to be most optimal solution.

Btw - isn't XMOS solution seem to be viable alternative to FPGA approach?

I'm not sure something like "xcore" is proper solution for JIT emulation. Which requires JUST the highest performance CPU you can imagine (and yes, most likely something like custom ARM 8.2+ would blow our mind).

[VladR]

Originally Posted by Promilus

sure, but lack of documentation ain't stopping PiStorm guys from introducing e.g. fully accelerated 3D.

What exactly do you mean here ?
68040-based OpenGL driver ? Or 68040-based 3DFX ?

A bare-metal JIT might come close to 3DFX-level, but the current 1000-2000 MIPS ain't nothing to write home about in terms of 3D acceleration.

You'll blow through 1000 MIPS just doing bilinear filtering on CPU at 640x480...

[Promilus]

@VladR - VideoCore inside RPi is 3D graphics module. There's open source driver available as well for Linux which might be a basis of AOS driver exposing actual capabilities of the chip for Amiga users. But... it won't write by itself. Someone has to do that. And it's not a top priority for Michal Schulz - emu68 creator. All we have now is rudimentary 2D and it certainly won't change anytime soon. Alternatively you might just write native ARM version of Wazp3D and run it on spare core(s) (as there are 3 which doesn't seem to see much of the use). But again - that won't be done unless someone actually does that. You don't see many ppl eager to do that in their spare time and for free. Right?

[pandy71]

Originally Posted by Promilus

sure, but lack of documentation ain't stopping PiStorm guys from introducing e.g. fully accelerated 3D. It's manpower. Trying to bite another SoC is the same - lack of manpower to use other chips. There's no one capable of rewriting current emu to work on other hardware than RPi3/4/zero2. Despite the fact other chips do have good enough documentation.

True, but this was my point about XMOS (I/O + some frontend).

Originally Posted by Promilus

Yes and no. Yes - because it's fully integrated hard processor with FPGA around so you could easily offload everything amiga interface related to FPGA, built whatever memory interface you need and whatever peripherals. But... ZynQ 7000 is Cortex A8 ~600MHz. That's rather old ARM core and obviously lacking in performance. That's also the only ZynQ actually being affordable for masses. Those FPGAs which has newer ARM hard processors are really expensive and hard to get by hobbyist. Also those ARM cores are still not nearly as fast as the one in RPi4. Not to mention RPi5.

Yes, clock is low but you can do some things in HW so create hybrid solution (some instructions emulated in software some performed directly by HW).

Originally Posted by Promilus

I'm not sure something like "xcore" is proper solution for JIT emulation. Which requires JUST the highest performance CPU you can imagine (and yes, most likely something like custom ARM 8.2+ would blow our mind).

XMOS as FPGA replacement - way easier to do some things in software than HW. Also FPGA has stepper entry curve, sometimes prohibitive. XMOS can directly interact with Amiga HW - sufficiently fast to emulate in software all HW tasks.

[Promilus]

If you want something fairly easily interfaced to amiga, done in software, no fpga and fairly decent core then just use TI Sitara - AM623 or something like that. That's the general approach nonarkitten had (+ her PJIT). Unfortunately it seems that project is stuck due to the obsolescence of the older Sitara chip, some mistakes during initial pcb design and absolutely no dev skills of those few ppl which ordered board samples for their amigas (which was the prerequisite to have some as it was hardly functional at that point).