Blitting from main loop and level 3 interrupt (copper)

[nandius_c]

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.

[roondar]

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:

; 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.

[nandius_c]

Originally Posted by roondar

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:

; 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?

[roondar]

Originally Posted by nandius_c

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.

[nandius_c]

Originally Posted by roondar

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!

[Galahad/FLT]

Originally Posted by nandius_c

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?

[nandius_c]

Originally Posted by Galahad/FLT

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.

[roondar]

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

[nandius_c]

Originally Posted by roondar

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 .

[deimos]

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.