analog_programmer wrote on 2025-04-12, 07:39:

About a month before BuB mentioned the SB hanging note bug in one of his latest soundcard repair videos, I read this whole threa […]
Show full quote

Ozzuneoj wrote on 2025-04-12, 06:32:

Some questions I hope to find answers to: […]
Show full quote

Some questions I hope to find answers to:

• Are there any downsides to upgrading any specific models to any specific DSP version?
• What kind of chips are needed and what is the cheapest reliable way to find them?
• Where are the relevant firmware downloads and are there any cards that this shouldn't be done on?
• Is a standard TL866A suitable for this job?

About a month before BuB mentioned the SB hanging note bug in one of his latest soundcard repair videos, I read this whole thread. So I had time to research some details that were subsequently missing in his video with the hardware solution of this problem. I'll try to give some answers to your questions.

• DSP versions with hanging note bug (4.11, 4.12, or 4.13) can be exchanged with patched 4.13, custom 4.16 or original (bug-free) 4.16 versions. As far as I know original DSP versions 4.04 and 4.05 are bug-free.
• AT89S52-24JU, AT89S52-24JI, AT89S52-24JC, AT89C52-24JI or AT89C52-24JC chips from ali-baba-and-the-40-thieves, fleabay or whatever electronic components shop you prefer.
• You can find all the needed bug-free firmwares here: https://github.com/S95Sedan/CT1741_DSP/tree/main/firmware
• XGecu T48 works, so probably TL866A will do the job.

P.S. Watching videos < reading 😉

I'm a bit puzzled by the 4.17 one where it says "Removed Code Jumps (vector_dma_dac_adpcm*, dac_silence, vector_op5)(Needed for duke2 compatibility)"
Does that mean it *breaks* compatibility with duke nukem 2 or on the contrary it fixes some bug ?

Deksor wrote on 2025-04-14, 21:48:

I'm a bit puzzled by the 4.17 one where it says "Removed Code Jumps (vector_dma_dac_adpcm*, dac_silence, vector_op5)(Needed for duke2 compatibility)"
Does that mean it *breaks* compatibility with duke nukem 2 or on the contrary it fixes some bug ?

It seems like Duke Nukem 2 is unplayable with DSP ver. 4.17 (patched 4.16):

Re: The Soundblaster DSP project

b_riera wrote on 2024-04-01, 16:11:

Duke 2: *4.13 patched - level 1 loads fine. Played a little bit and no crashing but sometimes it could be a couple of levels in […]
Show full quote

Duke 2:
*4.13 patched - level 1 loads fine. Played a little bit and no crashing but sometimes it could be a couple of levels in before it crashes. It's definitely not any worse than unmodified 4.11 or 4.13. Could be totally fixed but not sure yet.
*4.17 unofficial - level 1 loads fine. Right after the first enemy, pressing the shoot button to blast the red/grey breakable wall immediately locks up the computer every time without fail. I've never seen this before but I've also never tried playing Duke 2 on an AWE64 in DOS. Guess I could try on my Win98 PII system in DOS mode.

Either way, patching the Duke 2 executable to use more conventional memory and replacing the digital sound files with 8bit uncompressed seems to have totally solved the annoying problems regardless of DSP version. Not sure how much of a problem this really is as it seems to occur only with this game for me.

Re: The Soundblaster DSP project

S95Sedan wrote on 2024-04-02, 15:52:

Yeah Duke2 is very prone to crashing when the first sound effect plays even with some of the original firmwares, seems to work f […]
Show full quote

Yeah Duke2 is very prone to crashing when the first sound effect plays even with some of the original firmwares, seems to work fine on CT1746 based cards but giving issues on CT1747 or newer cards.
Haven't really looking deeper into what exactly triggers it but surely theres gonna be a workaround for it.

Same for the dma clicking, still needs some more looking into, leaning towards the double 'nop' in one of the routines for fetching dsp data.
(dma_dac2_adpcm, dsp_input_data incase anyone else wants to do some digging.)

Re: The Soundblaster DSP project

b_riera wrote on 2024-04-04, 00:57:

Yeah Duke 2 was a no-go for me with a stock SB16 Value CT2770. The specific card is dead and gone so not sure what firmware version but I have in my head it was 4.11. I have two more CT2770 cards but haven't tried them because no wave blaster header so I'm not interested in using them.
I put Duke 2 on my PII machine with Win98 and an AWE64 CT4520 using DSP v4.16 and it works perfectly in proper DOS mode with CTCM initialised etc. Looks like it's just when the firmware is modified/used on the newer SB16 cards like my CT2230.

