Raspberry Pi 5 - official announcement

mbrennock

@windg Thanks! I'll get started on that when I have some free time this weekend.
I just got my Pi5 in the mail today. I'll test it with Raspian later tonight.

90sgamer

@mitu is there any news about when retropie will be released for pi 5?

ExarKunIv

@90sgamer nope, just what you see here.
its still going to be a good few months

skankieflank

Using Batocera beta builds lr-dolphin with API vulkan is working really well. Tested a bunch of games and mostly they worked with very good framerate.

Hopefully we can do the same with RetroPie.

windg

@skankieflank The addition of Vulkan is on his way, see: https://github.com/RetroPie/RetroPie-Setup/pull/3785 .

skankieflank

@windg
That's good news.
Batocera have someone making beta images for the Pi5 and it's working great. Almost all the systems which I use on pi4 with RetroPie are working as they should. The person working on it doesn't even have a Pi5 yet.

I'm a long time user of RetroPie and understand it will take much longer for RetroPie to have a image released but very excited for that in the future knowing how well the Pi5 is running.

Jiryn

I'm just hoping it can play 3DO and Amiga CD/CD-TV Games without issue.

roslof

Regarding Pi 5 and Arcade games (lr-mame, lr-fbneo and similar) for what it's worth, I received my Pi 5 this past weekend and updated my Arcade Recommended Emulator List.

Goal here is multiple:

Reveal a highly optimized list of games that are very playable on the Pi 4B and now also for the Pi 5B (added column)
Recommended emulators are shown
Recommendations are explained on the first tab, but essentially, I'd like to get down to as few emulations as possible (lr-fbneo and lr-mame) with as much libretro functionality as possible.
Provide notes and tips for how to best get these running. I use a DualShock 4 controller, so a few comments around this and similar controllers.

Some takeaways for the Pi 5:
From what I can tell. Killer Instinct (1 & 2) are still not quite playable with libretro arcade emulators. Same with the NFL Blitz series.

Also, still can't get many Sega/Titan games to run with any emulator except the stand-alone advmame.

Almost all games that used to run well with lr-mame version 0.222 work fine with the most recent lr-mame. This is pretty huge, since MAME's addition to netlist discrete audio has been an issue on the Pis since 0.223.

Overall, great improvement across the wide spectrum of games, but still tricky to find the right emulator for the job. (Eg. Starblade is now at full-speed with lr-mame2016 with full graphics, but not with any other emulator (including lr-mame which can't hit framerate or lr-mame2003-plus which lacks a lot of the visuals).

So you don't just get more speed with the Pi 5. You definitely get more compatibility.

Been enjoying tinkering so far. Should be amazing once all of the video drivers and such are in order and an official release happens in the future.

ChaosEffect

@roslof Do you have an installation script (or perhaps a binary) for that "lr-mame 0.222" for Pi 5? I am curious about some games not on your list with that particular snapshot of MAME and want to try them out.

roslof

@ChaosEffect said in Raspberry Pi 5 - official announcement:

@roslof Do you have an installation script (or perhaps a binary) for that "lr-mame 0.222" for Pi 5? I am curious about some games not on your list with that particular snapshot of MAME and want to try them out.

Here is a link to the source from the lr-mame github repo:

https://github.com/libretro/mame/releases/tag/lrmame0222

and here is the referenced changelist to sync to:

https://github.com/libretro/mame/commit/739058dac4d2d2a4553b8677cc54ebe474fea6c3

I don't have a 64-bit binary handy at the moment, but if you backup and modify lr-mame.sh found in ~/RetroPie-Setup/scriptmodules/libertrocores/ you can add the first seven (7) characters of the changelist 739057d to this line:

rp_module_repo="git https://github.com/libretro/mame.git master 739058d"

This should build the 0.222 binary for you.

NOTE: This may clobber your existing lr-mame binary found at /opt/retropie/libretrocores/lr-mame, so be sure to rename the directory first, to something like lr-mame-newest

After lr-mame 0.222 builds, rename your binary folders as desired and update your emulators.cfg file to allow for multiple versions of lr-mame to be used.

I use:
lr-mame for the newest
lr-mame0222 for 0.222

And then have two (2) entries in emulators.cfg that point to each binary.

Hope that helps. (this is all from memory, but I believe this is accurate).

ChaosEffect

@roslof Hey, thanks for the quick response.

What you described is what I did try already (I also maintain several versions of some emulators for testing purposes), but the compile for this particular one just...crashes after about 43 minutes without any obvious error. I was able to compile upstream lr-mame just fine after increasing the swap size in the script (Pi 5, 4GB), but this particular 0.222 snapshot is not cooperating at all.

(I named it lr-mame2020). It just seems to stop while in the middle of compiling a driver (not enough memory maybe?). Reducing the swap size in the script resulted in a similar effect with an earlier driver in the list. I do have one more thing to try in a few hours.

Here's what popped up in the log:

Archiving libemu.a...
make: *** [makefile:1385: linux] Error 2
Removing additional swap
Could not successfully build lr-mame2020 - MAME emulator - MAME (current) port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame2020/mamearcade_libretro.so not found).
/home/pi/RetroPie-Setup```

roslof

@ChaosEffect said in Raspberry Pi 5 - official announcement:

(I named it lr-mame2020). It just seems to stop while in the middle of compiling a driver (not enough memory maybe?). Reducing the swap size in the script resulted in a similar effect with an earlier driver in the list. I do have one more thing to try in a few hours.

I add -j1 to the make line. Slower, but those memory-zapping items have historically made it through for me -- having only one core using memory instead of 2-4.

Let me try a run and see where things go since issue might be unrelated to memory.

roslof

@ChaosEffect said in Raspberry Pi 5 - official announcement:

Archiving libemu.a...
make: *** [makefile:1385: linux] Error 2
Removing additional swap
Could not successfully build lr-mame2020 - MAME emulator - MAME (current) port for libretro (/home/pi/RetroPie-Setup/tmp/build/lr-mame2020/mamearcade_libretro.so not found).
/home/pi/RetroPie-Setup```

Is there an "Error 1" in your log? If so, would you paste it along with a few lines before and after?

roslof

@ChaosEffect if doesn't look like a memory issue. I'm consistently having issues here:

Compiling src/frontend/mame/clifront.cpp...
In file included from ../../../../../3rdparty/sol2/sol/stack.hpp:30,
                 from ../../../../../3rdparty/sol2/sol/object.hpp:26,
                 from ../../../../../3rdparty/sol2/sol/proxy.hpp:26,
                 from ../../../../../3rdparty/sol2/sol/table_core.hpp:25,
                 from ../../../../../3rdparty/sol2/sol/table.hpp:25,
                 from ../../../../../3rdparty/sol2/sol/state_view.hpp:26,
                 from ../../../../../3rdparty/sol2/sol/state.hpp:25,
                 from ../../../../../3rdparty/sol2/sol.hpp:45,
                 from ../../../../../src/frontend/mame/luaengine.h:27,
                 from ../../../../../src/frontend/mame/clifront.cpp:19:
../../../../../3rdparty/sol2/sol/stack_push.hpp: In instantiation of ‘static int sol::stack::pusher<wchar_t [N]>::push(lua_State*, const wchar_t (&)[N], std::size_t) [with long unsigned int N = 2; lua_State = lua_State; std::size_t = long unsigned int]’:
../../../../../3rdparty/sol2/sol/stack_core.hpp:173:48:   required from ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const wchar_t (&)[2]; Args = {int}; lua_State = lua_State]’
../../../../../3rdparty/sol2/sol/stack_push.hpp:579:23:   required from here
../../../../../3rdparty/sol2/sol/stack_push.hpp:549:67: error: call of overloaded ‘push<const wchar_t*>(lua_State*&, const wchar_t [2], const wchar_t*)’ is ambiguous
  549 |                                 return stack::push<const wchar_t*>(L, str, str + sz);
      |                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
