S95Sedan wrote on 2023-09-22, 15:35:

Sounds fixed to me, nice job finding out where the mistake actually was.

Thank you very much for testing, S95Sedan ! ))
Hanging note bug detected and eliminated ! ))))

So am I to understand this patch is not expected to have any effect on the "type 2" hanging notes on cards with the CT1747 interface?

maxtherabbit wrote on 2023-09-22, 17:19:

So am I to understand this patch is not expected to have any effect on the "type 2" hanging notes on cards with the CT1747 interface?

This patch not limited to CT1745, it solved major bug in 4.13 fw. This major bug in interrupt handlers is not limited at all as Midi Uart bug. It can solve many random misbehaviour in many commands.

So, I think it worth trying in your card.

Maelgrum wrote on 2023-09-22, 17:28:

maxtherabbit wrote on 2023-09-22, 17:19:

So am I to understand this patch is not expected to have any effect on the "type 2" hanging notes on cards with the CT1747 interface?

This patch not limited to CT1745, it solved major bug in 4.13 fw. This major bug in interrupt handlers is not limited at all as Midi Uart bug. It can solve many random misbehaviour in many commands.

So, I think it worth trying in your card.

I currently have two CT2230s socketed as well as a CT1740 so I can give it a try in both types 😁

Maelgrum wrote on 2023-09-22, 13:59:

PS.
There is undocumented DSP command for reading from any bus-interface port, 0xF9. >>[F9] >>[port number] <<[port data]
And it counterpart, 0xFA for writing to port. >>[FA] >>[port number] >>[data to write]

Nope, that's not the bus interface. F9/FA peeks/pokes the internal 256 byte RAM of the 8052. The bus interface is also available, but in that one is on 0E (Poke XBus) and 0F (Peek XBus).

When we currently are at undocumented commands: The full CSP interface is

• 01 - Upload a CSP program: Write 01, wait for answer 00 (if it times out, the CSP program is currently locked). Write low byte of program block length, Write high byte of program block length, write whole block. Wait for answer. AA = program accepted, FF = program rejected. Actually, the byte AA or FF gets posted two bytes before the upload is complete, but I consider this an implementation detail. The uploaded program contains of a set of obfuscated CSP instructions (documenting that stuff is another project...), followed by a 2-byte checksum. This checksum is the sum of all the actual obfuscated instruction bytes. The last two bytes are the CSP program ID which serves no internal purpose. They can be read back using command 09
• 02 - Call CSP function: The next byte is passed as "function number" to a CSP program. When the CSP indicates "completion", a 16-bit IRQ is triggered. The function call interface needs to be implemented by the currently running CSP program for this command to work.
• 03 - Read CSP output byte: Returns a single byte. This is a shared location that can be written by the CSP program and read by the DSP. There is no ready/busy flag, so repeating this command returns the same byte over and over until the CSP program writes a new value into this location, but reading the CSP output byte triggers an interrupt on the CSP.
• 04 - Set CSP operation mode byte. This allows to start/stop/reset the CSP program execution.
• 05 - Write CSP input word: Reads two bytes (low, then high). These two bytes are placed into a shared location which can be written by the DSP and read by the CSP. This will trigger an interrupt on the CSP. By convention, the high byte is a function code and the low byte a function operand. In fact, the "Call CSP function" triggers the function call by writing the "function number" to the low byte and the fixed value "F2" to the high byte of this register.
• 06 - Increment CSP program lock count. Uploading a new program is blocked while the CSP is locked. The lock count is an 8-bit variable, there are no overflow checks.
• 07 - Decrement CSP program lock count.
• 08 - Get CSP version: Reads a constant byte over the X-Bus that is driven by the CSP and is supposed to contain the "CSP version".
• 09 - Get CSP program ID: Returns the last two bytes of the CSP program uploaded using 01.
• 0A - Get CSP program lock count.
• 0B - Send data block to CSP. Like command 02, this command requires the CSP program to implement a specific interface. The first byte is the length of data to send to the CSP (in words), the following bytes are pairs of low-then-high of the 16-bit words to send to the CSP program.
• 0C - Receive data block from CSP. Like command 0B, this command requires the CSP program to implement a specific interface. The first byte is the number of words to receive, then you can read the words as CSP answers.
• 0E - not a CSP function, but a generic X-Bus poke function. First data byte is the value to write, the second byte is the X-Bus address to write.
• 0F - not a CSP function, but a generic X-Bus peek function. The only data byte is the X-Bus address to read, the value is returned as DSP reply.

