The OS interrupt handler periodically scans the keyboard matrix. If an interrupt fires in the middle of testing the delay, the interrupt processing delay will definitely throw the test off, giving a lower-than-normal value. If the interrupt handler decides it's time to scan the keyboard matrix, it will leave the key group mask set to FF, which will cause the test to never read a key press. You could try to verify this by forcing an interrupt to occur in the middle of the test sequence using a crystal timer with its delay set to a specific number of clock cycles; see WikiTI for details. If you're feeling particularly ingenious, try disassembling the OS interrupt handler and determining what causes the OS to rescan the keyboard. Then, set up the test to force those conditions to occur.

Your results may be consistent across multiple runs because the interrupt timings are fairly predictable. Specifically, the OS won't start to execute the program until after the interrupt handler sees the ENTER key and stores the keycode into RAM, and then GetKey sees the keycode and returns to the home screen app, which closes the edit buffer and starts parsing it, and then the parser loads and executes the RAM program. So, this sequence can take a fairly predictable amount of time from when you hit ENTER.

So, for now, the known maximum delays are :
83+ : 6
other models - mode 0 : 6
other models - mode 1+ : 29

More tests are needed...

What about TI-84 Plus C Silver Edition color screen models?

It would obviously need some modifications (as does porting a TI-82 Stats/83 program over the 83 Plus series), but I heard that most modifications are changing RAM addresses (for example cmdShadow is now at 9BAA instead of 966E) and LCD stuff. The calculator ASIC is pretty much based on the 84+SE from 2004 (the ones that had 128 KB of RAM instead of 48).

I'm not sure why, but screwing with curRow and curCol the way you do makes it overwrite previous text.

Maybe those text display routines have been modified on the 84+CSE (Who knows...).
I'm specially thinking of the automatic newline performed by _puts (and putc i think) once a char has been displayed at col 15.

So I switched it to using the wonderful _NewLine. Anyway, this gives 22 ? ? ? on my TI-84+CSE. This seems highly unlikely to me, but I don't see anything obviously wrong. I'll have to do some more work later.

I just hope ti did not change the keyboard for some slow crap.
More likely, there is one or more piece(s) of hardware that is significantly faster (and that is involved in the test ofc).

EDIT :

I took some little time to modify the kbdelay.asm you provided.
It now goes up to 128.
Feel free to try it out =]

I can get you another 83+ and 84+SE tomorrow

@DrDnar :
So, did you try the new version ?
To tell the truth, i'm kinda curious to see the results.

22 72 72 72
I find it rather strange, since so far the MicrOS keyboard routines I've written appear to work fine at 32 cycles delay. I promise you the ASIC is identical to the one in my TI-84+SE. If the keyboard is slower, it would be due to hysteresis in the keyboard matrix, not the ASIC.

I added a download link for 84+CSE users.

22 72 72 72
I find it rather strange, since so far the MicrOS keyboard routines I've written appear to work fine at 32 cycles delay. I promise you the ASIC is identical to the one in my TI-84+SE. If the keyboard is slower, it would be due to hysteresis in the keyboard matrix, not the ASIC.

Thx for the results dude.
They are indeed kinda paranormal .

83+: 5 (N-0305H)
84+SE: 4 18 18 18 (no serial number listed, it's actually an 84+SE in an 84+ case)

These are short delays !
Too bad you don't have the serial but i assume it's one of the later models.
Thx for time.