Re: [hatari-devel] problems in b/w mode

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Sat, 7 Jan 2012 16:12:41 +0100
schrieb Thomas Huth <th.huth@xxxxxx>:

> Am Thu, 05 Jan 2012 23:13:00 +0100
> schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> 
> > On 05/01/2012 21:47, Eero Tamminen wrote:
> > > Hi,
> > >
> > > On keskiviikko 04 tammikuu 2012, David Savinkoff wrote:
> > >>> Jan 3, 2012 02:37:40 PM, hatari-devel@xxxxxxxxxxxxxxxxxxx wrote:
> > >>> in our forum at atari-home.de we have discovered a problem in
> > >>> black&white mode. In this mode, hatari starts and it seems like
> > >>> that tos is loaded and it is getting into the desktop but with a
> > >>> black screen at all.
> > >
> > > Black screen comes immediately.
> > >
> > >
> > >>> German speaking people can read it here :
> > >>> http://forum.atari-home.de/index.php?topic=9098.msg63760
> > >>>
> > >> The included EmuTOS 0.8.6 works Atari TOS doesn't.
> > >
> > > TOS 2.05 works (2.06 doesn't) as does TOS 3.06.
> > >
> > > TOS 4.x asserts with:
> > > cycInt.c:378: CycInt_AddRelativeInterruptWithOffset: Assertion
> > > `CycleTime>= 0' failed.
> > >
> > > Every other TOS version (from v1.00 upwards) is stuck at startup
> > > with black screen when "-m" option is given.
> > >
> > 
> > Couldn't this be related to the patches thomas made in rev 3659 and
> > 3671 ? Does it works it you revert to before these patches ?
> 
> Ok, now I am back from vacation, ... and it seems like I broke it in
> revision 3671 (ce618cc0d7f5) - sorry! ... I will try to figure out the
> reason later today or tomorrow ...

I now (hopefully) fixed this problem. The main issue was that the code
in video.c uses three different ways to determine the resolution: The
"bUseHighRes" variable, the "VideoShifterByte" variable and
IoMem[0xff8260] directly. Right after reset, they were not in sync in
monochrome mode, bUseHighRes was true, VideoShifterByte was 2 but
IoMem[0xff8260] was zero. So some parts of the code used the HBL/VBL
timings for monochrome mode, some others used the timings for color
mode, so things got screwed up and HBLs/VBLs did not get triggered
anymore.
I fixed it now by setting IoMem[0xff8260] to the same value as
VideoShifterByte during reset. But maybe we should also get rid of
VideoShifterByte completely, since it just mirrors the information
from IoMem[0xff8260] and is hardly used in the code at all. Nicolas,
what do you think?

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/