Maelgrum wrote on 2023-09-23, 23:11:

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

I'm currently running your patched 4.13 on my CT2230 and so far everything is working well.

maxtherabbit wrote on 2023-09-23, 23:40:

I'm currently running your patched 4.13 on my CT2230 and so far everything is working well.

Excellent, thank you for testing!
Did you try Adpcm games?
Hanging notes I am sure is ok))

Maelgrum wrote on 2023-09-24, 00:32:

Excellent, thank you for testing! Did you try Adpcm games? Hanging notes I am sure is ok)) […]
Show full quote

maxtherabbit wrote on 2023-09-23, 23:40:

I'm currently running your patched 4.13 on my CT2230 and so far everything is working well.

Excellent, thank you for testing!
Did you try Adpcm games?
Hanging notes I am sure is ok))

Duke 2 is working perfectly 😁

darry wrote on 2023-09-19, 20:25:

Is there some (un)official changelog for what got added improved between 4.05 and 4.16 ?

We know what broke. It would ne nice to know what Creative was trying to accomplish with the updated versions to begin with .

Well, I indirectly got my question about DSP code revision "changelogs" answered by following this thread.

While I am completly clueless about assembly language programming, I am fascinated by has been happening here.

Reading about 30+ year old bugs being analyzed, understood and fixed on hardware that was never meant to be user updatable (by the manufacturer) is a bit mind-blowing to me .

Respect and kudos to everyone involved!

darry wrote on 2023-09-24, 01:29:

Well, I indirectly got my question about DSP code revision "changelogs" answered by following this thread.

Even then comparing simple cases as 4.04 vs 4.05 - it's difficult task. I can tell that something is changed in execution of command xx- but what is meaning of this change? A lot of time needed to analysis))
Some changes is obvious -
4.04 leaves unreaded byte in MPU-401 data buffer on exit from mpu Uart mode, so mpu has stuck busy bit.
4.05 and up - solve it.
4.0x has 64 bytes Midi receive buffer, 4.1x - 128 bytes.

But most changes is hidden in pile of code))

Also working on my CT1740

Maelgrum wrote on 2023-09-24, 01:56:

Even then comparing simple cases as 4.04 vs 4.05 - it's difficult task. I can tell that something is changed in execution of com […]
Show full quote

darry wrote on 2023-09-24, 01:29:

Well, I indirectly got my question about DSP code revision "changelogs" answered by following this thread.

Even then comparing simple cases as 4.04 vs 4.05 - it's difficult task. I can tell that something is changed in execution of command xx- but what is meaning of this change? A lot of time needed to analysis))
Some changes is obvious -
4.04 leaves unreaded byte in MPU-401 data buffer on exit from mpu Uart mode, so mpu has stuck busy bit.
4.05 and up - solve it.
4.0x has 64 bytes Midi receive buffer, 4.1x - 128 bytes.

But most changes is hidden in pile of code))

Thank you!

maxtherabbit wrote on 2023-09-24, 02:28:

Also working on my CT1740
20230923_221904.jpg

Excellent))

georgel wrote on 2023-09-23, 22:15:

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?

I think i always had that working, no matter what firmware i used.
You mean the chorus/reverb/620h awe32 part of the card or anything specific?

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)

Seems like that is the case, see below:

1Card:					DSP:				Notes:					Music:			SFX:
2CT1320C					2.00				Game launches			Music plays		Sound effects work
3CT1600					3.02				Game launches			Music plays		Partially, some sound effects work
4CT1740					4.04				Game Launches			Music plays		Sound effects work
5CT1740					4.05				Game Launches			Music plays		Sound effects work
6CT1740					4.13				Game Launches			Music plays		Sound effects work
7CT1740					4.13-patched		Game Launches			Music plays		Sound effects work
8CT3900					4.04				Game Launches			Music plays		Freezes on new game	
9CT3900					4.05				Game Launches			Music plays		Freezes on new game	
10CT3900					4.11				Game Launches			Music plays		Sound effects work (Shooting has DMA clicking)
11CT3900					4.13				Game Launches			Music plays		Sound effects work (Shooting has DMA clicking)
12CT3900					4.13-patched		Game Launches			Music plays		Sound effects work (Shooting has DMA clicking)

