exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

compiling dosbox with dynamic recompilation support

Thu Jan 01, 2015 7:01 pm

Out of the box dosbox does not enable dynamic recompilation for the arm. It does have support though (has support for armv4 and armv7).

To compile dosbox for better performance with dynamic recompilation on raspbian you can do the following:

get the dependencies4.2 FPS

Code: Select all

sudo apt-get install libsdl1.2-dev libsdl-net1.2-dev libsdl-sound1.2-dev libasound2-dev libpng12-dev automake autoconf zlib1g-dev
get the source

Code: Select all

svn checkout svn://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk dosbox
configure it

Code: Select all

cd dosbox
./autogen.sh
CXXFLAGS="-O2 -mfpu=vfp -march=armv6j -mfloat-abi=hard" ./configure --disable-opengl
manually enable dynamic recompilation (thanks to http://boards.openpandora.org/topic/754 ... ec-update/ for the hints)

Code: Select all

sed -i "s/C_TARGETCPU.*/C_TARGETCPU ARMV4LE/g" config.h
echo "#define C_DYNREC 1" >>config.h
and build it

Code: Select all

make
and you should end up with a faster dosbox (in src/) - make install to install it. But it's not ready to run yet - we need a config to fix a few things.

add this configuration to ~/.dosbox/dosbox-SVN.conf

Code: Select all

# This is the configuration file for DOSBox SVN. (Please use the latest version of DOSBox)
# Lines starting with a # are comment lines and are ignored by DOSBox.
# They are used to (briefly) document the effect of each option.

[sdl]
#       fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go back)
#       fulldouble: Use double buffering in fullscreen. It can reduce screen flickering, but it can also result in a slow DOSBox.
#   fullresolution: What resolution to use for fullscreen: original, desktop or a fixed size (e.g. 1024x768).
#                     Using your monitor's native resolution with aspect=true might give the best results.
#                     If you end up with small window on a large screen, try an output different from surface.
# windowresolution: Scale the window to this size IF the output device supports hardware scaling.
#                     (output=surface does not!)
#           output: What video system to use for output.
#                   Possible values: surface, overlay.
#         autolock: Mouse will automatically lock, if you click on the screen. (Press CTRL-F10 to unlock)
#      sensitivity: Mouse sensitivity.
#      waitonerror: Wait before closing the console if dosbox has an error.
#         priority: Priority levels for dosbox. Second entry behind the comma is for when dosbox is not focused/minimized.
#                     pause is only valid for the second entry.
#                   Possible values: lowest, lower, normal, higher, highest, pause.
#       mapperfile: File used to load/save the key/event mappings from. Resetmapper only works with the default value.
#     usescancodes: Avoid usage of symkeys, might not work on all operating systems.

fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=original
output=surface
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-SVN.map
usescancodes=false

[dosbox]
# language: Select another language file.
#  machine: The type of machine DOSBox tries to emulate.
#           Possible values: hercules, cga, tandy, pcjr, ega, vgaonly, svga_s3, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe.
# captures: Directory where things like wave, midi, screenshot get captured.
#  memsize: Amount of memory DOSBox has in megabytes.
#             This value is best left at its default to avoid problems with some games,
#             though few games might require a higher value.
#             There is generally no speed advantage when raising this value.

language=
machine=svga_s3
captures=capture
memsize=16

[render]
# frameskip: How many frames DOSBox skips before drawing one.
#    aspect: Do aspect correction, if your output method doesn't support scaling this can slow things down!.
#    scaler: Scaler used to enlarge/enhance low resolution modes. If 'forced' is appended,
#            then the scaler will be used even if the result might not be desired.
#            Possible values: none, normal2x, normal3x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x.

frameskip=0
aspect=false
scaler=normal2x

[cpu]
#      core: CPU Core used in emulation. auto will switch to dynamic if available and
#            appropriate.
#            Possible values: auto, dynamic, normal, simple.
#   cputype: CPU Type used in emulation. auto is the fastest choice.
#            Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 386_prefetch.
#    cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#            Setting this value too high results in sound dropouts and lags.
#            Cycles can be set in 3 ways:
#              'auto'          tries to guess what a game needs.
#                              It usually works, but can fail for certain games.
#              'fixed #number' will set a fixed amount of cycles. This is what you usually
#                              need if 'auto' fails (Example: fixed 4000).
#              'max'           will allocate as much cycles as your computer is able to
#                              handle.
#            Possible values: auto, fixed, max.
#   cycleup: Amount of cycles to decrease/increase with keycombos.(CTRL-F11/CTRL-F12)
# cycledown: Setting it lower than 100 will be a percentage.

core=dynamic
cputype=auto
cycles=max
cycleup=10
cycledown=20

[mixer]
#   nosound: Enable silent mode, sound is still emulated though.
#      rate: Mixer sample rate, setting any device's rate higher than this will probably lower their sound quality.
#            Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
# blocksize: Mixer block size, larger blocks might help sound stuttering but sound will also be more lagged.
#            Possible values: 1024, 2048, 4096, 8192, 512, 256.
# prebuffer: How many milliseconds of data to keep on top of the blocksize.

nosound=false
rate=44100
blocksize=1024
prebuffer=20

[midi]
#     mpu401: Type of MPU-401 to emulate.
#             Possible values: intelligent, uart, none.
# mididevice: Device that will receive the MIDI data from MPU-401.
#             Possible values: default, win32, alsa, oss, coreaudio, coremidi, none.
# midiconfig: Special configuration options for the device driver. This is usually the id of the device you want to use.
#               or in the case of coreaudio, you can specify a soundfont here.
#               When using a Roland MT-32 rev. 0 as midi output device, some games may require a delay in order to prevent 'buffer overflow' issues.
#               In that case, add 'delaysysex', for example: midiconfig=2 delaysysex
#               See the README/Manual for more details.

mpu401=intelligent
mididevice=default
midiconfig=

[sblaster]
#  sbtype: Type of Soundblaster to emulate. gb is Gameblaster.
#          Possible values: sb1, sb2, sbpro1, sbpro2, sb16, gb, none.
#  sbbase: The IO address of the soundblaster.
#          Possible values: 220, 240, 260, 280, 2a0, 2c0, 2e0, 300.
#     irq: The IRQ number of the soundblaster.
#          Possible values: 7, 5, 3, 9, 10, 11, 12.
#     dma: The DMA number of the soundblaster.
#          Possible values: 1, 5, 0, 3, 6, 7.
#    hdma: The High DMA number of the soundblaster.
#          Possible values: 1, 5, 0, 3, 6, 7.
# sbmixer: Allow the soundblaster mixer to modify the DOSBox mixer.
# oplmode: Type of OPL emulation. On 'auto' the mode is determined by sblaster type. All OPL modes are Adlib-compatible, except for 'cms'.
#          Possible values: auto, cms, opl2, dualopl2, opl3, none.
#  oplemu: Provider for the OPL emulation. compat might provide better quality (see oplrate as well).
#          Possible values: default, compat, fast.
# oplrate: Sample rate of OPL music emulation. Use 49716 for highest quality (set the mixer rate accordingly).
#          Possible values: 44100, 49716, 48000, 32000, 22050, 16000, 11025, 8000.

sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=default
oplrate=44100

[gus]
#      gus: Enable the Gravis Ultrasound emulation.
#  gusrate: Sample rate of Ultrasound emulation.
#           Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#  gusbase: The IO base address of the Gravis Ultrasound.
#           Possible values: 240, 220, 260, 280, 2a0, 2c0, 2e0, 300.
#   gusirq: The IRQ number of the Gravis Ultrasound.
#           Possible values: 5, 3, 7, 9, 10, 11, 12.
#   gusdma: The DMA channel of the Gravis Ultrasound.
#           Possible values: 3, 0, 1, 5, 6, 7.
# ultradir: Path to Ultrasound directory. In this directory
#           there should be a MIDI directory that contains
#           the patch files for GUS playback. Patch sets used
#           with Timidity should work fine.

gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND

[speaker]
# pcspeaker: Enable PC-Speaker emulation.
#    pcrate: Sample rate of the PC-Speaker sound generation.
#            Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#     tandy: Enable Tandy Sound System emulation. For 'auto', emulation is present only if machine is set to 'tandy'.
#            Possible values: auto, on, off.
# tandyrate: Sample rate of the Tandy 3-Voice generation.
#            Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#    disney: Enable Disney Sound Source emulation. (Covox Voice Master and Speech Thing compatible).

pcspeaker=true
pcrate=44100
tandy=auto
tandyrate=44100
disney=true

[joystick]
# joysticktype: Type of joystick to emulate: auto (default), none,
#               2axis (supports two joysticks),
#               4axis (supports one joystick, first joystick used),
#               4axis_2 (supports one joystick, second joystick used),
#               fcs (Thrustmaster), ch (CH Flightstick).
#               none disables joystick emulation.
#               auto chooses emulation depending on real joystick(s).
#               (Remember to reset dosbox's mapperfile if you saved it earlier)
#               Possible values: auto, 2axis, 4axis, 4axis_2, fcs, ch, none.
#        timed: enable timed intervals for axis. Experiment with this option, if your joystick drifts (away).
#     autofire: continuously fires as long as you keep the button pressed.
#       swap34: swap the 3rd and the 4th axis. can be useful for certain joysticks.
#   buttonwrap: enable button wrapping at the number of emulated buttons.

joysticktype=auto
timed=true
autofire=false
swap34=false
buttonwrap=false

[serial]
# serial1: set type of device connected to com port.
#          Can be disabled, dummy, modem, nullmodem, directserial.
#          Additional parameters must be in the same line in the form of
#          parameter:value. Parameter for all types is irq (optional).
#          for directserial: realport (required), rxdelay (optional).
#                           (realport:COM1 realport:ttyS0).
#          for modem: listenport (optional).
#          for nullmodem: server, rxdelay, txdelay, telnet, usedtr,
#                         transparent, port, inhsocket (all optional).
#          Example: serial1=modem listenport:5000
#          Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial2: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial3: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, directserial.
# serial4: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, directserial.

serial1=dummy
serial2=dummy
serial3=disabled
serial4=disabled

[dos]
#            xms: Enable XMS support.
#            ems: Enable EMS support. The default (=true) provides the best
#                 compatibility but certain applications may run better with
#                 other choices, or require EMS support to be disabled (=false)
#                 to work at all.
#                 Possible values: true, emsboard, emm386, false.
#            umb: Enable UMB support.
# keyboardlayout: Language code of the keyboard layout (or none).

xms=true
ems=true
umb=true
keyboardlayout=none

[ipx]
# ipx: Enable ipx over UDP/IP emulation.

ipx=false

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
Notes: Building against the dispmanx SDL should improve graphics performance when scaling higher resolutions (and avoid the problems with the screen being left in a non working state)

running dosbox on the framebuffer without dispmanx SDL has some issues. it can crash on exit, or leave the screen in an unusable state. No doubt this is linked to SDL code incompatibility with the pi framebuffer - I am currently looking into that.

you can use something like Dhrystone from

http://www.roylongbottom.org.uk/oldones ... orBenchDOS

to benchmark it (change config between core=dynamic / core=normal to see a difference)

I decided to look into all this due to the "fastdosbox" source not seeming all that fast. Turns out, there is nothing in the fastdosbox released source really much different from the core dosbox code - it just requires knowing how to enable the dynamic recompilation.

I will be adding an SVN build of dosbox into RetroPie also.

Hope this is useful to someone.
Last edited by exobuzz on Fri Jan 02, 2015 12:57 am, edited 2 times in total.

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Thu Jan 01, 2015 10:20 pm

Ammended the configuration to have "scaler=normal2x" rather than "scaler=none". This is more compatible with framebuffer output - but if running with dispmanx sdl this should be scaler=none so SDL dispmanx does the scaling

RoyLongbottom
Posts: 489
Joined: Fri Apr 12, 2013 9:27 am
Location: Essex, UK

Re: compiling dosbox with dynamic recompilation support

Fri Jan 02, 2015 10:42 am

Following provides access to benchmark source code for RPi, including Dhrystone and comparative results

http://www.roylongbottom.org.uk/Raspber ... hmarks.htm

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Fri Jan 02, 2015 11:34 am

thanks :) interesting/useful site you have.

