I've been fiddling with my SCC replayer for a while now because the sound quality was not good when played on a real SCC cartridge. But it appears that my code is not to blame, but the SCC chip/DAC itself. To test this I put together a little test.

You can start SCC blaffer NT (or probably any other scc music app) and select the same wave for all channels. A simple sine will do. Then put in the following simple pattern:

C 4  ...  ...  ...  ... 
...  ...  ...  ...  ... 
OFF  ...  ...  ...  ...
...  C 4  ...  ...  ... 
...  ...  ...  ...  ... 
...  OFF  ...  ...  ... 
...  ...  C 4  ...  ... 
...  ...  ...  ...  ... 
...  ...  OFF  ...  ... 
...  ...  ...  C 4  ...
...  ...  ...  ...  ... 
...  ...  ...  OFF  ...
...  ...  ...  ...  C 4
...  ...  ...  ...  ... 
...  ...  ...  ...  OFF

And play it.

In theory it should sound the same 5 times. But it doesn't. In fact, it even sound different on repeated plays.

I suspect this is a bug in the scc chip. And a rather bad one at that. But I find it very strange that nobody has questioned this before. So, I'm interested in whether you can hear this on all SCC chips or maybe just some versions. I tested it on both the scc in Nemesis 2 and in the SCC Flash ROM. Both have horrible results. Bifi reported that it sounds fine on an SCC-I cartridge. Some reports on others would be nice.

I have a theory on what is happening here, but I'd like to hear yours before I share mine. Also, if you find ways to avoid this, I'd love to hear them.

I think it is because channel 4 and channel 5 share a wave. This is no fun

I'm very interested in this too and it could be the same problem I faced when doing the SCC sample player that is using 4 channels (see another thread).

I think that this would work correctly only on scc+ chipset,on scc+ channels 4 and 5 have a different wave and do not share only one. http://bifi.msxnet.org/msxnet/tech/soundcartridge.html here it mentions that :

"The improvement of SCC is compared to the normal SCC that the Sound Cartridge has a extra waveform. Now channel 4 doesn't have to share its waveform with channel 5 (thus all five channels have a private waveform). "

and when you go further down the page it has the following information

"The difference is that now channel 5 has a private waveform. For more information about the operation of the SCC, see SCC Sound Chip.

The fact that SCC may be addressed in two modes, this does not mean that the SCC+ has twice the channels of normal SCC. If you change Sound Mode, the different addresses refer to the same registers. "

In theory though all 5 channels should work but channel 4 would sound the same as channel 5.From what you mention chanel 5 is not heard at all?

nikodr: unrelated. It's common knowledge that 4 & 5 have the same waveform, nothing new here. Try 5 channels with the same instrument everywhere: there's a bug on 4 & 5.

Probably, and hopefully, related to the same 'bug': http://home.planet.nl/~haps/crap/msx_kv2.zip
This was recorded from an original KV2, it uses ch4&5 for those bells, it sounds different on all emulators.

That could as well be normal aliasing. Ppl from OpenMSX have spent some time, quite some months ago, to perfect a resampling algo. The main test sound used to test/analyze the quality of those resamplers was a bunch o' scary sound effects from Solid Snake, full o' aliasing. If you have the opportunity: try the given example in a tracker like Blaffer or Scc-Musixx.. ^_^

Note that the 1cM's SCC implementation is without this bug.

I don't think so. Could someone try King's Valley 2 "start select" song on an SCC+?

Best would be to isolate those channels on a real msx/scc .. I just don't know any bgm player that can isolate channels tho..

Hold on, I'll hack KV2 MSX1.

KV2 (MSX1 or 2) ROM, offset $8F23, change "11 FC E1 1A" to "00 00 3E 1F", with 1F being the value written to the SCC channel enable register ($988F), it gets written at the 2nd loop of the song. Disabling channel 4 or 5, or disabling channels 1,2,3 doesn't affect the bells pitch. So, unless disabling channel 4 or 5 doesn't fix the blafferthing, the KV2 problem is unrelated to it.

