FATQW@USU.BITNET (Bryan Ford) (08/14/88)
Subject: Re: vports ,cmaps, views and buses >)How can I create several different LOFcprlists that use the same colortable >)copper instructions? I am using one view structure that handles various >)views for double-buffering, and by mistake each copper list has its own >)color load instruction list. I want them all to use the same one, so LoadRGB4( ) >)will work on all of them. > >Tough one. Maybe someone more Studly than I can shed better light, but >I think you're screwed, because there is no way a copper list can >call another one as a subroutine. No way. Were it so, this might >be easy. No way, huh? Try this: A. Copper List wants to call Subroutine. It first stores the address to return to in COP1LC. Then it stores the Subroutine address in COP2LC and accesses COP2JMP to jump to the Subroutine. B. Subroutine receives control, does whatever is necessary (in this case, sets the color registers), and then accesses COP1JMP to return to the main copper list. C. Copper List receives control and resumes executing. True, this may not be practical for some purposes, and it only works on a single level (subroutines can't call subroutines), but if you've got several big copper lists, in which much of the code is duplicated in each list, this might be a possibility. Also, it is "possible" to create a true copper "stack" in memory by having the copper use the blitter to push and pop addresses off the "copper stack". However, this would be very inefficientt and you wouldn't be able to use the blitter for anything else. Bryan
jimm@amiga.UUCP (Jim Mackraz) (08/16/88)
In article <8808132257.AA02749@jade.berkeley.edu> FATQW@USU.BITNET (Bryan Ford) writes:
)Subject: Re: vports ,cmaps, views and buses
)
)>)How can I create several different LOFcprlists that use the same colortable
)>)copper instructions? I am using one view structure that handles various
)>)views for double-buffering, and by mistake each copper list has its own
)>)color load instruction list. I want them all to use the same one, so LoadRGB4(
) )
)>)will work on all of them.
)>
)>Tough one. Maybe someone more Studly than I can shed better light, but
)>I think you're screwed, because there is no way a copper list can
)>call another one as a subroutine. No way. Were it so, this might
)>be easy.
)
)No way, huh? Try this:
)
)A. Copper List wants to call Subroutine. It first stores the address
)to return to in COP1LC. Then it stores the Subroutine address in
)COP2LC and accesses COP2JMP to jump to the Subroutine.
)
)B. Subroutine receives control, does whatever is necessary (in this
)case, sets the color registers), and then accesses COP1JMP to return
)to the main copper list.
)
)C. Copper List receives control and resumes executing.
Very studly, Bryan. I guess I drew my false conclusion in a context
where I wasn't supposed to use both pointers, or some other excuse. You
win the "Institute for Advanced Studly Award for Shrewd Programming."
Don't forget to reload COP1LC with the head of the main copper list
before vblank.
So, the thing looks like this:
copmain:
....
MOVE return,COP1LC ; return address
MOVE copsub,COP2LC ; subroutine address
MOVE 0,COP2JMP ; jump to subroutine
return:
MOVE copmain,COP1LC ; restore
....
copsub:
...
MOVE 0,COP1JMP ; 'rts'
)True, this may not be practical for some purposes, and it only works
)on a single level (subroutines can't call subroutines), but if you've
)got several big copper lists, in which much of the code is duplicated
)in each list, this might be a possibility.
I dunno, I think it counts. You have to resolve the labels
yourself, of course.
)Also, it is "possible" to create a true copper "stack" in memory by
)having the copper use the blitter to push and pop addresses off
)the "copper stack". However, this would be very inefficientt and
)you wouldn't be able to use the blitter for anything else.
Now you're pushing your luck. ;^).
) Bryan
Nice hack, buddy.
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.brianm@sco.COM (Brian Moffet) (08/17/88)
In article <3304@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > > IDEA: Suppose you just poke the color registers directly? Take the The OS will put them back to what ever they are supposed to be. This is done with the copper I think. brian -- -=-=-=-=-=-=- Brian Moffet brianm@sco.com {ucscc,uunet,decvax!microsof}!sco!brianm My opinions do not in any way reflect those of my employer or my fish. 'Evil Geniuses for a Better Tommorrow!'