Posted on May 17, 2011 at 15:09 so, considering that you seem to be using a 4k ram derivative, I think the following should work (but I haven't tried):
# Segment Code,Constants:
+seg .const -b 0x8080 -m 0xff80 -n .const -it
+seg .text -a .const -n .text
# Segment Eeprom:
+seg .eeprom -b 0x1000 -m 0x800 -n .eeprom
# Segment Zero Page:
+seg .bsct -b 0x0 -m 0x100 -n .bsct
+seg .ubsct -a .bsct -n .ubsct
+seg .bit -a .ubsct -n .bit -id
+seg .share -a .bit -n .share -is
# Segment Ram:
+seg .data -b 0x100 -m 0xD00 -n .data
+seg .bss -a .data -n .bss
+def __startmem=@.bss
+spc .bss=0x400 # reserve 1K space
+def __endmem=@.bss
+def __endzp=@.ubsct # end of uninitialized zpage
+def __memory=@.bss # end of bss segment
+def __stack=0xfff
This linker file will give you the following RAM configuration:
0x000 to 0x0FF : zero page containing @tiny variables (.bsct+.ubsct)
0x100 to 0xF00 : contains @near data (.data+.bss) + 1k of heap, starting at the end of data
0xF00 to 0xFFF : stack
Note that the stack grows backwards from the top address (0xFFF): if it grows bigger than 256 bytes it will ''possibly'' overlap with the heap (if you have enough variables so that the heap actually reaches its maximum allowed address): in this case your application will behave randomly with no linker warnings (as it is always the case with stack overflow).
Hope it is clear (linker files are always complex),
Luca
