I did a version (not 100% done yet) that does all updates and reads while playing samples 0-14 and it sounds much better on the real scc. Need to tweak the code somewhat before its worth sharing.

The drawback is that the replayer is much more limited and dependent on the sample frequency, but the quality is a lot better.

If Guillian is right you need to avoid only samples 15-16, so you can read/write even if SCC in in range 17-31

In this case almost no drawback, I'd say

I don't know if I'm right or not. It is diffucult to understan the translation:


* The shape of waves is not neatly synthesized when pronouncing with SCC addition Megarom with channel D and channel E.
* The noise enters when a wavy memory is accessed by both mega-ROM and Snatchar momentarily in the address rugged movement of a wavy memory under the reproduction.
* The noise starts the movement of the address of a wavy memory under the reproduction to the 17th byte from the 16th byte by both mega-ROM and Snatchar.

Perhaps, these seem the troubles in which a wavy memory of each channel happens because it is not treatable at the same time of two processing or more.
When MSX accesses a wavy memory at the same time when SCC reads to a wavy memory as an example, it operates, and the value is output to DA converter, the MSX side is given to priority, and SCC thinks data to be a thing of becoming a noise it is not possible to read because of a wavy memory. I want to examine these sooner or later in detail.

Ok
if we assume that :

Quote:

The noise starts the movement of the address of a wavy memory under the reproduction to the 17th byte from the 16th byte by both mega-ROM and Snatchar.

I'd say that we can read ch4 whenever and wherever we like except than reading byte #15 or #16 in it.
So the use of channel 4 as counter SHOULD be safe.

Now all we need to avoid is to write the wavetable when SCC is accessing to those bytes, and for this
we need just to wait one or two sample if we find that the SCC is in the critical point
before updating the "used" samples as the second player Daniel already did

Its doable the way you secribe ARTRAG but not as simple as it sounds. This piece of code needs to be relatively fast in order to do other tasks. Adding that extra check will slow down things. But its certainly doable.

I understood that you have to accept a slowdown of 1 or 2 samples max,
where in 30/32 cases you do not wait anything

I'd just add this (offsets to be tuned apart)

.wait:
        ld a,(9800h+32*3+offset)
        cp      16
        jr  z,.wait        ; wait for sample 16
        cp      15
        jr  z,.wait        ; wait for sample 15 

Here is finally a new rom that avoids to access the scc when playing these samples. Sounds pretty good on a real MSX:

http://www.bluemsx.com/demos/fifth.rom

@ARTRAG: The update takes several samples (in 22kHz its almost 10 samples) so doing the check you did is not sufficient and quite slow if done on each sample so something else is needed.

The regression in openMSX is fixed, by the way (by Wouter). And the sound quality is a lot more realistic (as far as I can tell) than in openMSX 0.6.2. Will now check out dvik's latest.

manuel, can you describe that a bit more detailed. Did the change that broke Manuel's demo also make the sound less good in other cases? If so did you figure out what you did?

Here is a zip with the latest rom and source code. As you can see the workaround for the SCC defect is not that trivial. I'm sure it can be done better, perhaps like ARTRAG said but I haven't been successful doing that yet. But for just playing samples, this version works well on real SCCs:

http://www.bluemsx.com/demos/sccplay_20071023.zip

OMG
This bug disrupt the use of SCC for PCM
According to the FS you compute the time window when you can update the SCC
wavetable... this is terrible, as 1) makes the code depending by the Fs and 2) wastes a lot of CPU

BTW
Few ASM style questions (my curiosity):
why you prefer

        ld      hl,(WavePos)
        ex      de,hl

to

        ld      de,(WavePos)

and why you prefer

        jp      z,.end
[..]
.end:
        ret

to

        ret     z

@ARTRAG, I updated the zip (same url) with the changes you've made. Although I changed the latter to ret z instead of the jump. The update also has your updated comments. Sorry for not merging before I sent out the update.

mine aren't real improvements, you're free to skip them,
I was just curious.

PS
This rom sounds GREAT in BLUE and ugly (let's say so&so) in openmsx 0.6.2
Why this difference?

About the SCC bug, it does indeed totally screw up the PCM player and makes it less useful. The busy loop I put in the PlaySynced method can be somewhat variable in length but it needs to be long enough to avoid access while playing sample 15 and 16. But I can't find any ways of doing a dynamic update that can be used in a purely interrupt driven application. Its I think impossible to avoid at least one read access every now and then while playing samples 15 and 16. It can certainly be made much better than the previous demos but its not going to be noise free.