Out of curiosity, how are these being decrypted?

Kahenraz wrote on 2023-09-18, 16:44:

Out of curiosity, how are these being decrypted?

Cyclic XOR (block by block) with key:

Maelgrum wrote on 2023-09-18, 16:05:

S95Sedan wrote on 2023-09-06, 23:20:

Works perfectly here on a burned chip.
Also tried to dump a Signetics 4.12 chip i still had but that one seems to be locked.

You can try burn 4.05, 4.11 and 4.13 firmware, from my earlier post.
4.05 should work, for 4.11 and 4.13 i am not sure ))

Been running 4.05 for a while now and tested 4.04 on a burned chip so those ones good, no issues with hanging notes whatsoever.
Rest seems to work fine aswell, with the known issues offcourse.

Card: Creative Soundblaster CT1730/40, Rev. 039237 - Wavetable: Yamaha DB50XG
Burned 2.02 - ATMEL AT89S51-24JI - Doesnt Work
Burned 3.02 - ATMEL AT89S51-24JI - Doesnt Work
Burned 4.11 - ATMEL AT89S52-24JU - Works
Burned 4.13 - ATMEL AT89S52-24JU - Works
Original 4.13 - Creative / Intel Chip - Works obviously.

Hexen -warp 02 - Hanging note, High pitch (The burned chips seem to only have a single hanging note, not getting worse. The original chip seems to get worse over time.)
Doom E1M3 - Start plays random D# notes. (All three chips have the same issues)

S95Sedan wrote on 2023-09-18, 18:43:

Been running 4.05 for a while now and tested 4.04 on a burned chip so those ones good, no issues with hanging notes whatsoever.
Rest seems to work fine aswell, with the known issues offcourse.

BTW, i made a patch for 4.13, may be it can solve hanging note bug, can you test it ?

Maelgrum wrote on 2023-09-19, 14:21:

S95Sedan wrote on 2023-09-18, 18:43:

Been running 4.05 for a while now and tested 4.04 on a burned chip so those ones good, no issues with hanging notes whatsoever.
Rest seems to work fine aswell, with the known issues offcourse.

BTW, i made a patch for 4.13, may be it can solve hanging note bug, can you test it ?

Issues seem to remain the same compared to the default unpatched rom.

S95Sedan wrote on 2023-09-19, 17:01:

Issues seem to remain the same compared to the default unpatched rom.

Thank you for testing !
Seems to me, full differential analysis is needed between 4.05 and 4.13.

S95Sedan wrote on 2023-09-18, 18:43:

Burned 2.02 - ATMEL AT89S51-24JI - Doesnt Work
Burned 3.02 - ATMEL AT89S51-24JI - Doesnt Work

SB16 hardware is not compatible with firmware less then 4.00
3.02 is stictly for SB Pro 1/2, and 2.02 is for SB 1.0/1.5/2.0

All attached .zip's with firmware is disappeared from this thread.
Is this normal ?

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

All attached .zip's with firmware is disappeared from this thread.
Is this normal ?

Attachments temporarily unavailable

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 .

S95Sedan wrote on 2023-09-19, 17:01:

Issues seem to remain the same compared to the default unpatched rom.

Found horrible bug in 4.11-4.13 fw.
Bug patched, can be source of hanging note bug.
Can you test it ? ))

I'll give it a shot on one of my socketed CT2230 cards

I think i found source of hanging note bug 4.11-4.13 fw:
Classic way of writing interrupt handlers is :
1. push all used registers in stack
2. write a code to do a work
3. pop all pushed registers from stack and return

And in 4.04-4.05 it is done this way:
int0_handler:
setb p1.2
push acc
push dpl
push dph
push rb0r0
mov dptr,#int0_table
mov a,rb1r3
anl a,#0fh
movc a,@a+dptr
jmp @a+dptr

But in 4.11, 4.12, 4.13 things went wrong:
X0016: setb p1.2
push acc
mov r0,#5
movx a,@r0
setb acc.6
movx @r0,a
pop acc
push acc
push dpl
push dph
push rb0r0
mov dptr,#X0033
mov a,rb1r3
anl a,#0fh
movc a,@a+dptr
jmp @a+dptr

Here register R0 is used before being pushed to stack !!! This is complete disaster. After return to main code sequence, R0 will be not value before interrupt, but always set to #5.
And register R0 is used a lot in main code. Sometimes its usage is guarded by disabling interrupts before, and enabling after usage. But not in all cases !
This is part of MIDI UART loop:
mov r0,#1
movx a,@r0
clr ti
mov sbuf,a
sjmp X0cb1

if interrupt IE0 or IE1 is fired after 'mov r0,#1' line, r0 will be setted to #5, and reading will be done from wrong register, and then this byte will be send to MIDI OUT.
This bug also can do bad things to code not guarded by disabling/enabling interrupts, not only in MIDI loop.

Oh wow, what a blunder

Time for a bugfixed DSP 4.13 then? 😁

appiah4 wrote on 2023-09-22, 09:20:

Time for a bugfixed DSP 4.13 then? 😁

Already done: see upper post with ct1741_v413-patch3.zip
It must be V413 without hanging note bug, and without many random bugs.
At least i hope so ))))

It's probably worth mentioning again that the cards bearing a CT1747 bus-interface chip don't exhibit the erroneous latched/spurious MIDI byte behavior that the patch is thought to resolve. (Perhaps the reason for that can now be determined, Maelgrum?)

Sounds like we may need to wait for S95Sedan to test with his CT1746-bearing CT1730.

Cloudschatze wrote on 2023-09-22, 13:33:

It's probably worth mentioning again that the cards bearing a CT1747 bus-interface chip don't exhibit the erroneous latched/spurious MIDI byte behavior that the patch is thought to resolve. (Perhaps the reason for that can now be determined, Maelgrum?)

Sounds like we may need to wait for S95Sedan to test with his CT1746-bearing CT1730.

Nomally, MIDI UART loop reads from register #1 of bus-interface chip ( MPU-401 DATA IN), and writes this value to MIDI OUT. On erroneus event, it reads from register #5 of bus-interface chip (looks like trace port or something not clearly defined). Some bits of register #5 can be reservered and different in CT1747 and CT1746, and make some harmless MIDI command on CT1747, something like System Message Fx.
This is my assumptions, of couse.

PS. [some incorrect information removed]

And command 0xF4. This command gives back fixed 2 bytes, different for firmware version. Looks like precalculated checksum of firmware or something like this.
For 4.04 - x75, 0x92
For 4.05 - 0x7D, 0x1B
For 4.11 - 0xA4, 0x6F
For 4.13 - 0xA4. 0x6F

Creative used undocumented commands in lawsuits against Aztech to prove they have stolen the DSP code.
The undocumented features worked on Aztech cards too...
This is why Aztech had to license it from creative.

Maelgrum wrote on 2023-09-22, 01:37:

Found horrible bug in 4.11-4.13 fw. Bug patched, can be source of hanging note bug. Can you test it ? )) […]
Show full quote

S95Sedan wrote on 2023-09-19, 17:01:

Issues seem to remain the same compared to the default unpatched rom.

Found horrible bug in 4.11-4.13 fw.
Bug patched, can be source of hanging note bug.
Can you test it ? ))

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

Edit: (Diagnose of the card + e1m1 and the card itself)
https://streamable.com/iieak5