Re: [hatari-devel] Videl / VBL interrupt issue in Hatari?

[ Thread Index | Date Index | More Archives ]


I have scraped a bit more information on this since it was first noticed, and maybe some kind of conclusion worth looking into.

1) The VBL routine itself is short and linear - no backward branches (loops) or jumps. There are a few conditional skips but these don't contribute much to execution time and don't touch any hardware. The total duration in the VBL is very, very small (I can post it if required). The VBL simply cannot delay itself for >1 VBL so there must be an outside influence for this to happen.

2) There are other interrupts occurring, but none of them have a duration even close to 1 VBL. One special case might be disk accesses - but there are none initiated during the period of the crash (I use Hatari tracing to check that, and all printf activity is directed through natfeats now - and there are no other ROM calls left - none show via Hatari tracing). It happens in the title sequence of the game, where it just flips through 2 images, both of which are fully cached in memory at the time of the crash. No other resources are needed to run the attract sequence.

3) It is likely that the Videl register settings are reloaded on each attract mode 'page flip' - and this is suspiciously correlates with the bug triggering, although I can't prove that just now.. The Videl registers being loaded are exactly those which you can configure via ScreensPain (SCP).

4) There is no reading of Videl state at any time - no 'hardsync' style operations which wait for Videl or MFP state to change. I made sure of this while testing the bug.

5) If the VBL yields to itself (move.w #$2300,sr) even briefly before terminating, another VBL eventually occurs in that short time window, and leads to infinite regress. It doesn't appear to happen immediately - but reliably, and once it begins it seems to recur until the stack blows up. This does not occur on a real Falcon. It seems not to occur during gameplay or is rare enough to appear that way, but assured to occur after some seconds or minutes flipping pages in the frontend - the main difference being the frontend likely reloads Videl settings every few seconds where the main game loop does not.

6) Removing the 'yield' stops the regress (no crash), but other telltale signs indicate there is still a problem - the double buffering is not working properly in the game. Again, the problem does not show on a real Falcon.

6) The original (still crashing, but relatively infrequently) version of the code set the physbase registers ($ff820x) in the game loop, and not in the VBL. There were no problems with double-buffering using this code.

7) The code has since been modified to set the physbase register early in the VBL itself. The probability of a crash seems to have got much worse since then, and has resulted in broken double-buffering (visible tearing, some other effects which prove to me that the backbuffer is being shown early). This tearing is not visible on a real Falcon.

8) To rule out a software cause for the broken double-buffering, I tested with the buffers reversed. Having done this I can *still* see the backbuffer, but with more exaggerated tearing - i.e. neither of the buffers is now acting properly as a backbuffer. The buffers are not being switched at 55Hz intervals, but at apparently random (?) intervals.

It's difficult to draw a conclusion from this, but it looks very much like writing Videl state (either physbase, or other registers - or both in close proximity) is generating at least one more VBL which then tries to occur on top of the one just executed. If allowed to execute within the original interrupt, it seems to want to occur again, causing infinite regress, blowing up the stack. If not allowed to execute within the original interrupt, it just executes when the original completes and messes up the buffer switching.

I'm going to try another test which prevents Videl registers from being updated after being set once - in case it is an interaction with that (However even if this is true it doesn't occur on my Falcon).


On 20 January 2014 12:15, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
Le 20/01/2014 13:11, Mariusz Buras a écrit :
Well, for instance, if your VBL routine would take almost entire frame
to execute on real falcon, on Hatari it could be more then one frame to
do the same task, so they would overlap.

AFAIK, BM doesn't run in 1 VBL on falcon anyway, more like 2 or 3 VBL per frame.

So this problem should already be taken into account, else it would not work as soon as the 1st seconds of game.
Usually, when program doesn't run in 1 VBL, you will use a short VBL code that mostly only set a VBL counter + a few others things that really need to be real time (sound, music, ...), and then the main program (outside of the VBL) waits for the counter to change before working on the next frame..


Mail converted by MHonArc 2.6.19+