I've noticed that on previous generation cards (DSP v3.x and DSP v2.x) the crystal of the 8052 MCU is 12MHz - I wonder is it possible Creative engineers made some bug similar to this one:

Fixing the Roland CM-500 Vibrato Bug

i.e. forget to fix some clock-dividers in the code, when they migrated to 24MHz crystal (I kind of doubt DSP 4.x is complete re-write and not just developed on top of the older DSP code) . also, I think good question to be asked is - why in the 1st place such migration to 24MHz was needed?

mattw wrote on 2023-10-18, 01:00:

also, I think good question to be asked is - why in the 1st place such migration to 24MHz was needed?

I have a hunch for that one: ADPCM. On all sound blasters before the SB16, the 8-bit DAC was directly available on one 8-bit output port. On the SB16, you need to tunnel DAC values through the bus interface unit, instead of doing just a port write. As ADPCM decoding is implemented using a timer interrupt (or a DAC port empty interrupt on the SB16) which runs in background, just as 0x14 and 0x1c playblack commands are, too, there is a lot of interrupt handling overhead, and adding the X-Bus overhead for the DAC write in the ADPCM decoder might make the highest ADPCM rates that works on an SB 1.0 fail on an SB16 if the DSP clock isn't increased.

mkarcher wrote on 2023-10-18, 06:24:

... might make the highest ADPCM rates that works on an SB 1.0 fail on an SB16 if the DSP clock isn't increased.

interesting, maybe I add 2 crystals (12MHz and 24MHZ) and switch between them, that allows easy way of testing what works and what not in 12MHz case - like the "oscillator-switch-mod" I saw user @jaffa225man posted here on Vogons regarding Roland device:

mattw wrote on 2023-10-18, 01:00:

I've noticed that on previous generation cards (DSP v3.x and DSP v2.x) the crystal of the 8052 MCU is 12MHz - I wonder is it possible Creative engineers made some bug similar to this one:

Fixing the Roland CM-500 Vibrato Bug

i.e. forget to fix some clock-dividers in the code, when they migrated to 24MHz crystal (I kind of doubt DSP 4.x is complete re-write and not just developed on top of the older DSP code) . also, I think good question to be asked is - why in the 1st place such migration to 24MHz was needed?

1.xx, 2.xx, 3.xx fw is the same - it is very similar, with little patches/additions. DAC was directly coupled to DSP, and DSP pins was used to control all process. That was fast.

With 16 bit SB, they can't attach stereo 16 bit DAC directly to DSP. New hardware - bus interface chip was designed to do all work - handle automatic playing of 16/8 mono/stereo buffers via dma.
DSP is used to program and control this BIC.
But you have many x-bus registers to program, new code, e. t. c.
Code can't be fitted to 4k ROM of '51.
'52 was better in all aspects - 8k ROM, 256 bytes of ram (64/128 bytes was used as midi in buffer), 24 mhz clock.
As many thing on previous fw was fast, with new fw that was done via slow x-bus exchange, and high 24 mhz speed helps.

mkarcher wrote on 2023-10-18, 06:24:

mattw wrote on 2023-10-18, 01:00:

also, I think good question to be asked is - why in the 1st place such migration to 24MHz was needed?

I have a hunch for that one: ADPCM. On all sound blasters before the SB16, the 8-bit DAC was directly available on one 8-bit output port. On the SB16, you need to tunnel DAC values through the bus interface unit, instead of doing just a port write. As ADPCM decoding is implemented using a timer interrupt (or a DAC port empty interrupt on the SB16) which runs in background, just as 0x14 and 0x1c playblack commands are, too, there is a lot of interrupt handling overhead, and adding the X-Bus overhead for the DAC write in the ADPCM decoder might make the highest ADPCM rates that works on an SB 1.0 fail on an SB16 if the DSP clock isn't increased.

I completely agree with your arguments, Adpcm is main problem on 12mhz, as it is computationally complex, and sb16 fw code is generally slower then previous versions.

Currently, analyzing DSP 3.02, i found a way to significantly lower jitter in high-speed DAC modes. It could be useful in all games (using high-speed mode, of course).
Is anyone interested in this modification ?

