DOSBox will always run slower than DOSEMU.

You don't want DOS games to run too fast otherwise you'll experience issues with the games.

How about you list the games you are having issues with, post what version of DOSBox you are using, post the contents of your dosbox.conf and finally post your system specs?

Most likely you are running DOSBox on a machine that could probably run MS-DOS just fine so you are probably using a P3 or similar so most likely that's why you are complaining about the speed of games in DOSBox. (It's generally recommended to use a C2D or above for any DOS games newer than 1995 if you are using DOSBox)

For DOSEMU questions ask on the DOSEMU forum.

Blood (monolith) runs slow and causes a bad gameplay. The character moves slow. (resolution: 640x480 vesa mode)
I'm using the last version (0.74).

Here is my config file: [sdl] # fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go back) # full […]
Show full quote

Here is my config file:
[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 or 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, opengl, openglnb.
# 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 defaul value.
# usescancodes: Avoid usage of symkeys, might not work on all operating systems.

fullscreen=false
fulldouble=false
fullresolution=640x480
windowresolution=original
output=opengl
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true

[dosbox]
# language: Select another language file.
# machine: The type of machine 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=17

[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=true
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 keycombo.(CTRL-F11/CTRL-F12)
# cycledown: Setting it lower than 100 will be a percentage.

core=auto
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.
# 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.
# umb: Enable UMB support.
# keyboardlayout: Language code of the keyboard layout (or none).

xms=true
ems=true
umb=true
keyboardlayout=auto

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

This is my proccesor: AMD Athlon(tm) XP 2000+
Memory: 623.27 MiB (approximately)

> AMD Athlon(tm) XP 2000+

Too weak for most 640x480 games

If someone knows about sound and music problems from DOSEMU on ubuntu 10.04, I will be at: http://www.forumjar.com/forums/topic/dosemu_m … nd_sound_issues
I will be there for an answer.

Huh, you want something and expect people to follow you to another forum? Tricky forum advertising?
Anyway if YOU are interested in dosemu stuff, do as being told and visit the dosemu forum or mailing list.
But my 2cents: your PC is too weak for either emulator and that game

Dominus wrote:

Huh, you want something and expect people to follow you to another forum? Tricky forum advertising?
Anyway if YOU are interested in dosemu stuff, do as being told and visit the dosemu forum or mailing list.
But my 2cents: your PC is too weak for either emulator and that game

Okay I will use another computer. (if I find one in my stuff)
I wrote that link because there's nobody on dosemu forum, I was the first person there.

There's nobody there because that's not DOSEMU forum.

With those system specs I'd go back to Windows 98SE, myself (easy to get those speeds in native DOS 😁). I ran 98SE on an Athlon XP 2800+ with 768MB RAM for a very long time on a board with a VIA chipset that had good DOS sound compatibility. That's not for everybody though, I suppose.

If you want more modern Windows, XP or 2K would work fine on there and using VDMSound with NTVDM is faster than DOSBox on weak machines.

Finally, if you want Linux (I presume you do since you're talking about DOSEMU), then either use DOSEMU for the games that need it, or more preferably (speedwise) use alternative engines (ports of DOOM, Quake, Abuse, etc. all exist, ScummVM, and more..). For later DOS games many had a Win3x or Win95 version, and those could be run in Wine a bit faster than in DOSBox (API wrapping vs. emulation). Anything that you can't manage to run in one of these ways, DOSEMU or DOSBox is your best bet, as it's likely old enough to run fine anyway.

Oh and Blood in particular - there's a Glide patch/port for that iirc, which could be run via Wine with a glide wrapper, if I'm not mistaken, which would wrap from Glide->Windows OpenGL->Linux OpenGL->Card - convoluted, but an option. Don't remember if it has an OpenGL or D3D version.

or try booting into real dos with a floppy disc

Yushatak wrote:

Oh and Blood in particular - there's a Glide patch/port for that iirc, which could be run via Wine with a glide wrapper, if I'm not mistaken, which would wrap from Glide->Windows OpenGL->Linux OpenGL->Card - convoluted, but an option. Don't remember if it has an OpenGL or D3D version.

The glide version of Blood is a DOS program.

Thanks, I will try some of them.

I'd hate to sound like a noob here, but what's the main difference between DOSEMU and DOSBOX? I know they work differently, but I'm wondering just HOW they work differently. 🤣

mr_bigmouth_502 wrote:

I'd hate to sound like a noob here, but what's the main difference between DOSEMU and DOSBOX? I know they work differently, but I'm wondering just HOW they work differently. 🤣

DOSEMU is more of a virtualizer than an emulator, meaning that most of the operations performed by the DOS program are simply passed on to the host CPU/hardware (with some help from host OS services). Thus providing DOS apps with a "compatibility layer" ensuring they can run on your existing hardware and OS.

DOSBox actually emulates the full environment (including CPU/hardware) completely IN software. Obviously this is much more CPU-intensive, and explains why DOSBox will always run slower than DOSEMU, but also why DOSEMU has problems with things like music (programmed to be played on legacy hardware) while DOSBox can handle it just fine.

this is all in very general terms - it's a little more complex than that, but that's the general difference in approach.

So, in other words, DOSEMU works more like the NTVDM, which probably also explains why there isn't a DOSEMU port for Windows. 🤣

Yup. Also like VMWare and VirtualPC.