S95Sedan wrote on 2023-10-09, 17:56:

You mean the typo in X1231? Thats all i can see as changed in the later versions. […]
Show full quote

maxtherabbit wrote on 2023-10-09, 17:25:

S95Sedan wrote on 2023-10-09, 17:21:

These are the fixes that are out there? […]
Show full quote

These are the fixes that are out there?

Copy code to clipboard

1v413-8k_4ca3dca8_patch3
2- Fixed hanging note bug
3
4v413-8k_16a46526_patch4
5- Fixed hanging note bug
6- Fixed PSW bug in ExtInt0/ExtInt1 interrupt handlers

Id just go with the last one for now.
Theres a couple things which can be improved but it will probably take time.

Here im mostly cleaning up the code before doing anything, making it a bit easier to work with.

When I said "third maelgrum release" I was referring to the ones made by assembling modified disassembly from the dumps, not the hex edited versions. Also you forgot the ADPCM fix

You mean the typo in X1231? Thats all i can see as changed in the later versions.

Copy code to clipboard

1mov	a,0ffh
2to
3mov	a,#0ffh

Yes, it is it.

Maelgrum wrote on 2023-10-09, 17:59:

Yes, it is it.

This should be all of them if if im correct?
patch 3 - which moves int0_handler + int1_handler:

1    push	acc
2    push	dpl
3    push	dph
4    push	rb0r0

patch 4 - ExtInt0/ExtInt1 (adpcm2 + adpcm4 + adpcm2_6 + dac_silence)

1    pop	rb0r0
2    pop	dph
3    pop	dpl
4    pop	acc
5    reti
6to 
7    ljmp	X008c

And patch 5 offcourse:

1mov	a,0ffh
2to
3mov	a,#0ffh

S95Sedan wrote on 2023-10-09, 18:17:

This should be all of them if if im correct? patch 3 - which moves int0_handler + int1_handler: […]
Show full quote

Maelgrum wrote on 2023-10-09, 17:59:

Yes, it is it.

This should be all of them if if im correct?
patch 3 - which moves int0_handler + int1_handler:

Copy code to clipboard

1    push	acc
2    push	dpl
3    push	dph
4    push	rb0r0

patch 4 - ExtInt0/ExtInt1 (adpcm2 + adpcm4 + adpcm2_6 + dac_silence)

Copy code to clipboard

1    pop	rb0r0
2    pop	dph
3    pop	dpl
4    pop	acc
5    reti
6to 
7    ljmp	X008c

And patch 5 offcourse:

Copy code to clipboard

1mov	a,0ffh
2to
3mov	a,#0ffh

Hanging note bug:

1int1_handler:
2    clr	p1.2
3    push	acc
4    mov	r0,#5                     <--- illegal placement of access to x-bus reg 0x05 here
5    movx	a,@r0
6    clr	acc.6
7    movx	@r0,a
8    pop	acc
9    push	acc
10    push	dpl
11    push	dph
12    push	rb0r0

Solution:

1int1_handler:
2    clr	p1.2
3    push	acc
4    push	dpl
5    push	dph
6    push	rb0r0
7    mov	r0,#5                     <--- push acc and pop acc not needed here
8    movx	a,@r0
9    clr	acc.6
10    movx	@r0,a

4.04, 4.05, 4.16 is bug free
4.11, 4.12, 4.13 is bugged

I have a CT2230 with DSp 4.13 and like to join testing. How do i flash the chip? With a programmer only, or is there a flash programm?

S95Sedan wrote on 2023-10-09, 18:17:

ADPCM decoding bug:

1X1231:	add	a,r2
2    jnc	X1236
3    mov	a,0ffh

this is typo, ACC loaded not with intended 0xFF byte, but with value readed from non existing SFR register 0xFF.
Solution:

1X1231:	add	a,r2
2    jnc	X1236
3    mov	a,#0ffh

This bug is present is 4.04-4.13, fixed in 4.16

Samplerate conversion bug (present in 4.04, 4.05, 4.11,4.12, fixed in 4.13 and 4.16) - just for complete description of found bugs in fw.

1X0aa1:	mov	a,#17h            ; from 4.11
2	mov	b,rb2r4
3	mul	ab
4	mov	rb3r0,b
5	mov	rb2r7,a
6	mov	a,#17h
7	mov	b,rb2r3
8	mul	ab
9	xch	a,b
10	add	a,rb2r7
11	mov	rb2r7,a
12	mov	a,rb3r0
13	addc	a,#0
14	mov	a,rb3r0                  <-- bug - this line not needed
15	rrc	a

1X0a95:	mov	a,#17h
2    mov	b,rb2r4
3    mul	ab
4    mov	rb3r0,b
5    mov	rb2r7,a
6    mov	a,#17h
7    mov	b,rb2r3
8    mul	ab
9    xch	a,b
10    add	a,rb2r7
11    mov	rb2r7,a
12    mov	a,rb3r0
13    addc	a,#0
14    rrc	a
15    mov	rb3r0,a

