Help with playing routine for rmt (PAL speeds on NTSC)

[gauntman]

Hi all,

 

Looking at the rmtplayer source code, I don't see anywhere that corrects for NTSC/PAL timings. How can I play a song at PAL speeds on an NTSC machine?

 

Note: I want to be doing this during gameplay on a screen with pretty heavy DLI useage. Currently, I am calling the routine during the deferred VBI... moving to a busy loop watching VCOUNT is undesirable. How are other people doing this?

[+Stephen]

I believe a newer version of the player was recently released which allows this. The "timing bars" jump all over the screen (rather than being in a stable zone). Sorry I cannot provide more information.

[Sheddy]

just skip the playback routine every 12th VBI when it's NTSC. I was surprised it works so well, but it seems you really don't notice any timing problems (well maybe some people with amazing hearing/musicality can!).

[Rybags]

That skip should be every 6th actually... 5/6th of 60 = 50.

 

Instead of a VCOUNT wait loop you could use DLIs. Then decide within your VBI code which one needs to be enabled.

 

An alternative could be to modify the RMT code itself such that it doesn't store to the Pokey registers - do the stores within your own code after the RMT call.

 

The benefit there is that you could retain the RMT calls within VBlank and the DLIs then only need to do the register stores.

[gauntman]

just skip the playback routine every 12th VBI when it's NTSC. I was surprised it works so well, but it seems you really don't notice any timing problems (well maybe some people with amazing hearing/musicality can!).

 

Of course! I hadn't thought it would be that simple, I thought that the artifacts might be too noticable -- I will try at 1/12 and 1/6 and see if the music still sounds right. Otherwise, I will look at the more invasive suggestions from Rybags.

[Sheddy]

you're welcome

 

it should be every 6th frame as Rybags says though. You need to lose 10 NTSC frames every 60 to be same as PAL. Don't know where my 12 came from last night - it was late!

[Alphasys]

I wonder whats worse in the end. Keeping track of the timing/skips or just making a tune that'll work right on NTSC.

[Rybags]

If you make it "work right on NTSC" then it'll be wrong on PAL.

 

Coding the skips is nothing... here's all you need:

 

lda pal      ; $d014
cmp #$f
bne vbi_callplay
dec music_delay  ; single-byte counter, initial value should be <=6
bne vbi_callplay
lda #6
sta music_delay
bne vbi_exit
vbi_callplay
jsr rmt_play
vbi_exit
       jmp $e462

 

I find it best to just check the PAL register on the fly - that way it still works if you change video system in emulation.

[analmux]

To allow (hard-)synth instruments in an RMT tune, it's the best to make two separate versions (one PAL version, one NTSC version) of every tune. A synth instrument playing in PAL timing will sound different in NTSC timing, so you'd need to correct it.

 

Imagine you're dealing with a standard 50 Hz tune in the PAL mode, thus the engine runs once in 312 rasterlines. You could use a software trick on the NTSC version also running once every 312 rasterlines, but this will only work nice if f.e. you don't use any (other) DLIs.

 

Prime factors: 312 = 2*2*2*3*13 and 262 = 2*131. Thus, the GCD (greatest common divisor) of 312 and 262 is 2. On an NTSC machine, after 131 steps, the timing scheme will start over. This means that at every (even or odd) scanline you can expect the RMT engine to run. The method RMT uses itself is just an approximation of this scheme. RMT version 1.27 or 1.28 supports this variable scheme IIRC.

 

Maybe the easiest is to use the RMT-approximation scheme after all. But, some corrections are needed if you make use of the filter envelope, so PAL / NTSC versions are also needed after all then.

Edited March 2, 2011 by analmux