Re: [cc65] Specific Memory Addresses at Compilation

Hi Tom,

> I have a whole bunch of graphics data (charmaps and sprites) that I
> need to load into very specific data-locations in graphics bank 1
> between $4000 and $8000.
> Previously, I've just loaded that data directly into my machine code
> monitor as a single operation, and then loaded my compiled program
> into memory.
> Now my program is getting larger, it's starting to eat into my
> reserved memory area.
> How do I avoid this?
> I can either move my graphics data into code and get cc65 to include
> it at compile time - perhaps by genarating a large flat array - but
> I need to put it at a specific memory location for that to work. How
> do I do that? Alternately, is there a way to get the linker to
> recognise a particular file - perhaps even of "raw" data and to load
> it into memory at a specific address?
> Presumably this is a common scenario - how have people dealt with it
> in the past?

I would write a custom linker config.  At least to make sure $4000—$8000 
is safe from being used by code, data, and stack of the C program.

You could set up segments for the various graphic data in the linker 
config and use simple assembler files with ``.segment`` and ``.incbin`` 
to create object files that can be linked in by cc65 and produce one 
final binary.

The course of action also depends a little bit on what „starting to eat 
into my reserved memory area” exactly means.  Is code + initialized data 
crossing the $4000 address, or is dynamically allocated memory or the 
(software) stack trashing the graphic data?

If it is the dynamically memory then leave a gap for the graphic in the 
linker config.  Maybe moving initialized data behind that gap to have a 
little more space for just code before it.

If it is the code itself getting too large you could move the whole C 
program behind $8000.  Then you have 20 KiB for code + initialized data 
+ dynamically allocated memory + stack.

If shuffling the existing segments before and after the gap is not 
enough you have to start breaking up the code into different segments by 
defining at least one segment after the gap for code and using 
appropriate ``.segment`` statements in assembler sources and 
``#pragma``\s in C sources to place some of the code there.

Ciao,
	Marc 'BlackJack' Rintsch
-- 
“XML combines all the inefficiency of text-based formats
 with most of the unreadability of binary formats :-)”
                             -- Oren Tirosh, c.l.p, 2002
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.