|Re: [hatari-devel] New blitter code for xcount=1 nfsr=1|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] New blitter code for xcount=1 nfsr=1
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Wed, 16 Sep 2020 23:31:02 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1600291863; bh=lXfPuxjrq1RJdGTnLD2pVuKY1oI/weswW87WEX2KhuE=; h=Date:From:To:Subject:From; b=CSEOWL8Fqq1L0hRvllZ63h+2xnm6pqzGlEvFMLDI1+psha8hLvz/2PDv6PFOWEIwn joZ6koryGyWE/7+0DGvpLfkUGJ14XpqFtAAohuYLZ7T6Pr8sKolebZ5yUSzghve1l1 CgzlEs+B9PhZl7ub++3Mx8FJvpJtkeYgswpUK5lR4/nFVOcRHWa/F1J+QCHnxYO2UW WG7DtlU6ZtDcj5iVPRVkE59ctySF5rL85VDnE99TIxuLe1EZCqn690FTIoNgLrPErK kwW10APUBGaEdpezVpeNWQKAUgcO9x9oPc47jL/9AE30j1sc/rUNQZfbwqUVlwygnE LjPOtQErt7SrA==
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.
> I made a "blitter" test to be run in the tests directory (see
> 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
> 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