[DOSBox] official thread

ecto

@nemo93 said in [DOSbox] official thread:

@ecto would you mind sharing your full conf please (game.conf + dosbox.conf + OS/kernel/Retropie)? I'll reproduce here as I can't see why such big differences between SVN and Staging. For now there's no evidence about an issue in the "svga code" but anything supporting this will be helpful.

I'll do that in the next couple of days. I'll try to do it tonight, but you never know what else is left to do to prepare for Christmas ;)
With OS/Kernel config you mean /boot/config.txtright?

I've tried Timeshock and it's running very smoothly even in higher resolution. Is your issue only about sound distortion or is it also about slow video emulation?

It's usually a crackling and from time to time a distorted short bleeping/screeching. IIRC the emulation speed is ok, but it might skip "in sync" with the crackling.

Yesterday I tried "Dark Forces" and it was also crackling and the gameplay was skipping. It runs good on SVN...

nemo93

@ecto Don't worry I know what you mean regarding Christmas :D No rush, do what you can whenever you can! Yes if you could share the various DOSBox conf files you're using as well as the kernel version you're using (also are you using "full" or "fake" KMS driver) that would be great. Mention if you're using any overclock. If you don't know regarding kernel/KMS then please share your /boot/config.txt indeed.

The crackling for sure is coming from the specific Staging "pi4" branch we discussed above. Crackling shouldn't be heard if using the master branch and always setting less than 35000 cycles (which is the max cycles mark on both pi3B+ and pi4, above that value crackling should be heard and slowdowns will occur).

Dark Forces (another fantastic Star Wars game from that era that must not be forgotten about!!) is running very fine. I'm having General Midi + SB16 set up, machine = vesa_nolfb and 25000 cycles. Everything is running fullspeed and no sound issue to report. Don't forget to switch DOS4GW for the DOS32A extender.

If you have time I wonder if you could try my "default" conf file and give it another test with Dark Forces for instance.

xwons

Does anyone know how to try dosbox pure in retropie, now that it has been released?

ExarKunIv

@xwons for right now you have to compile it yourself

https://retropie.org.uk/forum/topic/28924/dosbox-in-retroarch-any-chance-we-can-have-this-on-the-pi

ecto

@nemo93 I found a little time today:

Here are my

DosBox SVN conf (to compare with stagings conf file)
DosBox Staging conf
Timeshock.conf
config.txt (using fkms for Amiberry and Daphne)
Kernel is Linux retropie 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux

I fiddled around a lot with everything (that's just how I work ;) So idk if the config.txt is all in order. But so far I haven't had any lockups or other problems with it.

And now I off, wrapping gifts ;)

Thanks for having a look!

retro81

Hi all, are we discussing here the new lr-dosbox-pure emulator, or should I use another thread?

quicksilver

Has anyone managed to get dosbox-x up and running on a pi 4? Very curious if it would be possible to run some windows games using it...

Lolonois

@nemo93 and other dosbox-staging users here:

Recently their build process has been changed to meson.
I adapted the dosbox-staging.sh scriptmodule in the Wiki of dosbox-staging.

@mitu what is the process/are the quality gates to get the script as experimental into RetroPie-Setup repo?

Cheers

mitu

@mitu what is the process/are the quality gates to get the script as experimental into RetroPie-Setup repo?

You can submit a PR, IMHO it would be preferable to take into account the available dependencies (newer fluidsynth libraries are not available in the distro) and an optimal configuration needed for each platform (i.e. has anyone tested this on a Pi3). The other Dosbox packages have also a starting script which start timidity for MIDI support, the starting script can maybe leverage that.

I can certainly review it, I think @BuZz already tested it and may have the basis for a new scriptmodule for dosbox-staging.

I see there's a special branch used for building in the Wiki script, are the changes now in the master or stable branch ? What is the upstream maintainers' take on the packaging - is it preferable to ship a release version or build from master/main ?

nemo93

@Lolonois thanks for the update! Much appreciated. I do confirm script does work 100%. There might be some (small) adjustments to be made but it's more than ok.

@mitu
some testing still required but the current version of Staging (master branch) might be a nice addition to Retropie. Staging does now come with full built-in GM and MT32 support, SDL2 and many other quality of life improvements. For those not willing to go the "libretro" route then Staging could be a very fine alternative for their Pis.

To your other points: Fluidsynth (GM) and Munt (MT32/CM32) support is built-in meaning no dependencies required. Devs were willing to support only the latest libraries version hence why these are built-in. The default configuration is roughly the same as other forks. Devs are testing on Pi3 and other+@Lolonois+myself on Pi4. My starting script is a very thinned-down version compared to "SVN" given I don't rely on Timidity but solely on Fluidsynth and Munt for MIDI playback.
=> Does Timidity come as a mandatory requirement here?

If you or @BuZz already have a scriptmodule (or a PR) for that fork please let me know and I'll be glad to assist.

The branch to go for is definitely master. The special branch you refer to comes with specific parameters and optim especially intended for Pi4. That branch is not ready yet to be merged into master. I'd say it's preferable to build from master but I don't want to step on anyone's shoes here and question will be asked to maintainers directly.

mitu

@nemo93 said in [DOSbox] official thread:

To your other points: Fluidsynth (GM) and Munt (MT32/CM32) support is built-in meaning no dependencies required. Devs were willing to support only the latest libraries version hence why these are built-in. The default configuration is roughly the same as other forks. Devs are testing on Pi3 and other+@Lolonois+myself on Pi4. My starting script is a very thinned-down version compared to "SVN" given I don't rely on Timidity but solely on Fluidsynth and Munt for MIDI playback.
=> Does Timidity come as a mandatory requirement here?

No, Timidity is not mandatory, but we might need some soundfonts installed (and then configured). The .conf that comes with Dosbox right now has the MIDI port configured for Timidity+ALSA, should be replaced/configured with the staging internal MIDI support instead.

The branch to go for is definitely master. The special branch you refer to comes with specific parameters and optim especially intended for Pi4. That branch is not ready yet to be merged into master. I'd say it's preferable to build from master but I don't want to step on anyone's shoes here and question will be asked to maintainers directly.

There are pros and cons to using master vs a release tag.
My preference would be to lock on a release version for a RetroPie scriptmodule. It makes it easier to track new features and the (unavoidable) bug reports would be easier to triage and diagnose when reported against a specific branch or version.

On the other hand, tracking master means new additions (and bugfixes) are easier to test with a simple 'update from source' in RetroPie.

Thanks for chiming in.

nemo93

@mitu thanks to you.

The above makes total sense. After a quick chat with one of the maintainers it might be better to indeed offer users with 2 options. One would be to get a specific tag/release binary whenever the "Install from Binary" is chosen. The other would get user to compile the latest master whenever "Install from Source" is picked up. I believe it's something already in place for other "cores" but I haven't checked recently. Would that be an acceptable solution?

mitu

@nemo93 Usually a scriptmodule wouldn't use different versions of the upstream project depending on binary vs. source installs. The binaries are just source installs packages stored on the RetroPie's server that can be installed from the setup script.

We have something similar for EmulationStation. It has a different package for the master branch (emulationstation-dev), while the regular emulationstation package builds from the stable branch.

Since we already have 4 Dosbox related packages in RetroPie (upstream, a SDL2 fork, a quasi-abandoned Libretro fork and the Dosbox Pure Libretro core), adding another 2 more Dosbox packages would be a bit much.

nemo93

@mitu Thanks again for answering my many questions. Let's do as follows:

