Blitting with the copper
 

I've never used to copper to drive the blitter previously, but thought I'd give it a try.

Set up double-buffered screens with two copperlists. Each copperlist includes a branch to a table with blitter (and other) instructions. No other blitting is going on.

Using $180 changes, I can see that the branch happens. The main copperlist branches to the "subroutine" and turns the background red. Then it is supposed to do some blitting and turn the background green. This never happens. If I remove the blitter-related MOVEs, and replace them with some Vanilla copper instructions ($180, copper NOP, other modulo etc) the subroutine completes and turns the screen green. If I include blitter-related moves, the things stops.

I must doing something terribly wrong here. Now, I am wondering what on earth can cause this behavior. I've only used one blit (one write to BLTSIZE), made sure there is no other blitting going on, and DMA is on. For good measure I have also included copper blitwaits (dc.l $00010000) before and after the blitter instruction group). Same result: copper instructions do not execute.

Any ideas?

There's the COPCON/CDANG register that you need to set first else copper ignore blitter registers. It's by design

http://amigadev.elowar.com/read/ADCD.../node0029.html

Holy macaroni! It was that easy. I guess I should RTFM next time I try to move outside of my competence area. Will try this tonight.

And THANKS to you for letting me know!

Now I added a MOVE $002e,$0002 to my copperlist, but the copper still seems to stop at the first blitter operation. Does it have to be set at a specific time (before enabling copper DMA or something like this)? I looked at the HRM but could not find anything about this.

Posting your code will make it easier for people to help.

You have to enable it using the CPU. If CDANG isn't enabled any write by the copper to registers below $80 will halt the copper until the next frame. Note that the OS relies (unintentionally) on this behavior so you should make sure to disable CDANG before returning to the OS. It's documented here (though the $40 limit only applies to OCS).

Because that register is protected from copper writes as well. Poke it with the CPU once at the start, and restore back to 0 at the end before your program exits.

edit: paraj beat me thanks to time zone difference of 0 ;P.

This is the page with the relevant address range info:
http://amigadev.elowar.com/read/ADCD.../node0052.html

This page would seem to be incorrect, it says the range is under $20?
http://amigadev.elowar.com/read/ADCD.../node004A.html

HRM pg. 26 (control register).
Here's the elowar link: http://amigadev.elowar.com/read/ADCD.../node0052.html

Basically, imagine an entity that dictates what it can do and then saying it can do whatever it wants. Wait.... we do have that: it's called the govermnent :P.

ECS works differently, so that's probably the reason why.

I don't have an ECS machine wired up to test, but for sure writing to any custom register works with AGA once CDANG is enabled. There's not much use in writing to the read only registers of course, but it doesn't halt the copper. In particular this:
will show a green screen on an A1200.

The documentation writer was probably trying to be describe what you can/should rely on, not what's actually possible. For ECS+ it was intended that you could use the copper to update registers in the $20-$40 range, but it just happens that the hardware doesn't disallow writes to $0-$20.

OCS: <$40 is always unavailable. CDANG enables $40-$7e.
ECS/AGA: CDANG enables $00-$7e