Re: [hatari-devel] Hatari screen test

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 27 May 2020 19:39:19 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 27/05/2020 à 19:32, Eero Tamminen a écrit :
> 
> >>   - natfeats "screenshot filename.png"  
> > 
> > Being able to give a screenshot name is a good,
> > but I think I'll return an error if there are any
> > path separators given.  Emulated program should
> > not be able to dictate on which directories it
> > writes to.
> >   
> 
> Hi
> 
> yes, command should be simple and not allow accessing every path.
> User can use the "screenshot dir" option if required.
> 
> >   
> >>   - natfeats "print 'fullscreen test complete'"
> >>   - natfeats "quit hatari"  
> > 
> > These are NF_STDERR & NF_EXIT natfeats calls.
> > 
> >   
> >> This way, no more sync problem or sleep to adjust, you can even
> >> run hatari in fast forward mode during the test and it will work.  
> > 
> > They already can run in fast forward mode, and looking at Thomas' 
> > run_test.sh, it already does.
> > 
> > I.e. 0.2s (and now 0.1s) wait can actually cover
> > a much larger range of VBLs, than what I thought
> > in my earlier mail...  
> 
> Yes, but what I meant is that even if it runs fast already, being
> able to remove "sleep" from tests would be good because it's never
> easy to fine tune the sleep delay for all possible cases/tests.
> 
> 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.

 Thomas