Anyway, I'm more than happy to test in the future with my cards should anybody continue work. Otherwise, the current modded 4.13 and 4.16 do plenty. Thanks!

Thanks for the clarification 😁

Deksor wrote on 2025-04-14, 21:48:

analog_programmer wrote on 2025-04-12, 07:39:

About a month before BuB mentioned the SB hanging note bug in one of his latest soundcard repair videos, I read this whole threa […]
Show full quote

Ozzuneoj wrote on 2025-04-12, 06:32:

Some questions I hope to find answers to: […]
Show full quote

Some questions I hope to find answers to:

• Are there any downsides to upgrading any specific models to any specific DSP version?
• What kind of chips are needed and what is the cheapest reliable way to find them?
• Where are the relevant firmware downloads and are there any cards that this shouldn't be done on?
• Is a standard TL866A suitable for this job?

About a month before BuB mentioned the SB hanging note bug in one of his latest soundcard repair videos, I read this whole thread. So I had time to research some details that were subsequently missing in his video with the hardware solution of this problem. I'll try to give some answers to your questions.

• DSP versions with hanging note bug (4.11, 4.12, or 4.13) can be exchanged with patched 4.13, custom 4.16 or original (bug-free) 4.16 versions. As far as I know original DSP versions 4.04 and 4.05 are bug-free.
• AT89S52-24JU, AT89S52-24JI, AT89S52-24JC, AT89C52-24JI or AT89C52-24JC chips from ali-baba-and-the-40-thieves, fleabay or whatever electronic components shop you prefer.
• You can find all the needed bug-free firmwares here: https://github.com/S95Sedan/CT1741_DSP/tree/main/firmware
• XGecu T48 works, so probably TL866A will do the job.

P.S. Watching videos < reading 😉

I'm a bit puzzled by the 4.17 one where it says "Removed Code Jumps (vector_dma_dac_adpcm*, dac_silence, vector_op5)(Needed for duke2 compatibility)"
Does that mean it *breaks* compatibility with duke nukem 2 or on the contrary it fixes some bug ?

In the 4.13-patch5 the end of some sections were replaced with code jumps.
This part breaks duke2 compatibility to some degree and thats why it was removed:

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
ljmp X008c ; Patch5: X008c ljmp

And replaced with this in 4.17:

vector_dma_dac_adpcm2_end: clr pin_dsp_busy pop isr_temp_storage pop dph pop dpl pop acc ; Fix: Restore 'pop PS […]
Show full quote

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
pop isr_temp_storage
pop dph
pop dpl
pop acc
; Fix: Restore 'pop PSW'
pop psw
reti

The removal of the jumps in code make it so duke2 should works properly on 4.17.

S95Sedan wrote on 2025-04-14, 22:42:

In the 4.13-patch5 the end of some sections were replaced with code jumps. This part breaks duke2 compatibility to some degree a […]
Show full quote

In the 4.13-patch5 the end of some sections were replaced with code jumps.
This part breaks duke2 compatibility to some degree and thats why it was removed:

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
ljmp X008c ; Patch5: X008c ljmp

And replaced with this in 4.17:

vector_dma_dac_adpcm2_end: clr pin_dsp_busy pop isr_temp_storage pop dph pop dpl pop acc ; Fix: Restore 'pop PS […]
Show full quote

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
pop isr_temp_storage
pop dph
pop dpl
pop acc
; Fix: Restore 'pop PSW'
pop psw
reti

The removal of the jumps in code make it so duke2 should works properly on 4.17.

Ok, but then why b_riera is reporting crashes on DN2 wiht DSP 1.47 here Re: The Soundblaster DSP project ? Is this post from the time before your final 4.17 version?

analog_programmer wrote on 2025-04-14, 23:37:

S95Sedan wrote on 2025-04-14, 22:42:

In the 4.13-patch5 the end of some sections were replaced with code jumps. This part breaks duke2 compatibility to some degree a […]
Show full quote

In the 4.13-patch5 the end of some sections were replaced with code jumps.
This part breaks duke2 compatibility to some degree and thats why it was removed:

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
ljmp X008c ; Patch5: X008c ljmp