*edit* To be sure about it, the request of someone trying KV2 on SCC+ still stands.

hap> indeed it's not the same problem. This problem has to do with the hardware itself. It has nothing to do with emulation.

i just tried it with the SCC from the Pazos Flashrom and my SD Snatcher soundcart

the scc gives weird and changing sounds every time you play
and the SD Snatcher has no problems

With Nemesis 2 on MSX1 connected to PC soundcard line in, I "poked" around a bit in Basic (I got fed up after a while tho ). What's happening is, if you write to the frequency registers of channel 4 or 5, its 32 byte output waveform may have a few glitches (up to about four), where, instead of reading a byte from offset X (0-31), it will read it from offset X+Y, the value of Y looks to be variable, 1 up to about 8, but the same for every loop (that is, until you rewrite to the frequency reg). So, instead of reading from 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14, ... it will read from eg. 0 1 3 3 4 5 6 7 8 9 14 11 12 13 14, ... The exact details, and why this happens is unknown to me, maybe a memory read conflict between channel 4 and 5. Changing the frequency of channel 5 will not affect the output waveform of channel 4, and vice versa. Disabling the channel or setting its volume to 0 before writing the frequency doesn't fix this glitch, neither does rewriting to waveram.

I've also had a good listen to 2 recordings of the Nemesis 2 intro, and noticed the rare and small differences in timbre between the two where channel 4/5 were used.

I suggest to use "soft" instruments in ch4&5 (no square, saw), to prevent large amplitude changes due to a glitched ram read. You could also try to write to the frequency regs every vblank, to get an averaged waveform instead of having the chance for a very buggy one, so.. eg. tone frequency=$1A3, write $A3 every vblank after (just to clarify that even writing the same frequency causes it to glitch).

(hope it's clear enough, I suck at explaining )

*edit* KV2 bells ch4&5 waveram is a high frequency squarewave, 7f 80 7f 80 7f 80, etc, glitched reads would cause very noticeable changes in timbre.

Thanks for the description, hap. I ran into some of these problems as well, but the way I understand them is slightly different. However, it is not the same problem that is at work here. If you check the sampled output, you see spikes in the waveform. These spikes are not generated just when changing the frequency, but every time the wave is played. I tested this by placing a pause function in my replayer. Even when paused, the spikes still appear in every loop of the waveform. So the SCC definitely generates them on its own. The strange thing is that the generated spikes stay the same while the SCC plays the waveform. But if you stop it and play it again, then the spike changes somewhat, but for the duration of play it stays the same again.

I'm not a musician and my ear for details in sound is not very good. But I have a feeling that while the problem is most pronounced on channel 4&5, it is does in (some) other channels as well on a small scale. I hope someone with a musical ear can confirm that.

My theory of what could be happening is based on the work I did writing a PAL encoder for the 1chipMSX. I am seeing the same sort of spikes in the PAL signal that I'm generating. In the PAL encoder I found that the culprit was the addition logic. When you add multi bit signals in a chip, not all bits are updated simultaneously. Propagation delay cases some bits to change quicker than others. When using the default addition in Quartus, it apparently uses an adder algorithm that works in some way that I don't understand yet. When you do an addition like "01111" + "00001" the high bit seems to be update first, leaving you with a intermediate value "11111" before the other bits get changed and you finally end up with "10000". The noise that this generates takes the form of sharp spikes, similar to those I see in the sampled SCC output. If this adder noise is indeed the cause of the sound problems in SCC, then it's pretty much unsolvable.

Since it is an obvious bug, it would have been fixed in SCC-I. In fact it might even have sparked the creation of SCC-I. But of course it is all speculation unless the adder problem can be confirmed. Which might be possible if someone knows the adder algorithm that is likely to be used in chips like these.