Re: [hatari-devel] New blitter code for xcount=1 nfsr=1

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 16 Sep 2020 23:53:42 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 16/09/2020 à 23:31, Thomas Huth a écrit :
> > Am Wed, 16 Sep 2020 17:30:50 +0200
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> >   
> >> Le 11/09/2020 à 09:23, Nicolas Pomarède a écrit :
> >>  
> >>>> Any chance you could add that test from BLIT.ZIP to the "make
> >>>> test" regression test suite?  
> >>>
> >>> that's planned to be next on my todo list :) It's indeed a good
> >>> test suite because it really checks many combinations and it
> >>> should be rather simple to add to the test suite.  
> >>
> >> Hi
> >>
> >> I made a "blitter" test to be run in the tests directory (see
> >> attachment)
> >>
> >> But I get an error when "run_test.sh" is using "--tos none" ; with
> >> debugging I see hatari reaches an illegal instruction then exits
> >>
> >> If I use "--tos emutos", then the blitter is working and succeeds
> >> as expected.
> >>
> >> Any idea why --tos none is causing an error ?  
> > 
> > Yes - if you run with --trace cpu_disasm, you can see this before it
> > jumps to the fake TOS ROM to print the panic message:
> > 
> > cpu video_cyc=4760 188@9 : 0000146E 3f3c 0026   MOVE.W #$0026,-(A7)
> > cpu video_cyc=4772 200@9 : 00001472 4e4e        TRAP #$0e
> > 
> > That means something tried to execute Supexec() which is not
> > implemented in the fake ROM. The fake TOS is indeed very, very
> > limited. So instead of using the PCSTART.O startup code in the .prj
> > file, you have to use startup.s from the tests directory there
> > instead, to make sure that there are no unwanted OS calls done by
> > the startup code. Alternatively, we could also try to implement
> > Supexec() and then run this test with "--bios-intercept on" ... but
> > there might be more missing OS calls later, so I'm not sure whether
> > that's worth the effort...  
> 
> Hi
> 
> does it mean that for now only  C program compiled with AHCC and this 
> startup.s code will work with --tos none ? It won't work either if
> the C program is compiled with gcc ?

I think it should work with other C compilers, too, if you use
startup.s as startup code there, and make sure that you don't use any
library functions that could call other unsupported OS functions.

> I don't know if we should add more OS calls to the fake TOS, but
> maybe we could add emutos as a required dependancy to run the tests ?

I don't like the idea of adding an EmuTOS image to the git repo ...
each time we have to update it, it will add another 0.5 MB to the
footprint of the repo (assuming that we have to use the 512k version to
support Falcon and TT mode, too), the test time might increase much
more code is executed, etc.

> I don't have ahcc installed on my setup ; could you compile blitemu.c 
> and send it to me and then I will push the blitter test to the git
> repo ?

Sure, attached is a version that should work. Note that I also had to
replace fopen() and friends with their TOS counterparts Fcreate() etc.
since the stdlib functions also tried to use some OS calls that were
not supported.

 Thomas

Attachment: blitahcc.zip
Description: Zip archive