For that, you need an assembly program. For example, name the program prgmALOCK and use Asm(prgmALOCK before the Input command:
AsmPrgm3E51FD7712C9


Also, I noticed that elsewhere you said this was for a school project ?

Update!

There was a pretty bad bug that I ran into a while ago while modifying the program and I wasn't sure what caused it. I finally tracked it to the root of the problem today by luck because I had no idea what to look for. It turned out that four bytes of code that I commented out were actually needed in a certain rare situation.

So that is fixed, and I added the NEW() command so that folders and files could be created whenever they were needed. As well, I added the SINSRT() command to insert a string of data into a file. It is not complete as it only inserts at the beginning of the file, but it is the start of a set of commands that I have been planning on working on. As well, you can now use the OS Ans variable, if it is a string, in place of string arguments and you can use OS String variables.
Here is an example:
:Input "Name:",Str1
:dim(-1             ;start a block of FileSyst code
:CD(Game/Str)
:NEW( Name.str)
:SINSRT( Name.str,Str1)
:Return             ;Exit the block of FileSyst code
That will create the file Name.str in folder Game/Str and fill it with the contents of Str1.


I am sure there are still bugs, so take care, but the download is here. I also updated the example program a little bit, but not much. In particular, renaming files seems to have problems and I haven't looked to see if that is a problem in FileSyst or prgmGUI.

EDIT: I added in the DELB() command to delete a given number of bytes from a file at a given offset. It properly handles when the offset is beyond the file data, when the number of bytes deleted would go beyond the file and other potential issues. I also added an offset argument to the SINSRT() command and it handles when the offset goes beyond the file by simply appending the string to the file. I won't be back for 5 or 6 hours, but if I am not too tired, I will try to add in commands for line reading/writing/overwriting. I will then want to add the ability to parse FileSyst code directly from archive and have user defined functions. I already have a bunch of other things planned, though, so I should try not to get too far ahead of myself Needless to say, the commands and a few of the routines that I added today have been on my To Do list since week 1.

The only trouble will be that you need to have a custom interrupt to make sure the OS doesn't throw an error. Hopefully somebody with time comes along to help Essentially, you would need the ONBLOCK program active to prevent ON causing an error, then a separate program to scan for key presses and ON. That would essentially be:
AsmPrgm
DB03
E608
EE08
2003
3A3F84
EF8C47
EFBF4A
C9
It returns 8 if ON is pressed, else it returns the values in the link that dinosteven linked to.

Wow, I was about to vote, but then willrandship posted and I was like Now I am stuck between two o.o

I am not exactly sure of what you mean, sorry Grammer 2 doesn't compile anything, so I am not sure where that would help out at the moment (but compiling is in the plans for Grammer 3). However, there are tricks for working with labels to make them faster, such as precomputing their location and storing them to point variables. This way, you don't need to constantly look up labels.

Generate Mersenne primes and you are good to go. Mersenne primes are of the form 2^p-1 where p is prime (but not all prime p will yield a prime number with 2^p-1). Then multiply that by 2^p-1 and you have a perfect number. There are also some pretty decent prime tests for Mersenne primes.

Okay EDITING can be done like this:
Just archive the file, and create a copy in archive/RAM to edit. No need for extra RAM.
Might be slow, though.
By the way, theoretical App size could be as big as 1.07 gigabytes (1 073 725 440) but the largest I"ve ever sent to my calc was 15XX kilobytes (maximum size)... Tilp crashes on that stuff lol

Archive works like this:
You can turn a bit OFF, but you cannot turn a bit ON unless you erase the whole 64KB sector. That is the challenge.

I would also like to point out that 1.07 gigabytes is about 1000 times as much archive space as any of these calculators have Also, I think you are assuming that it uses a two-byte page size when it actually uses 1 byte. Apps are stored in a completely different format than other variables