Re: [hatari-devel] Hatari screen test

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Thu, 28 May 2020 02:23:38 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 5/27/20 10:12 PM, Nicolas Pomarède wrote:
> > Le 27/05/2020 à 20:43, Thomas Huth a écrit :  
> >> I haven't completely looked through that code, but to my
> >> understanding, such fullscreen routines do something in almost
> >> each and every line of the screen... there are certainly some
> >> spots where you could try to fit such a natfeats instruction (e.g.
> >> right before the final "move.w #$2300,(SP)" instruction), and in
> >> the worst case you could also sacrifice the last line and not open
> >> the borders there to gain some spare time ... but still, if the
> >> routine is then not working on a real ST anymore, that's rather
> >> unfortunate, I think. 
> > 
> > I think it's possible to set an exception for illegal instruction
> > to catch the natfeats under a real ST (or when natfeats is
> > disabled) and then you can call it after the last fullscreen line.
> > In all cases, last fullscreen line will be HBL 307 (or 309 by going
> > to 60 Hz again, I don't think flix's code is doing that).
> > 
> > So, once on HBL 310 for example, there shouldn't be any cycle
> > accuracy required, fullscreen code should just wait for the next
> > VBL and calling natfeats function should not have an impact.  
> 
> Attached is NF_SCREENSHOT support & test code.
> Any comments on it?

I don't think that we really need this. We could also use XBIOS #20
interception to trigger a screenshot from the ST side if necessary (see
XBios_Scrdmp()).

> I investigated the VBL issue a bit more and
> I'm now more mystified.  By using this:
> ---------- debugger.ini -----------
> breakpoint  a0 = 0xFFFF820A  &&  VBL ! VBL  :trace :file info.ini
> ------------- info.ini ------------
> e VBL
> e HBL
> r
> -----------------------------------
> 
> I can see what are the HBL, VBL and register
> values when that breakpoint hits.  First hit
> happens on HBL 34.
> 
> However, the really interesting thing is that
> *5* additional VBLs are needed for screenshot
> to look correct! [1]
> 
> Looking at the assembly code, install_all()
> subroutine sets A0 value first, then does
> 2 vsyncs, and get_lines() subroutine does also
> 2 vsyncs.  These are before the real fullscreen
> routine starts, which explains the need for
> extra 5 VBLs.

Are you sure that your breakpoint triggered at the right point in time?
A0 is only set to FFFF820A in the open_top2 section during fullvbl ...
which should be called only after all the initialization stuff has been
done. During install_all, A0 is set to FFFF8201 instead.
==> Please double check that your breakpoint really triggers at the
right location.

 Thomas