Re: [cc65] o65 generation bug?

From: "Agent Friday"; on Monday, May 14, 2012; at 06:19 AM -0400
>
> 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 that by specifying something on the command-line, but I
> haven't looked too deep into the possibilities.
>
> 2.  Are the __segment_LOAD__ symbols supposed to still work?

1. You can tell ld65 to drop a memory area by giving that area an empty
file-name:

MEMORY {
   HEADER: start = $0000, size = $02,   type = ro, file="";
   HIRAM:  start = $CC00, size = $0400, type = rw, file="tools.o65";
}

You can make two configuration files, one that writes HEADER, and one
that doesn't.  Then, your command-lines choose which cfg. file to give
to ld65.

2. The output format has no effect on the "define=" attribute.

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.