[TI ASM] REALLY Weird Bug

Post by **L4E_WakaMol-King** » Wed 31 May, 2006 12:24 am

I don't even know how to describe this one. This is in my Loom game.

In its current state, the game works fine.

If I add in a line of code at the beginning of the game to modify one particular memory address (a variable), the game "freezes."

Code: Select all

ld a,0
ld (BOB_CASTING),a

And by freezes, I don't actually mean freezes... it goes into some kind of strange pause mode and only works if I continually press any key.

If I replace that line of code with one that modifies any other memory address (a different variable, for example), the outcome is the same... still freezes the game when you run it.

Code: Select all

ld a,0
ld (BOB_TALKING),a

So, I wrote a piece of code so that every time I press ALPHA, the value of that memory address (BOB_CASTING) is displayed. The value is 205 as long as I don't modify it at the start of the program like I am trying to do.

Taking that into consideration, I changed the line of code in the start of the program to read:

Code: Select all

ld a,205
la (BOB_CASTING),a

Still freezes.

If I write a piece of code to modify that variable somewhere else in the game (on ALPHA keypress, for example), the game works just fine, even after (BOB_CASTING) is set to 0.

I have checked and re-checked to make sure that no variables are overwriting one another. That's not the problem.

I have also checked every one of my bcall(_getkey) statements, since the "freezing" seems to be stuck in some kind of getkey loop. None of them even get accessed until certain keys are pressed... so I don't think that is the problem either.

Does anyone have any idea what is going on? I am totally confused.

Anyone interested in helping, please IM me. If you can't figure out the problem from the description, I will be glad to send you the source code.

MSN: L4E_wakamolking@hotmail.com
AIM: TheMaskedTortuga

Post by **benryves** » Wed 31 May, 2006 11:26 am

I'd need to see the source code, or (more likely) see the addresses of BOB_*
If this is in MirageOS, it could be that you're overwriting the interrupt handler (tasker) or some other part of MOS that loads itself into RAM - try sticking "im 1" as the first instruction of your program.

Post by **L4E_WakaMol-King** » Wed 31 May, 2006 3:32 pm

It's for ION. And I've tried changing the memory address for BOB_CASTING... no effect :S.

thegamefreak0134 · Post by **thegamefreak0134** » Wed 31 May, 2006 3:36 pm

Do you ever modify it somewhere else? (like is it used later in the game?) It sounds to me like perhaps you've got something already at those lcoations. (that would explain it always being 205 and not something random.) Course, we really do need source to be sure.

CoBB · Post by **CoBB** » Wed 31 May, 2006 4:02 pm

Does it also happen if you put six NOPs instead of those two instructions? Perhaps with a different amount?

Post by **kv83** » Wed 31 May, 2006 4:11 pm

source would be handy here.

you can do xor a instead of ld a,0 btw. saves some space

(1bit?)

Post by **benryves** » Wed 31 May, 2006 4:13 pm

Destroys the flags, though

Jim e · Post by **Jim e** » Wed 31 May, 2006 4:55 pm

What is with this idle guessing?? This is ridiculous. It's like phoning your doctor and telling him you have a cough(when your likely not noticing other symptoms), you can't expect him to give the right medicine on just that.

Post by **L4E_WakaMol-King** » Wed 31 May, 2006 10:27 pm

Ok, here it is. I know it's probably not well optomized... keep in mind it's still very much in testing phase right now.

I put big comments around the problematic line of code. Thanks to anyone who can help!

http://l4eclan.com/loom/loom.z80

Post by **Dwedit** » Thu 01 Jun, 2006 1:49 am

For one thing, you are doing something REALLY Bad by equating everything to a fixed address, you should use labels as your base. Like appbackupscreen + 0. Using absolute addresses like that prevents porting, even to the regular TI83.

Also, you're doing the return address thing wrong. You should save the STACK POINTER, not the value at there. Otherwise the stack will move if the program quits out of the usual place, messing up when the program returns to a shell.
Do it like this:

Code: Select all

 ld (some_stack_save_address),sp
...
quit:
  ld sp,(some_stack_save_address)
  ret

then jp quit to quit the program.
*edit: on a second look, you compared each stack value to the shell's return address. Might work, but you could get unlucky if the game produces an identical value on the stack. Saving the stack pointer is guaranteed to work correctly.

I'd recommend you don't use _getkey, use a halt + _getcsc loop instead.

Code: Select all

waitkey:
 ei
 halt
 bcall(_getcsc)
 or a
 ret nz
 jr waitkey

I think that ALPHA is incompatible with _getkey in the first place, since _getkey is TIOS style input, and 2nd and Alpha are shift keys for it.

Oh yeah, and you also have an incorrect header, should be $BB, $6D, not $BB, 6D. That turns into BB 06 instead of BB 6D, since D is an assembler suffix for decimal. MirageOS will fail to detect a program with an incorrect header.

Andy_J · Post by **Andy_J** » Thu 01 Jun, 2006 3:12 am

L4E_WakaMol-King wrote:It's for ION

The MirageOS tasker will still be enabled if it is used to run the program. If you tromp over it, you still need to im 1.

Post by **L4E_WakaMol-King** » Thu 01 Jun, 2006 3:49 am

Thanks for the input, but did you figure out what the bug is doing? That's my main concern. I'm going to worry about optomizations later.

I'll try using relative addresses and see if that makes any difference.

Edit: Now I'm getting a ton of Forward Reference errors... for some reason TIASM doesn't want to recognize appBackupScreen. Any ideas? (But I'm still more interested in the solution to the bug.)

threefingeredguy · Post by **threefingeredguy** » Thu 01 Jun, 2006 7:38 am

Are including a file/defining something at the end even though you use it before it is defined/included? Plus make sure you have a good include file, ti83plus.inc can be a little crazy.

Post by **L4E_WakaMol-King** » Thu 01 Jun, 2006 7:53 am

I'm using ion.inc... and I include it before any of those lines are assembled.

threefingeredguy · Post by **threefingeredguy** » Thu 01 Jun, 2006 8:03 am

What happens if you write an instruction of the samesize there? What happens if you change the address of (BOB_CASTING)? Why am I too lazy to try those myself?