Re: [hatari-devel] Re: Yanartas crash

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/02/2015 22:52, Troed Sångberg a écrit :
> If we move the discussion from synclocked lower border (where the cycle
> is 502 on both STE and STF, with the usual wake state dependant move 2
> cycles later in WS2/WS4) to top border instead we're suddenly not
> synclocked any longer*. That means that other timings come into play -
> and there I have unfinished research pointing to a 4 cycle difference in
> specific wake states/a specific wake state (not all!). It does not
> change at which cycle the "border check" takes place - but it does
> influence where you end up after having used timers.
>
> It doesn't surprise me that a demo can be fixed by making sure the
> "timer jitter" never triggers a miss - but this does not support the
> GLUE state machine border checks being different between ST and STE.
> Sorry. The code I posted in my earlier message is as simple as possible
> and shows it quite clearly.
>
> /Troed
>
> *) I dare to bet in regular demo usage. However, for my state machine
> research I've opened the top border sync locked as well.

Hi

yanartas doesn't synclock before removing top border, so it's sensitive 
to jitter due to the length of the instruction being interrupted by VBL 
and to the E clock.

But in my test program I sent to remove top border, I synclock on 
previous VBL on line 198, so the delay should be the same, as STF and 
STE both have 160256 cycles per VBL at 50 Hz (and my program doesn't use 
timer, all the code runs with SR=2700)

So, we have 2 different tests programs that both synclock with ff8209, 
but we get different results, that's quite a mystery to solve :)

Nicolas