Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!pdxgate!eecs!bairds From: bairds@eecs.cs.pdx.edu (Shawn L. Baird) Newsgroups: comp.sys.amiga.programmer Subject: Re: The Copper / HW level programming. Keywords: Copper Move Message-ID: <1686@pdxgate.UUCP> Date: 19 Feb 91 22:07:30 GMT References: <1991Feb11.162007.7750@vax1.tcd.ie> <1991Feb19.194313.29117@daffy.cs.wisc.edu> Sender: news@pdxgate.UUCP Lines: 65 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 |