A couple beginner questions

[Nyala]

Hello, I have a couple beginner questions to ask at this time.

As I can see in the Amiga System Programmer's Guide, when doing a clean exit from a program that installs it's own copper list, it is common to do an operation such as

move.l 38(a5),COP1LC(a6)

with graphics.library in a5 and chip base in a6, which supposedly restores some original copper list. However, in photon's wrapper, he also does

move.l 50(a5),$84(a6)

My first question is: Where can I find documentation on these offsets in graphics.library (38, 50) and what they do? I am guessing they are graphics.library functions, and you just have to know their offsets in asm. I'd also like to know more about this process of restoring the copper list.

My second question is: What is the best way of handling data such as copper lists and screen buffers? Is it best to do like photon and declare them in sections such as DATA_C and BSS_C, or is it better to do as in the System Programmer's Guide, and make an AllocMem call for them then build them if necessary? What are the pros and cons of each method?

Also, given the questions I have asked, is there any other advice you can think of that might be useful for me to know so I can avoid asking further questions?

[Don_Adan]

A6 can not be exec base for these examples. Must be $DFF000 aka CHIP.

[Nyala]

Originally Posted by Don_Adan

A6 can not be exec base for these examples. Must be $DFF000 aka CHIP.

Ah yes, my mistake. That is what I meant and I've updated my OP to correct it, thank you for pointing it out.

[redblade]

Originally Posted by Nyala

Hello, I have a couple beginner questions to ask at this time.

My first question is: Where can I find documentation on these offsets in graphics.library (38, 50) and what they do? I am guessing they are graphics.library functions, and you just have to know their offsets in asm. I'd also like to know more about this process of restoring the copper list.

http://amigadev.elowar.com/read/ADCD...AE.html#line24
https://amigadev.elowar.com/read/ADC.../node0551.html
Search for Gfxbase and you will find Offset Decimal 38 ($26 Hex) which is Copinit. The Second one has the calculated offset in both decimal and hex next to the structure function.

My second question is: What is the best way of handling data such as copper lists and screen buffers? Is it best to do like photon and declare them in sections such as DATA_C and BSS_C, or is it better to do as in the System Programmer's Guide, and make an AllocMem call for them then build them if necessary? What are the pros and cons of each method?

Copper Lists and screen buffers which are accessed by the custom chips can only be stored in CHIP memory.

You can Exec.library/AllocMem(CHIP) or Graphics.Library/AllocRaster() Which will return a pointer of allocated memory in CHIP RAM and you can store that pointer in PUBLIC memory.

If you need more info, just ask and some of the other programmers will help you

[Nyala]

Thank you redblade. From the links you posted I can now see where those offsets come from and how they are found. I can see that

move.l 50(a5),$84(a6)

sends the LOFlist to COP2LC, but I am still not sure what an LOFlist is or why photon is sending it to COP2LC when restoring things on exit in his wrapper.

On that note, why is there a COP2LC? When and why is it used or not used?

[phx]

Originally Posted by Nyala

Where can I find documentation on these offsets in graphics.library (38, 50) and what they do?

I would recommend to get the NDK with all autodocs and include files. Then you no longer have to care about numbers but just write:

        include "graphics/gfxbase.i"
        include "hardware/custom.i"
        ...
        move.l  gb_copinit(a5),cop1lc(a6)

Much more readable, isn't it?

I'd also like to know more about this process of restoring the copper list.

You may also want to load the old View from

GfxBase->ActiView

with

LoadView()

, before starting the copinit list.

Is it best to do like photon and declare them in sections such as DATA_C and BSS_C, or is it better to do as in the System Programmer's Guide, and make an AllocMem call

I would say that it primarily depends whether you want to keep this memory during the whole runtime of your program, or whether these are temporary allocations. In the latter case you should use AllocMem and friends. Otherwise you may use AllocMem as well, but you can save the OS-calls by having the loader (LoadSeg) doing the allocations for you.

DATA_C

and

BSS_C

are directives known by many Amiga assemblers to create a section which is loaded into Chip RAM. Alternatives:

section name,data_c

or

section name,data,chip

.

Originally Posted by Nyala

On that note, why is there a COP2LC? When and why is it used or not used?

I think the intention was to allow conditional jumps (via COPJMP1, COPJMP2) between two copper lists.

[Thomas Richter]

