Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: The Copper / HW level programming.
Message-ID: <6386@amiga.UUCP>
Date: 19 Feb 91 17:50:16 GMT
References: <1991Feb11.162007.7750@vax1.tcd.ie>
Organization: I and I Computing, Palo Alto, CA
Lines: 81

In article <1991Feb11.162007.7750@vax1.tcd.ie> smcgerty@vax1.tcd.ie writes:
)I'm starting to program the Amiga at the Hardware level, (with a lot of help
)from the Amiga hardware Ref. Manual) and I'm currently learning about the
)Copper:
)
)First a hint I picked up that isn't in the HW Ref. Manual:
)
)It states that "The COP1LC reg is written at the end of the vertical blanking
)period by a graphics interrupt handler.."

More like COP1JMP ... The copper is restarted from the value found in
COP1LOC, but if you have something in there, it won't be displaced.

)ie: The system imposes its own Copper list while the interrupts are on.
)Since turning off the interrupts is not the done thing, its better just to
)redirect this to your own Copper List.

No, interrupts on or off, the copper restarts from COP1LOC.  However,
graphics' vblank interrupt will stuff something into COP2LOC during vblank,
and the copper "header" list which remains constantly in COP1LOC does
a jump to COP2LOC (writes COP2JMP) after line 12 or 20 or something like
that.

)The interrupt looks at GfxBase->LOFList (offset 50 from GfxBase) and puts what
)is held there into COP1LC during the vertical blanking interval.

COP2LOC.

)To redirect it to your own list:
)
)	MOVE.L 	50(A6),OldCopper    ;a6=GfxBase.
)	MOVE.L	MyCopper,50(A6)
)	...
)and to restore it later
)
)	MOVE.L	OldCopper,50(A6)

Well, that might be one way ... as long as nobody does a LoadView().
Try pressing amiga-M/N ...

)Now a question:
)
)Does anyone know how long a Copper MOVE instruction takes?
)I'm curious to know how many CMOVEs I can do in one scan line...

Very easy to see.  Just put a mess of MOVE red,color0 MOVE blue,color0
in a row, and you will see exactly how long, in pixels, it takes to
execute the MOVE.  There is a program on a devcon disk I wrote which
does this, as well as a few other demos/tricks, but using the user
copper list, which doesn't turn out to be a very useful thing.


)Assuming the CWAIT finishes when the raster hits the point it specifies, will a
)CMOVE straight after it effect that position/pixel, or will it be too late? 
)(I imagine it can. Even if it can't, it doesn't really matter, as it will
)occure at every position, and everything will be 1 or 2 out.) I'd just like to
)know what I can do in what width of screen........

It will be several pixels later.  You'll have to experiment.  There are
many weird variables, the most profound of which is overscan.  For example,
if you were thinking of doing dynamic ham (hires with color register
jamming), you will probably get screwed come overscan time.

In fact the answer to you first question, "how many CMOVE's per line"
in 4 bitplanes of hires is ZERO -- all copper processing gets kicked out
into the horizontal retrace, and I don't know how many instructions can be
executed during that period.


)I'd be interested to hear from anyone doing any HW level programming at all.
)Its quite interesting (makes a change from C & good'ol intuition..!)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Tell me about it.

	jimm

-- 
--- opinions expressed herein are my own. ---
"... Because they can."
		- profound punchline to joke about dogs