[TI ASM] REALLY Weird Bug
Moderator: MaxCoderz Staff
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
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.
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.
- L4E_WakaMol-King
- Maxcoderz Staff
- Posts: 342
- Joined: Tue 01 Nov, 2005 6:34 am
- benryves
- Maxcoderz Staff
- Posts: 3087
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
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.Dwedit wrote:The data is at the end, so the 8.8k code limit is not a problem.
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.benryves wrote: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.Dwedit wrote:The data is at the end, so the 8.8k code limit is not a problem.
Last edited by CompWiz on Thu 01 Jun, 2006 7:45 pm, edited 1 time in total.
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
F*cking viral marketing...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.
I couldn't recreate the problem, Could you perhaps include the missing file?Neither fix the problem .
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"?
- L4E_WakaMol-King
- Maxcoderz Staff
- Posts: 342
- Joined: Tue 01 Nov, 2005 6:34 am
Sorry, that was my mistake -_-Jim e wrote:I couldn't recreate the problem, Could you perhaps include the missing file?Neither fix the problem .
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.
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.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."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.Code: Select all
ld a,0 ld (BOB_CASTING),a
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.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.Code: Select all
ld a,0 ld (BOB_TALKING),a
Taking that into consideration, I changed the line of code in the start of the program to read:Still freezes.Code: Select all
ld a,205 la (BOB_CASTING),a
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.
Also, see the comments in loom.z80 for a second description of the bug.
(See above... "freezing" = the getkey-like loop.)Jim e wrote:What needs to happen for it to enter the "freeze"?
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:Also are you debugging on hardware or emulator?
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:Did you try dwedits fix?
N/a since I couldn't assemble loom.z80 after the fix.Jim e wrote:If so, Did its still give getkeys despite getkeys not being present in your code?
(See above.)Jim e wrote:Last, what do you mean "loop of getkeys"?
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 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'm a rookie asm programmer. It's probably because I only sort of know what I am doing. -_-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.
- Now Under Development - [Progress]
-
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact:
Yup. We poor souls have nothing betterCompWiz wrote:I don't think Ion is very widely used at all, except maybe on 83(not +) calcs.
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- L4E_WakaMol-King
- Maxcoderz Staff
- Posts: 342
- Joined: Tue 01 Nov, 2005 6:34 am
I'm going to try to get Loom working in PTi and see if that helps.
- Now Under Development - [Progress]
Ah, yes, forgot about that oneCoBB wrote:Blasphemy! Venus says nothing to you?! It's vastly superior to all those fancy 83+ shells.Timendus wrote:Yup. We poor souls have nothing better
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS