New Getting Started guide¶
Due to popular demand, we’ve added a new Getting Started guide to the front page. The guide will teach you how to set up your own DOSBox Staging environment from scratch through easy-to-follow instructions with lots of pretty pictures. It adopts a learn-by-doing approach to ensure you’ll have fun while setting up famous classic DOS games.
Although it’s primarily intended for beginners, we guarantee even our most experienced long-time users will learn a few tricks from it!
Graphics¶
Authentic adaptive CRT emulation¶
We are happy to announce that we’ve removed all CRT shaders previously bundled with our releases.
Every single one of them.
What the @^$*%#!!!?? Have these guys gone mad??!
The reason for removing them is that they got replaced with something far better: a set of no less than 24 CRT shaders tweaked to perfection to emulate the glorious CRT monitors of the past, including authentic recreations of Hercules, CGA, monochrome CGA, composite CGA, EGA, and VGA monitors.
24 new CRT shaders sound a lot—how will someone not intimately familiar with CRT monitor technology and PC history know which is the best for a particular game? Well, the good news is you don’t need to know—DOSBox Staging will automatically pick the most appropriate shader based on the current DOS video mode and viewport resolution. High-DPI and displays from 720p to 4K resolutions are fully supported, and absolutely no manual configuration is required!
The following magic glshader options have been introduced:
crt-auto — This is the new default—an adaptive CRT shader that prioritises developer intent and how people experienced the game at the time of release. This means VGA games will be double-scanned, like on a real VGA monitor, EGA games will appear single-scanned with “fat scanlines”, and so on, regardless of the machine setting.
crt-auto-machine — This one emulates a fixed CRT monitor based on your machine setting. So CGA and EGA modes on a VGA machine will always appear double-scanned with big chunky pixels, just like on a real VGA adapter and monitor.
crt-auto-arcade — This fantasy option does not exist in real life, but it can be a lot of fun! It emulates a 15 kHz arcade or home computer monitor with thick scanlines in low-resolution modes. Perfect for playing DOS VGA ports of Amiga and Atari ST games to experience them with MT-32 or SC-55 sound from a strange parallel universe! 😎
Adaptive CRT shaders work in tandem with the new integer scaling feature to achieve the most optimal results. The default auto setting for integer_scaling auto-enables vertical integer scaling for the adaptive CRT shaders; this avoids unwanted interference patterns that can result from non-integer vertical scaling ratios.
Here are the shaders in action at 4K resolution (make sure to click on the zoomed-in images if the cursor turns into a magnifying glass to view them at 100% magnification):
Gods
320×200 VGA
If you don’t like CRT shaders, no problem—simply set glshader to sharp in your config to regain your sharp little rectangles back. Naturally, you can continue to use regular GLSL shaders like before. The deprecated CRT shaders are still available as a separate download, should you ever need them.
The adaptive shaders are largely based on one of Hyllian’s excellent CRT shaders, so big thanks to him for laying a solid foundation for this feature.
Why were the old CRT shaders removed?
One problem with the previously bundled CRT shaders was that they lacked proper documentation, so it wasn’t clear which shader was meant for what monitor resolution (some were tuned for 1080p, some for 4K, etc.) Moreover, most were designed to emulate arcade monitors or TV sets from the 80s and early 90s; these displays had very different characteristics than the much higher quality PC monitors. Because of all this, many people were rather unimpressed by them and gave up on CRT shaders altogether as a result.
Accurate VGA emulation¶
Previously, DOSBox rendered the emulated VGA output without double scanning, and only in quarter-frame chunks. These optimisation steps were necessary 20 years ago, but now we’re doing proper double scanning and accurate per-scanline rendering in all VGA, SVGA, and VESA video modes. It turns out this only causes a ~7% performance drop on modern hardware in benchmarks, which is not much for such a significant improvement.
Double scanning and per-scanline rendering were available via the special vgaonly machine type before, but that was incompatible with VESA modes and it truncated the 18-bit VGA DAC colour output to 16-bits only, causing banding in certain scenes. We no longer do that either—VGA output is now always rendered at full 18-bit precision.
We use 9×16 fonts on all emulated VGA adapters now which is how most people remember VGA text modes. You can still force 8×16 fonts on VGA by enabling the new vga_8dot_font setting.
These improvements absorb the benefits of vgaonly into the base VGA emulation, making the vgaonly machine type unnecessary, so it has been deprecated (it’s still recognised as an alias for svga_paradise for backward compatibility).
Additionally, all CGA, PCjr, and Tandy text modes are now properly single-scanned when using their respective machine types. A few CGA, PCjr, and Tandy graphics modes appeared with the incorrect aspect ratio before; these have all been fixed up.
The logging of video modes has become a lot more accurate; now we’re consistently logging the video standard the mode first appeared in (e.g., CGA modes are always logged as CGA, regardless of the emulated display adapter in use), and the logged pixel aspect ratios are now always correct.
3dfx Voodoo 1 emulation¶
Aaron Giles’ 3dfx Voodoo emulation originally written for the MAME project has finally found its way into Staging. During its journey, it has picked up a few enhancements, namely a few changes by kekko for the DOSBox integration, plus some multi-threading improvements by Bernhard Schelling (also known as psyraven).
We’ve added support for emulating a Voodoo 1 board with either a 2 MB Frame Buffer Interface (FBI) and one 2 MB Texture Mapping Unit (TMU), or a 4 MB FBI + dual 2x4 MB TMU configuration.
The default refresh rate for the Voodoo is 60 Hz, but it’s possible to force any custom refresh rate via dos_rate.
Please refer to the new [voodoo] config section to learn more.
Low vs high-level emulation
Note this is purely software-based low-level emulation; we’re emulating the 3dfx Voodoo 1 hardware accurately in software, which requires a beefy host CPU. We don’t support high-level emulation where the Glide API calls are transformed and passed through to modern 3D APIs for the actual rendering (e.g., OpenGL, Vulkan, Direct3D, etc.)
New integer scaling modes¶
A new integer_scaling setting has been introduced to constrain the horizontal or vertical scaling factor to integer values when upscaling the image to fit it into the viewport. For example, you can enable vertical integer scaling now with the following config:
[render]
integer_scaling = vertical
The correct aspect ratio will always be maintained, so in this case, the horizontal scaling factor might become fractional. With the sharp shader this is not a problem as the “interpolation band” can only be up to 1 pixel wide at the two sides of the pixels—still plenty sharp, especially on 1440p or 4K. Then with the CRT shaders, non-integer horizontal scaling matters even less; it’s practically a non-issue.
integer_scaling is set to auto by default which only enables vertical integer scaling for the adaptive CRT emulation, otherwise, it’s disabled.
This replaces the so-called “pixel-perfect mode” (openglpp and texturepp output modes) which prioritised 100% sharp pixels at the expense of aspect ratio correctness. That feature had been the source of endless confusion even among experienced users as most of the time it could only approximate the correct aspect ratio, and even that varied semi-randomly based on the current viewport size and monitor resolution. Our reasons for removing it are documented in detail here.
Aspect ratio correct image captures¶
Previously, even if you had aspect ratio correction enabled, the captured screenshots always contained the raw, non-corrected image. This has been flipped around: the new default is capturing images in the same aspect ratio that you see on your screen.
Taking raw and rendered (post-shader) screenshots continues to be an option, of course. The following three image capture formats have been introduced:
upscaled — The image is captured in the same aspect ratio you see on the screen. Upscaled captures always use sharp pixels, regardless of the shader in use.
rendered — Capture the post-rendered, post-shader image—an exact pixel-by-pixel replica of what you see on the screen.
raw — Capture the raw image; this always results in square pixels. So for 320×200 VGA or EGA content, you’ll always get a 320×200 PNG file, no matter what.
You can configure the capture formats of the default screenshot action with the following setting:
[capture]
default_image_capture_formats = upscaled raw
With this setting, two PNG files will be written in raw and upscaled formats whenever you press the Ctrl+F5 image capture hotkey (Cmd+F5 on macOS).
Keybindings for taking single screenshots in specific formats are also available.
Interpolation in upscaled mode
The image is integer or bilinear-sharp upscaled to around 1200 pixels of vertical resolution in the new upscaled capture mode. For example:
320x200 content is upscaled to 1600x1200 (5:6 integer scaling)
640x480 to 1920x1440 (3:3 integer scaling)
640x350 to 1400x1050 (3x vertical and 2.1875x horizontal scaling)
The resulting PNG files are only about 30% bigger than raw screenshots on average. This is a rather small price to pay for aspect ratio correctness.
Aspect ratio correctness, 2023 edition
Fact: most 320×200 and similar low-resolution DOS games absolutely need aspect ratio correction enabled to appear correctly. While some games benefit from forcing square pixels, these only account for about 1-2% of the total DOS gaming catalogue. That’s the reason why DOSBox Staging performs aspect ratio correction out-of-the-box.
The sad reality of the situation today is that the vast majority of 320×200 DOS games are displayed in the wrong aspect ratio with square pixels on various websites and video-sharing services. Emulators that don’t default to aspect ratio correct output and screen captures have undoubtedly contributed to this widespread problem. Aspect ratio correct screen captures by default is our attempt to play our part in remedying the situation, and hopefully reversing it with time.
Raw capture breaking changes
Previously, raw image captures width or height doubled certain DOS video modes. There wasn’t much rhyme or reason to it. Now raw captures always contain the actual emulated DOS framebuffer-level image (e.g., 320×200 modes get captured as 320×200 PNG files, regardless of any other settings).
The only exceptions are the composite CGA, PCjr, and Tandy modes. These modes are a bit special as internally they’re rendered width-doubled to have enough horizontal resolution for representing composite artifacts. Therefore, we write raw image captures of composite modes width-doubled to retain all rendered information (e.g., the 640×200 composite CGA mode will result in a 1280×200 raw image, which might be surprising at first, but it’s intended and correct behaviour).
Supercharged image and video capturing¶
The optimised zlib-ng library has been added to mitigate the video capturing performance hit incurred by our new more accurate VGA emulation approach compared to 0.80.1. In fact, zlib-ng not only makes up the difference but speeds video capturing up by another factor of three (!) versus 0.80.1! This makes a huge difference on older CPUs, but even on fast modern machines, you can now capture videos at higher resolutions without glitches.
Additionally, image capturing is now being performed in multiple background threads. This eliminates emulation micro-pauses and sound glitches even when rapidly spamming the screenshot hotkey. This was a problem even on fast machines with rendered post-shader captures at 4K resolution.
Aspect ratio and viewport enhancements¶
Stretching the image to completely fill the screen has been an often requested feature (e.g., to play text adventures without black bars on the sides). Now we’re giving you not only that but an entirely new mechanism to apply arbitrary aspect ratios, zoom into the DOS content, and even emulate the horizontal and vertical stretch controls of CRT monitors of yore! 😎
The key element of the feature is the new aspect = stretch mode which stretches the image to the extents of the viewport. For example, to make a game completely fill the screen, use the following config:
[sdl]
fullscreen = on
[render]
aspect = stretch
viewport = fit
integer_scaling = off
The second piece of the puzzle is the new relative mode added to the viewport setting (viewport_resolution has been renamed to viewport and moved to the [render] section). In relative mode, the viewport is a 4:3 aspect ratio rectangle fit into the window or screen as the starting point, which is then scaled by the specified horizontal and vertical stretch factors. The resulting viewport is allowed to extend beyond the edges of the window or the screen, so this can be used to “zoom” into the image while forcing arbitrary aspect ratios.
For example, you can aspect ratio correct lazy Hercules conversions that just reused the EGA/VGA assets and make them fill the screen better by zooming in a little. The following example illustrates this in Prince of Persia in Hercules mode:
[render]
aspect = stretch
viewport = relative 112% 173%
integer_scaling = off
You can use the Stretch Axis, Inc Stretch, and Dec Stretch hotkey actions to set the stretching in real-time (unbound by default). The current viewport setting is logged, so you can simply copy it to your config.
This is a fix for the “black vertical bars” video corruption issue seen on a few late 90s games and demos that require Pentium CPUs. Due to some fairly intricate technical details to do with 80-bit x87 FPU emulation, the issue does not manifest in Intel builds, but it does in all non-Intel builds when using the non-dynamic cores.
A non-exhaustive list of affected programs:
Games
Carmageddon (1997)
Motor Mash (1997)
Peter Sampras Tennis (1997)
Demos
Sunflower by Pulse (1997)
Multikolor by kolor (1997)
toontown by kolor (1997)
Multikolor by kolor
Black vertical bars issue
Multikolor by kolor — Black vertical bars issue
Multikolor by kolor
After the fix)
Multikolor by kolor — After the fix
New deinterlacing shader for FMV games¶
Schlocky 90s FMV titles are the guilty pleasure of every true retro-gamer (we’re no different, so zero judging!) Unfortunately, many of these games are plagued by a weird trick: the video footage is often displayed with alternating black “interlace lines”. This just doesn’t look very good on modern ultra-sharp flat screens, and upscaling such content with non-integer scaling ratios often causes very ugly interpolation artifacts.
To restore cosmic balance, we’ve introduced a pair of “deinterlacing” shaders, building upon the work of Ove Kaaven:
misc/fixvideo — This intelligently doubles scanlines that have a black line beneath them. Works well with non-integer scaling ratios.
misc/fixvideo-scanlines — Similar to the first one, but this retains a subtle scanline look to improve the “perceptual resolution” of the video footage. This one absolutely needs vertical integer scaling enabled!
Now you can enjoy your 90s FMV shlock in its full gory glory! 😎
Gods -- 320×200 VGA
With the misc/fixvideo-scanline shader
Other graphics-related changes¶
OpenGL Pixel Buffer Object (PBO) support was dropped to enhance performance and efficiency. This will result in reduced energy use, reduced thermal load, and significantly improved performance on single-board computers, Intel HD Graphics, and AMD APUs.
The keymapper now supports high DPI screens.
We’ve added support for disabling the screen via the clocking mode register. This fixes some visual glitches in Alien Carnage.
A new interpolation/catmull-rom shader has been added. This implements an upscaling method that looks better than the bilinear interpolation option you get with the none shader.
Various monochrome mode fixes & improvements affecting Hercules and monochrome CGA emulation have been made. Most notably, the manual “bright mode” hotkey to toggle between the two monochrome palette variants has been removed. Now the appropriate palette is auto-selected based on whether we’re in a text or graphics mode.
A corner case delayed display regression was fixed in VFR presentation mode. The presentation mode auto-selection criteria have also been refined to achieve optimal results with a wider range of monitor, driver, and operating system combinations.
The legacy surface output mode has been removed. The new fallback option is the texture output mode that automatically selects the best available rendering backend via SDL (a purely CPU-based non-accelerated backend is available too). The preferred and recommended output mode is still OpenGL, as it always has been.
Fixed a regression where some colours had a very subtle greenish tint on emulated VGA adapters. In practice, this was only noticeable on dark neutral grey colours.
Reloading shaders at runtime via the hotkey action now works a lot more reliably.
Nearest-neighbour output modes aren’t treated any differently anymore when determining the default window size.
sRGB GLSL pragmas now work correctly. Somewhat embarrassingly, the sharp shader was advertised to be gamma-correct more than a year ago, but sadly that was never the case—until this fix.
Introduction of the use_npot_texture GLSL pragma to request non-power-of-two-texture.
Introduction of the force_single_scan and force_no_pixel_doubling GLSL pragmas to force no line doubling and no pixel doubling in VGA modes, respectively. This might come in handy for certain shaders that need to work on the “raw” pixel data, such as upscalers.
We’ve changed the VESA BIOS branding to DOSBox Staging (because we can 😎)
Full PR list of graphics-related changes
Sound¶
IBM Music Feature Card support¶
The IBM Music Feature Card is a rare and expensive sound card from the late 1980s. It is mainly supported by early Sierra SCI games and a few others, like Silpheed. Thanks to Loris Chiocca for authoring this originally! See the [imfc] section for further details.
We highly recommend checking out this excellent blog post to learn more about the interesting history of the card.
Game Audio example
Quest for Glory: So You Want to Be a Hero Your browser does not support the element.
The Colonel’s Bequest – Intro 1 Your browser does not support the element.
The Colonel’s Bequest – Intro 2 Your browser does not support the element.
The Colonel’s Bequest – Intro 3 Your browser does not support the element.
Roland MT-32 ROM handling improvements¶
We have moved from the fiddly and error-prone filename-based Roland MT-32/CM-32L ROM lookup mechanism to checksum-based detection. It’s no longer necessary to get the ROM filenames right; you can chuck all of them into your mt32-roms folder—DOSBox Staging will do the rest! Valid ROMs are identified by their checksums (hashes) at runtime. Both interleaved (mt32pi style) and non-interleaved (MAME style) ROM files are supported.
As a result, the old “versioned” vs “unversioned” ROM differentiation doesn’t make sense anymore. The mt32 and cm32l model types now behave differently: mt32 now selects the first available MT-32 ROM, and cm32l the first available CM-32L ROM (in priority order). Similarly, the mt32_old and mt32_new aliases are not tied to specific version numbers anymore but pick the best available ROMs.
The revised ROM selection method should be backward compatible with the most common use cases—in fact, the new method should generally result in better matches, assuming the same ROM set.
Support for the rare 2.06 and 2.07 MT-32 ROMs and the CM-32LN 1.00 has also been added.
Lastly, we’ve improved the output of the MIXER /LISTMIDI command to make the display of available ROMs and the active ROM much clearer.
Output of the improved MIXER /LISTMIDI command
Output of the improved MIXER /LISTMIDI command
FluidSynth fixes¶
The Roland SC-55 and FluidSynth handle MIDI portamento messages (pitch glides between consecutive notes) very differently. As the rather unique Roland SC-55 portamento cannot be emulated with FluidSynth, music written for the SC-55 that uses it might sound weirdly out of tune on FluidSynth (e.g., the level 8 music of Descent).
All in all, it’s best not to send MIDI portamento messages to FluidSynth at all to avoid the problem completely. The resulting sound is a lot closer to the Roland SC-55’s output.
Additionally, a rather strange sound stage issue has also been fixed by upgrading to the latest FluidSynth library. The panning of some instruments was off-centre, slightly leaning to the left. The problem could be fairly subtle or quite apparent depending on the SoundFont in use, the musical score, and the instruments being played. You can hear it to varying degrees in the “buggy” audio recording below recorded using the previous 0.80.1 DOSBox Staging version.
Descent – Level 8 (SC-55) ¹ Your browser does not support the element.
Descent – Level 8 (FluidSynth buggy) ² Your browser does not support the element.
Descent – Level 8 (FluidSynth fixed) ³ Your browser does not support the element.
¹ Roland Sound Canvas VA in SC-55 mode was used for the recording
² DOSBox Staging v0.80.1 (previous version) with the GeneralUser GS SoundFont
³ Current DOSBox Staging version with the GeneralUser GS SoundFont
Improved MIXER command¶
The MIXER command has been recreated from the ground up to make it a lot more robust and less confusing to use. The main highlights are as follows:
The MIXER command no longer accepts slightly incorrect input; command parsing is now strict and we’re displaying error messages for invalid commands. These messages try to guide the users to correct their mistakes.
MIXER command handling is now “transactional”—if there is a single error in a list of multiple commands, no command is executed but an error for the first problem is raised. This leads to less confusing and more deterministic overall behaviour.
Mixer channels now retain their settings when a channel gets deleted and then re-created later (e.g., by setting sbtype none followed by sbtype sbpro1).
The CMS mixer channel is no longer renamed to GAMEBLASTER when sbtype is set to gb.
MIDI muting improvements¶
Previously, when muting the audio, all MIDI devices were sent Note Off messages, which was problematic with long-held notes in musical scores. You’d get missing notes after unmuting, and the slower the tempo, the more annoying this problem would become.
Muting has been 100% fixed both for the internal Roland MT-32 and FluidSynth MIDI synthesisers and also for external MIDI devices. Technically, we keep feeding external devices with MIDI events in the muted state, but we set all channel volumes to zero when muting, and then restore the volumes when unmuting.
Also, we’re now correctly muting the MIDI output when mute_when_inactive or pause_when_inactive is enabled.
Sanitise MIDI output & Roland RA-50 compatibility¶
The MIDI drivers of many games don’t fully conform to the MIDI standard, which makes editing the MIDI recordings of these games very error-prone and cumbersome in MIDI sequencers, often resulting in hanging or missing notes.
Now DOSBox Staging corrects the MIDI output of such games by default. This results in no audible difference; it only affects the representation of the MIDI data. Specifically, we’re emitting Note Off messages for all active notes when an All Notes Off message is encountered (this is mandated by the MIDI specification, but many games ignore that). There are other Channel Mode Messages that result in an implicit All Notes Off message; these are handled correctly as well.
This incidentally also fixes the infamous hanging notes issue with the Roland RA-50 external MIDI module (the module does not implement the All Notes Off MIDI message).
A new raw_midi_output setting has been introduced to disable this “sanitisation” of MIDI data. That might come in handy if you need to leave the raw MIDI stream unaltered (e.g., when working with music applications, or when debugging MIDI issues).
Optionally fade out hanging notes on Tandy & OPL¶
Some games like Bard’s Tale Construction Set and California Games II suffer from hanging note issues where the notes are not always properly terminated at the end of a musical piece. We’ve introduced an option to fade out the OPL or Tandy sound output after the last IO port write to these audio devices to remedy the situation. See the documentation of the opl_fadeout and tandy_fadeout settings for further details.
CD Audio support on Linux for physical CD-ROMs¶
CD Audio is now supported on Linux too via ioctls when using physical CD-ROMs. The audio is routed through the DOSBox mixer, each drive having its dedicated mixer channel (CDAUDIO_0 for the first drive, CDAUDIO_1 for the second, and so on).
With this addition, we now support CD Audio on both Windows and Linux for physical media (but on Windows, the CD audio still goes through the OS-level mixer).
Other sound-related changes¶
It’s no longer possible to create DMA conflicts by configuring multiple sound devices to use the same DMA channel. In case of a conflict, the last configured or enabled device takes precedence and the other device gets deactivated automatically. The three sound devices that use DMA are the Sound Blaster, the Tandy DAC (the Tandy PSG doesn’t need it), and the Gravis Ultrasound.
The crossfeed config setting has been revised; now it works the same way as the chorus setting (it has light, normal, and strong presets; on defaults to normal).
Fixed a regression that made the sound effects sound crackly in Duke Nukem 3D when using 44 kHz sample rate on the Gravis Ultrasound.
Fixed a Gravis Ultrasound regression where 16-bit samples sounded noisy in some games (e.g., Star Control II and Star Trek: The Next Generation – A Final Unity).
Un-deprecate the per-SoundFont volume scaling as it is useful to reign in overly loud SoundFonts.
Ignore speaker-output enable/disable commands on the Sound Blaster 16 (this is how the hardware works). This increases compatibility with some badly coded games, e.g., the digital audio in Monkey Island 2: LeChuck’s Revenge Ultimate Talkie Edition was muted before this fix.
CD-ROM seek delays are now emulated to fix the CD audio in a few games. For example, Chasm: The Rift stopped playing the music after about 20 minutes of gameplay without this fix.
Fixed a regression where the Sound Blaster 16’s maximum sample rate was erroneously clamped to 45 000 Hz (it can go up to 45 454 Hz on real hardware). This caused the sound to be slightly out of tune in programs that use the maximum sample rate.
Fixed a regression that prevented Tandy Sound from being re-configurable at runtime.
Full PR list of sound-related changes
Input¶
Virtual joystick fixes¶
Virtual joysticks can now be created without a physical joystick being plugged in. This fixes a regression introduced early in DOSBox Staging development, which now allows mapping keyboard events to joystick events. The deactivation logic of the pressed key now detects when the key is not being pressed anymore—this improves joystick support in 74 games.
Support for mapping mouse buttons to keys¶
Some games like Settlers I (also known as Serf City: Life is Feudal) require the player to push both mouse buttons at the same time to perform certain actions. This is impossible to perform on some input devices such as the Apple MacBook trackpad or the ChesterMouse. This has now been fixed by allowing mouse buttons to be mapped to the keys of the keyboard as a workaround.
VirtualBox mouse driver support¶
DOSBox Staging has had experimental support for the VMware mouse protocol for quite some time now, and in this version, we have added support for the VirtualBox mouse protocol. The primary motivation is to enable seamless mouse operation in Windows 3.x.
Just install Javis Pedro’s Windows 3.x driver and enjoy the seamless Windows 3.x experience!
Multi-monitor-aware mouse capture support¶
DOSBox Staging now has fully multi-monitor-aware mouse capture and seamless mouse behaviour. Essentially, if DOSBox is in fullscreen mode on multi-monitor systems, mouse capture and seamless mode work as if you were still in windowed mode, allowing you to move the mouse cursor freely between the monitors.
The feature is enabled by default but it’s only active on systems with multiple displays. Of course, you can always disable it by setting mouse_multi_display_aware to off in your config.
Other mouse improvements¶
The PS/2 mouse port is now emulated at the register level, and more PS/2 protocol commands are supported. This allows the emulation of fairly complex input devices like the Microsoft IntelliMouse Explorer with 5 buttons and a mouse wheel on Windows 95.
It is now possible to disable the built-in emulated mouse driver and use your favourite real DOS driver.
Fixed problems with the internal mouse driver and text modes with more than 80 columns.
Fixed mouse support in MS Word 5.5 for DOS.
macOS function key support¶
macOS users can now force the Touch Bar or media keys to operate as function keys in DOSBox Staging (this will not affect other apps or the OS). Please refer to our wiki article for the setup instructions.
Brazilian ABNT2 keyboard support¶
The mapper, keyboard, and BIOS tables have been expanded to handle the OEM102 and ABNT1 keys found on Brazilian ABNT2 keyboards. The left and right Windows keys have been assigned to their correct scan codes too.
Full PR list of input-related changes
DOS integration¶
New FOR command¶
The missing FOR command has been added, resulting in better software compatibility with batch files that contain loops. The behaviour mirrors the behaviour of the MS-DOS 6.22 FOR command.
Various DOS command additions and improvements¶
The missing MOVE, TREE, SETVER, and VOL commands have been added.
The CLS command now does not reset the screen mode to 80×25.
The verbosity of the DELETE command has been improved.
The wildcard handling of the IMGMOUNT command has been improved.
The LS command now accepts multiple paths or patterns and ignores hidden or system files unless the /A switch is specified.
The MEM command now supports XMS memory capacities over 64 MB and has a critical bug fixed where it consumed all upper memory blocks after invocation.
The MORE command is now extended with features from modern Windows.
Persistent command history¶
The emulated DOS shell now retains a 500-line history of your previous commands. The history is remembered across multiple sessions, just like you would expect it from a Linux shell.
If you’d like to disable the shell history, set the new shell_history_file setting to an empty value.
Support for all DOS file & directory attributes¶
All DOS file and directory attributes are now supported.
On Windows, the attributes are stored as standard filesystem attributes.
On macOS and Linux, they’re stored as a mixture of standard attributes (for the read-only flag) and extended xattr attributes. The extended attributes follow the Samba 3 format which is compatible with WINE and DOSEmu2.
Autoexec improvements¶
Several long-standing autoexec issues have been fixed:
The [autoexec] section in config files is now fully UTF-8 aware and its contents are now converted to the internally set code page on the fly.
The size limitations of the [autoexec] section have been lifted.
The generated Z:\AUTOEXEC.BAT is now prettier due to the added extra comments.
The CONFIG -wc command does not eat away empty lines from the [autoexec] section anymore.
Optional shell config shortcuts¶
We’ve supported config shortcuts for a long time now (e.g., instead of CONFIG -set sbtype sb16 you can simply use the sbtype sb16 shortcut). The feature is enabled by default, but this can cause some confusion when a shortcut conflicts with a DOS executable having the same name.
Now config shortcuts can be disabled by setting shell_config_shortcuts to off.
Full PR list of DOS integration related changes
General¶
Revised CPU cycles handling¶
Some legacy CPU cycles optimisations aimed at improving multi-tasking performance on single-core computers have finally been removed. These features probably made sense 20 years ago, but they no longer serve any useful purpose in a world where minimum quad-cores are the norm:
Previously, the cycles = max 100% setting resulted in only 90% CPU core utilisation and the max 105% “magic value” expanded this to about 95%. Now 100% means 100%, and the weird 105% special case has been removed. As a beneficial side effect, cycles = max 100% can now make the CPU emulation thread go into oversubscription at times (over 100% capacity), resulting in a faster and more aggressive boost c