English Amiga Board


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

 
 
Thread Tools
Old 07 February 2020, 13:47   #1
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 91
Blitting from main loop and level 3 interrupt (copper)

Hi there! I've got a test where one part of the code is run from the main loop and the other part is run from a copper interrupt (fired at the last line of the visible area). Blits are started from both parts (main loop and copper interrupt). The only interrupts enabled are COPPER and PORTS.



It seems as if waiting for the blitter from the copper interrupt handler is not working: glitches appear in the playfield as soon as I change blitter registers from there, even if I don't fire up the blit. If I take those blits out of the copper interrupt and into the main loop everything works fine.


Any help would be appreciated.
nandius_c is offline  
Old 07 February 2020, 14:25   #2
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,717
If the main loop can blit "at any time" and the Copper interrupt can do so as well, glitches may well start to happen even with Blitter waits.

Consider the following:
Code:
; Part of "main loop"
bsr BlitWait
move.w #val,someblitter_reg(a6)
move.l #val,someblitter_reg2(a6)
==> Copper interrupt occurs and starts blit
==> Interrupt ends, execution resumes
move.l #val,someblitter_reg3(a6) ; uh-oh
move.w #blitsize,bltsize(a6)
The easiest way to avoid this is to only blit in one of the two. If you want to use the CPU to start blits and want both the loop and the interrupt to do blits, some sort of synchronisation between the two is probably needed. A semaphore style system might work.

Last edited by roondar; 07 February 2020 at 14:30.
roondar is offline  
Old 07 February 2020, 14:36   #3
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 91
Quote:
Originally Posted by roondar View Post
If the main loop can blit "at any time" and the Copper interrupt can do so as well, glitches may well start to happen even with Blitter waits.

Consider the following:
Code:
; Part of "main loop"
bsr BlitWait
move.w #val,someblitter_reg(a6)
move.l #val,someblitter_reg2(a6)
==> Copper interrupt occurs and starts blit
==> Interrupt ends, execution resumes
move.l #val,someblitter_reg3(a6) ; uh-oh
move.w #blitsize,bltsize(a6)
The easiest way to avoid this is to only blit in one of the two. If you want to use the CPU to start blits and want both the loop and the interrupt to do blits, some sort of synchronisation between the two is probably needed. A semaphore style system might work.

Thanks for the answer! Yes, I know that's exactly what's hapenning but... why? A blit from the main loop is running. Before it ends, the copper interrupt is fired up. When it tries to start its first blit: shouldn't it wait until the blit from the main loop ends?
nandius_c is offline  
Old 07 February 2020, 14:46   #4
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,717
Quote:
Originally Posted by nandius_c View Post
Thanks for the answer! Yes, I know that's exactly what's hapenning but... why? A blit from the main loop is running. Before it ends, the copper interrupt is fired up. When it tries to start its first blit: shouldn't it wait until the blit from the main loop ends?
My example isn't about a blit that is already running, but about a blit that is being set up to run when the code doing this is interrupted midway through setting the registers.

This is a small, but crucial difference as waiting on the Blitter does nothing if it's not running already

Edit: I am assuming both your main loop and copper interrupts first wait on the Blitter before setting new values to Blitter registers. If you don't do that you'll also get glitches. But that is different from what I'm describing above.

Last edited by roondar; 07 February 2020 at 14:58. Reason: Rewrote the first sentence to hopefully be clearer
roondar is offline  
Old 07 February 2020, 15:08   #5
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 91
Quote:
Originally Posted by roondar View Post
My example isn't about a blit that is already running, but about a blit that is being set up to run when the code doing this is interrupted midway through setting the registers.

This is a small, but crucial difference as waiting on the Blitter does nothing if it's not running already

Edit: I am assuming both your main loop and copper interrupts first wait on the Blitter before setting new values to Blitter registers. If you don't do that you'll also get glitches. But that is different from what I'm describing above.

OK! That makes sense... I was so focused on guessing why blitter wait was not working that didn't even think about the set up process xD. Sorry I misunderstood your example . Thanks!
nandius_c is offline  
Old 07 February 2020, 16:00   #6
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,506
Quote:
Originally Posted by nandius_c View Post
OK! That makes sense... I was so focused on guessing why blitter wait was not working that didn't even think about the set up process xD. Sorry I misunderstood your example . Thanks!
I take it you have a blit wait at the start of all your blitter routines?

