Re: [hatari-devel] Hatari screen test

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 27 May 2020 21:20:21 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 5/27/20 8:50 PM, Thomas Huth wrote:
> > Am Wed, 27 May 2020 19:39:19 +0200
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:  
> >> By using natfeats calls and waiting for a specific message, you
> >> know the test is in progress / complete, you just have to wait for
> >> each messages that the test can print.  
> > 
> > I'm not sure whether introducing natfeats calls into a sensitive
> > test program like the fullscreen test is such a good idea - it's a
> > cycle accurate test program that you can also run on a real ST for
> > comparison. If we now add natfeats there, you first have to
> > struggle to get the cycles of the sync code right again, and then
> > it also won't work on a real ST anymore... so while natfeats are
> > good and nice for other tests (and we're indeed using natfeats
> > calls in other tests already), using the debugger for this test
> > like Eero suggested sounds like a better idea to me.  
> 
> It requires pushing file name pointer to stack,
> and NatFeats instruction, but those are needed
> only at the *end* of the screen, so why they would
> affect cycles used while drawing the screen?

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.

 Thomas