RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    lr-pcsx-rearmed won't run any games

    Scheduled Pinned Locked Moved Help and Support
    lr-pcsx-rearmedresident evil 3not working
    68 Posts 11 Posters 11.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • mituM
      mitu Global Moderator @zapp7
      last edited by

      Then your installation is incomplete.

      1 Reply Last reply Reply Quote 0
      • Z
        zapp7
        last edited by

        Oh okay. Is there a resource that you recommend to install RetroPie completely? I was under the impression that the setup script would take care of that.

        1 Reply Last reply Reply Quote 0
        • Z
          zapp7
          last edited by

          I used the update script and it already said that lr-pcsx-rearmed was installed. I chose "Update from Source" anyway and now it's working!

          Thank you for your help!

          1 Reply Last reply Reply Quote 0
          • H
            hhromic
            last edited by hhromic

            @mitu @BuZz due to the recent lr-pcsx-rearmed buildfix that now uses the libretro makefile directly, the generated shared file is now called pcsx_rearmed_libretro.so, which the scriptmodule configures in emulators.cfg. The old name was just libretro.so.

            I think the problem here is that the curent binaries in the RetroPie archive probably are the old ones installing the libretro.so and the new scriptmodule is configuring for pcsx_rearmed_libretro.so. This is why installing from source works. The solution should be simply to update the binaries on the archive server.

            EDIT: apologies as I forgot to remind in the PR to update the binaries.

            BuZzB 1 Reply Last reply Reply Quote 1
            • BuZzB
              BuZz administrators @hhromic
              last edited by

              @hhromic I will sort. Sorry, just been a bit busy. Rebuilding now.

              To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

              1 Reply Last reply Reply Quote 1
              • BuZzB
                BuZz administrators
                last edited by BuZz

                Build is currently failing for RPI1. Looks like neon code is trying to be built. I won't be able to debug the RPI1 build till later.

                RPI2 bins are updated.

                To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                H 1 Reply Last reply Reply Quote 0
                • H
                  hhromic @BuZz
                  last edited by

                  @BuZz umm I tested that build too, will take another closer look and report back. Hopefully I find the culprit before you need to spend time on it.

                  BuZzB 1 Reply Last reply Reply Quote 0
                  • BuZzB
                    BuZz administrators @hhromic
                    last edited by BuZz

                    @hhromic possibly due to logic somewhere that would fail then if built on my chroot. Eg. Something that checks for RPI1 hardware info. I have a feeling there was something before we had as a workaround for a similar issue.

                    Actually that's for the standalone core. Maybe it's the same issue though.

                    To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                    H 1 Reply Last reply Reply Quote 1
                    • josephxxJ
                      josephxx
                      last edited by

                      Hello world (first post by a new owner of a RPI 3B+):

                      To anyone who (like me) ended up here having the same problem/symptoms, the reason in my case was that I allowed my 4.4 Retropie to update everything.

                      Stock 4.4 image played PSX roms perfectly. When I read that a recent update to EmulationStation allowed the internal scraper to start working again, I did a full update. The scraper indeed worked, but lr-pcsx-rearmed never launched another ROM - black screen, starting, and back to the game list again.

                      What worked was updating specifically the EmulationStation package and nothing else.

                      Pi 3B+, official PSU, Retropie 4.4 official image, Xbox360 wired controller.

                      mituM 1 Reply Last reply Reply Quote 1
                      • mituM
                        mitu Global Moderator @josephxx
                        last edited by

                        @josephxx You can update from source the emulator and it should work.

                        josephxxJ 1 Reply Last reply Reply Quote 1
                        • H
                          hhromic @BuZz
                          last edited by

                          @BuZz said in lr-pcsx-rearmed won't run any games:

                          @hhromic possibly due to logic somewhere that would fail then if built on my chroot. Eg. Something that checks for RPI1 hardware info. I have a feeling there was something before we had as a workaround for a similar issue.

                          Actually that's for the standalone core. Maybe it's the same issue though.

                          Thanks for the info, will investigate that as I was having the same feeling. Libretro makefiles can be a bit hacky sometimes. Yes I think I saw the workaround you mention in the standalone emulator, however I will check passing variables to the makefile, e.g. HAVE_NEON=0, if necessary. I will be able to report shortly.

                          1 Reply Last reply Reply Quote 0
                          • josephxxJ
                            josephxx @mitu
                            last edited by

                            @mitu said in lr-pcsx-rearmed won't run any games:

                            @josephxx You can update from source the emulator and it should work.

                            Thanks for letting me know. I am new to all this and the Linux mindset (and it's been 20 years since I took some Linux at uni).

                            Pi 3B+, official PSU, Retropie 4.4 official image, Xbox360 wired controller.

                            1 Reply Last reply Reply Quote 0
                            • H
                              hhromic
                              last edited by

                              @buzz the build for RPI1 is now failing here for me as well doing the same i did before, so something changed upstream since I made the buildfix.

                              I will investigate what they changed and send a patch upstream as I believe our way to build is correct and we shouldn't use workarounds. They are rather quick to merge PRs for this core anyway. Will report back here anyway to keep you updated guys.

                              1 Reply Last reply Reply Quote 0
                              • H
                                hhromic
                                last edited by hhromic

                                Okay found the problem.

                                It is upstream but nothing they did recently actually. As you guessed @BuZz, when HAVE_NEON is not set by any of the checks the makefile tries to autodetect it using a compiler test. The problem is that when platform=armvalone, the makefile starts with HAVE_NEON unset, however for armv if neon is not set, then it will try to autodetect it using the compiler of the host in the chroot, leaving it enabled. The solution is rather simply to not leave the variable unset in the armv check block, i.e. set HAVE_NEON=0 explicitly in armv until NEON is requested explicitly. This way there is no autodetection, like this:

                                index 8899ed7..c6eb695 100644
                                --- a/Makefile.libretro
                                +++ b/Makefile.libretro
                                @@ -286,6 +286,7 @@ else ifneq (,$(findstring armv,$(platform)))
                                        TARGET := $(TARGET_NAME)_libretro.so
                                        fpic := -fPIC
                                        DRC_CACHE_BASE = 0
                                +       HAVE_NEON = 0
                                        ifneq (,$(findstring cortexa8,$(platform)))
                                                CFLAGS += -marm -mcpu=cortex-a8
                                                ASFLAGS += -mcpu=cortex-a8
                                

                                If NEON is present in platform=armvneon then HAVE_NEON=1 will be set correctly.

                                I will send a patch upstream now. An alternative is to pass HAVE_NEON accordingly from the scriptmodule but that will make the logic unnecessarily more complicated when it can be fixed upstream very easily.

                                I don't know exactly why my initial test worked, perhaps the compiler check did work at some point. Will let you know when the patch is merged upstream so you can rebuild.

                                1 Reply Last reply Reply Quote 0
                                • H
                                  hhromic
                                  last edited by

                                  Okay the PR is now sent upstream: https://github.com/libretro/pcsx_rearmed/pull/253
                                  Once merged the build for RPI1 should be working fine without altering the scriptmodule.

                                  1 Reply Last reply Reply Quote 0
                                  • J
                                    jdriscol
                                    last edited by

                                    I apologize in advance for my ignorance, but I also started experiencing problems with the lr-pcsx-rearmed emulator after doing an update from binary. I had several ROMs working perfectly fine, but after this update I get booted back to emulationstation. It sounds like my issue matches what's going on in this thread, so is there a fix yet? How exactly do I go about implementing? Thanks!

                                    quicksilverQ 1 Reply Last reply Reply Quote 0
                                    • quicksilverQ
                                      quicksilver @jdriscol
                                      last edited by

                                      @jdriscol which model pi are you using?

                                      J 1 Reply Last reply Reply Quote 0
                                      • J
                                        jdriscol @quicksilver
                                        last edited by

                                        @quicksilver 3B+

                                        mituM quicksilverQ 2 Replies Last reply Reply Quote 0
                                        • mituM
                                          mitu Global Moderator @jdriscol
                                          last edited by

                                          @jdriscol I just updated and don't have any issues - did you update your RetroPie script before installing the binary update ?

                                          1 Reply Last reply Reply Quote 0
                                          • quicksilverQ
                                            quicksilver @jdriscol
                                            last edited by

                                            @jdriscol Update retropie setup-script first then update from binary. The binary was already updated I believe.

                                            J 1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post

                                            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.