SBEMU puts Sound Blaster, OPL3 and the PC speaker on a modern PCI sound card

A DOS driver problem, not an application problem

SBEMU is described as legacy sound blaster emulation for DOS, and the README's first line is more precise: emulate Sound Blaster, OPL3 and PC-Speaker in pure DOS using modern PCI-based, onboard and add-in, sound cards.

That framing sets the whole scope. This is not an emulator of a sound card in the way DOSBox emulates a whole machine. It is a replacement for the ISA-era hardware interface, running inside DOS, on a machine whose sound card speaks a completely different protocol. The game still believes it is talking to a Sound Blaster at I/O port 220 with an IRQ and a DMA channel, and something has to translate that into the modern card's driver interface.

The emulated modes list gives the range.

- 8-bit and 16-bit DMA, in mono, stereo and high-speed variants - Sound Blaster 1.0, 2.0, Pro, Pro2 and 16 - OPL3 FM through DOSBox's OPL3 FM implementation - OPL3 passthrough to hardware FM if the PCI card has it - MPU401 UART emulation, or passthrough to the PCI card if supported - MPU401 Soundfont2 emulation, with original code by Cacodemon345 - PC Speaker emulation via the pc-speaker project by andersrodrig

That last group is the interesting one. MPU401 UART emulation covers the general MIDI side that games used for soundtrack playback, and the Soundfont2 emulation is what lets a game that expects a soundfont card find a substitute. The PC speaker implementation covers the cases where a game uses the timer-based beep channel for speech or effects, which is exactly the case most modern hardware has no equivalent for.

The passthrough options are pragmatic. Where the modern card can do it natively, SBEMU forwards rather than emulates, which is faster and avoids a class of fidelity problems.

Three tiers of sound card support, stated plainly

The supported sound cards section is unusual in how it refuses to overstate anything, and that honesty is the most useful thing in the README.

The source for much of this comes from MPXPlay, and the chips are grouped by status rather than by a flat list.

Enabled and working covers seven entries: sc_ich for Intel ICH, nForce and SIS 7012, sc_inthd for Intel High Definition Audio, sc_via82 for the VIA VT82C686 and VT8233/37, sc_sbliv for SB Live and Audigy, sc_sbl24 for SB Audigy LS with the CA0106, sc_es1371 for the Ensoniq ES1371 and 1373, and sc_cmi for the C-Media CMI8338 and 8738.

Compiled-in, but untested is a single entry, sc_via82 for the VIA VT8235.

Source code exists, but does not work yet is sc_sbxfi, the Creative X-Fi EMU20KX.

And then there are the additional Linux drivers ported by jiyunomegami, which covers SB X-Fi with the EMU20K1 and EMU20K2, the YAMAHA YMF7x4, the ALS4000, the OXYGEN CMI8788, the ESS Allegro-1 with the ES1988S and ES1989S, and the Trident 4D Wave.

That last list is worth separating from the core list, because these drivers were ported from Linux sources into SBEMU itself, and their status is not confirmed by the enabled and working tier. The X-Fi is the interesting case: it is a card family that was never supported by DOS natively, and the README says the source does not work yet. Since the X-Fi is a common choice for people who want a period-correct machine with a modern card, that gap is the one most likely to bite.

The three-tier framing is also what makes the project evaluable. A flat list of supported chips would be useless, because the difference between enabled and untested is the difference between a working setup and a wasted afternoon.

Real mode games need a memory manager you have to load by hand

The requirements section is where the project stops being a simple driver and becomes a configuration exercise.

The base requirement is HDPMI32i, described as HDPMI with IOPL0, linked to the author's own HX repository. On top of that, real mode game support needs I/O trapping, which comes from either JEMM with QPIEMU.DLL loaded, or QEMM, which is commercial software.

For memory management, the choice is between JEMMEX only, which provides both HIMEM and EMM, or a separate HIMEMX and JEMM386 pairing for the same effect.

In both cases the instruction is to use JLOAD, from the Jemm distribution, to load QPIEMU.DLL before starting SBEMU, so that real mode support is enabled. And the consequence of skipping it is stated without hedging: if you do not load JEMM with QPIEMU, or QEMM, only protected mode applications will be supported.

