[hatari-devel] Fixes for possible bug in dmasnd.c

npomarede at corp.free.fr npomarede at corp.free.fr
Wed Apr 28 00:33:56 CEST 2010


On Tue, 27 Apr 2010, Laurent Sallafranque wrote:

> Hello,
>
>>  1) dma end address could sometimes be <= dma start address
>
> I think this is possible anyway or the real ste.
> You can play "the whole memory if you put endframe < startframe"
> This could be tested easily or a real Ste.

Yes, I agree, on a real STE there's no "<=" comparison, the dma will just 
test that current address is "!=" from end address. Until this happens, 
dma sound will play.
But as I don't have an STE, I don't know how the current address behave : 
does it loop at the end of the real RAM, does it loop when current address 
reach the maximum possible address on 24 bits (16 MB) ?

If someone could test this on a real STE, we could emulate the correct 
behaviour, but for now it's certainly safer to "reject" such combination.

>
> Do you think there's something to do in the crossbar for this ?
> Code is different, but startFrame and EndFrame are used here too.

Yes, in Crossbar_setDmaPlay_Settings and Crossbar_setDmaRecord_Settings 
there's a test for "dmaPlay.frameLen <= 0" but as frameLen is Uint32 here 
too, this test will never work as expected.

I will commit a similar change for this, but as for STE this is certainly 
something that should be allowed (even if don't think many programs are 
using "end <= start")

Nicolas


> npomarede at corp.free.fr a écrit :
>> 
>> Hello,
>> 
>> while running EPSS demo by Unit 17, I got the following crash of Hatari :
>> 
>> #3  0xb7b9bb08 in __assert_fail () from /lib/i686/libc.so.6
>> #4  0x08082b9d in CycInt_AddRelativeInterruptWithOffset (CycleTime=-3840, 
>> CycleType=1, Handler=INTERRUPT_DMASOUND, CycleOffset=0)    at 
>> /home/npomarede/src/hatari-work/src/cycInt.c:377
>> #5  0x08082ccb in CycInt_AddRelativeInterrupt (CycleTime=-3840, 
>> CycleType=1, Handler=INTERRUPT_DMASOUND) at 
>> /home/npomarede/src/hatari-work/src/cycInt.c:337
>> #6  0x080835c0 in DmaSnd_StartNewFrame () at 
>> /home/npomarede/src/hatari-work/src/dmaSnd.c:283
>> #7  0x0808397e in DmaSnd_EndOfFrameReached (nMixBufIdx=5532, 
>> nSamplesToGenerate=1) at /home/npomarede/src/hatari-work/src/dmaSnd.c:302
>> #8  DmaSnd_GenerateSamples (nMixBufIdx=5532, nSamplesToGenerate=1) at 
>> /home/npomarede/src/hatari-work/src/dmaSnd.c:346
>> #9  0x080a45eb in Sound_GenerateSamples () at 
>> /home/npomarede/src/hatari-work/src/sound.c:1049
>> #10 Sound_Update () at /home/npomarede/src/hatari-work/src/sound.c:1081
>> #11 0x0808384e in DmaSnd_InterruptHandler () at 
>> /home/npomarede/src/hatari-work/src/dmaSnd.c:476
>> #12 0x080ce1d3 in m68k_run_1 (may_quit=1) at 
>> /home/npomarede/src/hatari-work/src/uae-cpu/newcpu.c:1755
>> #13 m68k_go (may_quit=1) at 
>> /home/npomarede/src/hatari-work/src/uae-cpu/newcpu.c:1847
>> #14 0x08098b55 in M68000_Start () at 
>> /home/npomarede/src/hatari-work/src/m68000.c:228
>> 
>> 
>> After quite some time of debugging, I found 2 problems :
>>
>>   1) dma end address could sometimes be <= dma start address
>>   2) after case 1) happened, hatari could crash
>> 
>> First point happened because the dma sound end of frame's interrupt 
>> sometimes happened during the exact moment where the demo wrote some new 
>> values to dma start/end register. This means the new loaded addresses were 
>> partially wrong.
>> 
>> In fact, around hbl 222, the program is doing "clr.b $ff8901 + move.b 
>> #3,$ff8901" to force an immediate reloading of the dma addresses. But in 
>> that case we should call SoundUpdate() when dma is stopped, to output all 
>> the samples that were generated up to hbl 222, else the next end of frame 
>> interrupt would happen near the start of the vbl, instead of hbl 222.
>> 
>> When this happened and dma end <= dma start, there was a second problem 
>> with the test "dma.frameLen <= 0" because frameLen is unsigned. As this was 
>> not detected, frameLen was in fact something like 4 billions samples to 
>> play, and this could lead to a crash of Hatari.
>> 
>> 
>> These fixes should correct the 2 bugs, but they should not improve/degrade 
>> sound quality as most of the time it would just have resulted in a crash.
>> 
>> Nicolas
>> 
>> _______________________________________________
>> hatari-devel mailing list
>> hatari-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>> 
>> 
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>


More information about the hatari-devel mailing list