Hardcode bitplane pointers in copperlist?
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! |
|
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? |
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: Code:
ABS_BITMAP EQU $70000 |
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? |
Quote:
Quote:
orgshould suffice. AFAIK loadis 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. Quote:
Quote:
dc.w). |
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. |
UHhhm ok... now I'm getting a bit confused :D
PHP Code:
PHP Code:
|
Quote:
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:
|
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.
|
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 |
I see, thanks.
|
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 :spin
Quote:
|
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). |
Quote:
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: Code:
SECTION ChipData,DATA_C |
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. |
Quote:
And jotd is right, the Assembler can only do what the OS reloc handler supports. From some testing you can declare any longword pointer, modified with + and - with as many absolute expressions (including symbols) as you wish, but a word size (which involves a calculation - truncating) or any other calculation operand results in Relative mode error. |
Thanks jotd and Photon, I learnt it the hard way :)
|
Here is the macro I use in ProAsm to put the bitplane address into the copper list:-
Quote:
the label 'z', when subtracted from the bitplane label, turns it from an address into a number which can then be split into high and low parts. The macro 'CMOVEA' (CMOVE Address) creates two CMOVEs, one for the high address part and one for the low part. 'reg' must be the first custom chip register in a pair, eg. 'bpl0pth'. |
Quote:
Quote:
You found a way to trick the assembler, so you no longer get the helpful error message. But in the end you trick yourself, because the relocation information is missing and the bitplane addresses are wrong after starting the program. |
All times are GMT +2. The time now is 10:39. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.