Re: [hatari-devel] Hatari screen test

[ Thread Index | Date Index | More Archives ]

This is a multi-part message in MIME format.

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

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 ------------

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 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.

Mail converted by MHonArc 2.6.19+