|Re: [hatari-devel] Hatari screen test|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Hatari screen test
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Thu, 28 May 2020 21:22:00 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1590693724; bh=8DIDwYPAK06z/VsJ+nofv+A7B9P92jhB3t6nb+im1Y0=; h=Date:From:To:Subject:From; b=rYf+jcjHK+hqR/yDALX+Mq7ZB59UC6ToabL5zVe1/lnu6pxg1/02eMBKN805PJWKZ pThe6C1MgKpVTWbof+LmYVortP40dopDTk+9JRqL//YfMAuw2XV1twl/eZMgtOr020 M0OXdn0QfvrrKS1uhf3FlsKnKMULg41UkM491EYKDQcXfyp10IX/6gsEo0NFMS4ICs 5csn5l4py9Xmb4vyaxRYUFyjV8oW+WJ1uDUvkYZs4vXHcRoRnE5YzM0gyx0JLc8mgB orz8D0lIDBp3hD+2Zbrg+/svI1NKAP/46fhouWdbBuJ/65pXIP/Fe/0G3fwy5JWsNd wk9xep7J38pUg==
Am Thu, 28 May 2020 02:23:38 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> 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
> 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
> 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! 
> 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