That is the sharpest requirement in the README and it is worth understanding. A DOS game that runs in protected mode and calls the Sound Blaster interface through a VxD or a DOS extender is straightforward, because the driver can trap its calls in protected mode. A game that runs in real mode has to have its I/O port accesses trapped, because a real mode program cannot be given a protected mode driver interface. The I/O trapping layer is what bridges that, and it has to be present before the emulator starts.

So the order of operations matters and is not negotiable: memory manager first, JLOAD the trap DLL, then SBEMU. Get that wrong and the games that most need the emulator are the ones that will not work.

Building it means a DJGPP toolchain and a DOS-aware makefile

The build instructions are the longest part of the README and they are written for two very different audiences.

For the cross compiler, scripts to build a recent GCC toolchain for DJGPP are available in the build-djgpp repository, and there are prebuilt releases there for people who do not want to build DJGPP themselves. The README notes the current version, from October 2023, uses GCC 12.2.0.

For make, the assumption is Debian or Ubuntu, and the host build tools are installed with one command.

sudo apt install -y build-essential

On macOS the Xcode command-line tools give you make and the other host utilities.

The project supports macOS, Linux and Windows, and for Windows the recommendation is to use WSL2 with the Linux binaries. There is also a makefile.dos for people who need to frequently debug or test on a local DOS machine.

Building DJGPP on DOS itself is discouraged, with a technical reason rather than a practical one: as the source code has grown it is not recommended, and the DJGPP DOS build does not use -O2 and -flto because the GCC version is old and buggy with -O2. The README still documents the route, including downloading the original DJGPP, selecting MS-DOS, OpenDOS or PC-DOS in the operating system dropdown and the C++ checkbox in the programming languages one, unpacking the files to a DOS partition such as C:\DJGPP, installing DOSLFN, and setting the path.

set PATH=%PATH%;C:\DJGPP\BIN

The DOS build uses make -f makefile.dos, and the README also suggests using RHIDE to edit and build on the fly, with the DJGPP environment variable set in autoexec.bat and the Alt+C Compile menu used to select Make for a dependency build or Build all for a clean one.

The build itself is two make invocations

Once the toolchain is in place, the actual build is short, and the README is careful about the one thing that commonly goes wrong.

The bin folder of the DJGPP toolchain needs to be in your path so that the compiler version command works.

i586-pc-msdosdjgpp-gcc --version

If that works, building the project is described as being as simple as running make.

make

And because you are on a modern machine with multi-core CPUs, the README recommends a parallel build, using 8 parallel processes as the example for a quad-core CPU.

make -j8

The build result lands in a folder called output, that is output/sbemu.exe.

The source layout gives a sense of the structure. There are main.c, utility.c and utility.h at the root, hdpmipt.c and hdpmipt.h for the HDPMI and IOPL side, irqguard.c and irqguard.h, and qemm.c and qemm.h for the QEMM interface. The drivers directory and the mpxplay directory hold the card support that came from MPXPlay, and the sbemu directory holds the emulator itself.

There are also a couple of build configuration files at the root, sbemu.gdt and sbemu.gpr, which are GDT and GPR project files for the Watcom debugger tooling, alongside the two makefiles and a scripts directory.

For debugging there is a separate build flag, and it is worth knowing about before you need it.

make DEBUG=1

The debug output goes to the serial port rather than the console, which the README points out is really useful because it keeps working when a game is full screen. The launch command is sbemu /DBG1 on COM1, with /DBG2 for COM2, at 9600, 8N1, and /DBG0 disables serial debug output at runtime. Serial debug output is off by default.

CD audio needs an analogue cable, which surprises people

The feature usage section starts with CD audio, and the reason it needs two parts is a good illustration of how much of DOS audio hardware is analogue.

Audio control, meaning play, pause and seek, goes through MSCDEX or SHSUCDX, and you need a CD-ROM drive with an analogue audio out and an MSCDEX-compatible CD-ROM driver set up. Volume control is taken care of by SBEMU on startup, and you adjust it with any Sound Blaster-compatible program such as SBMIX, because SBEMU emulates and forwards CD-Audio mixer settings.

The part that catches people out is the last line of that section. To actually hear anything, you need to connect an analogue audio cable from the CD-ROM drive to the 4-pin CD-IN header on your soundcard, or on the motherboard for onboard sound.

