I like your thinking 😀

Certainly will do a lot of good and with the existing supply of noise blasters it will help people out a lot money wise vs having to pay a lot more on other cards.

I'd considered swapping one of my 4.05 DSPs into another board but I'd need several hundred dollars worth of equipment just to desolder and resolder that chip. There's no way I'd be able to remove one of those chips with an iron without destroying the board in the process.

I always love projects like this.

I'll give it a try when I come back from vacation. Probably gonna test first with a regular card with a bugged DSP because:
1. cheap
2. I don't actually have any SB with DSP 4.05. Hope springs eternal...

-

PeterLI wrote:

IMO SB16s are so common it is hardly worth the hassle.

I think that's the point homeboy, they're common but bugged. Fix the bug and you have a ton of great cards on your hands.

I've actually tried to replace a 4.05 DSP from a CT1740 onto a CT3900, but with no luck unfortunately. There just was no sound after the manipulation.
However I have to admit that neither of the boards had been tested beforehand, and the operation wasn't conducted by myself, so there is certain chance that something went wrong and I'm just unaware of that.
Nevertheless, the card did detect and the diagnostics tool did display the new (4.05) revision number.

Is the Microcontroller of the DSP a masked programmed version or a OTP ?

its just a plcc or soj chip so should be simple enough to hot air it off and back on. without knowing what functionality/bug fixes youd loose by downgrading from 4.11 to like 4.05 or something, and dsp of 4.16 dont come in same package, I dont think its worth investigating.

matze79 wrote:

Is the Microcontroller of the DSP a masked programmed version or a OTP ?

Likely a masked ROM as they're cheaper in volume, and Creative being Creative...

Not that it really matters, they're functionally equivalent.

For my tests I plan to use a more modern Flash equivalent.

As for older bugs reappearing, can anyone with SB with DSP 4.05 tell me if they found any?

BloodyCactus wrote:

without knowing what functionality/bug fixes youd loose by downgrading from 4.11 to like 4.05

I think the idea would not be to replace the newer chips with a 4.05 chip, but to analyze the code to find what causes the problems and make a new chip programmed with a bugfixed version of the newer code.

--Zero

That would be the following step, yes.

If this means getting an AWE32 CT2760 or something of that nature with real OPL3, EMU8000, no hanging note bug, and heck, maybe even the ASP/CSP all in one slick card, I'm all for it.

I don't think I can help much seeing as the only ISA Sound Blasters I have are the aforementioned AWE32 CT2760 and an AWE64 Gold CT4390, neither with the 4.05 DSP, but hey, maybe they can contribute to this project somehow.

Just out of curiosity, would it be possible to give the SoundBlaster 16 proper SoundBlaster Pro PCM support with a custom DSP like this? As much as I like the SoundBlaster Pro 2.0, the way the motherboard in my Super Socket 7 build is laid out, having a single SoundBlaster AWE32 that can do everything I'm doing with a SoundBlaster Pro 2.0 combined with a SoundBlaster AWE64 CT4520 would be much less of a hassle for me.

stamasd wrote:

So we know (or at least we think we do) that the SB16 DSPs versions 4.11, 4.12, 4.13 and 4.14 have the hanging note bug, and the […]
Show full quote

So we know (or at least we think we do) that the SB16 DSPs versions 4.11, 4.12, 4.13 and 4.14 have the hanging note bug, and the 4.05 apparently doesn't. I haven't seen anything anywhere on the web related to what exactly is causing the bug, because there's no information about what's in the DSP.

It is however known that those "DSP" chips are in fact general-purpose 8051 microcontrollers. They have 4kB internal ROM which is custom factory-programmed. MCUs from that generation also have protection mechanisms so that the code can't be directly read externally.

However, there are techniques for reading the code even from protected 8051s.

I think it would be interesting if someone *ahem* could read that code. There are blank versions of the 8051 (8751 actually) that can be programmed with custom code. That may lead to the possibility of replacing DSP chips on the flawed cards with ones that don't have the bug. And since bugged cards are (still) plentiful whereas the non-bugged ones are exceedingly rare (haven't seen one on ebay for months) I thought this may be of interest to this community.

What are your thoughts?

I don't know if this could help, but back in the days we used to dump the content of Oki's 83C154, a Intel 8051 adaption of them.
Please refer to the page for the howto, you may be able to adapt the needed rom for the specific MCU

http://twiki.pgmfi.org/bin/view.pl/Library/OB … Oki83C154Reader

Synoptic wrote:

I don't know if this could help, but back in the days we used to dump the content of Oki's 83C154, a Intel 8051 adaption of them.
Please refer to the page for the howto, you may be able to adapt the needed rom for the specific MCU

http://twiki.pgmfi.org/bin/view.pl/Library/OB … Oki83C154Reader

That's eaxctly the sort of approach I was looking at. Some variants of 8051 have further protection though (once switched in external memory mode, the internal ROM cannot be read anymore). There are techniques for dealing with that also, but it involves a lot of trial and error. A LOT. 😎

(because you do unorthodox things to the MCU trying to force it to execute code from an address it doesn't want to...)

Hm interesting. I was browsing stuff today and it looks like someone has decapped a DSP v4.05 already and there are high-resolution pictures of it available. It uses mask ROM so theoretically you can extract the microcode just by visually decoding the bit pattern from the file.

http://siliconpr0n.org/archive/doku.php?id=na … ive_tech:ct1741
http://siliconpr0n.org/map/creative_tech/ct17 … 741_rom_20x.jpg

Also I found a script to automate the process a bit
http://adamsblog.aperturelabs.com/2013/01/fun … asked-roms.html
https://github.com/ApertureLabsLtd/rompar

I may give it a go... though the high-rez image of the ROM array seems to be a bit truncated towards the left (or bottom, as it appears it's rotated 90 degrees clockwise) so I may not get a full readout.

(edit) scratch this, it's more than a bit truncated, it's missing about half of the ROM area. No go.
There is a lower resolution picture of the whole chip but it's too blurry to read the bits.

Back in 2000, we used the technique of writing a programm on an external rom that would read the content of a 8051 compatible rom area and spit it out to a serial port.

see here : http://twiki.pgmfi.org/bin/view.pl/Library/OB … Oki83C154Reader

Any update on this project? Now that the Snark Barker is out, it might be useful to lift it to 2.0 capabilities.