Driving blitter from copper

[ross]

Originally Posted by roondar

This sounds like it might be an excellent idea (doing Copper bars with CIA interrupts and blitting using just the Copper). You could even consider doing all the display setup per frame using the CPU.

This would essentially allow you to 'not care' about the Blitter in the main loop of the program, other than setting up the changes in what to blit per frame. And crucially, it would do that while still allowing most (all?) of the nifty 'Copper tricks' - albeit now via CPU so slower than normal due to interrupt overhead.

This is a bit overkill , but doable.
Remember that apart interrupt overhead/registers saving/chip access, you have the slow E clock to acknowledge and clear as source IRQ.
Too much CPU time wasted, if you do it a hundred times every frame...

There are some games that use CPU IRQs, called by Copper, to do some video magia and often a patch is needed on fast processor to not desync..
For ex. in Lionheart the Copper also setup different 'unused' bits to signal to CPU what it want.

[roondar]

Originally Posted by ross

Too much CPU time wasted, if you do it a hundred times every frame...

Indeed, that would be a bad idea

But then again, not many games use the Copper for hundreds of changes a frame. Most seem to use only a few dozen on the high end.

Originally Posted by ross

Don't overcomplicate things, the Copper can handle for itself quite complex flows.

The key is to detach blitter queue from normal copper flux.
How to do this? Some hints:
- remember that Copper pointers are buffered
- use Copper1 only for normal jobs (like video split and copper gradients)
- use Copper2 only for blitter queue
- BFD bit works also for SKIP instruction
Even if simple the Copper is a real co-processor and you can control the flow and make subroutines.

Only at the last blit you can call for a CPU aid (even a Copper IRQ suffice), then check where you are, switch buffer and start a new queue.
Your only concern is a frame rate drop if you do not complete the queue in one frame time.

It feels like this sort of approach is only really practical if you can limit the time spent in any given wait in the normal flux. Otherwise you'll spend a lot of time waiting when you should be kicking off the next blitter job.

Good if your normal flux is implementing a copper fade every scanline; bad if it's waiting to reset bitplane pointers on display memory wrap.

[ross]

Originally Posted by ebenupton

Good if your normal flux is implementing a copper fade every scanline

This is the main idea (or at least every few lines as it is the minimal blitting).

bad if it's waiting to reset bitplane pointers on display memory wrap.

I don't seem to have read anything about the bitplane reset on display memory wrap, which by the way only serves in vertical scroll case (or 8-way scroll), and in many cases can be avoided.
For every problem its solution

In this thread two problems have been mainly raised: manage the overcoming of the next vertical blank and manage a copper line gradient with the copper at the same time with blitter queue.

Originally Posted by ross

I don't seem to have read anything about the bitplane reset on display memory wrap, which by the way only serves in vertical scroll case (or 8-way scroll), and in many cases can be avoided.
For every problem its solution

Very true. It's just at the forefront of my mind as I know I'm going to have to implement it soon and it's a massive PITA to do properly

[Seiya]

Originally Posted by ebenupton

My goal has been to explore how much performance I can squeeze out of the baseline OCS/ECS hardware, compared to what I could do as a teenager back in the 1990s.

you are so talented developer. Nice game and, from video, great gameplay. this game remember me best successfull Amiga game. You could creat a great game

Originally Posted by Seiya

you are so talented developer. Nice game and, from video, great gameplay. this game remember me best successfull Amiga game. You could creat a great game

Thank you! This was a game that Nick and I wrote for cellphones back in 2004. It's fun to come back to my favourite platform and find a way to squeeze this title on there.

[ReadOnlyCat]

Originally Posted by ross

This is the main idea (or at least every few lines as it is the minimal blitting).

Hum, nifty (using the two copper lists for different tasks).
If I understand correctly, Copper1 waits on scanlines and changes colors then switches to Copper2 which waits on Blitter Finished but how do you make sure timings are right and that it will we finished before the next scanlines occur?

I suppose re-reading the HRM chapter on Copper instructions should give me the answer but from memory I fail to see how to manage the switch back to Copper1 in the absence of a blit finished?
Can Copper2 be made to switch back to Copper1 before the next scanline occurs even while it is waiting for the Blitter?

This seems interesting but I clearly lack some knowledge there.

In this thread two problems have been mainly raised: manage the overcoming of the next vertical blank and manage a copper line gradient with the copper at the same time with blitter queue.

Regarding the second one, I am hopeful this works but will be convinced only upon reading an example Copper list.
(and yes, I need to peruse the HRM again )

[ross]

Originally Posted by ReadOnlyCat

Hum, nifty (using the two copper lists for different tasks).
If I understand correctly, Copper1 waits on scanlines and changes colors then switches to Copper2 which waits on Blitter Finished but how do you make sure timings are right and that it will we finished before the next scanlines occur?

More the opposite and here lies the key.
In each line (or every how many I consider appropriate or useful) I have a point where I could set the blitter's registers, but only if the blitter is free.
Then in a few cycles I setup and launch the operation, then return to my original copper list.
In this way I have a flow for the blitter almost continuous.
To make this I use in an advanced way the SKIP instruction and the two copper's pointers.

