Re: [hatari-devel] problems in b/w mode |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Am Sun, 8 Jan 2012 21:23:26 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> Hi,
>
> On sunnuntai 08 tammikuu 2012, Thomas Huth wrote:
> > > However, TOSv4 still asserts at boot:
> > > ----
> > > $ hatari -m --machine falcon --tos tos404.img
> > > ...
> > > hatari: /home/eero/work/hatari/src/video.c:2788:
> > > Video_StartInterrupts: Assertion `CyclesPerVBL <= 8012800/49'
> > > failed. Aborted
> >
> > When did you update your source tree? I noticed a problem in Falcon
> > mode, too, and updated it ca. 3h ago. Now it's working fine for me
> > in Falcon mode, too.
>
> Doesn't work for me, even with "make clean & make".
>
> Gdb tells:
> hatari: /home/eero/work/hatari/src/video.c:2788:
> Video_StartInterrupts: Assertion `CyclesPerVBL <= 8012800/49' failed.
D'Oh, I just also did a fresh "./configure --enable-debug" and suddenly
the assert is also showing up here. Strange, I was pretty sure that I
already enabled debug mode when I ran configure the last time...
> #4 0x080d4582 in Video_StartInterrupts (PendingCyclesOver=10) at
> /home/eero/work/hatari/src/video.c:2788
> 2788 assert(CyclesPerVBL <= CPU_FREQ/49);
> (gdb) info locals
> FrameCycles = 78
> HblCounterVideo = 0
> LineCycles = <value optimized out>
> Pos = 4681
> __PRETTY_FUNCTION__ = "Video_StartInterrupts"
> (gdb) print 8012800/49
> $3 = 163526
> (gdb) print CyclesPerVBL
> $4 = 254508
>
> (gdb) list
> 2785 /* TODO replace CYCLES_PER_FRAME */
> 2786 CyclesPerVBL = CYCLES_PER_FRAME;
> 2787 /* Note: Refresh rate less than 50 Hz does not make
> sense! */
> 2788 assert(CyclesPerVBL <= CPU_FREQ/49);
> >>> CYCLES_PER_FRAME is:
> (gdb) print nScanlinesPerFrame*nCyclesPerLine
> $11 = 254508
> (gdb) print nScanlinesPerFrame
> $13 = 501
> (gdb) print nCyclesPerLine
> $14 = 508
>
> Which of the above values is wrong?
nScanlinesPerFrame = 501 is the setting for monochrome mode (color
uses 313 or 263), and nCyclesPerLine = 508 is the setting for 60 Hz
color mode (monochrome uses 224 cycles instead).
==> The timings were still mixed between mono and color.
I tried another fix, and I really really think it should be fine now.
Maybe this is a good point in time now to test your new tosboot
regression script ...
> Btw. Why clocks_timings.c has global and video.c a local version of
> CyclesPerVBL?
>
> clock_timings.c default for CyclesPerVBL is also > 8012800/49:
> (gdb) print MachineClocks.CPU_Freq / nScreenRefreshRate
> $6 = 225950
clocks_timings.c seems to depend on the real CPU frequency when running
in Falcon mode, while video.c is always using ST timings internally (we
do not support real TT or Falcon video timings yet).
Thomas