And replaced with this in 4.17:

vector_dma_dac_adpcm2_end: clr pin_dsp_busy pop isr_temp_storage pop dph pop dpl pop acc ; Fix: Restore 'pop PS […]
Show full quote

vector_dma_dac_adpcm2_end:
clr pin_dsp_busy
pop isr_temp_storage
pop dph
pop dpl
pop acc
; Fix: Restore 'pop PSW'
pop psw
reti

The removal of the jumps in code make it so duke2 should works properly on 4.17.

Ok, but then why b_riera is reporting crashes on DN2 wiht DSP 1.47 here Re: The Soundblaster DSP project ? Is this post from the time before your final 4.17 version?

So is the "4.16-patch1.zip" not the latest patch bearing version number 4.17 then? If so, probably I may need to take the card out and flash it again, although it's been working fine so far.

I recall there was a game called "BioMenace" which also had this "lockup upon firing" behavior that doesn't seem to be related to sound card, as I've reproduced it on many systems I ever played it on. Don't know if Duke2's lockup behavior with 4.16-patch1 at that time was of a similar cause as I haven't tried it yet...

EDIT: If the issue with Duke2 can be patched without any side effect then probably not related to the issue I had with BioMenace. IIRC that one's sound effect was entirely Adlib.

LSS10999 wrote on 2025-04-15, 02:04:

So is the "4.16-patch1.zip" not the latest patch bearing version number 4.17 then? If so, probably I may need to take the card out and flash it again, although it's been working fine so far.

I recall there was a game called "BioMenace" which also had this "lockup upon firing" behavior that doesn't seem to be related to sound card, as I've reproduced it on many systems I ever played it on. Don't know if Duke2's lockup behavior with 4.16-patch1 at that time was of a similar cause as I haven't tried it yet...

I'm also confused, as the author of these DSP patches S95Sedan now claims that his 4.17 version (the one from the github repo which actually is a patched and optimized 4.16 version) doesn't have mentioned DN2 incompatibilities, but so far you're the second person to report hang-ups in another game.

analog_programmer wrote on 2025-04-15, 02:18:

LSS10999 wrote on 2025-04-15, 02:04:

So is the "4.16-patch1.zip" not the latest patch bearing version number 4.17 then? If so, probably I may need to take the card out and flash it again, although it's been working fine so far.

I recall there was a game called "BioMenace" which also had this "lockup upon firing" behavior that doesn't seem to be related to sound card, as I've reproduced it on many systems I ever played it on. Don't know if Duke2's lockup behavior with 4.16-patch1 at that time was of a similar cause as I haven't tried it yet...

I'm also confused, as the author of these DSP patches S95Sedan now claims that his 4.17 version (the one from the github repo which actually is a patched and optimized 4.16 version) doesn't have mentioned DN2 incompatibilities, but so far you're the second person to report hang-ups in another game.

It seems there were indeed updates to the 4.17 custom fw on the aforementioned github repo. The most recent version is "v417-8k_1.0.bin" which was pushed yesterday.

Maybe all the issues mentioned back then have been addressed at this point, just need some official clarification...

LSS10999 wrote on 2025-04-15, 05:38:

Maybe all the issues mentioned back then have been addressed at this point, just need some official clarification...

Now I see. The old patched DSP version 4.17 in the github repo was "v416-6k_patch1_32505fc2.bin" (I keep all the files locally just in case), but now there is a newer freshly uploaded version "v417-8k_1.0.bin" . So, maybe this one really solves the problems with games like Duke Nukem 2 as the author claims.

analog_programmer wrote on 2025-04-14, 23:37:

Ok, but then why b_riera is reporting crashes on DN2 wiht DSP 1.47 here Re: The Soundblaster DSP project ? Is this post from the time before your final 4.17 version?

Yes, that post is from almost a year ago.

LSS10999 wrote on 2025-04-15, 02:04:

So is the "4.16-patch1.zip" not the latest patch bearing version number 4.17 then? If so, probably I may need to take the card out and flash it again, although it's been working fine so far.

I recall there was a game called "BioMenace" which also had this "lockup upon firing" behavior that doesn't seem to be related to sound card, as I've reproduced it on many systems I ever played it on. Don't know if Duke2's lockup behavior with 4.16-patch1 at that time was of a similar cause as I haven't tried it yet...

