Strange bitplanes/copper alignment problem

[Muzza]

Hi,

I have a fairly standard vertical scrolling routine where I use the copper to adjust the bitplanes pointer back to the top of the bitmap at the required scanline. It works like this:

1. Wait Until Line N-1
2. Set BPL1MOD & BPL2MOD (modulo trick to fix the Low Word of the new bitplanes address)
3. Wait Until Line N
4. Set BPL1PTH through BPL8PTH (High words of new bitplanes address)
5. Reset BPL1MOD & BPL2MODback to their normal values.
6. End Copper

Note that this is using AGA, and setting all 8 bitplanes. Also it occurs both on a real A1200 and in an emulator.

I've had this running for months without problem, but recently discovered that it goes wrong when the memory address of the bitplanes is allocated at certain positions in chip ram.
For example, if the bitplanes are allocated at 0xDF404 it works, but if they are at 0xDF944, it fails. When it fails it looks like the copper is failing to set some of the higher bitplane addresses correctly, and I get corruption after the copper split.
I get the same pattern if the bitplanes are allocated at 0xCF404 vs 0xCF944 and 0x2F404 vs 0x2F944 and so on. (first address good, second address bad)

I thought perhaps it was an alignment problem, but aligning the bitplanes pointer to various values makes no difference. I have plugged in loads of addresses to try and find a pattern and gone over my copper code a thousand times. The only reliable (I think) fix I have found is to do this when allocating the chip ram:
bitplanesPtr = bitplanesPtr & 0xfffff0ff
(obviously I have to alloc extra memory to do this adjustment)

This doesn't make any sense to me, and it has been driving me mad the last few days, so I'm hoping someone with more hardware/copper experience can shed some light or give some ideas?
Thanks for reading.

[meynaf]

Looks like race condition between copper and display.
It is possible that BPL1MOD and BPL2MOD are somehow added after some high words of bitplane addresses have been set.

Anyway, it's clear the problem is linked to carry propagation from low word to high word.

Why isn't the modulo enough to fix the address ?
If the difference is never bigger than 32k (a single plane should be smaller than this), then you don't need to touch the high word at all.

[ross]

fmode

=?

[Muzza]

Fmode is zero.
Bitmap is interleaved which is why I need the high word.

[ross]

Can you post a WinUAE savestate with a non-working example?

On AGA there is some weirdness with high FMODE fetches/alignment/MODULO, but not for FMODE=0 (that I know of..).
See: http://eab.abime.net/showthread.php?t=94943

[meynaf]

Using 8 bitplanes with fmode=0 is gonna eat all chipmem bandwidth. Probably not the right thing to do.

[Muzza]

Thanks for the responses. I investigated various thing based on the above, and have found the problem to be a simple calculation error. My scrolling code was based on the aminet 'ScrollingTrick' examples, and it looks like the bug came from there.

After the copper split, the ScrollingTricks code does this to set the high words of the bitplane addresses.

	pl = (ULONG)ScreenBitmap->Planes[0] +  planeaddx;

	wp = CopPLANE2_1H;	

	for(i = 0;i < BLOCKSDEPTH;i++)
	{
		wp[1] = (WORD)(pl >> 16);

		pl += BITMAPBYTESPERROW * BLOCKSDEPTH;
		wp += 2;
	}

It advances the bitplane pointer by BITMAPBYTESPERROW * BLOCKSDEPTH where BITMAPBYTESPERROW is BitmapWidth/8 and BLOCKSDEPTH is the number of bitplanes.

It should actually advance by BITMAPBYTESPERROW, because the bitmap is interleaved.

When the number of bitplanes is only 5, and the bitmap is allocated at certain addresses, the error does not show, as the high word of the calculation comes out correct, even when the rest of it is wrong.

As I upped the bitplanes to 8, and moved the bitmap pointer, the bug showed itself. Can't believe how long it took me to find it, but at least it is an easy fix!