PCM player using SCC

ページ 25/33
18 | 19 | 20 | 21 | 22 | 23 | 24 | | 26 | 27 | 28 | 29 | 30

By dvik

Prophet (2200)

dvik さんの画像

25-10-2007, 23:29

I can't do those sawtooth tests because I can't sample the audio output from my MSX. On the emus I don't need it because I just run the emulator in a debugger so I can see whats going on in the scc emulation.

The timing may be slightly off in emus which may have an impact especially when the period is long. Another thing is that the VDP sometimes has its own clock that may be off a bit from the Z80. All these are reasons why I wanted an adaptive check of the actual period.

The reason why the period can't be set less than 1873 in the replayer may be that the timing of the phase resets may be off a little bit.

By ARTRAG

Enlighted (6923)

ARTRAG さんの画像

25-10-2007, 23:50

what about doing a self tuning program that adapts the period on the basis of the reading on the rotation of ch 4 ?

disable the ints
start with a guess period
set the 0,1,2,...,31 sequence in ch4
start rotating it
enable the ints

you read the value at VINT and compare the
value with the one red at the previous VINT
If the difference is>0 increase the period
if <0 decrease the period,
if ==0 you got it !

Done as piece of code it could tune the player on each HW it runs!

A sort of self test do be done only at boot time

By dvik

Prophet (2200)

dvik さんの画像

25-10-2007, 23:54

what about doing a self tuning program that adapts the period on the basis of the reading on the rotation of ch 4 ?
Thats exactly what its doing Smile

By dvik

Prophet (2200)

dvik さんの画像

26-10-2007, 00:08

Btw, the reason why the program sounds bad with periods less than 1873 is that the distance between resets of the phase of the channels are limited by the code:

        ld      de,9800h        ; 11
        ld      bc,18           ; 11
        ldir                    ; 23*18-5
        ld      bc,14           ; 11
        add     hl,bc           ; 12
        ld      (9881h),a       ; 14

This code takes 468 cycles to execute but to work with the real period 1866, this code can only take 466 cycles. Otherwise you'll get a wrap on the phase of the later channels. To be on the safe side, I would shrink the time it takes to execute this to maybe 450 cycles instead. This will have a very small effect on the phase difference between channels but will always be on the safe side to avoid unwanted wraps.

This is an especially good trade off if it is indeed the case that the phase is reset also if writing to the currently played sample.

By ARTRAG

Enlighted (6923)

ARTRAG さんの画像

26-10-2007, 00:26

IMHO the phase does not count, anyway this code here is exactly 466 cycles

lld	a,5
ld      de,9800h        ; 11
ldi 	; 18
ld      (9881h),a       ; 14
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
LD i,a
ld c,6

and requires interleaving of the data

[edit]
I did an error, now corrected, in the cycle count

By dvik

Prophet (2200)

dvik さんの画像

26-10-2007, 00:41

It may need to be less than 466 cycles, 450 is a better pick because on some machines the period may be shorter because of timing between SCC and VDP.

I don't think we need to interleave the data for a particular implementation. Its nice to have the freedom of implementing it differently. Hopefully we can be fine with one 60 Hz and one 50Hz implementation but it may be needed with more than one (in case the cycle count needs to be very exact). Performance is not an issue at all here so the code doesn't need to be super optimized for speed so no need to unroll the ldir. The important thing is timing.

By ARTRAG

Enlighted (6923)

ARTRAG さんの画像

26-10-2007, 00:54

ld	a,5
ld      de,9800h        ; 11
ldi 	; 18
ld      (9881h),a       ; 14
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18
ldi 	; 18

ld      bc,22; 11
add     hl,bc           ; 12

ld (label),a ; 14

Again 466 but without data interleaving, as you have now the data

By dvik

Prophet (2200)

dvik さんの画像

26-10-2007, 01:02

IMHO the phase does not count
I think it does. Thats why it doesn't sounded good when you tried to lower the period earlier. The thing is that the phase of each channel needs to be reset before it wraps by itself. If it wraps you'll get noise because its playing the wrong sample. Thats why it is important that the distance between resetting the phase of two channels is less than 466 cycles. 466 may work in the emu but not necessarily on a real MSX.

By dvik

Prophet (2200)

dvik さんの画像

26-10-2007, 05:04

Here is all the source code for both the tool that generates the data (from a 7.6kHz 16 bit raw audio file named fth01.raw).

I also added some code to generate square waves on each channel (the sum of all channels will be a triangle wave I think). I don't have a setup to sample a real MSX but it actually sounds very similar to the emulation. This makes me think that there is a problem with the data, perhaps its not possible to use this method on an SCC. Its too early to make that conclusion but I'm running out of ideas Crying

The replayer includes the adaptive period finder and it prints the period it finds on the screen. The distance of resets between channels is 445 or something which is less than 466 but it doesn't have much impact the sample width is almost correct anyways but I made it lower in case the period on a real MSX would be smaller. But at least my WSX gets the exact same period as the emulator so that is not a problem.

Any ideas are welcome. Would be cool to get this algorithm to work.

Anyways, here is a zip with the files:

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

By NYYRIKKI

Enlighted (6016)

NYYRIKKI さんの画像

26-10-2007, 07:56

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)

Yes, I noticed that you managed to get the CH4 version allready working, but as I said I'm really eager to hear, how this phase shifting idea will turn out... I didn't quite make it... I have newer actually learned to calculate M1 correctly and I may have had some errors also calculating time taken by whole screen update.

ページ 25/33
18 | 19 | 20 | 21 | 22 | 23 | 24 | | 26 | 27 | 28 | 29 | 30