Re: [hatari-devel] Sample frame buffer is incorrectly restarted

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 05/02/2024 à 21:39, Miro Kropáček a écrit :

On Sun, 4 Feb 2024 at 21:40, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Maybe these docs are wrong when they say timer A is triggered at the end
of the buffer ? Because on STE/TT timer A is triggered when the new
address is loaded into internal DMA register, ie when the sample starts
playing, not at the end.

Hmm, looking at my results below I'd say the timer is definitely triggered while setting the frame address. I even have this note in my ancient source code: https://sourceforge.net/p/mxplay/code/HEAD/tree/trunk/plugins/audio/asap/asap.c#l307 hinting that I confirmed this more than 10 years ago.

Hi

it would make sense that timer A behaviour is similar to how it works with STE/TT, but we can never be sure without real HW. thanks for checking this.

I mean, if the goal of timer A is to say "start address was loaded to internal counter, you can set address for the next frame", then it makes no sense to trigger timerA at the end.

line 68 :  Setbuffer(SR_PLAY, phys, phys + sampleBufferSize);
add after : printf ( "setbuffer init %p %d\n" , phys , (volatile
unsigned long *)0x454) );

line 82 : Setbuffer(SR_PLAY, phys, phys + sampleBufferSize);
add after  : printf ( "setbuffer loop %p %d\n" , phys , (volatile
unsigned long *)0x454) );

line 31, before the end of timerA(void) function, add :

printf ( "timerA %p %d\n" , frameAddr , (volatile unsigned long *)0x454) );

I guess you meant 0x466 (frclock) and not 0x454 (nvbls). :) Anyway, on Hatari it shows: 

setbuffer init 0xfc74 229

setbuffer loop 0x73c74 243
timerA 0x73c74 439
timerA 0x73c74 647
timerA 0x73c74 647
setbuffer loop 0xfc74 757
timerA 0xfc74 966
timerA 0xfc74 1174
timerA 0xfc74 1174
setbuffer loop 0x73c74 1270
timerA 0x73c74 1479
timerA 0x73c74 1687
timerA 0x73c74 1687
setbuffer loop 0xfc74 1783
timerA 0xfc74 1992

...

From this you can see that there is definitely something weird going on. It goes like this:

- init: fine

- first loop: fine

- first timerA: nothing happens, playback continues

- 2x timerA: silence

- loop: fine

- timerA: repeat starts here!

- 2x timerA: silence

...

If I'm not deaf :) I think the repeat isn't actually a repeat of the just loaded chunk but it starts repeating from the *previous* chunk and then continues to the loaded one.

Real Falcon:

The timer is fired as soon as the buffer is set. Then it works as expected, i.e. a second timerA is triggered after 250 VBLs with the new address, therefore continuing. However what is interesting is the fact that nobody has set anything afterwards and yet timeA is triggered for the third time after another 250 VBLs, seemingly at the end of playback? Hmm... is it possible that on Falcon it is triggered in both cases, at the frame address reload *and* at the end of playback?

I can't say :) but at least it confirms that it triggers at start, which is not clearly documented and not emulated either. I will have a look at this to see how I can replicate the results from real HW into emulation

Nicolas