why is this code so freakin' sloooow? 
#include "ti83plus.inc"
#include "DCS7.inc"   ;my DCS lib for Mimas, including it works a little different but thats np;
(DCS header here)
Xpos .equ saferam1
ld A,1
out ($20),A
B_CALL _runindicoff
res doneprgm,(IY+kbdFlags)
ld A,44
ld (Xpos),A
Game_Loop:
B_CALL _GrBufClr
ld A,(Xpos)
ld L,60
ld B,3
ld IX,Paddle
CALL isprite
CALL ifastcopy
B_CALL _GetCSC
push AF
CP skright
JP nz, cont
ld A,(Xpos)
CP 88
JP z,cont1
INC A
LD (Xpos), A
Cont:
pop AF
push AF
CP skleft
JP nz,cont1
ld A,(Xpos)
CP 0
JP z,cont1
dec A
ld (Xpos),A
Cont1:
pop AF
CP skclear
ret z
jp Game_Loop
Paddle:
.db %01111110
.db %10000001
.db %01111110
my apologies if I am not accurate with placing capitals in bcalls and if I forget to place an underscore before things, that is cuz I use Mimas.
I tested this and it ran a bit slow. What causes this?

Its slow in the way that it takes like 10 secs to scroll from the right to the left side on the screen. Souvik (on cemetech) said it has to do with B_CALL _ClrGrBuf, but its slow even if I comment that out.

To to eliminate GetCSC, all BCALLS are evil

though, direct input is a hard thing to learn, but if you understand how Ports/IN/OUT work, it's not horrible

most BCALLS are much slower because they use TIos routines -- other than that there are a few optimizations that can be made in your code but they would add up to only like 1 FPS more   here is a good resource for Direct I/O http://z80-heaven.wikidot.com/direct-input-output

Yes, the problem was the GetCSC, but not for the reason that you think. The problem was not the fact that bcalls are slow. While bcalls are slow (1000 t-states for the actual jump) you have to remember that bcall(_grBufCpy) is >100,000 t-states.

The method that GetCSC uses is the same one that Ti-OS uses. A key check is run every interrupt and the result is placed in memory. GetCSC goes and finds that memory, and returns it. But, what the interrupt actually writes to memory is first parsed to make sure that it is what we want. For instance, if the last key scan showed that [5] was pressed, it doesn't want to return [5] again or else you'll press 5 twice. The same thing happens with arrow keys, except, with arrows, they repeat at a certain frequency. That way, menus aren't impossible to use.

The slowness is actually feature. The only problem is that you have much larger distances to travel so you don't want the delayed repeat.

Edit:
    Just think about scrolling while tracing. That's essentially what you are doing.