VOGONS


First post, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

In the last few days we have been testing here on Vogons real Sound Blaster Pros's CT1330A Rev.4 to 6, and CT1600 Rev.3 to 6.
Using various games and a SBTEST tool by Harekiet we found and concluded that all SBPro versions and revision did NOT have the reverse stereo bug nor do they flip the stereo with an extra byte before the stereo PCM transfer.

All the information and tests can be found here: SBPro1 CT1330A, lets solve the Reversed Stereo myth!
Summary is in the first post.

I ask of DOSBox developer (for lack of a better place) to look into this issue and fix the reversed SBPro emulation in DOSBox, and also remove the "extra byte" behavior because NONE of the real cards actually flip the stereo with it.
Also, SB16 hardware does NOT have interweaved stereo like the SBPro, so is will play in mono with interweaved SBPro stereo games.

Last edited by James-F on 2017-06-11, 04:12. Edited 3 times in total.


my important / useful posts are here

Reply 1 of 16, by keenmaster486

User metadata
Rank l33t
Rank
l33t

Well... why the heck did we ever think the stereo was reversed in the first place? Did this happen with various clone cards and not with real SBPro's?

World's foremost 486 enjoyer.

Reply 2 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

The only clone cards that is actually reversed is the Aztech NX Pro, all other clones that I've tested are like the original SBPro.
But, the clones DO flip the stereo with the extra byte, where the original don't.
The reason for that I believe is the original SBPro starts each new Stereo PCM stream from the left sample as it should, and NOT from the last buffered one like the clones.

For years and years DOSBox has been reversed to all known original SBPro cards, and emulated the extra byte flip which only the clones do...


my important / useful posts are here

Reply 3 of 16, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Thanks for testing it.
Removing "keep the byte" functionality actually makes things easier for us.

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

I take your post as the issue has been acknowledged and will be fixed in the near future with the forthcoming SVN build.
I really hope this will come to fruition and finally DOSBox SBPro emulation will be correct.

If you ask me, it would be wise to keep the "extra byte" behavior in a type called "sbproclone" because many people owned a clone and could not afford the original back in the 90s, but remove it from the sbpro1 and sbpro2 types. But then again, it might be completely unnecessary if we strive for accurate emulation of the hardware.


my important / useful posts are here

Reply 5 of 16, by Sammy

User metadata
Rank Oldbie
Rank
Oldbie

I have an SB16 and its Connected to an amplifier.

I always had reversed Signals. (left sound on right speaker, and right sound on left speaker)
Thought the Card has a bug.

But a few month ago i found out, there a to type of 3,5mm to cinch cable: one for devices like mp3 player,discman,etc. and and one for Soundcards.

On the cable for soundcards there is the right channel connected to white connector, on normal cable to red connector.

So the card was not faulty, i just used the wrong cable all the years.

Reply 6 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

We are way beyond that issue Sammy, have a look in the first post link.
We are talking about how the DSP of the SBPro processes Stereo PCM signal and whether an extra byte has an effect on the SBPro before the actual stereo stream.
Thanks anyway.


my important / useful posts are here

Reply 7 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

A Sound Blaster DSP is something of a black box: you can try to infer what it does, but you don't really know.

A leftover sample on odd-sized stereo transfers is a situation that has to be dealt with in some way, and there is evidence that it can't just be discarded, at least not in all conditions.

For example, the WOWII 1.31 player's SBPro-specific mode. For whatever reason, it uses an odd-sized transfer by default, and discarding the remainder results in the stereo channels bouncing from side to side with each subsequent transfer.

Reply 8 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

ripsaw8080 can please be more specific, I'm trying to recreate what you call "stereo channels bouncing from side to side with each subsequent transfer".
WOWII and OCPlayer mod players are consistent on the hardware SBPro and I don't hear what you call "bouncing from side to side" phenomenon, the song plays at the same side each time.
What sound card did you test it on, and what you hear?

We thoroughly tested the hardware SBPro behavior with games and software in the first post link.
Also the small software by Harekiet I linked in the first post reveals much about the SBPro, which also been tested on CT1330A and CT1600 models in the linked thread.

Please look into it.

Last edited by James-F on 2016-10-27, 05:25. Edited 1 time in total.


my important / useful posts are here

