Awesome project, just tested it (in qemu) and it worked great.

(some notes:
- I used linux for my tests, started with
$ git clone https://github.com/FlyGoat/csmwrap
$ cd csmwrap
$ git submodule init
$ git submodule update --recursive
$ make seabios
At this point I got an error message which I solved by editing file seabios/out/vgasrc/vgalayout.lds and removing all lines starting with a #
Then I repeated make seabios
$ make seabios
$ make
Next, I edited the GNUMakefile and changed QEMUFLAGS to QEMUFLAGS := -m 2G -enable-kvm.
$ make run
Qemu started, showing first a Tianocore splash screen and then the familiar seabios text.
Qemu can be reset and with the escape key one can access the UEFI Setup.
)

@EduBat thanks for documenting your steps. But do the released binaries on the releases page of the GitHub project not work in QEMU out of the box?

By the way, I noticed a mistake in my initial post above. The older project by TK Chia that I referred to was initially named "biefircate" and was later renamed to "muefircate", but I apparently mixed the two names up here and called it "miefircate".

Anyway, CSMWrap is not related to biefircate/muefircate in any way and follows a different approach.

digger wrote on 2025-05-26, 20:43:

@EduBat thanks for documenting your steps. But do the released binaries on the releases page of the GitHub project not work in QEMU out of the box?

Yes.
Unfortunately I cannot test it any further as all my computers are either BIOS based or UEFI with CSM and all boot in "legacy" mode.

can't you just turn off CSM and test it that way?

myne wrote on 2025-05-27, 06:05:

can't you just turn off CSM and test it that way?

Yes, I hope so. This is what I'm going to try, with the provided binary (64-bit .elf file).

This looks like it is very promising.

If we can get the oddball sound hardware working with SBEMU, this would enable reprogrammed chromebooks to fill the niche of portable retrostations.

Most chromebooks already have weaksauce CPUs that would be perfect for this. (No need to downclock or otherwise kneecap them so they play right.)

See also, Mrchromebox.tech

Basically, that guy maintains a repository and install script to put UEFI bios on chromebooks so they can run a normal OS.
If that can be coaxed into working alongside this new project, then they could, in theory, run DOS.
Once they are running DOS, the only real snag is the goofy sound hardware present. SBEMU wants proper intel HDA, which is usually not what is present on chromebooks.

What is the sound?
I can't imagine someone reinventing a new sound standard like it's 1990 anymore.
They have to come from some chip, and that chip is some standard, and unless you want to spend a bundle, it'll be ac97 or hda...

No?

myne wrote on 2025-05-27, 12:31:

What is the sound? I can't imagine someone reinventing a new sound standard like it's 1990 anymore. They have to come from some […]
Show full quote

What is the sound?
I can't imagine someone reinventing a new sound standard like it's 1990 anymore.
They have to come from some chip, and that chip is some standard, and unless you want to spend a bundle, it'll be ac97 or hda...

No?

Nope. Intel low power audio / SST.

It is NOT HDA.

myne wrote on 2025-05-27, 06:05:

can't you just turn off CSM and test it that way?

That is my main machine, so no, I will not do any tests on it... Sorry 😀

What I did so far was setup a qemu virtual machine with UEFI firmware (Tianocore) and install Windows 10 on it.
Windows formatted the virtual hard drive and created the UEFI partition.
Then I shut it down, used losetup and mount to mount the UEFI partition to a folder and copied csmwrap.efi onto it.
I also got another virtual hard drive image file where I already had Freedos and added it to qemu.
Upon reboot I entered the tianocore setup, selected boot from file and picked up csmwrap.efi
Seabios started as expected and with the escape key I picked up the virtual hard drive with Freedos, which started.

Regarding real hardware, looking at the csmwrap source code (file unlock_region.c), the main limitation seems to be that, if the vendor UEFI implementation does not implement EfiLegacyRegion2ProtocolGuid it will work only on some computers with certain intel chipsets. The solution for AMD chipsets seems to be more generic, which is more encouraging.
As per the current version in Github, csmwrap (file video.c) will try to run the video BIOS from the graphics card, if supported. If not then it will try seavgabios which needs a VGA compatible graphics card at the register level.
All this to say that the solution on real hardware needs testing by the community, I guess.

(for reference
qemu-system-x86_64 -enable-kvm -M q35 -m 4G -smp cores=2 \
-boot menu=on \
-drive if=pflash,unit=0,format=raw,file=ovmf-code-x86_64.fd,readonly=on \
-drive if=pflash,unit=1,format=raw,file=ovmf-vars-x86_64.fd \
-drive driver=raw,file="wtest.img",if=ide \
-drive driver=raw,file="freedos.img",if=ide \
-cdrom 10_20H2_Consumer_x64_en-GB.iso \
-net nic,model=virtio -net user \
-rtc base=localtime,clock=host \
-usb -device usb-tablet
)

