LSS10999 wrote on 2023-10-11, 06:39:

If you overclock the MCU you need to adjust timer init values accordingly. Be it using faster crystal, or operating at faster mo […]
Show full quote

georgel wrote on 2023-10-11, 05:52:

For testing of theory that latency of DSP is related to single cycle DMA clicking why don't you overclock the DSP to some extent by replacing its crystal (the newer MCUs will even not be overclocked in relation to their maximum clock frequencies) or providing an external clock (from oscillator)? This maybe would change the playing sample rate but clicking would be noticed even then.

If you overclock the MCU you need to adjust timer init values accordingly. Be it using faster crystal, or operating at faster modes (such as 6T).

Otherwise UART-related features namely MIDI will end up in a wrong baudrate and not function.

The 1 or 2 NOPs in some routines may or may not be an issue with DSP operating faster than standard. Need testing.

MIDI/ UART is not needed for this test and I guess you know it.

georgel wrote on 2023-10-11, 06:44:

MIDI/ UART is not needed for this test and I guess you know it.

I know. Just not sure how higher clock one could use. Most classic-complaint 8051 MCUs tend to max out at 30-35MHz, with higher operation performance achieved by using fewer clock cycles.

Some very modern 8051 MCUs have internal oscillator and even PLL, but PLCC44 packaging is quite dated and hardly used by modern ones.

A frequency of 33MHz at which AT89S52 is guaranteed to work will do fine for the test I am proposing.

georgel wrote on 2023-10-11, 07:03:

A frequency of 33MHz at which AT89S52 is guaranteed to work will do fine for the test I am proposing.

Previous test build of fw (with significantly lowered execution time of cmd 0x14 and End of block ExtInt1 interrupt) shows no audible difference on clicking (compared to classic 4.13).
I suspect that on stopping DMA playback, Bus interface chip sets output value of DAC to zero.
Then playback of new block started (via 0x14).
This short time between last sample of previous block and first sample of new block, then DAC zeroed, is heard as click.
[Edit] If some model of Bus interface chip doesn't do zeroing DAC value on stop, no clicks will be on this hw.
This all is only my assumptions, of course.

Maelgrum wrote on 2023-10-11, 09:28:

Previous test build of fw (with significantly lowered execution time of cmd 0x14 and End of block ExtInt1 interrupt) shows no au […]
Show full quote

georgel wrote on 2023-10-11, 07:03:

A frequency of 33MHz at which AT89S52 is guaranteed to work will do fine for the test I am proposing.

Previous test build of fw (with significantly lowered execution time of cmd 0x14 and End of block ExtInt1 interrupt) shows no audible difference on clicking (compared to classic 4.13).
I suspect that on stopping DMA playback, Bus interface chip sets output value of DAC to zero.
Then playback of new block started (via 0x14).
This short time between last sample of previous block and first sample of new block, then DAC zeroed, is heard as click.
[Edit] If some model of Bus interface chip doesn't do zeroing DAC value on stop, no clicks will be on this hw.
This all is only my assumptions, of course.

This can be confirmed if a test program is made that outputs zeroes (or any other value if needed) consecutively with single cycle DMAs. If clicking is not heard then your theory is correct.

georgel wrote on 2023-10-11, 10:07:

Maelgrum wrote on 2023-10-11, 09:28:

Previous test build of fw (with significantly lowered execution time of cmd 0x14 and End of block ExtInt1 interrupt) shows no au […]
Show full quote

georgel wrote on 2023-10-11, 07:03:

A frequency of 33MHz at which AT89S52 is guaranteed to work will do fine for the test I am proposing.

Previous test build of fw (with significantly lowered execution time of cmd 0x14 and End of block ExtInt1 interrupt) shows no audible difference on clicking (compared to classic 4.13).
I suspect that on stopping DMA playback, Bus interface chip sets output value of DAC to zero.
Then playback of new block started (via 0x14).
This short time between last sample of previous block and first sample of new block, then DAC zeroed, is heard as click.
[Edit] If some model of Bus interface chip doesn't do zeroing DAC value on stop, no clicks will be on this hw.
This all is only my assumptions, of course.

This can be confirmed if a test program is made that outputs zeroes (or any other byte if needed) consecutively with single cycle DMAs. If clicking is not heard then your theory is correct.

Can you write this test program?

Testing utility done.
Command line arguments:
1 - play sine, with last sample of the block = 0xFF
2 - play sine, with last sample of the block = 0x01
3- play sine, with last sample of the block = 0x80
4 - play buffer, filled with 0xFF
5 - play buffer, filled with 0x00
6 - play buffer, filled with 0x80

Waiting for feedback )) which mode is with clicks, and which is clickless

The only ones where I could clearly hear it were 1 and 4. And it didn't happen after every sample either only sometimes

