SCC quality output problem in MG2 (and probably other software)

Page 2/2
1 |

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

25-06-2020, 21:07

ARTRAG wrote:

Could it be an analog low pass effect somewhere in the chain ?

I put tape onto pin 49 of the cart. The picture is the same - spike goes really small in its amplitude.

To all: Please contact me ASAP if you want any tests to be made on SCC while I have the testbench.

By NYYRIKKI

Enlighted (5587)

NYYRIKKI's picture

25-06-2020, 22:45

Eugeny_Brychkov wrote:
NYYRIKKI wrote:

It might be that they tried to get past the hardware design fault that if SCC is internally reading wave table from offsets 16-31 and the wave table is being written by CPU at the same time, this will cause nasty spikes to the output.

Can you explain please. Maybe I missed some of your posts regarding it, then just give the link for reading.

I don't think this "feature" has ever been even properly documented by anyone... and IIRC it was fixed in SCC+...

It took a while, but now I found the discussion, where I remember this from:
https://www.msx.org/forum/development/msx-development/pcm-pl...

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

25-06-2020, 23:35

Some progress here. I captured the digital signals output by the SCC at period 255 and period 9, and they match perfectly.
Thus I was wrong suspecting that SCC is doing something to the waveform depending on the period being set in its period register. But something must be smoothing the spike. Next idea is that it is being done by R2R network (DAC), or this DAC device contains something more than just a set of resistors (e.g. output filtering capacitor to the ground between its pins 13 and 14). I am going to simulate the operation tomorrow using LTSpice, and play with capacitance.

By NYYRIKKI

Enlighted (5587)

NYYRIKKI's picture

26-06-2020, 01:52

I actually now did read the old posts again and it seems I did remember the problem wrong... It seems the problem I meant was limited to 15th-16th byte of the wave...

The whole discussion is very long and jumps between subjects in a rate that makes it hard to follow, but I still kind of recommend to read it trough and collect some notes about the questions, remarks, speculations and tests... There are quite a good questions and some very interesting observations buried there.

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

26-06-2020, 09:16

No need in simulation. Simple visual examination and probing the "resistor pack" with the multimeter confirmed my and ARTRAG's suspicion: there's a 0.01 uF capacitor between pins 1 and 2 (not 13 and 14, confused the sides of the device):



Thus there is a LPF, which can be turned off by disconnecting pin 1 (one of the onboard capacitor's pins) from the ground.

By hit9918

Prophet (2896)

hit9918's picture

26-06-2020, 17:12

a frequency register value of 9 works, but 8 does much different?
maybe there is a RAM acess rate limit? but, this theory does not go together with the mode that does 256 times more frequency. EXCEPT the 256x mode does things at frequency register below 0x0900 when the normal mode does it below 0x0009.
and in 16x mode below 0x0090.

By ARTRAG

Enlighted (6427)

ARTRAG's picture

26-06-2020, 21:48

Hi Eugeny
Good finding! About SCC glitchs, as far as I can remember, changing the wave on channel 4 and 5 will cause several spikes in the output. This doesn't happen on others channel.
The issue could be related to the wave timings but it happens even when you write the wave while the chip is playing sample 31. This makes continuous playback using isr on channel 4&5 very noisy

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

09-08-2020, 18:52

I redesigned SCC circuit, and made some changes improving the things. At least this is how I would design the SCC for the purpose and technique used in MG2.

  • When volume register or tone register is written to, the current tone counter for respective channel is reloaded without sample RAM pointer advance, causing current sample playing again for the defined amount of time. When the reloaded tone counter depletes "naturally", and pointer advances to the next sample, only then "buffered" volume or tone register value is updated in the sound generation engine.
  • When on/off register is written to, the value is buffered and tone register for respective channel having bit value changed is reloaded with current one. When tone counter depletes and pointer advances, only then buffered on/off value is loaded into the sound generation engine.
  • While re-launched counter is running, CPU can buffer all the SCC registers, which, on respective channel counter depletion, will become effective for the respective channel's sound generation engine.

The advantage of this design is that time application has until current sample finishes and new is fetched is known in advance (=current value of tone register). Application can use this time to update all the registers, and reload on/off bit (overwriting buffered value if counter did not deplete yet). The technique causes sample to play for up to 2x of its duration, and if it is not done continuously (e.g. is performed in ISR every 16.6 or 20 ms), there must be no audible artefacts.

The only issue here is the current value of the tone register stored in the sound generation engine - it must be big enough to allow application performing changes in sample RAM/registers and re-launch the process. If application is not in time, new tone/volume/on-off registers take effect and, if off is set (for example), channel is being muted with waveform almost immediately falling to 0 causing audible click. But there're good news: this audible click will be obvious and annoying on low frequency sampling, thus with big value of tone counters.

I tested on MG2, and it is always in time. Some other applications I tested - SD Snatcher, Nemesis 2 have proper clear sound.

P.S. If you will be reusing this technique in your hardware/emulation, I will be extremely glad for the credit.

By Grauw

Ascended (9268)

Grauw's picture

09-08-2020, 20:54

Does this mimick real hardware? If not, it may break specific tricks that assume accurate emulation of the SCC. In the same way that sample playback trick only works on real YM2413s (except for the Nuked.OPLL core which is extremely accurate).

Page 2/2
1 |