Duffman wrote:

could this help with PCI sound cards in DOS? […]
Show full quote

could this help with PCI sound cards in DOS?

ISA enable.This bit modifies the response by the bridge to ISA I/O addresses.This applies only to I/O addresses that are enabled by the I/O base and I/O limit registers and are in the first 64 KB of PCI I/O address space (0000 0000h to 0000 FFFFh). If this bit is set, then the bridge blocks any forwarding from primary to secondary of I/O transactions addressing the last 768 bytes in each 1-KB block. In the opposite direction (secondary to primary), I/O transactions are forwarded if they address the last 768 bytes in each 1K block.
0 = Forward downstream all I/O addresses in the address range defined by the I/O base and I/O limit registers (default)
1 = Forward upstream ISA I/O addresses in the address range defined by the I/O base and I/O limit registers that are in the first 64 KB of PCI I/O address space (top 768 bytes of each 1-KB block)

I think this would only help with operations against ISA I/O ranges so things like FM synth would work, and would not solve the fundamental issue (which is legacy DMA). The chipset is required to have certain capabilities (such as PC-PCI/DDMA) in order to enable uses of legacy DMA channels on PCI devices, which is required for DOS games to have functional SFX. Such capabilities were long gone from modern chipsets, although they may retain LPC DMA capabilities so one can still put a SuperIO (LPC-based) chip which in turn provides legacy ports such as PS/2, LPT and COM(UART). (NB: TPM also utilizes LPC bus for its operations)

1) It's well known for years that some new soundcards like SBL, SBA, HDA... works with native drivers in MPXplay, Q2DOS, HXDOS... but it doesn't use legacy access so it's irrelevant to SB emulation

2) ISA enable bit in the bridge probably enables subtractive decode for legacy IO adress that will be passed to PCI slot. This is needed for SB emu on Yamaha and at least Adlib should work then. But it doesn't mean that SB DMA and IRQ will work too, so just test it. You need to set this bit in DOS before loading Yamaha drivers.

3) The right PCIE-PCI bridge is not the only requirement for Yamaha to work. It's knownt that it works at least on my GB P67 with IT8892E but there are other MBs with IT8892E and Yamaha SB doesn't work there (may only Adlib work or nothing). So it depends on some other stuff like IRQ routing and BIOS/UEFI support (my MB is the last one with Award BIOS before GB swithched to UEFI). Nobody can state if it will work without trying it on real MB and Yamaha, so more testers needed.

how do i set the ISA Enable bit from within DOS mode?

The thread I linked to in my last post links to two utilities that can be used for modifying PCI registers under DOS. PCISET might be handy of you only going to change a single bit within a register.

LSS10999 wrote:

So generally speaking... sound cards can work under DOS if one knows how to write code to properly initialize and operate them (which is what device drivers do in other operating systems). The hard part is how to make it interoperable with Sound Blaster standards (which DOS games rely on).

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blaster addresses and catch and translate data request to modern cards calls without big latency and of course fake responses back to program so it would thing that SB is in the machine?
And other big if is there enough documentation about these request and modern cards to make translation working even when someone has enough skill to make it? Its there some HW limit, so SB feature which is not able to modern card make?
I thing that if such thing would be possible that it would be already done for Realtek HD and other cards, but i could be wrong.

RayeR wrote:

2) ISA enable bit in the bridge probably enables subtractive decode for legacy IO adress that will be passed to PCI slot. This is needed for SB emu on Yamaha and at least Adlib should work then. But it doesn't mean that SB DMA and IRQ will work too, so just test it. You need to set this bit in DOS before loading Yamaha drivers.

No, it is not. Subtractive decoding is an implementation specific feature. PCI/PCIE specs does not mandate such implementation. The spec simply allows such scheme to be implemented, otherwise the cycles would just Master-Abort.
The ISA enable bit tells the bridge if it should also decode ISA aliases in case of 10-bit decoding, otherwise the bridge would only ACK on the full 16-bit IO addresses from the IO BARs.

The whole story of SB/Adlib emulation lies in the capabilities of hardware to forward the SB/Adlib IO register range, so that the destination sound hardware can emulate the behaviors. This happens naturally on the original PC/286/386/486 ISA. During the Pentium PCI era, PCI soundcards sit between the north and south bridges. IO cycles would tunnel through the north bridge, pass over PCI and reach the south. So this still made the job of emulating IO registers simple, whether it was done through hardwired logic or internal firmware. It did not require complex hardware/software trapping logics.

As PCI got demoted down further to the south to make ways for bandwidth hungry peripherals (USB, SATA, GbE, PCIE RPs etc.), the IO cycles would no longer guarantee to pass over PCI and render the SB/Adlib emulation useless on the PCI soundcards. IO cycles targeting legacy blocks (PIC, PIT, DMAC etc.) can be consumed internally without having them show up on external buses.

ruthan wrote:

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blast […]
Show full quote

LSS10999 wrote:

So generally speaking... sound cards can work under DOS if one knows how to write code to properly initialize and operate them (which is what device drivers do in other operating systems). The hard part is how to make it interoperable with Sound Blaster standards (which DOS games rely on).

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blaster addresses and catch and translate data request to modern cards calls without big latency and of course fake responses back to program so it would thing that SB is in the machine?
And other big if is there enough documentation about these request and modern cards to make translation working even when someone has enough skill to make it? Its there some HW limit, so SB feature which is not able to modern card make?
I thing that if such thing would be possible that it would be already done for Realtek HD and other cards, but i could be wrong.

