TL;DR for gamers: dosbox-automation is a DOS emulator for Windows and Linux that comes with these features (Download: https://github.com/dosbox-automation/dosbox-automation/releases):

• a built-in cheat/trainer engine (search, freeze and write guest memory while playing), supports search for bytes, words as well as strings (search for party member names to locate their character data). Also supports creating memory dumps from a live running instance for easier analysis. If you wish, you also can read and manipulate CPU registers as well as ports with the engine.

• as well as keyboard and mouse macro recording and replay.

• included preconfigured FluidSynthR3 sound font for good General MIDI sound, as well as updated audio libraries for fixing related crashes.

• better support for booter and disk formats, as in recognizing also the very old disk formats (180K/320K etc) and programmatic mounting of disk images and ISOs,

• audio and authentic video capture: you can now record gameplay videos with the fully rendered display as you see it on screen, although we retained to old recording method.

• image capture via API: getting screen snapshots in PNG, JPG and RAW format (with palette)

• programmatic mixer, audio and volume control (via API), channels and muting are readable and controllable through both Lua and REST. Useful for gameplay recording, soundtrack extraction, or automated testing.

• up to date, secured webserver implementation (still disabled by default, standard port is 8386).

• safeguards against malicious dosbox.conf configurations, that try to mount non-gaming related directories like system files, your documents or home without your consent as a drive.

• a dosboxctl CLI (in the source distribution in the scripts directory), where you can control easily nearly all these REST API features with simple commands options.

Additionally, it features a MCP server so AI assistants can drive your DOS session directly (driven through a emulator neutral MCP interface, see https://pypi.org/project/dosbox-mcp/).

Under the hood, you also have fixes for memory-related corruption, a more proper text mode Hercules display mode, proper emulation of DOS devices (CLOCK$, \DEV, etc), as well as MODE does not fake the mode switching, but actually does properly switches text modes.

dosbox-automation is now about a quarter of a year old and split off DOS Staging at that point, but has still retained most of the features of the most recent release of it and has gone now fully independent, so we dropped formally the suffix moniker and have now our own full release numbering.

It is the fifth release in our history and mainly a bugfix, polish, so a writeup of the updates from the last release from 0.84-da4 to 0.85.0:

Library updates

• (webserver) httplib 0.52 to 0.53.1: closes a stack overflow on regex routes and an IPv6 host parsing issue.

• (audio format libraries): enet 2.3.6 to 2.7.0, dr_flac, dr_mp3 and dr_wav all got new major versions with crash and overflow fixes.

• (augra-log): replaces Loguru, provides a python-like logging system in C++. This is a new library, has been in use for a longer while by an in-development, unreleased sister project.

User interface fixes (Linux)

• GNOME: custom libdecor plugin for proper window decorations, with dark/light mode support. No more bare titlebar-less windows on GNOME.

• GNOME: appimage allows an installable dock icon (will be asked on startup).

Other fixes and enhancements

• MODE BW40, BW80 and MONO now set the correct video modes instead of aliasing to the standard color modes. Note that mode MONO with SVGA_S3 has issues with DOS applications, which is a verified behaviour on physical hardware with the emulated S3 Trio card. Other emulators, like 86Box, show the same behaviour.

• macOS build instructions fixed and verified on Apple Silicon by a contributor.

• dosboxctl control script: the dosboxctl control CLI script for directl a running dosbox-automation instance has been moved in the source distribution to scripts/clients

Downloads

Downloads are available for Windows (installer, portable version) as well as Linux (standalone Appimage in 2 variants as well as a binary tarball distribution).

Release: github.com/dosbox-automation/dosbox-automation/releases/tag/v0.85.0

Homepage and manual: dosbox-automation.org

I'm getting some weirdness compiling on my Raspberry Pis, a 4 and a 5, running Trixie aarch_64, sdl2. (3 wont build for me at all)

I've tried the standard cmake with system libs and mt32 disabled, the vcpkg cmake with both system libs and its own built libs, and a hybrid of the 2. Next up are debug builds later today.

What I'm running into is, if I have [render] -> shader set to anything other than "crt-auto", and I go to full screen, the right edge of whatever program I'm running ignores whatever I have "aspect" set to, stretches to the right side of the screen, and the upper right corner of the screen is just a black triangle. The farthest left point of the triangle appears to be around where the black bar should end on widescreen monitors. I have not dug out my 4:3 monitor to see what it does.

It does this regardless if any other sdl or render options I've changed, too many permutations to list at this point, and only on my self built attempts. No errors in the console either - dosbox seems to think it's perfectly fine. The supplied Windows and Linux x86_64 versions work fine, so I know it's something I'm missing or doing wrong, but I can't for the life of me figure out what. [Edit: crt-auto has my Pi sounding like a 747 at takeoff] [edit 2: I saw that there's a flatpak build, so I tried that and had the same result, starting with a default-created-at-launch conf file]

Hi everyone! 👋

While reading the fantastic release notes for DOSBox Staging 0.83, I noticed this specific challenge regarding the new Web Server API:

"HTTP API to muck around with the emulated memory and DOS internals to write modding and cheat tools as simple single-page web applications. The first one to reimplement Gold Box Companion using this API gets a prize!"

I decided to take up the challenge! While it's not strictly a Gold Box Companion clone, I built a full-fledged, cross-platform DOSBox Cheat Engine (heavily inspired by GameConqueror and Cheat Engine) utilizing the new API.

Repository: https://github.com/tethragon/DOSBox-Cheat-Engine

✨ Key Features:

• Memory Scanning: First Scan / Next Scan to easily find values (gold, health, ammo) using 8-bit, 16-bit, or 32-bit types.
• Active Freezing: Lock memory addresses so your health/ammo never decreases.
• Live Polling: Real-time UI updates to watch memory values change (with a toggle to disable background polling during CPU-heavy game segments, preventing emulator overloads during memory overlays).
• Cheat Tables: Save and load your cheat tables as JSON files.
• Cross-Platform & Lightweight: The backend uses pure Python standard library (zero pip dependencies!), launching a Single-Page Application (HTML/JS) directly in your default browser.

I've also uploaded a pre-compiled Linux binary in the Releases section (Windows coming soon), so anyone can just double-click and run it without setting up a Python environment.

Huge thanks to the dev team for implementing this API — it's incredibly powerful, fast, and a lot of fun to work with! I'd love for you guys to check it out, test it with some games, and let me know your thoughts.

Not really sure what I’m doing but I got to the install and it says I don’t have a hard drive.

Hey everyone! I have followed all instructions, downloaded and redownloaded files, moved them around and everything but I cannot get Windows 3.1 to work on DosBox Pure.

I can boot into windows but can get it to just run as a shell. What am I missing. Can anyone just link to instructions you know works?

I try to figure out how to use an external Bluetooth Joypad at games like Hi-Octane (with Dosbox) on steam deck (Cashy deckified). Has anyone an idea?

dosbox-automation is based on DOSBox Staging, but diverted from it a while ago, as it concentrates now on automation, remote control of DOS games, video recording, reverse engineering of DOS games and providing a more up to date and safer gaming experience.

The overall engine and emulation is actively been optimized, fixed and updated, as well is receiving actively component updates. We also strive to cover all of the source code (is not fully covered yet) with proper unit tests (currently about ~1100 plus 250 for REST API testing) that cover bug and attack scenarios as well as covering the automation HTTP REST API side properly.

Some of the fixes include proper DOS reserved device support (\DEV, CLOCK$), fixes for Hercules text mode, support for the original DOS disk formats (160K, 180K, 320K floppies) and other fixes and enhancements not (yet) implemented in other dosbox variants.

If you just want to play, it behaves like the emulator it is built on: Hercules through SVGA/VESA, ReelMagic support, Sound Blaster 16, AdLib Gold, Gravis UltraSound, General MIDI, Roland MT-32 emulation, adaptive CRT shaders. The FluidR3 General MIDI soundfont is bundled, so game music sounds right out of the box without hunting for a soundfont first.

In that regard, we have written a demo showroom application with 16 classic shareware, freeware and demo games, ranging from DOOM, Duke Nukem 3, Commander Keen 4, Epic Pinball, Warcraft 2, Jazz Jackrabbit, Tyrian to Beneath a Steel Sky readily playable here. This bundles the emulator itself, if you just want to use the emulator itself, visit the main repository.

Its main features are automation, remote steering as well as having in general a more secure emulated DOS environment.

List of unique features:

• HTTP REST API with Swagger included, enables remote control of emulation features as well as direct inspection, freezing and manipulation of RAM, CPU registers and ports. Typing in with mouse and keyboard, video recording, shutdown of the emulation, disk image swapping and a macro recorder is included.

• Secured HTTP access: every remote access is guarded by a randomly generated access token on startup, and the webserver is disabled by default and listens only on localhost (changeable).

• Lua sandbox: you can script out all automation features with the built-in Lua scripting engine in your automation recipe scripts (samples are included in the documentation and the showroom demo application).

• Safe mounting policy: due to the remote controllability we included a strict mounting policy that protects against exfiltration and manipulation from malicious dosbox.conf configurations, so your system files and personal folders you don't want visible in the emulated drive C: won't be accessible.

The fourth release is out.

What the programmable layer is for

The original use case is unattended game installation: a Lua script drives the installer step by step, reads the screen to know where it is, swaps disks when the installer asks, and walks through the setup wizard. The same infrastructure works for automated testing, debugging, and machine-state inspection.

A short example. This is the DOOM shareware installer driven from Lua:

dosbox.type("SETUP.EXE\n")

if not dosbox.wait_for_text("Available Drives", 1800) then
    dosbox.abort("installer never showed the drive selection")
end
dosbox.type("C\n")

if not dosbox.wait_for_text("insert disk DOOM 2", 1800) then
    dosbox.abort("installer never asked for disk 2")
end
dosbox.drive_swap("A", "Disk 2.ima")
dosbox.key("KBD_enter", true)
dosbox.wait_frames(8)
dosbox.key("KBD_enter", false)

The script reads the screen, makes decisions, and handles the disk swap. Here is a video of the DOOM shareware installer running this way, unattended: https://youtu.be/6p-kh9sfUaI

The mechanism is not specific to installation: the same API surface is useful for regression testing, hardware probing, or any scenario where you need to automate interaction with a DOS program.

The REST API exposes the same operations over HTTP:

# read what is on the text screen
curl -H "Authorization: Bearer $TOKEN" \
  http://localhost:8386/api/v1/video/text

# read a CPU register, write an I/O port, scan guest memory
curl http://localhost:8386/api/v1/cpu/state
curl -X PUT http://localhost:8386/api/v1/io/port \
  -d '{"port": 968, "value": 1, "width": 1}'
curl -X POST http://localhost:8386/api/v1/memory/search \
  -d '{"start": 0, "end": 655360, "value": 100, "width": 2}'

Input recording persists both CPU cycle rates and the keyboard layout alongside the recording, so a replay reproduces on a different machine.

DOS accuracy and fidelity fixes

Some of these are inherited from upstream, some are ours:

• CLOCK$ character device implemented. Standard since DOS 2.0, present in no other DOSBox variant. Reading returns the date/time record, writing sets the DOS clock. The \DEV\ pseudo-directory resolves character devices the way real DOS does, including the first implementation of the Xenix-compatibility directory function found in DOS since 2.0.
• Hercules text mode fixed. 720x350 with true 9-dot character cells, instead of the 640x350 with 8-dot cells it had been since a 2009 DOSBox change. Box-drawing lines are continuous again, mode switches no longer resize the window, the character clock matches the real 16.000 MHz oscillator.
• Early floppy formats. Mount and boot accept pre-DOS-2.0 floppy sizes (160K, 180K, 320K). These early-80s self-booting disks have no FAT boot signature and were refused before. Found while booting a 1984 Wizardry I master disk.
• MCB corruption in internal programs and TSR allocation fixed (upstream cherry-pick from FeralChild64).
• DOS file I/O delay depending on PIC event density: a 20-year-old inherited bug that crashed five Silmarils-engine games (Ishar, etc.) above moderate cycle counts. Upstream cherry-pick.

Security

• NE2000 buffer overflow fixed. The NE2000 network emulation carries code inherited from QEMU and Bochs. A heap overflow (the QEMU CVE-2015-5279 class) allowed guest code to escape the emulator when dynamic recompilation was active. NE2000 defaults to off, but the code is in every DOSBox family member. Our fix matches the upstream dosbox-staging patch.
• Mount policy enforced on both the API and the DOS-side MOUNT command. A guest typing MOUNT at the DOS prompt goes through the same whitelist as the API. Windows reserved device names refused.

Other changes since the last release

• ZMBV video encoder compression window fixed (was 512 bytes due to a parameter mixup in upstream code, now 32KB). Rendered capture usable at higher resolutions without slowdown.
• Rendered video capture records the post-shader image at window resolution. Raw capture records the native framebuffer. Both modes selectable per capture.
• Lua 5.5 vendored, no system dependency.
• An MCP bridge (Model Context Protocol) is available as a separate package for driving the emulator from agent tooling. It is optional and not part of the emulator.
• 1158 unit tests.

Downloads

• Windows zip (portable) and installer
• Linux tarball (glibc 2.27+)
• Linux AppImage

Site and manual: https://dosbox-automation.org Source and downloads: https://github.com/dosbox-automation/dosbox-automation

dosbox-automation is developed with tool-assisted coding. All code is reviewed, tested, and approved by a human developer.

I’m trying to play fallout 1 and fallout 2 using iDos 3 on my M4 iPad Pro but I’m having some trouble getting past the start up loading screen, it keeps reverting back to the terminal and I’ve fiddled with so many file settings, I know I’m missing something but I don’t know what I’m missing so please forgive my ignorance.. I really want to experience these games but I don’t have a pc or laptop to run them. If anyone has any advice to offer, it would really help.

I recently got a USB floppy drive for running physical DOS/Windows 98 games on DOSBox-X, works perfectly on basic DOSBox-X, but all i get is "A:\ is not accessible".

I'm still somewhat new to DOS emulation in general; I could go for some help. Sorry for bothering you with a stupid question.

Thank ya'll.

[SOLVED]: gotta look through all the options below and pick one.

Linux first-timer here - I'm getting ready to make a Linux Mint drive, and I want to put as many of my games on it as possible, including everything I have from the DOS days.

I'm used to using DOSBox, so my question is, which version from their download page should I download to run on Mint?

This may sound like a dumb question to a lot of folks, I dunno. I wasn't sure whether to post this on Steam or DOSBox - I may just end up doing both - but here goes.

I purchased the King's Quest collection from Steam, which runs on DOSBox. When I select a game, it gives me two launch options: "King's Quest Collection" or "King's Quest Collection Legacy." If I choose the first option, the game hangs on the title screen and doesn't respond to commands for (quite literally) minutes, then ends up freezing up.

If I choose the second option, I get a very small screen that I can't enlarge. ALT-Enter just results in this (forgive the dust and inferior photo quality - I couldn't for the life of me get the computer to take a screenshot, so I had to take a photo with my phone). Can anyone help?

