ok

  423 	case 0x80:
  424 		for (unsigned i = 0; i < 3; ++i) {
  425 			rotate[i] = false;
  426 			readOnly[i] = false;
  427 		}
  428 		for (unsigned i = 3; i < 5; ++i) {
  429 			rotate[i] = true;
  430 			readOnly[i] = true;
  431 		}
  432 		break;
 

By setting ONLY bit 7 in deformation register, I would have
ch1,2,3 not rotating and unlocked, ready for PCM samples
ch4,5 rotating and ready to be used as counter...

Do I correctly understand ?

(I don't know, I know nothing about details of SCC....)

Maybe i saw wrong in my experiments
Does bluemsx behave in the same way?
Dvik what about it ?

@nikodr
I'll send you something only once if I get something
working on open or blue msx.

This will be a good test for accuracy of their emulation

I also have a Mega Flash ROM SCC, so you can also send me stuff. Up to 512kB When it is behaving differently in openMSX than on the real SCC, I'll create a bug report in openMSX.

Ok, finally I had some time with my MSX and I could test, how the SCC really works. This is what I found:

First of all, subsample difference can be done! This means that with clever coding it should be possible to play 7680Hz sample in one int only on 60Hz machine. This is anyway very hard to implement. Check out speculation in previous posts.

Deformation register:

RRB000XX

XX:	freq multiplier
	00 = *1
	01 = *256
	10 = *16
	11 = *16
(This affects both freq of voice and rotation speed.)

B:	0 = Normal
	1 = Start from beginning of sample when freq changes
(This can be also used to implement subsample differences)

RR:	00 = Normal, No rotation
	01 = Rotate all waveforms with channel own freq. CH4 & CH5 common waveform will be rotated with CH5 freq.
	10 = Rotate only CH4 & CH5 common waveform. Waveform will be rotated with CH4 freq.
	11 = Normal, No rotation.

Channels that are rotating are READ ONLY. Writing will have no any effect.
Rotating speed is same as reading speed of sample from memory. This means that it is easy to use CH4 & CH5 common waveform as time counter for sample in other channel. Note anyway, that reading too actively may cause noice as SCC can't read the memory at the same time.

Quote:

I also have a Mega Flash ROM SCC, so you can also send me stuff. Up to 512kB When it is behaving differently in openMSX than on the real SCC, I'll create a bug report in openMSX.

Manuel I think there is a disk rom that we flash into the rom and i think it compresses disk images,so more than 512kbyte could be used on mega flash scc.Right?

Great!
Can you post also the asm of a working program?
I've the feeling that bluemsx does not emulate correctly this behaviours,
your code, tested on the real HW, could be used to spot problems in the
emulators.
Anyway, the fact that channels at 1920Hz can have offsets is a very good
news!!

Can I guess a way to work with them?

0a) compute the phases as you proposed in you previous posts
(ch1 == original signal subsampled by 4 on phase 1)
(ch2 == original signal subsampled by 4 on phase 2 - ch1)
(ch3 == original signal subsampled by 4 on phase 3 - ch2)
(ch4 == original signal subsampled by 4 on phase 4 - ch3)

0b) reset the volumes of the 4 channels

loop :

1) reset volumes of ch2,ch3,ch4 => prevent errors in the first 4 samples of each loop
2a) fill ch1
2b) set freq and volume in ch1 => sample 1 is well reproduced as only ch1 is active
2c) wait 1/7680 secs
3a) fill ch2
3b) set freq and volume in ch2 => sample 2 should be well reproduced as only ch1&2 are active
3c) wait 1/7680 secs
4a) fill ch3
4b) set freq and volume in ch3 => sample 3 should be well reproduced as only ch1,2&3 are active
4c) wait 1/7680 secs
5a) fill ch4
5b) set freq and volume in ch4 => sample 4 should be well reproduced as all chs are active
5c) wait 1/7680 secs
6) wait (32/1920-4/7680) secs (the complement to, in order to keep cycle accuracy)

8) goto 1

If it works standalone as cycle accurate loop, it can go in an interrupt too.
and in any cases steps from 1) to 5b) must be cycle accurate even when in interrupts

If it works, the time "wasted" in the int routine is 3/7680 secs, not a lot, without considering that in each pause of 1/7680 secs you can do VDP I/O

Quote:

Channels that are rotating are READ ONLY. Writing will have no any effect

If this is the case, then there is no possibility to play a PCM sample, right ?
Or am I missing something ?

you are missing a lot ;-)

I just checked: the info in NYYRIKKI's post seems to match the implementation in openMSX. Except for RR=11, in that case only channels 1-3 rotate and all channels are read-only.
For more details see the comments at line 35-69 in the openMSX SCC source file:
http://openmsx.svn.sourceforge.net/viewvc/openmsx/openmsx/trunk/src/sound/SCC.cc?revision=6786&view=markup

Yes, I think the problems are in BLUEMSX.
(the one I used in development)

Actually openmsx also is broken!!

This part :

Quote:

10 = Rotate only CH4 & CH5 common waveform. Waveform will be rotated with CH4 freq.

does not work, as rotation is done on ch5 freq!!!

I'll check the blueMSX implementation. I know it was very similar to openMSX at one point but maybe they have fixed bugs or reimplemented since I last checked. I took a quick look and saw some things that didn't look correct, like the one you just mentioned about openMSX.

Quote:

Actually openmsx also is broken!! This part : Quote: 10 = Rotate only CH4 & CH5 common waveform. Waveform will be rotated with CH4 freq. does not work, as rotation is done on ch5 freq!!!

Indeed. I've fixed it in openMSX.

Artrag, If you have an updated version of the program, can you send it. The one you sent earlier sets RR to 11 which according to NYYRIKKI is no rotation. It shouldn't be too hard to get the emulators fixed with the last issue you mentioned.