I will plug mrchromebox's uefi again, as it is coreboot/tianocore, like your VM / Qemu test, and should work nicely.

Just needs sbemu support, and you'd have something quite slick I think.

Yeah, plugging sbemu as a kind of bios service would be the full package.
But one step at a time. I have a small inkling how hard this is to write (see sig)

myne wrote on 2025-05-28, 00:01:

Yeah, plugging sbemu as a kind of bios service would be the full package.
But one step at a time. I have a small inkling how hard this is to write (see sig)

As far as I understand it, the only options that would allow such integration would be the following, none of which could be considered pure "bare-metal":

• Boot DOS in V86 mode (so hardware access can be intercepted and emulated). This option would be incompatible with Windows, as well as a handful of games that don't play well with DOS extenders.
• Implement the port-trapping stuff necessary for Sound Blaster and MPU-401 emulation through System Management Mode (SSM). This is the same way how PS/2 keyboards are emulated by many BIOSes when only a USB keyboard is attached, but I believe this method is quite slow.
• Boot into a very light-weight Type-1 hypervisor that emulates Sound Blaster and MPU-401 and whatever other hardware that DOS needs which is no longer present on modern host systems, and allows DOS to access anything else directly, by running it in a privileged domain (dom0).

To elaborate further on the third option: to my knowledge, a DOS-optimized light-weight boot-time Type-1 hypervisor does not currently exist yet. (Let me know if you know of one, please!) However, such a hypothetical solution has the potential to be the most optimal solution in terms of both performance and compatibility, even if it's not exactly "bare-metal" in a purist sense. In many ways, it would be like the EMM managers of old, except that it uses the hardware-assisted virtualization features in modern CPUs instead of the 386's V86 virtualization feature.

This would allow it to do more than just sound card emulation. You could expose the multiple CPU cores to DOS applications through some kind of high-level API, or emulate expanded memory while at the same time still being compatible with software that refuses to run in anything other than real mode. (Some games come to mind.)

It could optionally offer full VGA emulation for systems lacking a GPU that has hardware-level VGA compatibility.

It could also offer legacy BIOS compatibility on pure UEFI systems, simply by loading SeaBIOS in the dom0 VM that it spins up to boot DOS (or other legacy and retro OSes) in.

You could call such a solution EMMX64.EFI or something. 🙂

But that would be a substantially different approach than that of CSMWrap.

And since CSMWrap ends up booting "pure" real mode from a legacy BIOS (as "bare-metal" as you can get), I don't see how you could reconcile that with software-based Sound Blaster emulation (as done in SBEMU or VSBHDA) without in effect resorting to any of the options I listed above. The reason for that is that is requires DPMI to emulate sound hardware for protected mode DOS applications, and it requires V86 mode to emulate sound hardware for real mode DOS applications. Neither DPMI nor V86 are available in "real" real mode.

There's another place to do this with a chromebook.

The embedded controller.

https://chromeos.dev/en/posts/embedded-controller

However, the implication that this should be hypervisor or hardware trapped as a firmware serviced function wasnt initially intended.

I meant that just support for SST type sound hardware by existing VSBHDA and SBEMU would give sufficient function (despite the warts) for these devices, if used with this hot pluggable csm.

digger wrote on 2025-05-28, 11:20:

As far as I understand it, the only options that would allow such integration would be the following, none of which could be con […]
Show full quote

myne wrote on 2025-05-28, 00:01:

Yeah, plugging sbemu as a kind of bios service would be the full package.
But one step at a time. I have a small inkling how hard this is to write (see sig)

As far as I understand it, the only options that would allow such integration would be the following, none of which could be considered pure "bare-metal":

• Boot DOS in V86 mode (so hardware access can be intercepted and emulated). This option would be incompatible with Windows, as well as a handful of games that don't play well with DOS extenders.
• Implement the port-trapping stuff necessary for Sound Blaster and MPU-401 emulation through System Management Mode (SSM). This is the same way how PS/2 keyboards are emulated by many BIOSes when only a USB keyboard is attached, but I believe this method is quite slow.
• Boot into a very light-weight Type-1 hypervisor that emulates Sound Blaster and MPU-401 and whatever other hardware that DOS needs which is no longer present on modern host systems, and allows DOS to access anything else directly, by running it in a privileged domain (dom0).

To elaborate further on the third option: to my knowledge, a DOS-optimized light-weight boot-time Type-1 hypervisor does not currently exist yet. (Let me know if you know of one, please!) However, such a hypothetical solution has the potential to be the most optimal solution in terms of both performance and compatibility, even if it's not exactly "bare-metal" in a purist sense. In many ways, it would be like the EMM managers of old, except that it uses the hardware-assisted virtualization features in modern CPUs instead of the 386's V86 virtualization feature.

