Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Keoni29 on November 25, 2014, 10:37:24 am

Title: Help with axe interrupts
Post by: Keoni29 on November 25, 2014, 10:37:24 am
For some reason interrupts don't work the way they used to (or I am just being stupid)
This code is supposed to increment a number on screen once every second, but it doesn't. It just increments T once and then never does the ISR again. Why is that?
Code: [Select]
.ISR fnInt(msc, 6)
0->T
FnOn
ClrHome
Repeat  getkey(15)
 Output(8,0,T/108>Dec
End
LnReg
Return

Lbl MSC
T++
Return
Title: Re: Help with axe interrupts
Post by: Runer112 on November 25, 2014, 11:29:13 am
For some reason interrupts don't work the way they used to (or I am just being stupid)
This code is supposed to increment a number on screen once every second, but it doesn't. It just increments T once and then never does the ISR again. Why is that?
Code: [Select]
.ISR fnInt(msc, 6)
0->T
FnOn
ClrHome
Repeat  getkey(15)
 Output(8,0,T/108>Dec
End
LnReg
Return

Lbl MSC
T++
Return

It seems that B_CALL(_DispHL), which is what Axe translates homescreen ▶Dec printing commands into, disables interrupts. You can turn them back on with FnOn, and I think that if you do this, B_CALL(_DispHL) is fast enough that no interrupts should be swallowed up while they're disabled for its duration.
Title: Re: Help with axe interrupts
Post by: Sorunome on November 25, 2014, 03:50:48 pm
And a 'Stop' before your Output command would decrease the possiblility of the interrupt supposivley triggering then.
Title: Re: Help with axe interrupts
Post by: Keoni29 on November 26, 2014, 03:44:28 am
I just got rid of the output altogether. This was a test program to check why interrupts were not working. In my soundplayer program I had a frame counter displayed on screen which was giving me these issues. I got rid of it and now it works great!
Title: Re: Help with axe interrupts
Post by: Keoni29 on November 29, 2014, 04:26:29 am
I might have found a bug. I'm just gonna put this here:
When interrupts are enabled in my game Hero Core a file called tableSet gets corrupted. When I select the option tableset on my calculator it gives me a memory error. It also prevents me from using backup files in tilem.

To make sure it was not my own code that was causing this I changed the ISR to this:
Lbl MSC
Return

To call it I use fnInt(MSC,6)
At the end of the program I do LnReg.
Both of these are inside of a subroutine. (first one called INMSC, second one STMSC)

I am using the fullrene axiom to be able to run the large 12k executable from ram. I have no idea why this kind of memory leak occurs.
Title: Re: Help with axe interrupts
Post by: Sorunome on November 29, 2014, 04:59:01 am
Do you use L2 as a screen buffer?
Title: Re: Help with axe interrupts
Post by: Keoni29 on November 29, 2014, 05:11:11 am
Do you use L2 as a screen buffer?
I do use L2 for the back buffer.
Title: Re: Help with axe interrupts
Post by: Sorunome on November 29, 2014, 05:12:27 am
Try to use a different ram area and check if that'll still happen.
Title: Re: Help with axe interrupts
Post by: Keoni29 on November 29, 2014, 05:26:11 am
Try to use a different ram area and check if that'll still happen.
No actually it's L3 that is used for the back buffer. I am not using L2
Title: Re: Help with axe interrupts
Post by: Runer112 on November 29, 2014, 02:23:30 pm
For 1.2.1, a few people wanted me to try to find a place for interrupt data other than L2 because they wanted to have that space available in their programs that used custom interrupts. Basically all of the viable side-effect-free RAM was already in use, so I had to settle for something with as minor of a side effect as I could find. That ended up being 9200h, part of which stores some sort of data about tables (I'm not exactly sure what).

Anyways, when I made this change, I was aware it would screw up table stuff. To try to remedy this, I added the LnRegr (http://axe.eeems.ca/Commands.html#interruptsCommands) command, which theoretically restores the important table data that got clobbered by the interrupt code. Get the table data back in a valid state (possibly via a RAM reset), try using this instead of the plain LnReg, and tell me if it that works.
Title: Re: Help with axe interrupts
Post by: Keoni29 on December 01, 2014, 01:43:49 pm
The good news is that the table bit is no longer corrupted. The bad news is that everything is spazzing out all of the sudden. The ISR affects all kinds of letter variables now O.O
These variables are not used inside the routine by the way.
Title: Re: Help with axe interrupts
Post by: Runer112 on December 01, 2014, 01:59:18 pm
I can't think of any reason why Axe's interrupts would mess with the letter variables, at least in their default location. I just double-checked to make sure I didn't do anything really stupid, and I think I can confirm that no Axe routine or RAM location overlaps with the default location of the letter variables, at least since they were moved out of L1 (saveSScreen) in 1.2.0. Do you use any parts of static RAM not "sanctioned" by Axe, e.g. not L1-L6?

For reference, the letter variables were moved to $9D2F for 1.2.0 and 1.2.1, and were moved again to smallEditRam ($90D3) for 1.2.2. Also, the changes to interrupt code in 1.2.1 made it use $8624-$86A4 and $9200-$9301.
Title: Re: Help with axe interrupts
Post by: Keoni29 on December 01, 2014, 02:05:38 pm
I am only using L1 and GDB's for the rest.
Title: Re: Help with axe interrupts
Post by: Runer112 on December 01, 2014, 02:12:20 pm
Hmm, I guess I'm out of easy solution ideas then. Do you think you'd be capable of debugging the issue at the assembly level in an emulator? If not, are you able to post either the source or compiled code and tell me how to reproduce the issue so I could try it?
Title: Re: Help with axe interrupts
Post by: Keoni29 on December 01, 2014, 02:37:07 pm
Adding a Return at the end of the source file solved the problem. It has something to do with fullrene.