stick to master branch only. Staging is rock-solid and I haven't got a single issue with it for many many months. Few issues I got are games-related. Also better from a maintenance standpoint. Not sure how you promote an emulator from "experimental" to "optional" though?
decide of a default config. To prevent any issues and to provide best experience to new users the default config file is pivotal. I trust I've nailed it after countless testing sessions (pi3 and pi4) and I'm quite happy with the one from the wiki. With Staging the most important is to ensure the cycles = parameter is set to a value (eg. 25000) not leaving it on auto.
=> I recall there might be some Retropie command to pass to the scriptmodule in order to tweak a conf file after it has been generated. This to ensure some values are being properly set. EDIT: should be the iniConfig + iniSet functions.
decide if a soundfont (fluid?) should be considered a dependency. Configuration of anything MIDI-related (General MIDI via Fluidsynth and MT-32 via Munt) is actually quite simple. You just need to set which synthetizer you'd like to go with and that's all. No need to fiddle with ports or Timidity. All you need is a soudfont (typically .sf2 file) and/or mt32 roms. The former is available from multiple sources online (or from your GNU/Linux distro) where the latter is trickier given mt32 roms are not free.

I'll submit a PR in the coming days if you agree so we'll be able to discuss further on github. It will be roughly the same as from the wiki, I just made a few more tweaks. Any questions please let me know.

Note: I totally agree regarding the multiple DOSBox forks available, it's important to keep number to a reasonable level. I'd just don't want to comment too much on that as I'm partial but perhaps the SDL2 fork you're referring to (from DuganChen) could be dropped at some point as Staging does bring similar features (+more). Staging is in active development.

mitu

@nemo93 said in [DOSbox] official thread:

I'll submit a PR in the coming days if you agree so we'll be able to discuss further on github. It will be roughly the same as from the wiki, I just made a few more tweaks. Any questions please let me know.

Sure, you can go ahead and submit it. A few notes on your existing script:

a new scriptmodule has to declare a new variable pointing to the repository (rp_module_repo ) and gitPullOrClone will automatically use it. This a very recent change in the build scripts - take a look at how dosbox-sdl2 is configured.
No libs copied to /usr/local/lib. If you need something that's not in the distro (i.e. libfluidsynth), copy it to the install folder ($md_inst) and add a .sh wrapper that extends LD_LIBRARY_PATH before running the binary to pick it.
the inst function should just list the output files and they'll be copied to to $md_inst. No need to manually copy files.
You should include some additional files besides the binary, I like to include a README and/or the licensing info present in the distro.

=> I recall there might be some Retropie command to pass to the scriptmodule in order to tweak a conf file after it has been generated. This to ensure some values are being properly set. EDIT: should be the iniConfig + iniSet functions.

Yes, but be aware that iniSet sets the value only if it's missing from the file - this is intentional to not override any user set option.

nemo93

@mitu thanks again. Script edited to take all above points into account. Works very fine now on my setup. Also PR just submitted. Happy to discuss further. Thanks to all maintainers, testers and to @Lolonois for giving me a boost :-)

On another note the next stable release of Staging is around the corner and should be tagged 0.77. Some features have already been merged to master branch. In (very) short many improvements have and are still being made to MIDI playback (including lower latency via dedicated thread) and build system migrated over to Meson. A proper announcement will be sent over once everything is ready.

There's also a new DOSBOX-X release. As always plenty of additions and improvements added. On the Libretro front DOSBox Pure keeps receiving updates as well. I'm afraid I have no time to push further my testing on that "core" hence any feedback appreciated.

Lolonois

Ah great, thanks for pushing the dosbox-staging scriptmodule forward quickly @nemo93 @mitu @BuZz :)

jamrom2

@lolonois Hiya... yes my attempt to build from source crashed on the Meson error. how can I upgrade to the required 51 from 49.2?

Thanks!

update: I found this... but I'm running a Pi3B+. Does it matter? I just did an image of my build, so I'm ok to mess around with my build to test.

https://www.reddit.com/r/RetroPie/comments/egjqw2/how_to_manually_compile_newest_mesa_drivers_for/

mitu

@jamrom2 said in [DOSbox] official thread:

how can I upgrade to the required 51 from 49.2?

Are you using a recent Raspberry Pi OS (Buster) release on your Pi ?

jamrom2

@mitu good question... I'm using the latest build of Retropie... 4.7.1. That's about all I know about what's running the background.

So ... I'd like to say yes, but I honestly don't know.

Can I run a command to tell me?