Help with blitter descending mode.

[axilmar]

Hi,

I am stuck with how to program the blitter to blit in descending mode.

I want to blit a 16x16 bitmap from coordinates X=0,Y=200 to coordinates X=1,Y=220, without a mask.

I am correctly setting the bltxpt pointers to the last word of the respective areas, as per the hardware reference manual.

I am reversing the shift value, since, in descending mode, the shift is to the left.

The blit width is correctly calculated to 2 words.

However, despite the above, the blit does not come out right:

https://imgbb.com/6rkRf7S

I've followed the advice of user roondar (many thanks) in the other thread(https://eab.abime.net/showthread.php?t=109910), but still no good result.

Here is the blit function (this is an asm forum section, so I am not asking for corrections on my C code, I am only putting this here for reference; my question is about the blitter operation in descending mode):

https://pastebin.com/eiAeXVgm

Thanks in advance...

[a/b]

Originally Posted by axilmar

... from coordinates X=0,Y=200 to coordinates X=1,Y=200

X from 0 to 1 is right shift by 1. Typo or ...?

Originally Posted by axilmar

I am reversing the shift value, since, in descending mode, the shift is to the left.

Shift value should be the same if you are shifting by 1 pixel (regardless of direction).

[axilmar]

Originally Posted by a/b

X from 0 to 1 is right shift by 1. Typo or ...?


Shift value should be the same if you are shifting by 1 pixel (regardless of direction).

No, I want to blit a rect of 16x16 pixels from 0,200 to 1,220 (fixed destination Y).