The commands 0E and 0F are often mis-attributed to being CSP read/write commands, because the original Creative Labs CSP initialization code uses these commands to test the CSP program memory, bypassing the "CSP program upload" abstraction layer. These commands are not necessary to interface with the CSP, using them is only sensible for diagnostic functions and arcane hardware replica checks.

mkarcher wrote on 2023-09-22, 18:14:

Maelgrum wrote on 2023-09-22, 13:59:

PS.
There is undocumented DSP command for reading from any bus-interface port, 0xF9. >>[F9] >>[port number] <<[port data]
And it counterpart, 0xFA for writing to port. >>[FA] >>[port number] >>[data to write]

Nope, that's not the bus interface. F9/FA peeks/pokes the internal 256 byte RAM of the 8052. The bus interface is also available, but in that one is on 0E (Poke XBus) and 0F (Peek XBus).

You are absolutely right, my bad, F9/FA is 'mov a,@r0/@r0,a', not 'movx a,@r0/@r0,a', so its internal RAM access, and 0E/0F is x-bus access.

About CSP/ASP - in 4.05 fw, in processing of command F8, one branch is never taken, and points to routine (addr 119A) what load array of 0x3BB bytes to x-port 0x83. Is it some loader of default ASP/CSP code ?

Is there any thread about researching SB, command set, CSP/ASP e.t.c. ? Its very interesting ! ))

Maelgrum wrote on 2023-09-22, 18:39:

About CSP/ASP - in 4.05 fw, in processing of command F8, one branch is never taken, and points to routine (addr 119A) what load array of 0x3BB bytes to x-port 0x83. Is it some loader of default ASP/CSP code ?

Yes, X-Bus 80-83 is the CSP interface. These ports are located inside the CSP and are dead if no CSP is installed. The firmware v4.13 I have at hand also contains this dead function, this time at 1365. I named it "UploadIntegratedProgram". Again, it is only called from a location near Command F8, so that seems to be unchanged between 4.05 and 4.13

Is there any thread about researching SB, command set, CSP/ASP e.t.c. ? Its very interesting ! ))

I did some reverse engineering on it, just to find out that the first card with DSP I had at hand is slightly broken, thus I am an owner of a nice (though possibly overpriced) CT2760r3 now. The CSP is produced by SGS Thompson, and is a custom ASIC for Creative Labs. It is based on the ST18932 DSP core. You can find data sheets for the DSP cores in the ST18930 and the ST18940 (which are complete chips, and not just a part that is to be integrated into a more complex ASIC). There is a ST18933 DSP chip containing the ST18932 core, but the data sheet for that chip refers to the core documentation instead of containing it. The ST18932 is a slightly enhanced compared to the ST18930, but seems to be mostly binary compatible, so my disassembler based on the ST18930 documentation mostly works for CSP code after deobfuscation.

I intend to do a proper documentation of the CSP stuff, but currently I don't find the time to do that (that is: I spend my time in other ways). See Tests/Info welcome: Reverse engineering the SB16 ASP/CSP for a thread about CSP stuff.

I just checked my notes: I have a (approximate) ST19832 of the integrated CSP program, but I didn't completely analyze it yet. Possibly creative intended to have some basic CSP program pre-loaded on CSP-equipped cards, but never went live with that feature. Some comments in my disassembly indicate that either I don't understand the architecture correctly or the program is buggy, as it seems to be writing to a sound data input location, which is supposedly read-only.

mkarcher wrote on 2023-09-22, 19:15:

I just checked my notes: I have a (approximate) ST19832 of the integrated CSP program, but I didn't completely analyze it yet. Possibly creative intended to have some basic CSP program pre-loaded on CSP-equipped cards, but never went live with that feature. Some comments in my disassembly indicate that either I don't understand the architecture correctly or the program is buggy, as it seems to be writing to a sound data input location, which is supposedly read-only.

Thank you for sharing your CSP knowledge, mkarcher ! Step by step, we getting closer to understanding of SB16, for community good))

mkarcher wrote on 2023-09-22, 19:15:

Possibly creative intended to have some basic CSP program pre-loaded on CSP-equipped cards, but never went live with that feature.

After looking at that program for some more time, it is obviously meant as diagnostic program, not as useful porgram to be used during normal card use. It can output a test signal to the DAC (volume controlled), it can loop back from ADC to DAC (volume controlled), it can test all the CSP RAM (192 words X-RAM, 128 words Y-RAM; 512 words E-RAM), it can transfer a blocks (implements the protocol for CSP commands 0B and 0C), and it can negate the buffer memory used for the block transfer. That's all. So I guess this was meant for diagnostic features (as most of the F-commands are meant).

