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