Thank you very much for offering you help FGB, but I think we have all the data we need, including latest Rev.06.
The older Rev.04 tested by kixs shows the same DSP behavior as all later revisions right up to the CT2600.

I'm rather late to the party, but I do want to add that my test results on my CT1330A rev 5 fall in line with the results others have reported on their CT1330As, no reverse stereo for Wolf 3D & Tie Fighter, reverse stereo for Descent and Epic Pinball, square wave (not sine wave!) sound out always of left speaker for sbtest.exe. Good job exposing the myth and identifying a weakness in the compatibility of the clone cards.

Oh, and if you want some real samples of GUS vs. SB Pro, just check out my latest blog entry. The ideal emulation of DOSBox in this case presents a very "distorted" picture of how the real cards sounded when pitted against each other.

Thank you very much for reconfirming Great Hierophant.

I've heard the GUS samples in your blog and saw the discussion about it here on Vogons.
It is hard to believe these two actually released in the same years, the GUS is WAY ahead in sound quality to the SBpro.

The discussion about this matter and DOSBox continues in this thread: DOSBox emulation of the SBPro is reversed to the real hardware.
Hopefully it will be fruitful.

James-F wrote:

It is hard to believe these two actually released in the same years, the GUS is WAY ahead in sound quality to the SBpro.

Yup, and it's not that the GUS is particularly good for that era. The SB Pro is particularly bad. If you listen to how an Amiga from 1985 sounds... Noise-free, good clarity, great stereo separation etc. And by the time the SB Pro came out, you could pretty much buy an Amiga 500 for the price of the SB Pro. It's insane.
I literally went back to the store with my SB Pro after I bought it, since I thought the noise and distortion of the card meant that it was broken. Turns out it was supposed to sound that bad.

Scali wrote:

I literally went back to the store with my SB Pro after I bought it, since I thought the noise and distortion of the card meant that it was broken. Turns out it was supposed to sound that bad.

Hehe 🤣 , you still can't deny that 100% of DOS games work with the SBPro, reversed or not.
Well what did you expect, pristine Discman (90s) quality from interleaved-stereo 8bit 11kHz samples in DOS games? 😀

James-F wrote:

Hehe 🤣 , you still can't deny that 100% of DOS games work with the SBPro, reversed or not.

Oh yea, for years I ran my 486 with an SB Pro 2.0 and a GUS MAX. I would say it's the best of both worlds:
The SB Pro 2.0 gives you perfect compatibility with AdLib and earlier SB cards.
The GUS works great for newer games that support 16-bit audio, MOD/XM/MIDI and all that. And for demos of course.
The fact that it's a GUS MAX means you also have a 16-bit ADC/DAC which is useful for Windows, and can even be used in certain software that is WSS-compatible.

Sorry about not participating further.. I've been feeling a good bit under the weather physically and sleeping too much the past couple days. So you don't need testing any further from my CT1330A?

No need to apologize, real life first, Vogons later.
No further investigation is needed, all is concluded with an even earlier Rev.04.
Thank you very much for your help kithylin.

Originally I thought my Pro 1 card was unique because it did not appear to suffer from the reverse stereo issue in Epic Pinball. However, I had physically reversed the stereo on the cable to the speaker because I was recording the GUS ACE 1.0 playback at the same time and the ACE 1.0 does have a hardware reverse stereo issue. I did not think of the reversal until someone had identified EP as having the bug.

Great Hierophant wrote:

I did not think of the reversal until someone had identified EP as having the bug.

Not a bug mind you, just carelessness.
The SB16 is perfectly fine in EP, the devs simply didn't bother to test with a SBPro or put a reverse switch for it, this is the worst case scenario.
BTW most computer speakers back then did not have RCA jacks but a simple 1/8" plug, therefor to reverse the stereo one had to physically move the speakers just for these games. 😵

More thorough development would have tested all the cards the game supports and adjust the sound engine to the card abilities like Doom, or at least include a reverse switch like Tie Fighter or Duke3D for example which already adapted for the SBPro and don't need to enabled the reverse switch anyway.

So there are several types of games:
1. The game is tested with a SBPro and adapted to it without having a reverse switch (Doom, ROTT, LBA, Quake).
2. The game is not adapted for the SBPro but has a reverse switch (Descent, Transport Tycoon, MPXPlay, OpenCP).
3. The game is adapted to the SBPro and has a reverse switch just in case (Tie Fighter, Duke3D), this is the best of both worlds.
4. The game is not tested with the SBPro and doesn't have a reverse switch (Jazz Jackrabbit, Epic Pinball, Carmageddon, F22), yet still has a SBPro Stereo option. 😐

The Aztech NX Pro was very popular replacement for the SBPro but it had its stereo Digital sounds reversed to the real Sound Blaster Pro (CT1330A & CT1600), but OPL3 and CD were correct.
This probably generated a lot of confusion back then because its popularity as an excellent but cheaper SBPro clone, and most probably was the cause of the "Reverse Switch" in some games.

