Hardcode bitplane pointers in copperlist?

[KONEY]

So far I've only seen bitmap pointers poked into copperlist by the CPU, but is there a way to hardcode them directly from source code? Is there a syntax for this?

Thanks!

[Skyhawk]

Read this: http://amigadev.elowar.com/read/ADCD.../node0011.html

[DJ Mike]

Are you banging the hardware directly or using OS calls?

Copperlist has to reside in chip memory, so at some point the CPU has to move it there, whether that's your program building (poking) it into memory at runtime, or it being loaded along with your code. It might be helpful to know what you're trying to achieve?

[a/b]

Yeah, if you are using absolute addresses (AllocAbs() or ORG/LOAD). Otherwise (AllocMem() or relative sections) you don't know where the bitmap will be in memory during compile time, and since the segment loader cannot handle splitting a 32-bit address into 2 parts you have to do it manually with the CPU in run-time (which is what you want to avoid).
For example:

ABS_BITMAP EQU $70000

; version1
  SECTION Code,CODE
  move.l 4.w,a6
  move.l #(320/8)*256,d0
  lea ABS_BITMAP,a1
  jsr _LVOAllocAbs(a6)  ; +handle error

; version2
; absolute section, will not be added to executable as a hunk (ok for OS-killer demos/games and similar)!!
  ORG ABS_BITMAP
  LOAD ABS_BITMAP
  DS.B (320/8)*256

; now you can hardcode it in copperlist
  SECTION DataChip,CHIP
Copper:
  DC.W $00e0,ABS_BITMAP>>16,$00e2,ABS_BITMAP&$ffff
...

[KONEY]

Thanks a/b! I think version 2 is what I was looking for!

In short, what I need to do is use ORG + LOAD in place of a label then on the copper use it to deal with low and hi words, as per example.

May I ask why the second word is padded with ones? (&$ffff)? Or is it ANDed?

Also, do you know any documentation of these assembler tricks?

[phx]

Originally Posted by KONEY

I think version 2 is what I was looking for!

Depends on the rest of your project. Is it all absolute code?

In short, what I need to do is use ORG + LOAD

org

should suffice. AFAIK

load

is only required for AsmOne-family assemblers to load the assembled code to that address in memory - at the time of assembly! May be useful for testing on real machines, but I would avoid that source code.

in place of a label

You still need a label. But the label will be absolute after ORG.

May I ask why the second word is padded with ones? (&$ffff)?

You want to make sure that only the least significant 16 bits of the address are stored. Some assemblers would otherwise warn, because the value doesn't fit into a word (

dc.w

).

[a/b]

Phx got most of it covered, so just a few extra notes...

Yeah, you could add a label after ORG/LOAD, it's what I typically do when I have multiple data sets at some abs address (so each data gets a label).
In principle, you don't even need ORG/LOAD and DS.B. EQU at the start to define a symbol (so you don't have to hardcode it all over the place) is all you need, but you'd have to keep a mental note what it at that particular address, how much space does it take, etc.
It's ugly enough as is and without it it's worse, and basically don't recommend doing it unless you are killing the OS and the only way to exit is a reset.

&$ffff removes the upper word, reason explained above.

[KONEY]

UHhhm ok... now I'm getting a bit confused

PHP Code:

ABS_BITMAP EQU $70000 


is all I need but how do I figure out the value $70000? Isn't the value figured out during build?

PHP Code:

DS.B (320/8)*256 


reserves enough bytes to hold a bitplane, why shouldn't I need it? In fact, I was going to change it into an incbin of a file, in my plans...

[KONEY]

Originally Posted by phx

Depends on the rest of your project. Is it all absolute code?

if with absolute you mean that I know the addresses then no, I don't think so.

So to speak, this is a tipical code I would produce: https://github.com/KONEY/rusteater_a...STEATER_MAIN.s

Basically what I'm trying to do is get rid of these lines:

PHP Code:

    LEA    BGNOISE0,A0
    LEA    COPPER\.BplPtrs,A1
    BSR.W    PokePtrs 


and pre-populate the copperlist with the hi and lo words from the address which will be at label BGNOISE:

[jotd]

it's a lot of constraints for which result? just set them at initialization time and that's it. Else you have to know exactly the value.

[a/b]

If your bitmap is in a relocatable section (e.g. SECTION xyz,DATA_C) you cannot take a shortcut. You have to set the bitmap pointers in copperlist manually with CPU because you don't know at what address will bitmap be when your program is executed, and you are trying to split that address in two halves (not supported).
You can do that only when the bitmap address is known at compile/assemble time (and that requires absolute address).
There is a similar thread (different problem, but the same reason why not) which should explain the program loader's limitations in regard to address manupulation in more detail: https://eab.abime.net/showthread.php?t=117217

[KONEY]

I see, thanks.

[KONEY]

Result in my mind is to split the screen in 32 waits and point 32 different EHB planes in each one of them. And all this would be generated by an ARexx script running from PPaint, adding palettes and includes etc. Therefore getting rid of some code would have been quite helpful, at least while testing if all could work the way I plan

Originally Posted by jotd

it's a lot of constraints for which result? just set them at initialization time and that's it. Else you have to know exactly the value.

[Photon]

List of pros and cons:
A generic PokePtrs routines is easy to write and can be used for sprite, audio, etc pointers as well. That is, if you set them with the Copper. If you set your pointers in your mainloop sync or in the VBI, you can just... set them

However you do it, this is the dynamic way.

As for absolute addressing, it was the fastest way to assemble and run on a dedicated dev A500. It can still be used for this, or if the result is intended to be run from trackdisk, in which case it might be very difficult to LoadSeg() with full compatibility plus have enough memory left if you don't turn the OS off/overwrite Exec.

It's useful if you reuse memory a lot (e.g. a multi-part, trackloaded demo or game) and want to actually reuse it under your control, as opposed to pretending "buy more RAM" is always true and adding sometimes ridiculous memory demands onto your program (or hog a clump and roll your own allocation a la C).

IOW, use it wisely and it saves you time (and some boring cross-SECTION references handling), OTOH, if it will not be track-loaded, let the OS handle memory. The latter is good practice, if you use absolute addressing, just know what you're doing.

And finally, if the Copper list and screen buffer are in the same (Chip) SECTION, you can have the Assembler poke it for you at assembly time, as a/b shows. If you get errors, just put parentheses around and limit each calculation to 16-bit (&$ffff).

[KONEY]

Originally Posted by Photon

List of pros and cons:
And finally, if the Copper list and screen buffer are in the same (Chip) SECTION, you can have the Assembler poke it for you at assembly time, as a/b shows. If you get errors, just put parentheses around and limit each calculation to 16-bit (&$ffff).

Thanks Photon! Copperlist and buffer are in same SECTION so I'm trying this suggestion. But any combination of parentheses and limits leads to an "illegal relocation" error, at least with Vasm. Am I missing something?



Tried all these:

    SECTION    ChipData,DATA_C


COPPER:


    DC.W $E0,(COPPER)&$ffff
    DC.W $E0,(COPPER&$ffff)

    DC.W $E0,(COPPER>>16&$ffff)
    DC.W $E0,(COPPER>>16)&$ffff
    DC.W $E0,COPPER&$ffff
    DC.W $E0,COPPER>>16
    DC.W $E0,COPPER>>16&$ffff

[jotd]

as said earlier, amiga executable format can't handle half-relocations like this

.elf format can do this (because powerpc needs that to load half-instructions) but hunk exe format can't.