Some more information regarding performance with normal vs dynamic core:

I ran doom with default settings at "-timedemo demo3". With the normal core, it did 1.55 FPS. With the dynamic recompilation core, it did 4.16 FPS which is a decent improvement

rpix86 was faster again and did around 8fps

dudleydes
Posts: 51
Joined: Sun May 18, 2014 12:19 pm

Re: compiling dosbox with dynamic recompilation support

Tue Jan 13, 2015 1:59 pm

Thank you for this version of DOSBox. I played around with DOSBox and FastDosBox on the pi before Christmas. I found that neither seemed to be able to handle the scaler being set to normal2x and the use of a mapper file at the same time. I was presented with a black screen but I could hear audio so the game was still running. With this new build with dispmanx enabled to handle the scaling, the mapper file works fine with my game controller.

One small issue. When DOSBox launches, a config file dosbox-0.74.conf is created in the .dosbox folder. It appears that this is the one that DOSBox uses, not the dosbox-svn.conf file created during Retropie configuration. I know this because DOSBox produces the following line in the console.

Code: Select all

CONFIG:Loading primary setting from config file /home/pi/.dosbox/dosbox-0.74.conf
The trouble here is that the keyboard is messed up because in the default dosbox-0.74.conf file, usescancodes in the sdl section is set to true. It needs to be changed false for the keyboard to work on the pi.

