smcgerty@vax1.tcd.ie (02/12/91)
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.." 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. The interrupt looks at GfxBase->LOFList (offset 50 from GfxBase) and puts what is held there into COP1LC during the vertical blanking interval. 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) 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... 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........ 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..!) Thanks in advance. ---------------------------------------------------------------------------- | / T | / Stephen John McGerty | Amiga // | | / | |/ smcgerty@vax1.tcd.ie (C.Sci.) | "Hmm.. No, nothing." \\// | |__________________________________________|_______________________________|
jimm@amiga.UUCP (Jim Mackraz) (02/20/91)
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 dogspochron@cat53.cs.wisc.edu (David Pochron) (02/20/91)
In article <1991Feb11.162007.7750@vax1.tcd.ie> smcgerty@vax1.tcd.ie writes: >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... Well, I vaguely recall that you only have time to change 16 color registers in one scan line... >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? Good question. I have played around witht hardware out of curiosity and found the WAIT instruction to be extremely accurate as to when the next instruction would take effect - like programming a Copper list to change the screen color 2/3s the way across the screen. The change is perfectly vertical so either the MOVE instr. fetch/execute time is right on the mark each time, or the Copper pre-loads the next instruction after a WAIT so it can make the change at the exact pixel. (More likely) The closest I have been able to get a color change to occur on a single scanline has been 16 pixels apart, by just doing two MOVE's one after the other. I guess you could say it take 1 bitplane DMA word for an instruction to execute, but this is just guessing on my part. >---------------------------------------------------------------------------- >| / T | / Stephen John McGerty | Amiga // | >| / | |/ smcgerty@vax1.tcd.ie (C.Sci.) | "Hmm.. No, nothing." \\// | >|__________________________________________|_______________________________| -- -- David M. Pochron | "Life's a blit, | and then you VBI." pochron@garfield.cs.wisc.edu |
kskelm@happy.colorado.edu (02/20/91)
In article <1991Feb11.162007.7750@vax1.tcd.ie>, smcgerty@vax1.tcd.ie writes: > The interrupt looks at GfxBase->LOFList (offset 50 from GfxBase) and puts what > is held there into COP1LC during the vertical blanking interval. In my experience, WRONG. If you write an address into cop1lc and then reference copjmp1, your copper list WILL supersede the normal OS, and will continue to do so until you load the system's value back in (gfxbase->copinit, I think). > 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... If you form a copper list that reads WAIT 0,0 /* wait for line 0, column 0 */ MOVE color0, 0xFFF /* set background color to brite white */ MOVE color0, 0x000 /* set background color to black */ ... you will get a white bar 8 lores pixels wide, followed by blackness. Enjoy, Kevin Kelm
bairds@eecs.cs.pdx.edu (Shawn L. Baird) (02/20/91)
pochron@cat53.cs.wisc.edu (David Pochron) writes: >In article <1991Feb11.162007.7750@vax1.tcd.ie> smcgerty@vax1.tcd.ie writes: >>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... >Well, I vaguely recall that you only have time to change 16 color registers >in one scan line... Actually, if you're thinking of SHAM, for example, that's 15 color registers during the horizontal blank, so that none of the color changes are visible. I'm not sure if you can fit more than this or not. You should be able to perform at least one copper move every four pixels, which is the horizontal resolution limit of the copper wait. >>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? >Good question. I have played around witht hardware out of curiosity and >found the WAIT instruction to be extremely accurate as to when the next >instruction would take effect - like programming a Copper list to change the >screen color 2/3s the way across the screen. The change is perfectly vertical >so either the MOVE instr. fetch/execute time is right on the mark each time, >or the Copper pre-loads the next instruction after a WAIT so it can make the >change at the exact pixel. (More likely) Exact up to the four pixel resolution limit I mentioned above. For example, you should be able to have two "windows" in which a single palette color changes aligned on a four pixel boundary. However, more than one move and you might notice some problems. I don't know, since I haven't tried it. Sometimes I wonder if it wouldn't have been possible to have a register pointer to a color map in chip memory rather than having the color map in registers. Imagine being able to change the entire palette in a singal instruction, making multiple color map windows a distinct possibility. (assuming the color palettes were pre-computed) BTW: That's four low resolution pixels, eight high resolution pixels. >The closest I have been able to get a color change to occur on a single >scanline has been 16 pixels apart, by just doing two MOVE's one after the >other. I guess you could say it take 1 bitplane DMA word for an instruction >to execute, but this is just guessing on my part. I have done eight pixels apart on a single scanline (low-resolution), but I could've sworn I've seen a color changed within four pixels. I suppose it could have been two colors presenting that illusion. Assuming eight pixels apart in low resolution that means 40 copper moves. >>---------------------------------------------------------------------------- >>| / T | / Stephen John McGerty | Amiga // | >>| / | |/ smcgerty@vax1.tcd.ie (C.Sci.) | "Hmm.. No, nothing." \\// | >>|__________________________________________|_______________________________| >-- > -- David M. Pochron | "Life's a blit, > | and then you VBI." >pochron@garfield.cs.wisc.edu | -- | Shawn L. Baird | Or via US Snail: | | bairds@eecs.ee.pdx.edu | 17650 SE Cason Rd. | | ...uunet!tektronix!psueea!eecs!bairds | Gladstone, OR 97027 |
bartonr@eecs.cs.pdx.edu (RTFM) (02/21/91)
In article <1991Feb11.162007.7750@vax1.tcd.ie>, smcgerty@vax1.tcd.ie writes: > The interrupt looks at GfxBase->LOFList (offset 50 from GfxBase) and puts what > is held there into COP1LC during the vertical blanking interval. The copper list chosen (LoFList or ShFList) also depends on whether you are using interlace and whether the long frame bit of custom.VPOSR is set. ================================================================================