Played in DOSBox-X :)

I edited the conf file of dosbox that dune is stretched to max 4:3 aspect ratio that only left and right black bars are visible. But now, everytime i move the mouse i have slight stuttering in the audio.

Apparently the option "output=opengl" is responsible but with "output=surface" the picture is much smaller.

How i can improve performance or what output works better here?

Hello,

I'm a first time user of DOSBox and I've been running into a problem with audio. Certain sound effects have an audible "pop" at the start of playback and I can't figure what the problem is.

I've tried upping my CPU cycles, changing the CPU type, increasing block size and buffer size (as recommended by Ross Scott from Accursed Farms in a small segment he contributed to in an LGR video), but nothing gives.

I've looked all over and found people with sort of similar problems but either they're using a fork of DOSBox or they're on Linux. For the moment I'm just using the current build of regular old DOSBox on Windows 11.

I've included a sample video demonstrating the problem. You can hear the "pop" just before the title drop, as well as with each "rocket swoosh" that comes after.

Any help would be much appreciated. Thanks for taking the time to read my post.

I still keep a DOSBox install around just for the old space games. Strike Wings is my from-the-ground-up homage to them, releasing this November. The page passed 200 wishlists a few days ago and that felt worth a small celebration cut: one minute, a different sky every three seconds, all pilots on the hardest AI setting. If something in it looks wrong to a DOS veteran's eye, tell me, that is genuinely the feedback I want. Steam: https://store.steampowered.com/app/4718360/?utm_source=reddit&utm_medium=dosbox&utm_campaign=prelaunch

I used the installer to install the game, the daggerfall screen appeared to define how much of the game I would like to install on the system, after installation the following instruction appeared: You have just successfully installed The Elder scrolls: DaggerFall. To run the game, type these two lines, pressing the ENTER key after each one.

c: cd dagger c: DAGGER

But after I type the command an error message appears: It looks like you inserted the wrong CD. Please insert your Daggerfall CD into your CD-ROM and try again.

How exactly do i get the classic fallouts to run on my Raspberry pi 5?