From: Groepaz (groepaz_at_gmx.net)
Date: 2003-04-22 15:28:29
On Sunday 20 April 2003 17:11, 3843416 wrote:
> MEMORY {
> 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.
> SEGMENTS {
> 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
segments?)
> FEATURES {
> CONDES: segment = RODATA,
> type = constructor,
> label = __CONSTRUCTOR_TABLE__,
> count = __CONSTRUCTOR_COUNT__;
> CONDES: segment = RODATA,
> type = destructor,
> label = __DESTRUCTOR_TABLE__,
> count = __DESTRUCTOR_COUNT__;
> }
> SYMBOLS {
> __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?
gpz
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 majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-04-22 15:35:49 CEST