Key Port Questions (TI-83+)

[Ben24]

Hello,

I'm fairly new to ASM and have a few, quick, questions about the key port on the TI-83+. It is not through lack of information that these questions have arisen but rather a surplus. Everything that I have read seems to be in complete contradiction with what another guide or forum post suggests. :P

Question 1) What does sending $FF to the key port actually do?

• "ASM In 28 Days" makes a brief reference to this in “Program 22-3” with a comment saying that it resets the key port.
  
• "Phil's TI-83 Assembly Logs" says that it activates the port and that this is necessary before using _GetKey (I am assuming that this information is accurate and that it is something that only needs to be done on the Ti-83).
  
• I also read a forum post a while back that said something along the lines of "Resets the key port... sort of".
  

Question 2) How much delay time is necessary between enabling a key group and reading from the key port? Where are delays necessary? Are there any times where there is no need for a delay? (eg. When you are just checking the same key group again and again in a loop?)

• "Program 22-1" in "ASM In 28 Days" demonstrates the need for a delay for 2 NOPs (Although without NOPs the program runs fine in every emulator that I have tried it in. I am guessing this is because slow key port response time has little practical application).
  
• "Program 22-2" in "ASM In 28 Days" does not use NOPs. This is what prompted the last question "Are there any times where there is no need for a delay?".
  

I would appreciate any help/tips/advice/links/etc. that could help me to understand this.

Thank you
- Ben

[DigiTan]

[Ben24]

Ah, fantastic. Thanks for all the information and the quick response.

The problem that you describe of keys from other groups having affect as well, sounds very similar to the one I referenced from "ASM in 28 Days". Source: http://pastebin.com/U4M5QHey
Apparently two NOPs between the OUT/INs solves the problem of the keys [x] and [->] also having effect. I wonder if $FF would fix the problem also?

I'm reluctant to do any testing with my actual calculator, just in case I bork it the day before an exam or something.
I'll have to see if I can find a cheap second-hand one on eBay for testing.

Thanks again.
- Ben

[DigiTan]

Yeah, it's not a bad idea to wait or just emulate with VTI, PindurTI, or WabbitEmu. I'm not sure if it's possible to absolutely brick a TI-83+ from a code bug, but it's fairly easy to crash it to the point that pulling the battery has no immediate effect. There's a reset sequence to fix that, but it's kind of an unnecessary hassle for most.

[Xeda112358]

Oh, since it is here, what exactly does a halt do? I've never really used it to any effect that I have noted, but I am pretty sure it has something to do with interrupts, right? ... or wrong?

[Ben24]

[Xeda112358]

But what exactly does that mean?

[DigiTan]

Yep. A HALT is similar to the IDLE or SLEEP commands seen in other processors. When operating normally, the processor will briefly break away from whatever it's running to execute a quick interrupt routine. This happens at regular intervals (~200 times per second), but it's over so quick most programs won't even notice.

Adding a HALT command will suspend most CPU activity until the next interrupt is over. It's a good way to save energy or slow things down when speed isn't necessarily a good thing.

[Xeda112358]

So if my code uses a halt during loops where it waiting for user input, it saves power? That would be mightly useful. And the FFh thing explains some things about my key routines Thanks a bunch!