Re: [cc65] Customization of cc65 for new targets

From: Bruce & Ann Reidenbach <bereiden1gmail.com>
Date: 2010-02-18 13:55:22
Forgive me as this is a long post:



Firstly, if I specify the ZEROPAGE segment to be $1A in length, I get a
linker error because I define my own pointer in the zerpage space for the
RS232 driver.  The linker error is:



> ld65.exe: Warning: Memory area overflow in `ZP', segment `ZEROPAGE' (2
> bytes)
>
> ld65.exe: Error: Cannot generate output due to memory area overflow
>


So I need to increase the size of the zero page segment.  I was under the
impression that the .cfg file is used to describe the underlying hardware
memory map, so bumping the ZEROPAGE segment to $100 in length does no harm,
since that what it truly is.  The only issue I see in using the maximum
value is if the zeropage data constructor were to copy the zeropage
locations that are used into a "safe" area.  In this case, you'd want to
specify the smallest size so that it minimizes the copy time and the safe
area size, but wouldn't the linker already have this information and would
only copy what was needed?


The other option is to spec the actual storage requirement (in this case
$1C), but then every time an additional zeropage location is used in the
code there would need to be change to the .cfg file.  From my (admittedly
lazy) viewpoint, using the maximum value is one less thing to worry about.  I
defer the decision on what value to use to the people who have much more
experience in using cc65 than me -- I’d just like to give you my insight as
a long time FPGA/ASIC engineer.  In the meantime, I have changed the writeup
by adding the second sentence:


ZP defines the zero page location, starting at $0 with a length of $100.  At
> a minimum, the cc65 run-time environment uses 26 zero page locations, so the
> smallest zero page size that can be specified is $1A.
>

 Second, I probably misread what Oliver said in this thread (and apologies
to Oliver if I did), but I got the impression that he recommended the RAM
space start at $0 instead of $200.  As an experiment, I set the RAM starting
address to $0, and according to the map file the DATA and BSS segments now
start at $0 and grow upwards, stepping on the zeropage and 6502 stack pages:



> Segment list:
>
> -------------
>
> Name                  Start   End     Size
>
> --------------------------------------------
>
> DATA                  000000  00002E  00002F
>
> ZEROPAGE              000000  00001B  00001C
>
> BSS                   00002F  00005E  000030
>
> STARTUP               00F02F  00F04C  00001E
>
> INIT                  00F04D  00F08B  00003F
>
> CODE                  00F08C  00FCD8  000C4D
>
> RODATA                00FCD9  00FD42  00006A
>
> VECTORS               00FFFA  00FFFF  000006
>


So again, I see the .cfg file as a description of the actual hardware memory
map, which means that the program RAM space really does start at $200 since
the first two pages are reserved for the 6502.



Finally, I have changed the text to use __fastcall__ instead of fastcall to
avoid confusion.


Bruce

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Feb 18 13:55:30 2010

This archive was generated by hypermail 2.1.8 : 2010-02-18 13:55:32 CET