Answered.

Maelgrum wrote on 2023-09-22, 15:41:

S95Sedan wrote on 2023-09-22, 15:35:

Sounds fixed to me, nice job finding out where the mistake actually was.

Thank you very much for testing, S95Sedan ! ))
Hanging note bug detected and eliminated ! ))))

No problem, if you have more changes or improvements you want tested in the future let me know.

georgel wrote on 2023-09-23, 10:43:

Is the available (thanks to MAME) firmware dump 4.13 identical for SB16 and for AWE32 cards?

Any card that uses the CT1741 chip. (with version 4.11, 4.12 or 4.13)

The list below should have most information;
Sound Blaster: From best to worst

georgel wrote on 2023-09-23, 10:43:

Is the available (thanks to MAME) firmware dump 4.13 identical for SB16 and for AWE32 cards?

From disassembly of existing dumps, I can tell following: 4.04 and 4.05 are basically same with small improvements/updates, but 4.1x (4.11 and 4.13) is significantly updated with x-bus register transactions. But all old interface on external pins of DSP is same as in 4.0x fw.
So, as I see it, 4.04/4.05 is for classic SB16,
And 4.1x is for AWE and (!) SB16.
We need more dumps to be sure, of course.
Or if someone can replace DSP on AWE with new patched 4.13 without hanging note bug and see as it behaves.
The code in fw is not very good, and may be its possible to externally attack fw to get dump of known fw.

It's possible to patch 4.05 fw to remove sample rate bug (this bug is corrected in 4.13), but why not simply use new patched 4.13?
Someone needs this patch for 4.05?

Maelgrum wrote on 2023-09-23, 17:48:

From disassembly of existing dumps, I can tell following: 4.04 and 4.05 are basically same with small improvements/updates, but […]
Show full quote

georgel wrote on 2023-09-23, 10:43:

Is the available (thanks to MAME) firmware dump 4.13 identical for SB16 and for AWE32 cards?

From disassembly of existing dumps, I can tell following: 4.04 and 4.05 are basically same with small improvements/updates, but 4.1x (4.11 and 4.13) is significantly updated with x-bus register transactions. But all old interface on external pins of DSP is same as in 4.0x fw.
So, as I see it, 4.04/4.05 is for classic SB16,
And 4.1x is for AWE and (!) SB16.
We need more dumps to be sure, of course.
Or if someone can replace DSP on AWE with new patched 4.13 without hanging note bug and see as it behaves.
The code in fw is not very good, and may be its possible to externally attack fw to get dump of known fw.

The main card i run is a AWE32 CT3900, but the type-2 just isnt as visible as the type-1 bug shown in the CT1740 card. When i went from 4.13 to 4.05/4.04 there really wasnt much of a (noticable) difference.
But then again it would probably require some more extensive testing to really see/hear what changed. Especially knowing afterwards what the error was.

Would also be interesting to see how the 4.13 firmware compares to 4.16 from an awe64 but dumping that would probably be quite difficult i assume. (as its an integrated rom)

Without dumping or looking the firmware code, 4.16 does fix the other notorious bug that plagued the DSP v4.xx: Single-cycle DMA clicking which can be easily reproduced in Wolfenstein 3-D and Jill of the Jungle.

S95Sedan wrote on 2023-09-23, 19:09:

Would also be interesting to see how the 4.13 firmware compares to 4.16 from an awe64 but dumping that would probably be quite difficult i assume. (as its an integrated rom)

I have some ideas how 1.16 can be dumped, but it's quite a challenge))

S95Sedan wrote on 2023-09-23, 19:09:

....

The main card i run is a AWE32 CT3900, but the type-2 just isnt as visible as the type-1 bug shown in the CT1740 card. When i went from 4.13 to 4.05/4.04 there really wasnt much of a (noticable) difference.
......

Is the AWE32 MIDI emulation with AWEUTIL under DOS working when you use the at89s52 with 4.0x firmware on your CT3900? And with 4.13?

One thing that doesn't work on CT1747 based cards with DSP 4.05 is ADPCM (duke2)

maxtherabbit wrote on 2023-09-23, 22:46:

One thing that doesn't work on CT1747 based cards with DSP 4.05 is ADPCM (duke2)

But it can work on patched 4.13 ))
It is a question - can this 4.13 solve most of the problems, or can't? ))