Re: [cc65] cfg-files and the linker and so on..

On Sat, Sep 25, 2004 at 04:55:12PM +0200, Mats Andrén wrote:
> This works nicely, but the RAM area after the startupcode
> ($08xx-$0fff) is now unused since the editor code segment currently
> starts at $2000. Now let's say that I'd like to be able to simply
> relocate the asm-player-code to some other adress, like $6000 or
> whatever, then I'd obviously like to have some of the editor-code
> going before that segment and some of it after it since the memory
> after the player-code would be to small to hold the complete editor code.
> Is that possible somehow, or am I asking too much? Perhaps I have to
> do this by myself, by changing here and there in my C code where
> different parts of the C code should go, so some of it ends up before
> the player and some of it ends up after it?

Why exactly do you want to move some of the code to $1000? If it is part of
the program, why is it important, at which address the code is located?

The linker is able to place segments at the addresses you specify, but it is
not intelligent enough to distribute code between several memory areas without
your help. So if you want code or data to get located somewhere, you will have
to place it into a segment and assign this segment to a specific memory area.

But you may want to consider groepaz' suggestion. You didn't give any reasons
for the things you're trying to accomplish, but for me his suggestions sound
reasonable.

> Also, should I really be required to have that "fill = yes"-snippet in
> the cfg-file to make the linker understand that I don't want a binary
> that only contains the code I've actually written, but that I actually
> want it to automatically end up at those places in memory that I have
> specified in the cfg-file, with chunks of empty space in between? I
> thought "load = $xxxx" was supposed to take care of that?

No. "load =" is used to define different run and load addresses. The linker
will always relocate the code to a specific address, but that does mean
nothing for the format of the output file. The output file could consist of
three 256 byte chunks located at $1000, $2000 and $3000 with a total size of
3*256=768 bytes. This may be useful for special purposes. If you want a memory
area to be filled in the file, you will have to request that explicitly.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.