The hardware reference manual says shifts are reversed in descending mode, but the blit is not correct with either 1 or 15 as a value (it's not correct for any shift value).

[roondar]

Yeah, sorry for not having more tips. I did use descending mode before, but I never actually tried shifting data alongside doing so. Hence I never had to work with masks/shifts in descending mode so I don't really know the caveats.

Generally I've just not really needed to use it.

[deimos]

To me it looks like your output rectangle isn't in the right place, it looks like it's a word to the right, and then it looks like you're shifting one to the right, but without anywhere for the pixels to go to on the right hand side, so they're wrapping around.



You're losing the top row in the result, I think the calculation for

start_y_off

shouldn't have a -1 in it.

I also question this

const WORD shift = force_desc ? (16 - lshift) : lshift;

If

lshift

has values 0..15, then won't

shift

take values 1..16?

Could you output all the values you put into the blitter registers for us?

[ross]

I haven't followed the previous thread but I see no reason why code like this shouldn't work:

	lea	((320/8)*(200+15),a0),a1
	lea	((320/8)*(220+15)+2,a0),a2

	move.l	#$f9f00002,($40,a6)
	move.l	#$ffff0000,($44,a6)
	move.l	a1,($50,a6)
	move.l	a2,($54,a6)
	move.l	#((320-32)/8)<<16+(320-32)/8,($64,a6)
	move.w	#16<<6+2,($58,a6)

Where a0=bitplane_start and a6=custom_base.

The descending mode works in a completely opposite way to the ascending mode so in this case the shift must be 15 and include one more word for the fetch, the mask must exclude the second word read and an incremented destination pointer used.
That's all

PS: if you want I can create a raw executable to test the code.

[axilmar]

Originally Posted by deimos

To me it looks like your output rectangle isn't in the right place, it looks like it's a word to the right, and then it looks like you're shifting one to the right, but without anywhere for the pixels to go to on the right hand side, so they're wrapping around.

Attachment 75109

You're losing the top row in the result, I think the calculation for

start_y_off

shouldn't have a -1 in it.

I also question this

const WORD shift = force_desc ? (16 - lshift) : lshift;

If

lshift

has values 0..15, then won't

shift

take values 1..16?

Could you output all the values you put into the blitter registers for us?

Regarding 16-lshift, you may be correct, it may be 15-lshift.

So, if I put 15 - lshift, and try to blit, the blitter values are these, for bitplane 0:

bltcon0 = 59338
bltcon1 = 57346
bltbmod = 196
bltcmod = 196
bltdmod = 196
bltafwm = 0
bltalwm = 65535
bltadat = 65535
bltbpt = 0x1f8ea
bltcpt = 0x2088a
bltdpt = 0x2088a
bltsize = 1026

The start of the source image, which is also the screen, and also the destination in this example (because I am trying to blit one part of a bitmap onto itself), is 0x150f0.

The result image is this (top row is missing, the image is shifted to the left 14 pixels, the first part of the image that is blitted contains the 2 rightmost image columns, the second part of the image that is blitted contains the 14 left most image columns):

https://ibb.co/LJfZQcc

The shift value in this case is 14, because x = 1 (shift = 15 - lshift, lshift = 1). Which does not look correct to me, I believe that when x = 1, the shift value for descending mode shall be 15.

[axilmar]

Originally Posted by ross

I haven't followed the previous thread but I see no reason why code like this shouldn't work:

    lea    ((320/8)*(200+15),a0),a1
    lea    ((320/8)*(220+15)+2,a0),a2

    move.l    #$f9f00002,($40,a6)
    move.l    #$ffff0000,($44,a6)
    move.l    a1,($50,a6)
    move.l    a2,($54,a6)
    move.l    #((320-32)/8)<<16+(320-32)/8,($64,a6)
    move.w    #16<<6+2,($58,a6)

Where a0=bitplane_start and a6=custom_base.

The descending mode works in a completely opposite way to the ascending mode so in this case the shift must be 15 and include one more word for the fetch, the mask must exclude the second word read and an incremented destination pointer used.
That's all

PS: if you want I can create a raw executable to test the code.

I did all the above but it still doesn't work.

Incrementing the destination ptr by 2 bytes (i.e. 1 word) has the effect of simply displacing the distorted image horizontally by 16 pixels.

[deimos]

Originally Posted by axilmar

Regarding 16-lshift, you may be correct, it may be 15-lshift.

So, if I put 15 - lshift, and try to blit, the blitter values are these, for bitplane 0:

bltcon0 = 59338
bltcon1 = 57346
bltbmod = 196
bltcmod = 196
bltdmod = 196
bltafwm = 0
bltalwm = 65535
bltadat = 65535
bltbpt = 0x1f8ea
bltcpt = 0x2088a
bltdpt = 0x2088a
bltsize = 1026

The start of the source image, which is also the screen, and also the destination in this example (because I am trying to blit one part of a bitmap onto itself), is 0x150f0.

The result image is this (top row is missing, the image is shifted to the left 14 pixels, the first part of the image that is blitted contains the 2 rightmost image columns, the second part of the image that is blitted contains the 14 left most image columns):

https://ibb.co/LJfZQcc

The shift value in this case is 14, because x = 1 (shift = 15 - lshift, lshift = 1). Which does not look correct to me, I believe that when x = 1, the shift value for descending mode shall be 15.

So I think you should ignore me and listen to Ross, "so in this case the shift must be 15 and include one more word for the fetch". That second part, adding 2 to your source address, might fix your missing top row, but I think you'll also need to tweak your destination address as it's currently, I think, one word too high.

Your blitcon values of 0xE7CA and 0xE002 are a bit different to Ross' of 0xF9F0 and 0x0002. You could try those values, and if it magically works then we know we need to work on your calculations of them.

[ross]

Originally Posted by axilmar

I did all the above but it still doesn't work.

Incrementing the destination ptr by 2 bytes (i.e. 1 word) has the effect of simply displacing the distorted image horizontally by 16 pixels.

Works for me. Attached the code applied.

Background filled with a pattern so you can view the exact blitter effect for this specific setup.
LMB start the blit, another to exit.

[ross]

Originally Posted by deimos

Your blitcon values of 0xE7CA and 0xE002 are a bit different to Ross' of 0xF9F0 and 0x0002. You could try those values, and if it magically works then we know we need to work on your calculations of them.

Yeah, I simply executed this:
"I want to blit a 16x16 bitmap from coordinates X=0,Y=200 to coordinates X=1,Y=220, without a mask."

So: minterm to do a bare copy, to the right by 1 pixel (16-1 in descending plus extra word and mask) and AD channel enabled +DESC bit.

EDIT:
I'am now looking at the values used by the user and there are many things wrong

As he is using a generic formula with a cookie-cut where the mask is in channel A, he used only the source pointer in B, but channel B does not have a usable mask.
In addition, channel C is also active (which does not make sense in this case).

Basically is a full cookie-cut blit, with a constant A channel and a wasted active C channel..
What exactly would you like to do? Keep the background too?

[axilmar]

Originally Posted by ross

Works for me. Attached the code applied.

Background filled with a pattern so you can view the exact blitter effect for this specific setup.
LMB start the blit, another to exit.

Hey, it actually worked for me too!

First, I interpreted the values from the asm code you posted above:

move.l    #$f9f00002,($40,a6)                   //bltcon0/bltcon1;0xf9f0/0x0002; shift = 15/blitreverse
move.l    #$ffff0000,($44,a6)                   //bltafwm/bltalwm; 0xffff/0x0000
move.l    a1,($50,a6)                           //bltapt; screen base + (320/8)*(200+15)
move.l    a2,($54,a6)                           //bltdpt; screen base + (320/8)*(220+15)+2
move.l    #((320-32)/8)<<16+(320-32)/8,($64,a6) //bltamod/bltdmod; 36/36
move.w    #16<<6+2,($58,a6)                     //bltsize; height = 16/width = 2(words)

Then I modified my blit code to this (accounting for interleaved bitmaps, different channel setup etc):

custom->bltcon0 = (15 << ASHIFTSHIFT) | SRCB | SRCC | DEST | 0xCA;
custom->bltcon1 = (15 << BSHIFTSHIFT) | BLITREVERSE;
custom->bltbmod = 200-4;
custom->bltcmod = 200-4;
custom->bltdmod = 200-4;
custom->bltafwm = 0xffff;
custom->bltalwm = 0x0002;
custom->bltadat = 0xFFFF;
custom->bltbpt = src->bitplanes[i] + (320/8*5)*(200+15);
custom->bltcpt = src->bitplanes[i] + (320/8*5)*(220+15)+2;
custom->bltdpt = src->bitplanes[i] + (320/8*5)*(220+15)+2;
custom->bltsize = (16<<6)+2;

And voila, it worked!

https://ibb.co/6N9jQFV

MANY MANY MANY thanks!!!!!!!

Now I have to find wtf does my original code do....;-)

[axilmar]

Originally Posted by ross

Yeah, I simply executed this:
"I want to blit a 16x16 bitmap from coordinates X=0,Y=200 to coordinates X=1,Y=220, without a mask."

So: minterm to do a bare copy, to the right by 1 pixel (16-1 in descending plus extra word and mask) and AD channel enabled +DESC bit.

EDIT:
I'am now looking at the values used by the user and there are many things wrong

As he is using a generic formula with a cookie-cut where the mask is in channel A, he used only the source pointer in B, but channel B does not have a usable mask.
In addition, channel C is also active (which does not make sense in this case).

Basically is a full cookie-cut blit, with a constant A channel and a wasted active C channel..
What exactly would you like to do? Keep the background too?

You are correct, of course. I'll fix it later, I know I should only do a A->D, since it's a simple copy. These are artifacts from the original code I copied and pasted into my code, for testing.

But anyway, thanks for noticing it.

For my first Amiga program, I am doing well (I think) (:-)).

[ross]

Originally Posted by axilmar

For my first Amiga program, I am doing well (I think) (:-)).

Sure!