I had to double check on the scope of constant strings - I was wrong and you are right that they should be global and statically allocated.
I also agree that both constant character strings are statically allocated in the assembly code, so that part seems to be working OK. The part I'm still having issue with is that the pointer being declared has type "unsigned char *" while the constant string has type "const unsigned char *". The extra const in there allows/disallows certain optimizations. Further looking at the generated assembly makes me think this isn't the issue causing this problem, though.

The ldaxysp function being run just before the second _lcdPrint looks to me like the compiler is trying to load A and X (which we can see hold the string pointer by looking at the working call to _lcdPrint) based on Y and the stack pointer, and Y was just loaded with 1 prior to that. That looks like the compiler is trying to get that pointer from the stack (which makes sense, as the pointer in main is a local variable).

The local variables should be initialized right at the start of main, and it looks like, indeed, the address of L0004 is being pushed onto the stack right at the beginning.

I think leepivonka has the correct answer - the data stack is not being allocated to RAM properly. I believe cc65 uses a data stack that is separate from the return stack, so it's possible for the jsr/rts to work properly but the local variables to not work properly. Can you (echidna) share the cc65 config file (and a description of your memory map for your computer)?

That can be easily tested by commenting out the first call to _lcdPrint...

Divide and conquer.

The CC65 documentation has detail on how to make a configuration for custom hardware: https://cc65.github.io/doc/customizing.html
There are also many supplied configurations for various systems.

When you run CC65, the "target" parameter picks the configuration to use.

Source files for all of this, and the library routines like ldaxysp is available in the CC65 distribution at http://cc65.github.io .


Since the 6502's return stack is limited to 256 bytes, CC65 maintains another software stack to keep procedure local data on.
There are many library routines like pushax, ldaxysp, & incsp2 to operate on this stack.

I presume that's not a standard configuration. I also presume that you're attempting to run a CMOS 6502 binary on NMOS 6502.

Actually, we should start with the "digital thermometer" test. I don't care where you bought a 6502 or what it has on the label. Stick you finger ("digit") on the middle of your 6502. If it is noticeably warm then it is NMOS 6502. This lacks one addressing mode and a short, unconditional branch. When running unoptimized C, branch will be ignored. The result is that for loops and while loops may fail to iterate and else blocks may execute unconditionally. When optimized C has unrolled loops, the first byte of a string may be pre-loaded but the remainder is not fetched. This is very much like the symptoms you observe.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!