PCI cards cannot handle ISA DMA, a compatibilityTSR must be able to capture the writes to DMA controller which necessitates entry into protected mode. Then it can capture all the DMA controller writes and initiate sound playback on the actual hardware.

If I understand what you suggest right is that a sb emulation TSR all have to do is capture the DMA call and that would explain it's small 2~5kb footprint. I can agree that DMA writes need the processor to be in virtual mode for being intercepted, but does that mean it could be possible to emulate prior soundblaster cart that did not used DMA ?

I think if that was true then it would had been done already so while I am very grateful you took the time to answer my question, Tiido, I think there is something more to it about opl and pcm output.

ESSsolo1 does not require emm386 loaded.

ElBrunzy wrote on 2021-01-16, 16:04:

I think all pci soundcard that provide soundblaster emulation require the use of having the cpu in virtual 8086 mode.

No, not all PCI soundcard. Some have built-in port trapping and DMA snooping logic and do not rely on CPU virtual 8086 mode to do so. From a technical perspective, this works for any PCI soundcard design willing to spend the silicon for SB emulation on chipsets with PCI as the north-south link. Both the north-bound DMA and the south-bound port I/O will pass through PCI.

Only for newer generations of chipsets where PCI was demoted to the south, then this no longer works reliably.

Pure hardware solution requires chipset support, and all that support is variable within old chipsets and completely absent in things past Pentium III era. For example with many chipsets, access to a chipset peripheral such as DMA controller will not be visible on PCI bus so there isn't anything to snoop, the chipset knows this request is for a base peripheral and forwards it directly to it. There are some cool things like DDMA and PC/PCI but all of these require chipset support...

Stuff like Covox etc. are purely IO based devices and that is not any kind of problem as long as chipset doesn't get in the way. LPT is a base peripheral and doesn't necessarily appear on PCI bus...

oh wow now that's good news and thank you a lot for you very professional explanation. Now we will need to build a list of pci soundcard that provide that emulation in real mode. I think it's safe to say that the sblive does not. I have a yamaha 724 and now I'm totally wondering if it does. Post result later, can you tell us more about that dma bridge chip ?

ALS4000 provides SB16 (and SBPro in stereo) in real mode.
The utility from Avance Logic is memory-resident, but there's also a third-party non-resident utility.
Doesn't use PC-PCI connector (a.k.a. SB Link).
But it does require chipset support.
See also - The ALS4000 PCI Sound Card - PCI SB Compatibility in Newer Systems

yes I'm not surprised you bring that excellent malik thread and I always wondered about that sb link thing. Are you suggesting it is important in the sb emulation virtual real mode equation ?

solo1 does not require sblink.
yamaha pci-cards require emm386.

Aureal Vortex cards do not require EMM386 either, as far as I know. They are very underrated cards in my opinion. Decent wavetable music in Windows, good DOS compatibility without EMM386, waveblaster header, digital output on some (SQ2500) and impressive A3D effects in supported games (though it can be a matter of taste and the quality of the implementation in each game).

ADLIB/FM sounds bad on AurealVortex.

dr.zeissler wrote on 2021-01-18, 12:32:

ADLIB/FM sounds bad on AurealVortex.

But not as bad as on the AudioPCI !?
Creative ES1371 or ES1373 sound card.

😀

ElBrunzy wrote on 2021-01-16, 16:04:

I think all pci soundcard that provide soundblaster emulation require the use of having the cpu in virtual 8086 mode. This disable running good titles as zone66 video game or crystal dream ][ demo, to name a few. So I guess it was somehow impossible to provide sb emulation while having the cpu in real mode and I would like to know why.

if you can use SB-Link Connector on Mainboard it will work without V86 Mode.

The bottom line is that you need some form of virtualization or code patching.

Virtualization can be hardware-assisted as in Virtual 8086 mode, which emulates real mode, or as provided by VT-x and AMD-V which go far beyond that but require a much more recent CPU.
The dedicated interception mechanisms for Sound Blaster access would count as hardware-assisted virtualization, as well.

Code patching can be done either manually or in an automated fashion, namely by replacing relevant hardware accesses with function calls.
Purely software-based virtualization basically does the same, but dynamically at run-time. The best example is probably old-fashioned VMware.

The problem at hand is that no such virtualization software exists for pure DOS, which is why you have to resort to manual code patching for protected-mode games that do not use a well-known DOS extender.

There is the dosemu2 project, which supports hardware-assisted virtualization (at least on Linux hosts, through KVM). It will emulate VGA and Sound Blaster 16, and should work with protected mode games as well. Unfortunately, compatibility is not nearly as good yet as for instance DOSBox. But it is under early development. It is, to my knowlege, the only open emulation/virtualization software that is optimized for running games while using hardware-assisted virtualization instead of full CPU emulation in software.