S95Sedan wrote on 2023-09-24, 15:14:

georgel wrote on 2023-09-23, 22:15:

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?

I think i always had that working, no matter what firmware i used.
You mean the chorus/reverb/620h awe32 part of the card or anything specific?

Yes but with AWEUTIL MIDI emulation working which uses ISA NMI generated by the 8051. That signal is only wired on AWE cards so I wanted confirmation that it works (e.g. that the 8051 firmware is common for SB(16) and AWE series of cards).

OMG, found another bug in ALL SB fw (all versions)!
They did not store and restore PSW to stack in interrupt handlers, PSW is modified in interrupt code, and main code uses PSW flags.

Result: Execution any command what uses flags while inerrupts a triggered can be wrong.

In layman's terms, what does that result in?

Maelgrum wrote on 2023-09-25, 11:11:

OMG, found another bug in ALL SB fw (all versions)!
They did not store and restore PSW to stack in interrupt handlers, PSW is modified in interrupt code, and main code uses PSW flags.

Result: Execution any command what uses flags while inerrupts a triggered can be wrong.

It is not that difficult to patch and add PUSH PSW and POP PSW to the interrupt handler, is it?

georgel wrote on 2023-09-25, 11:46:

Maelgrum wrote on 2023-09-25, 11:11:

OMG, found another bug in ALL SB fw (all versions)!
They did not store and restore PSW to stack in interrupt handlers, PSW is modified in interrupt code, and main code uses PSW flags.

Result: Execution any command what uses flags while inerrupts a triggered can be wrong.

It is not that difficult to patch and add PUSH PSW and POP PSW to the interrupt handler, is it?

There is no space in existing interrupt handlers to place POP PSW, but with some 'spagetti' code and using free space at the code end, it is possible, of couse.

Maelgrum wrote on 2023-09-25, 12:03:

There is no space in existing interrupt handlers to place POP PSW, but with some 'spagetti' code and using free space at the code end, it is possible, of couse.

No need to add jumps. It is a simple vintage standard MCU . You'd better go disassembly path in order to have an easily editable "source" file.

georgel wrote on 2023-09-25, 12:15:

Maelgrum wrote on 2023-09-25, 12:03:

There is no space in existing interrupt handlers to place POP PSW, but with some 'spagetti' code and using free space at the code end, it is possible, of couse.

No need to add jumps. It is a simple vintage standard MCU . You'd better go disassembly path in order to have an easily editable "source" file.

Jumps are easy and i can be sure what nothing can be done wrong.
Compile disassembled source is 'right' way, but more error prone - there are embedded jump tables with byte offsets in code.

Dang I just buttoned back up both the machines I was using for testing these

I must tell that from programmers point of view severity of this bug is huge - it is totally lame code, not allowed in production.
But from user point of view severity is low - it depends on many factors.
First of all - software (game) must send commands to SB. And this commands must be vulnerable (dependant on flags in codeflow).
Not all commands are vulnerable.
Game that uses auto-init DMA can send no commands at all after init (and during init things are safe - no interrupts are triggered).
And occurence of this bug depends on timings.
So dont expect from this patch something noticeable - you need combination of many factors for bug to occure.

Maelgrum wrote on 2023-09-25, 12:49:

I must tell that from programmers point of view severity of this bug is huge...
But from user point of view severity is low...

classic creative... if the customers dont complain its good enough 😁
#noiseblaster 😏

But jokes aside.
I am a total noob in this area.
How can i check wich version of dsp is on my cards?

I already checked my creative cards, and they seem to have v413 (written on the chip).
But i also have a ton of aztech soundcards wich should use cloned / stolen creative code.

How can i read the dsp version of my clone cards? Maybe there is something interesting in there, or we can use the modded creative dsp code to get the bugs out of some aztech cards too...

You can use SBCHECK.EXE to check DSP version on Creative as well as clone cards.