Hello Uz, * On Fri, Sep 14, 2012 at 02:12:12PM +0200 Ullrich von Bassewitz wrote: > 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? Because that's exactly what I want to achieve: Change the filler bytes between two segments, because these are "wrong" (i.e., not conforming to the original ROM). My only other solution to this would be to split the memory sections into two, each with different filer. > > 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. No, it will not change the length, only the filler byte between them. Perhaps my wording was misleading? With "count", I did not mean to add exact filler bytes. I only wanted to say the filler bytes at the end of a segment _get_ the defined fillval of that segment. > 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. How can I change the value of this "something else" without defining a second memory section? 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 Fri Sep 14 20:51:02 2012
This archive was generated by hypermail 2.1.8 : 2012-09-14 20:51:06 CEST