1,2,3 play with clicking at the end of buffer I guess . 4,5,6 click at the beginning and no more. Tested on vibra16 and on CT3900 with discrete DSP. No difference. For me this sbplay.exe worked only under QEMM. Otherwise used to halt and produce no sound , nor console output. But the latter is not a problem since this was only for testing. So your theory is wrong. Clicks are due to something else.

Tested sbplay on a CT3980 v4.13 unmodified

I had a similar experience to georgel with clicking in 1,2,3 on each cycle, and only clicking at beginning of 4,5,6

However I will also add that I could keep replaying either 4,5, or 6 with no clicking heard until I switched to a different argument

maxtherabbit wrote on 2023-10-11, 19:39:

The only ones where I could clearly hear it were 1 and 4. And it didn't happen after every sample either only sometimes

Thanks for testing! )))
Strange that 2 and 5 not click.

Thanks to all members for testing.
Results are mixed, and strange.

Maelgrum wrote on 2023-10-11, 20:10:

Thanks to all members for testing.
Results are mixed, and strange.

What tools are you using for debugging the DSP firmware?

georgel wrote on 2023-10-11, 20:21:

Maelgrum wrote on 2023-10-11, 20:10:

Thanks to all members for testing.
Results are mixed, and strange.

What tools are you using for debugging the DSP firmware?

Mind.
Pencil and paper.
Tea.

Disassemler - D52, code editor - visual Studio code, compiler - keil c51, but for _debugging_ - don't know any tools, except mentioned above))

Maelgrum wrote on 2023-10-11, 20:26:

Mind. Pencil and paper. Tea. […]
Show full quote

georgel wrote on 2023-10-11, 20:21:

Maelgrum wrote on 2023-10-11, 20:10:

Thanks to all members for testing.
Results are mixed, and strange.

What tools are you using for debugging the DSP firmware?

Mind.
Pencil and paper.
Tea.

Disassemler - D52, code editor - visual Studio code, compiler - keil, but for _debugging_ - don't know any tools, except mentioned above))

Too bad and inefficient. Here is my advice to you. But you need a contemporary computer. Use MAME, ct486 machine with SB16 LLE device that uses 4.13 firmware (you will figure how to replace it, after all initially your firmware came from MAME 😉 )and emulates DSP via 8052 code. The debugger can switch between several processors, including DSP. Everything is cycle counted and accurate too. The SB 16.cpp shows incomplete MIDI / port 33x emulation, but it is only matter of easy to you correction, and you no longer need that.

georgel wrote on 2023-10-11, 20:42:

Maelgrum wrote on 2023-10-11, 20:26:

Mind. Pencil and paper. Tea. […]
Show full quote

georgel wrote on 2023-10-11, 20:21:

What tools are you using for debugging the DSP firmware?

Mind.
Pencil and paper.
Tea.

Disassemler - D52, code editor - visual Studio code, compiler - keil, but for _debugging_ - don't know any tools, except mentioned above))

Too bad and inefficient. Here is my advice to you. But you need a contemporary computer. Use MAME, ct486 machine with SB16 LLE device that uses 4.13 firmware (you will figure how to replace it, after all initially your firmware came from MAME 😉 )and emulates DSP via 8052 code. The debugger can switch between several processors, including DSP. Everything is cycle counted and accurate too. The SB 16.cpp shows incomplete MIDI / port 33x emulation, but it is only matter of easy to you correction, and you no longer need that.

Thanks for advice! It's interesting tool.
Maybe with this powerful and efficient tool at your disposal, you can find some more bugs 😁
'52 command set is simple, and fw itself is simple, so, for me, simple tools like pen and paper is enough.
If needed, some simulator can be written, doing all I need the way I need.
With all respect to MAME team (they are great!), is desoldering of DSP and reading it with programmer a difficult task? Few minutes with right equipment and skills.
If they did it via decapping and optical capture - hats off then.

Maelgrum wrote on 2023-10-11, 22:40:

is desoldering of DSP and reading it with programmer a difficult task?

yes, lock bits are a motherfucker

maxtherabbit wrote on 2023-10-12, 01:53:

Maelgrum wrote on 2023-10-11, 22:40:

is desoldering of DSP and reading it with programmer a difficult task?

yes, lock bits are a motherfucker

But it can be not locked))
S95Sedan dumped 4.04,
Malice dumped 3.02 and 4.05.
So it is possible, but requires some luck.

And 2.02 (?) dump by Eric (@TubeTimeUS).
Decapping chip, direct probing of chip signals, reading bit by bit from sense amplifier.
This is astonishing, hats off.

PS. With all my respect for work of @S95Sedan and @Malice

@TubeTimeUS actually reverse engineered it using die x-rays or some such imaging rather than dump it AFAIR?