PSW bug - present in all versions of fw.
In all interrupt handlers, PSW is not pushed and popped to/from stack.
Any executing commands, which have JC, JNC, JZ, JNZ in code path, or any usage of carry (rrc, rlc, e.t.c.) can be affected.
In typical (classic) SB usage scenarios, this should not be an issue.
But some non standard/not typical usage scenarios, this bug can affect command execution badly.

And in timer0_handler, R0 is spoiled in one path of execution, also in all present fw.

Solution:
PUSH PSW
...
POP PSW
in interrupt handlers

and
push rb0r0
...
pop rb0r0
in timer0_handler

Yeah i think i have them all from what i can see summarized. But its good to have it all documentated incase people need it.
See the attached files which include python scripts to patch them, input (stock 4.13) and output files (5 has all the fixes combined)

Thinking about Single DMA clicking bug, i think it can be fixed.
Now command 0x14 executes in following way:
1. SB recieves 0x14 and 2 more bytes, and programs Bus control chip for buffer playing.
2. Bus control chip reads by DMA samples and outputs them to DAC
3. At buffer end, IRQ is fired, and int1 in DSP programs Bus Control chip to stop playing.
This is hardware assisted way.

My idea is do this in SB/SB Pro way - not hardware assisted.
In int0 handler, request DMA byte, read it, and send it to DAC.
By this way, we can have full control over DAC, and no clicks will be produced at buffer end.
But it is not a patch ! )) It is new code, never existed before, completely new code in int0 handler and completely new code in cmd 0x14 .

If you want i have a ct1600 i can take the dsp off and try to read it. (Intel chip, v302, which should be readable)
Maybe its usable in some way for that, as i believe thats one of the last versions which is still unaffected right?

S95Sedan wrote on 2023-10-10, 16:50:

If you want i have a ct1600 i can take the dsp off and try to read it. (Intel chip, v302, which should be readable)
Maybe its usable in some way for that, as i believe thats one of the last versions which is still unaffected right?

3.02 is already dumped - dump in this thread
Re: The Soundblaster DSP project

All SB with fw 1.xx, 2.xx, 3.xx do output in this 'hardware unassisted' way.

Maelgrum wrote on 2023-10-10, 16:39:

My idea is do this in SB/SB Pro way - not hardware assisted.

I'm unsure whether this will work at the expected quality. The SB/SBPro uses a classic R/2R-type DAC which is quite resistant to jitter. On the other hand, the SB16 uses an Sigma/Delta DAC (aka Delta/Sigma DAC), which requires to process samples exactly at the sample clock. This is why you should have a FIFO of depth 1 at least, so that the next sample for the DAC is always pre-fetched. This is implemented in the hardware-assisted way in the SB16 bus interface chip.

If you run without hardware assistance, the 8052 code is responsible for making sure that the DAC "FIFO" doesn't underflow, because otherwise... ...you will likely get "single cycle clicks". I wrote "FIFO" in quotes, because this is not the ~10 level DMA FIFO in the bus interface unit you usually think about when you say FIFO and SB16, but it's a single level "transmit hold register" in the parallel-to-serial converter in the bus interface unit that generates the DAC clock and the serial DAC data signal.

I am aware that the ADPCM code in fact does loop the sample data through the DSP, just as the SB/SB Pro did, but I don't know enough about it to be able to judge how the avoided the FIFO underflow risk there. Maybe they just tolerated it for ADPCM data, which is of mediocre quality anyway, or maybe the DAC and DSP clocks are sufficiently synchronized, such that the timer interrupt is phase locked with the DAC and you won't never miss the correct time to re-fill the transmit hold register.

mkarcher wrote on 2023-10-10, 17:00:

I'm unsure whether this will work at the expected quality. The SB/SBPro uses a classic R/2R-type DAC which is quite resistant to jitter. On the other hand, the SB16 uses an Sigma/Delta DAC (aka Delta/Sigma DAC), which requires to process samples exactly at the sample clock. This is why you should have a FIFO of depth 1 at least, so that the next sample for the DAC is always pre-fetched. This is implemented in the hardware-assisted way in the SB16 bus interface chip.

Why not to implement 1 sample FIFO ? It is possible

mkarcher wrote on 2023-10-10, 17:00:

If you run without hardware assistance, the 8052 code is responsible for making sure that the DAC "FIFO" doesn't underflow, because otherwise... ...you will likely get "single cycle clicks".

If it underflows, last output sample can be repeated, so no sudden level change in DAC will happen.
Clicking, as i suspect, is due setting of DAC output to 0000 during stopping of Bus control chip.

Anyway 4.16/4.13 firmware plays without DMA clicking on all SBs with integrated DSP so this problem is not a matter of firmware but of hardware.

georgel wrote on 2023-10-10, 17:17:

Anyway 4.16/4.13 firmware plays without DMA clicking on all SBs with integrated DSP so this problem is not a matter of firmware but of hardware.

