Re: [hatari-devel] 8 runes of aerillion doesn't have sound

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 17/03/2024 à 09:32, Laurent Sallafranque a écrit :
> Hi,
>
>
> I use the same music technic in Electric night and 8 runes of aerillion.
>
>
> I noticed this AER bug when coding "8 runes of aerillion" and I removed it.
>
> It was certainly a bad instruction I added when I first coded the music 
> in Electric night, but I didn't detect it, as the sound worked both on 
> hatari and my real falcon.
>
>
> I did a lot of tries by the time, before getting into some code that 
> worked as I wanted.
>
> As it worked like this, I used the code in both the demo and he game. I 
> had some problems later with the game, and I removed this AER change.
>
>
> But, as it worked for "Electric Night" on the real hardware, I think it 
> should be emulated, no ?
>
> (I can modify the code of electric night and deliver a new version, but 
> I would prefer Hatari to be closer to the real hardware if possible).

Hi

AER bit is correctly emulated under hatari, but I think the problem is 
triggered by lack of cycle accuracy combined with AER.

On real falcon, can you confirm if the sample during vhs-like blue 
screen is supposed to end before you set vector $13C for GPIP7 ?

Because what I see on Hatari is this :

 - vhs sample plays
 - demo sets vector 13C
 - demo calls music_stop
 - music_stop will stop dma sound, so dma line goes to idle (=1) and 
this triggers immediately a call to music_mfp_i7_interrupt (because int 
13C was enabled just before)

so you get an extra call to music_mfp_i7_interrupt before calling 
music_start

I think that on real falcon the vhs sample is already played before 
setting vector 13C, so when you call music_stop it has no effect (dma 
sound is already idle) and the mfp int is not called.

The problem is that Hatari is not cycle exact, so I guess it runs 
slightly faster than a real Falcon considering cpu cycles, but audio is 
played at correct speed :
 - cpu goes slightly too fast
 - sound plays at correct speed

so, the vhs-like intro is not synced with audio and ends slightly before 
what is expected, resulting in calling music_stop when audio is not 
still playing

Unless Hatari has cycle exact 68030 mode, I think the cpu/audio sync 
problem can't be resolved.

For less trouble in the future, you should ensure MFP is disabled when 
you call "music_stop", then do a "bclr #7,$fffffa0b.w" (to be sure that 
any pending sound interrupt that happened before will be ignored) then 
init vector 13C after that + set bit 7 in fffa07 and fffa13.
If not, even on real Falcon you could have a pending gpip7 interrupt 
from some previous sample that could cause an extra int after you 
install your own handler.

> Anders wrote
> Hi, as a sidenote;
>
> when you asked me to record Electric Night all those years ago, I remember you said the demo was out of sync in my recording when I had captured from a real Falcon.

indeed, this looks like this could be related to what I wrote above. It 
might have been fixed by inverting AER bit when dma sound is already 
playing, because this will kind of delay the 1st audio interrupt but 
cleaner solution would be to clear fffa0b bit 7 (pending A gpip7) to 
remove any pending sound int :
 - mask mfp gpip7 in fffa13 (clear bit7)
 - stop dma sound
 - clear bit 7 in fffa0b
 - set new timer A dor gpip7 + enable MFP


Nicolas