mockingbird wrote on 2023-11-09, 13:27:

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.

Thanks for the explanation.

I don't really think that was the issue, either... as I think the capacitor in question has gone loose probably for quite a while, yet the card still worked. I only replaced that broken capacitor when I was modding the card to install the PLCC44 (DSP) socket.

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

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 switch […]
Show full quote

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...

I'm still rocking the version posted immediately before the one you referenced on three different machines with no issue

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

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...

An update on this issue... The changes to the DSP code is unlikely to be the issue, as the card behaves the same when I put back the original 4.13 DSP. Not sure if it was some other part of the sound card, or the motherboard on which I'm running it (RUBY-9719VG2AR).

On the same board with a YMF718 based soundcard, the sound files that previously failed to play in NT 3.51 played fine using the default Sound Blaster driver (it cannot use Creative's driver), although YMF718 is only SBPro compatible.

Dunno how I missed this thread, but this is incredible! Well done and thank you to everyone who made this happen. If the single cycle DMA bug can be fixed via firmware, the SB16 suddenly becomes an attractive sound card again.

From what I can gather, these are the bugs fixed so far:

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.)

I didn't see any mention of the stuttering bug when high sample rates and midi are played together, is this not possible to fix?

orcish75 wrote on 2024-01-04, 09:00:

Dunno how I missed this thread, but this is incredible! Well done and thank you to everyone who made this happen. If the single cycle DMA bug can be fixed via firmware, the SB16 suddenly becomes an attractive sound card again.

We tried many things, and the general conclusion was that it cannot.

maxtherabbit wrote on 2024-01-04, 13:21:

We tried many things, and the general conclusion was that it cannot.

That's a pity, but thanks for the effort, fixing the hanging note bug makes a huge difference.

orcish75 wrote on 2024-01-04, 14:50:

fixing the hanging note bug makes a huge difference.

yeah and you can use cool setup like this one:

Re: Pure DOS gaming system with 100% digital audio output

i.e. not only avoid the DMA bug, but going pure digital without any crappy noisy DACs. So, you can use CMI8330-based card (like AV310), because it has SPDIF In and Out plus it's SB16-compatible and I personally prefer now AWE32 (instead AWE64 as on the diagram from the aforementioned post - I guess in the past AWE64 was used, exactly because of no hanging note). So, the advantage of AWE32 SPDIF (over AWE64) is that it Outputs EMU8000 MIDI and OPL3 output plus OPL3 is not only the original Yamaha chip (that Creative licensed and integrated), but it also take advantage of EMU8000 and adds reverb and chorus. So, it's very nice that AWE32 is free now of the hanging note.

[EDIT] and you don't need such complex setup as on the diagram: essentially, SB16 and DMA is handled by CMI8330-based card and MIDI/OPL3 by AWE32, i.e. just connect EMU8000 SPDIF Out to SPDIF In of CMI8330-based card and then that card SPDIF Out to the SPDIF In of you high-quality receiver/DAC.

I just read this, find it interesting while I was upgrading my CT2290 which has DSP4.13 I took a picture of DSP location. Many things are not there anymore.
I will attach image :

I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an ASM commented source of v4.13 and jewel in the crown, to have the most annoying bugs corrected with optimizations in bonus, all of that in a very short period of time. Thank you very much to all the people involved, especially @Maelgrum who made it possible.
But it is quite sad their is no real conclusion there. I was left a little unsatisfied as nothing new was done since last October.
Is there any plan for new optimizations or additions in the firmware in the future?
Is there any clue on what can causes the last remaining issue if not a bug in the DSP?
Is there a place, apart from along the thread, where the files and the project purpose and history can be accessed?
Thanks.

Datadrainer wrote on 2024-01-24, 20:02:

I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an […]
Show full quote

I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an ASM commented source of v4.13 and jewel in the crown, to have the most annoying bugs corrected with optimizations in bonus, all of that in a very short period of time. Thank you very much to all the people involved, especially @Maelgrum who made it possible.
But it is quite sad their is no real conclusion there. I was left a little unsatisfied as nothing new was done since last October.
Is there any plan for new optimizations or additions in the firmware in the future?
Is there any clue on what can causes the last remaining issue if not a bug in the DSP?
Is there a place, apart from along the thread, where the files and the project purpose and history can be accessed?
Thanks.

I think we're at the end of the road on what can be done with software optimization, but I do wish maelgrum would upload the final version of his modified fw to vogons drivers so it doesn't remain buried in this thread

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 running this release on three different systems since it was available, it's rock solid

maxtherabbit wrote on 2024-01-25, 01:05:

I think we're at the end of the road on what can be done with software optimization

using stock microcontroller or overall? Was the conclusion of single cycle dma clicking investigation that its source is inside the bus asic? I remember someone mentioning trying faster microcontrollers earlier in the thread.

rasz_pl wrote on 2024-01-25, 02:24:

maxtherabbit wrote on 2024-01-25, 01:05:

I think we're at the end of the road on what can be done with software optimization