But we can replace fw only in discrete DSP

Maelgrum wrote on 2023-10-10, 16:13:

PSW bug - present in all versions of fw. In all interrupt handlers, PSW is not pushed and popped to/from stack. Any executing co […]
Show full quote

PSW bug - present in all versions of fw.
In all interrupt handlers, PSW is not pushed and popped to/from stack.
Any executing commands, which have JC, JNC, JZ, JNZ in code path, or any usage of carry (rrc, rlc, e.t.c.) can be affected.
In typical (classic) SB usage scenarios, this should not be an issue.
But some non standard/not typical usage scenarios, this bug can affect command execution badly.

And in timer0_handler, R0 is spoiled in one path of execution, also in all present fw.

Solution:
PUSH PSW
...
POP PSW
in interrupt handlers

and
push rb0r0
...
pop rb0r0
in timer0_handler

My 8051 assembly is not good, but I don't see this push/pop of PSW in the ASM file you included in the most recent release of your modified firmware.

maxtherabbit wrote on 2023-10-10, 18:20:

Maelgrum wrote on 2023-10-10, 16:13:

PSW bug - present in all versions of fw. In all interrupt handlers, PSW is not pushed and popped to/from stack. Any executing co […]
Show full quote

PSW bug - present in all versions of fw.
In all interrupt handlers, PSW is not pushed and popped to/from stack.
Any executing commands, which have JC, JNC, JZ, JNZ in code path, or any usage of carry (rrc, rlc, e.t.c.) can be affected.
In typical (classic) SB usage scenarios, this should not be an issue.
But some non standard/not typical usage scenarios, this bug can affect command execution badly.

And in timer0_handler, R0 is spoiled in one path of execution, also in all present fw.

Solution:
PUSH PSW
...
POP PSW
in interrupt handlers

and
push rb0r0
...
pop rb0r0
in timer0_handler

My 8051 assembly is not good, but I don't see this push/pop of PSW in the ASM file you included in the most recent release of your modified firmware.

That version was for testing Single Cycle DMA bug - is it solved or not. It is in no way 'release', only test build for single purpose only.
I am planning to release normal build, without modifications of logic (classic V4.13), just to fix all known bugs and optimize source code.

Maelgrum wrote on 2023-10-10, 17:08:

mkarcher wrote on 2023-10-10, 17:00:

I'm unsure whether this will work at the expected quality. The SB/SBPro uses a classic R/2R-type DAC which is quite resistant to jitter. On the other hand, the SB16 uses an Sigma/Delta DAC (aka Delta/Sigma DAC), which requires to process samples exactly at the sample clock. This is why you should have a FIFO of depth 1 at least, so that the next sample for the DAC is always pre-fetched. This is implemented in the hardware-assisted way in the SB16 bus interface chip.

Why not to implement 1 sample FIFO ? It is possible

The issue I see is not implementing a FIFO (which is obviously possible), but synchronising the DSP, which runs at 24MHz with the Sigma/Delta DAC, which runs at 46.615 MHz from a different crystal. While you have the timer of the DSP, which was used as DAC time base on the SB and SB Pro, this time base is no longer synchronized to the conversion cycles of the DAC, that happen at an externally given rate. Do you get any feedback of the DAC rate (or "fill level" of the transmit register in the bus unit) back into the DSP?

mkarcher wrote on 2023-10-10, 19:17:

Maelgrum wrote on 2023-10-10, 17:08:

mkarcher wrote on 2023-10-10, 17:00:

I'm unsure whether this will work at the expected quality. The SB/SBPro uses a classic R/2R-type DAC which is quite resistant to jitter. On the other hand, the SB16 uses an Sigma/Delta DAC (aka Delta/Sigma DAC), which requires to process samples exactly at the sample clock. This is why you should have a FIFO of depth 1 at least, so that the next sample for the DAC is always pre-fetched. This is implemented in the hardware-assisted way in the SB16 bus interface chip.

Why not to implement 1 sample FIFO ? It is possible

The issue I see is not implementing a FIFO (which is obviously possible), but synchronising the DSP, which runs at 24MHz with the Sigma/Delta DAC, which runs at 46.615 MHz from a different crystal. While you have the timer of the DSP, which was used as DAC time base on the SB and SB Pro, this time base is no longer synchronized to the conversion cycles of the DAC, that happen at an externally given rate. Do you get any feedback of the DAC rate (or "fill level" of the transmit register in the bus unit) back into the DSP?

no timer should be used for the task, and timer is not needed,as ExtInt0 interrupt is synchronous to samplerate (triggered at samplerate speed)
you can simply output one sample per ExtInt0 interrupt

Maelgrum wrote on 2023-10-10, 19:25:

no timer should be used for the task, and timer is not needed,as ExtInt0 interrupt is synchronous to samplerate (triggered at samplerate speed)
you can simply output one sample per ExtInt0 interrupt

Thank you! That's the clue I was missing.