An idea for a PCM player from
http://en.wikipedia.org/wiki/Konami_SCC

In this site i read that :

------------------------------------
Deformation Register: 98E0h

If bit 6 is set, all waveform data start rotating with following speed:

      fclock
f = ---------
      (P+1)

If bit 6 is set, since the waves start to rotate, the values in 9800h through 987Fh will change each time you read them.
------------------------------------


IDEA for the PCM player:

I refer to channel 1, but we could use this idea to have a PCM player with 4 channels

1. We reset the 32 byte in wavetable
2. We set bit 6 at 98E0h. Reset a counter

LOOP:
3. read byte #1 in the wavetable of ch1 and store it
4. do some easy task : we do not need CPU cycle accuracy !!!
5. read again byte #1 in the wavetable of ch1,
6. has it changed with respect to the one stored?
7. If no, goto 3., if yes, increase a counter: if counter is <32 goto 3.
8. reset the counter
9. write the new PCM sample in position #1 of wavetable of ch1
10. goto 4


Why this seems a GOOD idea to do a PCM player ?

Because we do not need CPU cycle accurate code in point 4.
The SCC itself gives the synchronization by rotating samples

The loop should guarantee that we write in the SCC at
exactly the same frequency of play of the channel,
spending the extra time in any nice duty we like.

Is there out of there some SCC expert that can confirm my idea
before I waste time and health in coding it ?

Do the emulators behaviour in this way or SCC works differently ?

DVIK what about SCC in bluemsx?
How deformation register is implemented ?

The functionality of the deformation register is implemented in blueMSX and openMSX but since there aren't any apps using it, the emulation may not be 100% correct but it should be pretty good in both emus.

Interesting idea. Though, keep in mind that this algorithm will go wrong if the PCM data that you are channeling to the SCC does not change during two consecutive samples, so you should prepare your data well.

When the data are all constant the output is silent.

In a normal case, the noise of the samples should be sufficient.
BTW loosing a little bit of synchronization for silent segments
of audio shouldn't be an issue.

You can always make sure that two consecutive samples are different, either on the fly or beforehand. The samples are eight bit, so adding or subtracting one from a sample won't be audible.

agree

Very good thinking!

In fact, synchronisation should be no problem in you write an inc'd value at the byte that gets rotated in as well. Should be possible to get a 5 channel replayer with that.

In fact, now I'm thinking about it, it seems very likely that SCMD may have taken this approach as well. With the timing on the samples being less strict, it should be able to control the other soundchips as well. With samples at 4kHz, a byte only needs to be written every 4 scanlines, leaving plenty of room for interleaving other code.

Naturally, even in this case, it holds that multiple channels can be used
jointly in order to increase the sample resolution.
The main difference with AY8-9-10 is the fact that SCC has linear DACs
this means that the sum of two channel at 8 bit gives a result at 9 bits
while the sum of 4 channels at 8bit results in a channel at 10bits....

this means quite a lot of data to be stored to gain only 2bit more of resolution....

Maybe in this case it is more useful using the 4 channel for mixing 4 independent samples.

Maybe a 4-channel mod player?

Quote:

The functionality of the deformation register is implemented in blueMSX and openMSX but since there aren't any apps using it, the emulation may not be 100% correct but it should be pretty good in both emus.

Actually, Fony/Tyfoon did some SCC sampling in one of their picture disk demos. Maybe the filehunter can point you out the right file from his website in order to test the feature in any emu.

A 4-channel mod player is exactly the application I was thinking at,
but before we need to know if things work as I thought

Quote:

A 4-channel mod player is exactly the application I was thinking at, but before we need to know if things work as I thought

Will it take a lot of CPU time???

I think it would take practically all CPU time.

It depends on the frequency of the samples but actually, yes I do not think
that, while playing 4 samples at 8kHz, we can do a lot of other things.

You need to write 4 bytes each 2 scanlines, so you have barely the time
to fetch the current bytes of the samples or to change the current samples
(maybe swapping memory pages).

Maybe, if you are very efficient, you can also move one or two sprites on the
screen, or scroll vertically the screen itself (msx2)- just pre-calculated data.

The sole (main) advantage is that you do not need cycle accurate code
to perform these actions, as the code can synchronize the I/O

I don't think your idea works...

If I understand this correctly the frequency of the sample is played is 32x bigger (one step rotation after playback of whole 32 byte sample) This means that you should fill the entire sample space. It is also not possible to write sample while in rotation mode, so you would need to write deformation register two times for each sample.

Maybe you can set bits 6 and 7 of deformation register and use channel 4 for timing (volume 0) and channels 1-3 for playing samples by keeping oscillators stopped on these channels.