EDIT: If the issue with Duke2 can be patched without any side effect then probably not related to the issue I had with BioMenace. IIRC that one's sound effect was entirely Adlib.

Correct, 4.16-patch1 on was one of the earlier versions from before it turned into 4.17 that is on github, the rename was done to diffrentiate original firmwares from a custom one.
4.16-patch1 still has the code jumps mentioned earlier so it might have issues with duke2 on some cards.

However alot of changes upcoming in 4.17-8k_1.0 will be done mostly to the backend of the code and wont change core functionality, the goal is to make this a base version where the overall code is more flexible and readable so further improvements are easier.

No idea if ' BioMenace' issues are related but i can test that whenever i get the chance. (could be something completely unrelated though)

S95Sedan, thank you for the confirmation and of course for your work on the DSP firmwares code!

S95Sedan wrote on 2025-04-15, 06:20:

Correct, 4.16-patch1 on was one of the earlier versions from before it turned into 4.17 that is on github, the rename was done to diffrentiate original firmwares from a custom one.
4.16-patch1 still has the code jumps mentioned earlier so it might have issues with duke2 on some cards.

However alot of changes upcoming in 4.17-8k_1.0 will be done mostly to the backend of the code and wont change core functionality, the goal is to make this a base version where the overall code is more flexible and readable so further improvements are easier.

Thanks for the reply. If "v4.17-8k_1.0" is stable enough to use then I think I'll try flashing it when I have time.

S95Sedan wrote on 2025-04-15, 06:20:

No idea if ' BioMenace' issues are related but i can test that whenever i get the chance. (could be something completely unrelated though)

Come to think of it, the issue with that game locking up upon firing was well documented and most likely not related to the DSP code... Found at least 4 old threads from here.
Bio Menace
Biomenace still freezes
Biomenace .. and passing Stacks options in config.sys
Bio Menace 0.65

In some threads mentioned patches meant to address the issue with DOSBox but as I haven't touched that game for a while I'm not sure if those can fix the issue with real hardware...

BTW: I'm curious about the known incompatibility with SBPro stereo sound on SB16. Is this a pure DSP flaw (that may be fixed/implemented), or it is caused by software as well as other components on a SB16?

S95Sedan wrote on 2025-04-15, 06:20:

No idea if ' BioMenace' issues are related but i can test that whenever i get the chance. (could be something completely unrelated though)

It's not. Bio menace just has a memory leak. The patch released for use with dosbox does work on real hardware

maxtherabbit wrote on 2025-04-15, 12:26:

It's not. Bio menace just has a memory leak. The patch released for use with dosbox does work on real hardware

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duke Nukem II.

I flashed the v4.17-8k_1.0 firmware but it seems Sound Blaster sounds still don't work correctly in Duke Nukem 2, locking up the system. The game plays fine using Adlib sounds, though.

Guess ADPCM still isn't working correctly in my case... will consider patching the game to work the issues around.

For now the only question left is the one I later put on my previous post, regarding whether SB16's SBPro stereo incompatibility was a pure DSP flaw or there were other factors involved.

LSS10999 wrote on 2025-04-15, 15:02:

For now the only question left is the one I later put on my previous post, regarding whether SB16's SBPro stereo incompatibility was a pure DSP flaw or there were other factors involved.

It's impossible to implement SBPro stereo compatiblity in the DSP given the design of the Soundblaster 16. On the Soundblaster Pro, the DSP does not know whether it is dealing with 22kHz stereo or 44kHz mono (the same is true for 11kHz stereo, which is treated just like 22kHz stereo on the DSP). The Soundblaster Pro only has a single-channel DAC, and the output of that DAC is distributed to the two output channels by two sample-and-hold circuits in the mixer chip, which is addressed separately (on port 224/225), and logically completely seperated from the DSP.

On the SB16, there is a "true stereo" DAC. The bus interface chip always sends 16 bit stereo data serially to the DAC. The DSP configures the bus interface chip whether it should apply

• mono-to-stereo expansion
• unsigned-to-signed conversion

before forwarding the data received from an ISA DMA channel to the DAC. In case the 8-bit channel is not used as fallback for 16-bit sound, samples from the 8-bit channel get expanded to 16 bit by the bus interface chip. As the Soundblaster 16 DSP interface is just like the original Soundblaster DSP interface, it still can not observe mixer access, but just read host CPU bytes and send bytes back to the CPU, so the DSP doesn't know whether it should configure the bus interface for 44kHz mono or 22kHz stereo when it receives a "play" command after a "confiure 44kHz" command.

