lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores)
-
@quicksilver You can try it if you want, just create the script
/home/pi/RetroPie-Setup/scriptmodules/libretrocores/lr-dosbox-svn.sh
with the following:#!/usr/bin/env bash # This file is part of The RetroPie Project # # The RetroPie Project is the legal property of its developers, whose names are # too numerous to list here. Please refer to the COPYRIGHT.md file distributed with this source. # # See the LICENSE.md file at the top-level directory of this distribution and # at https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/master/LICENSE.md # rp_module_id="lr-dosbox-svn" rp_module_desc="DOS emulator" rp_module_help="ROM Extensions: .bat .com .exe .sh .conf\n\nCopy your DOS games to $ROMDIR/pc" rp_module_licence="GPL2 https://raw.githubusercontent.com/libretro/dosbox-svn/libretro/COPYING" rp_module_section="exp" rp_module_flags="" function sources_lr-dosbox-svn() { gitPullOrClone "$md_build" https://github.com/libretro/dosbox-svn.git libretro } function build_lr-dosbox-svn() { local params=() if isPlatform "arm"; then if isPlatform "armv6"; then params+="WITH_DYNAREC=oldarm" else params+="WITH_DYNAREC=arm" fi fi cd libretro make clean make -j4 "${params[@]}" md_ret_require="$md_build/libretro/dosbox_svn_libretro.so" } function install_lr-dosbox-svn() { md_ret_files=( 'COPYING' 'libretro/dosbox_svn_libretro.so' 'README' ) } function configure_lr-dosbox-svn() { mkRomDir "pc" ensureSystemretroconfig "pc" addEmulator 0 "$md_id" "pc" "$md_inst/dosbox_svn_libretro.so" addSystem "pc" }
Then start the RetroPie setup script from ES, go to experimental packages and install
lr-dosbox-svn
package from source. That will install thelr-dosbox-svn
core and add it to the RetroPie system as usual. There's not much else to it. -
@muldjord how is the performance on the pi 4? Lr-dosbox was too slow on my pi 3.
-
@quicksilver Not too good unfortunately. I tried using it with the config that comes with the non-libretro package and it improves it quite a bit. But it's not good even with that. With that said, I have the same issues with the non-libretro package on Pi4. I'm gonna look into why this is and see if I can figure out a way to get it to run better.
EDIT: No luck so far. Maybe this is down to sdl2 still not supporting the videocore. Not sure, I'm not knowledgeable enough to answer that currently. I've been digging up information on the videocore 6 support in the mesa project though. And of course I can't find the article I read it on some days ago, but supposedly the latest release of Raspbian now has the version of mesa that contains it included in the kernel it uses (take this with a grain of salt. The article could have been wrong, and I certainly could have misread it as well). That doesn't mean all software will use it though. For instance, SDL2 will probably need some flags to use it I believe. Again, I'm kind of guessing here, my knowledge is limited on the subject.
-
I wouldn't count out DosBox ECE (https://dosboxece.yesterplay.net/en/). There's a lot of interest on these forums to get Windows 9x running, and this fork seems better at doing it.
-
@muldjord said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):
Small update: I've been fiddling with the
lr-dosbox-core
core today (as mentioned by @mitu). It has some compilation issues which seem to stem from a problem in their repository. It's related to some of the fluidsynth stuff included. But I did manage to get it to compile eventually. Can't get it to run though... So from a pure ease-of-install perspectivelr-dosbox-core
is subpar. It doesn't even have built instructions or dependencies listed (it requireslibsndfile1-dev
) in the repository.I've added some more information about dependencies:
https://github.com/realnc/dosbox-core
Most deps can now be bundled. They can be built together with the core and linked against statically. glib and alsa-lib are not, but I think these are available (and even installed by default) on virtually every Linux system.
-
@RealNC Thank you for the update. I seem to be able to compile it now, but had some weird issues with configuring the fluidsynth lib. Anyways, I'll update you all on this when I have tested it.
-
Sorry for the silly question, but I'm not familiar at all with retropie (or the rpi in general.) Don't the libretro buildbot ARM builds of dosbox-svn run as-is on retropi? I mean these:
-
@RealNC They do work (I know I tested the
armv7-neon-hf
build fordosbox-svn
). If the regulardosbox-libretro
repository is no longer updated, I guess we can switch todosbox-svn
instead ?I think the new
dosbox-core
is the one that's not working - due to the C++17 requirements. It builds, but I think I got a runtime error when loading the core. I can repeat the test to get the actual error. -
@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. -
@RealNC I'll give it a try.
-
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.3which I believe should be already pre-installed on virtually all Linux systems out there.
-
@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 onlygcc
8.3.0, so it's missing the necessary requirements. Probably if compiled with a newer gcc/clang would work. -
@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 onlygcc
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 editMakefile.libretro
and add in line 366, at the end of the line that starts withLDFLAGS += `$(PKGCONFIG)
-
I uploaded a debug build as well:
https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf-dbg.zip
-
@RealNC I think it might be targeting the wrong (ARM) dynrec.
-
@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.
-
Btw, if you disable the dynrec by setting the core's "System: CPU core" option to "normal", does it work then?
-
@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) ordosbox-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.
-
@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.
-
@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.
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.