SCC sound output buggy?

Página 2/3
1 | | 3

Por Edwin

Paragon (1182)

Imagen del Edwin

14-02-2008, 20:20

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

Por OeiOeiVogeltje

Paragon (1407)

Imagen del OeiOeiVogeltje

19-02-2008, 22:19

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

Por hap

Paragon (2040)

Imagen del hap

21-02-2008, 00:56

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 Running Naked in a Field of Flowers ). 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 Wink )

*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.

Por Edwin

Paragon (1182)

Imagen del Edwin

21-02-2008, 13:06

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.

Por ARTRAG

Enlighted (6844)

Imagen del ARTRAG

21-02-2008, 13:41

Could this be somehow linked to the SCC bugs that we spotted while trying to do an SCC PCM player that overlaps 4 channels in order to generate the correct PCM level ?
http://www.msx.org/forumtopic7875.html

Por hap

Paragon (2040)

Imagen del hap

21-02-2008, 14:10

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 {do you write to the frequency reg here?}, then the spike changes somewhat, but for the duration of play it stays the same again.
If the answer to the question in bold is yes, then it's the same behaviour I saw. I wasn't clear in my description that the glitches (spikes) stay the same for every 32byte loop, until you rewrite to the frequency reg.

Your adder theory sounds plausible.

Have you tried writing to the frequency reg every vblank? This would cause a change in timbre 50/60 times per second, and hopefully sound as a rougher version of the original waveform. (it may sound even more horrible, i dunno.. worth a try i say Tongue ). If that doesn't work, just live with it I guess, and keep ch4/5 in the background (no solo).

Por ARTRAG

Enlighted (6844)

Imagen del ARTRAG

21-02-2008, 14:18

Writing the frequency of one channel can affect its time offset wrt the others (even if you write always the same frequency).
In this sense if the errors are due to the adder, changing the timing of one channel could affect the place where the adder fails.

Por Edwin

Paragon (1182)

Imagen del Edwin

21-02-2008, 14:21

ARTRAG> If my theory is correct, then it could definitely affect the PCM player. But if it is, then it should be correct on the SCC-I. Maybe you can check that.

hap> I do write the frequency when starting again. But just once at the start of playing the note. So it is the same problem then.
Rewriting the frequencies is a very bad idea as it resets the internal sample counter. In effect playing the current byte for a longer period than it's supposed to. It distorts the sound. Not as bad as this particular problem, but bad enough for it not to be a solution.

Por sjoerd

Hero (602)

Imagen del sjoerd

21-02-2008, 14:28

The NoFun replayer writes the frequency every vblank, and it does sound more like the original waveform, with some added special high noise/resonating effects. I thought it was a bug somewhere in my code, writing to the scc too fast or something like that Tongue

Por ARTRAG

Enlighted (6844)

Imagen del ARTRAG

21-02-2008, 14:29

Unfortunately I have no SCC-I to test the SCC PCM player, but it would be a good idea give a try...
Does anyone have a working SCC-I with RAM ?
I or dvik could adapt to SCC-I the test of the original SCC PCM player

Página 2/3
1 | | 3