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

RealNC

@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.

mitu

@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.

RealNC

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?

mitu

@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.

RealNC

@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.

RealNC

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.)

mitu

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

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.

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.

RealNC

(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.)

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

This works, no crash.

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

This one doesn't work, it crashes - but strangely not if I run in through gdb.

RealNC

The 1 hour GCC build it will have to be then.

Thanks!

jul059

Not sure where to post this, but dosbox-staging might be worth considering as a core. The pixel-perfect scaling mode looks interesting.

RealNC

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

Not sure where to post this, but dosbox-staging might be worth considering as a core. The pixel-perfect scaling mode looks interesting.

Pixel-perfect scaling is done by the frontend in libretro cores. Usually called "integer scaling" (RetroArch calls it that, for example.) If you enable that in the frontend, and also turn off the "Video: Aspect ratio correction" core option, you get 100% pixel-perfect scaling. With aspect correction enabled, you get what is sometimes called "near-perfect" scaling.

nikitau

Hey, kinda new to this forum so idk if necrobumping is frowned upon, but wanted to share my recent experience with this. I actually got dosbox-core to work quite fine on a RPi4 without any modification of the binary build from github. The setup script is pretty basic and doesn't do much besides downloading the binary and installing it:

#!/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-core"
rp_module_desc="DOS emulator LIBRETRO"
rp_module_help="ROM Extensions: .bat .com .exe .sh\n\nCopy your DOS games to $ROMDIR/pc"
rp_module_licence="GPL2 https://raw.githubusercontent.com/libretro/dosbox-libretro/master/COPYING"
rp_module_section="exp"
rp_module_flags=""

function sources_lr-dosbox-core() {
    wget "https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip"
}

function build_lr-dosbox-core() {
    unzip linux-armhf.zip
    md_ret_require="$md_build/dosbox_core_libretro.so"
}

function install_lr-dosbox-core() {
    md_ret_files=(
        'dosbox_core_libretro.so'
    )
}

function configure_lr-dosbox-core() {
    mkRomDir "pc"
    ensureSystemretroconfig "pc"

    addEmulator 0 "$md_id" "pc" "$md_inst/dosbox_core_libretro.so"
    addSystem "pc"
}

I only tested it on Prehistorik 2 and Wolfenstein 3D, but they seem to get decent performance. Control mapping and sound seem to work just fine, but I should test performance against vanilla dosbox and see if it holds for more demanding titles (eg. Blood or Duke Nukem).

Sidenote: I did have a lot of the dependencies installed beforehand and the binary does come bundled with some of them so idk at this moment if there is some prerequisite that should be installed by the script. Maybe fluidsynt and/or bassmidi(?)

RealNC

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

Sidenote: I did have a lot of the dependencies installed beforehand and the binary does come bundled with some of them so idk at this moment if there is some prerequisite that should be installed by the script. Maybe fluidsynt and/or bassmidi(?)

It includes everything it needs, except for BASS and BASSMIDI (due to licensing reasons; these libraries are not GPL-compatible.)

In general, to see which libraries an executable or library needs, you use readelf -d. In this case:

readelf -d dosbox_core_libretro.so | grep NEEDED

BASSMIDI does not show up here because it's optional and thus not linked against explicitly but instead loaded by the core manually if it exists. If not, the core runs just fine, except without BASSMIDI support.

nikitau

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

readelf -d dosbox_core_libretro.so | grep NEEDED

Nice, that is actually good info. Apart from asound and libc which are preinstalled, there isn't anything else. Also performance-wise, with some cycle-tuning, even duke nukem runs fine.

Great work, man! Given the convenience of retraoarch, I'll definitely use this instead of vanilla dosbox from now on.

I might clean the script up in the next days and put it on github in case anybody else wants to run it on RPi (unfortunately I only have armv7/v8 devices so I won't be able to test for older versions of the Pi)

RealNC

@nikitau
If you want to enable BASSMIDI support, the ARM versions are posted here:

https://www.un4seen.com/forum/?topic=13804.msg95617

You need the "hardhf" builds of libbass.so and libbassmidi.so. They need to be placed in the libretro system directory, which is where the core looks for them.

RealNC

I made an ARM64 build of dosbox-core:

https://github.com/realnc/dosbox-core/releases/tag/latest_build_linux_arm

I don't actually know if it runs, since I don't have an ARM machine. In theory, it should run fine on RPi 4 since it's built on arm64v8 Ubuntu 16.04.