(DSP 3.xx is SB Pro 1/2, and i think '52 MCU can be used)

how do i read the older versions? i always wanted to confirm that aztech cards use creative dsp code.
i have a ton of aztech cards with 3.xx and 4.xx reported dsp versions (maybe 2.xx but i cant remeber).

DerBaum wrote on 2023-10-18, 19:20:

how do i read the older versions? i always wanted to confirm that aztech cards use creative dsp code.
i have a ton of aztech cards with 3.xx and 4.xx reported dsp versions (maybe 2.xx but i cant remeber).

For 4.xx, sbdump must work if fw code is same as in creative.
Or you can use sbcrack stage 1.
Be warned ! if code differs, result can be unpredictible, use at you own risk.

More safe way is to use early sbdump, what only dumps RAM in file, and send me to analyze - is it looks like real creative code, or not. This is the best way to start.

I tested 4.16 on a CT1740. Apart from making an amusing screenshot it worked fine but still clicked in DOTT.

maxtherabbit wrote on 2023-10-19, 00:23:

I tested 4.16 on a CT1740. Apart from making an amusing screenshot it worked fine but still clicked in DOTT.
20231018_201304.jpg

ı guess that more or less confirms the clicking is not DSP related and solvable with a code fix?

Obviously the clicking is not related to firmware. If some of you have factory modded SB cards with wire(s) and probably SMD capacitors attached additionallynear those wires would be good to test them if they are clickng too.

Maelgrum wrote on 2023-10-12, 18:16:

This is release of 'dsp_v413_maelgrum' version 5 Changes from classic V4.13: 1. Hanging note bug fixed 2. ADPCM decoding bug f […]
Show full quote

This is release of 'dsp_v413_maelgrum' version 5
Changes from classic V4.13:
1. Hanging note bug fixed
2. ADPCM decoding bug fixed
3. ALL interrupt handlers are fixed (PSW bug and R0 used before pushed to stack bugs)
4. Numerous small scale optimizations (LJMP to RET is changed to RET, e.t.c.)

Must be as stable as classic V4.13 - nothing is changed in logic of code.
And have some improvements, comparing to old patch 4.

I've been using this version on three different machines and it's working 100%. Seems like a solid stable release. May I suggest uploading it to vogons drivers before this thread gets buried?

maxtherabbit wrote:

I've been using this version on three different machines and it's working 100%.

So does this mean if we put this firmware in our own 89C51 onto a Snark Barker, that we have ourselves a Sound Blaster card?

I'm thinking about an Amiga version of the card as I've been working on an ESS one.

You still need rest of the SB too, and SB16 is much more than the older SB cards are.

PurplePigeon wrote on 2023-10-25, 11:00:

So does this mean if we put this firmware in our own 89C51 onto a Snark Barker, that we have ourselves a Sound Blaster card?

I am not sure what you mean, that thread is about SB16 DSP V4.x, AFAIK Snark Barker is not SB16 card and the Creative card that was made upon had DSP 2.x, which was dumped a long time ago by the author of Snark Barker and even disassembled and documented:

https://github.com/schlae/sb-firmware

to an extent that even interesting parts of it were translated to C:

SoundBlaster 4-bit ADPCM algo from SB v2.02 DSP dump by TubeTime

Plus DSP 2.x was 3rd party ported even to Atmel MCUs:

https://github.com/labs-lv/blasterboard

so, I guess I am completely not following what you mean...

PurplePigeon wrote on 2023-10-25, 11:00:

So does this mean if we put this firmware in our own 89C51 onto a Snark Barker, that we have ourselves a Sound Blaster card?

It isn't simple. The Snark Barker is a 1:1 clone of the original Sound Blaster card with DSP v2.xx.

SB16 does need additional components: Notably the mixer functionality which in most variants have settings for bass and treble, and 16-bit DAC which in earlier ones were from Asahi Kasei.

Gmlb256 wrote on 2023-10-25, 13:12:

SB16 does need additional components: Notably the mixer functionality

yeah and for example here:

https://github.com/crazii/SBEMU/pull/36/commi … 1eec12de34922db

you can see that the mixer registers are totally different between "CT1335 mixer (SB 2.0)", "CT1345 mixer (SB Pro)" and "CT1745 mixer (SB 16)".

Maelgrum wrote on 2023-10-14, 03:22:

Source code update.
small optimizations
with MACRO usage - much easier to read and understand, looks nicer

I'm currently using this version (calling it v6) and I noticed something odd after using it for a bit.

Namely 16-bit audio stopped working (hung) in some if not all cases -- namely Windows NT 3.51. When playing a WAV file of 22050 16-bit (Win2000's logon/logoff sounds are good examples) there was no sound and progress bar would not move, but I'm able to stop the playback. Playing a 22050 8-bit file works fine, though. I thought it might be a driver issue so I searched online and found a newer SB16 driver for NT3.5, but no difference.

EDIT: This issue does not occur with VBox's SB16 emulation on a test NT3.51 VM of mine (files in question played fine there) so software issues can be ruled out.

From DOS I also just tried TEST16 from DIGPAK and it hung at 16-bit mono test as well (8-bit works). However, when I tested 16-bit in SB16 DIAGNOSE everything's fine.

I wonder what might have been changed between these versions of modded DSP code. I haven't really paid attention about whether the same issue happens with the stock DSP chip, however... as I hardly played anything that really used high sample rate 16-bit audio samples...

LATE EDIT: Turned out this issue I'm having is invalid. I have also reproduced this same issue on a different, older system with a real AWE64 Gold (DSP 4.16). Audio samples beyond threshold would refuse to play on Windows NT 3.51.

Interestingly, on the same system, non-Creative cards like YMF718 and ALS007 can play the same audio files just fine.

LSS10999 wrote on 2023-10-26, 13:24:

I'm currently using this version (calling it v6) and I noticed something odd after using it for a bit. […]
Show full quote

Maelgrum wrote on 2023-10-14, 03:22:

Source code update.
small optimizations
with MACRO usage - much easier to read and understand, looks nicer

I'm currently using this version (calling it v6) and I noticed something odd after using it for a bit.

Namely 16-bit audio stopped working (hung) in some if not all cases -- namely Windows NT 3.51. When playing a WAV file of 22050 16-bit (Win2000's logon/logoff sounds are good examples) there was no sound and progress bar would not move, but I'm able to stop the playback. Playing a 22050 8-bit file works fine, though. I thought it might be a driver issue so I searched online and found a newer SB16 driver for NT3.5, but no difference.

EDIT: This issue does not occur with VBox's SB16 emulation on a test NT3.51 VM of mine (files in question played fine there) so software issues can be ruled out.

From DOS I also just tried TEST16 from DIGPAK and it hung at 16-bit mono test as well (8-bit works). However, when I tested 16-bit in SB16 DIAGNOSE everything's fine.

I wonder what might have been changed between these versions of modded DSP code. I haven't really paid attention about whether the same issue happens with the stock DSP chip, however... as I hardly played anything that really used high sample rate 16-bit audio samples...

A bump on this... looks like the issue I'm having may not be with the modded DSP FW as I also reproduced the issue when I switched back to the original Creative 4.13 DSP. Maybe something wrong with the card, or with the system. I'm still investigating, though it affected only a select few use cases.

Actually when I was modding the card (CT2950) I encountered another issue -- a small 10uF capacitor near the ISA connector key (C80) came off, and I replaced it with another 10uF one that's a bit bigger in size (5x11mm to be precise), but not too big to get in the way of anything. I wonder if the difference in voltage rating (50V compared to 18V of the original one) would cause any issue...

Either there's something wrong with the system config, or the card simply can't handle too high bitrates...

LSS10999 wrote on 2023-11-09, 11:04:

Actually when I was modding the card (CT2950) I encountered another issue -- a small 10uF capacitor near the ISA connector key (C80) came off, and I replaced it with another 10uF one that's a bit bigger in size (5x11mm to be precise), but not too big to get in the way of anything. I wonder if the difference in voltage rating (50V compared to 18V of the original one) would cause any issue...

No, that's not it. For practical purposes, there's no difference between a 16v 10uF cap and a 50v 10uF cap. There are times when it is preferable to use a cap with a lower voltage rating (sometimes capacitors within the same series with the same dimensions but with different voltage ratings will have a different ESR -- the cap with the higher voltage rating will have a higher ESR), but that's beyond the scope of this. That said, you can try to match the ESR of the original 4x7mm 16V 10uF cap (it was most likely higher) to see if that changes anything, but I doubt it.