Uz, Nice of you to send off a reply at such a time. I removed the LDADDR segment from the code, and that seemed to clear up the discrepancies. (Well, almost.) It appears that some of the calculations rely on the assumption that the code segment will be the first thing specified to go into the file, and if it's not so then things get thrown off. The tbase value of 0000 in the original output probably came directly from the (don't care) start address I specified for the HEADER memory area. Instead of actually removing the .WORD __CODE_LOAD__ directive, I moved it into the DATA segment to see what got generated. LD65 actually generated a text-relative fix-up entry in the data seg relocation table, which is good, but the actual value generated for __CODE_LOAD__ was still 0. That seems odd. Are the "define=yes" settings meant to be rendered invalid by choosing .o65 as the output format? I guess I'm left with a couple of questions now... 1. I'd like some nice way to be able to switch between .o65 and binary file formats w/o having to make temporary edits to my code. It would be nice if I could do this by specifying something on the command-line, but I haven't looked too deep into the possibilities. 2. Are the __segment_LOAD__ I prefer to handle jump tables by placing it in its own "JMPTBL" segment, thus being able to guarantee that the jump table is the first code in the target w/o relying on what order the source files are specified. I tried this out, putting the segment JMPTBL first in the segments section, just before code, and it seemed to work nicely. :-) However, __JMPTBL_LOAD__ also came up 0. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Mon May 14 12:19:21 2012
This archive was generated by hypermail 2.1.8 : 2012-05-14 12:19:26 CEST