Reply 9 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Of course you won't hear it on real hardware. The point is that WOWII provides evidence that you can't just discard the remainder, because you hear the channel bouncing if you do that in DOSBox.

Reply 10 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Oh, your referring to Qbix remark about Removing "keep the byte" functionality in DOSBox.

Of course there has to be some buffer or continuity DURING the PCM Transfer, else is will go crazy like you describe; but this buffer should close at the end of the transfer, and start each new PCM transfer with a new buffer.
I'm talking from my point of understanding and my observations with Harekiet SBTEST software.

The SBTEST utility doesn't flip sides with the original SBPro (any of them), but does with clones like YMF71x, Aztech SG 16 Pro, or DOSBox, so it seems the buffer remains open like it is one continuous transfer.

According the the Sound Blaster Programming Guide the DSP should send an Interrupt after the transfer.
Page 41, or just search for "restore the original interrupt service routine".
In page 54 there is a section of the proper procedure of "At the end of date transfer" for 8bit Stereo High-Speed Transfer.

Filename
Sound Blaster Hardware Programming Guide.pdf
File size
485.41 KiB
Downloads
81 downloads
File license
Fair use/fair dealing exception

This is the reason I assume SBTEST flipping sides (it shouldn't), because of "improperly ending a transfer".

EDIT:
There is a command called "Release the allocated DMA buffer" at the end of a Stereo High-Speed Auto-Initialize Transfer which does not exist on the Stereo High-Speed Single-Cycle Transfer.
Can it be that the clone cards and DOSBox use the single-cycle procedure for all stereo transfers, without releasing the buffer?


my important / useful posts are here

Reply 11 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
James-F wrote:

Oh, your referring to Qbix remark about Removing "keep the byte" functionality in DOSBox.

Well, you wrote 'remove the "extra byte" behavior' in your opening comment, but perhaps you were parroting it.

James-F wrote:

Of course there has to be some buffer or continuity DURING the PCM Transfer

That's too obvious. Of course I'm referring to between transfers as well. WOWII uses single-cycle transfers, and the channel bouncing occurs on each successive transfer if the residual byte from the previous transfer is discarded.

Anyway, I don't think the remaining byte behavior is the culprit. The idea I would like to test is that the first byte of the first transfer after a reset is thrown away, regardless of stereo or mono because the DSP probably doesn't even know about that. It would account for the rumors of the buggy SBPro DSP and talk about the first byte being "eaten" and so forth, and it seems like it would shift the left/right pattern so the SBPro emulation matches real hardware.

Reply 12 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

We definitely should test that with a real SBPro, I will gladly help to test this on the real hardware.
Can you write a small test software like sbtest.exe?


my important / useful posts are here

Reply 13 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Harekiet's program may already test my idea, or at least some permutations of it, as long as there are resets before each test. However, one-byte transfers are unusual and could cause behavior that obscures or interferes with other behaviors, so I would also like to test with "normal" transfers.

BTW, it's probably not worth testing WOWII 1.31 on a real SB16 because it only uses SBPro-style stereo. I think later versions did support SB16 for stereo, though.

Reply 14 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Yes, Harekiet's software sends a reset before each test.
If you want to test this in a real game use QUAKE, it does exactly what sbtest.exe does before the second transfer (I assume).

If you look at the Quake column and the SBTEST column you'll see that quake behaves like the second test, while most other games behave like the first test (no extra byte).
Quake is reversed on the clone cards because is sends the extra byte, but not on the real SBPro.

Stereo Reverse Chart.png
Filename
Stereo Reverse Chart.png
File size
62.85 KiB
Views
2101 views
File license
Fair use/fair dealing exception

You probably have a way to debug and see what exactly Quake is doing, maybe you'll find the answer there.


my important / useful posts are here

Reply 15 of 16, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Bump, SBPro stereo is still reversed in DOSBox.

Harekiet's SBTEST.EXE plays twice on the left channel on the hardware SBPro1/2, but currently in DOSBox it plays once on the right then once on the left.
So DOSBox is reversed to the hardware AND needlessly obeys the singly byte switch, two bugs.
The hardware SB16 plays SBTEST.EXE in the Center, because it doesn't support interweaved stereo at all.


my important / useful posts are here