A.D.A. Amiga Demoscene Archive

Hi,

I've been trying to get to grips with blitting source data with shifts & masks and I think I'm hitting some serious noob confusion. The HW ref manual is, I think, just confusing me more.

The data I'm trying to blit is 1 word wide, by 32 pixels high. I've no problem blitting this anywhere on a word boundary. All good.

So, next step; I'm trying to blit the same data but 8 pixels along the screen. Here's my code so far:

move.w #$89f0, bltcon0(a6) ; 8 pix shift, Use A & D, $FO lf
move.w #$0000, bltcon1(a6) ;

move.l #bobBPL, a1 ; Source A (16x32pix data)
move.l #emptyBPL, a0 ; Destination (fullscreen bitmap)

move.w #0,bltamod(a6) ; linear data
move.w #36,bltdmod(a6) ; 2 word blit size (crossing a word boundary)

move.w #$00ff, bltafwm(a6) ; mask out first 8 pix for
move.w #$ff00, bltalwm(a6) ; mask out last 8 pix

move.l a1, bltapt(a6) ; source addy
move.l a0, bltdpt(a6) ; destination addy

wait_blitter
wait_blitter

move.w #1026, bltsize(a6)


This does at least blit something to the correct place on screen, but it's not my source data in the correct, linear order. It's more like every other line, starting from the last 2 bytes of the first line.

I'm confused. :(

I understand the blitter barrel rolls, but my expectation was that, where the mask bits were unset, then the data would continue to be shifted to the next set pixel in the mask. This doesn't look like being the case, and now I've just typed that here it does make more sense that the data is just not written where bltaf/lwm is unset.

Did I say I'm confused? ;)

Can anyone explain (or give me a quick source example) about how to do this? I've tried the cookie cutter example from the HW ref manual, with an 8pix shift on the B channel, A unused in bltcon1, bltadat pre set to $ffff and the same masks as above and I can't get that to work either. It's much the same garble and I'm now going around in circles.

I know I'm doing something daft, so apologies in advance and thanks very much for any help :D

You need to wait for the blitter first before you write to any of its registers otherwise if it's still in use all hell could break lose ! My blitter graphics were once missing and I found them on my Devpac screen when I quit out of my program. I kid you not !!!

I thought the value you wrote to bltsize was wrong at first but you wrote it in decimal unlike the other registers which you write to in hex.

As before I haven't used the Blitter for 12 years so take my advice casually ;0)

I think you need to have an A channel modulo of -2 and not 0. The blitter is reading in 2 words per row and theres only 1 word in your data. So you need to set the A pointer back a word with the A modulo so it's still aligned correctly.

For Masks you need this:-

move.w #$ffff,bltafwm(a6); I want to see the graphics in the first word
move.w #$0000,bltalwm(a6); but not the second word as im just fetching it for scrolling.

Hope this helps (if I've rememberd the way the old blitter works).

PS Anyone care to estimate what Commodores main motivation was for putting tally/sort etc into the AAA blitter ? For doing filtering and colour/reduction stuff maybe ? AAA blitter had pixel addressing which made it much simpler to code for BTW.

"Blitter Confusion" sounds like the name of a cool demo :0)

i think toffee's advice is spot on with the 2words/scanline and the modulo-tweaking

Thank you, thank you, thank you!

Source modulo was bang on the money. I was seriously off course there and it's suddenly making lots of sense. Big smiles here :D

If I may continue this well named thread because I have reached a state of confusion about this special friend of ours ... yet again :)
ATM I'm messing around with the area fill feature. Although it basically seems to work the visible result is quite less than satisfying.
This is the scenario:

- 2 buffers in chipmem - "dest" and "buff" (one pointed to bitplanes)
- I draw a rectangle in "buff" at "top left corner". buffer looks as follows:

--- simplified 16x10

0000000000000000
0000111111110000
0000100000010000
0000100000010000
0000100000010000
0000100000010000
0000100000010000
0000100000010000
0000111111110000
0000000000000000

- blit this area from "buff" to "dest" (on screen) and try to fill the damn thing:


the result on the screen however looks like this:

0000000000000000
0000111111110000
0000100011111111
0000100011111111
0000100011111111
0000100011111111
0000100011111111
0000100011111111
0000111111110000
0000000000000000

do I have to shift or mask something 'cause it just looks shifted to the right???

Wow, you really managed to confuse the blitter! ;)

When doing area fills, you must use descending mode (bit 1 of bltcon1) since filling is done from right to left. That shouldn't make any difference with inclusive fills when your input has an even number of 1-bits in every word (except for pointers, modulos and shifts going the other way of course), but apparently that is not the case. It seems the blitter somehow depends on descending mode being set, not just to propagate the fill correctly from one word to the next, but also to fill each word correctly. I wonder what goes on inside this thing. :)

Another thing is that when filling, you should only plot the left and right boundary of the area to be filled. In this exact case, it would make no difference, since you have en even number of pixels in the top and border lines and are using inclusive fill, but in general, top and bottom boundaries should not be drawn.

I wonder what goes on inside this thing. :)

The logical thing to do following this uttering is of course for someone to investigate what exactly the blitter does when you enable area fill but not descending mode. It might be useful for something. ;)

Actually, for the Exclusive Fill, Inclusive Fill, Fill Carry In And Descending Mode bits, only 6 out of 16 combinations are valid according to the AHRM. Lots of undocumented combinations to investigate! :-D

thanks a lot Blueberry. Works now. The hardware reference confused me a little about the DESC mode. I though it would only be necessary when source and destination address were the same.

6 out of 16 combinations are valid according to the AHRM. Lots of undocumented combinations to investigate! :-D

ehehe, just like a 21 speed bike. Only some combinations are good the rest could damage the chain :)

Hmm, I ran some blitter tests on my A1200 with various combinations of ascending mode and fill, and I did not see any difference from how the fill works in descending mode. The words are filled the same way and propagate to the next word the same way. Did you really just change from ascending to descending mode (and changed the modulos accordingly) and then it worked? Which Amiga model are you running on? Maybe your blitter is broken? ;)

actually, the square I tried to fill was 40x40 pixels ...or 32 (don't remember correctly) and then blitted the outlines as a chunk of 48x48 to the screen. Also I pointed to the first word of the source address instead of the last.
I don't know exactly the board revision but it's a 1200 with 3.1 ROMs and and the generally known expansions.

The logical thing to do following this uttering is of course for someone to investigate what exactly the blitter does when you enable area fill but not descending mode. It might be useful for something. ;)

Turns out it is indeed. I will be utilizing this very combination in my 4k for Breakpoint. ;)

It is not exactly often that I find use for a technique I invented 12 years ago. :-D