Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Keoni29 on March 20, 2011, 03:52:47 pm
-
Is there an axe command that shuts down your calculator? If not: has someone got an asm line that does this?
I need it for password protection.
-
What do you mean "shut down?"
If you mean to turn the screen off, then just use
:Asm(DB10CB6F3E0220013CD310C9
Re-run that code to turn it back on as well.
To set the calculator into sleep mode and wait for the [On] key to be pressed, use
:Asm(3E01D303FB76FDCB09A6C9
To completely turn the calculator off so that the program will exit and the user will return to the homescreen:
:Asm(EF0850
All courtesy of Xeda and TI-BASIC dev.
-
Asm(EF0850) shuts down your calc (turns off completely, so when you turn it on again it's at the home screen). It causes memory leaks, though.
There some more specific hex codes here (http://ourl.ca/8996/179007), thanks to Xeda.
EDIT: Ninja'd with a better explanation.
-
I'm afraid Axe doesn't have such command and Asm(EF0850 is what you need.
-
If Keoni29 is really brave, they could always use Asm(C7, which doesn't cause memory leaks ;)
-
If Keoni29 is really brave, they could always use Asm(C7, which doesn't cause memory leaks ;)
No, don't do that :P That's the instant RAM reset code.
-
If Keoni29 is really brave, they could always use Asm(C7, which doesn't cause memory leaks ;)
No, don't do that :P That's the instant RAM reset code.
http://ourl.ca/8617/160758 (http://ourl.ca/8617/160758)
And Qwerty knows it :P
-
If Keoni29 is really brave, they could always use Asm(C7, which doesn't cause memory leaks ;)
No, don't do that :P That's the instant RAM reset code.
Awww, you spoiled the ruination of hours of work by a single misplaced byte :P
j/k
I probably should have mentioned that in my post...
-
If you simply want to turn off the calc without exiting to the home screen, you can use Asm(3E01D303 I believe. I've never had to use it in an assembly program.
-
:Asm(EF0850
Is that what super mario 1.2/2.0 do when you press MODE? I'm kind of shooting for an effect like that
-
What does that do?
-
You press mode and the screen turns off until you press on. It was called a teacher key iirc.
-
If you execute 3E01D303 when you press Mode, that is what will happen :) If you use the EF0850, it will exit the program or App upon pressing On.
-
EF0850 is basically "quit everything and shut down" (not really, but it's as close as you're gonna get without causing a RAM clear). If you run it from a program, it can cause memory leaks (not sure, gotta check).
-
I don't think it resets the stack or any of the non-volatile RAM storage areas (aside from the homescreen), so it shouldn't cause major leaks.
-
I don't think it resets the stack or any of the non-volatile RAM storage areas (aside from the homescreen), so it shouldn't cause major leaks.
It might cause the copy of your program at $9D95 to never be deleted. That can cause major leaks.
-
No, the leak occurs when you are running a program (not an APP). The reason is because the OS copies the program and when you use the same exiting routine as an APP or you use EF0850 (or a few other opcodes), the OS never readjusts the memory, creating a memory leak. So for example, running this code:
AsmPrgm
EF0850C9
Will make you lose 4 bytes of RAM because the code is four byte long. If you run this:
AsmPrgm
210000
224B84
EF4645
EF0850C9
That will make you lose 13 bytes of RAM.
EDIT: Ninja'd :O
-
Confirmed (and ninja'd (twice)):
In short, this should only be used in apps, because they don't get copied (not in this sense) in the first place.
EDIT: Huh, Wabbit doesn't do blank screens very well. There's a bug report for Buckeye.
-
My programme runs on startup. When someone simply removes the battery while running ram clears and the password is no more (I'm the only one who knows that at my stupit skool XD)
Can I prevent this from happening?
-
In Axe? Not much. If you want to get into some fancy Assembly code, I think some people here know how the OS manages to do it though.
I don't think it resets the stack or any of the non-volatile RAM storage areas (aside from the homescreen), so it shouldn't cause major leaks.
It might cause the copy of your program at $9D95 to never be deleted. That can cause major leaks.
Oh yeah, forgot about that RAM copy. That'd be a major problem...
-
My programme runs on startup. When someone simply removes the battery while running ram clears and the password is no more (I'm the only one who knows that at my stupit skool XD)
Can I prevent this from happening?
Yep. Asm(215AA522BE85) should prevent ram clears. However, it will probably (never tried it) remain in effect until you next turn the calc off, so when you exit your program you might want to Asm(21000022BE85), although it shouldn't doesn't have any nasty side-effects if you don't.
-
My programme runs on startup. When someone simply removes the battery while running ram clears and the password is no more (I'm the only one who knows that at my stupit skool XD)
Can I prevent this from happening?
You could copy the password to archive immediately so that you keep a copy in both RAM and flash. Then, if somebody clears the RAM, you can check to see if the password exists in archive.
-
Yep. Asm(215AA522BE85) should prevent ram clears. However, it will probably (never tried it) remain in effect until you next turn the calc off, so when you exit your program you might want to Asm(21000022BE85), although it shouldn't doesn't have any nasty side-effects if you don't.
That's an interesting feature, I never knew about that. You are missing some important details, though; while it certainly appears simpler than computing the correct checksum, it also has some weird side effects. For example, you also need to initialize (statVars-2) with the desired boot-time stack pointer. I wouldn't recommend doing it unless you understand the implications. And I myself don't understand all of them.
Bear in mind that, whether you use the actual checksum or this A55A trick, you need to ensure that memory actually is in a safe state. If you're writing a RAM assembly program, for instance, you need to free the allocated memory first (or else go through some horrible contortions to arrange to free yourself after the reset.)
-
Here it is. This will turn the calculator off properly with no memory leaks, the only downside is it's a little big.
Asm(21 E1 E5 22 72 98 3E C9 32 74 98 CD 72 98 11 0F 00 19 11 72 98 01 10 00 ED B0 C3 72 98 EF F1 42 EB 5E 23 56 21 95 9D EF 57 43 EF 08 50)
Put the name of your program in OP1 and run this, it deallocates your program and turns the calculator off. Needless to say, you should not run this from within Mirage.
ld hl, $E5E1 ;pop hl, push hl
ld (appBackUpScreen), hl
ld a, $C9
ld (appBackUpScreen+2), a
call appBackUpScreen ;we have to get a pointer to the runner
sizeToAdd:
ld de, sizeToAddEnd-sizeToAdd
add hl, de
ld de, appBackUpScreen
ld bc, runnerEnd-runnerStart
ldir
jp appBackUpScreen
sizeToAddEnd:
runnerStart:
bcall(_chkFindSym)
ex de, hl
ld e, (hl) ;grab its size
inc hl
ld d, (hl)
ld hl, $9D95
bcall(_delMem)
bcall(_powerOff) ;that's pretty nifty, I just found this
runnerEnd:
Edit:
I don't know much about axe, but if you can get a pointer to the start of this routine, I can make it substantially smaller.
-
Needless to say, you should not run this from within Mirage.
Why not? I don't know much about shells, sorry :-\
-
You cannot use it with MirageOS because while the OS copies the program to 9D95h, MirageOS moves the program to 9D95h. Pretty much, if you delmem at 9D95h, you delete your program data for good (instead of deleting the copy).
-
Ah, so it'd be the same for any other shell, right?
-
Not necessarily, but most likely. If the shell executes the program the same way as the OS (likely by using one of the bcalls), then it wouldn't be a problem. Also, I am pretty sure that as long as the program is archived and there is no writeback, you won't need to worry.
-
So...
:[110F0019117298011000EDB0C37298EFF142EB5E235621959DEF5743EF0850]->GDB000
Then.
:GDB000
:Asm(E9)
That ought to work. Just define GDB000, or whatever you want to call it, then run that little bit of code. The calculator should turn off.
sizeToAdd:
ld de, sizeToAddEnd-sizeToAdd
add hl, de
ld de, appBackUpScreen
ld bc, runnerEnd-runnerStart
ldir
jp appBackUpScreen
sizeToAddEnd:
runnerStart:
bcall(_chkFindSym)
ex de, hl
ld e, (hl) ;grab its size
inc hl
ld d, (hl)
ld hl, $9D95
bcall(_delMem)
bcall(_powerOff) ;that's pretty nifty, I just found this
runnerEnd:
Needless to say, you should not run this from within Mirage.
Why not? I don't know much about shells, sorry :-\
Nothing good can happen basically.
1. Program is in ram: The routine will find either the correct size, or random garbage, at which point it will delete your program, and possibly all of ram including the VAT. Or nothing if it's pointing to 0000's. (I've had like 31KB legitimately free before.)
2. Program is in flash: The routine will find some garbage value for the size and will delete all kinds of things in ram either giving you positive or negative memory leaks. But your program should still be intact.
Basically, just don't do it. ;)