Hi,
in my project I'm able to put my own code into the language card. My goal is to have as much as possible RAM free to store data. So I would like to move some of the code linked in from libc into the language card also.

The location of the code can only be stated during compile time. At least I did not find any other way. And recompiling libc for my purpose would result in a libc which is special for my project. This is not desirable.

I think It would be necessary to tell the linker about my goal. But how? Is there any way? Any other tips?

Thanks!

A couple of alternatives. You could use the language card for your data instead putting your code there. That way you wouldn't have to change any addresses that make calls to your code or within your code. It is relatively easy to check the ceiling of available RAM for your data and extend that range into the language card for your data.

Another option might be, is to not use the language card, but rather, keep your data in what I like to call "modules" on disk. That way the amount of data that can be handled is only limited to the size of your disk.

Both of these methods can be programmed into your code with very little overhead.

The problem I have is that the language card gets write protected by code in libc (bit $C082, bit $C080). So I have to wrap all code which might alter the memory of the language card by special code to write enable the RAM. Since I'm using malloc if have to wrap each malloc/free/realloc. And I have to wrap my own code which may write to RAM. This is very error prone! So I think, cc65 prefers to put code into the LC (r/o).

There are many problems with what you just wrote.

First if LibC is disabling the LC with the use of $C082, then to access your code in the LC you will have to re-enable the LC again anyways.
Secondly, if your code was in the LC, then it wouldn't be able to make any calls to LibC as it would put you back into monitor ROM and not return to the LC.
Thirdly, if your code makes any calls to the Monitor ROM (COUT or KEYIN get used a lot) then you will have to copy the Monitor ROM over to the LC, which takes up space that could have been used for data.

This will cause you a lot more problems than wrapping your code with softswitches to switch between the LC and Monitor ROM.

Any which way you look at it, using the LC will cause you to put a lot of extra instructions into your code, whether your code is in the LC or lower RAM.

To write to the LC is two accesses of either $C083 or $C08B.

BIT $C083
BIT $C083

will read and write to bank 2 of the LC ($D000.DFFF)

BIT $C08B
BIT $C08B

will read and write to bank 1 of the LC ($D000.DFFF)

And in both cases, $E000.FFFF can be written to.

I'm a little bit confused. You do not take into account that cc65's libc already performs activation and deactivation of the language card. See e.g. https://github.com/cc65/cc65/blob/ce3bc ... le2/home.s.

And exactly this is my problem: Each switch from ROM to the LC RAM switches into read only mode. This would have to be corrected by my code which I would like to avoid.

(And you are right: I can't call code in ROM from the LC. This kind of code (e.g. home() as seen above) has to be located in normal RAM. So not each function in libc is able to be moved into the LC.)

The only other way to avoid LibC fiddling with the LC softswithes is to disable the softswitches in LibC so that the LC always remains in READ/WRITE mode. You will then have to put ROM calls in lower memory that disable the LC to make calls to ROM.

Something like:

BIT $C082
JSR HOME ; $FC58
JMP LC_RW


LC_RW BIT $C083 ; or BIT $C08B if you want bank #1 of the LC
BIT $C083
RTS ; return to the LC code

Thank you for all your input.

So it boils down to modifying LibC. Either I have to patch it to write enable the LC or I have to move some code to the LC. This I wanted to avoid.