The simplest things - CC65

[GadgetUK]

It's been a long time since i played around with C - around 10 years infact... I've found that some of the simplest things can be a challenge (well, for me at least!).

 

Just trying to maintain a score > 32767 seems awkward at the moment. It seems that an int is 8 bit on this platform - is that correct? And a long is 16 bits, strangely enough even if I declare the score as an unsigned long it still only seems to hold +/-32767. I can dig around for ideas on how to get around this on the net but just wanted to float this past in case I am missing something simple.

 

The other oddity that I dont remember from when I used C years ago is that you seem to need to declare variables at the start of a procedure or function - you can't just declare one anywhere in the procedure? Is this just me going crackers here or what? I found the compiler goes mental if for example I declare:- int loop = 0; after ive already done some other assignment type code or anything other than declaration of variables previous to the entry.

[+karri]

You can declare an int as this:

 

unsigned int a;

 

Then "a" can be 0..65535

 

You can also declare a byte as

 

unsigned char a;

 

In this case "a" van be 0..255

 

If you need more you can use

 

unsigned long a;

 

Now "a" can be 0..4294967295

 

The int of a Lynx is 16 bits.

 

If you want to have negative numbers then use "signed" instead of "unsigned".

 

 

You can also declare variables in several places:

 

char b=5;

 

void main() {

}

 

In this case the variable b is assigned outside the program and it reserves memory from the DATA segment.

 

void main() {

char b = 5;

}

 

Now b is initialized inside the program and resides on the stack in the BSS segment,

 

void main() {

if (1 > 0) {

char b = 6;

}

}

 

Now b is not defined outside the if-statement.

[+karri]

If you need to convert large values to ascii for printout there are some nice functions available:

 

stdlib.h:char* __fastcall__ ltoa (long val, char* buf, int radix);

stdlib.h:char* __fastcall__ ultoa (unsigned long val, char* buf, int radix);

 

Or the other way around:

 

stdlib.h:long __fastcall__ atol (const char* s);

stdlib.h:long __fastcall__ strtol (const char* nptr, char** endptr, int base);

stdlib.h:unsigned long __fastcall__ strtoul (const char* nptr, char** endptr, int base);

Edited December 3, 2012 by karri

[GadgetUK]

I think my first problem was using itoa to convert long to ascii, seems to wrap at > 32767 even when using unsigned long.

 

The declaration problem is very odd - I will post examples later because it sounds like it should work but it doesnt. Heres an example of what doesnt work:-

 

tgi_clear();

 

int loop = 0;

 

while (loop < 7)

{

....

}

 

Compiler complains about 'expected statement at line' pointing to loop declaration.

 

If the declaration is moved above the tgi_clear, it works.

Edited December 3, 2012 by GadgetUK

[GroovyBee]

The CC65 compiler isn't fully C99 compliant so you can't declare variables like that.

[GadgetUK]

The CC65 compiler isn't fully C99 compliant so you can't declare variables like that.

 

Thanks! So I am not going mad lol!! Ive looked at it many times trying to understand whats wrong with the code and finally I know its not me lol

[GadgetUK]

If you need to convert large values to ascii for printout there are some nice functions available:

 

stdlib.h:char* __fastcall__ ltoa (long val, char* buf, int radix);

stdlib.h:char* __fastcall__ ultoa (unsigned long val, char* buf, int radix);

 

Or the other way around:

 

stdlib.h:long __fastcall__ atol (const char* s);

stdlib.h:long __fastcall__ strtol (const char* nptr, char** endptr, int base);

stdlib.h:unsigned long __fastcall__ strtoul (const char* nptr, char** endptr, int base);

 

 

Thanks! The problem with the integer wrapping at the 32k mark was me trying to use itoa with a long, I can confirm ultoa works fine! Some of these are new functions to me, I miss printf =(

[Shawn Jefferson]

Read this page for some pointers on helping the compiler produce the best code:

http://www.cc65.org/doc/coding.html

 

Also you can generate asm listings at compile time, so you "check" what the compiler is doing. I also find that downloading the library source is useful if you want to know what a particular function actually does and why it works the way it does.

Edited December 4, 2012 by Shawn Jefferson

[GadgetUK]

Read this page for some pointers on helping the compiler produce the best code:

http://www.cc65.org/doc/coding.html

 

Also you can generate asm listings at compile time, so you "check" what the compiler is doing. I also find that downloading the library source is useful if you want to know what a particular function actually does and why it works the way it does.

 

Thanks, those are very useful!