Enge Emulator

0 views

Skip to first unread message

Priamo Gregory

unread,

Aug 3, 2024, 4:58:20 PM8/3/24

to spactitoleg

Supported both real mode and protected mode games. Requirements:
HDPMI32i is needed for protected mode support, which is included in the zip file.
QEMM or JEMM is needed for real mode support. JEMMEX is included in the zip. It's optional, SBEMU can run without it and so without real mode support.

The original discussion can be found here: Possibility to write OPL3 sound driver for protected mode games, which initially intended for RetroWave OPL3 but then led to a pure soft emulation of SB & OPL.
The source code of SBEMU can be found here:

Known issues: some games might not work properly, need more tests & improvement. 16 bit protected mode games are not supported - this remains a challenge so far.
Some games prefer VCPI over DPMI, need use "JEMMEX NOVCPI" AFTER loading HDPMI, or remove QEMM/JEMM and run the system without VCPI (also no real mode support).
Use /t6 to enable SB16 emulation.
Use /i5 to change the virtual IRQ if you get an IRQ conflict error, or adjust IRQ assignment in the BIOS.
Any suggestion and bug report are welcomed.

IRQ guard to prevent the virtual SB IRQ sending to BIOS.
Bugfix: crash on calling HDPMI functions, and crash on error exiting.
Bugfix: DMA address mapping using DPMI_MapMemory/DPMI_UnmapMemory that doesn't work properly and cause leaks.
Bugfix: SB16: IRQ/DMA mixer registers not initialized properly, seen in TOMBRAIDER's SETUP.
Add high DMA check, force /Hx=/Dx when /Hx uses low DMA for 16 bit PCM.
Bugfix: prevent compiler optimization on MMIO reads/writes.
Bugfix: fix for some Intel HDA chips that mutes the sound for unkown reason.
Add README.txt & CHANGLOG.txt, shipped with binaries in zip file.
Compatibility: make /H option working if /T6 not set.
Some trivial bugfixes and improvements.

1.0 Beta2c:
Add "/R" option to reset sound card driver, in case the soundcard is touched by other utilities.
Add SB direct mode handling (non-DMA, DSP command 10h) previously requested by @Bondi. tested game: Shanghai 2 - experimental, may have noises.
Bugfix on BLASTER env set. (seen on FreeDOS or MSDOS prior to 7.0)
Set power states for Intel HDA, fix compatibility issues for some PCs.
Bugfix on volume settings, disable mixer resetting on DSP resetting, make volume consistent among games and can be set properly by SB utilities.
Hack: double the "volume" of OPL so that it sounds near to the digital volume.
Other bugfixes that may fix functionality or improve stability.

1.0 Beta2b:
Fix SB Live/Audigy interrupt.
Add option "/SCL" to list sound cards, use "/SC[n]" to select sound card.
Experimental: adjust sound buffer to reduce latency. (1/8 to original).
This is a single binary of SBEMU. You need HDPMI32i and JEMMEX in the 1.0 Beta2 zip.

Your latest revison of SBEMU works nearly perfectly now! All the problems I reported in the other thread have nearly magically disappeared. Real mode Apogee games work perfectly now with digital sound (ADPCM support was the ticket to success). No more stuttering audio in some games. I even got NFS to work reliably now. It's 95% playable (slight keyboard problems remain) with SB16 sound now, which is a kind of holy grail. The only game out of all those I listed before that still doesn't work with digital sound is Monster Bash. It only has clicks for the digital sound, which is an improvement over before, when no clicks were even heard.

Your SBEMU program is so important and epoch-changing that it makes DOS cool again. We may now play the old games baremetal and eschew emulators (DOSBOX) or virtual machines and get back to real, fast hardware without 3 and 4 abstraction layers slowing things down.

The sad part is: most very new systems have been intentionally castrated by Intel and Microsoft. All legacy DOS support has been brutally and viciously removed, with only UEFI 64-bit .EFI support and no 16-bit legacy support or video BIOS / legacy VGA mode support, since 2017-18.

I think about the fastest modern system we'll see able to run SBEMU natively is a 9th or 10th gen Core i9 system. Everything beyond that will sadly be impossible outside of an emulation / VM due to the terrible decision made by Intel and Microsoft to delete BIOS legacy code.

As long as the BIOS has the legacy boot mode, you should be able to use DOS on it though you are going to be stuck using PCIe to PCI adapters in order to get stuff like 3dfx cards and VESA video modes working.

All it needs is some sort of modified, self-bootable EMM386.. It could intercept/trap all DOS BIOS calls and hw bit-banging attempts and translate them to UEFI.
Speaking of, wasn't 386Max source code just recently released?

All is not lost, though. You might want to keep an eye on tkchia's biefircate project as a possible solution to keep native DOS compatibility alive, even on newer 64-bit UEFI-only systems that no longer come with a CSM. (Seriously, it's a fascinating project that deserves more attention and assistance from other retro coders!)

Before that, there will probably first be a transitionary period in which 32-bit mode is supported only in VM instances running under a hypervisor. Even on such CPUs, a "native" DOS experience could still be had by passing through a DOS-compatible graphics card to the VM. Perhaps in combination with a more modern EMM386 variant as Jo22 suggested, which can boot from UEFI and run as a hypervisor that sets up a dedicated hardware-assisted DOS VM. An "EMMX64", if you will. Perhaps something like SBEMU could even be integrated with such a tool, as an all-in-one DOS game compatibility solution for newer systems.

It is often the case with DOS sound, genuine hardware in period machine or not, that the first application to mess it up, leaves it messed up for everything tried after. Thus I suggest it's made clear whether everything was tried individually after a fresh boot or not.

I've been trying to figure this out myself. Information is very scant and often conflicting. I remember using a 10th Gen core i5 laptop (Costco price mistake about 3 years ago), and it actually booted into legacy mode (DOS), but its VGA drivers were entirely absent, which made it useless for DOS, and especially for DOS games (most of which are 320x200 - 640x400). That HP laptop only supported 640x480 and above VESA video modes / resolutions, which few legacy DOS games used or can use. And it only supported very, very slow bankswitching, and no linear frame buffer, so you could not "speed" up the VESA throughoutput by modifying the MTRRs through write-cache combining.

Currently, I've got an 8th gen Dell latop which has decent DOS support, supports VGA (though its castrated Intel UHD onboard graphics vBIOS does *not* support 320x240 or 640x400 which is super-annoying, also MTRRs can't be enabled on it for writeback cache speedup through MTRRs). It works wonderfully with SBEMU. I've also got two 5th gen core i5 Dell laptops and a 6th gen core i5 laptop, all three of which work fabulously with SBEMU -- with its Intel HDA / IHD PCI audio support. Life is good.

It may be possible to use up to an 11th gen core i7 system with some BIOSes through side-loading a special CSM module onto a dedicated video card, which would allow booting to DOS. Who knows how good that vBIOS would be in supporting lower VGA resolutions, though?

It's an awful crapshoot. As to AMD, all Ryzen systems, from the 2000 series on up have castrated onboard vBIOSes and don't support *any* VGA resolutions. So, again, although DOS will boot on them, it's useless because none of the under 640x480 non-VESA modes are even recognized -- not in the BIOS of the video card's ROM.