| dosbox.conf property | Explanation | Desktop DOSBox | n0p’s port |
| [sdl] section (Screen and keyboard) : fullscreen=false | Start dosbox directly in fullscreen. | + | - (always runs in full screen mode, regardless of the mode) |
| fulldouble=false | Use double buffering in fullscreen. | + | - (!) (didn’t see any difference in speed) |
| fullresolution=original | What resolution to use for fullscreen: original or fixed size (e.g. 1024x768). | + | - (always runs in 320*240, independent of this setting. That is, it can be virtually anything.) |
| windowresolution=original | Scale the window to this size IF the output device supports hardware scaling. | + | - |
| output=surface | What to use for output: surface, overlay, opengl, openglnb, ddraw. | + | - (!)(didn’t see any difference in speed between the different settings; OpenGL didn’t result in depixelization, not even on the OpenGL ES-enabled Dell Axim x51v) |
| autolock=true | Mouse will automatically lock, if you click on the screen. | + | - (always locked – there’re no other windows / hovering mouse) |
| sensitivity=100 | Mouse sensitivity. | + | - (no meaning in a stylus-based, non-hovering environment; the two mouse emulation modes (touchpad & D-pad modes) have their own sensitivity settings, see below) |
| waitonerror=true | Wait before closing the console if dosbox has an error. | + | - (no console) |
| priority=higher,normal | Priority levels for dosbox: lowest, lower ,normal, higher, highest, pause (when not focussed). Second entry behind the comma is for when dosbox is not focused/minimized. | + | + (?) |
| mapperfile=mapper.txt | File used to load/save the key/event mappings from. | + | ? (at least Wall’s version 1.1 supports this – other DOSBox ports don’t have an external mapper file) |
| usescancodes=true | Avoid usage of symkeys, might not work on all operating systems. | + | n/a (doesn’t exist) |
| hwscale=1.00 | Extra scaling of window if the output device supports hardware scaling. | n/a | |
| n0p mouse emulation-related subgroup (also see the uppermost section HERE): dpadmouse=false | Mouse cursor directed by D-pad like on mouse- and analogue control-less gaming consoles or computers like the NES or the c64 without the mouse in, say, GEOS | n/a | +; Only enable it if neither the other two touchscreen-based mouse methods work (for example, in DOTT) |
| dpadmousespeed=8.00 | Speed of D-pad-controlled mouse cursor | n/a | + |
| tpadmode=true | Touchpad mode; by default, enabled. Instead of absolute screen positions, it uses relative ones. That is, if the traditional, always-enabled mouse doesn’t work, you can still (try to) move the cursor on the screen by keeping down the stylus and moving it, dragging the mouse cursor along; use a single tap for (left-)clicks. It’s much more awkward than just clicking the screen but is still better (in games where it does work OK) than D-pad based mouse emulation. | n/a | + |
| tpadspeed=3.00 | Speed of mouse emulation in touchpad mode. Has no effect on the two other mouse modes, of course. | n/a | + |
| n0p keyboard-related subgroup: the first four entries (dpadup, dpaddown, dpadleft, dpadright) | These entries contain the kets on the numeric keypad on a standard IBM PC keyboard. Dpaddown has a value of 85, which is mapped to the KBD_kp2 key on the keyboard – that is, 2 (down) on the numeric keypad (kp stands for keypad). The other three directions are similarly set. See THIS for a complete list (it also applies to the rest of this section). | n/a | + |
| dpadconfirm | KBD_enter; that is, the Action button on the D-pad is connected to Enter, as one would expect | n/a | + |
| hwkey1..4 | The four hardware buttons. They are assigned to 49, 53, 56 and 54; that is, Escape, space, left Ctrl and left Alt. | n/a | + |
| n0p mouse button-related subgroup: dpadconfirm_ma=1 | This subgroup defines what mouse buttons are clicked when a given hardware button (D-Pad’s Action and the four hardware buttons) is pressed. 1 stands for the left, 2 for the right and 3 for the center button and 0 while not assigned to anything. dpadconfirm_ma=1, therefore, means pressing Action will (also – in addition to simulating pressing Enter) result in an emulated left click. | n/a | + |
| hwkey1_ma =0, hwkey2_ma =0 | Pressing the first two hardware buttons (by default assigned to Esc and Space) doesn’t result in an additional mouse event (0: disabled, not assigned) | n/a | + |
| hwkey3_ma=2, hwkey4_ma=3 | Pressing the third hardware button emulates a right click; the fourth emulates a click with the center button. | n/a | + |
| n0p’s GFX Output options subgroup: directgapi=true | Improves speed of graphics output. Works on VGA too, albeit, IMHO, it doesn’t deliver vastly improved results. It’s the best to keep it enabled. For example, the x51v (A12 ROM) doesn’t even start without it enabled. Only disable it if you DO encounter the app’s inability to start at all (as is the case with the GAPI hacked WM2003SE Dell Axim x50v) and you don’t want to uninstall the GAPI hack. | n/a | + |
| lefthand=false | This enables left-hand Landscape mode (instead of the default right-hand one). Note that, in some occassions, it has not worked on some of my PPC’s – they stayed using the right-hand mode. The same may happen to you. In other cases, right-hand landscape worked great on my iPAQ 2210 and iPAQ hx4700. | n/a | + |
| n0p’s Forced on-screen keyboard options subgroup: | This (where you should click or what button you should press in order to either bring up or maximize the on-screen SIP’s) is pretty well explained in the official documentation, therefore, I don’t explain it in here. | n/a | + |
| n0p’s Toolbars subgroup: | n0p’s app supports manually editable toolbars. If you don’t need a non-English keyboard or, for example, don’t want to, say, create an on-screen D-pad (as can be seen – even if it doesn’t work – in Wall’s version 2), you most probably won’t need to touch this section (neither will you need to download the Toolbar Editor). Note that there’re already at least a Russian on-screen downloadable & deployable keyboard file for the emulator. See THIS for more information on the editor. | n/a | + |
| [cpu] section: core=verysimple | This is by far the most important section (unless you want to redefine hardware buttons / mouse (button) emulation). It lets you select a core (which has a considerable impact on the emulation speed). The two, by the author, most recommended cores are the default and, in general, most recommended ‘verysimple’. The other one is ‘full’, but you will need it very rarely (if ever). The former “only” emulates 80286 (and lower) CPU’s and delivers the best speed; the latter also emulates 80386 and 80486 at a reduced (the speed hit is about 40%) speed. As very few 80386+-only games are actually playable (fast enough) on current Windows Mobile devices, you will want to keep it as ‘verysimple’ and just ignore 386+ games. Note that while the author doesn’t recommend the default ‘normal’ core, I’ve found it a bit faster than ‘full’. Therefore, if you still want to run 386+ apps, you may want to give a try to the ‘normal’ core first. Also see THIS desktop-related (!) explanation. | + | + |
| cyclesmax=3000 | By default, the emulator uses automatic cycle settings. This, in most cases, is the most optimal solution (you don’t need to fuss with the manual optimization as is described for example HERE, in the “STEP 3 - Performance” section), as opposed to setting it manually. Some people recommend to switch to manual mode sometimes; see for example Damien's remark at the top of THIS page. I’ve made a LOT of tests to find out whether the stuttering in, say, Xanth or Gateway 2 can be fully eliminated. The answer is no – even when running the CPU at about 40-50% usage, the stuttering remained at the same intervals as at the ~95% CPU usage of automatic mode. When running in automatic mode, the other parameters (cycles, cycleup and cycledown) will have no effect as you won’t be able to in/decrease the cycle emulation at all (cycleup / cycledown) manually and the system will always use the most optimal, still-emulable cycles and will, therefore, also ignore the original ‘cycles’ parameter Your mileage may vary, though. | + | + |
| [mixer] section: nosound=false | Generic sound issues – sets common parameters of all subsequent sections. nosound dis/enables sound; it’s enabled by default. | + | + |
| rate=11025 | The sampling rate. | + | ? |
| blocksize=256 | According to the official docs, “Mixer block size, larger blocks might help sound stuttering but sound will also be more lagged.” With n0p’s app, however, it has no effect at all – that is, don’t try to set it to a (much) higher value to reduce stuttering. | + | - |
| [midi] and [gus] section: mpu401=false and gus=false | This en/disables midi emulation. It isn’t supported in n0p at all; hence the ‘false’ (don’t bother with setting it to true – it will NOT work). It, on the other hand, works just great with the desktop version and should be preferred over Adlib / SB. BTW, the same (not supported) stands for the Gravis emulation ([gus] section). | + | - |
| [sblaster] section: | Sound Blaster emulation – the only sound/music-related emulation that DOES work in n0p’s emulator (in addition to, of course, the beeper emulation; see the [speaker] section). The parameters here (IRQ, DMA etc) speak for themselves and, in general, shouldn’t be modified. | + | + |
| [dos] section: xms=true and ems=true | By default, DOSBox (and n0p’s port) emulates both memory types at the same type, using exactly the same memory, going up to 16 Mbytes at most. In this, it’s far more flexible than PocketDOS, which not only uses these memory types exclusively, but also can’t go over 6-7 Mbytes in practice. The amount of memory used as EMS / XMS is set by the ‘memsize’ parameter in the [dosbox] section. | + | + |
| [dosbox] section: machine=vga | This parameter sets the display type to be emulated. It can be handy in some cases:you want to compare the rendition difference between the different display typesyou need to force your application auto-detecting EGA/VGA devices to use CGA graphics. In cases, this may be preferable – for example, with games otherwise not playable because of the low-resolution rendition. Using a forced CGA mode, for example, results in the first-generation Legend Entertainment games becoming pretty readable as can also be seen in this screenshot. (Compare it to THIS screenshot, showing the same using the original EGA resolution! See the point in sticking to the, compared to EGA, low-resolution two-color (640*200) CGA mode?) | + | + |
| captures=capture | This parameter, in the desktop version, sets the directory where screenshots (Ctrl-F5) and audio clips (Ctrl-F5) are stored (on the desktop, it’s in the home directory of the app itself; that is, \Program Files\DOSBox-0.70\capture\). In n0p’s port, however, taking snapshots don’t work at all: neither screenshots nor music WAV or MIDI files. Don’t even bother trying to make shots. | + | - |
| memsize=4 | The full RAM memory consumption (the lower 1M + the rest). 16M max. This means if you leave it at the default 4, you’ll have 2990 kbytes of XMS/EMS. Note that some people will (incorrectly) state the value here ONLY sets the value of XMS/EMS memory. Not that it would count, however: 15 Mbytes are more than enough for any DOS-based and still playable apps, as opposed to the far worse memory handling of PocketDOS. | + | + |
| [render] section: frameskip=4 | This group sets parameters related to rendering on screen. The ‘frameskip’ parameter is probably the most important parameter. You, however, won’t want to modify it right in the config file: after clicking the Settings icon on the upper left corner of the numeric keypad, you’re taken to the Settings pad, where you can just in/decrease the frame skips with using the increase/decrease arrows. The more frameskips, the less CPU load but the more stuttering graphics. That is, try to find the best optimum; it; with most games, is around 3-4-5 frameskips. Note that, after the frameskip value of 6, the additional CPU gain becomes really minimal (I’ve thoroughly tested this); that is, you won’t want to use larger frameskips than, say, 6. | + | + |
| scaler=none | With n0p’s app, you don’t need to touch this. It’s only with Wall’s 1.1 running on VGA devices that it’s worth giving it a value of normal2x to render low-res (320*200) games stretched to double the size and, therefore, (horizontally) filling in the screen. | + | - |
| [autoexec] section: | To avoid having to manually mount your storage card(s) every time you restart DOSBox, it’s very important that you place mount (and drive change) commands here as in, say, mount c "\cf card\"
c: | + | + |
