[hatari-devel] Re: [Emutos-devel] blitter

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 05/08/2017 07:57 PM, Christian Zietz wrote:
> "Markus Fröschle" schrieb:
>
>> Feel free to pull the fork at https://github.com/mfro0/emutos for
>> testing and address any issues to me.
>
> Tested on my 1040STFm with added Blitter. I noticed that some of the
> icons on the desktop are not correctly redrawn after I open and then
> close the desktop's preferences dialog. The edge of this dialog goes
> right through the icons in question. See
> <https://ocean.czietz.de/index.php/s/SXMOS3jsuI1yGge>
>
> Happens on the STE, as well.

On 05/08/2017 09:56 PM, Christian Zietz wrote:
Christian Zietz schrieb:
Like you, I also wasn't able to reproduce this with Hatari. But I can
reproduce the incorrectly drawn icons with Steem SSE 3.9.1. Maybe
Blitter emulation in Hatari is not 100% accurate?

CCing hatari-devel.  I assume Nicolas will be interested about
any emulation issues.

Which Hatari version you used?


I used part of the debugging code in do_blit() to dump the Blitter
configuration prior to the call to blitter_do_blt(blt).

In the Hatari debugger you can use:
	info blitter

To check current blitter settings.


	- Eero

Here's a case where an icon is drawn correctly:

X COUNT 2
Y COUNT 32
X S INC -2
Y S INC -2
X D INC -2
Y D INC -78
ENDMASK 0xffff-ffff-0007
S_ADDR  0x00026c7e
D_ADDR  0x003fac74
HOP 2, OP 7
NFSR=1,FXSR=1,SKEW=0

... while this is a case where the icon is *not* drawn correctly like
shown in my previous photo:

X COUNT 1
Y COUNT 32
X S INC -2
Y S INC -4
X D INC -2
Y D INC -80
ENDMASK 0xffff-ffff-0007
S_ADDR  0x00026c7e
D_ADDR  0x003fac72
HOP 2, OP 7
NFSR=1,FXSR=1,SKEW=0

As you can see the difference is that the X count is only 1. Probably
something special happens (in the real Blitter and in Steem) when only
one word per line is copied, that is not properly accounted for in your
code.

Regards
Christian




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/