Originally Posted by Nyala

As I can see in the Amiga System Programmer's Guide, when doing a clean exit from a program that installs it's own copper list, it is common to do an operation such as

move.l 38(a5),COP1LC(a6)

with graphics.library in a5 and chip base in a6, which supposedly restores some original copper list.

Frankly, whenever possible, you should use the graphics library for graphics operations. In particular, graphics does support user copper lists, and they even drag with the screen they are installed on. These are the UCopperListInit(), CMove and CWait() calls of the graphics.library. You find them documented in the "autodocs" of the graphics.library, freely available with the NDK of the operating system, and the RKRM Libraries book, which you also find online.


If you *must* take over the graphics system, use "LoadView(NULL)" (again from graphics) to ensure that you are operating on a native display and not an RTG display, and to restore the display, use LoadView(GfxBase->ActiveView).


All these calls are, as Phx already mentioned, documented in the NDK and the RKRM Libraries, both freely available.

Originally Posted by Nyala

My second question is: What is the best way of handling data such as copper lists and screen buffers?

The best way is through the graphics.library, and through the intuition.library, the latter includes also functions for double buffering and swapping screen buffers in a system-friendly way. Some example code how to arrange screens and screen buffers you find in the mentioned RKRM volume.

[ross]

Originally Posted by Nyala

..but I am still not sure what an LOFlist is or why photon is sending it to COP2LC when restoring things on exit in his wrapper.
On that note, why is there a COP2LC? When and why is it used or not used?

The system uses COP1LC as the main copper list (and this is obvious because the pointer is reloaded at the beginning of the frame) but at some point it forks the copper list dynamically.
To do this it uses the value in gb_LOFlist: during the VBI it puts it in COP2LC and the main copper list jump to it with a strobe to COPJMP2.
But there can also be the use of interlaced mode; in this case the value in gb_SHFlist for short fields is also used alternating (in progressive mode, long fields are normally used).

Why is it done this way?
- COP1LC remains unchanged and even if there are jumps in the copper list the next frame is always consistent
- COP2LC can be dynamically changed at will and screens with different properties can be generated without side effects on subsequent frames

So going back to why in your example gb_LOFlist is also saved.. well there would be no need.
Saving gb_copinit is mandatory and essential because its value is unchanged over time, as well as that of gb_Actiview if you use LoadView(NULL).
That of gb_LOFlist instead is 'optional' because the system, once restored, resets it during the VBI.

BUT, provided system restore is done properly..
If for some reason the right COP2LC is not reset in time and the main system copper list jumps to 'old value', and at this point the used memory no longer contains a valid copper list, at best you would have video glitches, at worst a crash.

Again, this should not in theory happen if your code is sane, but as a precautionary measure, if you modify COP2LC in your code, then it doesn't hurt to restore it.

[Thomas Richter]

Ross,

what you describe here is not part of the operating system interface, it is just what the current implementation of graphics does - for native screens. The interface towards user provided screens goes through LoadView() from the graphics side. That will keep care of the system copper lists. If there is a copper, that is.

[ross]

Originally Posted by Thomas Richter

Ross,

what you describe here is not part of the operating system interface, it is just what the current implementation of graphics does - for native screens. The interface towards user provided screens goes through LoadView() from the graphics side. That will keep care of the system copper lists. If there is a copper, that is.

Yes, sure.
My speech absolutely does not exclude the use of LoadView() (and in fact I also wrote about it).

But it seems that the OP wants to directly use the access to copper list custom registers (and he has all the rights);
otherwise it would not make sense to actually restore the values at exit.
Is it a bad and dirty way? Yes, and I can survive at it

I'm not advising him anything, I'm just telling him how it works on a classic/native view Amiga (and answered his questions).
Of course he can follow your advices and no one will tell him it's wrong.

[Rock'n Roll]

From a beginner side I would say, the ordinary way is to put the copperlist
in section DATA_C. The advantage is you can easy modify the copperlist every
time. In the most examples is this made so.

And this is also the disadvantage for AllocMem for the copperlist, because you
have to know the copperlist size from beginning or you allocate to much memory.

I prefer to declare the copperlist in section DATA_C also from the esthetic
side. It is easier to read and you need no OS-calls.

[Nyala]

Thank you for your responses everybody, the explainations are excellent and my questions are answered for now!