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 libraries. ---------------------------------------------------------------------- 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 00:00:40 2010
This archive was generated by hypermail 2.1.8 : 2010-02-18 00:00:42 CET