Re: [hatari-devel] Re: Yanartas crash

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


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



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