DOS ain't dead

Hi,
according to recent discussions on Vogons (e.g. here http://www.vogons.org/viewtopic.php?f=62&t=61238 ) I found a working solution of SB emu for modern motherboards (intel core based, PCIE+PCI) as my Gigabyte GA-P67-DS3-B3 with core i7-2600K. It's well known that Creative SB Live/Audigy SB emulation DOS driver is no longer working on PCIE motherboards. In the best case Adlib emulation may work but no SFX. No way to make it working.
But there emerged that 2 old forgotten PCI soundcards use some different and better SB emulation drivers for DOS that works even on modern MBs. They are Yamaha 72x/74x and Aureal Vortex AU88x0. It is still possible to buy them on eBay. I was very excited about this info so got the YMF724, YMF744 and AU8820 and test them: http://rayer.g6.cz/hardware/gap67ds3.htm#DOS_SBEMU (sry, CZ-only, use trans, tables are self-explanatory). So in my case I can now run games like Doom, Qauke, Blood, Duke3D, Sand Warrior and some demos with native sound and high resolution (if available) without worying about slow DosBox emulation.
One disadvantage is that those soundcards doesn't support WaveTable synth only FM synth. While Yamaha FM synth sounds quite good the Aureal Vortex FM synth sounds ugly. Fortunatelly there is a solution. I have build the DreamBlaster (using SAM2695 chip) external WaveTable synth that is feed by MIDI out from game port of the soundcard and feeding this sound back to line-in and mix it with SFX.
I know that most modern MBs now don't have PCI slots but there is a possibility it would run via external PCIE2PCI bridge. In my case the intel P67 chipset also lacks native PCI support and it use onboard ITE IT8892E PCIE2PCI bridge. So it shouldn't matter if the bridge is onboard or on a PCIE card. More testing is needed. Till now, it's confirmed these soundcards works on intel X58, H55 and P67 chipset.

For Japheth: I found a strange behavior that when Yamaha TSR DSDMA.EXE is loaded and I use JEMMEX in my config.sys I got this error from DOS4GW extender when trying to run a game:
"DOS/16M error: [17] system software does not follow VCPI or DPMI specifications Spawn Error: Error 0"
It was figuerd out that disabling VME by NOVME JEMMEX option solve this problem. Maybe some incompatability how JEMMEX use VME?

---
DOS gives me freedom to unlimited HW access.

> For Japheth: I found a strange behavior that when Yamaha TSR DSDMA.EXE is
> loaded and I use JEMMEX in my config.sys I got this error from DOS4GW
> extender when trying to run a game:
> "DOS/16M error: [17] system software does not follow VCPI or DPMI
> specifications Spawn Error: Error 0"
> It was figuerd out that disabling VME by NOVME JEMMEX option solve this
> problem. Maybe some incompatability how JEMMEX use VME?

I find it more likely that the TSR (DSDMA.EXE) intrudes the V86-monitor address context. This can only be done in a "hackish" way, because there is no API for that. Such a program, if it isn't aware that VME exists, may cause troubles. The V86-monitor can do nothing about that ( except to disallow intrusion ).

Does sound work for protected-mode programs only or also for real-mode progs?

You could also try out what hdpmi may say if used instead of dos4gw. You might have to start it with "hdpmi32 -i -x" to be "fully" dos4gw compatible.

---
MS-DOS forever!

> I find it more likely that the TSR (DSDMA.EXE) intrudes the V86-monitor
> address context.

Yes it may be rational explanation. DSDMA probably do some V86 magic. So you mean that when VME is used by JEMM then the v86-monitor run a bit different way that conflicts with DSDMA tampering approach while if VME is not used it do it correctly? The DSDMA.EXE is dated 13.5.1999 maybe that VME was not exist yet. Do you think it could be pathed to be VME compatible? Unfortunatelly no sources available. I can only run it through IDA DASM if you are interested in what it does. I didn't tried it with a realmode game as I don't remember one that use SB and run realmode.

BTW the TSR of Aureal Vortex ASP4DOS.COM doesn't require v86 mode but it also interfere with some pmode demos that hangs/crashes so it's not 100% SB emulation but for dos4gw games it seems to work well.

---
DOS gives me freedom to unlimited HW access.

Seems that VME was here since Pentium from '90. Here's some info, maybe it clears something about VME support detection: http://www.rcollins.org/ddj/May98/May98.html
From DASM of DSDMA.EXE I can see it only reads CR4 on 2 places (mov eax, cr4) no write to CR4.

---
DOS gives me freedom to unlimited HW access.

> Seems that VME was here since Pentium from '90. Here's some info, maybe it
> clears something about VME support detection:
> http://www.rcollins.org/ddj/May98/May98.html
> From DASM of DSDMA.EXE I can see it only reads CR4 on 2 places (mov eax,
> cr4) no write to CR4.

It first appeared in the Intel Pentium (aka, 586) in 1993, AFAIK, so "V86 Mode Extensions" mostly just meant faster (non-virtual) "IF" (interrupt flag) handling. But I'm no systems engineer, so I dunno exactly. (No, I didn't really read the above article, a bit too technical for me.) IIRC, none of the other EMM386s support VME since they were too old, thus Japheth was probably the only one to add such support.

And there were other Pentium quirks (bugs in early models), e.g. Undocumented RDTSC.

> you mean that when VME is used by JEMM then the v86-monitor run a bit
> different way that conflicts with DSDMA tampering approach while if VME is
> not used it do it correctly? The DSDMA.EXE is dated 13.5.1999 maybe that

VME in Jemm is used only to provide a "shortcut" for most (software) interrupts in v86 mode, because it avoids the cpu having to switch to ring0 protected-mode.

The "virtual interrupt"-stuff isn't used at all and isn't needed, because the v86-code runs CLI/STI/INT/IRET/PUSHF/POPF instructions in full speed.

> I didn't tried it with a
> realmode game as I don't remember one that use SB and run realmode.

Keen 4 for example.

---
MS-DOS forever!