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

Quote:

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 ). If that doesn't work, just live with it I guess, and keep ch4/5 in the background (no solo).

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.

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.

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

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

In case you feel like experimenting some more. Check these two waveforms:

	db	$FC, $0C, $0C, $0C, $0C, $0C, $0C, $0C
	db	$0C, $0C, $0C, $0C, $0C, $0C, $0C, $0C
	db	$0D, $00, $00, $00, $00, $00, $00, $00
	db	$00, $00, $00, $00, $00, $00, $00, $00

	db	$FC, $0C, $0C, $0C, $0C, $0C, $0C, $0C
	db	$0C, $0C, $0C, $0C, $0C, $0C, $0C, $0C
	db	$10, $00, $00, $00, $00, $00, $00, $00
	db	$00, $00, $00, $00, $00, $00, $00, $00

I tried playing something with these waves on channel 1 (not even 4 or 5). The first one is good, the second one sounds awful. Not something that the single different byte should cause.

Edwin, your theory needs at least the mix of two channels otherwise I do not see any "adder" at work.
Was you using the same waveform on two or more channels ?
If not, how do you explain that playing only one single channel gives strange results ?

I think you can expect adders in the volume multiplication as well. In fact, it may be the major source of the problems since I've been able to reproduce all problems with only a single active channel.

In Dvik's guess, problems rise when accessing to the ram registers (any of them, waveform
table or frequency) while the SCC is reading some samples in the wavetables.
I remember that for some strange reason, when reading or writing to the ram registers while
sample 14 or 15 was being played, the output resulted corrupted.
I think that by trial and error dvik has found a timing for accessing to the SCC registers without
affecting the output.
This would go against your theory of the adder....
(Look at Leila K demo)

I discussed this with dvik a while back. However, as I understand it, that problem seems to occur when there is some secondary access to the SCC (like reading or writing a wave). This problem persists when there is no access to the SCC at all. For instance, when you do a "Loop: jp Loop" when the SCC slot is not selected, it will continue giving the spikes in the output.

Quote:

In case you feel like experimenting some more. Check these two waveforms: (...) I tried playing something with these waves on channel 1 (not even 4 or 5). The first one is good, the second one sounds awful. Not something that the single different byte should cause.

I can't confirm: http://home.planet.nl/~haps/crap/mrcscc.png

That looks pretty much as it should. Although the it is funny how unstable the constant value sections are. I must admit that I never analysed this case. I noticed in while testing my wave volume multiplier and sometimes heard distinct secondary tones in the sound.

IIRC, I did notice a big difference between the Nemesis 2 and the Flash ROM scc in this test. It appears that the SCC in the nemesis 2 cart is more heavily filtered in the DAC.

Quote:

Although the it is funny how unstable the constant value sections are.

I believe that's mostly due to constant low amplitude noise on my soundcard line-in, even if nothing's connected to it. This was just a rough measurement for the $10 thing.