I suppose re-reading the HRM chapter on Copper instructions should give me the answer but from memory I fail to see how to manage the switch back to Copper1 in the absence of a blit finished?
Can Copper2 be made to switch back to Copper1 before the next scanline occurs even while it is waiting for the Blitter?

I think that this approach is pretty novel and peculiar.
And yes Copper2 can switch back to Copper1, like in a subroutine, and is what I do
Of course it is not a panacea that can work in all cases...

Regarding the second one, I am hopeful this works but will be convinced only upon reading an example Copper list.
(and yes, I need to peruse the HRM again )

In http://eab.abime.net/showpost.php?p=...5&postcount=19 there is all you need, even a practical example.
I put it specifically because the concept wouldn't have been so easy to understand.

Usually in my small intros I always try to exploit Copper in an unusual way.
Often the same thing could be done in much more banal (but slow) ways, but programming on Amiga means being creative.

Well, have fun with copper in advanced mode.

[deimos]

I'm trying to create a blitter queue copper list right now, based on what I've read in this thread. I'm struggling a bit, particularly with creating a split screen while still blitting, and with updating to point to a new blitter list when the next set of calculations are done. Could you guys please look over the following bit of pseudo code and tell me whether you think I've understood, or if there's anything in there that's going to balls it up?

Thanks.

main() {
    front = 0
    back = 1
    flipping = 2

    next_blitter_queue = NULL;

    update copper list to point to front

    set COP1LC to start
    set COP2LC to end
    screen_availble <- FALSE
    blitter_active <-FALSE

    for (;;)
        draw_screen();
}

draw_screen() {
    next_blitter_queue = all_the_calculations();
    if (!blitter_active) {
        blitter_active <- true
        COP2LC <- next_blitter_queue
        next_blitter_queue <- NULL
        hit COP2JMP
    }
}

VBLANK {
    set COP1LC to start

    if screen_available {
        swap front and flipping
        update copper list to point to new front
        screen available <- FALSE
    }
}

COPER {
    swap back and flipping
    screen_available <- TRUE
    if (next_blitter_queue) {
        COP2LC <- next_blitter_queue
        next_blitter_queue <- NULL
        hit COP2JMP
    } else
        blitter_active <- FALSE
}



// upper copper list

// set up primary display
start:
    wait for top
    set up upper screen

    set COP1LC to upper_loop
upper_loop:
    wait for blitter
    skip if near middle
    jump to COP2LC
    // fall through to middle



// lower copper list

// set up instrument panel
middle:
    wait for middle
    set up lower screen

    set COP1LC to lower_loop
lower_loop:
    wait for blitter
    skip if near bottom
    jump to COP2LC
    // fall through to end



// too close to bottom of screen to risk starting a blit
end:
    sleep



blit_done:
    set COP2LC to end
    trigger COPER
    sleep




// a blitter queue copper list

blit0:
    set COP2LC to blit1
    set up blitter
    finish with BLTSIZE
    jump to COP1LC

blit1:
    set COP2LC to blit2
    set up blitter
    finish with BLTSIZE
    jump to COP1LC

blit2:
    set COP2LC to blitn
    set up blitter
    finish with BLTSIZE
    jump to COP1LC

...

blitn:
    set COP2LC to blit_done
    set up blitter
    finish with BLTSIZE
    jump to COP1LC

[dissident]

Originally Posted by ross

Don't overcomplicate things, the Copper can handle for itself quite complex flows.

The key is to detach blitter queue from normal copper flux.
How to do this? Some hints:
- remember that Copper pointers are buffered
- use Copper1 only for normal jobs (like video split and copper gradients)
- use Copper2 only for blitter queue
- BFD bit works also for SKIP instruction
Even if simple the Copper is a real co-processor and you can control the flow and make subroutines.

Only at the last blit you can call for a CPU aid (even a Copper IRQ suffice), then check where you are, switch buffer and start a new queue.
Your only concern is a frame rate drop if you do not complete the queue in one frame time.

Practical snippet:

    lea    copper,a0
    move.l    a0,$dff080
    lea    blitter_queue,a0
    move.l    a0,$dff084
        ....
    

copper
    dc.w    $0082,§1
    dc.l    $8001ff00
    dc.l    $ffff0001    ;if (blitter busy)*
    dc.l    $00880000    ; JMP to §1 (normal flux)
    dc.l    $008a0000    ;else JSR to next blit on queue 

§1    dc.l    $01800fff
    dc.w    $0082,§2
    dc.l    $8101ff00
    dc.l    $ffff0001
    dc.l    $00880000
    dc.l    $008a0000

§2    dc.l    $01800888
    dc.w    $0082,§3
    ....
    ....

$138    dc.w    $0082,copper
    dc.l    $fffffffe 


blitter_queue
    dc.w    $0086,~1    ;setup next subroutine
    dc.l    $00540003    ;setup blitter
    dc.l    $00560000
    ....
    dc.w    $0058,start0    ;start blitter
    dc.l    $00880000    ;RTS
    
~1    dc.w    $0086,~2
    dc.l    $00540003
    dc.l    $00568000
    ....
    dc.w    $0058,start1
    dc.l    $00880000

~2    dc.w    $0086,~3
    ....


*Why $FFFF? So I can recognize immediately a SKIP point on copper list :)

Cheers

Wow, I know much about driving the blitter from the copper, but this idea using subroutines within the copperlist is really excellent!