Q: Copper Interrupt

[Herpes]

Hi #?#!

I recently wanted to use copper interrupts to change color of raster beam with the cpu - not for a real purpose but just to try out. I thought with a copper interrupt it would be possible to trigger the interrupt always in sync with the raster position.

- only allow COPER interrupts (no BLIT or VERTBL):
- only allow Copper DMA - nothing else needed

move.w	#$c010,$9a(a6)	; intena-wr SET:INTEN--|----|---COPER|----
move.w	#$8280,$96(a6)	; dmacon-wr SET---|--DMAEN-|COPEN---|----

- most simple level3 handling routine - sure that it can only be COPER:

.newlvl3
	movem.l	d0-a6,-(a7) 	; save all regs
.copper
	; ---
	; just a simple color marker
	; to see if raster is stable
	; ---
	move.w	#$0f00,$dff180
	move.w	#$0000,$dff180
	moveq	#$0010,d0	; off COPER
.exitlvl3
	move.w	d0,$dff09c	; intreq (write)
	movem.l	(a7)+,d0-a6	; restore all regs
	rte

- very simple copper list containing the part where I trigger COPER int.

copper:
	; ....
	dc.w	$0180,$000
	; just a marker to know where the 
	; COPER int triggering takes place
	; on the raster line below
	dc.b	149,55,$ff,$fe
	dc.w	$180,$0f0f
	dc.w	$180,$0000
	; voodoo with these waits
	; it gets more stable
	dc.b	150,51,$ff,$fe
	dc.b	150,53,$ff,$fe
	dc.b	150,55,$ff,$fe
	; trigger the COPER int
	dc.w	$09c,$8010

	; rest which is of no interest
	; ...
	; end the clist
	dc.w	$ffff,$fffe
	dc.w	$ffff,$fffe

I noticed some oddities: In the copper list when I wait consecutively the triggering of the interrupt - or lets say the handling gets more stable.
BUT it is not stable - meaning that the raster is colored red (int routine) shifted either 4 pixels left or right. When handling other lev3 interrupts (VERTBL, BLIT) the instability gets worse.

I made 3 screen shots and combined them and inserted white vertical markers that you can see where the COPER int routine is executed. Note that the red markers are manually stacked just to emphasize the shift. In reality the markers are on the same line.

So the purple marker is to see where on the vertical position one line below the COPER interrupt is triggered by the copper. One notices quite a time until the routine is actually executed (1.5 rasters maybe), which of course makes sense (interrupt handling costs time). The interrupt routine itself does nothing but coloring the beam to red and immediately to black again - of course using a faster CPU would make the marker smaller - anyway here an A500 is used (in emulation AND in real which makes no difference).

Sorry for the long setup words - here are my question:
WHY is the handling of the COPER int not stable? The routine ist as simple as it gets. I notices that if code is executed in the CPU loop waiting for left mouse button this also changes the stability for worse.

1. Is this because the interrupt is not always triggered at the same time OR
2. is it because the CPU loop it not really in sync because of polling the the position?
3. Is it at all possible to be 'exact' - meaning no shift of the red marker occurs, so the COPER int routine is ALWAYS totally in sync with the beam?
4. What am I doing wrong (it's very likely I am ;-)

- simple 'empty' main loop

mainloop:
	move.l	$dff004,d0
	and.l		#$1ff00,d0
	cmp.l		#80<<8,d0
	bne.b		mainloop
	btst		#6,$bfe001		; lmb pressed?
	bne.w	mainloop
	rts

Thank you very much in advance for noob enlightenment.

[Toni Wilen]

Quick and short answer: CPU needs to finish currently executing instruction before interrupt exception can start. This adds extra "random" cycles to interrupt start up. It will become even more worse if there are DMA channels active, stealing time from the CPU.

[nocash]

The CPU will first need to finish executing the current opcode (in your mainloop) before it can execute the interrupt, so there will be some random delay (depending on how soon the CPU will finish the current opcode).
You could try to insert a STOP opcode in your mainloop, that should wait for interrupt, and hopefully suspend waiting at the exact time when the interrupt occurs. STOP is a privileged instruction (can't be used in user mode).
And, it will stop the CPU so you can't execute any other useful code, unless you do something like firing two interrupts shortly after each other (the first one just as notification that the CPU shall enter STOP state).
Anyways, as you said, results won't be stable on faster CPUs and memory caches, so it might be better to avoid using such stuff in real-life.

[Herpes]

Originally Posted by Toni Wilen

Quick and short answer: CPU needs to finish currently executing instruction before interrupt exception can start. This adds extra "random" cycles to interrupt start up. It will become even more worse if there are DMA channels active, stealing time from the CPU.

Ah, thanks Toni and nocash - that makes perfectly sense.

@nocash: ...real-life: hehe, that's a good one