![Smile :)](./images/smilies/grayscale_smile.gif)
That's probably because I've mostly been doing PC programming, and any z80 programming I did was "the easy stuff".
But now it's question time!
What exactly happens when a TI-83+/84+(SE) goes through the various flavours of "reset"?
"All batteries died" vs "OS update" vs "jp 0" vs "jp [address in no-execute page]" (are there more?)
I'm especially interested in the differences between a reset caused by normal programs (jp 0, jp [address in no-execute page]) compared to other kinds of reset (power related, OS-install), with the goal of catching things like "jp $C000" (assuming standard pages) by just killing the program. (it's an other useless toy OS to learn how things work, so changing page-0 code is no problem)
Knowing what happens, in addition to what the result of "whatever is happening" is, would also be useful to be able to reason about it (and I'm curious).
I have (of course) tested a bit with PindurTI, but is its reset behaviour 100% hardware-accurate? It sets R to 0 and SP to -1 on hard-reset, "no change" on soft-reset. Is that also the hardware behaviour?
If it is, then that's cool, I could just make it so that "SP!=-1" indicates a soft-reset (SP==-1 could still be both of course, but I'd still catch more crashes than normally)
Also, after a soft-reset it remembers whether interrupts were enabled or not (so initialization code should di, otherwise an interrupt that uses uninitialized variables might blow things up), but after a hard-reset they are always disabled. That would also be very useful, since then I could catch all cases where a "jp [no-execute or 0]" happened when interrupts were enabled (and saying "when you di, you are on your own" seems reasonable to me). Is that also the case on hardware?