That is not a quirk of the emulation, it is a fact about the era. DOS CD audio was an analogue signal out of the drive and into the sound card, and no amount of driver work changes that. A modern machine with a USB headset has no CD-IN header at all, which is a harder blocker for this project than any driver compatibility issue.

The README also has a separate document for end users, README.txt, with setup instructions and a list of command line options, and there is a user_instructions.md file at the repository root as well.

Where SBEMU is the wrong tool

The first limitation is hardware class. This emulates an ISA-era interface on top of a PCI sound card, so a machine with only USB audio or Bluetooth headphones has nothing to attach to. The supported chip list is a list of PCI and onboard codecs, and a modern laptop or a current desktop with USB-only audio is outside it.

The second is the dependency on commercial or fiddly memory managers. Real mode game support needs JEMM with QPIEMU.DLL loaded through JLOAD, or QEMM which is commercial software. That is a hard ordering requirement before SBEMU will start, and getting it wrong produces a protected-mode-only setup where the games that motivated the project are precisely the ones that fail.

The third is the release maturity. The recent releases are Release_1.0.0-beta.7rc1 from 2026-10-14, Release_1.0.0-beta.6 from 2026-06-16, and an experimental build with new VDPMI from the same June date. So the project is on release candidate seven of a 1.0.0, and the VDPMI path is explicitly experimental. There is no 1.0.0 final in the release list, and the project description calls the work legacy.

The fourth is that this is a translation layer, not a fidelity guarantee. A game that used the Sound Blaster in an unusual way, or that relies on timing behaviour of the original DSP, may not behave exactly as it did on 1994 hardware. The README is honest that X-Fi support does not work yet, which is the same category of problem.

The fifth is the tooling burden. Building from source needs a DJGPP toolchain, a DOS build environment if you want to iterate on DOS itself, and enough of the vintage ecosystem to have the memory managers. A prebuilt binary is fine for trying it, but working on it is a project in itself.

How it compares to DOSBox and to a plain DOSBox with a real sound card

The obvious alternative is DOSBox, and the comparison is more nuanced than it first looks.

Plain DOSBox with no configuration already emulates a Sound Blaster and an OPL3, because that is the machine it emulates. It does so in software, on whatever audio backend the host offers, and it works on a laptop with Bluetooth headphones because it never touches real hardware.

What DOSBox does not do is present itself to a program as a device. The difference matters for a narrow but real class of software: DOS utilities and drivers that expect to talk to a real Sound Blaster at fixed I/O ports with a real IRQ and a real DMA channel, and that are not themselves emulated. A DOS-era audio tool that pokes registers directly, or a TSR that hooks the interrupt, is outside what DOSBox can satisfy, because in DOSBox there is nothing at port 220 to poke.

SBEMU provides that. A DOS program gets a real device it believes is hardware, and the modern card does the actual work. That is why it needs a real memory manager and a real PCI card, and why it is the right answer for the cases DOSBox cannot cover rather than a better DOSBox.

The other comparison is with the original hardware, which is the one most people have not considered. A vintage Sound Blaster 16 on an ISA machine, or a real OPL3 card, does the job with no driver at all, and it is authentic. For someone who only wants to play a few DOS games, that remains the simpler answer, and the cost of a used ISA card plus a machine with an ISA slot is now the barrier rather than the software.

So the choice is: DOSBox for convenience and universality, real hardware for authenticity, and SBEMU for the narrow middle case where a DOS program needs to believe a card is present.

Editorial conclusion

SBEMU fits someone with a modern PCI sound card who wants to run DOS games that expect a Sound Blaster, an AdLib or an MPU401, and who is prepared to build a DJGPP toolchain or use the prebuilt binaries. It does not fit someone whose machine only has USB audio, and it does not fit a project that needs a stable release, because the release line is a series of 1.0.0 beta tags and the sound card support list is explicitly partial. Before you start, check which of the seven listed chipsets your card uses and read the three-tier support status, because the difference between enabled and working, compiled-in but untested, and source exists but does not work yet is the difference between a working evening and a debugging session.

Frequently asked questions

Official sources

1. crazii/SBEMU on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases