Page 1 of 1

Problem in OSDK?

Posted: Fri Dec 30, 2011 1:02 pm
by barnsey123
Nice problem to round off 2011...

In the chess game I'm working on I have come across the following problem:

Code: Select all

...
char canbetakenweight=4;	
...
if (target[takerow][takecol]>1){target[takerow][takecol]=canbetakenweight;}  		
//if (target[takerow][takecol]>1){target[takerow][takecol]=4;}  
In the above code (present in main.c on SVN, the "if" is on line 824) I want to make the "target" be the value of the global variable "canbetakenweight" (which is 4)
This does not work unless I EXPLICITLY assign it the value "4" (in the commented line).

Initially, I thought is was to do with mismatched char types (target is UNSIGNED and canbetakenweight is SIGNED but making them the same (unsigned) makes no difference.

By printing out the values of particular target locations (straight after being assigned the value of "canbetakenweight" which should be 4) we get different figures (e.g. 72). This drastically alters the behaviour of the program as "proper" higher value targets sometimes get ignored in favour of these spurious ones.

Anyone got any thoughts? (perhaps it's my coding and NOT the OSDK) but I just can't spot it and it's really slowing me down. :(

Thanks
Barnsey

PS: Happy New Year everyone!

Posted: Fri Dec 30, 2011 5:03 pm
by JamesD
If I remember right, OSDK uses lcc rather than cc65 like the rest of the 6502 world.
It could be a couple things.
How long of variable names does lcc support?
Or it could be a parser issue.

Things to try.
Use shorter names (replace canbetakenweight with CnBTakenWt)
Use more white space (this also helps us read your code)

Code: Select all

if (target[takerow][takecol] > 1)
    target[takerow][takecol] = canbetakenweight; 

Posted: Fri Dec 30, 2011 5:32 pm
by highwayman
bracket-hell.
assembly is much cleaner.

do you have to somehow say that the variable your messing with is global so it doesnt just create a local one with the value of 4?

i know some c/c++ compilers are a bitch in this respect even though i have never used these bastard "languages"

Posted: Fri Dec 30, 2011 6:50 pm
by Dbug
I can try to reproduce the problem when I am back home.
Could you try one thing: Declare the variable as a GLOBAL and check if it still misbehave. If it works then it probably means that there is a another bug in the stack frame handling (do you remember the bug with the function calls corrupting paramters when using printf?)

Conformity wise, lcc65 is pretty good, it behave pretty much like most other compilers used in the real world, so I would not really assume the bug is there.

Another possible candidate would be the macro expansion file that possibly does not generate correct 6502 code for this particular statement.

Posted: Mon Jan 02, 2012 10:31 am
by barnsey123
@JamesD
Hi James, I tried shorter variable names (e.g. cbtweight) but results were the same.

The variable is already defined as global but cannot be a constant as I intend to change it's value dynamically based on the game state. Other global variables seem to work OK and I can see nothing obviously wrong here.

@dbug
Yes, I remember the bug you mention and this is where I've got my money on at the moment. There are other puzzling aspects relating to game behaviour which I suspect may be related to this issue. Exhaustive dry running (using LOTS of paper and pencil) suggests to me that the logic is OK and is doing what I want it to but the reality is different...sometimes... :(

Posted: Wed Jan 04, 2012 9:25 pm
by Dbug
Don't forget that the memory is very scarce on the Oric, you can easily corrupt memory by using too many locals, doing too deep recursions, etc... and these are very hard to track.

Posted: Thu Jan 05, 2012 6:43 pm
by barnsey123
barnsey123 wrote:Exhaustive dry running (using LOTS of paper and pencil) suggests to me that the logic is OK and is doing what I want it to
Er...scratch that...found a big can of worms today.
dbug wrote: you can easily corrupt memory by using too many locals, doing too deep recursions, etc.
Have now removed all local vars and some redundant functions. The program is now getting better AND worse all at the same time! More coffee! :?