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.

The signaling rate of the Silverlink, if I remember correctly, is limited by TI to about 2 Kbyte/s, so half-an-hour for a complete dump is about right. You could make it considerably faster by adding logic that detects and avoids unused pages, or just hard-coding the sectors of the ROM unlikely to be important. A blacklink might get considerably higher throughput under some circumstances, but since you can't (by design) maintain complete CPU control in the protected and fully-preemptive environment that all modern OSes provide, the link may be less stable at high speeds.

Here's a screenshot of TI Device Explorer.

DJ_O, I certainly have little intent of doing anything BASIC-related in the near future, due to my assembly language expertise.

It wouldn't have been so bad if TI had upgraded the ASIC with extra RAM, and more importantly, some kind of simple sprite-based graphics accelerator. Such a circuit could output 1 pixel every clock cycle, which would be about a 30-fold improvement over the Z80. So once the font data were loaded, displaying text would be a simple matter of telling it where to draw the sprites (letters). However, it seems TI was hell-bent on not having to change the ASIC. But as we all keep saying, TI really could have easily made that unnecessary by simply raising the clock speed. At 25 MHz, I suspect the calculator would feel much more responsive. I'm still trying to devise new and creative methods of tapping into those unused pins.

Also, I suspect the 68K would be able to drive the display far better. The 68K has pipe-lining and a wider bus, so it could probably output a pixel far better than the Z80's rate of about 30 cc/px. I don't know how well-pipe-lined the 68K is, but 3 cc/px would basically make it ten times faster at 15 MHz, making the display speed completely reasonable.

I prefer to heat up my calculator with overclocking.

You'll probably need my detokenize Axiom to do anything useful with the input command. Off the top of my head, I'm not certain why it would crash, but I can think of a few possible reasons.

It could be that you're parsing the data returned by input incorrectly. It's tokenized, in case you didn't know. Tokens are explained elsewhere, but suffice it say, you can't send the result of input directly to Output or Disp, and it's unwise to pass the result to GetCalc( without validating that the user typed a valid name.

It could also be due to memory allocation issues. input is special in that it allocates a special temporary variable to hold the text the user types in. A temporary variable is just a regular file (like Axe files, programs, Strings, Pics, &c.) that is automatically deleted when your program ends. It's entirely possible to run out of memory by calling input multiple times, so the detokenize Axiom has a CleanAll() command that frees all of the temporary memory input allocates.

If you create, resize, or delete anything after calling input, the pointer to the temporary variable becomes invalid (the OS moves the variable) and you have no way of getting a new, valid pointer. You can do it in assembly, but it would be a bit of a pain. (Of course, in assembly, you'd already know the same of the temporary variable, so getting a new pointer to it would be easy. I wish Runer would add an option in Axe to get the VAT pointer to files; it would have reduced the excessive amount of assembly code embedded in its source.)

Is it possible? Yes. Is it cheating? Yes. Do you still want to do it? Why should I bother asking. . . .