There isn't an issue here that really needs to be fixed here but I wanted to bring it to your attention. I imagine many people using DOSBox as part of Retropie will want to use game controllers to auto launch games as well as play them. In which case, it's probable that each game will require its own custom config file that directs DOSBox to the custom mapper file.

I am planning to publish a series of tutorials on setting up custom config and mapper files for DOSBox within Retropie. I want to make sure that I have the correct info so please let me know if you intend on making any changes.

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Tue Jan 13, 2015 2:04 pm

if you built it from svn it should use the svn config naming - the retropie one does use this config (please report stuff related to retropie on the retropie issues tracker). You sure you are running the right dosbox ? sounds like you might be running a preinstalled debian one or something. please paste the output when running dosbox.

dudleydes
Posts: 51
Joined: Sun May 18, 2014 12:19 pm

Re: compiling dosbox with dynamic recompilation support

Tue Jan 13, 2015 2:27 pm

I updated the Retropie binaries over the weekend and dosbox binary I am using is dated Jan 3 22:50.

The output from DOSBox was

Code: Select all

DOSBox version 0.74
Copyright 2002-2010 DosBox Team published ubder GNU GPL
---
CONFIG:Loading primary setting from config file /home/pi/.dosbox/dosbox-0.74.conf
"dynamic" is not a valid value for variable: core
It might now be reset it to default value: auto
ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
MIDI:Opened device:none
One joystick reported, initializing with 4 axis
Using joystick SONY Computer Entertainment Wireless Controller with 27 axes, 19 buttons and 0 hats(s)
MAPPER: Loading mapper settings from /home/pi/.dosbox/mapper-0.74.map

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Tue Jan 13, 2015 2:30 pm

