Raspberry Pi 5 - official announcement

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.

S_Dev88

@Darksavior I love to see the negative, Sadly they are far from shady, I’ve helped them out on a few projects and they share everything. I’m guessing you haven’t read there credits or check there public GitHub’s before making silly comments.

Like they say if you got nothing nice to say keep it to your self, We have enough negativity in this world.

S_Dev88

@retropieuser555 This is working on raspberry OS. I installed RetroPie with there new Branch and everything works for me including PS2

There pi 5 branch they are using for testing.
https://github.com/supremeretrogaming this is not there main GitHub but one that was made focused on the pi 5 with small tweaks.

mitu

@S_Dev88 said in Raspberry Pi 5 - official announcement:

@retropieuser555 This is working on raspberry OS. I installed RetroPie with there new Branch and everything works for me including PS2

Where is the branch ? The repo at https://github.com/supremeretrogaming/RetroPie-Setup doesn't have a 'pi5' branch, as you mentioned. Is this in another repo ?

S_Dev88

@mitu I may be wrong on the branch that was used, The link I provided just seem to work out of the box for me. I was told they simply took community feedback and made a custom branch for testing for everyone.

These are the branches supreme is sharing for testing:

https://github.com/SupremeRetroGaming/RetroPie-Setup

https://github.com/RapidEdwin08/RetroPie-Setup

mitu

@S_Dev88 said in Raspberry Pi 5 - official announcement:

These are the branches supreme is sharing for testing:

There are no branches in either of the repos you linked, they're just forks or RetroPie's main repo. One of them has merged some of the pending PRs from the RetroPie's repo, but I don't see any AetherSX additions in either of them.

S_Dev88

@mitu Sorry maybe it’s the repo, my English is not the best. When I install RetroPie using there repo the PS2 emulator just works without errors.

All I did was a basic install with there repo and then installed the PS2 Emulator it works! But when I use the official repo the PS2 Emulator doesn’t work. There basic install is adding requirements that the PS2 emulator needs to run correctly it seems. I could ask them as they been pretty nice to me.

Darksavior

This image from that RapidEdwin08 guy says it includes AetherSX2 but I haven't tried it to see if it runs on the desktop or not https://retropie.org.uk/forum/topic/34904/doom-the-way-pi-did-doom-ready-base-images-for-raspberry-pi-0-5-gpi

roslof

@Widge said in Raspberry Pi 5 - official announcement:

@roslof I released a YT video last month describing my experience of Supermodel performance on the Pi5.

Love the video (and gave it a Thumbs Up!)

Tough to tell, since the YouTube video runs at 30fps, but sincerely at 1024x768, game is overall smooth and the graphics much better (obviously). Again, I'm overclocked at 2700 on the CPU which does made a bit of a difference, I pushed it to 2800 and don't see any noticeable improvement.

The same hitches I've seen are seen in your video (where the video freezes for a brief moment) like just before Darth Vader's tie appears for the first time over the Death Star run.

But I can't tell where other slowdown might be from the video. I'll try @DirtBagXon 's version shortly.

windg

I don't understand why the people that can made retropie better they don't contribute, instead they released their own images.