lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores)
-
I see there are 2 (update recently) Libretro cores for Dosbox, besides the older core:
- https://github.com/libretro/dosbox-svn (the one mentioned here)
- https://github.com/libretro/dosbox-core
Which one will win ?
-
@mitu I hadn't even noticed that one. Interesting. I will test both and see which one works best at the moment.
-
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.EDIT: Little more progress with the
lr-dosbox-svn
core. My segmentation fault when loading a.conf
file stemmed from amount c ./some/path
command. Apparentlylr-dosbox-svn
does not like.
's in the path even though the dir relative to working dir should be correct (even if it is, it should not crash). It has issues with joystick mapping though. I tried playing Jazz Jackrabbit, and it would not recognize the up-left, up and up-right directions when calibrating the joystick inside the game options. -
@muldjord thanks for the progress reports. Since vanilla dosbox isnt up and running quite yet on the pi4 I thought I would try dosbox-sdl2 but it apparently doesn't like .ogg/.mp3 files so some of my CD based games will not work properly. I'll try out lr-dosbox if it looks like youre making some headway.
-
@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.
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.