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

RealNC

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

RealNC

I uploaded a debug build as well:

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

mitu

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

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.

RealNC

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

mitu

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

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.