Re: [cc65] Specific Memory Addresses at Compilation

From: Karri Kaksonen <karri1sipo.fi>
Date: 2012-10-15 06:37:41
On 14.10.2012 12:49, Zen Tom wrote:
> Hi,
>
> I wonder if someone can help - I'm writing a game using cc65 for the C64.
>
> 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?
>
> Any pointers much appreciated.
> Kind regards,
> Tom

I had the same problem with an Elite clone. When the code gets bigger 
the best solution is to split both the code and the graphics into 
segments that can be loaded in when needed.

In Elite there is separate places in the game:
- flying needs 3D math, stars, planets, spaceships
- docked at a space station needs buying, selling, starmaps, storyline stuff

Swapping with two or more modes using segments will actually double the 
available memory. Of course you need to split the code into multiple 
files also. One file contains common code, one code that is needed in 
flying mode, one file with code for docked mode.

--
Karri

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Oct 15 06:37:58 2012

This archive was generated by hypermail 2.1.8 : 2012-10-15 06:38:02 CEST