Simon,

First let me say that I don't believe that this should be done. If you have to do what the original question wants to do then you (he) probably did not design your (his) program carefully enough. I only offer this as a way of getting the job done technically. In practice I would never do this. I would find a better approach.

Peter, again, I do not endorse the use of this approach, I think its bad design.

You can return to the main program from the second interrupt without going through the first interrupt, but special care must be taken. You will not be able to reliably do this by setting a flag. Hans' second post to the original post hits the reason why right on the head.

Here is what is needed:
1) You must never use the stack in the main program. The stack must only contain pushes from inside a call routine or an interrupt routine. You must always know what your stack might contain.

2) You must know the address range(s) of your lower priority interrupt routine(s). This can be done dynamically.

3) In your high level interrupt routine, just before executing the RETI you examine the top two bytes of the stack to see where the program was when this interrupt was initiated.
One of two things will be true. It came from a lower priority interrupt or it didn't. (Obvious right?) If it did not come from a lower priority interrupt then you simply execute an RETI and everything is happy. If the bytes on the stack show that you came from a lower priority interrupt then things could get very tricky, but here is what you do in the simple case. You replace the top two bytes of the stack with the address of a routine you wrote called something like "MY_STUPID_STACK_MANIPULATION_ROUTINE" and then execute the RETI.

4) Now you are in the special stack routine and you know that you must execute another RETI to clear the interrupt logic correctly. But where do you go? That depends on where the PC was when the lower priority interrupt was initiated. The stack might contain addresses from nested calls. (That is what could make this trickY but possible). Lets say that the stack contains no other calls except for the interrupt. You should already know where your stack started because as a good programmer you moved the stack pointer to some nice safe place during your init routine. You can also determine where the stack is now. Now you need to pop off bytes from the stack until you get to the RETI address. But where do the bytes go? That depends on how big the stack is. You know how many PUSHES you wrote in you lower priority interrupt and can determine which PUSHES occurred by the stack size. POP off the bytes to the appropriate registers (ACC, PSW, etc.) until you are at the original RETI address. Now execute an RETI and you have avoided the lower level interrupt routine. You can see where this could be very complicated if the stack contains nested calls already.

This would satisfy the hardware requirements but would break a couple of rules. One of which is that interrupt routines should be short, quick, and sweet. This stack manipulation method could prove to be long.

The very thought of implementing this method makes my skin crawl. Your best bet is to (I cringe as I say this) follow the rules of good program design. Supportablity and reliabilty will be better met.

Allen