I am using a grayscale interrupt routine using IM 2 and I wanted to know how I would go about making a routine that checks for the [ON] key being pressed and if so turns off the calc until it is being pressed again. In essence, I want to use this to pause/unpause my game.
Here are two ways to check for the On key:
See the WikiTI documentation for ports 03 and 04 for more details.
The documentation for port 03 also contains information and example code about how to put the calculator in a low power state (i.e. switch it "off" - it's never truly off as long as batteries are installed).
- Polling: Read port 04. If bit 3 is reset, the On key is currently pressed; if it is set, the On key is currently released.
- Interrupts: Set the least significant bit of port 03 to enable On key interrupts. In your interrupt handler, check the least significant bit of port 04 - if it's set, that indicates the On key was pressed; at this point, clear the least significant bit of port 3 to acknowledge the interrupt then set it again to re-enable On key interrupts.
See the WikiTI documentation for ports 03 and 04 for more details.
The documentation for port 03 also contains information and example code about how to put the calculator in a low power state (i.e. switch it "off" - it's never truly off as long as batteries are installed).
Thanks! I've had a look and tried several things, but I can't seem to make it so that [ON] turns the calc off, but not immediately turn it back on again. Any idea how to do that?
You could add a delay so that when the ON button is pressed, you wait until the ON button is released and then turn the calc off.
souvik1997 wrote:
You could add a delay so that when the ON button is pressed, you wait until the ON button is released and then turn the calc off.
That's a great idea! Imma try that right now.
It works, thank you!
Indeed, key debouncing is your friend in that sort of situation. For example, this is from the CALCnet 2.2 interrupt:
Code:
Code:
ld a,2
out ($10),a ;turn off screen
res OnInterrupt,(iy+OnFlags)
call Cn2_debounceon
im 1 ; OS interrupt
eI ; enable interrupts for poweron
ld a,1
out (3),a
halt
di
im 2
res OnInterrupt,(iy+OnFlags)
ld a,3
out ($10),a ;turn on screen
jp Cn2_debounceon ;interrupt caller will fix the port 3/4 values
[...code...]
Cn2_debounceon:
ld b,16
Cn2_debounceoninner:
in a,(4)
bit 3,a
jr z,Cn2_debounceon
djnz Cn2_debounceoninner
ret
KermM: Thank you for your input. I managed to get it to work with this though:
Code:
Any thoughts on if/why your method is better? Or do you know if it's possible to write it so that it is possible to remove your batteries while the calc is turned off without it resetting ram when turned back on?
Code:
getInputPause:
in a, ($04)
and 8
jr nz, getInputPauseSetOnPressed
getInputPauseOnPressed = $ + 1
xor $00
jr z, getInputTeacherQuit
ld a, 2
out ($10), a
getInputPauseLoop:
in a, ($04)
and 8
jr z, getInputPauseLoop
inc a
out ($03), a
halt
ld a, 3
out ($10), a
ld a, 0
getInputPauseSetOnPressed:
ld (getInputPauseOnPressed), a
getInputTeacherQuit:Any thoughts on if/why your method is better? Or do you know if it's possible to write it so that it is possible to remove your batteries while the calc is turned off without it resetting ram when turned back on?
Well, for one thing, my routine is in a Flash app (Doors CS, of course), so your SMC wouldn't work for me. Second, you only debounce on power-off, not power-on, which I think may not be the best idea. Finally, I think your debouncer would probably work in most circumstances, but not when there is a noisy tail on the bounce, like this:
Code:
Code:
_____ ____ __ _
|_| |__| |___| |_________
I understand about the SMC, but I'm not sure about the rest... especially that bounce you are talking about. 
Care to explain a little better? To me it seems like it works like it should. It tried it on my calc with no errors.
Care to explain a little better? To me it seems like it works like it should. It tried it on my calc with no errors. cerzus69 wrote:
I understand about the SMC, but I'm not sure about the rest... especially that bounce you are talking about. Care to explain a little better? To me it seems like it works like it should. It tried it on my calc with no errors.
One of the common characteristics of key debouncing is that when the user releases (or presses) a key, there is not a clearly-defined switch from totally off to totally on, or vice versa. As the switch contacts come together or apart, the switch state normally flips several times between on and off before settling on the final state, which is why I have a conditional loop inside a timed loop. The timed loop makes sure that the key has stayed in state for at least 16 iterations, which means that transient behavior has settled. This is probably more relevant to keys other than ON, though. Care to explain a little better? To me it seems like it works like it should. It tried it on my calc with no errors.
Ahh, I see what you mean, but that doesn't seem like that big of a risk to me. I mean, what could happen and how often would it?
Do you know anything about the battery removal?
Do you know anything about the battery removal?
cerzus69 wrote:
Ahh, I see what you mean, but that doesn't seem like that big of a risk to me. I mean, what could happen and how often would it?
Do you know anything about the battery removal?
There are indeed tricks you can do to prevent resets from battery pulls during poweroff, but they require certain bits of TI-OS intervention that I didn't want for some reason. I'll have to look back at why that was. Do you know anything about the battery removal?
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement