[TI ASM] REALLY Weird Bug

Jim e · Post by **Jim e** » Thu 01 Jun, 2006 8:10 am

appBackupScreen = $9872

anyway, I tried debugging it but I can't recreate the problem. Either the problem requires that loom data file present or there is some thing else that I am missing.

The only instance I see a getkey even occurring in game is in spell casting and I don't see any references to it. Am I looking at a modified work around?

I did notice though that your file is approaching the 8.8k mark, Right now there is only about 768 bytes till you hit $c000. The problem there is that ion can't execute code if it is beyond that mark.

I see a lot of odd stack use and and for some reason a lack of push af? is there a reason you don't want to save the flag register so often.

Any way if it is a getkey, that happens to be rather hazardous itself. it's not a smart routine. It monitors certain blocks of memory for change but if that doesn't occur then it will wait indefinitely. The only way memory will change is if the interrupts are enabled and regular ti code gets executed. In other words getkey sux.

NanoWar · Post by **NanoWar** » Thu 01 Jun, 2006 12:42 pm

You can make Loom an application, like MirageOS, Zelda or Wizards.
Then you'd have more space and I think your game will need that (I dont know how well RLE works).

Post by **Dwedit** » Thu 01 Jun, 2006 5:17 pm

The data is at the end, so the 8.8k code limit is not a problem.

Post by **L4E_WakaMol-King** » Thu 01 Jun, 2006 5:37 pm

Neither fix the problem

.

Post by **benryves** » Thu 01 Jun, 2006 5:42 pm

Dwedit wrote:The data is at the end, so the 8.8k code limit is not a problem.

Regardless, Ion copies itself (or rather, the Ion libraries/functions) at the end of your program, so if your entire program is > 8.8K and you call an Ion function, you're trying to run something past that limit. This only applies to Ion itself, Ion programs in MirageOS don't exhibit this behaviour.

CompWiz · Post by **CompWiz** » Thu 01 Jun, 2006 6:04 pm

benryves wrote:
Dwedit wrote:The data is at the end, so the 8.8k code limit is not a problem.
Regardless, Ion copies itself (or rather, the Ion libraries/functions) at the end of your program, so if your entire program is > 8.8K and you call an Ion function, you're trying to run something past that limit. This only applies to Ion itself, Ion programs in MirageOS don't exhibit this behaviour.

How many people still use Ion anyway? Everyone at my school used to use MirageOS, then I distributed CrunchyOS and everyone switched over. I don't think Ion is very widely used at all, except maybe on 83(not +) calcs.

NanoWar · Post by **NanoWar** » Thu 01 Jun, 2006 7:07 pm

You can also include Ion routines manually.
Then it's Ion, MirageOS and Crunchy compatible.

Jim e · Post by **Jim e** » Thu 01 Jun, 2006 7:20 pm

How many people still use Ion anyway? Everyone at my school used to use MirageOS, then I distributed CrunchOS and everyone switched over. I don't think Ion is very widely used at all, except maybe on 83(not +) calcs.

F*cking viral marketing...

Neither fix the problem .

I couldn't recreate the problem, Could you perhaps include the missing file?

Under what function does this getkey loop occur? I can't even find a link to that. Rather Im seeing other bugs, but not this pausing bug.

What needs to happen for it to enter the "freeze"?

Also are you debugging on hardware or emulator?

Did you try dwedits fix?

If so, Did its still give getkeys despite getkeys not being present in your code?

Last, what do you mean "loop of getkeys"?

CompWiz · Post by **CompWiz** » Thu 01 Jun, 2006 7:47 pm

NanoWar wrote:You can also include Ion routines manually.
Then it's Ion, MirageOS and Crunchy compatible.

If I understand benryves correctly, if you just make a normal Ion program that uses up all the executable space, then it will run fine in Crunchy or MirageOS.

Post by **L4E_WakaMol-King** » Thu 01 Jun, 2006 9:27 pm

Jim e wrote:
Neither fix the problem .
I couldn't recreate the problem, Could you perhaps include the missing file?

Sorry, that was my mistake -_-
http://l4eclan.com/zlomdata.z80
Also, here's my ino.inc just in case...
http://l4eclan.com/loom/ion.inc

Jim e wrote:Under what function does this getkey loop occur? I can't even find a link to that. Rather Im seeing other bugs, but not this pausing bug.

L4E_WakaMol-King wrote: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.

There is no endless getkey loop in my code that I can find... but that is what seems to be be happening because when the game "freezes" you can still run it if you hit any key over and over. The fact that it is caused by a getkey loop is speculation on my part.

Also, see the comments in loom.z80 for a second description of the bug.

Jim e wrote:What needs to happen for it to enter the "freeze"?

(See above... "freezing" = the getkey-like loop.)

Jim e wrote:Also are you debugging on hardware or emulator?

Virtual TI. Even if that is the problem, I really need to get it fixed for the emulator. I need it for testing. This game is way too big for me to test it on my actualy calc every time.

Jim e wrote:Did you try dwedits fix?

The appBackupScreen thing? Yes... and it generated a ton of 'Forward Reference' errors. I know what that means, but since ion.inc is included before any references to appBackupScreen are made, I shouldn't be getting those erros

. The reason that I use appBackupScreen instead of just $9872 is for portability.

Jim e wrote:If so, Did its still give getkeys despite getkeys not being present in your code?

N/a since I couldn't assemble loom.z80 after the fix.

Jim e wrote:Last, what do you mean "loop of getkeys"?

(See above.)

Jim e wrote:I did notice though that your file is approaching the 8.8k mark, Right now there is only about 768 bytes till you hit $c000. The problem there is that ion can't execute code if it is beyond that mark.

This my be my problem. I think the program is either right at or above that limit. If this is the problem, what should I do? I suppose I can port the game to Mirage (even though I wanted it to be ION compatible). What is the easiest way to do that? Should I just copy the ion routines to my code and switch to the Mirage header? I've never programmed for Mirage before, so if anyone can help me out here, please do.

Jim e wrote:I see a lot of odd stack use and and for some reason a lack of push af? is there a reason you don't want to save the flag register so often.

I'm a rookie asm programmer. It's probably because I only sort of know what I am doing. -_-

threefingeredguy · Post by **threefingeredguy** » Thu 01 Jun, 2006 9:57 pm

I wouldn't be suprised if it was VTI's fault, though I can't see how it could be unless the zloomdata is in the archive. VTI doesn't "do" archive, so it will crap out if you try that.

Timendus · Post by **Timendus** » Thu 01 Jun, 2006 10:16 pm

CompWiz wrote:I don't think Ion is very widely used at all, except maybe on 83(not +) calcs.

Yup. We poor souls have nothing better

CoBB · Post by **CoBB** » Thu 01 Jun, 2006 10:19 pm

Timendus wrote:Yup. We poor souls have nothing better

Blasphemy! Venus says nothing to you?!

It's vastly superior to all those fancy 83+ shells.

Post by **L4E_WakaMol-King** » Thu 01 Jun, 2006 10:23 pm

I'm going to try to get Loom working in PTi and see if that helps.

Timendus · Post by **Timendus** » Thu 01 Jun, 2006 10:30 pm

CoBB wrote:
Timendus wrote:Yup. We poor souls have nothing better
Blasphemy! Venus says nothing to you?! It's vastly superior to all those fancy 83+ shells.

Ah, yes, forgot about that one