English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 08 April 2019, 17:17   #21
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,241
Quote:
Originally Posted by roondar View Post
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.
ross is offline  
Old 08 April 2019, 17:31   #22
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,388
Quote:
Originally Posted by ross View Post
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.
roondar is offline  
Old 09 April 2019, 00:17   #23
ebenupton
 
Posts: n/a
Quote:
Originally Posted by ross View Post
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.
 
Old 09 April 2019, 01:00   #24
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,241
Quote:
Originally Posted by ebenupton View Post
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).

Quote:
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.
ross is offline  
Old 09 April 2019, 01:40   #25
ebenupton
 
Posts: n/a
Quote:
Originally Posted by ross View Post
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
 
Old 09 April 2019, 14:04   #26
Seiya
Registered User

Seiya's Avatar
 
Join Date: Nov 2014
Location: Italy
Posts: 981
Quote:
Originally Posted by ebenupton View Post

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
Seiya is offline  
Old 09 April 2019, 18:46   #27
ebenupton
 
Posts: n/a
Quote:
Originally Posted by Seiya View Post
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.
 
Old 06 June 2019, 04:21   #28
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 48
Posts: 1,143
Quote:
Originally Posted by ross View Post
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.

Quote:
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 )
ReadOnlyCat is offline  
Old 06 June 2019, 11:43   #29
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,241
Quote:
Originally Posted by ReadOnlyCat View Post
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.

Quote:
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...

Quote:
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.
ross is offline  
Old 21 October 2019, 15:41   #30
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 491
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.

Code:
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
deimos is offline  
Old 21 October 2019, 19:36   #31
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 224
Quote:
Originally Posted by ross View Post
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:
Code:
    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!
dissident is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Best way to mix blitting with copper and copper effects roondar Coders. Asm / Hardware 3 12 September 2016 14:12
Blitter busy flag with blitter DMA off? NorthWay Coders. Asm / Hardware 9 23 February 2014 22:05
Avoiding copper strobe/blitter bug mc6809e Coders. Asm / Hardware 31 28 November 2013 09:09
Combining copper scrolling with copper background phx Coders. Asm / Hardware 14 16 June 2013 08:26
Blitter using the copper... h0ffman Coders. Asm / Hardware 9 23 February 2012 09:25

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07543 seconds with 16 queries