Re: [hatari-devel] Monochrome bug with latest Hatari

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 27 Dec 2015 22:15:16 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 27/12/2015 22:01, Thomas Huth a écrit :
> > Am Sun, 27 Dec 2015 21:47:45 +0100
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> >
> >> Le 27/12/2015 19:06, Eero Tamminen a écrit :
> >>> Hi,
> >>>
> >>> Hatari shows following monochrome mode demo:
> >>> http://miniserve.defence-force.org/svn/public/atari/demos/defenceforce/TimeSlices/Final/timslces.prg
> >>>
> >>>
> >>> in wrong graphics mode.  It seems like it were in
> >>> low/med rez instead of monochrome, although monochrome
> >>> mode doesn't support such resolutions.
> >>>
> >>> Earlier Hatari version works fine.
> >>>
> >>> See attached screenshots.
> >>>
> >>
> >> Hello
> >>
> >> I saw the same things and was looking at it. In video.c
> >> Video_CopyScreenLineMono seems to be the same as in Hatari 1.9, so
> >> I wonder if the change could be related to the cleanup Thomas made
> >> earlier to remove some of the unused conversion functions between
> >> planar and 8/16/24 bits ?
> >
> > Yeah, it's likely due to the different screen convert function ... I
> > think the new way is not taking the line width register ff820f into
> > account yet ... It seems to work better when using a patch like
> > this:
> >
> > diff -r c70bfb005c69 src/screen.c
> > --- a/src/screen.c      Sun Dec 27 10:32:43 2015 +0100
> > +++ b/src/screen.c      Sun Dec 27 21:59:18 2015 +0100
> > @@ -33,6 +33,7 @@
> >   #include "configuration.h"
> >   #include "avi_record.h"
> >   #include "ikbd.h"
> > +#include "ioMem.h"
> >   #include "log.h"
> >   #include "m68000.h"
> >   #include "paths.h"
> > @@ -1334,7 +1335,8 @@
> >
> >          if (bUseHighRes && !bUseVDIRes)
> >          {
> > -               return Screen_GenDraw(VideoBase, 640, 400, 1, 640 /
> > 16, 0, 0, 0, 0);
> > +               int linewidth = 640 / 16 + IoMem_ReadByte(0xff820f);
> > +               return Screen_GenDraw(VideoBase, 640, 400, 1,
> > linewidth, 0, 0, 0, 0); }
> >          else
> >          {
> >
> > However, the main screen then still does not work right yet.  I'll
> > have a closer look at it when I've got some spare time (likely not
> > within the next 3 days ...)
> >
> 
> patch tested, I confirm it's better. Regarding the main part, it's 
> indeed still broken, but maybe that's something else than the
> conversion functions.

I haven't looked into it yet, but I guess the demo is using some video
tricks like writing to the screen counter registers during HBL. So that
needs to convert the buffer which is updated on each HBL instead of
converting the buffer in the ST RAM - i.e. replacing "VideoBase" in
above code with pSTScreen should basically fix this problem.
.... but I'd like to double-check some possible issues first before
committing that, to make sure that there are no other problems left
(i.e. I first need some spare time for that).

 Thomas