You would be correct thinking that the interrupts are causing your problems. I'm not exactly sure what your calculator is doing in the background to make ON slow it down, but it no doubt changes from program to program.

The obvious way to fix this problem is to just disable interrupts. A simple di somewhere in your loop should take care of this. But now you have to watch out because TI likes to use interrupts. Bcalls that draw to the screen tend to turn the interrupts back on, so just be careful there. Also, bcall(_GetCSC) relies on interrupts to function, so you are going to have to use direct key input with port (01).

The other option that would kind of work is to disable the on interrupt. You would output %00001010 to port (03) instead of %00001011. However, this is just a temporary fix because as soon as the next timer triggered interrupt occurs, it will re-enable the ON interrupts.

You can actually see it in the TI-OS. Just create a really big string and try to recall it. While it's recalling, pressing ON will make it slow just a little bit.

The di instruction disables interrupts.

Perhaps a simpler solution might be to just disable the ON key interrupt, which is controlled by bit 0 of port 3. Outputting 00001010 to port 3 should disable the NEXT ACTIVATION of the ON key interrupt while keeping other interrupts enabled. You'd need to find some way to constantly deactivate it though, I believe.

You could send that byte every pass of the loop, I guess.

DI, though, disables all interrupts, including all system interrupts (which includes the ON interrupt), so some functions won't work (including GetKey and GetCSC). If you use it, ALWAYS ALWAYS remember the EI!

More info: http://future_history.freehostia.com/Files/Resources/ASM/ASMin28Days/lesson/day23.html

You could send that byte every pass of the loop, I guess.

The problem with disabling only the ON interrupts through port (3) is that the ON key is only disabled for .01 second. This is because as soon as the next Ti interrupt fires, it will turn them right back on.

Is this info contradictive, or don't I understand it?
If it will only turn ON off for .01 sec, then just sending that once per loop won't be enough, right?

As for the DI instriction, that seems like a good way, though all I have to do is replace GetCSC with a directly-into-port routine?
Or would it be nesaccery to do DI after every B_Call, since:

typically routines like bcall(_clrLCDFull) have an ei at the end of them.

Or perhaps do this? :
   EI
   B_Call(_GetCSC)
   cp  SKwhatever
   JP   Z, Randomness
   DI
But thanks, I'll mess around a bit tomorrow and see what works and what not. (though I've gotten a very scary error message on my calc last week - never seen that one before... Maybe the trail-and-error way of working might have it's downsides after all. ^_^).

if you just put a DI after each bcall, your problem would go away and GetCSC should still work.

Thanks, I'll try that.
It isn't sacret though that GetCSC must work, it's always possible to use the direct-output thing (I got a script for that already somewhere, I believe ).

EDIT:
Nope, this didn't work.
Spamming on will still result in a slowdown.
I'll be trying some of the other suggestions.

EDITEDIT:
Nothing I've tried with DI worked so far, spamming on will still slow the lot down.
It's a BIG loop, with loads of calls, jumps, sprites checking and drawing and moving and other stuff (but just 1 b_call iirc).
Putting the DI as the first line of the loop does nothing, and I've put it before and after the B_call and at some random places just to be sure, but ON will still blow the lot.
Also, you're all saying that GetCSC will stop working, but even this still works:
DI
    b_call _GetCSC
DI
    CP     skButton
    JP     Z, Label
Which proves that I have no idea what I'm talking about...

I unfortunately cannot help due to lack of ASM knowledge but one thing to be careful with when using direct input is to make sure to either add a delay between key detections or get rid of key repeat by checking if the user has released the key you pressed before continuing further in the program. Also make sure there's a small delay before checking if people released the key, so it gets detected at all. Not sure how long the delay would be in ASM, though. Otherwise, what happens is that in your game menus, options will be chosen way too fast and it will be impossible to accurately navigate through menus due to key detection being too sensitive. In-game it can also pose problem if your game has everything moving tile-by-tile. An example of this problem would be the first version of Splut, which was submitted to the contest.

I had that problem before already, but luckely Quigibo had a perfect solution for that:
http://ourl.ca/6459/105146

So direct input would defenitely be an option.
Although I'm still unsure of how to completely disable the ON button.
Like other here have said - completely disabeling it would force the use of direct input, which I'm fine with.
So, how to disable it?
I'm not good enough (yet) to understand what the kind people post here. ;P