[DOSBox] official thread
-
@nemo93 Im not sure I have as great a need for this as I once did. I have dosbox-svn running with great performance on my pi 4 now (much better than my pi 3). If there is a automated build script for this I would be happy to try it out but for now im pretty content with dosbox-svn.
-
@quicksilver Box86 is giving great performance for x86 Linux, and I finally got Bochs going (not easy) as well. Bochs is still a bit slow with Win98 and XP, but you CAN install things into the virtual machines and then grab any assets you need from those installs.
-
Hoping one of you DOSBox experts might be able to help..
I'm struggling to get any of my flight sims (F-117A, F19 etc) to recognise my Thrustmaster USB joystick when it's configured as JS1.
The problem is that I really need my arcade cabinet controller PCB to be JS0 for other systems, and when I plug in the Thrustmaster after the PI is booted it is assigned as JS1.I've tried the joysticktype "axis4_2" option in the .conf file which is documented as "supports one joystick, second joystick used" and, according to runcommand.log, that does indeed pass the Thrustmaster (JS1) to DOSBox, but when the game is launched the joystick is still inaccessable.
I can get round this by using auto or axis4 and plugging in the Thrustmaster USB BEFORE I boot the PI, in which case it's assigned as JS0 and then works perfectly in the games.
Am I missing something ?
If I'm not then the ideal solution for me would be if I could temporarily swap the controller PCB and Thrustmaster JS values (JS0->JS1 and JS1->JS0) in the .sh or .conf file and then revert back when the game exits. I'm no Linux expert though so no idea if that's possible ?
-
@shaun57 maybe this would help? https://github.com/meleu/RetroPie-joystick-selection
-
@quicksilver thanks I'll have a look at that
-
Though on closer look that may be only for retroarch emulators...
-
@quicksilver said in [DOSbox] official thread:
Though on closer look that may be only for retroarch emulators...
Wasn't there an experimental libreto core for dosbox?
-
@VictimRLSH performance is very poor last I tried it out, even on the pi 4.
-
@quicksilver said in [DOSbox] official thread:
@VictimRLSH performance is very poor last I tried it out, even on the pi 4.
I've noticed that DOSbox on the Pi 4 is a let down in general and in many cases worse than a 3B+. Once I get more skilled in compiling and learn a few more tricks and I can try recompiling it to see if I get better performance than what has been packaged. I've noticed with Bochs it works a bit better if you compile it yourself instead of just install the package from the repository. Bochs is too slow to run games at all really, BUT is a great way to get a Windows game installed so you can mine the assets for ports.
-
@VictimRLSH I have another thread around here somewhere with a method to improve dosbox performance on the pi 4. Once you make the proper changes, performance is better than on a pi 3. I'll try to find the thread and post the link when I have a sec.
-
Quick update given dosbox-staging keeps on adding features amidst other improvements. The upcoming 0.76.0 release will bring major GUS (Gravis UltraSound) improvements as well as other audio refinements.
0.75.1 is only a small release squashing few bugs (see release note) as well as other small changes:
- Add support for binding more controller axes
- 64-bit Windows builds
- Log base memory address (for Cheat Engine)
Also on the pi3/pi4 front especially, there's a dedicated branch with a scheduler-like addition allowing to unleash the number of allowed cycles on a stock pi4 for instance. Games like Fade to Black runs at full speed at higher resolution. Many other games run at fullspeed (or close to that) now.
-
@nemo93 Wow I've read through your contributions to the pi4 build, the wiki and the release notes. This really sounds like a big step! Thanks for your dedication!
I've been an avid DOS gamer in the 90s, so my Retropie was always equipped with a great library of DOS games and custom made startup scrips for MIDI output selection etc...I was a little bummed with the performance of the pi4 in this regard until @quicksilver's workaround (btw. thanks for that, too)! Now it seems SDL1 and dispmanx should work again as they should (see How to keep 4/3 aspect ratio in Daphne games ?)
I haven't tried it yet due to time restrictions, but what would you all think: should I update to Staging or stay on SVN for the time being?
I think Staging sounds too good to be true, but I fear I have to rework quite a bit (although my startup script should work with Staging, as it just generates a conf on the fly which is passed over to dosbox). I fear that I have to edit all these conf files for the cycles count by hand...Also, can Staging be installed though the retropie-setup script or do I have to do it by hand?
Thanks and happy gaming!
-
hi @ecto ! I'd say for the time being it's safe to stick with SVN. The many improvements on "staging" have not all been merged into the master branch and some are still being tested (like the Pi speed/cycles improvements). Also
fluidsynthhas just been implemented and for now it's not really easy to use with Retropie. So if you got some General Midi games they might not work out-of-the-box.But it's getting closer...I'm using staging for more than 6 months now and it's my default choice since then for anything DOS. My testbed is made of roughly 250 games (from early CGA stuff up to the more complex 3D games) and I'm not the only one testing. Meaning we'll have quite some tailored conf files to share for various devices and for many games. I already did share some in the wiki but I do hope to share even more in the future.
Like with many things we need to be a bit more patient as this version of DOSbox is likely to become a "must have" at some point (this is my expection at least!). For that reason there's still no script bundled with the retropie-setup but I have one ready that I could share if you want.
Once staging will be ready I'll raise a PR for it to be included into Retropie if that makes sense (I'd like to not have too many DOSbox forks or people might get confused).
-
@nemo93 Thanks for this very informative reply! I'll stick with svn with the patched sdl1 library for the time being!
Btw. I'm using a mix of munt and fluidsynth for midi under dosbox, as not everything plays nice with fluidsynth. ;)
-
Another quality update from the DOSBox Staging folks who come with a 0.76.0 release. Feel free to check the release note) for list of changes. Few highlights below:
- More Gravis UltraSound emulation improvements
- new built-in GLSL shaders
- Built-in MIDI support via FluidSynth (2.x)
- Audio pop and click prevention
- ...
I'd say the compatibility, performance and quality of life improvements have me stick to that fork. For those interested to give a try there's a script to have it integrated with Retropie on the Wiki (no support provided at this stage). MT-32 integration is lacking but it's being looked after as well as many other interesting topics.
-
@nemo93 This sounds really exciting! I have a few questions though, before I start the tranition:
- as MT32 is not integrated, is it posible to use Munt externally (the way through an Alsa port)?
- how are the cpu cycle settings now working out? Does every game need a separate setting?
- This is minor: does Staging behave the same way as Dosbox when started through the command line with extra overriding config files? I'm using a custom starting script, but changing that should be no problem...
Cheers!
-
@ecto hello! Let me try to address your points.
-
as MT32 is not integrated, is it posible to use Munt externally (the way through an Alsa port)?
=> the logic is simply not "wired" in DOSBox Staging and to any versions prior 0.76. There's a very early branch available for testing (check here and scroll down to the bottom). The good news is that MT-32 will be provided the same way ScummVM does (integrated). This feature is planned for 0.77. -
how are the cpu cycle settings now working out? Does every game need a separate setting?
=> I'd say that generally speaking all DOS games do require precise fine-tuning. I found out setting a default cycles count of 25000 or 30000 does work for a good number of games on pi4 (same on pi3). More are coming on that front hopefully. Perhaps the new Vulkan driver and next kernel etc would help. If you have any issue with a specific game feel free to ask here or on Staging Discord. -
this is minor: does Staging behave the same way as Dosbox when started through the command line with extra overriding config files? I'm using a custom starting script, but changing that should be no problem...
=> It should given the layering approach is still there (wiki). If you do have an example feel free to share but I guess best way is to give it a go and report back :)
Hope this helps.
-
-
@nemo93 Thanks for your reply! That was really helpful.
I guess that a lot of games (especially the protected mode games) can be run with max cycles, right? Is 30000 the maximum on a non-overclocked RPi4? I've seen that there are listings of recommended cycles for a lot of games on the Staging wiki.
And - best of all - you have written a dos32a extender compatibility sheet, right? That was really helpful. I think all my games now run with dos32a now. Thanks for that btw!It's really tempting to start integrating Staging into my setup, and I guess there is probably not much too much to do.... Hmmm. Do you have an idea how long the 0.77 release will take (give or take)?
-
@ecto no problem. For now on a stock pi4 you won't be able to go above 35000 cycles based on my testing. Setting a higher cycles count will get your games to stutter. This is weird as this count is roughly the same I was able to get to with a pi3B+. Hence why a specific branch has been created to somehow unleash the power of the pi4. With it you could get up to 100.000 cycles with some (protected mode/3D) games like Fade to Black which now runs fullspeed even on higher resolution. That branch can be compiled as it's part of the "Retropie script" as indicated from the wiki (just uncomment a line).
About DOS32/A extender, yes I did spend quite some time on that list but I'm happy it's useful to other people. I'm not the only one to have participated of course. So if you find more games that deserve to be on that list just let me know on Discord or update the list by yourself.
"If it works don't fix it" :) Therefore if you're happy with your current setup just leave it as it is especially if you need MT-32. Otherwise if you're struggling to get a game properly working with DOSBox SVN then give it a try. Staging is being updated almost daily and the amount of work done by the 2 main devs is simply breathtaking. Yet I can't commit to any release date. You could have a look at the project page to see progress by yourself.
I'll keep updating that thread whenever there's important change about DOSbox (not only Staging).
-
@nemo93 Since the thread is about DOSBox in general, you probably want to add information for DOSBox-X updates too. DOSBox-X (https://dosbox-x.com) aims to be a complete DOS emulation package that is both fully-featured and easy to use, so unlike DOSBox Staging and most other DOSBox forks it officially goes beyond DOS gaming, covering things like DOS applications, DOS games, DOS commands, DOS-based Windows including Windows 3.x/9x, and more. DOSBox-X is very feature-rich compared with other DOSBox forks and it is under very active developments as well for further features and improvements to usability etc. It has a menu system which makes it easier to use too. You can find examples of DOSBox-X's unique features from the DOSBox‐X’s Feature Highlights page (these are just examples; there are a lot more).
DOSBox-X version 0.83.8 has been recently released with quite a few new features and other improvements over the previous version, such as support for TrueType font (TTF) output and on-screen text styles for DOS applications, support for ARM-based M1 Mac and macOS 11 Big Sur, mounting MAME CHD CD images, switching OpenGL (GLSL) shaders at run-time, selectable host keys from the menu (Ctrl+Alt, Ctrl+Shift, etc), improved automatic fix for the "Packed file corrupt" error, enhanced MODE command to change screen dimensions, along with a lot of usability improvements such as enhanced mapper editor interface, more saving options for the built-in configuration tool, displaying help information for DOS commands from the "Help" menu, and loading DOSBox-X mapper files dynamically from the "Main" menu. The release notes for DOSBox-X 0.83.8 is available from: https://dosbox-x.com/release-0.83.8.html
The latest packages for Windows, Linux, macOS and DOS platforms can be downloaded from the DOSBox-X homepage (https://dosbox-x.com/).
The DOSBox-X Wiki system including its user guide is available from: https://dosbox-x.com/wiki
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.