RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login

    lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores)

    Scheduled Pinned Locked Moved Ideas and Development
    libretroretroarchdosboxlr-dosboxlr-dosbox-svn
    43 Posts 8 Posters 6.0k 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.
    • R
      RealNC @mitu
      last edited by

      @mitu
      In that case, I will look into adding ARM builds for dosbox-core. Right now it's only being built for Linux x86-64.

      If you build yourself, then you need to pass STATIC_LIBCXX=1 to make so that libstdc++ and libgcc_s are statically linked. This is already being done for the x86 buildbot builds so that the core runs on old Linux distros as well.

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

        @RealNC I'll give it a try.

        1 Reply Last reply Reply Quote 0
        • R
          RealNC
          last edited by RealNC

          I was able to set up a build using Ubuntu 16.04 ARM 32-bit ("armhf"). I have no idea if it runs though, so it would be helpful if anyone could test:

          https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip

          Munt, fluidsynth and bassmidi are all supported and built-in (except for bassmidi due to licensing) along with their dependencies (like vorbis, libsndfile, etc.) The only external library dependencies are:

          libasound.so.2
          libpthread.so.0
          libgobject-2.0.so.0
          libglib-2.0.so.0
          libm.so.6
          libc.so.6
          ld-linux-armhf.so.3

          which I believe should be already pre-installed on virtually all Linux systems out there.

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

            @RealNC said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

            https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip

            Seems to be ok on a PI4 (Raspbian Buster) system, I don't get any errors when starting.

            I get a crash though trying to load a simple .conf file, but since the .so doesn't have debugging symbols, kind of difficult to say where it crashes. Could be because I don't have any soundfonts or some assets are missing.

            EDIT: Compiling directly on a Raspbian Buster works, but even with STATIC_LIBCXX=1, there's still a runtime error about missing a new C++17 filesystems function. I think that's ok, Buster has only gcc 8.3.0, so it's missing the necessary requirements. Probably if compiled with a newer gcc/clang would work.

            R 1 Reply Last reply Reply Quote 0
            • R
              RealNC @mitu
              last edited by

              @mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

              Seems to be ok on a PI4 (Raspbian Buster) system, I don't get any errors when starting.

              I get a crash though trying to load a simple .conf file, but since the .so doesn't have debugging symbols, kind of difficult to say where it crashes. Could be because I don't have any soundfonts or some assets are missing.

              It doesn't rely on any assets or soundfonts. I'll put up a debug build as well.

              EDIT: Compiling directly on a Raspbian Buster works, but even with STATIC_LIBCXX=1, there's still a runtime error about missing a new C++17 filesystems function. I think that's ok, Buster has only gcc 8.3.0, so it's missing the necessary requirements. Probably if compiled with a newer gcc/clang would work.

              Ah, with GCC 8 you need to add -lstdc++fs to LDFLAGS. The handling of that is wonky though. You probably have to edit Makefile.libretro and add in line 366, at the end of the line that starts with LDFLAGS += `$(PKGCONFIG)

              1 Reply Last reply Reply Quote 0
              • R
                RealNC
                last edited by

                I uploaded a debug build as well:

                https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf-dbg.zip

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

                  @RealNC I think it might be targeting the wrong (ARM) dynrec.

                  757eff56-558f-40f3-8dae-5b68933878a2-image.png

                  R 1 Reply Last reply Reply Quote 0
                  • R
                    RealNC @mitu
                    last edited by RealNC

                    @mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

                    I think it might be targeting the wrong (ARM) dynrec.

                    It's the correct one for ARMv7. Does 32-bit stand-alone dosbox run fine when dynrec is enabled? (core = dynamic in the .conf file.) I think the rpi4 CPU is supposed to be backwards compatible with 32-bit ARMv7. So if stand-alone 32-bit dosbox with the same dynrec has the same issue, then this could be a bug in the dosbox dynrec.

                    I'll also put a 64-bit ARMv8 build up to see how that one behaves.

                    1 Reply Last reply Reply Quote 0
                    • R
                      RealNC
                      last edited by

                      Btw, if you disable the dynrec by setting the core's "System: CPU core" option to "normal", does it work then?

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

                        @RealNC Yes, the RPI4 (at least on Raspbian) should fall into the 32 bit ARMv7 category. Sadly 64 bit (ARMv8) would not work out-of-the-box since Raspbian has no 64 bit userspace support.

                        I tried the recommended settings (core and .conf) and it's still crashing - while the normal dosbox (upstream SVN) or dosbox-staging work fine.

                        RetroPie uses these build instructions when packaging upstream dosbox.

                        My testing .conf has just an autoexec section for starting Q1:

                        [autoexec]
                        mount c: /home/pi/roms/pc-data
                        c:
                        cd \quake1
                        quake -nocdaudio
                        exit
                        

                        I think I'll try again to build the core - modifying the Makefile - and see if I can get it running locally, it might be an issue with the automated build.

                        R 1 Reply Last reply Reply Quote 0
                        • R
                          RealNC @mitu
                          last edited by

                          @mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

                          I tried the recommended settings (core and .conf) and it's still crashing

                          Can you get a backtrace in this case? The old crash pointed to the dynrec, so with it disabled it should point somewhere else.

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

                            @RealNC Re-tested with core = dynamic and the crash is similar. Using the "System: CPU core" option to "normal" doesn't crash, but it's obviously slow.

                            1 Reply Last reply Reply Quote 0
                            • R
                              RealNC
                              last edited by

                              It's very difficult to debug this on my end, as I don't have any ARM devices. To check if this an issue with the toolchain, I built the regular dosbox-svn core with it:

                              http://83.212.109.87/~realnc/tmp/dosbox_svn_libretro.zip

                              Does it also crash?

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

                                @RealNC said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

                                Does it also crash?

                                No, it doesn't crash. I don't think the toolchain is at fault. Since the last update I managed to compile it natively (modifying the LDFLAGS) and I get a crash also.

                                I don't know if the core you linked (svn) is synchronized to the latest Dosbox SVN tag (I think dosbox-core is), but I'll install from source the latest Dosbox and see if maybe there's a recent regression.

                                R 1 Reply Last reply Reply Quote 0
                                • R
                                  RealNC @mitu
                                  last edited by

                                  @mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

                                  I don't know if the core you linked (svn) is synchronized to the latest Dosbox SVN tag

                                  No, it is kept in sync with SVN trunk. So that's not it.

                                  I found something that might be the cause of it. I'll upload a new test build shortly.

                                  1 Reply Last reply Reply Quote 0
                                  • R
                                    RealNC
                                    last edited by

                                    If you want to test locally if this is indeed the issue, edit Makefile.libretro and change this line near the beginning of the file:

                                    CXXFLAGS += -std=c++17 -Dregister=
                                    

                                    to:

                                    CXXFLAGS += -std=c++17
                                    

                                    Then do:

                                    make <your other options here> targetclean`
                                    

                                    and build again.

                                    (targetclean only cleans core files, not deps, so that you don't have to rebuild deps again.)

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

                                      @RealNC I'll give it a shot, thank you.

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

                                        Well, it's not crashing anymore - this may be the winning ticket. If you have an automated build, I can give it a test.

                                        1 Reply Last reply Reply Quote 1
                                        • R
                                          RealNC
                                          last edited by RealNC

                                          Well, that will teach me to assume that the register keyword is useless. I disabled it to get rid of the GCC warning about register being invalid in C++ now. Turns out that even if you specify an actual register to be used for a variable using __asm("register_name"), you still need the register keyword...

                                          Oops.

                                          Thanks for the help! I'll add the ARM build to the libretro buildbot and upload fixed builds soon.

                                          1 Reply Last reply Reply Quote 0
                                          • R
                                            RealNC
                                            last edited by

                                            (I hope I'm not stealing too much of your time with all this :-P)

                                            Automated build is now up:

                                            https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip

                                            Now, the above is built with GCC on actual Ubuntu ARM. However, building it this way is extremely slow (takes like an hour to build) because I have to emulate ARM in QEMU inside the Azure VM github provides. So I'd like to cross-compile from Intel to ARM instead using Clang. And that build is here:

                                            http://83.212.109.87/~realnc/tmp/linux-armhf-clang.zip

                                            Can you check if the Clang build works just as well as the GCC one? (Assuming the GCC automated build works, that is.)

                                            mituM 1 Reply Last reply Reply Quote 0
                                            • 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.