[hatari-devel] Two Hatari bugs

[Nicolas Pomarède]

Le 14/05/2011 16:37, Anders Eriksson a écrit :
>
> Hi,
>
> I've found two bugs in Hatari that seems to be across both Mac OS X and
> Linux platforms.
>
> Bug #1
> If you leave Hatari with the F12 menu open for many hours (say over a
> night) Hatari becomes unresponsive and needs a kill -9 to terminate.
> I've confirmed this with the Hatari in the repositry from both Mac OS X
> 10.6 and Ubuntu Linux 11.04.

Hello

I think this could be due to the microsec counter wrapping ; I would 
need to check.


>
> Bug #2
> Hatari YM-file writing needs some improvements. The YM specification
> says that for buzzer sounds, register 13 should have value $ff, this
> means that the YM player should not update register 13 in that case.
>
> I've only tried the YM files in my own player, but as far as I can tell,
> it doesn't do the buzzer correct (silent channel) - I'm unaware of any
> YM player on OS X that I could use and compare.
>
> Here are two YM snippets recorded with Hatari 1.5 repo:
> http://ae.dhs.nu/tmp/tao.ym.gz
> http://ae.dhs.nu/tmp/frazer.ym.gz
>
> And here are the original files:
> http://sndh.atari.org/sndh/sndh_lf/Tao/Just_Buggin/Ride_The_Sky.sndh
> http://sndh.atari.org/sndh/sndh_lf/Frazer/If_Pigs_Could_Fly_End.sndh

Do you mean reg 13 in the YM file is never set to 0xff, or the opposite ?

 From the code in ymformat.c, we have :

                 if (bEnvelopeFreqFlag)
                         *pYMData++ = SoundRegs[PSG_REG_ENV_SHAPE];
                 else
                         *pYMData++ = 0xff;

I tried recording an YM from the GEM desktop and reg 13 is always 0xff 
in the YM file.

Same in the 2 files you sent, reg 13 is always 0xff ; are you sure those 
tunes don't use mfp timer to change reg 13 ? Because in that case it 
clearly won't work in Hatari's ym dumping.

Nicolas