Le 10/03/2024 à 21:45, Nicolas Pomarède a écrit :
Le 10/03/2024 à 08:32, Laurent Sallafranque a écrit :
Maybe this can help.
I use a variable : "music_sequence_index" to keep the current sample
index.
I've traced my code and I see that "music_sequence_index" goes from
0(*8) to 2(*8) immediately at the beginning of the music,
which means there's an interrupt played immediately after the
beginning of the music.
The VHS intro plays a sample without interrupts.
I stop the music between the VHS screen and the intro of the demo.
The sample is bigger than the effect length, so, I stop it, load the
1st music sample into memory and start to play the music.
In the music_start code, I add #8 to "music_sequence_index" because
I read this value at the beginning of the interrupt code to load the
next sample.
I also increment by #8 this variable during each interrupt in the
interrupt code.
The traced value of 2(*8) for the variable means that there's a
first interrupt triggered.
Hi
thanks for the information.
What Hatari does at the moment is that it triggers an interrupt (TAI
or GPIP7) when sample start playing (this is because SNDINT signal
goes from idle to playing).
And optionaly it triggers an interrupt when reaching the end of the
sample buffer (if value is set at $FF8901)
I thought signal always goes from idle to playing when starting a
sound, but from what you describe it seems it's not the case, because
this extra interrupt at start explains why sample 1 is not played and
it "jumps" directly to sample 2.
That would mean DMA sound triggers an interrupt at start only if
FF8901 is not enabled to trigger an interrupt at the end (Hatari
allows both at the moment)
I need to write a small test program for falcon that would check the
different cases (loop yes/no and interrupt at end yes/no), because so
far the lack of real documentation from Atari makes it difficult to
emulate.
Hi
looking at the demo, I see that the 1st sample is skipped because when
you stop the music after the vhs-like / blue screen then dma sound
channel goes to idle (=1) and this trigger the un-wanted gpip7
interrupt because bit 7 in MFP's Active edge register is set to 1 (so
0->1 transition on GPIP7 will give an interrupt)
This is not the TOS default value, usually AER's bit 7 = 0 (transition
on 1->0 on gpip7)
I see that at the start of the demo you save MFP content and you also
do this :
0001fd14 0838 0007 fa01 btst.b #$0007,$fffffa01.w
0001fd1a 6608 bne.b #$08 == $0001fd24 (T)
0001fd1c 08b8 0007 fa03 bclr.b #$0007,$fffffa03.w
0001fd22 6006 bra.b #$06 == $0001fd2a (T)
0001fd24 08f8 0007 fa03 bset.b #$0007,$fffffa03.w
0001fd2a 08b8 0007 fa0b bclr.b #$0007,$fffffa0b.w
0001fd30 08f8 0007 fa13 bset.b #$0007,$fffffa13.w
It checks bit7 of of GPIP7 (dma sound status) and depending on that it
changes AER bit7. And in this case it sets AER bit7=1 insted of
leaving it to 0 (because dma sound is idle when starting the demo from
tos)
Why is this needed, can you tell what's the purpose of changing AER ?
Nicolas