| Re: [hatari-devel] Regression in Hatari w.r.t. "ST High" video mode |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Regression in Hatari w.r.t. "ST High" video mode
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Thu, 16 Jun 2022 07:49:04 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1655365747; bh=14N3y2rHe3kax1r/K9GCh+RV2zvphAzQ01wXWPzoosM=; h=Date:From:To:Subject:From; b=GjQx9yXv7XOuO1MygApOeqhEn4M79iy4R8ZfWICDre4b3sbvFjjwMBixpck+AaUxq d1/F5fzOiXd2TrJUoQ2F0scraMcSnrrQfegIBpXzPRPGDXi5f7yiAGZVeqIe3wBfbq xlYQi6zeMQPGoQ71Dkt91PPVqOTXbJSvqekEpGacK8Mnc7lAyaI1+L8Zbw0OGbfZ+K lsLjoZI39/kT2+Wp/KgpbcY1kceuaZNm+pHsPuMhlfqKmfCxgrXQX6FwR+S+aJltQA ReVt4A0hCQUv2pVFe/mCpM/OGOckhfCSyerN3bAou1aIaFh4Hqa/Ked+JzI7FO9jnm jwhw8QQ1BQq2A==
Am Tue, 14 Jun 2022 13:01:34 +0000
schrieb Thomas Huth <th.huth@xxxxxxxxx>:
> On 14/06/2022 13.05, Christian Zietz wrote:
> > Hello,
> >
> > lately, I compiled Hatari for Linux on AArch64, which I haven't done
> > before. There, I noticed that ST High (monochrome) video mode would not
> > work. The screen would just stay white except for the status bar; while
> > the floppy access indicator showed that otherwise the emulated ST was in
> > fact running. On the same system, ST High works when compiling Hatari
> > 2.3.1 instead.
> > > Bisecting lead me to the following commit as cause for the regression:
> > "Add sanity checks to avoid accesses beyond the end of the ST-RAM":
> > https://git.tuxfamily.org/hatari/hatari.git/commit/?id=c3875fc8bf3148c376262a71966fd4bbcd54ff22.
> >
> > I added some debug printfs to see the variables which are involved in
> > the check that was added by this commit:
> > fvram, nextline, (Uint16 *)&STRam[STRamEnd]
> > DEBUG: 0x7f94b8e010 28 0x7f87c70010
> > DEBUG: 0x7f94b01010 28 0x7f87c70010
> >
> > As you can see, the "fvram" is outside the ST RAM area, causing the
> > check to fail and, therefore, the screen to be drawn white. I did not
> > have time to fully debug this. But I think this happens because for mono
> > mode a separately allocated screen buffer pSTScreen is used:
> >
> > https://git.tuxfamily.org/hatari/hatari.git/tree/src/screen.c#n735
> > https://git.tuxfamily.org/hatari/hatari.git/tree/src/screen.c#n190
> >
> > If that memory allocation by chance happens to be *below* the ST RAM,
> > the check passes; otherwise (like on my AAarch64 system), it fails.
> > Imho, this needs to be fixed before a 2.4 release.
>
> Oh, drat, I added the checks with src/falcon/videl.c in mind that calls
> Screen_GenConvert(&STRam[videoBase], ...), i.e. fvram indeed points
> somewhere in the STRam[] array here. But Screen_ConvertHighRes() from
> screen.c uses the buffer that you spotted instead, so these checks are
> currently wrong. Thanks a lot for the hint, Christian, I'll try to come up
> with a solution (might take a while, though, since I'm pretty busy this week).
Fixed now. Hopefully I did not mess up something else along the way now ;-)
Thomas