It MIGHT be possible IF the PCI card in question actually supports the legacy Sound Blaster and/or FM stuff natively. Then you would only
have to capture and redirect the correct stuff. Otherwise you would have to also incorporate some software emulation which would be specific to each sound chipset... AC'97 might be easier but it would again be software emulation.

ruthan wrote:

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blaster addresses and catch and translate data request to modern cards calls without big latency and of course fake responses back to program so it would thing that SB is in the machine?

Without any help from hardware, one can only do IO trapping using x86 CPU DR0-DR7 debug registers or setting up V86 mode with IOPL traps. These requires very complicated software programming. Obviously, the 1st method would fail if any games have anti-piracy/anti-hacking mechanism that would simply whack the debug registers. The 2nd method would simply fail for DOS protected mode games. Microsoft EMM386 had a specification for software to setup IO traps using EMM386. This in theory would work for any real-mode only games, or DOS protected-mode games that would behave nicely with DPMI specification to run at Ring 3.

All these endeavors of finding ways to implement IO trapping using only CPU infrastructure are, I would say, extremely complicated and unsustainable from software point of view. So as modern PCs become more powerful, emulation is the way to go.

Well, if you are thrilled with the challenges and have the will to tackle the problems with reduced scope and confined hardware software compatibility, then just go ahead. Wish you all the best 😀

cyclone3d wrote:

It MIGHT be possible IF the PCI card in question actually supports the legacy Sound Blaster and/or FM stuff natively.

No, this would not work universally. IIRC, PCI Express 2.0 no longer supports IO cycles. PCI Express 1.0 supports IO cycles in deprecated state that only device advertised as legacy device can have IO BARs and decoding IO cycles. The x86 port I/O mapped address space is a thing of past dinosaurs. In near foreseeable future, PCI Express will completely remove the IO read/write commands that were only used by x86, and it is possible that PCIE RP will not support downstream IO cycles.

> kjliew
Oh yes, I remember. I had a big problem with such IO aliasing when part of my SB Audigy IO range was aliased by VGA IO ports and then it failed to work on my Gigabyte - stupid BIOS enumeration. WinXP was smart enough to remap Audigy IO base to avoid conflict with aliased VGA. I didn't find why one could want the aliasing - for what the purpose is this setting damn good for, it's such stupid thing...
I changed that bit in my option ROM code to enable full 16-bit decoding and aliasing has gone and SBA works fine then...

--------

The problem with trapping and emulation is that SB emu code needs to run at higher privilege level hidden for user app. It's well suitable for real mode apps where v86 monior can trap IO and IRQ to fully emulation the SB on any HW. No problem. But it's problem for protected mode apps and games. Then you need something beyond protected mode - which means... the SMM or VMM. SMM way was used by AMD VSA and it worked fine but was abandoned years ago and nevr opensourced AFAIK. VMM implementations like VMware or Virtual box sucks with SB emulation as it is not in commercial scope of such VMMs and programming such code needs extra knowledges, maybe even NDA resctricted documentation...

cyclone3d wrote:

ruthan wrote:

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blast […]
Show full quote

LSS10999 wrote:

So generally speaking... sound cards can work under DOS if one knows how to write code to properly initialize and operate them (which is what device drivers do in other operating systems). The hard part is how to make it interoperable with Sound Blaster standards (which DOS games rely on).

Ok, but is DOS in pure theory capable to run some driver wrapper (TSR) as more modern OSes, which would be listen at Sound blaster addresses and catch and translate data request to modern cards calls without big latency and of course fake responses back to program so it would thing that SB is in the machine?
And other big if is there enough documentation about these request and modern cards to make translation working even when someone has enough skill to make it? Its there some HW limit, so SB feature which is not able to modern card make?
I thing that if such thing would be possible that it would be already done for Realtek HD and other cards, but i could be wrong.

It MIGHT be possible IF the PCI card in question actually supports the legacy Sound Blaster and/or FM stuff natively. Then you would only
have to capture and redirect the correct stuff. Otherwise you would have to also incorporate some software emulation which would be specific to each sound chipset... AC'97 might be easier but it would again be software emulation.

Not sure if one can write a HAL for sound cards then write SB emulation on top of it... given the fact that code for natively operating audio controllers are already present.

There's a caveat, though, that the native operation code known so far are mainly for DPMI usage (as the programs capable of doing so, including MPXPLAY and SETUPDS, require DOS extenders such as DOS4G, DOS32A) and may not be reliably usable for real-mode scenarios.

kjliew wrote:

Without any help from hardware, one can only do IO trapping using x86 CPU DR0-DR7 debug registers or setting up V86 mode with IOPL traps. These requires very complicated software programming. Obviously, the 1st method would fail if any games have anti-piracy/anti-hacking mechanism that would simply whack the debug registers. The 2nd method would simply fail for DOS protected mode games. Microsoft EMM386 had a specification for software to setup IO traps using EMM386. This in theory would work for any real-mode only games, or DOS protected-mode games that would behave nicely with DPMI specification to run at Ring 3.

If someone would really want to make it happen, it could use multiple methods, depends what user need. I guess that majority of code still could be reused regardless of method.

Otherwise we know that Virtual Box, Vmware or Qemu arent the way in short term and probably not even in long term. What about PCem? Can some sound guy review its sound implemetation and compare it and speed with Dosbox? It would be good enough for Rayers 1600x1200 Duke3D / Blood, but it could be better than Dosbox and there is also more friendly Windows 3.11 /95 /98 support, there is Glide too..