How do you guys handle the problem that the 65816 registers could be in 8-bit or 16-bit mode when an interrupt occurs?

Obviously, in an interrupt routine, you would need to stack the registers, then set the register sizes to suit the interrupt routine at the start of the routine and at the end of the routine restore them to their previous sizes and then pop them off the stack.

Am I right in thinking that popping the status register restores the register sizes? So if I push the status register after pushing all the other registers, when I restore the registers popping the status register first will re-set the sizes of the other registers so they can then be popped off the stack?

Is there a better way than this? I.E. something that doesn't end up with the status register pushed twice?

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Looking back at my multiple prioritized interrupt system on my '816 Forth that I did many years ago (and hence have forgotten), I see I just set the accumulator to 16 bits and pushed it, restored it at the end, and did RTI. That way you're safe whether you started in 8- or 16-bit, either way. If the individual ISR in the list that claimed responsibility for the interrupt and serviced it needed one or both index registers too, it could do the same thing. You can always save and restore in 16-bit. If the RTI at the end sets one or both sets back to 8-bit, it will be correct, and all you've lost is the few extra cycles to needlessly push and pull the high byte. No time is taken to test whether they were in 8- or 16-bit mode at the time of the interrupt sequence.

My sytem was intended for no emulation-mode operation at all after the initial reset routine. I go into native mode and leave it there permanently. Also, A is rarely taken out of 16-bit mode and the index registers are rarely taken out of 8-bit mode.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Wouldn't you do a PHP as well as pushing, the accumulator, X and Y registers?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

PHP is automatically included in the interrupt sequence, kind of like the CMP#0 being automatically included in instructions that affect A, X, or Y.

The article mentions having a different stack area for the ISR's use, but I can't think of any reason for that. It won't step on anything, because that's part of a stack's function-- that wherever you are, it leaves it alone and builds past it then when it's done it removes anything it has added without affecting anything that was there previously. My zero-overhead system of servicing interrupts in Forth takes advantage of that. Before I did it, people said it could not be done without the overhead of setting up another pair of stacks. If either the background program or the ISR need a lot of stack space for local variables and environments, recursion, etc., the best use of stack space will be gained by having one large continuous stack space with one large free area at the end, as opposed to fragmenting it and having dead zones between the fragments.

I forgot about saving the banks, since my use of the '816 has been limited to bank zero only. (You still get a ton of benefits.) The bank pushes and pulls are always 8-bit though. The direct-page register is 16-bit, so pushing and pulling it are always 16-bit regardless of status bits.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for your replies gentlemen. They have been very helpful. BDD - that wikipedia article is very good and extreemly useful. I hope it doesn't get removed due to other people's narrowmindedness.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!