Blitter Question.

[cdoty]

Any idea what could cause the blitter to product strange results?

I use the blitter to restore parts of the screen, and then blit a sprite.

The restore blit produces weird errors, the width should be 32 pixels and the height should be 16 pixel, but it almost appears to reverse these values (0x0402 is my BlitSize), and my mod value is 36 ((320 - 32) / 8) for source A and Dest D. In between blitting the 5 planes, I am only setting channel A, D pointers and, BLITSIZE. I normally wait fo the blitter to complete between planes, but have also commented out the wait.

And using the same values, I can blit a sprite correctly. The only differences are the use of all 4 channels, masking the last word, mod values for channels A and B (mask and pixel data) and, a shift value for channels A and B. The mod values for C and D are the same as above. BLITSIZE is the same as above. My sprite is acutally 16 x 16, but I use the extra 16 bit as required and mask the last word.

The correct pixels are transferred, but the locations are wrong. I can see what it's doing, if I override the source in the restore operation.

I am using the AA chipset, but only using 5 planes.

I've debugged and verified that the values are what they should be.

[Codetapper]

Are you sure the modulo for source A in the restore part shouldn't be 0? If you're effectively saving the background that is going to be destroyed to a buffer, it's likely to be a continuous buffer in memory so no modulo on the A channel.

Can you attach your source code so we can see everything in that routine? Is your sprite on a word boundary itself - ie. up against the far left? What minterms are you using? (I think source would be easier to look at!)

Also pictures of the screen before the screen restore, after screen restore, after new blit etc would be useful if you can do that.

The theory you've written does all sound correct, so it must only be a small bug.

[girv]

Source code and screenshots if possible would be very helpful

I assume youre doing a $9f0 D=A copy blit for the restore?

What size is your capture area?

If you set bltcon0=$1f0 or set the source to a block of all $ff, is the correct area of screen affected? Is it possible that the initial blit to capture the background is borken and capturing the wrong data?

[cdoty]

Originally Posted by Codetapper

Are you sure the modulo for source A in the restore part shouldn't be 0? If you're effectively saving the background that is going to be destroyed to a buffer, it's likely to be a continuous buffer in memory so no modulo on the A channel.

Can you attach your source code so we can see everything in that routine? Is your sprite on a word boundary itself - ie. up against the far left? What minterms are you using? (I think source would be easier to look at!)

Also pictures of the screen before the screen restore, after screen restore, after new blit etc would be useful if you can do that.

I'm actually blitting from a 320 x 224 background screen to the screen (which is also 320 x 224)

* D0 - Bitplane mod value
* D1 - Blitsize
* A0 - Back pointer
* A1 - Screen pointer
BlitBack:
jsr BlitterWait
* Set Source A first and last word mask
move.l #0xFFFFFFFF, BLTAFWM

* Set Source A modulo
move.l d0, BLTAMOD

* Set Dest D modulo
move.l d0, BLTDMOD

* Set blitter control bits
move.l #0x09F00000, BLTCON0

* Do 5 bitplanes
move.l #(5-1), d7

BlitBackLoop:
jsr BlitterWait

* Set Source A
move.l a0, BLTAPT

* Set Dest D
move.l a1, BLTDPT

* Blit start and size
move.w d1, BLTSIZE

* Advance to next bitplane
add.l #PLANESIZE, a0
add.l #PLANESIZE, a1

dbra d7, BlitBackLoop

rts

PLANESIZE is 320 * 224 / 8
D0 is 36
D1 is 0x0402 (I've also tried 0x0401 and 38 for Mod value, since I'm not using a shift)
A0 is the background data (320 x 224 x 5) allocated as CHIP
A1 is the screen (320 x 224 x 5) allocated as CHIP

You can download the program from http://www.emuvibes.com/Frog.zip. It uses the A button and not start as shown on the screen, this allows testing in WinUAE.

This is setup as a CDTV bootable CD, although all testing is done on the WinUAE CD32 configuration in NTSC. The BlitBack is changed to point A0 to the top of the background data before entering the BlitBackLoop. This make the area that is blitted more obvious.

I'm hoping that this isn't just a bug in WinUAE.

[cdoty]

Originally Posted by girv

I assume youre doing a $9f0 D=A copy blit for the restore?

What size is your capture area?

If you set bltcon0=$1f0 or set the source to a block of all $ff, is the correct area of screen affected? Is it possible that the initial blit to capture the background is borken and capturing the wrong data?

It fills an area above the sprite. I'm not actually capturing the screen, I blit from a duplicate copy back to the screen.

[cdoty]

I've posted the relevant parts of the source to http://www.emuvibes.com/Src.zip

It starts in Sprites.c with AddSprite, which does work correctly.

Then any changes in the sprite's position or graphics causes AddEraseBlock to be called.

These are restored starting in WaitVBlank in Routines.s. WaitVBlank calls RestoreBackground, which processes through the EraseBlock structure looking for any used EraseBlocks. RestoreBackground calls BlitBack for each block found.

[girv]

MOD registers are word sized

[cdoty]

Originally Posted by girv

MOD registers are word sized

D'oh! that was it. It works fine now.

I looked at that routine for hours yesterday, and it was solved in minutes here.

[girv]

Originally Posted by cdoty

I looked at that routine for hours yesterday, and it was solved in minutes here.

Do you understand why it didn't work before and what was happening when you were writing longs to AMOD and DMOD? I dont mean to be patronising, I'm just offering to explain if you don't get it Nothing worse than blindly applying a fix without understanding why it was broken in the first place.

And don't worry about staring at code for hours and missing obvious bugs,we all do it!

[BippyM]

nice to be able to understand that code regardless

/me whips out some asm books

[cdoty]

Originally Posted by girv

Do you understand why it didn't work before and what was happening when you were writing longs to AMOD and DMOD? I dont mean to be patronising, I'm just offering to explain if you don't get it Nothing worse than blindly applying a fix without understanding why it was broken in the first place.

I was initally going to post a reply back about the MOD register being in bytes, but then it hit me what you were saying.

I realized I was writing the high word to BLTAMOD (which was zero) and BLTDMOD. For a moment BLTDMOD contained the right value.

Thanks for the help.

[cdoty]

If you're interested in seeing the results (and downloading the demo), check it out at http://www.game-shoppe.com/.