Hello Uz, * On Wed, Sep 12, 2012 at 08:29:09AM +0200 Ullrich von Bassewitz wrote: Good morning! > > On Tue, Sep 11, 2012 at 10:29:14PM +0200, Spiro Trikaliotis wrote: > > you are missing rule #2: > > > > 2. the end is defined as the last byte before the next segment begins > > (according to rule #1). > > If there is no next segment, until the end. > > > > That is, filler btes at the end of the segment are part of that > > segment. > > If you interpret this rule so that the contents of a segment can be changed by > assigning an offset to *an other* segment, then I think this rule is highly > unreasonable. Just because I change the offset of CODE2 doesn't mean I want > CODE1 to change. Yes, this was the intepretation. The reason to do it so was to make sure the whole memory area can be controlled by the segments. Otherwise, we happen to have "whole" where the filler bytes cannot be controlled by the segment to override the memory section value. > > Thus, a segment begins with the first byte that is issued for this > > segment (as defined specifically, filler bytes do not count for this > > segment), but it ends with the last byte that is issued before the > > beginning of the next segment. Here, filler bytes *do* count. > > Yes, but not filler bytes issued for some other segment. Or did you really > interpret this so? Yes, my specification was meant for exactly this: I wanted to make the filler bytes before the next segment to count for the current one - and, likewise, the filler bytes at the end of a memory section to count for the last segment. An alternative would have been to make the filler bytes before a segment to count for that one. Unfortunately, with this approach, there would still be filler bytes at the end of the memory segment that could not be overwritten by a section. That's why I decided for my approach, which I specified before. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ ---------------------------------------------------------------------- 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 Sep 13 21:12:51 2012
This archive was generated by hypermail 2.1.8 : 2012-09-13 21:12:54 CEST