English Amiga Board


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

 
 
Thread Tools
Old 25 April 2016, 11:02   #1
Herpes
... aka Amix73

Herpes's Avatar
 
Join Date: Jan 2009
Location: Austria
Posts: 87
Question Q: Copper Interrupt

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

Code:
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
Code:
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.
Attached Thumbnails
Click image for larger version

Name:	coper_int.png
Views:	238
Size:	38.1 KB
ID:	48260  

Last edited by Herpes; 25 April 2016 at 11:29. Reason: typo
Herpes is offline  
Old 25 April 2016, 12:59   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 25,035
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.
Toni Wilen is offline  
Old 25 April 2016, 13:14   #3
nocash
Registered User
 
Join Date: Feb 2016
Location: Town/Country
Posts: 32
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.
nocash is offline  
Old 25 April 2016, 13:31   #4
Herpes
... aka Amix73

Herpes's Avatar
 
Join Date: Jan 2009
Location: Austria
Posts: 87
Quote:
Originally Posted by Toni Wilen View Post
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

Last edited by Herpes; 25 April 2016 at 13:36. Reason: second answer post seen too late
Herpes 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
Combining copper scrolling with copper background phx Coders. Asm / Hardware 16 13 February 2021 12:41
Interrupt 7 BigT support.WinUAE 2 07 September 2013 22:25
Creating a 50/60Hz interrupt? oRBIT Coders. General 5 13 May 2010 21:13
level 7 interrupt on A600 xc8 Hardware mods 1 26 October 2008 14:53
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 02:20.


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