that is not the svn compiled dosbox. you are launching another one. you probably have the debian package still installed. It also does not have the dynamic recompilation core enabled.

retropie dosbox build lives in /opt/retropie/emulators/dosbox/bin/dosbox

if you are manually launching from console you may be loading a debian one from /usr/bin/dosbox (especially if you are just typing "dosbox" to launch).

dudleydes
Posts: 51
Joined: Sun May 18, 2014 12:19 pm

Re: compiling dosbox with dynamic recompilation support

Tue Jan 13, 2015 2:41 pm

I was indeed using just dosbox to launch. I have changed the command to /opt/retropie/emulators/dosbox/bin/dosbox in my shell script and the SVN version is now being used. Thanks for clearing this up.

AmigaGamer
Posts: 94
Joined: Sat Feb 01, 2014 9:02 pm

Re: compiling dosbox with dynamic recompilation support

Sun Feb 15, 2015 10:07 pm

Original post was made for Raspberry PI 1 compiling with ARMV4LE

I Compiled this on Raspberry PI 2 , It works well with the following defines using ARM7

#define C_DYNREC 1
#define C_TARGETCPU ARMV7LE
#define C_UNALIGNED_MEMORY 1

in dosbox.conf use

core=dynamic

also compiling with CFLAGS="-march=armv7-a -mfpu=neon-vfpv4"

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Sun Feb 15, 2015 10:52 pm

ah yeh, good point - I had forgotten it had some arm7 optimisations. Should provide some further performance improvement - I'll update the retropie script. thanks.

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Sun Feb 15, 2015 11:53 pm

~16.5 fps on doom (-timedemo demo3) - an increase of 3-4 fps. Pretty decent :) (this is on an overclocked rpi2 @1ghz)

User avatar
7F20
Posts: 95
Joined: Tue Jul 24, 2012 2:45 am
Location: New York

Re: compiling dosbox with dynamic recompilation support

Sat Mar 28, 2015 6:13 am

