In a program I'm making I'm attemting to implement a teacher key. To clarify what I mean by that: the user will press a button (Sto-> at this point), and it will quit very fast to the Homescreen, bypassing the shell it's being run from (DCS, MOS, Crunchy etc...). The two possible strategies I've come up for doing this are as follows:

-bjump(_JForceCmdNoChar)
-Find out what level the stack is at before it ran the shell and set SP = to that.

I've tried the former method, but when it quits it leaves the homescreen in a mess of characters. I tried to fix this by loading 0 into ever byte of TextShadow before I bjump(_JForceCmdNoChar), but no dice. It appears that bjump(_JForceCmdNoChar) itself screws with TextShadow. This leaves me conflicted. Although this way is much easier, it's not very professional becuase the Homescreen looks like a mess.

I have yet to attempt the latter method because I'm confused as to where to start. I guess I could try setting sp to one byte higher in memory each time until I achieve the desired result, but will that really work?

Does anyone have any suggestions or different methods for quickly quitting by bypassing a shell?

Edit: Solved my own question, but I will leave the topic up here for others if they want to learn. All you have to do is
Code:


Make sure that you clear out TextShadow first as most shells like to use that for variable storage.

Code:

Ahh, of course. The clear character =/= $00. Stupid me

Heh, and that's much safer than just jumping into the middle of the stack.

I have to say, my way was remarkably stable. I'm only switching to this way because I'm not sure that it will work on 83+ because the different OSs may have different stack usage, etc...

They not only might, they do. It changes with each OS version, in fact.

You mean that different versions of 84 OSs have different stack usage? Well, I'm glad you posted that code then.

Yup, I discovered that myself one day while tracing through some DCS stack errors. 'Tis useful to know.

Yet another instance of TI's inconsistency in its products.

The onlty thing consistent about their stuff is the inconsistency.

Let's not forget the bad drivers in their newer calcs.... but that's completely different. When I first saw this thread, I thought it was like shells were drugs or something like that, and people were addicted, so it was giving a way to quit... never mind, my mind sometimes works in ways even I don't understand....

Ooookay then, time for someone to lay off the crack pipe... :d It is a rather obtuse topic title to someone unfamiliar with the context of the terms.

it is really, or we are just really big nerds when we think the way we do about the topic title.

still thinkin the quickest way to exit a shell is pull the batteries... or pull the plug, which ever is the circumstance.

Only problem with that is it wilt clear thy RAM. I believe the idea was an instant quit without any adverse effects to the calc. If you want to pull the batteries, you could just as easily jump tto $0000. That would just reset the calc.

hehe, guess so.

And anyways, I was joking. Thought I would throw a lil random humour out there...

Ironically, testing this on my real TI84 (physical not emulated), resets the ram. When I run on in Tilem or Pindurti it runs fine. Any idea why this is?

What's wrong with the topic title? I posted it in the z80 asm section so there should be no doubt that it will be an assembly question.

Actually, I first thought he meant a linux shell - it took me a sec before I realized he meant a calc shell... heh...

Ok, fine. If you all think it sucked so bad, what would you suggest for a topic title?

Oh, and can I get some help with it crashing on a physical calc?

Under z80 assembly? I don't think Chipmaster would mistakingly put it here...