Re: [cc65] Customization of cc65 for new targets

From: Greg King <>
Date: 2010-02-18 00:00:19
From: "Shawn Jefferson"; on Wed., Feb. 17, 2010; at 04:52 PM -0500
> From: Oliver Schmidt
> Date: Wednesday, February 17, 2010 11:54 am
> > If the guide targets not only bare-metal [or rather,
> > bare-virtual-metal, in your case ;-)] developers, then I'd really
> > like to see the zero-page memory-area size reduced from $100 to $1A.
> > That is the amount of zero-page space used by cc65. And, the config.
> > file doesn't describe what's there, but describes what's used. Just
> > the same with the RAM area starting at $200 instead of $0. For any
> > target running inside an OS and/or BASIC environment, co-ordinating
> > the zero-page space usage is crucial; and therefore, it would help a
> > newbie a lot to understand how many zero-page locations CC65 needs.
> > If you check out the existing configurations, you'll notice that
> > they all have a zero-page size of $1A.
> I don't believe that it is true for all targets.  The Atari 8-bit has
> a zero-page size of $80; and, the Atari Lynx has much more.  At least,
> I think that what you are referring to is the amount of zero-page
> space that is safe for cc65 to use, as listed in the linker config.
> file?  Where zero-page space starts and the size of it is going to be
> very platform-dependent; and, that should be pointed out in the
> document (which I haven't had a chance to read yet, sorry!)

Many of the configuration files have bigger zero-page areas.  Those
files say what _can_ be used (not what is used).  That gives programmers
as much flexibility as possible when they write code.  Some of the files
say only the minimum-required space because those targets save the old
data into a buffer; and, Uz chose to keep that buffer small.

I agree that the document should mention that the zero-page memory area
needs to be -- at least -- 26 bytes long for programs that use the CC65

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Feb 18 00:00:40 2010

This archive was generated by hypermail 2.1.8 : 2010-02-18 00:00:42 CET