using stock microcontroller or overall? Was the conclusion of single cycle dma clicking investigation that its source is inside the bus asic? I remember someone mentioning trying faster microcontrollers earlier in the thread.

I think just by ears alone is not going to be reliable. I wasn't able to hear any audible difference in the test cases back then (mostly a Wolf3D TC).

On the other hand, using a MCU too fast would indeed break a few use cases (namely Windows NT and Duke Nukem 3D as far as I've tested), but a simple MCU with a 12T/6T toggle is fine (except one needs to set MIDI timers to appropriate values when using 6T in order to work).

If you are going to re-investigate single DMA clicking, and you have a test case that can reproduce the clicks well enough to be reliably heard, please modify the test case to set the sample rate using the undocumentd 43h command. This command works exactly like the SB16 sample-rate commands 41h and 42h, but if I understand the firmware correctly, it disables "setting the DAC to idle after playback" until the next sample rate command. If this approach fixes the issue, patching the firmware to always disable the "DAC idle" feature is likely straightforward.

reproducing the bug to be reliably heard is trivially easy when you're physically using the computer with speakers, it's getting it to come across in a capture that's challenging

I always found Day of the Tentacle intro, the part where tentacle drinks sludge and grows arms, to be a click fest. Is that using single cycle DMA?

Just replaced the bugged DSP on one of my SB16 cards (CT2910) with Maelgrum's latest release burned to an AT89C52. Great stuff! Initial tests indicate that digital audio and FM is working properly, but I wasn't able to test MIDI yet since I didn't have my SC-55 at hand.

So I wanted to ask, knowing that the DMA click bug still persists (and probably not DSP related), what about the issue with using high sample rate digital audio and MIDI at the same time causing lockups on certain games (Duke3D, Tie Fighter, etc.)? Did someone test if that was also fixed by Maelgrum's code?

rasz_pl wrote on 2024-01-25, 19:49:

I always found Day of the Tentacle intro, the part where tentacle drinks sludge and grows arms, to be a click fest. Is that using single cycle DMA?

yes

maxtherabbit wrote on 2024-01-25, 01:05:

Datadrainer wrote on 2024-01-24, 20:02:

I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an […]
Show full quote

I also missed the topic... And it is a really interesting one! That is wonderful to have a dump of all 4.xx firmware, to have an ASM commented source of v4.13 and jewel in the crown, to have the most annoying bugs corrected with optimizations in bonus, all of that in a very short period of time. Thank you very much to all the people involved, especially @Maelgrum who made it possible.
But it is quite sad their is no real conclusion there. I was left a little unsatisfied as nothing new was done since last October.
Is there any plan for new optimizations or additions in the firmware in the future?
Is there any clue on what can causes the last remaining issue if not a bug in the DSP?
Is there a place, apart from along the thread, where the files and the project purpose and history can be accessed?
Thanks.

I think we're at the end of the road on what can be done with software optimization, but I do wish maelgrum would upload the final version of his modified fw to vogons drivers so it doesn't remain buried in this thread

Yes that would be good.
I really appreciate projects like this with passionate people not counting their time to understand how things works and improving them. Allowing to get the better of our beloved old hardware.
But my personal opinion for open source projects is it would be preferable to use repositories with DVC like GitHub as it allow to follow the development history. Get the sources for a defined version, and it's easy to distribute binaries through a single link.
Having backup in archives sites like archive.org or the VOGONS Vintage Driver Library is the step after as the more a piece of software is spread, the more chance it have to persist.
But in the end, I'm just glad such project exists 😀

maxtherabbit wrote on 2024-01-25, 01:06:

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 running this release on three different systems since it was available, it's rock solid

Thank you for the feedback. Great to know.
For what I understood and to summarize it (please, correct me if I'm wrong. I surely am):
- The processing algorithms were not modified.
- The modified parts were the functions handling the data streams from the BIC with the code being reorganized to work correctly with a few additional lines to guaranty the states are always correct.
- The optimizations never changed the timings, just trying to get the data flow more efficient and fast to avoid to lose data on DSP reset.

And there is always the rule: Bugged firmware code + bugged software trying to correct the firmware shortcomings = kinda working. You correct the firmware, you get a mess. So it's always possible to get strange behaviors with some software. That's why feedback is important.

Marmes wrote on 2024-01-07, 23:11:

I just read this, find it interesting while I was upgrading my CT2290 which has DSP4.13 I took a picture of DSP location. Many things are not there anymore.
I will attach image :

@Marmes. I do not understand your assertion «Many things are not there anymore.», can you please explain what do you mean?
I'm interested to know where you got this partial pinout for the DSP. I found nothing about that. Maybe from the firmware ASM but I hadn't the time to look it for now. Creative Labs is often using rebadgered ICs from different manufacturer on different packages. Some are programmable meaning the pinout for the data and addresses lines is what is defined by software making it hard to know what they do. That can be guessed looking to where the lines go on other well know ICs I suppose or where the lines came from. Considering the DSP, probably not all pins are used. I hope someone can answer.