Hi,
I'm having no luck at all getting stuff to run.
I tried scummvm, and I can't get it to compile, then I tried ripx86 and it works, but it seems choppy and the sound is broken and weird.
So then I tried to compile this and I got Makefile:310 recipe for target 'callback.o' failed, 330:'all-recursive', 353: 'all-recursive', 301, 241 all failed.
I followed all your instructions, i even setup svn and used it to checkout, etc.
any clues to what i'm doing wrong?
I'm running a raspi 2.
everything is updated.
I have regular sdl.

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Sat Mar 28, 2015 2:17 pm

no sorry - maybe with a full log it might shed some light.

If you don't want the hassle of compiling, you can use RetroPie script to install individual emulators to the system from binary (or source).

User avatar
7F20
Posts: 95
Joined: Tue Jul 24, 2012 2:45 am
Location: New York

Re: compiling dosbox with dynamic recompilation support

Sat Mar 28, 2015 4:19 pm

exobuzz wrote:no sorry - maybe with a full log it might shed some light.

If you don't want the hassle of compiling, you can use RetroPie script to install individual emulators to the system from binary (or source).
will RetroPie give me the faster performance?

It is a little frustrating, but I want to learn. I am trying my best as someone who doesn't really know linux.
I can start over with the SD card from scratch, I suppose.
Do you have a suggested sources.list?
I have some stuff in there, but I could be missing something important.

Also, I read in Vanfanel's Scummvm post that he wants you to use stock Raspbian SDL, but you say use dispmanX sdl for dosbox. will this cause a conflict in trying to do both your dosbox compile and his scummvm compile?

Vanfanel
Posts: 531
Joined: Sat Aug 18, 2012 5:58 pm

Re: compiling dosbox with dynamic recompilation support

Sat Mar 28, 2015 4:22 pm

Don't use my modified SDL with dispmanx backend. Implement a dispmanx backend instead.
My modified SDL 1.x libs block until vsync arrives, which makes them unsuitable for emulators really. That's why I started releasing stuff with a non-blocking update algorithm (Giana's, Scummvm...).

exobuzz
Posts: 140
Joined: Mon Nov 26, 2012 6:58 pm

Re: compiling dosbox with dynamic recompilation support

Sat Mar 28, 2015 4:37 pm

RetroPie has a single sdl library with code based on vanfanel's sdl dispmanx but also with standard fbcon support and other fixes. So you can decide if you want tear free, but blocking dispmanx or framebuffer. dosbox works fine with the fbcon driver though, so use that. Performance will be worse with the dispmanx backend as vanfanel mentioned.

User avatar
7F20
Posts: 95
Joined: Tue Jul 24, 2012 2:45 am
Location: New York

Re: compiling dosbox with dynamic recompilation support

Sun Mar 29, 2015 2:10 am

exobuzz wrote:RetroPie has a single sdl library with code based on vanfanel's sdl dispmanx but also with standard fbcon support and other fixes. So you can decide if you want tear free, but blocking dispmanx or framebuffer. dosbox works fine with the fbcon driver though, so use that. Performance will be worse with the dispmanx backend as vanfanel mentioned.
Ok, I'll try that. I got Scummvm working, so I am now somewhat hesitant to go reflashing my SD card.

I am a little worried that I have something screwed up on my image because I can't get your dosbox to compile. Shouldn't it pretty much work the same on all Raspis?
I must be missing some dependency or something.

Thanks for the input and Info. And thanks again Vanfanel for helping me out with flac problem. :)

Vanfanel
Posts: 531
Joined: Sat Aug 18, 2012 5:58 pm

Re: compiling dosbox with dynamic recompilation support

Sun Mar 29, 2015 5:47 pm

I will eventually add non-blocking dispmanx support to dosbox without the need of my sdl 1.x version. I want to see how smooth can it get with the Pi1 and Dosbox running on non-blocking vsync-ed display.

User avatar
7F20
Posts: 95
Joined: Tue Jul 24, 2012 2:45 am
Location: New York

Re: compiling dosbox with dynamic recompilation support

Sat Apr 04, 2015 5:54 am

exobuzz wrote:RetroPie has a single sdl library with code based on vanfanel's sdl dispmanx but also with standard fbcon support and other fixes. So you can decide if you want tear free, but blocking dispmanx or framebuffer. dosbox works fine with the fbcon driver though, so use that. Performance will be worse with the dispmanx backend as vanfanel mentioned.
Hi exobuzz,

