High RAM question

[TediusTimmy]

I'm using the cc65 compiler to compile some C code. A little project that I'm working on.

I understand that I can change the byte at memory address 0x0000 to change the High RAM bank. I understand that bank 0 is reserved for the Kernal. So, banks 1 to 63 are fair game and I can assume that there will be memory there. However, does the C run time use any of High RAM? Can I change that register willy-nilly (for fun and for profit, of course) while my program is running and expect nothing to have a heart attack? (Though, given that I'm using C and that the RAM bank register is at NULL, heart attacks are to be expected.)

This really isn't an X16 question so much as an X16 + programming environment question, but it does seem more appropriate than the cc65 discussion board. If you think I should just try it and see, give me a little while. I'm a ways away from having the program at that level. I've been doing bottom-up programming, and I haven't gotten to the thing that uses ALL the memory, yet.

Thanks

[StephenHorn]

As far as I'm aware, none of the C environments are presently using hi-ram, so the entirety of hi-ram should be fair game. There have been some folks (or at least one person?) attempting to figure out how to load a C program, or at least library functions, into hi-ram, but it's not the default behavior of the environment to try and do so.

[DragWx]

EDIT: CC65 does not use any high RAM unless you specifically tell it you want to. The rest of this post was me trying to figure out how to tell it to, which may be a bit off topic.

There have been some folks (or at least one person?) attempting to figure out how to load a C program, or at least library functions, into hi-ram, but it's not the default behavior of the environment to try and do so.

I'm not very familiar with CC65 (as in, using it to write C code instead of using CA65), nor the innards of making a CFG file for LD65, but I know the NES community uses it often and I was able to find some information.

The CC65 toolchain supports the concept of banked memory, and supports the concept of wrapped calls (i.e., for trampolines).

So if I'm reading this right, your CFG file would define multiple memory areas with the same address range ($A000-$BFFF), each with a "bank" attribute with the value you need to write to $0000 to make that bank available, and an output to a separate file which your program will load to high RAM when it runs.

Then, you'd write a wrapper function (using the inline assembler?) which gets the address of a desired function and the "bank" value for the memory area it's in, writes the bank value to $0000, calls the desired function, restores the old value of $0000, and returns.

Then, when defining functions which will live in banked memory, use #pragma wrapped-call to indicate that CC65 needs to call the wrapper function instead of calling the function directly, and then (I'm guessing) #pragma code-name to tell CC65 you want this function to be in a specific segment (tied to one of the banked memory areas).

Finally, when your program runs, you load that extra bank file to high RAM, and then all of the pieces to this puzzle hopefully come together.

EDIT: It looks like cc65 already has the stuff necessary to support bankswitching on the cx16 (cx16-bank), which already conveniently creates an output file for each extra bank of RAM, even prepended with the load address! So, it would just be a matter of writing the function wrapper, and using the #pragma directives to locate your various functions to high RAM.

[TediusTimmy]

Hey thanks. I'm not going to put any code up there, just data. The amount of free space will allow the user to go wild with whatever they want to do.

Good luck with trying to get code there.

[Ed Minchau]

Hey thanks. I'm not going to put any code up there, just data. The amount of free space will allow the user to go wild with whatever they want to do.

Good luck with trying to get code there.

Oh, you can get code there too. I made a module called FASTMATH that fits in one bank of RAM. There's a mixture of code and lookup tables for fast 8 bit fixed point math functions. All the subroutines are accessible from a jump table in page BF.

My META/L editor is spread across banks F0-FF of RAM, about 11 thousand lines of code plus data and metadata.

You can do damn near whatever you want with this computer.

[TediusTimmy]

Well, it appears to work. The C run time doesn't appear to go boom. Maybe I've just gotten lucky with my memory selections?

See the monster that I made here: viewtopic.php?t=6528
It's always great when you get to write a line of code like this: https://github.com/TediusTimmy/X16Cell/ ... ina.c#L194

Thanks for the help in me making poor decisions.