Tiido wrote on 2026-02-17, 18:24:

The Atmel AT89Sxx are rewritable many many times, but there can be OTP versions of some compatible chip. There also isn't a problem to erase and write it even if locks are set, because erase also removes the locks. But if the chip fails to get detected etc. it is probably just defective or maybe not even the chip at all. The ones on the photo seem to be a bit suspicious...

I have to admit I did not tried to erase them first, did not come to my mind that this might be necessary. I'll try this evening. Every single pin is not mapped on the adapter, the chip has 44 Pins but the programmer only 40. But this chip is listed as supported (with AR-17 adapter) in the programmers manual, so it should work. Adapter came from Alixpress too, the original adapter with shipping from Canada would have been well above $100, the one from Chins just 3€. But they look the same, pin 1 is on the same location, but can't rule out the adapter for sure.If erasing does not work out I'll order the ones from eBay mentioned above and try thoose.

Would be also possible to erase and re-flash the original DSP coming from the Sandblaster? I do have two dead SB16s where I could remove the DSPs from and try 😉

No the original DSP chip has mask ROM and cannot be reprogrammed

It's weird, i can erase the device successfully, i can do a "blank check" which reports chip is blank (once i erased it), i can start flashing but this fails immediately. Afterwards the device is no longe blank. There's also an "ID check function which reports "incorrect ID: 1E42FF".

Maybe it's the adapter and not the chips.

janosch wrote on 2026-02-18, 18:52:

It's weird, i can erase the device successfully, i can do a "blank check" which reports chip is blank (once i erased it), i can start flashing but this fails immediately. Afterwards the device is no longe blank. There's also an "ID check function which reports "incorrect ID: 1E42FF".

Maybe it's the adapter and not the chips.

This is typical behaviour of a bad chip, had this with several eproms bought from china...

[/quote]
This is typical behaviour of a bad chip, had this with several eproms bought from china...
[/quote]

Thanks, i ordered 20 using the ebay link from above, let's see how thoose will work out and already asked for return on AliExpress for the others. Hopefully just 2-3 will work, that's all i need. 😉

janosch wrote on 2026-02-18, 18:52:

There's also an "ID check function which reports "incorrect ID: 1E42FF".

They're either fake or some other atmel 8051-based chip rebadged. I can't find a chip with that exact ID, closest is the AT89S4051 which uses 1E 43 FF.

Got the new chips, 17 out 20 worked, ID check also fine now. So if anyone in Germany (or Europe) needs a Chip with socket, just let know, got plenty now 😉

I did this mod and it worked flawlessly. Just curious, though: I am currently running version 4.17, but I did get a patched 4.13 as a backup in case I need to revert to it. Are there any known issue that may arise from the modifications in 4.17?

No, 4.17 is fully tested and stable and apart from the issues present in every firmware (mpu401 slowdown and dma clicking) shouldnt give problems.

S95Sedan wrote on 2026-06-18, 22:05:

No, 4.17 is fully tested and stable and apart from the issues present in every firmware (mpu401 slowdown and dma clicking) shouldnt give problems.

Where can it be download?
It compatible with CT3900 AWE32?

https://github.com/S95Sedan/CT1741_DSP/tree/main/firmware

https://theretroweb.com/chips/8003

As long as your card has a CT1741 chip, it can be replaced with a new microcontroller chip programmed with the fixed firmware.
This is not a simple software upgrade. You will need to have surface mount soldering skills.

Works only creative soundcards with ct1741 ?
Is somewhere list, which sound cards have it?
Maybe opl3 too instead cqm?

envagyok wrote on 2026-09-26, 23:46:

It compatible with CT3900 AWE32?

If you see my previous post, I was able to do the mod on my CT3900. It worked. I ran into the DMA clicking issue, though, which S95Sedan mentioned every firmware has. There are some other components in the way of soldering a socket on, but I just soldered it on top of those components. Your mileage may vary. That was almost a year ago now, and I haven't had time to use it since then.

Looks like I tried v413-8k_b1a727d9_patch5.bin and v417-8k_1.0.bin, but it was before the binary size of the v417 was corrected, so I had manually truncated it. I don't remember which version worked better. The beauty of the socket is that you can swap out chips easily and experiment with different versions.

S95Sedan wrote on 2026-06-18, 22:05:

No, 4.17 is fully tested and stable and apart from the issues present in every firmware (mpu401 slowdown and dma clicking) shouldnt give problems.

So... is there no way to resolve the DMA clicking issue? Since it's in every firmware, then it doesn't matter which AWE32 card you have?

meyertime wrote on Today, 06:07:

S95Sedan wrote on 2026-06-18, 22:05:

No, 4.17 is fully tested and stable and apart from the issues present in every firmware (mpu401 slowdown and dma clicking) shouldnt give problems.

So... is there no way to resolve the DMA clicking issue? Since it's in every firmware, then it doesn't matter which AWE32 card you have?

Not that i know of currently, i have done tests in the past to alleviate the problem but it made very little to no difference.
Same for looking into the mpu slowdown issue in duke nukem 3d atomic on 44khz, which can be improved with 'duke3d.exe /mpudelay 4000' if i remember correct, but it does drop notes when you do that. (This is just for the wavetable header, external devices , sc-88, nx5r, etc should not have issues)

Im currently working on finishing up a ps2 > pc recompilation project but at some point i might setup a dev environment, as mame recently implemented (more accurate) ct1741 support, so its easier to test what does and doesnt work regardig fixes as thats alot faster then continuesly swapping chips. (that is if things are replicable in such an environment)

Also no, type of card shouldnt matter, my main cards for testing are a CT1740 and a CT3900 which covers both SB16 and AWE32 families which are most of the card stack.

Most of the cards are listed here: Sound Blaster: From best to worst

Thanks for the quick reply! I'm wondering, when you work on fixing this firmware, are you just working directly with the binary? Or some kind of decompilation of it into some type of human-readable language?

Don't want to get anyone's hopes up, as my job has been insane for a long time, but I would love an opportunity to dig into this if I ever had the time... I can't say enough, though, how much I appreciate your work on this and sharing it with us! As I'm sure you're busy with your own stuff too.

If this is fixed in the AWE64, is that a result of something in the DSP chip or a hardware change?