Re: [hatari-devel] defaulting to SMALL_MEM

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 9 Mar 2022 16:12:41 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 25/02/2022 à 23:06, Nicolas Pomarède a écrit :
> > Le 20/02/2022 à 09:48, Thomas Huth a écrit :
> >   
> >>> Also , I think the code in dmaSnd.c is accessing STRam[] directly
> >>> too, so we can have same problem of reading unallocated memory. Doing
> >>> nbr 3 would fix that too (for blitter it's OK already, it uses
> >>> get_word() )  
> >>
> >> Ok, but I guess we could also switch the DMA functions here, too? Just
> >> like I did in commit 853fdeef9d438c for the crossbar code?
> >>  
> > 
> > yes, I think this was on my todo list ; using STMemory_DMA_ReadByte in 
> > DmaSnd_FIFO_Refill() should take care of this possible problem.
> > DmaSnd_FIFO_Refill() is called only on every HBL, so this shouldn't have 
> > a noticable impact if we used STMemory_DMA_ReadByte() instead of 
> > directly accessing STRam[]  
> 
> Hi
> 
> I made some changes to use STMemory_DMA_ReadByte() for STE DMA sound.
> Tested with "Music Dream II" demo by Electronic Images and FIFO is 
> correctly filled as before.

Thanks!

FWIW, some days before your mail, I started working on a test program for
this issue (see attachment). I wasn't able to crash Hatari with it, but at
least with Valgrind, it showed some illegal memory accesses. After updating
the Hatari sources to the latest level (with your fix included), the errors
in Valgrind are gone, indeed.

 Thomas

Attachment: dsnd_end.s
Description: Binary data

Attachment: DSND_END.PRG
Description: Binary data