Raspberry Pi 5 - official announcement
-
My Pi 5 arrived last week and have been using it for 3-4 days. I don't want to use the time to compile the code it just too time consuming. I have tested another distribution, and so far so good. Everything runs as it should youtube reviewers are spot on.
I also moved to a Samsung fit 256Gb and its very fast loading compared to the sd card.
I hope we have an official release soon :) can't wait to test it.
-
Okay some more notes:-
I attempted to build Retropie on top of Ubuntu 23.10 and made various edits, installing the fan control script, setting it so ubuntu boots into the CLI and then into emulationstation rather than to the desktop etc.
The reason I did this is because AetherSX2 right now only works on Ubuntu, not Raspberry Pi OS. On the plus side PS2 now works from emulationstation booting AetherSX2 straight into a rom
GTA 3 - No issues, works fine
Dragon Quest 5 - No issues, works fine
Kingdom Hearts 1 Final Mix - No Issues, works fine
Lego Star Wars - No issues, works fineDragon Quest VII - very slow framerate, not playable for now
Harry Potter Chamber of Secrets - turning software rendering on it works a little better but framerate definitely isn't quite there as there's a bit of slowdownand for standalone Dolphin (which will work on bookworm or Ubuntu)
Pikmin - No issues, works fine
Chibi Robo - No issues, works fine
Eternal Darkness - No issues, works fine
Tales of Symphonia - No issues, works fine
Baten Kaitos - Only played a little but seems fine
Warioware - No issues, works fineLegend of Zelda - Wind Waker - Works great, some minor stutters when the shaders are loaded at points and in combat, nothing too significant. Edit :- Played further in, the forsaken fortress has really slow FPS, basically any area with that fog effect the game uses seems slow. I imagine by the time of the Fire dungeon it'll be way too slow to play
Paper Mario TTD - crashes at the boat intro, tried various settings, fixes and couldn't get it to work
Luigi's Mansion - Gameplay is fine, but the cutscenes are a complete slideshow. Once you get past those it's ok
Star Fox Adventures - Framerate is okay-ish but audio is a bit scrambled and slow
Simpsons Hit & Run - Framerate is too slow
Smash Bros Melee - At first it seems alright but certain levels the effects slow the framerate too much, the F Zero levels for example. Also with 4 players on screen rather than 2 it takes a bit of a dive.Mario Kart Wii - Framerate is fine but audio is a bit scrambled and slow
Wii Sports - Little too slow framerate that makes it not quite playable. It's not far off though -
I didn't think it could run ps2 games, great news! I hope it will be possible to use this emulator with PI OS, but the developer is not active on this project due to the bad behavior of some people.
-
@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. -
@mitu is there any news about when retropie will be released for pi 5?
-
@90sgamer nope, just what you see here.
its still going to be a good few months -
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.
-
@skankieflank The addition of Vulkan is on his way, see: https://github.com/RetroPie/RetroPie-Setup/pull/3785 .
-
@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.
-
I'm just hoping it can play 3DO and Amiga CD/CD-TV Games without issue.
-
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.
-
@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.
-
@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:
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.222And 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).
-
@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```
-
@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.
-
@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?
-
@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.
-
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.
-
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.
-
@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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.