A.D.A. Amiga Demoscene Archive

Hi

I'm currently trying to change 16 AGA colours per scanline using the copper.. For each line, the copper does this :

dc.w $2cdf,$fffe ; wait for some scan line.. here the first one
dc.w $0106,(1<<5) ; set hi bits of colours active
dc.w $0180,col0hi
:
dc.w $.......,col15hi
dc.w $0106,(1<<5)|(1<<9) ; set lo bits active
dc.w $0180,col0lo
:
dc.w $.......,col15lo
Next scanline

And it proceeds like this for every scanline..

This worked OK on Alice Copper where I only had 2 bitplanes, but now I'm using 4 and I see some artifacts which looks as though the colours have not been set properly before a quarter of the horizontal width of the screen. I've tried waiting for different horizontal values of the scanline and this move the artifacts around a bit, but nothing works perfectly.

Has anyone made this before with any success?

Any other registers which affect this? Is the wait instruction bogus?

The wait instruction seems fine, but you have to keep in mind that the copper is pretty slow compared to the raster. 36 instructions take a while to execute, dunno exactly how much it works out to with 4 planes but with 8 planes, a copper instruction will take roughly 8 lowres pixels to execute, so that code snippet probably takes well over half a scanline to finish.

Any chance you could alternate between two sets of 16 colours? That'd give you a whole extra scanline to work with.

@doom Thanks for the reply.. Alternating between two sets of 16 colours should be possible. So then I should use 0..15 for even lines and change 16...31 in this line, then the other way around for the next line. Thanks. That should do the trick :)

Note that you might be able to do the "bank switching" per-line by setting BPLCON4 to 0x0000 on odd lines and 0x1000 on even lines, instead of adding a 5th bitplane with a striped pattern in it.

If the above works then you'll avoid incurring the extra DMA stalls that a 5th bitplane otherwise would cause.

But isn't the bank switching just for selecting "currently affected set of colours" ? Will it affect what colours are fetched? That would be very cool though. I'll give it a try of course.

I'm not referring to the BANK bits in BPLCON3; I mean the BPLAM bits in BPLCON4.

"This 8 bit field is XOR`ed with the 8 bit plane color address, thereby altering the color address sent to the color table"

I interpret that as the value stored in BPLCON4.BPLAM will be XORed against the pixel color value just before the pixel's RGB value is looked up in the palette.

wow. This is completely new to me. xor should do the trick. What do you think this functionality is designed for originally?

Probably for purposes like these. It is a generalization of the mechanism used when selecting "palette bank" for sprites.

rload: of course it is designed to be used for the tilting rotozoom from roots/sanity ;)

that aside, at least in no-aga machines, a copper-move eats 8 lowres pixels (cf. 8x2 rotozoom on nomorelies).

also another way to have more time per scanline is to start changing colors at the end of the visible part of each scanline, instead of waiting for the physical start of the next one.

Depending on how much other work you need to do, you can also change the colors with the CPU. The CPU can write to the hardware registers twice as fast as the copper, since it does not need the two chipram accesses per copper instruction for loading the address and value.

I used this trick for the texturing on the twister in Kunto. It changes 30 colors on each scanline (using a single MOVEM of 15 registers) completely outside the area covered by the effect.

Hmm, it seems Kunto isn't on ADA. That must surely be a mistake. :) The only ever ECS demo by Loonies, as far as I am aware.

Just for the record. The BPLAM + double buffered colour register stuff works. I guess many of you don't need to have this confirmed really, but if there are some other newschool amiga coders who dropped straight into the chunky age and never did much with HW, then now you know :)

I also tried modifying 32 aga cols per scanline, but the artefacts came back then. Didn't try anything in between. Maybe Blueberrys CPU trick is the thing here. How did you time the colour writes to a certain part of the scanline?

I guess you can poll the beam counter if your effect is scanline based and you have enough time per scanline.

The copper can create an interrupt somehow, so that could perhaps be used.

loady: under optimal circumstances the copper can do ~56 MOVEs per scanline. That means you can reload approximately 25 AGA color registers per scanline using the copper. So yes, you will need to use the CPU if you want to update more colors than that per scanline.

I wrote an example to test this and it worked pretty nice. Atleast in UAE standard A1200, can't say it runs fine on real hardware and all systems, but it serves as a demonstration.

Code is at coppertrix.s and customregisters.i

There is enough raster time to stretch the 64 color bitmap to 128 pixels for a 2x1 mode, though 128 colors 1x1 is probably not doable.

@zeroblue: can you supply customregisters.i aswell? It would be nice if anybody can compile this out of the box. It's always easier and more fun to study code when you can see the result (and experiment). Thanks

z5: i've uploaded a modified version of zeroblue's source that doesn't need any external files here