And that the blit wait comes before you start poking any blitter registers?
Galahad/FLT is offline  
Old 07 February 2020, 16:11   #7
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 91
Quote:
Originally Posted by Galahad/FLT View Post
I take it you have a blit wait at the start of all your blitter routines?

And that the blit wait comes before you start poking any blitter registers?

Yes! As roondar said, the problem happens when the copper interrupt fires up when the main loop has started setting up blitter registers but the blit hasn't been started yet. I don't see how it could be fixed with a semaphore style system, so I guess I'll have to blit always from the main loop or from the copper interrupt.
nandius_c is offline  
Old 07 February 2020, 16:55   #8
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,717
It doesn't help I used the wrong term. I meant a basic locking system, semaphores are better suited for objects that need many locks - which is not the case here.

Anyway, I thought about it some more and have to agree. It's not easy to make your idea of Blitting with both loops work. Main issue is not the locking itself (which can be fixed relatively easily by strategically disabling/enabling the Copper interrupt), but rather that the Copper interrupt can't easily wait on the Main loop to be done setting up Blitter registers.

The way I see it, you have three options:
1) Blit from only the Copper interrupt or the main loop, not both.
2) Use Blitter interrupts instead and use the Copper interrupt/main loop merely to queue blits.
3) Check if the main loop has a lock (using a locking system like I mentioned) at the start of the Copper interrupt and if so, reschedule the Copper interrupt somewhat later down the screen and exit. This also requires the main loop to relinquish locks after actually starting blits.

The 1st is easiest by far, the 2nd will work as well but is very different from what you have now and the 3rd, while probably working, is not exactly "neat".

Perhaps there are other options though, I'm only giving my thoughts here and may have missed something
roondar is offline  
Old 07 February 2020, 18:14   #9
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 91
Quote:
Originally Posted by roondar View Post
It doesn't help I used the wrong term. I meant a basic locking system, semaphores are better suited for objects that need many locks - which is not the case here.

Anyway, I thought about it some more and have to agree. It's not easy to make your idea of Blitting with both loops work. Main issue is not the locking itself (which can be fixed relatively easily by strategically disabling/enabling the Copper interrupt), but rather that the Copper interrupt can't easily wait on the Main loop to be done setting up Blitter registers.

The way I see it, you have three options:
1) Blit from only the Copper interrupt or the main loop, not both.
2) Use Blitter interrupts instead and use the Copper interrupt/main loop merely to queue blits.
3) Check if the main loop has a lock (using a locking system like I mentioned) at the start of the Copper interrupt and if so, reschedule the Copper interrupt somewhat later down the screen and exit. This also requires the main loop to relinquish locks after actually starting blits.

The 1st is easiest by far, the 2nd will work as well but is very different from what you have now and the 3rd, while probably working, is not exactly "neat".

Perhaps there are other options though, I'm only giving my thoughts here and may have missed something

I'm already working on the first option. Thanks a lot for the detailed explanations .
nandius_c is offline  
Old 07 February 2020, 19:15   #10
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 545
From my experiences a few months ago, I'd say don't.

But if you do, then it's not hard to build a "linked list" of copper instructions to do your blitting, where the links are COPJMP2 instructions. You don't use blitter interrupts, and just use copper interrupts when you get to the end of a list.

The hardest bit is triggering the queue. There's no easy place that I could find - I ended up using the vblank interrupt to restart blitting in odd occasion that I couldn't keep feeding the copper new blitter queues.
deimos 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 13:12
Q: Copper Interrupt Herpes Coders. Asm / Hardware 3 25 April 2016 13:31
Copper loop confusions Fell Coders. Asm / Hardware 15 21 September 2015 21:02
How to load data and keep your main loop running? alkis Coders. Asm / Hardware 12 09 September 2013 20:13
Level 7 interrupt Kintaro support.WinUAE 1 21 January 2004 17:31

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 09:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07351 seconds with 15 queries