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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


>  - 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)


From what I read, and the code I sent you in the previous mail, it seems that THERE'S A SEQUENCE PROBLEM IN HATARI : the VHS stops BEFORE the "set vector 13C"


Regards

Laurent



Le 17/03/2024 à 11:10, Nicolas Pomarède a écrit :
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












Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/