DT-INTs What's legal in an INT handler?

My program spends most of it's time in a loop waiting for an interrupt (button presses). Once received, I need to decode 24 buttons and execute the right commands.

My present interrupt handler has a SELECT CASE function in it, with a GOSUB in every case to execute the functions. Is this legit? What are the specifics and restrictions in an interrupt handler?

With DT_INTS using a PBP type interrupt, pretty much anything goes. I.E. use as many
PBP instructions as you like in the int handler.

That's the really cool part of using DTs' int program. He's done all the work for you.

Just don't GOSUB outside the interrupt handler - or it will go-like-splat...:)

Thanks Bruce. The issue that led me to this question is obviously something else.

I'm using LONG variables for the first time, and have an issue where a bit in a 24-bit LONG is being changed/corrupted by me TOGGLEING another, unrelated BIT variable! I figured the problem is me MISDECLARING my variables OR my interrupt handler. Bit 14 of the LONG variable GRN is being corrupted when I toggle the bit variable SOLO. (If I don't use interrupts, the problem goes away).

My variable declarations are:

Code:

---

RED        VAR    LONG                 
GRN        VAR    LONG                 
BUTTONS    VAR    LONG                 
X          VAR    LONG                 
Y          VAR    BYTE                   
Z          VAR    BYTE                   
RED0        VAR    RED.BYTE0
RED1        VAR    RED.BYTE1
RED2        VAR    RED.BYTE2
GRN0        VAR    GRN.BYTE0
GRN1        VAR    GRN.BYTE1
GRN2        VAR    GRN.BYTE2               
BU0        VAR    BUTTONS.BYTE0         
BU1        VAR    BUTTONS.BYTE1       
BU2        VAR    BUTTONS.BYTE2         
LCD        VAR    BYTE[80]           
COUNTER    VAR    BYTE                 
VOL        VAR    BYTE                 
SOLO        VAR    BIT

---

Thanks.

Bruce, could you please explain your comment to me? I would think that PBP knows what bank it is in, and keeps track of that - even in an interrupt handler. Is that not true?
And what constitutes "outside the interrupt handler"? Must all the handler code be placed between the INT entry point and the INT_RETURN?
I have to admit, I have violated your "rule" and it hasn't caused problems. Am I lucky?
Please explain.

? toggle command is only good for port pins ?

Oh my gosh, you're right! I don't know why I thought that would work for a bit. That fixed it.

THANKS Michael.

Quote:

---

Bruce, could you please explain your comment to me? I would think that PBP knows what bank it is in, and keeps track of that - even in an interrupt handler. Is that not true?
And what constitutes "outside the interrupt handler"? Must all the handler code be placed between the INT entry point and the INT_RETURN?
I have to admit, I have violated your "rule" and it hasn't caused problems. Am I lucky?
Please explain.
__________________
Charles Linquist

---

Hi Charles,

Would be happy to answer if you could point me to the inital post...;)

This is a cut-and-paste from post #2 above.





With DT_INTS using a PBP type interrupt, pretty much anything goes. I.E. use as many
PBP instructions as you like in the int handler.

That's the really cool part of using DTs' int program. He's done all the work for you.

Just don't GOSUB outside the interrupt handler - or it will go-like-splat...
__________________

I wanted to clarify a point just to possibly help somebody else...

Unfortunately, TOGGLE does work to change the state of a BIT variable, even though this is an incorrect use of the command! It also quite possibly clobbers some other unsuspecting variable, in this case a LONG. It would be nice if the compiler would flag it, but it doesn't so BEWARE!!

Thanks again, Michael.

Hi Charles,

What I meant was -- you don't want to jump outside an interrupt handler routine - without
returning to it.

I.E. if you GOSUB outside the interrupt routine, and don't re-enter it before your return, you might
experience major problems.

DT_INTS needs to exit from DT_INTS. If you jump outside of this routine, and try to return
from the interrupt on-your-own, you're going to have a problem.

Exit from an interruppt requires a lot of regitsers to be restored.

If you jump outside of the int routine, and return on-your-own, you will for sure see a problem.

Quote:

---

I.E. if you GOSUB outside the interrupt routine, and don't re-enter it before your return, you might
experience major problems.

---

Code:

---

------------ DT Interrupt handler --------
Get_Byte:

do something here

If black then gosub apples
If withe then gosub peach

@ return


apples:
do something
return

peach:
do something
return

---

Bruce, can you please explain better your statement? from what you said, I understand that the above example code could give problems, while I am using this type of jump out of the interrupt handler, quite often and I never experienced any problem.

Al.

Hi Al,

No problem at all with your code. You GOSUB outside the int handler, and you RETURN right back to it, so this isn't a problem.

The problem is only when you GOTO (or GOSUB) to another routine, outside an interrupt handler, and you do NOT return to it where it restores saved registers, and issues a RETFIE command.

You show a DT Interrupt handler. You may not see it, but i guarantee theres a lot of code on exit from a DT interrupt routine
that's restoring system file registers.

I feel better now! I haven't broken any laws.

Bruce, tank you for the explanation.

Al.