Cartridge coding using CC65

[Wrathchild]

After discussions in the normal A8 forum, I've put together a little example

of using C code and arranging it across banks in a cartridge (in this example XEGS)

such that functions can be called via a Jump Table that handles the bank switching.

 

We can use this thread to expand upon (or completely replace) ideas about how

to go about this. One thing I'm not too happy about is the dependencies that

I should really setup in the makefile as a change (such as a newly exported function)

would mean that the jmptable files change. Also you have to declare the bank

that the function resides in - not too much effort required there - but maybe a

dynamic way of doing this can be done.

 

It requires modifications to the atari.o (effectively crt0.s) in order to prep some

of the data (r/w and read-only segements), copying them to RAM, but I did leave

in an example where the RODATA section of one codebank was left in that bank

(and so available to the bank when it was switched in). The atari.lib however can

be used 'as-is' and for now I've left that in the always loaded bank at $A000->$BFFF.

 

I hope this can help someone get going on ideas they have. Post here or PM me

if you have something specific you are trying but can't quite pull off under CC65.

 

Regards,

Mark

XegsBanking.zip

[Wrathchild]

Here's a better main(), I'd forgotten to include the return value of Bank0Test:

void main(void)
{
char c;
clrscr();
c = Bank0Test(g_nGlobalInt);
printf("Bank0Test returned '%c'\n", c);
CodeSegMsg();
Bank1Test(&g_nGlobalInt);
printf("Tests done\n");
}

[Tickled_Pink]

Does CC65 store compiled code in contiguous memory addresses without interruption? Or does it create compound files?

[kenfused]

Does CC65 store compiled code in contiguous memory addresses without interruption? Or does it create compound files?

In the linker config file you can pretty much configure how you want it (how you want everything laid out in the output file).

In fact, if you need headers like on 8-bit binary load files, it is up to you to define those too.

[Wrathchild]

To add to that, the compiled (from C) object file (.o) doesn't hold the destination address,

that is assigned during linking. This is true too of the objects created from assembler

sources (.s), hence you can inter-mix them in your final program.

 

The .c to .o compilation actually goes via a temporary .s file which is assembled.