By the way, you should take into account that at least in normal speed (6Mhz), the Ti-83+ has more interrupts per second than a Ti-83+ silver edition does.  It's roughly 110 interrupts per second for the Ti-83+ SE, and 120 interrupts per second for the Ti-83+. 

This was only tested on Wabbitemu, so please feel free to correct me.

Could this be why on the 83+SE, most ASM games run slightly slower than on the regular 83+?

So if I set interrupts at a frequency of 6, how many times would it run in a second?  What unit does it mean by '6'?

Unfortunately, it's not as simple as "units."

6 is the binary number 00000110.  Axe uses the 6th and 7th digits of this binary number to set an interrupt speed, because that's just the way the calculator works.  The calculator interrupt speed is set by a two-digit binary number, and Axe takes that number from the 6th and 7th binary digits of the number you specify. 

On a Ti-83+, if you specify a speed in axe of 0, the calculator reads the 6th/7th digits of the binary number 00000000 = 00, and it knows your interrupt routine should be run 560 times a second.  That's just the way the calculator works, it's a predefined interrupt speed.

If you specify a speed in Axe of 2, the calculator reads the 6th/7th digits of the binary number 00000010 = 01, and it knows your routine should be run 248 times a second.

If you specify a speed in Axe of 4, the calculator reads the 6th/7th digits of the binary number 00000100 = 10, and it knows your routine should be run 170 times a second.

If you specify a speed in Axe of 6, the calculator reads the 6th/7th digits of the binary number 00000110 = 11, and it knows your routine should be run 118 times a second.

OH is that how the Mirage speed settings work?

Yes indeed, which is why it doesn't work for all programs.

Also, you are increasing health by 6 each time but checking that it's equal to the max health.  If the current health is 999 and you add 6, that's 1005 which is not equal to 1000 and the health would continue to increase.

Oh, ya, I know. It was just a quick example. Not perfect or anything like that. Just to see if my thought was correct

The following works:

.TEST
ClrDraw
0->A->B->C
fnINT(TIM,6)
While 1
    If getKey(4)
        1+C->C
        Text(0,0,C->DEC)
    End
    If getKey(15)
        Goto END
    End
    If A>=118
        0->A
        1+B->B
        Text(0,10,B->DEC)
    End
End

Lbl TIM
    1+A->A
Return

Lbl END
    FnOff
    LnReg
    ClrDraw

It acts as a timer while allowing me to increment the variable C at whim,
but if I try doing this:

.TEST
ClrDraw
0->A->B->C
fnINT(TIM,6)
While 1
    getKey->D
    If D=4
        1+C->C
        Text(0,0,C->DEC)
    End
    If D=15
        Goto END
    End

...etc.

the getkey doesn't appear to work, or store anything to the variable D.

Meh?  What gives?

(I added indents for clarity)

Yeah, the OS interrupt needs to be on in order to use the BASIC getkey because it has to detect when keys are pressed in the background.  You could tack on your own getkey routine for a few keys to the end of your interrupt if you really need a feature like that.

You can't have more than one interrupt running at once independently meaning an interrupt that interrupts the main code and the other interrupt.  But you can have multiple interrupt routines at once for different frequencies. Lets say you want one interrupt at 110Hz and one at 22Hz.  What you can do is setup a single interrupt at 110Hz (number 6) that increments a timer and when the counter gets to 5, then you call the 22Hz routine which also resets the timer.

Ahh, that would be why. 
Well, thankfully, this isn't much of a problem.

btw, can you have more then one custom interrupt running at a time?

You could add code to the end of one interrupt routine that basically jumps to the beginning of the second, so that you could run just the second routine or both.