Can you pass execution to the Ti-OS with a condition to return to program execution if, say, you pressed certain keys or the calculator turned off or something?
I was trying to refrain from answering this question, becasue I am not an assembly programmer, but seeing as all our actual assembly programmers are being inconsiderate "glare" I will have to step in.
I have done some research on z80 assembly, and as far as I can tell, there is no way to do this, although I am not entirely sure I know what you mean (again, I'm not an assembly guy)
What are you trying to accomplish?
Lol, i feel that once the thread is off the recent posts it deserves a bump :D just kidding i won't be so impatient next time.
What I am trying to do is basically quit the program (in appearance) and allow the user to do other stuff and then when the calculator turns off (i know how to detect this within normal assembly program) and then back on, it returns to my program. Kind of random, but i have my reasons :P
Involvement of interrupts significant?
Anyways, thanks for the reply builderboy
Look into hooks.
EDITNevermind I got it to work. Found another source code so i guess the one i found was just suck. Thanks for the suggestion of hooks.
Okay so after a little bit of searching i found keyhooks, which would serve my purpose, but i can't get it to work… and there's not a whole lot of information about hooks. Has anyone ever experienced using them?
Here's my code if you can spot anything at a glance
.nolist #include "ti83plus.inc" #define ProgStart $9D95 .list .org ProgStart - 2 .db t2ByteTok, tAsmCmp jp quit #define B_CALL(xxxx) rst 28h \ .dw xxxx ld hl, keyhook ;The label of the keyhook ld de, appbackupscreen ; it will be saved at the appbackupscreen ld bc, hook_end-keyhook ; this is the number of bytes the routine is ldir ; copy it into appbackupscreen (safe RAM area) Not needed if an application is doing this ld hl, appbackupscreen ; tell the TI-OS where the keyhook is in a, (06h) ; get the memory page B_CALL(4F66h) ; undocumented call that installs it ret keyhook: ; this routine will be the keyhook .org appbackupscreen ; if you use a jump it will be to one of the RAM areas where the keyhook ;is stored add a,e ; you will need this for any keyhook. It's needed for the op-;code cp $05 jr z, quit PUSH AF b_call(_HomeUp) ld a, 'D' POP AF quit: ret hook_end: .end .end
Even with the jp quit at the beginning, the calculator rejects the program. >.<
The only thing i could find on hooks was this.
Okay. One more problem, lol. The b_call for uninstallation doesn't seem to work well… b_call(4F6Fh)
There's really no explanation anywhere of how to use it (just call it and it undos the keyhook??)
Probably, yes, but make sure you have a pointer to the keyhook when you do it.
Also in the above code "jp quit" jumps to somewhere in appbackupscreen which probably isn't what you want.
So the b_call takes a pointer as an input? like in hl? would it just be the label: keyhook?
*sigh* I wish they would tell me what the inputs are…
I don't know what the inputs are either, but that would be my guess. Except the input would be appbackupscreen because that's where the keyhook actually is. The keyhook label is just where the code for the keyhook is at the time the installation program is running, which isn't helpful to the OS at all.
so this keyhook is at the very beginning of appbackupscreen (i think that's a huge data structure, right?), as a coincidence? I remember there are lots of other things involving appbackupscreen. What is that anyways (appbackupscreen)? I tried searching about it but nothing really brings up any relevant information.
It's at the beginning of appbackupscreen because the program you posted above loads it to the beginning of appbackupscreen. Which is just an area in memory (768 bytes long, I think) that isn't used for anything important by the OS, so it's useful for something like a keyhook that needs to stay in a fixed location in RAM after a program exits.
but…Can't that area easily be overwritten by other ASM programs?
—And i think i'm also starting to understand the keyhook now. You put away code somewhere and the rom call changes the value of the pointer that points to the program to be run at a keypress!
What if I pointed to the code within the installation program itself? I think that does not work because of the in a, (6) rom page stuff. Do you understand how that works? I didn't really understand the explanation of it on http://wikiti.brandonw.net/index.php?title=83Plus:Ports:06
The reason that it doesn't work is simple: the installation program doesn't stay at the same place in memory. It gets moved to $9d95 when the program is running, otherwise it can be virtually anywhere depending on what other files you have around. You also don't know if it's in RAM or archive.
Ohh. I get it now..
I've been having problems with labels inside the keyhook code. Do they work at all? If not, is there anything I could do to control program flow?
The directive ".org appbackupscreen" is used to make sure that the labels after it point to the proper place. That is, the byte after that directive is, from then on, assumed to be the first byte of appbackupscreen.
This does cause some problems. In particular, in the sample code above, the labels "quit" and "hook_end" are also after the .org directive, and are assumed to be pointing to something in appbackupscreen. This means that "jp quit" jumps to somewhere random (the first byte after the just-installed keyhook, which could be anything), and subtracting "hook_end-keyhook" doesn't give you the number of bytes you want since one of the labels is before .org and the other one after.
Make sure that the keyhook is the very last thing in your program. Also, instead of "hook_end-keyhook" you'll want "hook_end-appbackupscreen": THIS is the number of bytes the keyhook routine is.
ohh ok. my new code doesn't have that directive in it. that is necessary, isn't it
Oh well, I decided that i would not need a loop in my program. It's all about done, I just need to make sure that it won't screw up the calculator somehow. Here is the program:
.nolist #include "ti83plus.inc" .list .org userMem-2 .db 0BBh,6Dh ld hl,myHook ld de,appBackUpScreen push de ld bc,myHookEnd-myHook ldir pop hl in a,(6) ld hl,appBackUpScreen b_call(4F66h) ret myHook: add a,e cp $8d ret nz ld a, (CurRow) PUSH AF ld a, (CurCol) PUSH AF ld a, 'O' b_call(_PutC) ld a, 'V' b_call(_PutC) ld a, 'E' b_call(_PutC) ld a, 'R' b_call(_PutC) ld a, ' ' b_call(_PutC) ld a, '9' b_call(_PutC) ld a, '0' b_call(_PutC) ld a, '0' b_call(_PutC) ld a, '0' b_call(_PutC) b_call(_HomeUp) POP AF ld (CurCol), a POP AF ld (CurRow), a b_call(_getkey) cp k6 ret nz b_call(_getkey) cp k9 ret nz in a,(6) ld hl,appBackUpScreen b_call(4F6Fh) xor a ret myHookEnd: .end .end
Pretty simple; What it does is it replaces 7 with OVER 9000 when inputting something (intended for the homescreen, but it does menus too). I want to know If appbackupscreen is overwritten and the chance that the new code does not have a ret in it, will it destroy the calculator (or by some other way)?
Also, will Mirage's keyhooks or any other shell's interfere with mine?
Hey look this thread is off the recent posts, time to bump :D
No really, I'd like to know by tomorrow because i'm going to be distributing this program then and I just wanna make sure this thing won't kill anybody :P just making sure the pepole who can help we will see this post
(not to be pushy or anything though :o )
So i gave my program to a couple of people yesterday…
With the first person i tried it on, it worked for a little bit and then it stopped working and the program was also removed…
This person had mirage installed on the calculator and i'm wondering if that had anything to do with it.
The second person i tried it on, it worked fine and he didn't have any extra stuff on his calculator.
Download ti flash debugger, there you can test your asm programs without risking $120 :D.