Here is as much code as I can give you without revealing personal information. Some parts might seem wrong, but that is because I did some weird things with the strings at the end, like combining them so that I don't have to do a bunch of bcall(_NewLine)s.

Code:

You really need to be careful about registers after using bcalls. There's no telling really what TI did with the registers, and unless it's official (for example, that _PutS will leave hl at the byte after your string) it's liable (even if not that likely) to change between OS versions. The 83plus system routines guide says that _NewLine destroys all registers, for example, and that _GetKey destroys HL and DE. I dunno if that's true or not or maybe it changed for the 84+CSE OS.


AHHH! I just found the problem! On the 84+CSE, penCol is 2 bytes! So you need a two-byte write to penCol and a one-byte write (using a) to penRow

Thanks! With that, once and for all, finally, without doubt (unless you have optimizations, but I'm not going to ask you to look for any), this topic is finally over and we can all move on to other projects.

I greatly apologize for bringing up this topic again. However, after a few days of trying out the password program, I have decided that it is really irritating to have to run the program every time I want to lock the calculator. I will make it automatically happen upon power-down.

I recognize that you all have spent a great deal of time on this project. Thus, I will not ask you to necessarily go out of your way to help me with this project: only to answer the very specific, direct questions that I will attempt to ask.

Oh, by the way, I also plan to make this more like I traditional lock screen: I will add a clock. But I think I can manage that myself. In the GetKey call, I will add something where it updates the time on the screen before scanning for a keypress.

My first question in the new round of programming:

1. I will worry about how to run the RawKeyHook later. But for now: how do I use a RawKeyHook at all? It works with GetKey, but the ON button doesn't work with GetKey anyway.

EDIT: On the TI-84+CSE, there is a reset button. Can someone who knows about the hardware of newer models answer this question: is it possible to stop the reset button from working? I know that the calculator can always be reset by taking out the battery, but still, I want to make it less easy for a bully to reset the calculator to get in my calculator.

I doubt that you will be able to stop the reset button short from physically removing it from your calculator, but i dunno.

As for the RawKeyHook, you should really turn your program into an app. I would first try to keep your current program as it, just get it to assemble as an app and function the same way your current program does (remember, you can't use _PutS to draw strings inside your app, but _PutC is ok). Once you get that done, then it's time to start worrying about the RawKeyHook. Getting it setup from an app along with the OffScrpt appvar shouldn't be too difficult. You've actually already written the code earlier in here (at least i think so), you'll just need to provide the current flash page (which just so happens to be the flash page that your app is stored on). To get the current flash page, you can just do "in a,(6)".

I agree with chickendude in this case. It's relatively nice to set up a hook within an app, which can be triggered fairly easily. Converting to an APP doesn't require to much effort, just a couple miscellaneous things really.

As for the reset button, I believe that is completely hardware-based, so there is really no way to disable it. Also, taking control of the calculator right before it APDs sounds doable as well, but I will have to research it a little bit more. A clock function is relatively simple, as long as you decide to use some bcalls rather than reading from the clock ports.

I have decided to forgo the clock in the program. I have other programming projects (Asm and non-Asm) and general projects to move on to, so I am desperate to finish this program quickly. In addition:
"What time is it?"
"Time to get a watch!"
I certainly won't need a clock on the lock screen, and other people shouldn't.
Oh, and also, there is little documentation on clock stuff, like the format of time that _GetTime leaves in OP1, etc., or what _FormatTimeString (only found in the 84+CSE) does. But anyway, since I am not doing a clock, I don't need you to explain.

Thank you for informing me about the reset button: I shall find an alternate solution, like tape, or something.

Taking control of the calculator right before APD does sound doable, if I turn my program into an app. However, ideally, though this is not necessary, I would like to have neither a program nor an app. I run the program once on my calculator, and it sets up OFFSCRPT. Then, all I ever need on my calculator is OFFSCRPT, the AppVar. No program or app.
In addition, wouldn't taking control of the calculator before APD only run the password program if the calculator turns off using APD? Because now I will be pressing 2nd + Off: the calculator will rarely ever turn off by APD.

If having only an AppVar is impossible, then I suppose it is time I accepted your advice and turned this into an app.

The problem is you need a place to run the code from. An app is a stable place where you can always find your code.

OFFSCRPT gets run every time the calc gets turned off, the APD method was just a hack to turn the calc off in a program. The app would create the OFFSCRPT appvar and then whenever you turn the calc off (APD or [2nd]+[On]) that code will be run. An appvar is much less stable, and Mateo and i don't know how to run a hook from RAM (your appvar would have to be in RAM). Also, you would have to be very careful about your addresses, because you don't know where your appvar is going to be stored (you don't know where on the calc will be free) until after you create the appvar. It might be possible, but to my knowledge it's never been done before.

My suggestion, either:
1. Be happy with your program as it is and move on to something else
or
2. Convert it to an app. After this, you can add other features to the app. For example, your Fake Reset program, games, etc. You can put your projects together in the app and make a little menu to select which one you want to run. That way it's not a bunch of wasted space.

EDIT: Also, have you thought about adding in a feature to set your own password? It would be very easy to do in your current program, you can save the input data from _GetCSC as is. In an app, you'd have to save it in an appvar. But that way only you know your password, not every single person who uses your program

All right, I suppose I shall turn it into an app: that is quite a good idea, combining all of my projects into one app, called "Utility" or "My Projects" or something like that.

And adding a feature to set a password should be quite easy: I can just overwrite the values at the end of my program.

Now that I have decided to turn it into an app, once I do so with my current code, the rest should be easy. My OFFSCRPT could be only a few lines long: find the location of the app, and jump to label in the app, which the app doesn't run but the OFFSCRPT does. Then the app, rather than the OFFSCRPT, can have the RawKeyHook and all that stuff. I think that's what you were saying anyway.

Now a basic question: how do I turn it into an app? I know that I have to add a header. I know that I have to replace "bcall(_PutS)" with "call _PutS", which will call my own _PutS routine. I believe that I should replace "ret" with "bcall(_JForceCmdNoChar)". Is there anything else I need to do, like special directives or something? Something with pages?

If you would like, I could give you the template that I use for my apps. You can find it here:

App Builder

To change your compile options, just edit 'build.bat'
It uses spasm, which might be a good idea to get used to for the future CE.
If you have any questions, post them here! Hope this helps!

By the way, your code goes in "Main.asm"

EDIT: Also, changing the password can't simply be done by overwritten the values in your program, since it resides in flash. I would recommend you create a AppVar and write and read from that instead.

Also, the point of the offscrpt is not to run code in your application, the point of the offscrpt is to create the RawKeyHook. The RawKeyHook will point to a place in your app, once it executes it uninstalls itself (so that the code isn't run at every trigger of the raw key hook). So each time the calc shuts off, it sets the raw key hook. Once it turns on, the hook triggers, you run your code, uninstall the raw key hook, and continue as normal.

And as Mateo says, you can't overwrite data stored in a flash app, you'd have to create an AppVar.

Also, Mateo, why don't you use app.inc? Does it not work with the CSE?

Chickendude: I did originally use app.inc (Just had to change a single byte) but I figured that it is really not necessary to create a one-page app. If this went multiple pages, then I would probably use app.inc for some of its macros. Plus you pretty much just have to copy and paste the DCSE header if you wish to create an icon for your program. App.inc also fills the name with extra bytes, which is odd... But that's just me. I guess you could use app.inc if you wanted to.... So yeah. It's just me liking to know what goes where in apps.

EDIT: Or you could use Brass.

That's because app names have to be 8 characters, so it fills the name with spaces if it's not 8 characters. Personally, i think the code looks much cleaner with app.inc and it's easier than copying/pasting from another file. In the end, if it works it works, so i guess it doesn't really matter. But defpage(0,"Utility") is much less scary-looking than the full app header

This is a falsehood propagated by bad habits that got started long, long ago. It's trivially-easy to have an App name that is not 8 characters: you simply change the length nibble in the 16-bit field identifier, the provide the correct number of name bytes immediately thereafter.

Thanks for the clarification, so that means that the app header doesn't necessarily need to be $80 bytes long? I never knew!

Correct! In fact, the header can be much, much shorter. Here's the entire header from Doors CS 7, with no padding whatsoever afterwards:
Code:


Edit: And if you wanted, say, a 5-byte name:
Code:

It's true that the app header doesn't have to be 128 bytes, and that the app name can be shorter than 8 bytes, but it's recommended to keep it at 8 and pad it with spaces, even by TI, because of OS bugs that don't properly check that field length. I know the OS does explicitly handle spaces when comparing app names (such as when you try to find one with _FindApp).

It's possible those bugs have since been fixed, though -- just wanted to provide a little background on how that started.

Okay then! Taking all that into consideration, I edited the app.inc file for support with the CSE version. You can use it to build apps relatively easily now. I decided to leave the packing on there, because hey, TI cares.

App Builder
This should work. Hope this helps!

Thanks a lot!

I got a TI-84 Plus CE yesterday, which of course is programmed with eZ80 Assembly rather than Z80 Assembly. I am unfamiliar with eZ80 Assembly. I know that I have to change some of the addresses, but what else needs to be changed to get the password program to work on a TI-84 Plus CE?