pouët.net

I need suggestions on what's the best way to do the DMA wait before triggering a new sample on the same channel on Paula.

Right now I'm doing a CPU loop which I realise is not the best way and is bound to fail on faster CPU's.

How long exactly should I wait for? Depending on where I look, I read anywhere between 5 and 7 rasterlines?

I've seen some code busywait on VPOS for a certain number of lines, but I'd like not to waste rastertime and let the CPU do something else during that time.

Any ideas? CIA timer? Copper triggered interrupt? Something else?

how long i dunno... maybe there is a advice in the hw manual?

maybe if your code is running in vbl. you could set the sample directly with the copper... no need for an irq then.

that's a cool idea, however I'm trying to write a generic replay routine which anybody can just "plug and play" into their prod.

this way the replay code would always need to know where the active copperlist is, and every copperlist would need to include a special line to poke the values into paula (which would probably not leave too much time for the copper to do any graphical stuff on that line).

i might use this in some future prod where I control everything, but I'm also looking for a more generic/flexible approach.

CIA interrupt seems to be the (only?) way to go ...

From what I recall, you need to wait until the first word (2 samples) is played, which depends on the sample rate. '5 to 7 scanlines' is probably worst-case.

I suppose CIA interrupt is probably the best way. If you play the music in the VBL, you should have plenty of inactive scanlines to perform the wait inside the VBL, so it will never interfere with the visuals.
So something like:
1) VBL starts
2) Perform per-frame music routine
3) Set up interrupt for sample updates
4) Do other stuff in VBL
5) Interrupt from 3) is triggered and samples are updated
6) Continue doing stuff from 4)

In the Cinter player, I use a compromise waiting strategy to cut down on the code size (since the player is meant for 4k intros):

The player code is split into two parts, where the first one just stops the channels that are to be triggered in this vblank and then returns. The second part sets all audio registers and starts the new samples. The idea is that you call the first part, then do all your own vblank work, then call the second part. That way, the CPU will be held up for the whole DMA wait (whenever at least one channel is to be triggered), but that time overlaps with other vblank work, including most of the player itself.

I calculated the worst-case wait as two periods of the lowest possible note (C-1): 856 * 2 / 227 = 7.5 scanlines. So that's what I use. You might be able to get away with less, especially if the lowest note used in the music is higher than C-1.

I can confirm what Blueberry said. The Protracker 3.00B replay routine writes the delay value 330 to the CIA timer B hi/lo registers while intitializing the audio registers.

The HRM says that the PAL countdown is 0,709379 MHz or 1,4096837 microseconds per count. So the CIA timer value 330*1,4096837 microsecods = 465 microseconds.

A PAL scan line has 227 clock cycles * 280 nanoseconds duration of one cycle = 63560 nanoseconds or 63,56 microseconds.

So the delay in scan lines is 465 microseconds/63,56 microseconds = 7,32 scan lines. A value very close to Blueberry's delay value.

If fine tuning -8 with the lowest period value is considered, then the worst-case wait increases with the note C1: 907 * 2 / 227 = 8 scanlines.

This fact is unimportant, if you only wait in scanlines (7.5 rounded = 8), but using the CIA timer it looks like this:
907 * 2 / 3546895 PAL clock constant = 511,43 microseconds
511,43 microseconds * 0.709379 MHz PAL countdown = 362 CIA timer value
or in scanlines:
511,43 microseconds / 63,56 microseconds PAL scanline = 8 scanlines

For those who are interested in, I've released a little package about different tracker replay routines also considering this topic: http://aminet.net/util/cli/RSE-UTS.lha