Problem in OSDK?

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

Post Reply
User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Problem in OSDK?

Post by barnsey123 » Fri Dec 30, 2011 1:02 pm

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!

JamesD
Flight Lieutenant
Posts: 352
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD » Fri Dec 30, 2011 5:03 pm

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; 

highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman » Fri Dec 30, 2011 5:32 pm

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"

User avatar
Dbug
Site Admin
Posts: 2322
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Fri Dec 30, 2011 6:50 pm

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.

User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Post by barnsey123 » Mon Jan 02, 2012 10:31 am

@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... :(

User avatar
Dbug
Site Admin
Posts: 2322
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Wed Jan 04, 2012 9:25 pm

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.

User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Post by barnsey123 » Thu Jan 05, 2012 6:43 pm

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! :?

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest