[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