mr3@ukc.ac.uk (M.Rizzo) (03/25/91)
In article <12305@monu1.cc.monash.oz> int131d@monu3.cc.monash.edu.au (mr s.d. twyford) writes: > Then improve it by ... > ...generating your own copper lists for the screen display. Why do you do this and what exactly do you put in your copper lists ? Can you or anyone else give me a few examples of what can be gained by generating one's own copper lists please ? 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 ! > Stuart Twyford Michael Rizzo Mike The Maltese Amigan Yes we've got Amigas in Malta too !
bairds@eecs.cs.pdx.edu (Shawn L. Baird) (03/26/91)
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 |
kdarling@hobbes.ncsu.edu (Kevin Darling) (03/26/91)
In <2069@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >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 being 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) Wishes like this might be a good reason for CBM to start using PClone hardware, at least in the palette output section. For example, I'm running on a 68K machine which uses a common-brand palette RAM-D/A chip, which gives me the usual 256 colors out of 16 million. Now the interesting thing is that I can pop in a slightly more expensive version which has four separate full palettes... and up to 16 window areas (start xy, size xy, priority) can be set to use any of those four palettes. The palette chip itself handles the switching, no palette reloads needed. If it had perhaps 32 areas possible, I'd consider using it myself, but I can wait for now... I expect fancier models before long. Then there are the HAM-like chips coming soon, and ones which do ECS-like stuff such as changing 640x16-color into 1280x4-color. Buying these off the shelf must make more sense than creating your own chips ;-). Just a random thought - kevin <kdarling@catt.ncsu.edu>
clp@gumby.Altos.COM (Chuck L. Peterson) (03/28/91)
Anyone have a sample of a copper list for a simple interlace screen with no sprites? The interlace copper example in the HRM installs the copper program then spins waiting for the VSYNC interrupt; where it installs the correct bitplane depending on whether it is a long frame or not. I want a copper list which installs the correct bitplane pointers by itself so the silly thing will work even with interrupts disabled. Any hints? Chuck L. Peterson clp@altos.com
jimm@amiga.UUCP (Jim Mackraz) (03/28/91)
In article <4739@gumby.Altos.COM> clp@altos.COM (Chuck L. Peterson) writes:
)Anyone have a sample of a copper list for a simple
)interlace screen with no sprites? The interlace copper example
)in the HRM installs the copper program then spins waiting
)for the VSYNC interrupt; where it installs the correct bitplane
)depending on whether it is a long frame or not.
)
)I want a copper list which installs the correct bitplane pointers by
)itself so the silly thing will work even with interrupts disabled.
)Any hints?
I can't see any sane way in the world you could get the right phase of
the thing, but once started right you can set each field's copper
to ping-pong cop2jmp to the other field's copper.
You can see how graphics.library does this if you disassemble the copper
for an interlaced viewport.
I once said that you couldn't do a subroutine jsr in COP, but you can
(one level deep), so I don't want to go too strong on my "you can't
determine the correct phase."
Perhaps some elaborate dependency on the differing number of rows,
like a dead WAIT until the last row of the long frame ... hmmm.
If there was a row number unique to the long field, and you wait
for x=0 on this row, then the following instructions (aplenty)
would only be executed on the long field. Otherwise, they'd
be skipped when the hardware restarted the copper.
Maybe long-frame copper ends like this..
load coploc2 with pointer to this, the long frame, just
in case we're now out of phase.
wait until very last longframe row (ie, "if this is the long field")
reload coploc2 with pointer to short frame, because now
we know that we are the long frame.
Use coploc1 if you don't subscribe to the graphics copinit header...
Hmmm.
You could test this by poking colors .... send me a copy if that works...
jimm
--
--- opinions expressed herein are my own. ---
"... Because they can."
- profound punchline to joke about dogsmykes@amiga0.SF-Bay.ORG (Mike Schwartz) (03/31/91)
In article <7183@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >In article <12305@monu1.cc.monash.oz> int131d@monu3.cc.monash.edu.au (mr s.d. twyford) writes: > >> Then improve it by ... >> ...generating your own copper lists for the screen display. > >Why do you do this and what exactly do you put in your copper lists ? >Can you or anyone else give me a few examples of what can be gained >by generating one's own copper lists please ? > >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 ! > > >> Stuart Twyford > >Michael Rizzo > >Mike The Maltese Amigan >Yes we've got Amigas in Malta too ! First of all, you don't need TWO copper lists to do double buffering. All you need to do is change the plane pointers in a single copper list. Second, the copper is a coprocessor with the ability to wait until a specific scanline position (x and y) and it can store values into the Amiga hardware registers. The Operating System uses this trick to allow you to drag/pull down screens. What is really going on here is the copper list (program) is changing the hardware plane pointers and color palettes at the first scan line of the screen that was dragged down. The game shadow of the beast uses the copper heavily to achieve its stunning visual effects. -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
m_gietzen@saarag.zer.sub.org (04/02/91)
Once a guy asked about the reason of using the copper. I program games and know sth. about this wonderfull customchip. The simplest effect is the use of different palettes and different screens in different resolutions. You can mirror pictures without any processingtime, stretch pictures, rotate them and so on. Another great ability of the copper is that it is able to leave interrupts. So you can exactly start a routine at the same rasterpositon. (see rasterirqs on the C64...) Ciao, Markus Gietzen PS: Sorry for my bad english!
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/03/91)
In article <mykes.0830@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <7183@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >> >>Why do you do this and what exactly do you put in your copper lists ? >>Can you or anyone else give me a few examples of what can be gained >>by generating one's own copper lists please ? >> >>Other than having two copper lists for double buffering, as >>shown in the RKM Libraries & Devices (Yep I'm still using the > >First of all, you don't need TWO copper lists to do double buffering. >All you need to do is change the plane pointers in a single copper list. And this is considered one of the big NO-NOs for system-friendly programs! Thou shalt not do this (sp?). -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
andreww@uniwa.uwa.oz (Andrew John Williams) (04/03/91)
m_gietzen@saarag.zer.sub.org writes: > >Once a guy asked about the reason of using the copper. >I program games and know sth. about this wonderfull customchip. >The simplest effect is the use of different palettes and different >screens in different resolutions. >You can mirror pictures without any processingtime, stretch pictures, ^^^^^^^^^^^^^^^^ I know someone who has achieved this on the C64. No I didn't believe it either. He's got a full-screen picture (80*200, any pixel any colour) and puts sinusoidal waves through it. With a scrolly message below. And a very little red bar in the border to show how much CPU time is left. This sometimes vanishes completely. >rotate them and so on. >Another great ability of the copper is that it is able to leave >interrupts. So you can exactly start a routine at the same >rasterpositon. (see rasterirqs on the C64...) >Ciao, John West (stealing Andrew's account) I'd rather have a box of fish than a son like that > Markus Gietzen >PS: Sorry for my bad english!
jimm@amiga.UUCP (Jim Mackraz) (04/04/91)
(Peter Kittel GERMANY) writes: )(Mike Schwartz) writes: )>First of all, you don't need TWO copper lists to do double buffering. )>All you need to do is change the plane pointers in a single copper list. ) )And this is considered one of the big NO-NOs for system-friendly )programs! Thou shalt not do this (sp?). You cannot believe that the Amiga has gotten this far without people doing substantially more with the hardware, Copper in particular, than is supported by the OS. User Copper Lists are pretty useless; you can't even provide different copper instructions for the two interlaced fields, which means no Copper assisted smooth scrolling, playfield swaps, or mode changes in "TV" modes. Most of these effects would conflict with other screens, if present, anyway even if you used the user copper lists. Even color gradients, which the user coplists can do, conflicts with other screens. Clearly, since the system copper lists are dynamically reallocated and disposed, you can't poke their contents, but if you're telling programmers that they cannot and should (shalt) not use custom hardware copper lists of their own construction, you're way off base. The Copper is the biggest technical advantage the Amiga has in many application areas, including video, titling, and presentations. The difference in overhead between double-buffering displays using the copper and not using the system support Use it. jimm -- --- opinions expressed herein are my own. --- "... Because they can." - profound punchline to joke about dogs
jbickers@templar.actrix.gen.nz (John Bickers) (04/04/91)
Quoted from <9104011518.35.1541@SAARAG> by m_gietzen@saarag.zer.sub.org: > You can mirror pictures without any processingtime, stretch pictures, > rotate them and so on. Stretch and rotate? Feel free to elaborate... > Markus Gietzen -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***