MaxCoderz

It's been a while since my last question
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?

I'm afraid I can only really answer for the behaviour of the Z80, not the behaviour of the TI-OS. The Z80 CPU user manual states:

RESET
Reset (input, active Low). RESET initializes the CPU as follows: it resets the interrupt enable flip-flop, clears the PC and registers I and R, and sets the interrupt status to Mode 0. During reset time, the address and data bus go to a high-impedance state, and all control output signals go to the inactive state. Notice that RESET must be active for a minimum of three full clock cycles before the reset operation is complete.

As far as I'm aware, the contents of the other registers are undefined. If you like I could test this against a real Z80 MPU, but you'd have to wait until next week I'm afraid and I don't know whether that would match what the chips in the TI-83+ do.

Ok, thanks
But what does that mean in practice, when is RESET pin actually used?
Do the "protection" mechanisms like Flash Exclusion and the execute-protected ram pages use the RESET pin? On PindurTI, executing something on a protected RAM page does not reset the IFFs

King Harold wrote:But what does that mean in practice, when is RESET pin actually used?
Do the "protection" mechanisms like Flash Exclusion and the execute-protected ram pages use the RESET pin?

I took the back off my TI-83+ and put a probe on the RESET pin (23, easily spotted as 23 is printed on the silk screen). Naturally this sits high most of the time, but a CALL&C000 in BBC BASIC causes it to briefly go low, resetting the calculator. I'm not sure what you mean by Flash Exclusion, sorry.

If I had a spare TI-83+ I'd try cutting RESET and soldering the stub to the positive supply to see if that bypasses the protection. As I don't want to damage my only calculator any more than necessary I tried driving the pin high without disconnecting it from the TI-branded chip on the board. The calculator still reset which may have been to do with the protection (the protection may disable other parts of the calculator then reset the Z80 rather than sitting in limbo) or may have been down to me shorting out the power rails when it attempted to drive RESET low, causing a brownout.

Thanks for experimenting
That is bad news, though. It means that it's impossible to distinguish a real reset from a jp $C000, right? It also means that PindurTI is not as accurate as I'd hoped..

benryves wrote:I'm not sure what you mean by Flash Exclusion, sorry.

Port $22/$23, controlling the executability of a range of flash pages.

The calculator doesn't use the Z80's RESET line for any other purpose, as far as I'm aware, so there isn't "real reset" as such.

You could take out the batteries and let it sit for a while, I'm pretty sure it ends up being reset..

That's a power-on reset rather than an assertion of the RESET pin. I believe the calculator uses DRAM so you could check for a power-on reset by verifying the contents of RAM.

King Harold wrote:(are there more?)

When the RAM check sum fails.

Sorry I can only answer to this.
Any reason for asking this or just mere curiosity?

But there is no ram checksum. Maybe in TIOS but it's not really relevant..

Yes I'm asking so I can find out whether it would be possible/easy to just kill a program when it crashes, instead of resetting everything when some unidentified crash happens out of fear of state corruption, hopefully without validating the entire state (which is next to impossible)

King Harold wrote:But there is no ram checksum. Maybe in TIOS but it's not really relevant..

Yes I'm asking so I can find out whether it would be possible/easy to just kill a program when it crashes, instead of resetting everything when some unidentified crash happens out of fear of state corruption, hopefully without validating the entire state (which is next to impossible)

Yes, it is done by the TIOS.

That would really interesting.