[cc65] o65 generation bug?

I'm beginning to use .o65 format for a set of runtime APIs for the C64.  Up
until now I've done relocation by bundling a relocation routine with my
code and the relocation data from the .o65 file, and have ignored things
that did not make sense.  I guess it's time to hunt those down now...

Here are the relevant portions of my source...

>> Command-line <<
> cl65 -t c64 -C tools.cfg animator.asm

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

SEGMENTS
{
   LDADDR:   load = HEADER, type = ro,  define = no;
   CODE:     load = HIRAM,  type = ro,  define = yes;
   DATA:     load = HIRAM, type = rw;
   BSS:      load = HIRAM, type = bss, define = yes;
}


FILES
{
   "tools.o65":  format=o65;
}

>> ANIMATOR.ASM <<

.IMPORT __CODE_LOAD__

.SEGMENT "LDADDR"
.WORD __CODE_LOAD__

.CODE
JMP INIT_ANI
JMP LAUNCH_ANI
JMP KILL_ANI
JMP SERVICE_ALARMS
JMP SERVICE_ANI

<snip>

Here is a hexdump of the beginning of the .o65 generated, with issues
highlighted:

0000 01 00 6F 36 35 00 00 08
0008 00 00 25 03 23 CF 06 00
0010 29 CF 1B 00 00 00 00 00
0018 00 00 0F 02 6C 64 36 35
0020 20 56 32 2E 31 33 2E 32
0028 00 1B 04 53 75 6E 20 4D
0030 61 79 20 31 33 20 32 31
0038 3A 33 37 3A 33 37 20 32
0040 30 31 32 00 00 00 00 4C
0048 0F CC 4C 3B CC 4C 20 CD
0050 4C C5 CC 4C 2A CD A9 00
0058 A0 7F 99 80 CF 88 10 FA

Referring to file offsets:

  08..09 : 00 00 -- This is the text base.  I guess 0 makes as much
sense as anything if the code is relocatable, but then....
  0C..0D : 23 CF -- .... why do the dbase and bbase values appear
to based on the HIRAM location in my .cfg?

  0A..0D : 25 03 23 CF -- If the above is just a glitch, and the
code is really compiled to $CC00, then these bytes seem amiss.  If
the code size is really 0325, then the data should start at
CC00 + 0325 = CF25.  Why is dbase CF23 instead?

I guess in the simplified format, anything beyond tbase are of
little consequence, but...

  45..46 : 00 00 -- These are presumably generated by my LDADDR
segment, which was there for generating ready-to-run targets.  Does
ld65 not strip out extraneous segments?  In any case, the zeroes
seem to imply that __CODE_LOAD__ really WAS 0000... ?

  47..56 : 4C 0F CC 4C 3B CC 4C 20 CD 4C C5 CC 4C 2A CD ...
My jump table has 5 entries, occupying 15 bytes.  The JMP targets
clearly seem to be generated as if the code were in fact assembled
to $CC00.  (The first target is CC0F, directly after the jump table.)

I'll try commenting out the LDADDR segment entry.



-- 
// Agent Friday

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