Re: [cc65] o65 generation bug?

From: "Agent Friday"; on Thursday, May 17, 2012; at 08:38 PM -0400
>
> On Thu, May 17, 2012 at 9:15 AM, Greg King wrote:
> > > 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.
> >
> > 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.
>
> *sigh* I'm already not a big fan of having a different cfg file for
> every single target I build, let alone multiple.  I don't know if
> that's the expectation, but it's how it always ends up for me.  If I
> could specify everything needed to correctly build a target, I don't
> think I'd mind so much, but I don't think that's possible.

This trick might be useful to you; change the MEMORY section to this:
MEMORY {
  HEADER: start = $0000, size = 2,     file="tools", type = ro;
  HIRAM:  start = $CC00, size = $0400, file=%O;
  STUB:   start = $FFFF, size = 0,     file="tools.o65";
}

Then, the command-line's "-o" option can choose the output format.
When you use "-o tools", you will get a ready-to-run binary.
When you use "-o tools.o65", you will get two files: a stub file,
"tools", that you can delete, and an O65 file, "tools.o65".  (The
"STUB:" line is needed because ld65 wants the MEMORY section to name
every file that the FILES section names -- even when we don't generate
those files.)

>
> > > 2.  Are the __segment_LOAD__ symbols still supposed to work?
> >
> > 2. The output format has no effect on the "define=" attribute.
>
> OK, looks like there's a problem then.  I have not yet been able to
> get a segment load-address correctly into my code if I output to
> o65.

I apologize; I was half wrong.  I had forgotten about a bug in ld65.  It
uses $0000 in O65 files instead of the actual values of linker-generated
labels (the SIZE expressions are used correctly).

In my LUnix code, the zerobss subroutine failed because __BSS_RUN__ was
wrong.  So, I used a work-around:  I added a BSSRUN segment between DATA
and BSS.  I defined and exported "__BSS_RUN__:" from that segment.  (The
linker warned about a duplicate symbol; but, the trick worked.  zerobss
got the proper address.)

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