Hi crazii, just to let you know that I've been lurking watching this from a far just wanted to say thank you for your hard work for the community! You're a legend!

This is relevant to my interests.

Now a competition to see who can run DOS Quake with audio on the fastest PC?

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.

Awesome, got some older newer laptops which will benefit from this. I'm "into" other projects/eras at the moment though, will have to revisit.

zyzzle wrote on 2023-03-05, 15:56:

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.

Any idea what CPU/chipset is the last one with a normal BIOS?

Congrats bro! This is a very good project! It's possible include support for Realtek Ac97 chips?

rasteri wrote on 2023-03-05, 17:23:

zyzzle wrote on 2023-03-05, 15:56:

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.

Any idea what CPU/chipset is the last one with a normal BIOS?

A lot of the newer Dell laptops have Legacy(BIOS) and UEFI boot modes.

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.

What would be cool is if FreeDOS was actually updated to support UEFI boot and also bug fixed to fix other issues that have apparently been around forever.

Great stuff! Would this work with old netbooks? Asus EEE 701/90x for example?

cyclone3d wrote on 2023-03-05, 19:00:

What would be cool is if FreeDOS was actually updated to support UEFI boot and also bug fixed to fix other issues that have apparently been around forever.

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?

ArcaOS, that ecomstation successor, seems to support UEFI boot by now, too.
Unfortunately, there's no free demo version available to check that out.

Edit: A modified version of PC-MOS/386 would also be an alternative.
By design, it can already virtualize certain graphics modes and i/o..

Congrats on the beta release! 👍
I can confirm MDK and Duke2 work perfectly now!
Amazing work, crazii!

rasteri wrote on 2023-03-05, 15:19:

This is relevant to my interests.

Now a competition to see who can run DOS Quake with audio on the fastest PC?

I thought the exact same thing 😂

How incredible.

Should it work on audigy platinum?

crazii wrote on 2023-03-05, 06:13:

Hi, I'm happy to announce that SBEMU is ready for more tests. :D […]
Show full quote

Hi, I'm happy to announce that SBEMU is ready for more tests. 😁

Purpose: for PCs with AC97/Intel High Definition Audio sound cards that doesn't have Sound Blaster support (vintage PCs after 2000 era, or modern PCs with HDA).
Supported PCI soundcards:

• Intel ICH
• nForce (nForce boards not tested so far)
• Intel High Definition Audio
• VIA VT8233 & VT82C686
• SB Live/Audigy (thanks to Baron von Riedesel for debugging)

Emulated cards: SB 1.0, 2.0, Pro, 16, 8 bit DMA & 16 bit DMA.

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.

For more information, read the readme.txt in the zip and use /? in the command line.

Thanks to:

• MPXPlay's: sound card drivers
• DOSBox: DBOPL emulation
• HDPMI & JEMM: Port traps
• Folks in the forum that helped guiding & testing & improving the emulation

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: https://github.com/crazii/SBEMU

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).
Any suggestion and bug report are welcomed.

1.0 Beta2:
SBEMU.zip

Amazing work! Thanks!

zyzzle wrote on 2023-03-05, 15:56:

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.

Indeed. It's quite a breakthrough in DOS retro gaming land.

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.

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!)

That is, until inevitably the day comes when native 32-bit compatibility is removed from newer x86-64 CPUs at the hardware level.

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.

But yeah, native DOS compatibility is well and truly on its way out. And honestly, it's amazing that it was preserved this long, when you think about it.

But in the meantime, I'm also quite curious to see some records shattered with Quake and other games in DOS running on as modern as possible hardware in all their audiovisual glory. 🙂

It would be interesting to dedicate a second CPU (core) where available to the emulation of the SB.

I've gotten no sound.
This is on a AC97 - Intel i915.
SBEMU finds the chip "Found sound card: ICH AC97".
Provided Jemmex is used.
Wolf3d, is used for realmode test.
Dos Mplayer/Wolf4GW, used for protected mode test.
SETBLAST.EXE asks that settings be checked, when test is run.
On system power down/reboot, audio speaker crackles; as it only does after dos sound activation. So, something is working.
Edit:Each test after fresh reboot. Quake also tested.
Vendor 8086, Device 266e, Subsystem 834c10f7, revision 04
MS-Dos 7.10
MPXPLAY works.
MPXPLAY -SCT output: ICH : Intel ICH6 found on port : 18C0 irq:9 (type:ICH4, bits:16,20)

What more useful information can I provide?

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.

BitWrangler wrote on 2023-03-06, 04:18:

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'll edit the post.

rasteri wrote on 2023-03-05, 17:23:

Any idea what CPU/chipset is the last one with a normal BIOS?

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.