I think this information is relevant in this thread too, I believe it was probably a big part of creating the reversed stereo issue back then.

From 1993 PC Magazines on Google Books:
* Sound Blaster Pro Deluxe = CT1600... marketing strategy.
* Sound Galaxy NX Pro Extra is the SBPro2 clone.

Sep 93:

Dec 93:

Of interest is the price of the Gravis Ultrasound, which was much cheaper than a Sound Blaster 16 and practically the same price as a Sound Blaster Pro.

Granted, it didn't offer proper Sound Blaster compatibility, but if you wanted MIDI, then you could buy this card for much cheaper than a Wave Blaster and use it in conjunction with a Sound Galaxy NX Pro.

jesolo wrote:

Of interest is the price of the Gravis Ultrasound, which was much cheaper as a Sound Blaster 16 and practically the same price as a Sound Blaster Pro.

REALLY interesting is that the GUS cost less than it often sells now 🤣

PhilsComputerLab wrote:

jesolo wrote:

Of interest is the price of the Gravis Ultrasound, which was much cheaper as a Sound Blaster 16 and practically the same price as a Sound Blaster Pro.

REALLY interesting is that the GUS cost less than it often sells now 🤣

Yes, must be one of the few cards that actually kept pace with inflation. 🤣

Roland Sound Canvas Module - $279 vs Creative Wave Blaster - $235. Someone who thought they were going to get something equivalent to the Roland and save a few bucks must have been kicking themselves. Note the drop in price three months later of the Creative product.

Yeah, the price drop of the Wavetable is dramatic for a couple of months.
In the 1995 issue the SBPro is no longer for sale and there is a Wavetable II.

Go to Google Books and search for "Aztech NX" "or Sound Blaster Pro", "sound canvas" "VGA card" etc... then just click the edition of PC MAG you want to read.
Very nice period correct reviews of various cards and prices.

For example: SBPro advertisement from Oct 1991
At a devastating price of 299.95$ 😁

Man, I love that google actually scanned these..

Not sure if I should resurrect this older thread but since I recently picked up a Rev 2 CT1330A I thought I would add my results to the list.

SBCheck:
DSP version 3.01
Sound Blaster Pro 1 Stereo 8-bit board... use SBPro.ADC driver.

SBTest:
1. I heard the tone out of the left speaker, and if I turned the volume up I could hear something out of the right.
2. Heard the same tone/sound from the same speakers in the second part.

Dark forces:
I didn't have easy access on this machine to any of the games but I did have a copy of Dark Forces nearby so I installed it and ran the setup. Stereo reverse was set to 0 and the sound panned from left to right.

It is currently placed in a 386 dx/40 machine so it has a hard time with "newer" dos games. I have a few other machines I could put it in (486, Pentium) so if you think it would help with the cause I could do that.

IRQ2 is a bad idea on a 286 or newer (AT-class).
This is because they introduced a second interrupt controller on the AT, and it is 'cascaded' by connecting it to IRQ2 on the first controller.
I'm surprised it even works correctly.
I would advise you to configure it either to IRQ7 (default on early SBs, shared with LPT1, this would have been the factory default on a CT1330A), or IRQ5 (default on later SBs, I believe starting when the SB16 was launched, shared with LPT2), to avoid compatibility issues.

The 'real' IRQ2 line is actually connected to IRQ9 on the second controller on an AT. So if software isn't aware of the difference between an XT and an AT, the card probably won't work correctly.

Scali wrote:

The 'real' IRQ2 line is actually connected to IRQ9 on the second controller on an AT. So if software isn't aware of the difference between an XT and an AT, the card probably won't work correctly.

Yes IRQ9/2 can be an issue with some software. But for standard things it might work just fine. Non-AT aware software just hooks to IRQ2 vector (int 0x0A) as usual, and when card raises IRQ2 which is really IRQ9 on AT machine, interrupt 0x71 is triggered and it points to AT bios routine that acknowledges the PIC at port 0xA0 and calls/jumps to int 0x0A vector to run the hooked code which runs as usual and acknowledges the PIC at 0x20 like before.

Jepael wrote:

Yes IRQ9/2 can be an issue with some software. But for standard things it might work just fine. Non-AT aware software just hooks to IRQ2 vector (int 0x0A) as usual, and when card raises IRQ2 which is really IRQ9 on AT machine, interrupt 0x71 is triggered and it points to AT bios routine that acknowledges the PIC at port 0xA0 and calls/jumps to int 0x0A vector to run the hooked code which runs as usual and acknowledges the PIC at 0x20 like before.

Ah makes sense! I didn't know the AT BIOS had a default handler for compatibility.
I guess things will be fine then (aside from the extra overhead) as long as other software doesn't break that int 0x71 handler.
Still, I'd use IRQ7 for maximum compatibility. I've run into some software where the IRQ was hardcoded.