Hi! On Thu, Sep 13, 2012 at 09:12:26PM +0200, Spiro Trikaliotis wrote: > 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. I don't know if this requirement is necessary. Why do you think anything should be controlled by the attributes in the segments? > 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. This leads to the situation where changing attributes for one segment will change the length of another segment. Which I think is highly unintuitive. > 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. So what is the problem if that cannot be done? Having the space between the segments not assigned to a segment, but just being "something else" that is part of the memory area seems more logical to me. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri Sep 14 14:12:24 2012
This archive was generated by hypermail 2.1.8 : 2012-09-14 14:12:27 CEST