As previously mentioned, the Wave Blaster II (aka WB2) documentation makes no mention of possible bidirectional MIDI communication. But while trying the Wave Blaster II control panel with various host cards out of desperation, an interesting thing happened: When attempting to go to the preset screen, I was informed that I couldn’t because “MIDI In is currently busy”.
Now that’s interesting because the MIDI implementation chart for WB2 makes absolutely no mention that the device might send anything. Then again the chart does not list system exclusive messages (SysEx) at all.
A quick look at WP2CPL.EXE with a disassembler confirmed that the control panel preset dialog only opens if the device responds to a SysEx. What does the SysEx do?
I wish I knew. What I do know is only the following. When this system exclusive message is sent
F0 18 40 00 01 07 00 F7
the Wave Blaster II responds with
F0 18 40 00 01 7F 07 00 0B 01 00 09 06 F7
(i.e. another SysEx, which is a fairly typical exchange in MIDI devices). The WB2 responds to variations of the SysEx but currently I have no sense of what the returned data means.
What’s interesting is that the WB2 also responds to some of the documented SysEx messages. That is, the input is documented, the response is not. For example,
F0 18 40 00 02 F7
is a SysEx that resets all patch parameters, and which the Wave Blaster II graces with the following response:
F0 18 40 00 02 7F 00 F7
Again, what that means is anyone’s guess.
Host Cards
With a known talking WB daughterboard, I can finally test the behavior of various host cards. Unsurprisingly, it is not uniform.
Let’s start with a really funny one. Sound Blaster AWE32 CT3900 (rev. 1 PCB, 4.13 DSP) fails to open the presets page in the WB2 control panel, and the DOS-based WB2MODE.EXE utility hangs when changing the device’s parameters.
Yet with my own hand-rolled MPU-401 utility, I can both send MIDI data to the daughterboard and receive responses back. Bizarre.
A rather old Sound Blaster 16 CT1740 (rev. 3 PCB, 4.04 DSP) behaves differently: There’s no response from the WB2, and the control panel preset page can’t be entered. But it does produce sound and WB2MODE.EXE does not hang either.
A newer SB16 Pro PnP CT2950 (rev. 2 PCB, 4.13 DSP) actually behaves properly. The WB2 responds, the control panel works.
A Vibra 16S PnP CT2890 (rev. 1 PCB, integrated 4.13 DSP) works without problems as well.
I also tested an old AWE32 CT2760 (rev. 1 PCB, 4.12 DSP) and found it’s behavior just as bizarre as that of the newer CT3900. My own utility works, WB2MODE.EXE hangs, and the WB2 control panel does not work.
I have not yet tried any non-Creative host cards. The current assumption is that most of them do not support bidirectional MIDI communication to WB daughterboards, but that is just an assumption.
Undocumented WB2MODE
Only later I discovered that the WB2MODE.EXE utility has an undocumented /VERSION argument. It produces the following output:
f0 18 40 0 1 7f 7 0 b 1 0 9 6 f7
Yes, that’s the exact same SysEx that the WB2 control panel wants to receive, only formatted differently. So perhaps it indicates the version of the WB2 chips and/or firmware. If anyone knows more, please share the information.
On the subject of sound cards, might I ask if you’ve ever investigated how Creative/Ensoniq’s later SBINIT.COM and SBEINIT.COM accomplished the routing of ISA requests to the PCI bus, or whatever it is they do? It seems no one has ever definitely established exactly why it works on older motherboards but otherwise tends to fail completely.
You’re talking about the ES1370/ES1371 chips (and their Creative equivalents) I assume? No, I didn’t investigate those in detail. Do you know what exactly constitutes an “older” vs. “newer” motherboard? Is a newer one perhaps a board with no PCI-to-ISA bridge?
I did investigate PCI audio somewhat and concluded that for DOS compatibility, it’s a monumental waste of time. At best it works as well as an ISA card but typically nowhere near that.
Indeed, it is difficult to determine exactly what feature is present on boards with which SBINIT.COM works that is lacking from boards on which it doesn’t. Some suggest the ICH5 southbridge is the critical distinction.
I don’t see significant changes between ICH4 and ICH5, but ICH6 no longer supports PC/PCI DMA. ICH5 may have also been the last chipset to have some sort of PCI-to-ISA bridge support (ICH6 only does LPC).
Here’s some good stuff: U.S. Patent 5,790,837. That talks about the ISA-based Ensoniq VIVO cards. It’s all horrible NMI-based emulation of the SB Pro and AdLib.
It’s not unlike Gravis’s infamous software-based emulation, the product of some idiot thinking “let’s save a few dollars on the chips and replace them with software!”, only to learn the hard way that the software is very expensive to support, never works 100%, and the end result is a board that doesn’t sell. Ensoniq did better only thanks to Windows (and Creative).
From the ES137x datasheets it’s obvious that those chips generate PCI SERR# signal to trigger NMIs for emulation as well. The problematic bit is probably DMA. Without knowing the actual details, it seems to me that the AudioPCI cards snoop (on the PCI bus) ISA DMA controller register accesses, and that doesn’t work with chipsets that do not support PCI-to-ISA bridges because the cycles never make it to the PCI bus at large. AFAIK the ESS PCI audio chips and a few others used similar techniques.
Oh, I just realized that ICH5 was also the last generation prior to the arrival of PCI Express.
Ensoniq/Creative’s PCI DOS solution was one of the most picky to get working. I think it used PC-PCI DMA. It did manage to emulate a OPL2/3 somewhat decently. The ESS PCI chipsets tended to have better DOS support (they used Transparent DMA on most systems). Anything newer than a Solo-1 had horrible OPL emulation though, but the card DID work under Windows 3.1 using SB Pro drivers, something Creative’s SB Live/Audigy emulation drivers couldn’t pull off.
Thanks, that’s some neat info.
If that’s what it comes down to, what would be the expected cutoff for VIA or AMD?
Since the topic of DOS Sound Blaster compatibility came up I’m curious if anyone knows if there are any PCI cards other than the CMI8738-based ones which have true hardware Sound Blaster compatibility and if they will work in systems with chipsets after ones with ICH5 ?
@ESS, Yamaha, Crystal, AdvanceLogic, OPTi… You will heard these names when you want to find a PCI soundcard with DOS compatibility.
Since PCI legacy compatibility with ISA-Style way to enable interrupts and using DMA isn’t part of the PCI specification, these cards will require some way to make it possible. The PCI sound cards with the best compatibility will always require Chipset Support, in the form of the PCPCI header (Yamaha/Creative ViBRA PCI offer), or an implementation of the DMA engine (ESS Transparent DMA, Intel Distributed DMA).
The cards that don’t use chipset support will always load a TSR and with use EMM386/NMI to accomplish the same, with variable degree of sucess.
My (limited) experience with PCI sound cards in DOS has been pretty uniformly bad, and I did most testing with old boards (430HX and 440BX chipsets). New boards have no PC/PCI or DDMA, so maybe something like ESS’s approach can work. Maybe this is a future project for me 🙂
The Yamaha chips are highly SB compatible and have a “real” OPL3 synth but only work right in older boards (ideally with SB-LINK).
IIRC the Forte chips are also OK. The Ensoniq and Sound Blaster PCI boards (incl. Live/Audigy) do not have hardware SB compatibility, ironically.
For those who can read German, this ought to be useful: ftp://78.46.141.148/docs/pc_hardware/pcisoundcards_v12.pdf
There is quite a bit out there about PCI sound cards and DOS.
http://www.flaterco.com/kb/audio/PCI/
http://www.vogons.org/viewtopic.php?t=24769
The biggest hurdle to emulating a Sound Blaster card on the PCI bus is going to be ISA DMA used for digital audio output, particularly with DPMI programs since a driver can’t trap hardware access using something like EMM386 under v86 mode. MPU-401 and OPL appears to be much easier to emulate.
Speaking of ISA DMA, I’m still curious how Sound Blaster compatible Microchannel sound cards handled it.
Ah yes, the flaterco stuff is pretty informative.
Ensoniq/Creative used an NMI (directly on ISA, via SERR# on PCI) to trap hardware accesses (with a little assistance from the chip), and used “interesting” tricks to ensure that they retained control even when a VCPI client switched to protected mode. DMA is probably still a problem though, especially when an application looks at the DMA status registers (which, to be fair, most don’t).
For real life experiences about PCI soundcard compatibility with DOS apps and Games, VOGONS site has threads and threads about stories of success or failures of many users testing a variety of card/motherboard/application combinations.
The flaterco stuff is interesting though it seems that I had much better success with the CMI8738 in real mode DOS on a Intel 865PE/865G chipset (ICH5). The CMI8738 is Sound Blaster Pro compatible without any special TSRs or device drivers and only needs to be initialized properly via the SETAUDIO utility though I had to patch it so that a configuration register is set to update the DMA address and count registers during DMA transfers since some games actually check them. Everything I tried worked except that there seemed to be a slight pitch difference (48000 Hz vs 44100 Hz perhaps ?)
Also the CMI8738’s native mode is much cleaner than the overblown AC97 or its successor Intel HDA.
“Speaking of ISA DMA, I’m still curious how Sound Blaster compatible Microchannel sound cards handled it.”
I think MCA was able to do 8237-style DMA directly, though with some limitations such as not supporting auto-init.