Creative Labs could have implemented a status register in the bus interface chip which is readable by the DSP and reflects the "stereo enable" bit sent from SB Pro software to the SB Pro mixer, but they didn't. So there is no way to support SB Pro stereo compatibility on an SB 16 on a pure hardware level. Of course, stereo emulation is possible if you use IO Port trapping on the host.

analog_programmer wrote on 2025-04-15, 06:31:

S95Sedan, thank you for the confirmation and of course for your work on the DSP firmwares code!

No problem, let me know if any issues pop up.

LSS10999 wrote on 2025-04-15, 15:02:

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duk […]
Show full quote

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duke Nukem II.

I flashed the v4.17-8k_1.0 firmware but it seems Sound Blaster sounds still don't work correctly in Duke Nukem 2, locking up the system. The game plays fine using Adlib sounds, though.

Guess ADPCM still isn't working correctly in my case... will consider patching the game to work the issues around.

For now the only question left is the one I later put on my previous post, regarding whether SB16's SBPro stereo incompatibility was a pure DSP flaw or there were other factors involved.

Which card is this happening on?

S95Sedan wrote on 2025-04-15, 20:18:

LSS10999 wrote on 2025-04-15, 15:02:

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duk […]
Show full quote

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duke Nukem II.

I flashed the v4.17-8k_1.0 firmware but it seems Sound Blaster sounds still don't work correctly in Duke Nukem 2, locking up the system. The game plays fine using Adlib sounds, though.

Guess ADPCM still isn't working correctly in my case... will consider patching the game to work the issues around.

For now the only question left is the one I later put on my previous post, regarding whether SB16's SBPro stereo incompatibility was a pure DSP flaw or there were other factors involved.

Which card is this happening on?

I'm using a CT2950. The card uses IRQ7 as on that system I was not able to make IRQ5 available.

Is there any technical detail on how DN2 plays sound? As the sound card works fine in other places, something in the sound playback logic might have flaws making it prone to issues...

LSS10999 wrote on 2025-04-16, 05:13:

S95Sedan wrote on 2025-04-15, 20:18:

LSS10999 wrote on 2025-04-15, 15:02:

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duk […]
Show full quote

Just tested using BMFIX and BioMenace seems to run okay with it, though I did find a better patch here along with stuffs for Duke Nukem II.

I flashed the v4.17-8k_1.0 firmware but it seems Sound Blaster sounds still don't work correctly in Duke Nukem 2, locking up the system. The game plays fine using Adlib sounds, though.

Guess ADPCM still isn't working correctly in my case... will consider patching the game to work the issues around.

For now the only question left is the one I later put on my previous post, regarding whether SB16's SBPro stereo incompatibility was a pure DSP flaw or there were other factors involved.

Which card is this happening on?

I'm using a CT2950. The card uses IRQ7 as on that system I was not able to make IRQ5 available.

Is there any technical detail on how DN2 plays sound? As the sound card works fine in other places, something in the sound playback logic might have flaws making it prone to issues...

Allright, i own that card so can do some tests on it later.

According to some earlier notes i make Duke 2 uses:
DMA DAC, 4-bit ADPCM Reference
DMA DAC, 2.6-bit ADPCM Reference

The modified 4.13 released by maelgrum works perfectly with Duke 2

LSS10999 wrote on 2025-04-16, 05:13:

I'm using a CT2950. The card uses IRQ7 as on that system I was not able to make IRQ5 available.

Is there any technical detail on how DN2 plays sound? As the sound card works fine in other places, something in the sound playback logic might have flaws making it prone to issues...

Did some tests on the same card but here it did nothing, no freezes. I suspect a lot of the issue are timing related and very hardware dependent.
What kind of system is the card in?

maxtherabbit wrote on 2025-04-16, 13:56:

The modified 4.13 released by maelgrum works perfectly with Duke 2

Yeah more of the buffer and dma16 initialization is left intact which probably helps with keeping hardware in check more.

Did some 6T mode timing tests aswell on some new chips (opposed to 12T for regular ones) and at double that speed it fully fixes (duke nukem 3d: atomic edition) stuttering at 44khz.
Still has timing issues though as it breaks the internal mpu401 port and prevents it from outputting audio.