In file included from ../../../../../3rdparty/sol2/sol/stack.hpp:25:
../../../../../3rdparty/sol2/sol/stack_core.hpp:172:28: note: candidate: ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const wchar_t*; Args = {const wchar_t*}; lua_State = lua_State]’
  172 |                 inline int push(lua_State* L, T&& t, Args&&... args) {
      |                            ^~~~
../../../../../3rdparty/sol2/sol/stack_core.hpp:178:28: note: candidate: ‘int sol::stack::push(lua_State*, Arg&&, Args&& ...) [with T = const wchar_t*; Arg = const wchar_t (&)[2]; Args = {const wchar_t*}; <template-parameter-1-4> = void; lua_State = lua_State]’
  178 |                 inline int push(lua_State* L, Arg&& arg, Args&&... args) {
      |                            ^~~~
../../../../../3rdparty/sol2/sol/stack_push.hpp: In instantiation of ‘static int sol::stack::pusher<char16_t [N]>::push(lua_State*, const char16_t (&)[N], std::size_t) [with long unsigned int N = 2; lua_State = lua_State; std::size_t = long unsigned int]’:
../../../../../3rdparty/sol2/sol/stack_core.hpp:173:48:   required from ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const char16_t (&)[2]; Args = {int}; lua_State = lua_State]’
../../../../../3rdparty/sol2/sol/stack_push.hpp:587:23:   required from here
../../../../../3rdparty/sol2/sol/stack_push.hpp:560:68: error: call of overloaded ‘push<const char16_t*>(lua_State*&, const char16_t [2], const char16_t*)’ is ambiguous
  560 |                                 return stack::push<const char16_t*>(L, str, str + sz);
      |                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sol2/sol/stack_core.hpp:172:28: note: candidate: ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const char16_t*; Args = {const char16_t*}; lua_State = lua_State]’
  172 |                 inline int push(lua_State* L, T&& t, Args&&... args) {
      |                            ^~~~
../../../../../3rdparty/sol2/sol/stack_core.hpp:178:28: note: candidate: ‘int sol::stack::push(lua_State*, Arg&&, Args&& ...) [with T = const char16_t*; Arg = const char16_t (&)[2]; Args = {const char16_t*}; <template-parameter-1-4> = void; lua_State = lua_State]’
  178 |                 inline int push(lua_State* L, Arg&& arg, Args&&... args) {
      |                            ^~~~
../../../../../3rdparty/sol2/sol/stack_push.hpp: In instantiation of ‘static int sol::stack::pusher<char32_t [N]>::push(lua_State*, const char32_t (&)[N], std::size_t) [with long unsigned int N = 2; lua_State = lua_State; std::size_t = long unsigned int]’:
../../../../../3rdparty/sol2/sol/stack_core.hpp:173:48:   required from ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const char32_t (&)[2]; Args = {int}; lua_State = lua_State]’
../../../../../3rdparty/sol2/sol/stack_push.hpp:595:23:   required from here
../../../../../3rdparty/sol2/sol/stack_push.hpp:571:68: error: call of overloaded ‘push<const char32_t*>(lua_State*&, const char32_t [2], const char32_t*)’ is ambiguous
  571 |                                 return stack::push<const char32_t*>(L, str, str + sz);
      |                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sol2/sol/stack_core.hpp:172:28: note: candidate: ‘int sol::stack::push(lua_State*, T&&, Args&& ...) [with T = const char32_t*; Args = {const char32_t*}; lua_State = lua_State]’
  172 |                 inline int push(lua_State* L, T&& t, Args&&... args) {
      |                            ^~~~
../../../../../3rdparty/sol2/sol/stack_core.hpp:178:28: note: candidate: ‘int sol::stack::push(lua_State*, Arg&&, Args&& ...) [with T = const char32_t*; Arg = const char32_t (&)[2]; Args = {const char32_t*}; <template-parameter-1-4> = void; lua_State = lua_State]’
  178 |                 inline int push(lua_State* L, Arg&& arg, Args&&... args) {
      |                            ^~~~
make[2]: *** [frontend.make:1256: ../../../../libretro/obj/libretro/src/frontend/mame/clifront.o] Error 1
make[1]: *** [Makefile:88: frontend] Error 2

Not certain how to resolve this, but I'll try an older lr-mame.sh script from that era.

OBSERVATION: I'm realizing that this is pretty spammy for this topic and not important to most, so I'm going to end lr-mame 0.222 discussions here and create a new topic in the development category called Generating older lr-mame builds.

roslof

Pi 5 is better than I thought.

Giddy that Sega Model 3 (from Exarkuniv's unofficial RetroPie-Extra fork using supermodel-mechafatnick.sh) works great with "xorg/XINT" runs at 60FPS at 1024x768 on my Pi 5. Editing runcommand video mode (88-36) can have it full screen 4:3 on a modern 16:9 TV. Outstanding. I'm safely overclocking CPU to 2700, but still, I didn't suspect the Pi 5 could handle this one.

Darksavior

It looks like the "supreme" guys managed to get AetherSX2 working with RetroPie. Too bad they are shady and don't share their work. At least we know that it's possible.

Widge

@roslof
The Yavin level is pretty lightweight compared to the others. Does it maintain 60fps on the Hoth level in MFN's fork?
I've been using DirtBagXon's fork.
How can you even measure the framerate in Supermodel?
Also LA Machine Guns is a busy one and can't maintain the framerate on a higher resolution. How does that go on MFN's fork? The on screen clock gives that away.

retropieuser555

@Darksavior said in Raspberry Pi 5 - official announcement:

It looks like the "supreme" guys managed to get AetherSX2 working with RetroPie. Too bad they are shady and don't share their work. At least we know that it's possible.

Yeah it's been working on mine for a while. I bet he's just built it on Ubuntu rather than the Pi OS.

roslof

@Widge said in Raspberry Pi 5 - official announcement:

The Yavin level is pretty lightweight compared to the others. Does it maintain 60fps on the Hoth level in MFN's fork?

I just played all the way through and did note some showdown issues:

Most cut scenes are lagging, but are not invasive. Endor moon shield generator explosion is the most egregious
Hoth periodic showdown and minor poly render issues. Switches shooting ATATs seem most egregious
Endor Forest frame rate "hitches” (pops occur from time to time)
Minor slowdown in small bursts throughout, but not major problems.

Can ghetto-gauge accuracy by music sync. To your point, since Supermodel doesn't have a counter and renders frames more slowly, there's no accurate way to do this. Perception though, most of the game has no perceivable frame rate hits.

Will check out @DirtBagXon 's commits and see if there's anything interesting in his fork.

Cheers!

Widge

@roslof I released a YT video last month describing my experience of Supermodel performance on the Pi5. And a complete playthrough of SWT at a resolution only slightly higher than original. I was not overclocking and trying to play at HD-level res would lead to inconsistent performance.
I identified the package needed to allow it to run in Bookworm Lite which DirtBagXon then added to his installation script. I guess ~~MechaFatNick~~ RetroPie Extras has finally caught up.
DBX and MFN's repos aren't that dissimilar, so performance between them should be the same, but I think that DBX's is the only one of the two that has multimouse support allowing the use of two lightguns in games such as Lost World. I could be wrong though, but it looks like MFN hasn't made a commit for 2 years. Meanwhile DBX is constantly on top of improvements, updates and support.