Re: [cc65] Romable configuration / run-time library?

From: Darryl Sokoloski <darryl1sokoloski.ca>
Date: 2013-01-18 22:39:06
Uz, Oliver,

Thanks for the help!

> The code above copies up to 255 bytes. Maybe you want to check your
> map file if the DATA segment is already larger than 255 bytes...

The size of my DATA segment is $8F.  I know my copy code will only
copy up to 256 bytes, but I didn't worry about that yet as I'm still
under that limit.  Here is the finalized segment values:

Name                   Start     End    Size  Align
----------------------------------------------------
ZEROPAGE              000055  00006E  00001A  00001
DATA                  00040D  00049B  00008F  00001
ZPSAVE                00049C  0004B5  00001A  00001
BSS                   0004B6  0004E4  00002F  00001
INIT                  00B000  00B02E  00002F  00001
CODE                  00B02F  00B821  0007F3  00001
RODATA                00B822  00C020  0007FF  00001
STARTUP               00D3B6  00D432  00007D  00001

> * The startup module contains code to chain the kernal IRQ handler. Are you
>   sure this works with your setup? It might be better to remove that code
>   until you need it.

I have yet to implement any IRQ handling and I have stepped through
the startup segment to verify that the NoIRQ label is hit, which calls
initlib.  Maybe I will remove all of IRQ chaining stuff just to be
sure.

> * How about the zero page? You just define it as starting from $00. Are you
>   sure, that the first 26 bytes can be used by the runtime?

This was my ignorance of the architecture I suppose.  I read about
zeropage a bit and as the name implies, discovered it should be the
first page.  This is why I have chosen $00.  Since my last email, I
have editing my LD configuration, restoring the default addresses for
ZP and RAM from pet.cfg.  My memory map now looks like this:

MEMORY {
    ZP:         file = "", start = $0055, size = $001A, define = yes;
    RAM:        file = "", start = $040D,
                size = $8000 - __STACKSIZE__ - 100;
    ROM:        file = %O, start = $B000, size = $23B6, fill = yes;
    STARTUP:    file = %O, start = $D3B6, size = $0C4A, fill = yes;
}

Unfortunately, this made no difference.

>  The zero page locations used
>  by the runtime should be choosen so that they don't interfere with other
>  code that might be running (the kernal for example).

I'm not sure how to do that.  Should using $1A as above leave enough
space for the kernal and it's IRQ handlers?  Is there a method I can
follow to determine what that value should be?

I have indeed checked the address of cprintf (I'm using labels
generated via -Ln) and through the monitor, I can follow the execution
path from my code all the way through:

cprintf -> _vcprintf -> __printf

From there, the routine eventually call .CallOutFunc, which makes
another jump, but this time in to uninitialized space:

.C:0491   .CallOutFunc:
.C:0491   4C 78 9A   JMP $9A78

(C:$04bb) d $9A78
.C:9a78   9A         TXS

It's like the stack is corrupt, or some internal library state is has
gone awry...  I'll keep at it.  Please share any opinions or ideas,
things I should be checking.  I appreciate any and all feedback!

Cheers,

Darryl
----------------------------------------------------------------------
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, 18 Jan 2013 16:39:06 -0500

This archive was generated by hypermail 2.1.8 : 2013-01-18 22:39:28 CET