Hello!
First post here so I hope I'm doing things correctly..
I have the Ben Eater 6502 project done... mostly.
I'm using the cc65 tools and have managed to get printing to my LCD working.. sort of.
It handles printing a globally declared char string, but gets super weird printing a locally declared string.
I would expect the ','s to print, followed by the '!'s. Instead I get the ','s then garbage.
Any insight into what I'm doing wrong or misunderstanding about how all of this works would be greatly appreciated.

The following is my c code and then the generated assembly:

Welcome!

What happens if you print from c first and then from command?

Is the CC65 environment configuration appropriate for your system?
Are you running the CC65 environment initialization routine before calling main?

The global string pointer is defined globally. It doesn't use the CC65 local stack.
The local string pointer is defined on the CC65 local stack.

The CC65 local stack needs to be allocated in RAM . The zero-page pointer to the current location in it needs to be initialized & not overwritten.

RAM & Zero-page space allocations are specified in the CC65 environment configuration.
If you aren't already familiar with this, look at the sample .cfg files (none, apple2, etc) supplied with CC65.

I believe this info is correct, but I won't claim to be an expert on it.

Well, the nice thing about having the generated assembly is that you can play with it to see if it does what you expect.

You can change this:



to this:



....and see if that changes anything. If it does, that might give you a clue as to where things might be going wrong.

I'm assuming the compiler is doing what it does because of the initial assignment to the variable 'c'. That and not performing enough analysis to see that it doesn't have to do that first (or at all, really).

I wonder what it would do if you made the assignment closer to the point of actual use. Or used a string constant in the call instead of a variable. You might try replacing both variables with string constants to see what happens.

What happens when main returns? Just to be sure nothing weird is happening after that, you could try putting while(1); before return (0);. Also, no need to put parentheses around the value in a return statement.

Oh man, I've tried so many combinations that I honestly can't be sure, but I *think* it prints garbage then the good stuff

This sounds right. I'm SURE my config is wonky. I had a feeling this was the road I was about to go down. Perhaps trying to learn assembly AND the learn intricacies of the CC65 tools is too big of a bite.

excellent suggestion, I'll try it out.

same results with or without an infinite loop.
Please forgive my C styling, 20 years of Java coding shows, huh?

What’s the handleinterrupt function doing?

Normally, an irq or brk would return with an rti not rts.

Cheers,
Andy

It's cruft, I was lazy, but thanks for the rti vs rts.

[quote="echidna"]Hello!

Your C code has some issues. The biggest issue is that you never actually allocate the memory for your strings. While you can get away with that (to some extent) in the global scope, you can't inside the function. Try the following change:

If cc65 doesn't like the empty []s, put one larger than the number of characters in your string (so there will be room for the null character on the end of the string, which the compiler will only add if there is room).
If you only want the strings to live in ROM, you can toss a "const" keyword in front of those declarations.

What you had before was only declaring pointers to character and then you pointed them to a constant string. The issue is that the constant string is an unnamed "temporary" value that only needs to be valid while the line is being evaluated. When you get into a local scope (eg. inside a function), these temporary values are often placed on the stack. This means your string of !s is placed on the stack and then that address is placed into the pointer. Once the code moves on to the next line, the compiler is not required to keep those temporary !s in memory. and the stack may be overwritten (especially with jsr instructions in the mix). The constant strings only needed to be there long enough for the assignment into the c pointer to take place.

It's a little more complicated than that, as the optimizer is optimizing away some of the operations, but the main point here is you actually need to store those strings in a variable (or constant) to have them guaranteed to still be around later. Changing your declarations to be an array of chars will guarantee the value exists beyond that one line of code.

You got lucky on the global scope because the compiler handles global variables a little differently and it "happened to work", but you should change that declaration as well.

Thank you. This makes tons of sense.

That is not true.

In general cases, a string constant (anything between double quotes) is statically allocated (clearly visible in the assembly code as well ...), i.e. it exists for the entire program run, and its type is either 'const char*' or 'char*' (depending on the implementation). There is no need here to copy it by value.

My first guess would be that something in _lcdPrint corrupts the stack (and therefore the pointer to the string of plings, which is stacked at the time).