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.hardware
Subject: Re: Using the copper (was Re: 3d Graphics)
Keywords: copper lists
Message-ID: <2069@pdxgate.UUCP>
Date: 25 Mar 91 19:39:35 GMT
References: <12305@monu1.cc.monash.oz> <7183@harrier.ukc.ac.uk>
Sender: news@pdxgate.UUCP
Lines: 49

mr3@ukc.ac.uk (M.Rizzo) writes:

>Other than having two copper lists for double buffering, as
>shown in the RKM Libraries & Devices (Yep I'm still using the
>old ones :-), and changing the colour palette in the middle of scan
>lines for nice demos :-), I can't see much point in messing around with
>copper lists. I can't understand what people do with copper
>lists in programs such as Stuart's. Help please !

Well, although my coding has been centering towards visual effects such as
those achieved in European demos, I think the general techniques available in
the copper lists are fundamental to a lot of things. Having two viewports
with different resolutions wouldn't be possible without the copper (or it
would involve a lot of work on the processor side). Remember, the copper
allows you to change any of the custom registers. This means you can change
colors, but it also means you can even start blitter moves, adjust scroll
pointers, change the screen depth and resolution, start audio DMA, etc. You
can also have it generate a specific interrupt. What it really means, then,
is that you can use the copper to time any event that you need to happen
somewhere on the order of a 60th (or 50th) of a second. Primarily, however,
this is for video. Arguably, the most common direct use of the copper will
remain in demos and games.
   However, a good example of other use might be something like an oversized
scrolling workbench screen. Rather than worrying about adjusting pointers and
the scrolling modulos every time there is a VBLANK interrupt, it is much
easier to keep pointers into the copper list and then modify the copper list
entries directly. (Note, potentially the copper could be reading instructions
between where you are changing them so this isn't always a very good idea)
What you could do in a situation like that is maintain two copper lists. Each
one is initially set to jump back to the beginning of itself. You modify the
one that isn't being used and then set its address to point to the other
copper list and vice versa. (Essentially double buffering the copper lists)
Anyways, the copper is a very powerful tool and should not be overlooked. It's
one of the best pieces of hardware on the Amiga, right up there with the
blitter and the audio, so it shouldn't be discarded as worthless just yet. I
still wish that instead of 32 palette registers we had a pointer to a
palette and that the resolution of the copper was one hires pixel, but you
can't have everything. (Just imagine beinge able to have windows that
themselves have different palettes, and imagine all that on the fly, like a
workbench where each window has whatever 16 colors it wants) (oh, and I don't
care if the palettes have to be stored in chip memory either, and yes, I know
it means you'd have to be able to fetch up to 32 words of data within the
resolution of a single pixel, after all this is just a wish, isn't it?)

>Michael Rizzo

| Shawn L. Baird                        | Or via US Snail:                  |
| bairds@eecs.ee.pdx.edu                | 17650 SE Cason Rd.                |
| ...uunet!tektronix!psueea!eecs!bairds | Gladstone, OR  97027              |