This would allow it to do more than just sound card emulation. You could expose the multiple CPU cores to DOS applications through some kind of high-level API, or emulate expanded memory while at the same time still being compatible with software that refuses to run in anything other than real mode. (Some games come to mind.)

It could optionally offer full VGA emulation for systems lacking a GPU that has hardware-level VGA compatibility.

It could also offer legacy BIOS compatibility on pure UEFI systems, simply by loading SeaBIOS in the dom0 VM that it spins up to boot DOS (or other legacy and retro OSes) in.

You could call such a solution EMMX64.EFI or something. 🙂

But that would be a substantially different approach than that of CSMWrap.

And since CSMWrap ends up booting "pure" real mode from a legacy BIOS (as "bare-metal" as you can get), I don't see how you could reconcile that with software-based Sound Blaster emulation (as done in SBEMU or VSBHDA) without in effect resorting to any of the options I listed above. The reason for that is that is requires DPMI to emulate sound hardware for protected mode DOS applications, and it requires V86 mode to emulate sound hardware for real mode DOS applications. Neither DPMI nor V86 are available in "real" real mode.

It's all just software. The bios, option roms, and even the quasi-emulation that transparently converts ide to sata via int13h using a combination of real and protected mode.

I don't see why a similar thing for sound couldn't be bundled.

I'm in the perplexing position of wondering whether you know a lot more than me, or a lot less.

myne wrote on 2025-05-28, 13:22:

It's all just software. The bios, option roms, and even the quasi-emulation that transparently converts ide to sata via int13h using a combination of real and protected mode.

I don't see why a similar thing for sound couldn't be bundled.

I'm in the perplexing position of wondering whether you know a lot more than me, or a lot less.

There's really no need to strike such a hostile tone.

INT 13h doesn't perform any "IDE to SATA" conversion. It's a higher level legacy BIOS API for disk access, which provides an abstraction on top of more specific disk controller standards (IDE, SCSI, AHCI, NVMe, what have you).

That's why DOS doesn't care what kind of disk controller the system has, as long as it's compatible with the legacy BIOS through the INT 13h API.

It's up to the legacy BIOS implementation (in this case SeaBIOS) to actually support the specific underlying hardware standards (for instance IDE and AHCI) under the hood. But it will expose the functionality to the OS through the INT 13h API.

The reason why more complex emulation is needed to get sound support in most DOS games is because a similar higher level API never gained enough traction in the DOS era.

There is the INT 66h (DIGPAK/MIDPAK) API, and there is the VBE/AI spec that added audio extensions to the INT 10h VBE API, but neither of those became dominant standards in the same vein as Sound Blaster did.

That's a real shame, because if a high level sound API had emerged and caught on earlier on in the DOS gaming era, we would have had much healthier competition in those days, and also we wouldn't have to resort to complex I/O port trapping and hardware emulation solutions like SBEMU and VSBHDA today.

Just a quick note to mention that github user Farel Reski Aditiya has created an amazing wiki as part of the project pages:
https://github.com/FlyGoat/CSMWrap/wiki

The reason why more complex emulation is needed to get sound support in most DOS games is because a similar higher level API never gained enough traction in the DOS era.

Well, in principle, there was MVSOUND.SYS for ProAudioSpectrum 16 and SOUND.COM for AdLib..
But in practice, most DOS games probably talked to sound hardware directly.

Edit: Some versions of Jill of Jungle had Creative's counterpart to the latter driver built-in.
I wonder what happens if a synthetic/high-level implementation is available.
Would the Jill driver detect that the driver is already loaded and pass over control to it?

There is the INT 66h (DIGPAK/MIDPAK) API, and there is the VBE/AI spec that added audio extensions to the INT 10h VBE API,
but neither of those became dominant standards in the same vein as Sound Blaster did.

Impressive, that's cool. I wonder if PCem/86Box and DOSBox could be bothered to have direct support for this.
Even if it seems superflous at first glance, it might improve performance, at least.
Weak devices such as Raspberry Pi or Android devices might do benefit if a synthetic sound device is available as a Sound Blaster alternative.

Edit: The sound device in Insignia SoftWindows 2.0 is a synthetic device, too, I think.
Since there's a driver for Windows 3.1 available (as part of SoftWindows) it might be worth to emulate/implement that, too.

What is the fundamental difference between int13h translation to sata, and an int5h translation from sb# to hda?

myne wrote on 2025-06-02, 03:42:

What is the fundamental difference between int13h translation to sata, and an int5h translation from sb# to hda?

Software interrupt vs hardware interrupt, I think.
MS-DOS uses int21h, for example.