Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Deep Toaster on October 23, 2010, 12:28:15 pm
-
Really plain question: What are hooks? (As you've probably guessed from that question, I don't know anything at all, so links would be great ;D) TInA!
-
I would have linked to http://wikiti.brandonw.net/index.php?title=Category:83Plus:Hooks:By_Name but it doesn't really explain what are hooks, it just lists them.
-
Hooks are assembly routines called by the OS in certain situations. The parser hook, for instance, is run when a command is executed. This is how xLib works.
-
There are multiple types of hooks, though, right? Key kooks, parser hooks, etc...
-
Yep. That page you linked to earlier has all of them ;)
-
Oh wow I didn't realise every single of those were different types of hooks. I am noticing the parser hook in there now.
-
Oh, thanks. I was just wondering if it'd be possible to make a hook that allows me to calculate something while inside the prgm editor (so that I don't have to quit and scroll all the way back down again just to check what 324*73 is). Can hooks even do something like that?
-
It depends. Can hooks be real-time?
-
That sounds possible. As for hooks, you basically look through that list to see where the closest hook is to what you will be doing. For your purposes, I would say you want the raw key hook. That hook is called any time the OS receives a key press. So lets say that you decide that VARS is going to be your goto button. You would have to find a ram area that you don't think is going to be killed in the near future. My favorite is smallEditRAM, no one knows about it so it is never used; it will persist through almost all games.
Then at smallEditRam you will make the code for your hook, your first line must be a .db $83, this is so the OS knows that it is calling a hook and not jumping to an outdated address. Since this ram area is pretty small ~170 bytes, I like to make the code at this area find the real program in the archive, and stream the real code into appBackUpScreen. Then for your hook, the first thing you want to do is figure out which button was pressed, and if it wasn't vars, quit. Then if it was vars, you probably want to have some other qualifier so that the vars button is not useless, like the ON button which doesn't trigger the hook.
So now you are ready to do your calculations. Remember that since you are editing a program, the edit buffer is open and there is 0 free ram available. And when your calculation is done, I'm not exactly sure how you would put the screen back to normal you'll have to ask someone else for that. A bcall(_jForceCMDNoChar) might do it, but I think that will go to the homescreen. Also, don't forget to enable the hook with it's corresponding enable bcall.
Edit:
Now that I think about it, don't stream the info in on every single key press, you're calculator will be sooo slow. Instead, do the checks in smallEditRAM and then stream in your calculator GUI code when you get a match.
-
Yeah what you mention in your edit was my concern. We must not make user input too slow either, same for scrolling through the program. MathPrint was slow enough like that x.x.
-
Thanks for the info. So here's what I've figured out so far:
The hook will find and run a program the way you suggested. The program will let the user input the equation on the final (eighth) line of the BASIC prgm editor, storing everything to some saferam area. And then it calls _ParseInp and copies the result into the editor. _JForceCmdNoChar doesn't work because it returns to the homescreen, so it's just going to simply quit and clear the last line.
Then I realized: _ParseInp requires that the input be stored to some equation variable. Since I can't create a new equation variable, I'm thinking of hacking the VAT to make Y1 or something point to the equation loaded in the saferam area where the actual expression's stored, then restoring the VAT later. Anyone know a reason why I shouldn't (like if it would be unstable)?