Re: [hatari-devel] Hatari screen test

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

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?

Using NF in a test makes it a bit more
complicated, as it needs to include support
for NF ID initialization and careful call
placement.

So I concur with Thomas that using debugger
is better, as I prefer simpler test-case code.


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.

Hwoever, I don't understand how the current
run_test.sh script can produce correct results
so reliably...


	- Eero

[1] i.e. exact breakpoint to use is:
---------- debugger.ini -----------
# parse screenshot.ini on 5th VBL on which A0 has required value
breakpoint  a0 = 0xFFFF820A  &&  VBL ! VBL  :trace :file info.ini  :5 
:trace :file screenshot.ini
-----------------------------------

Note: breakpoint conditions are short-circuited.

If VBL change check is put first, one can deduct
one VBL as A0 changes only on HBL = 34.

However, when one uses tracing breakpoints with
'!' condition for VBL, breakpoint would then
output all VBL changes from emulation start, as
that first condition is hit first.  This is a bit
too verbose, so I prefer having A0 check first.