realnc / dosbox-core Goto Github PK

Hi again,

I found out that gamepad/joystick input shows some problems with this core.
I am using a wired XB360 gamepad here, and this behaviour only seems to affect dosbox-core.

Keeping one joystick button pressed, while rapidly move left or right using the gamepad, causes the right direction to stop responding eventually. That affects gameplay on games such as SuperFrog or Jazz JackRabbit, where fast jumping+directional action is needed.

For example, in SuperFrog, look for an area without enemies and keep the jump button pressed while moving left and right very fast: you will eventually see one of the directions does not respond.

I have tried playing with the "Force 2 axis/2 button" and "Enable joystick timed intervals" options, but they don't make any difference.

Thanks!

Hello. I have set up Falcosoft Midiplayer to load the official version of the Roland Sound Canvas VA. It inputs from port 14:0 ("Midi Through Port-0").

In the stand-alone version of Dosbox, I just have modified the dosbox.conf as:
mpu401 = intelligent
mididevice = alsa
midiconfig = 14:0

and it works perfectly.

In Retroarch I have tried to set up manually the dosbox.conf file but it doesn't work.
If i set the "Sound: midi driver" to ALSA, in the core options, "Sound: ALSA midi port" returns me "(no midi ports found)".

Is there a way to solve this problem ? Am I doing anything wrong ?

My OS is CentOS 7, I am using the latest stable version of Retroarch (1.9.0) and the dosbox core.
Thanks in advance!

This is often need for, for example, playing some windows 95 games that can go over 1 gb (or whatever the limit was in dosbox upstream).

Each of these is relatively rare, but it adds up:
Dosbox insists on internally doubling pre-VGA 640x200 modes vertically to 400. This causes them to be detected as interlaced when using shaders in RA, which is of course inaccurate.
640x350 EGA mode aspect correction doesn't work correctly at all, the core turns this into some sort of widescreen mode. Trivial fix with the RA scaling settings for the rare cases where it's necessary, but I thought it's worth mentioning anyway.
Since I'm at it, could the text for the Aspect correction option in RA be slightly modified? It references non-square VGA resolutions, but the VGA reference seems unnecessary.
There are also a few games which will look more correct with Aspect correction off, some European games which where probably developed with the Amiga as lead platform. For that reason, I suggest just deleting the latter part of the last sentence ("but this will result in a squashed or stretched image).

This might already be done and if that is the case, leave a message and close the issue please.

If you start upstream dosbox with dosbox -conf -userconf GAME.conf you'll have a merge of the default dosbox.conf and GAME.conf, with GAME.conf overriding any duplicates. This is handy to have minimal game confs that you can easily change 'master' settings, a bit like the retroarch config override.

Now, i don't know how this core handles config, but i wouldn't appreciate to have to do per game configurations to replicate the same effect if the core already can load existing dosbox.confs. Only instead of using 'dosbox.conf' like the original dosbox, maybe the retroarch core options GUI should butt in.

if there is a 'actual' dosbox.conf (say in the retroarch system/bios dir):
//system/dosbox.conf -merge/overridenby-> 'core options' -merge/overridenby-> 'game options' -merge/overridenby-> start game conf file

if there isn't a 'upper' conf file (a viable idea to make the core more like the others):
'core options' -merge/overridenby-> 'game options' -merge/overridenby-> start game conf file

I want to clarify that if you feel confident that the GUI is 'good enough' to change most settings, a conf file in the system dir looks unnecessary to me, users hate editing config files. The main 'weird' setting ([autoexec] section) is/should always overridden by the game conf so the conf file doesn't appear critical to anything if the GUI/core options are good enough.

Imagine that you're starting a .conf file from a dvd (or more to the point, from a mounted read only lz4 filesystem) - it should be possible to check that directory is read only and do something about it by assuming a conf file is always at the top of the game 'dirs' (warning, this is not always true for badly made installs, though not GoG installs because dosbox doesn't have support for platform independent host directory separators in conf files).

edit: this is probably going to happen in upstream in the 'next' release, but will probably have to be adapted to libretro at least, and may not occur automatically which is the part that would be handy imo. It may also happen for zipped games.