I went back to Dosbox because I couldn't get Scummvm to output at the correct aspect through a composite video source.

I actually managed to compile you dosbox and run it, but I am running into some issues.
I can only launch it in X, and it won't let me fullscreen. It says "to error: Could not set fullscreen video mode 640x400-32: No video mode large enough for 640x400"

I would like to use dosbox in console, butif I have to use X, it'd be nice to get it fullscreen.

Also, it works fine through HDMI. I had some issues with the aspect correction when going into dosbox and I had to change the dosbox.conf file to aspect=true, and it seems to correct.
It's behavior is weird though; when the red dosbox logo lauches, it cuts off the top and the bottom of the screen and then when it jumps into the console, it corrects the aspect.
Without the aspect correct, it just stays in the cut-off region.
I am also having some speed issues. I am trying to play Spycraft, and it runs, but it gets slow sometimes.
Fallout will launch, but it hangs on the opening loading screen. (I followed the suggestions I found online about getting it to run in dosbox including setting the memsize=32, didn't help)

AmigaGamer
Posts: 94
Joined: Sat Feb 01, 2014 9:02 pm

Re: compiling dosbox with dynamic recompilation support

Fri Apr 10, 2015 2:36 pm

this could be interesting.....SDL2 patch

http://www.vogons.org/viewtopic.php?f=3 ... 0&start=20

latest version of the patch here
http://www.vogons.org/download/file.php?id=15194

needs some fixing for the latest SVNs, bit of code rejected on patching sdl_mapper.cpp and sdl_main.cpp

AmigaGamer
Posts: 94
Joined: Sat Feb 01, 2014 9:02 pm

Re: compiling dosbox with dynamic recompilation support

Fri Apr 10, 2015 5:59 pm

Managed to get ny00123's patch working now with SVN3910 and ran a quick diff -rupN against it.
This should patch ok if anyones interested in testing https://www.dropbox.com/s/xfls4y8ext7hp ... patch?dl=0

run autogen.sh after patching to update the configure scripts with the sdl2 stuff.

Im configuring with ./configure --with-sdl2 --disable-opengl --prefix=/home/pi/dosbox

in the dosbox-CVS.conf im using the following [sdl] screen settings to get things started.

Code: Select all

fullscreen=true
vsync=false
fullresolution=0x0
windowresolution=original
output=texture
renderer=auto
autolock=true
sensitivity=100
waitonerror=true
Testing this all out now with dynarec enabled on PI2. I haven't benchmarked or tested different settings yet

User avatar
ulysess
Posts: 311
Joined: Thu Aug 02, 2012 6:35 am
Location: Spain

Re: compiling dosbox with dynamic recompilation support

Fri Apr 17, 2015 12:20 pm

Please, share the binary to us!
:)
AmigaGamer wrote:Managed to get ny00123's patch working now with SVN3910 and ran a quick diff -rupN against it.
This should patch ok if anyones interested in testing https://www.dropbox.com/s/xfls4y8ext7hp ... patch?dl=0

run autogen.sh after patching to update the configure scripts with the sdl2 stuff.

Im configuring with ./configure --with-sdl2 --disable-opengl --prefix=/home/pi/dosbox

in the dosbox-CVS.conf im using the following [sdl] screen settings to get things started.

Code: Select all

fullscreen=true
vsync=false
fullresolution=0x0
windowresolution=original
output=texture
renderer=auto
autolock=true
sensitivity=100
waitonerror=true
Testing this all out now with dynarec enabled on PI2. I haven't benchmarked or tested different settings yet
  • PiKISS for Raspberry Pi: https://github.com/jmcerrejon/PiKISS
  • Blog: https://misapuntesde.com/
  • Patreon: https://www.patreon.com/cerrejon?fan_landing=true
  • Twitter: https://twitter.com/ulysess10
  • Discord: https://discord.gg/Y7WFeC5

IBM Portable PC
Posts: 46
Joined: Sun Apr 26, 2015 10:18 am
Location: Melbourne, Australia

Re: compiling dosbox with dynamic recompilation support

Wed May 31, 2017 2:24 am

Apologies for necroposting, however I had no trouble installing DOSbox SVN, as per this thread, however for me DOSbox SVN runs slower than the standard version of DOSbox.

This includes from the console and via SSH with X forwarding.

I cannot imagine why this is the case, however the performance difference is very obvious.

Return to “Gaming”