Re: [hatari-devel] Chambers of Shaolin

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 29/11/2021 à 23:15, Nicolas Pomarède a écrit :
> Le 28/11/2021 à 23:08, Phil a écrit :
> > Hi Nicolas.
> >
> > Tested on ste 1.06 4mb. And mste 2.06. Both play ok. As does the Sndh 
> > on those machines.
> >
> > Phil
>
> Hi
>
> after more traces, I think the problem is related to the MFP AER where 
> bit 7 is set to 1 to trigger an interrupt when dma sound starts to play 
> (instead of triggering it when dma sound reaches end address).
>
> This could be because hatari has some incorrect value on reset in STE 
> case ; could you check on your ste with monst or any small piece of asm 
> code the value of $fffa01 before running chambers of shaolin (if you 
> bypass the automation menu).
>
> This should be checked from TOS desktop when running in color mode 
> (because bit 7 of fffa01 is also xored with color/mono bit).

Hi

nevermind for the check with an STE, I fixed the value of GPIP bit 7 and 
it should now behave like a real STE.
Music plays fine in 'Chambers of Shaolin' with STE/1MB RAM (you can use 
the latest devel version of Hatari from today)

IIRC this is rare for a music replay to change MFP's AER to trigger an 
interrupt at the start of the DMA play, instead of doing it at the end 
of the buffer (but it's true that if you want to get seamless replay of 
several dma sound buffers, setting the value of the next buffer just 
when the current one starts to play is a better way of doing things 
(because next buffer address will be latched until end of current buffer 
and will be loaded immediately after that)

Anyway, thanks for the report :)

Nicolas