I already have something that does this, but it requires a fixed source filesystem (i didn't bother to handle multiple possible filesystem mounts) and doesn't treat individual games as 'individual'. I suggest to use as 'filesystem cache id' the name of the parent dir of the conf file (or exec if not) as the 'id' of the game, possibly postfixed with a hash of the conf or executable (maybe not that last, because some executables self modify to 'save' for instance). Some games are weird and place their actual .exe files in subdirs, but i'm assuming that in those cases there will be a bat or conf file above you actually want to use anyway.

Sorry for opening so many issues, @realnc , I promise this one will be the last for now.

You can easily see the problem in Jazz Jackrabbit, which changes emulated DOS videomode frequently: go from main menu (tittle screen) to game, and back to main menu, back to game... You will see audio breaks and doesn't come back anymore.

I am using 1000 cycles here, but I have seen the same effect with other numbers of dosbox cycles. According to TOP, CPU usage is ~25%.

Sound dropouts are expected when changing the DOS videomode, but sound not coming back seems like an specific dosbox-core bug (I could be wrong of course).

Using EXTERNAL framerate timing.

Standalone DOSBox supports using CUE files that list compressed audio for CD tracks. Is this something that can be added to DOSBox Core?

https://www.dosbox.com/wiki/Cuesheet#Compressed_audio_tracks

Games like Carmageddon have massive graphical issues on the 64 bit version of dosbox, is it possible to have a 32bit build also for compatibility?

i have running dosbox-core since over 1 year on retroarch. but since day one, i always have the same problem. when i launch retroarch and start a dos game, it don't matter which one, the game is always starting without a problem. but when a dos game is running, or when i quit the runnign dos game, and start another dos game, retroarch always crashes. i have 17 cores running on retroarch, and this core is the only one, with that behavior. is this known? if yes, how can i fix it?

Is this on the roadmap for this libretro core? I have no idea whatsoever how hard this would be to implement, but if this was implemented & working in the long run I personally would no longer need the old Windows releases of DOSBox with glide support installed on my PC any more.

If this however was implemented, it would be beneficial if there somehow could be an option to enable higher resolutions than glide originally enabled while running a game in 3dfx mode (I think Carmageddon 1 went from 320x200 to maybe 640x400 in 3dfx mode; on modern displays it could be beneficial to get the resolution as high as possible).

Currently multiple discs have to be added one at a time manually - the first disc listed in the autoexec is loaded but it's not added to the swapper and the remaining discs are ignored. The way this is accomplished in standalone DOSBox is via:

mount/imgmount [drive name] "path\to\first\disc" "path\to\second\disc" -t cdrom [adding on as many discs in sequence as needed]

You could follow this same behavior and/or potentially integrate .m3us so that you could do something like imgmount [drive name] "path\to\m3u" -t cdrom

It should also be mentioned that the way the swapping itself works at the moment is not ideal - it basically treats it as if you've completely removed the disc drive and replaced it with another that has the new disc, rather than simply changing discs - this will generally work with DOS applications but wreaks havoc once you get into Windows 3.1 stuff.

Hi, I noticed that this core is unavailable for Android, as the only version available is the DOSBox-SVN which is apparently dead. However, this one has some problems, and these should be fixed in this version of the core. Are there plans to eventually make an Android core, or is it not possible?

It's great having Joystick support for racing/flight games or even games like Descent but only being able to map 2 buttons is a major limitation. It would be great to have an option to map controls to both a joystick and keyboard device. This would save messing around with scripts for Joy2Key/Xpadder/Anti-Micro etc.

Hello there.
I have been looking around dosbox-svn trying to run Jill of the jungle game which runs in 70fps. The game there does seem to have the same predicament as this core. If vsync is enabled and frame timing mode is set up (by default) as internal(fixed 60fps), so then you get some skipped frames in-game while running with the character around any level. If set to internal (variable) or external the game will run in proper fps
but with massive sound crackling nor slowdowns for music.

The game runs properly is disabling vsync and setting up internal(variable) as frame timing mode but this last option is not available in dosbox-core, could it be added up to run games in such cases please ?

It only has available internal(fixed 60fps) or external, neither of them work properly as the game is made.

Thanks for any help or reply.

Hi there,

I have noticed that SuperFrog's protection screen is black if "External" framerate is selected.
I have tried all available video card modes, and it's the same with all them.

Bug is very easy to replicate: just load SuperFrog and you will see it.

Hello,
The music is not playing on all levels on super star dust 96, when using ogg format. The title screen doesn't play but the level select and first level play ok, then it stops playing again. I had edited the cue to point to all the oggs correctly

bin/cue and wav plays all the music tracks perfectly. I've also tried VBR and CBR oggs both at stereo 128kb and both have the same problem

Thank you

Hi,

First, thanks for the good job with this core. I cannot really use a dosbox core without MT32 emulation so for me it's the best one ;)

I built a version of this core for Windows x64 in february before fluidsynth integration (0.74-SVN r4308 a016aa2) and everything were fine. Shaders worked great.

Since many version, including the last one, built by myself or released recently for the buildbot (r4335 14ae740) the shaders don't work in OpenGL or Vulkan on Windows.

Example with version 0.74-SVN r4308 a016aa2 :

2020-03-26 18:26:00,985 :: DEBUG :: [INFO] [slang]: Compiling shader "D:\Emulation\Emulators\RetroArch\shaders\shaders_slang\crt\shaders\crt-pi.slang".
2020-03-26 18:26:01,016 :: DEBUG :: [INFO] [slang]: Building pass #0 (Indisponible)
2020-03-26 18:26:01,016 :: DEBUG :: [INFO] [Vulkan]: Push Constant Block: 32 bytes.
2020-03-26 18:26:01,050 :: DEBUG :: [INFO] [Vulkan filter chain]: Not using frame history.
2020-03-26 18:26:01,050 :: DEBUG :: [INFO] [Vulkan filter chain]: Not using framebuffer feedback.

Shader load well.

With version r4335 14ae740

2020-03-26 18:23:58,918 :: DEBUG :: [INFO] [slang]: Compiling shader "D:\Emulation\Emulators\RetroArch\shaders\shaders_slang\crt\shaders\crt-pi.slang".
2020-03-26 18:23:58,932 :: DEBUG :: [ERROR] [slang]: Invalid #pragma parameter line: "#pragma parameter CURVATURE_X             "Screen curvature - horizontal" 0.10 0.0 1.0  0.01".
2020-03-26 18:23:58,932 :: DEBUG :: [ERROR] Failed to compile shader: "D:\Emulation\Emulators\RetroArch\shaders\shaders_slang\crt\shaders\crt-pi.slang".
2020-03-26 18:23:58,932 :: DEBUG :: [ERROR] [Vulkan]: Failed to create preset: "D:\Emulation\Emulators\RetroArch\shaders\shaders_slang\crt\crt-pi.slangp".
2020-03-26 18:23:58,932 :: DEBUG :: [ERROR] [Vulkan]: Failed to create filter chain: "D:\Emulation\Emulators\RetroArch\shaders\shaders_slang\crt\crt-pi.slangp". Falling back to stock.
2020-03-26 18:23:58,932 :: DEBUG :: [INFO] [slang]: Building pass #0 (Indisponible)
2020-03-26 18:23:58,933 :: DEBUG :: [INFO] [Vulkan filter chain]: Not using frame history.
2020-03-26 18:23:58,933 :: DEBUG :: [INFO] [Vulkan filter chain]: Not using framebuffer feedback.

Shader fail to load

Don't know what is wrong ?

A few months ago, I notice that Xbox One (UWP) build of Retroarch dosbox-core core would fail to start core and in the most recent release, the core does not even load anymore. The dosbox pure and dosbox SVN core both load and start fine.

The Last Known Good build that I know for sure is based on the commit below. After that some commit seems to break starting core and then some time after that, the core no longer loads.

The environment is Xbox One Series X which runs UWP flavor but most likely repro on all Xbox One flavors.

aeb8ba2

'mount.exe' can already simulate parts of imgmount, but 2 crucial parts are missing to be able to flatten all disc images into the native filesystem (well those whose games don't read sectors directly anyway).

1. Mounting multiple directories in the same drive, using the 'disc change' mechanism of dosbox. This is necessary for multidisc games to be able to use this.
2. Mounting a cue extension that has a folder as a track and audio files, just like imgmount. This is necessary for games with cd audio.

These two features would 'close the gap'.

As for why do i want them, it's simple. I want to share data with scummvm and DOS. To do this the ideal mechanism is hardlinks, since the data is all readonly, only if the data is hidden away in a cue/bin or iso in the DOS side, this is impossible.

Another, maybe better, way would be making scummvm read isos/cue/bin inside a game dir for data, but that was suggested and rejected (I think). If someone appeared with a patch ready that had no effort for those guys, maybe, but i kind of fear they'd reject it because it 'would be for piracy' when it's actually just for data compression and less effort.

I have dosbox-svn running win95 and the mouse works great. I try the same win95 install with dosbox core but the mouse is not controllable though the keyboard input works great. I checked both input settings and controls and ensure keyboard+mouse is enabled.

Does a mouse device not work? Must I use a gamepad only? I have installed retroarch git version 9ec7cec and dosbox core db798da

Thanks! I'm hoping it runs win 9x much better than svn!

There are two obscure Dos games that used lightguns back in the day, moreover they supported 2p action:
AD cop
Bonbon paradise
In both games you have a Dossteup.exe where you can set your controller as lightgun but as espected as it's very rare, it won't work.
If you set controller to mouse you can play with modern lightguns, but only one player allowed.
In windows, nowadays lightguns like Aimtraks or Sinden or even Crt ones, are seen as absolute coord mice, and uses rawinput to allow two pointers at once.
https://www.youtube.com/watch?v=PKdaGMO1QQo
In this video he talks about some technical details.

I am playing using a custom .conf that was generated locally on the Switch. I have not altered any of the option other than adding mounting commands to the AUTOEXEC portion of the .conf. However, upon launching any title (including Lost Vikings, Black Thorne, Raptor, and Keen 4), the audio run faster than normal. I have tried these exact same .conf's on my PC and the games run perfectly with no audio issues. All core settings are identical and the console is not overclocked, though that should not matter.

I am using what I assume is the latest build (r4356 7a0b662).

A nice feature present in some variants of DOSBox like ECE and Daum is internal soundfont and MT-32 integration. You can accomplish the same goal if you use external software like VirtualMidiSynth and Munt, but it would be nice to have this handled all internally.

You could place soundfont/.sf2 files as well as requisite MT-32 files in /system or /system/DOSBox or some such, and select them in the core options.

i have setup command an conquer red alert with both addons and have mounted all 4 disc like this:

imgmount d allied.iso soviet.iso counter.cue after.cue -t iso

the game is starting and all 4 discs are mounted. when i try to start a mission from the aftermath missions, the game asks for the aftermath disc. in dosbox u need no press ctr+f4 to switch discs, but this is not working with the dosbox-core. i tried it with the same config and in the original dosbox its working without problems. is this feature missing in this fork?

Today I've been trying to configure the decades old game Super Off-Road for MS-DOS in this libretro core to work with 3 controllers (Wireless Xbox One gamepads). As of now I have not yet succeeded.

This old game can either use the combination of Keyboard Player 1 & 3 while Joystick Player 2, or Keyboard Player 1 while Joystick Player 2 & 3 as far as I can tell.

If we use the first scenario, I can manage to get Player 1 & 3 Keyboard controls working on my gamepads, but having Player 2 as Joystick makes all action buttons work but only the right directional button working on a gamepad. If I change Player 2 from Joystick to Gamepad in the Port 2 controls, none of the directional buttons seem to work at all. As I recall, this new core defaults the first Gamepad/Joypad activated in the Port menu to a 4axis one (I don't think this game likes that).

In the second scenario with only Player 1 using Keyboard controls on my gamepad, I can only use Port 2 for Joystick/Gamepad because it seems like it's not possible to choose Joystick/Gamepad for Port 3 and beyond in this libretro core. If Port 1 is Mouse/Keyboard, then it would be nice if Port 2 & Port 3 could be selected as 2axis Joysticks/Gamepads.

In all of the examples above I've fully configured all the control mappings for all of the 3 Controller Ports in this libretro core.

It could also be beneficial to have an option for changing between auto/4axis/2axis for Joystick type in the core Options menu for at least this game (I remember doing that with the dosbox.conf files in the "old days" of MS-DOS-emulation). It seems like this game might not be to happy with 4axis Joystick types because of its age.

Edit: I surely could just make the first 2 Ports Joypads and make the 3rd Port Keyboard as a workaround, but for "authenticity" I'll like the first Player to actually be the red car aka the Player 1 car.

Currently, the only options for cycles are Auto, Fixed, and Max. Standalone DOSBox has a "Max Limit #" option that can be pretty useful that would be worth adding. It essentially tells the game to run as fast as capable but no more than [number specified]. This is useful in that it lets you specify an upward limit so as not to cause problems with the game running too fast but keeps it simultaneously compatible with older hardware that isn't capable of reaching that upward limit.

So let's say, for example, you have a game that runs too slowly on auto but starts to run too fast past 50,000 cycles. You could specify a fixed value of 50,000 cycles and that would be fine if the machine is capable of 50,000 cycles. If it's not, you're going to have performance problems. If you specified "max", it would be fine for the slower machine because it goes as fast as it can, but not able to reach 50,000, meanwhile the faster machine passes 50,000 cycles when set to max and is now running too fast. Specifying "Max Limit 50000" would make it run as fast as possible on the machine but no more than 50,000 cycles, which now makes it compatible with both the slow and the fast machine with the same setting.

More info here.

Aren't these useful for application/game descriptions as well as a proper name for the core?

Hi there,

Seems that something's off with Disney's Aladdin on this core: when setting the joystick control, the main characted immediately runs to the left and never ever responds to directional input again.

On standalone dosbox, it's possible to set timed=false and it works fine, but not with this.

There was recently a bug report I noticed via SCUMMVM that seems to effect DOSBox-core as well. It pertains to an error in the Libco dependency that causes errors/crashes on Windows x64.

The original bug report is here:
libretro/libretro-super#1643

The author mentions that the old (and now deprecated) DOSBox core is effected and specifically links to it. They are probably unaware that core is no longer maintained. I checked the libco/amd64.c file used in the current DOSBox-core sources, however, and it seems to be effected as well in lines 62-71, as the original report mentions. The erroneous x28 instructions are there instead of x29.

I thought I should bring it to attention here so it can be investigated further.

Hi @realnc !

I have found that this is simply the best way to access DOS software for me, so I am doing some builds on low-spec hw (think of Pi1-level or performance) so I can use sw on those where 2000 cycles and simple VGA graphics are enough.

So, since it's already possible to build without FluidSynth (WITH_FLUIDSYNTH=0) for faster building times and smaller binary size, would it be possible to have a WITH_MT32EMU build option to disable MT32 building?

Thanks!

Audio Pre-Buffer can be a useful option for fine-tuning performance/reducing audio hiccups. It's not currently a usable core option.

The standalone version of DOSBox allows for full keyboard remapping via SDL, and this is a very useful feature. However, due to the limitations of the RetroArch API this is currently not available in DOSBox-core. Is this something that could be added?

One of the frustrating aspects of RetroArch is that it is entirely focused around controller input. This is considerably less than ideal for PC emulation, however, where many programs are much better suited to keyboard input. Unfortunately, RetroArch only allows remapping controller to keyboard inputs, and not keyboard to keyboard. For instance, it is not possible to remap the keyboard arrow keys to WASD using DOSBox-core.

I know that some other RetroArch cores such as MAME work around this problem by having their own internal remapper which can be accessed via their own UI (not RetroArch). Could DOSBox-core utilize a similar system to allow for full keyboard remapping? Would it even be possible to make use of MAME code to get a head start on this considering they are also a GPL licensed project?

Perhaps I don't know how and someone could kindly point me in the right direction, but I tried all the traditional methods available in DOSBox.conf, and they do not work. When I check the output from the core within Retroarch it always remains at 640x400.

See, the issue I am having is I am properly trying to emulate the Tandy CM-5 RGB color monitor through shaders, which has a much higher dot pitch(really poor, actually), so gaps between the pixels are essential to truly capture the grainy features of the tube, which enhance how games of the era looked.

It would be nice if we had a feature that would allow us to disable doublescan or even force the output resolution we are trying to achieve, so we can inject into the shader stack the lower resolution and go from there. Prompt text in particular does not look right when doublescanned to a higher resolution.

I am having an issue with not being able to increase/decrease cycles in game using Dosbox-core r4473 0654bd7 in RetroArch 1.10.2 on Windows 10. I am not certain if I am doing something incorrectly, or if the cycle adjustment functionality is not working as expected.

I can set cycles properly at the command line and through a conf file. The problem is with using the hotkeys Ctrl-F12 and Ctrl-F11 to adjust on the fly in game. I can't get these to respond either with Retroarch's Game Focus Mode on or off. I am not seeing any noticeable cycle differences even when cycleup and cycledown are set to extreme numbers that should be easily noticeable. It's not clear if the core is even seeing these at all, although all other inputs seem to be working.

I am loading games by having Retroarch load the game's individual conf files where I have cycles set to various fixed numbers depending on the game (for example: cycles = fixed 80000). Dosbox-core is reading these conf files since entering "config -get cpu" returns the expected values at the DOS command prompt, and there are noticeable changes in game when the cycles values are changed. However, the values for cycleup and cycledown do not seem to be used despite being properly reported as well by "config -get cpu".

I am not sure if I am doing something wrong (perhaps there is some other way to adjust cycles besides Ctrl-F12/Ctrl-F11 in Dosbox-core? I couldn't find anything relevant in the README). But I have not been able to figure out how to make this work. Is it perhaps broken?

Hi there @realnc

Live RetroArch geometry adjustments cause major audio drops on Raspberry Pi3-4 and other aarch64 light computers.

In order to avoid live RetroArch geometry adjustment AND have the right aspect ratio for non-4:3 games, I am working on trying to add an option to have games with 16:10 ratios displayed letterboxed inside the default 4:3 screen area.
For example, Jazz Jackrabbit should look like this, letterboxed inside the 4:3 area:

...it would be smaller, but live geometry adjustment could be avoided by always keeping the same 4:3 aspect ratio.

I have started by disabling live RetroArch geometry callback adjustment here:

...but doing that alone, Jazz in-game levels seem vertically stretched to 4:3, instead of letterboxed inside 4:3 with a 16:10-like aspect ratio as in the picture I put up there.

So, where in the DOSBOX code should I try to do ajustments to get it done? Do you happen to know?

When a directory is mounted and do not want the contents of the directory to be changed, the -t overlay parameter can be used to redirect the modification of this directory to another specified directory.

for example:

mount c c:\game\game1
mount c c:\game\save -t overlay

Now, all writes to the directory will be redirected to the c:\game\save directory. This is helpful for someone that needs to keep the directory unmodified as vanilla.

DOSbox ECE , DOSbox GOG , DOSbox-X , Dosbox-staging already support this function.

Hello. I have been testing the IPX function of DOSBox-core and I noticed that clients cannot connect to the server. I have two android devices that I used for testing. I used one device as a server (ipxnet startserver 2000) the server was created successfully. On the other device that I used as a client (ipxnet connect 192.168.x.x) but there was a connection failure, and this only occurs in RetroArch DOSBox-core and DOSBox-SVN cores, in standalone emulators like Magic DOSBox, Server and Client work normally.

Sorry for my english.

I'm really happy about be able to use dosbox on RA and even more excited about have it with munt.

As much i'm using dosbox on RA i'm getting most of time stucked by little things that i'm forced to change manually in a not-pratical way like save per game config, edit it and create custom batch files or config in order to have the desired results.

[the problems]
One of the first problem i had is about the free memory on the automatically mounted drive, in order to setup/install correctly some software inside dosbox it will be usefull to create inside RA core options a voice for "mount unit free memory" (i use usually a value nearby 1024).
This can be done by adding a variable at the end of the mount line recalled on the dosbox core options on RA. Simply if it's default it will be not considered otherwise it will had the -freesize (amountoffreememory) at the end of mount line accordly to the option selected by users.
Core Options->mount unit free memory (default,1024 etc...)
command line "mount c [path] -freesize amount"

Another problem is usually that some dos software require to be into a specific path (or sometimes the "installation path" is stored and wrote on an additional .ini file inside the software directory).
This pop ups two solutions:
1.the final user will be able to understand and manipulate the .ini file in order to set the right directory (but sometimes it's not accepted C: as installation directory)
2.give the user the possibility to choose a directory as "MAIN" mount.
This problem happen often especially when the software will set environment variables and set path variables.

example if I wish to launch c:/DOSBOX/SOFTWARE/WIN3/win.com i will need a mount c c:/DOSBOX/SOFTWARE/ and not mount c c:/DOSBOX/SOFTWARE/WIN3/

Hi,

I'm trying to build this core on my GNU/Linux systems, where SDL1.x (being old, dead software years ago), is not present.

So, trying to build dosbox-core I get this:

g++ -std=gnu++17 -Wno-register -DFMT_HEADER_ONLY -D__LIBRETRO__ -MMD -fPIC  -I../src -I../libretro -I../libretro/virtual_keyboard -I../libretro/deps/common/include -I../include -I../libretro/deps/SDL_audiolib/3rdparty/dr_libs -I../libretro/deps/SDL_audiolib/3rdparty/speex_resampler -I../libretro/deps/SDL_audiolib/include -I../libretro/deps/SDL_audiolib/src -I../libretro/sdl_sound_wrapper -Ideps/fmt/include `pkg-config  --cflags-only-I mt32emu  libmpg123 opusfile vorbisfile` -DGIT_VERSION=\""f5e1796"\" -DSVN_VERSION=\""r4470"\" -DHAVE_ALSA -DC_HAVE_MPROTECT="1" -O3 -DNDEBUG `pkg-config --cflags sdl` -DC_IPX -DC_SDL_SOUND `pkg-config --cflags libmpg123 opusfile vorbisfile` -DAULIB_STATIC_DEFINE -DOUTSIDE_SPEEX -DRANDOM_PREFIX=SDL_audiolib -DSPX_RESAMPLE_EXPORT= -DC_DYNAMIC_X86="1" -DC_TARGETCPU="X86_64" -DWITH_PINHACK=1   -c -o ../libretro/disk_control.o ../libretro/disk_control.cpp
Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found
In file included from ../libretro/disk_control.cpp:5:
../src/dos/cdrom.h:34:10: fatal error: SDL.h: No such file or directory
   34 | #include "SDL.h"
      |          ^~~~~~~
compilation terminated.
make: *** [<builtin>: ../libretro/disk_control.o] Error 1

The whole point of using a LibRetro core is not having to depend on SDL, even less depending on SDL1.x in 2021. So, what am I doing wrong here?

Thanks!

Attempting to load DOSBox core on latest Debian results in:

[ERROR] Failed to open libretro core: "/dane/gry/retroarch/cores/dosbox_core_libretro.so"
[ERROR] Error(s): /dane/gry/retroarch/cores/dosbox_core_libretro.so: symbol _ZNSt10filesystem7__cxx114path5_ListC1Ev version GLIBCXX_3.4.26 not defined in file libstdc++.so.6 with link time reference

Debian Buster supports the following libstdc++:

$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep LIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25

Would it be possible to build against an earlier version or link statically against 3.4.26? Identical bug has been fixed in the Play! core in a fairly straightforward way:

jpd002/Play-#865

Would it be possible to apply a similar fix for the DOSBox core?

https://www.vogons.org/viewtopic.php?f=41&t=34642#p674876

These are the minimal (and very unlikely to get broken) patches to support the largest possible DOS size for hdd images, which upstream doesn't support because they decided to limit those ints to 32bits instead of 64bits for some reason.

The explanation of what the patches do is in the link but to repeat it, one changes the max size of a hdd mount by changing the bit size of a variable, the other changes the default autodetect of hdd mounts to support the max size possible for them if they were FAT16 (note, you can always not use the autodetect by specifying the geometry manually during mount, which is what i always do to be safe to defaults changes).

I said 'FAT16' because you can only mount FAT32 raw iirc (windows manages it, not dosbox shell, which can't read FAT32), so a FAT32 mount larger than the FAT16 max should always use the -size setting to be 'correct'.

What does this affect? Users will need to use C/255/63 (cylinders/headers/sectors) instead of C/16/63 when making their FAT16 images if they want to autodetect them. That patch can be skipped if that is unacceptable, since specifying the geometry manually is a good idea anyway.

Note: unlike the more complex patch to support larger images, these patches don't add imgmake or change the code more extensively. This means they should break a lot less (and i've noticed that on my ppa buildbot).

The disadvantage is that making the image is a more complex process for the users, but they needed to rawmount/fdisk the image anyway to use it with windows because i haven't found a 'simple' linux (or portable) command to create a FAT (16 or 32) formatted and fdisk'ed image ready to use from the host OS. And imgmake certainly doesn't.

mkfs.fat from the package dosfstools comes close but it doesn't appear to have a single liner to do it or a easy way to get the imgmount parameters.

What happens is that i create a non bootable image with dd with a weird calculation¹ and then keep the values used on that weird calculation to pass to imgmount -size with a raw drive letter² for windows to fdisk and then reboot with a normal drive letter³ without the -fs none (if fat 16, otherwise keep the raw mount). It's user unfriendly to say the least.

¹ dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]` (with C between 0-1023)

² imgmount 3 dsk.img -size 512,63,255,1023 -fs none (max size, 8.4 gb, so its going to be a FAT32 image after windows fdisk)

³ imgmount c dsk.img -size 512,63,8,731 (for if a fdisked fat16 image, i use this to hold windows 95 and be able to place files on the autostart dir from the dosbox shell)

I ran UK CD version of that game on Thinkcenter-m72e (x86 mini PC) Linux (Ubuntu 20.04) version,

but when I tried run this game on dosbox-core, the framerate is unstable. it 'spikes' ingame.

(standalone DOSBox works well, but doesn't work well in dosbox-core core)

Hi there,

Just built this core on the latest Raspberry Pi OS on the Pi5, and it segfaults when dosbox_core_core is set to dynamic.

Not much more to say, it seems the ARMV8L dynarec doesn't work on the Pi5.

Hi,

I don't know if it's related to RetroArch apparently lacking pointer confinement on Wayland, as I commented here:
https://forums.libretro.com/t/sticky-cursor-around-the-visible-area-of-rgui-on-wayland/38979

...But for example, Lemmings or Ishar have major problems with cursor movement on Wayland, like cursor is stuck on the right half of the screen, or in a certain area.
This happens on all Wayland compositors I tried: Weston, Sway and tinywl.

Has anybody tried this core on Wayland compositors?

Hello,

first of all, thanks for all the work! I was just wondering, would it be difficult to integrate the dosbox-x fork with retroarch? If you already have the svn mainline, how much work would it take to also integrate dosbox-x? Dosbox-x is interesting in the sense that it has the best Win9x support, the other forks/SVN are very spotty on 9x.

I use scripts that load games using e.g.

mount c .

These no longer work since the change on Dec 15. How can I reference the current folder in a DosBox BAT/CONF file?

Hi there, @realnc

Once again I come to you with a question about dosbox-core.
I build the core on the Pi4 (running 64bit kernel & libs) with this line:

make -j4 platform=unix WITH_FAKE_SDL=1 STATIC_LIBCXX=1 \
WITH_FLUIDSYNTH=0 BUNDLED_AUDIO_CODECS=0 BUNDLED_GLIB=0 BUNDLED_LIBSNDFILE=0 WITH_PINHACK=0 WITH_VOODOO=0 WITH_BASSMIDI=0

However, I have observer that CPU usage is exactly the same whether I chose DYNAMIC (generic recompiler) or NORMAL CPU emulation modes in SPECS.

I have run Dosbox on x86 many times, and the dynamic recompiler usually leads to a way lower CPU usage, so my guess here is that there is no dynamic recompiler running here.

So, what am I missing to build it with the best possible dynamic recompiler for arm64?

Thanks!

Hey, good day there. I was looking up recently that anytime you attempt to run a config/bat file all is good to that point.
Problem is if you close the game and get back to Retroarch's menu but then either attempt to re-load the same file or any other config/bat one then you get client crash, just like in the video below. The moment gets black is when client gets shutdown.

https://www.dropbox.com/s/yzdh7g6ypik1qm4/dosbox%20core%20crash.mkv?dl=0

Not really an issue if you have all files configured already but I was looking different settings to test up and I need to restart retroarch anytime in order to look up for new ones. Also, since Retroarch's restart option doesn't work unless absolute path have no spaces for folder name, then gotta need to close and re-open it manually. Either way, I'm reporting this since it may have to do be related to the core or Retroarch itself. This test is done in windows 10 64 bits. Last retroarch version + dosbox core build.

Thanks for your time and any help.

The beauty (and the purpose) of cycles auto and max is that you wouldn't need to tweak so much to get decent game performance

Setting cycles to max results in the following:

This would be fine for low end games but not for something like quake...
I benchmarked with this:
quake +timedemo demo1

I didn't have enough patience to wait for the timedemo to finish

If I do the same but beforehand I run:
config -set cpu cycles max

auto is also unusable for quake too even if I set it from the commandline, not sure why, but it's worse when using the core options because the result is: