Re: [cc65] linker cfg files

Date view Thread view Subject view

From: Groepaz (
Date: 2003-04-22 15:28:29

On Sunday 20 April 2003 17:11, 3843416 wrote:
>  ZP: start = $02, size = $1A, type = rw;
>  RAMLO: start = $07ff, size = $1800, define = yes, file = %O;
>   BMP: start = $2000, size = $1f40, define = yes, file = %O;
>   RAM: start = $3f3e, size = $4000, define = yes, file = %O;
> }

slight mistake :o)

>   BMP: start = $2000, size = $1f3e, define = yes, file = %O;
>   RAM: start = $3f3e, size = $4000, define = yes, file = %O;

try to change that.... i have no clue how the linker deals with overlapping 
segments, but if it doesnt throw an error (which it should probably.... UZ??? 
:O)) i would expect it to garble the output..... maybe changing this is 
already the solution to your problem.

>   BITMAP: load = BMP, type = bss;
>   STARTUP: load = RAMLO, type = wprot;
>   CODE: load = RAMLO, type = wprot;
>   RODATA: load = RAMLO, type = wprot;
>  DATA: load = RAM, type = rw;
>  BSS: load = RAM, type = bss, define = yes;
>  ZEROPAGE: load = ZP, type = zp;
> }

ok....uhmz...except there is no "LOWCODE" segment (which the startupcode uses) 
... sure this is what you want? (dont you get warnings about missing 

>  CONDES: segment = RODATA,
>   type = constructor,
>   label = __CONSTRUCTOR_TABLE__,
>   count = __CONSTRUCTOR_COUNT__;
>  CONDES: segment = RODATA,
>   type = destructor,
>   label = __DESTRUCTOR_TABLE__,
>   count = __DESTRUCTOR_COUNT__;
> }
>  __STACKSIZE__ = $800; # 2K stack
> }

also ok... btw stacksize can be easily reduced to like $400 bytes or even less 
(i've used $0200 bytes for the pcengine stuff and it still works ok for 
me..... probably not for deep recursion stuff and alike though :=P)

> then i used following assembly prg to reserve storage in the
> BITMAP segment:
> .segment "BITMAP"
> .res 8000,0

this might work, but it is not sane.... it doesnt garantee (? err) at which 
memory location this block will be allocated.... however since you have 
defined a seperate section "BMP" and dont use it for anything else, it will 
still work :=)

in this case, you might omit the above completely and just use the "BMP" 
section manually (if you dont use it for other stuff than bitmap that is)... 
this might save you some bytes in the final binary (however not in this case, 
since the BMP section is located in the middle of the binary so it can not be 
ommited from the output file)

> the rest was done in c. i expect malloc to reserve storage in this
> segment, so that the program crashes. yes, that is what it does.
> without using this memory configuration the program ran already.

so are you using malloc at all? (just asking because the above "res 8000,0" 
will not use malloc but allocate space at compile time).

tjam.... maybe you can post an as-small-as-possible testprogram that leads to 
the same problem?


btw as someone else suggested.... you can avoid lotta trouble of you use the 
ram under kernel/io for bitmap graphics (and you also dont loose all the 
valueable space for your c-program)
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-04-22 15:35:49 CEST