Quote:

Well, but why coping 2 old samples when you could copy NEW one :-)? Is it doable ? I think yes, this would rise the Fs of some % (passing the 8KHz in any case) and not waste any extra CPU than now. (this because while updating the channels the SCC went on in using them, so when you finished the copy you can update some already used rising the total number of sample played per frame :-)

Ah ok, yes thats doable and should indeed be done.

EDIT: This is somewhat tricky so I'll wait with this.

Quote:

How does the real thing behaves when you change the value of the sample CURRENTLY being played ?

Not sure. The idea with this replayer is to avoid that. But I think something is wrong somewhere with the timing somehow. I need to do some more debugging to figure out. The real MSX doesn't sound good and the emulator sounds good with a period that doesn't seem to be correct (as you said earlier).

Quote:

does it affect the output, and more important does it reset the TIMING OF THE PERIOD ?

If it did it could explain the phase problems I have on the real SCC.

If thats the case I only need to update the adaptive frequency finder (that syncs the SCC and VDP) so it works correct

The idea is to reset a channel when it has been playing just a bit less than 32 samples (31.9 or so, the closer the better).

Quote:

The idea is to reset a channel when it has been playing just a bit less than 32 samples (31.9 or so, the closer the better).

But if this is your idea, you have to adopt the strategy I said
updating with LDI the first sample (16cyles) resetting ASAP the
channel and than continue your update

In this way you can increase the freq and go very very close
to the end of the 32nd sample

Quote:

But if this is your idea, you have to adopt the strategy I said updating with LDI the first sample (16cyles) resetting ASAP the channel and than continue your update

Thats what the code is doing, except that its copying 16 bytes instead of one. but the reset happens at sample 31.9 and then the channel is reset and the new sample in position 0 will be played.

Quote:

In this way you can increase the freq and go very very close to the end of the 32nd sample

Thats indeed the idea.

But if you advance the reset (e.g. using my solution) you could increase the Fs
or not ?

Not sure. If you do you need to reset the phase twice every frame. Otherwise you'll get a drift which will cause problems with those samples 15 and 16. Perhaps you can fill sample 0, let the scc wrap around and reset at sample 0.9 instead of 31.9. But the first goal is to get the player working at all so I'd wait with these improvements.

In order to do testing, I've found that even my processing does not avoid some rounding errors
those errors could mask other problems.

Can I suggest you to generate a simple waveform or to choose a signal for which there is no rounding
error before starting your tests?

You should test, while producing channel data, if the "reconstructed" result differ from the original
in order to select a sequence of input that does not suffer of this problem.

just evaluate the difference between z and Y in my matlab code to see where my formulas fail

(IMHO after solved all the other issues, this "rounding" problem will stay in any case)

I was thinking of just playing a sine or square wave or something on all channels, sample it and make sure the phase is ok but I don't have a working setup for doing that.

Yes, I'd try a saw teeth, it is easier to see the lack or the duplications of samples.

Anyway you say:
;; 7648Hz in 60Hz mode
Period: equ 1873

Accordingly to the Manuel's site and to the WIKI the Fs is linked to the period by

Fs = Fc/(P+1)

so

P = -1 +Fc/Fs

Ur numbers does not fit in this, is it wanted?

Not really. I think I calculated the numbers slightly wrong. But I have no idea why it sounds ok with these numbers This is basically the intended calculation (but I may have put some wrong number in there):

C = Cycles per scanline = 228
S = Scanlines = 262

Fs = Fc / (C * S)

and from wiki, Fs = Fc/ (32 * (P+1))

so:

Fc / (C * S) = Fc / (32 * (P + 1)

=>

P = (C * S - 1) / 32


When I calculated this earlier I used 263 scanlines per frame which is not correct. The correct value should be:

P = ( 228 * 262 - 1) / 32 = 1867

But a period slightly longer is actually wanted to avoid that the phase wraps before the samples are updated. So a period of 1873 is probably quite good since it will reset the phase after 31.9 samples.

Actually, I get

P = C*S/32 - 1

that gives 1.865,75, i.e. I'd say 1.866 and not 1867


More in detail

Fp = Fc / C / S

Fs = Fp * 32

from Wiki

Fs = Fc / (P+1) => P = Fc / Fs -1 = Fc / Fp /32 -1 = C*S/32 - 1

I'm sorry that I've had no time to be involved in this. Last weekend I wanted to put together the MSX Info Update video and now I've been busy with my work.

It is anyway great to see that you started to solve this puzzle. I did some tests with this method last year(?), but I really didn't manage to get the timing right. It seems that you have already advanced beyond what I managed to make...

I'm really eager to hear how well this method can be made to work!

NYYRIKKI, you should check out
http://www.bluemsx.com/demos/sccplay_20071023.zip

I think this is the version that has a fully working workaround for some SCC issues and the result is quite amazing on a real MSX. If these roms doesn't sound good I probably linked the wrong version but I believe this is the latest and greatest using the rotating channel 4.

The version discussed last two pages doesn't sound as good and doesn't work well on a real SCC yet but it has other great advantages, like only requiring updates in VBLANK and its using only 4% cpu to play decent samples (If the timing can be fixed)

@ARTRAG, yes you're right. I did a small calculation error. The period needs to be sligthly bigger than the exact value to avoid sample 0 to be played too early, so the 1873 period is quite good (at least not bad).

Strange 1.866 should be the right value but it does not work if you set less than 1.873 ...