Blitter shift eats 1px away

[KONEY]

OK, at this point I know I'll have to live with the fact that experts among this section will hate me... but I'm stuck again with blitter

I have a problem using the shift function, basically it works but at every complete loop it eats 1px away, resulting in complete deletion of the scrolled part. I made a video to show what happens:

[ Show youtube player ]

I've been checking my code dozen of times without finding anything wrong but at some point I tried the example from the Photon/Scoopex youtube tutorial and the problem is also there!

this is the video [ Show youtube player ] but I'll attach also a picture which shows better what's happening.

CODE: https://github.com/KONEY/asm68k-test...OBMP2X_BLIT3.s

any hint?

[Antiriad_UK]

What is your last word mask set to? Bits shifted off the end wrap around and can look like this (from the video, not sure about the pic ). Set your LWM to $0 to test if the problem goes away and if it does then add something like this:

;To prevent data that is scrolled out of the left reappearing on the right we have to mask the LAST word 
;By the same amount that we are shifting. Last mask is applied BEFORE the shift occurs so only zeros
;get shifted back into the right
;shift 1, mask $7fff
;shift 2, mask $3fff
;d3=shift amount
	moveq	#-1,d0				; $ffffffff for FWM/LWM
	lsr.w	d3,d0				; add x number of zeroed bits to LOW word (LWM)
	move.l	d0,bltafwm(a6)			;FWM, LWM

If not, then show some code

[KONEY]

ah sorry I forgot to put the source!

https://github.com/KONEY/asm68k-test...OBMP2X_BLIT3.s

but yes I'll verify what you suggest, thanks!

[Antiriad_UK]

Yeah, line 244 of that source change:

	MOVE.W	#$FFFF,BLTAFWM	; BLTAFWM lo spiegheremo dopo
	MOVE.W	#$FFFF,BLTALWM	; BLTALWM lo spiegheremo dopo
	MOVE.W	#%0001100111110000,BLTCON0	; BLTCON0 (usa A+D); con shift di un pixel

to

	MOVE.W	#$FFFF,BLTAFWM	; BLTAFWM lo spiegheremo dopo
	MOVE.W	#$7FFF,BLTALWM	; BLTALWM lo spiegheremo dopo
	MOVE.W	#%0001100111110000,BLTCON0	; BLTCON0 (usa A+D); con shift di un pixel

[KONEY]

I'm a bit confused, now the shift happens at the middle of the screen but the problem persists. See pic.



Have you got a link for me about this behaviour?

[Antiriad_UK]

Check your A/D ptrs. They should be pointing to the last word of the buffer for desc mode. They look to be pointing one word past that:

MOVE.L	#_DUMMYTXT,BLTDPTH
...
DUMMYTXT:
	INCBIN	"dummytxt_320_8_1.raw"
	DCB.W	8,$5E
_DUMMYTXT:

So ptr should be _DUMMYTEXT-2.

Not sure what the dcb.w 8,$5e is? Assuming this dummytxt file is just a 320x8 bitmap that you are trying to scroll off the screen?

[KONEY]

no that was a test to add some data at the end and see if I can overcome the problem, that is what generated the extra pixels. Now I removed it but the scroll is still eating the 1 pixel.

[Antiriad_UK]

And you changed both the APTH an DPTH lines to _DUMMYTEXT-2?

[KONEY]

no I did change
MOVE.W #8*64+320/16,BLTSIZE
to
MOVE.W #8*64+336/16,BLTSIZE

I was trying to move a larger area with 0s at the end, with no success

[Antiriad_UK]

Well I just did everything I said and tested it and it works as I expected (assuming I understood what you are trying to do).

Changed BLTALWM to $7fff
-2 from _DUMMYTXT in BLTAPTH/DPTH
Removed dcb.b 8,$5e
Changed all sizes to 320



Edit: Oh and get out of the habit of running your assembler in case-insensitive mode. It's an accident waiting to happen! Also, having constants defined at the top and then using magic numbers in the code also confused me
Edit: If you were expecting the text to scroll back in on the right then that's something different.

[ross]

Just a quick look.

Blitter waits are wrong.

[StingRay]

Blitter waits are wrong and why is there a dcb.w $8,$5e right behind your DUMMYTXT? Change this to ds.w 8 and the problem will, most likely, be fixed.

Edit: Looks like Antiriad was faster. However, I'm quite sure there is no need to change the masks or anything else, code should work with just the blitter waits fixed and the dcb.w 8,$5e line corrected.

[ross]

Yep, with blitter wait fixed (and Antiriad fix) the code now works.
Just tested

[Antiriad_UK]

I can't see what's up with the blitwaits, oh my god what have I missed? My own blitwait macro may be broken. Is it the byte access in a register? Sure I read it was illegal but everyone does it and works ok?

[StingRay]

Originally Posted by antiriad_uk

i can't see what's up with the blitwaits, oh my god what have i missed? My own blitwait macro may be broken. Is it the byte access in a register? Sure i read it was illegal but everyone does it and works ok?

dmaconr = $02.

[ross]

Originally Posted by Antiriad_UK

I can't see what's up with the blitwaits, oh my god what have I missed? My own blitwait macro may be broken. Is it the byte access in a register? Sure I read it was illegal but everyone does it and works ok?

A write to BLTDPT before the wait .

[Antiriad_UK]

Ahhhhh.

Two mistakes then!

[StingRay]

Yep, for the bit of extra fun.

[KONEY]

eheh no you were fooled by the masking, just like me in the beginning

the problem is still there, if you BLTALWM back to $ffff you can see it.

At the end my code will have that mask in but it will have 2 more bytes where I'm going to put the new text in place, 2 chars at the time every 16 frames. It's meant to be a text scroller, so needs to be "dynamic". But when I put some data in those 2 new bytes the very same problem starts again, so in my example I've shown an early version with dummy text which was a better example

So what I'm trying to do is a working shift in place first, with the text coming back from the right.

Originally Posted by Antiriad_UK

Well I just did everything I said and tested it and it works as I expected (assuming I understood what you are trying to do).

Changed BLTALWM to $7fff
-2 from _DUMMYTXT in BLTAPTH/DPTH
Removed dcb.b 8,$5e
Changed all sizes to 320



Edit: Oh and get out of the habit of running your assembler in case-insensitive mode. It's an accident waiting to happen! Also, having constants defined at the top and then using magic numbers in the code also confused me
Edit: If you were expecting the text to scroll back in on the right then that's something different.

[KONEY]

OH YES, blitter waits below a write... that is wrong!

Btw after fixing that it still scrolls oddly, both with my code and with Antiriad_UK's.

As I mentioned, besides my code being crap and confusing you guys, I think the problem is not with masks and pointers but somewhere else. In fact also in this example from Photon/Stingray you can see the very same behaviour.

We could be doing the same mistake but it's a bit unlikely...