Re: [hatari-devel] Something broken in Hatari recently?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/1/19 7:26 PM, Nicolas Pomarède wrote:
> Le 30/09/2019 à 23:49, Eero Tamminen a écrit :
> > Check the icon texts in the attached screenshots. With latest Hatari
> > git version, TOS v4 fonts look broken.
> >
> > This doesn't happen with 2.2.1 release, and I don't see it with TOS
> > v3/TT, or older TOS versions.

Nor with EmuTOS.  I guess it's using blitter differently from TOS v4
(e.g. not for all the things that TOS v4 uses it).


> > Neither cache emulation, prefetch nor
> > MMU options affect it. I haven't tested Falcon for a while, but I
> > think this is recent issue.
> >
> > If you look at the TERRAIN.TRS file name in grab002.png image,
> > you can see that character 'R' is in some screen location rendered 
> > correctly, and in some other location incorrectly.  I.e. problem
> > isn't font data in ROM, but rendering it to screen (drawing of
> > the desktop folder contents utilizes blitter, but I think texts
> > are drawn with CPU). >>
> > Does somebody else see the same issue?
>
> did you try to bisect to see when this first appeared ?
>
> I made some small changes to blitter 1 or 2 weeks ago, don't know if 
> that's related (although I didn't see regression with some games/demos I 
> used for testing)

Bisect gave this commit as culprit:
-------------------------------------------------
commit f7855cae5e5d4e0ddc552cd6785119bb47c81d44
Author: Nicolas Pomarede <npomarede@xxxxxxxxxxxx>
Date:   Thu Sep 12 22:18:44 2019 +0200

    For the blitter, use x_count to decide to add src_x_incr or 
src_y_incr after reading each src word
    We use the same conditions as described in the blitter 
documentation, instead of handling
    an additional variable to count the number of reads
-------------------------------------------------

Reverting that patch, fixes fonts in TOS v4 desktop.


	- Eero