Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: E37 on October 27, 2015, 05:16:20 pm
-
So... I've been trying to make a program editor with Axe that acts like the default editor but with the small graph screen sized text.
The large font has been annoying me lately and I could see more with the smaller font size.
My current attempts have lead to multiple RAM wipes and wierd font.
Can anyone point me in the right direction? Is this really hard or just impossible (maybe I am missing something really obvious). ;D
-
It's certainly not impossible to build your own program editor. However, there are lots of OS calls that would assist in providing functionality of the OS editor that you don't have access to in Axe. Namely, you'd have to handle input entirely yourself, translating keypresses to tokens and making your own menus.
If there are any specific problems you're running into, ask directly about those.
By the way, if you simply wanted a small font program editor to use, there's a version of zStart that replaces the OS editor with one. It was released in a mostly completed state when the developer was more or less stopping calculator development, so there may be a few things wrong with it that won't be fixed. But I think it works for the most part. And zStart provides other nice features, especially for Axe developers, so you should have some version of it anyways. If you're interested, grab the proper version attached to this post (https://www.omnimaga.org/ti-z80-calculator-projects/zstart-an-app-that-runs-on-ram-clears/msg378608/#msg378608) (the first is for the 84+ and the second is for the 83+).
-
Thanks! All I was trying to do was enable the small font size editor.
I looked through zStart (I already had it installed) and I couldn't find how to enable it.
Also, I heard it could let you jump to labels and couldn't find that feature either.
On the subject of reading files, I've tried to convert compiled programs to hex using the >Hex command.
I got the program to work but the code doesn't work.
Is it possible to convert a compiled program to hex?
I want to run some asm commands in Axe that don't exist (like powering the calc off).
Edit (Eeems): Merged double post.
-
Isn't that what the Asm( token is for?
Asm(HEX) Native assembly code written in hexadecimal is inserted at the current position.
-
Yes, I am trying to convert compiled asm code to hex to run in Axe.
I just used to power off feature as an example.
I am also just trying out different commands. I never know when this knowledge might be useful! ;D
-
Yes, I am trying to convert compiled asm code to hex to run in Axe.
I just used to power off feature as an example.
I am also just trying out different commands. I never know when this knowledge might be useful! ;D
Then you'll want to use this tool (http://asmtools.omnimaga.org/) to "unsquish" the program into the hex bytes.
-
Yes, I am trying to convert compiled asm code to hex to run in Axe.
I just used to power off feature as an example.
I am also just trying out different commands. I never know when this knowledge might be useful! ;D
Then you'll want to use this tool (http://asmtools.omnimaga.org/) to "unsquish" the program into the hex bytes.
Thanks!
Do you know how to enable the small font on zStart?
-
I think only the specific version that Runer112 linked to has that feature.
If you're interested, grab the proper version attached to this post (https://www.omnimaga.org/ti-z80-calculator-projects/zstart-an-app-that-runs-on-ram-clears/msg378608/#msg378608) (the first is for the 84+ and the second is for the 83+).
-
I loaded it in wabbitemu and the version numbers are the same.
When I looked through it it was the same.
Also, through the getcalc( command is is possible to create self modifying code assuming you knew what you were doing?
-
I loaded it in wabbitemu and the version numbers are the same.
Since the small font editor version was not actually officially released, I think the author didn't increment the version numbers. Perhaps the easiest way to know if you have this version or not is that all previous versions of zStart are only one page (16834 bytes) large, while the version with the small font editor is two pages (32768 bytes) large. Also, you can't actually turn the small font editor off, so you'd certainly know if you had it.
Also, through the getcalc( command is is possible to create self modifying code assuming you knew what you were doing?
Self-modifying code is certainly doable in Axe if you know what you're doing. But I'm not sure how GetCalc() would factor into it without knowing more about your intent.
-
I am writing a program to restore some of my files (after RAM clear thanks to zStart) and I am using the copy command.
Does the size command {pointer-2} not work of files? It works fine if I just manually input the size but otherwise it just copy's one bite.
On a different subject is there a way to run already compiled programs (including the ability to call subroutines) to bypass the compiled code limit?
I know about axioms to circumvent this need but I would like to not have to use them.
For self modifying code what numbers correspond to which command tokens?
-
I am writing a program to restore some of my files (after RAM clear thanks to zStart) and I am using the copy command.
I'm skeptical that zStart would actually cause a RAM clear unless it was abused a bit... but anyways, you should really keep all your source code archived to keep it safe, since zStart lets you edit archived programs.
Does the size command {pointer-2} not work of files? It works fine if I just manually input the size but otherwise it just copy's one bite.
As far as I know, that works for files. Make sure you're reading a 2-byte value by appending r to the closing brace. If this isn't the issue, I can't immediately offer any ideas to fix it.
On a different subject is there a way to run already compiled programs (including the ability to call subroutines) to bypass the compiled code limit?
I know about axioms to circumvent this need but I would like to not have to use them.
I know you said you'd like not to use Axioms, but there's really no easy way to do what you're specifying without one. Specifically, the RunPrgm Axiom (https://www.omnimaga.org/the-axe-parser-project/(axiom)-run-(unarchived)-external-assembly-programs/) lets you run external assembly programs. If you wanted to run specific subroutines, you'd need to create your own convention, but that shouldn't actually be that hard.
But before turning to this, there may be a few less radical ways to solve this problem. If the issue is that you're running into the executable code limit, which is about 8KB, try compiling your code as an application or using the Fullrene Axiom (https://www.omnimaga.org/ti-z80-calculator-projects/fullrene/msg253452/#msg253452). Both remove the executable code limit, although the total size of your code and data combined is limited to 16KB for applications and however much RAM the user has available (you can generally expect about 20KB) for programs using Fullrene. Also, Fullrene is known be a bit unreliable.
If the issue is that your application or program is too large due to containing lots of data, try externalizing data into appvars to keep the size of your actual program to a minimum. There's no clear/documented way to do this, but if you'd like to, ask and ye shall receive help.
For self modifying code what numbers correspond to which command tokens?
If you're aiming to change more than just a numeric value in code, SMC is probably not the way to go, because code can vary wildly in size and format based on what it's doing. In what context are you imagining using SMC? I'd imagine that there's probably a more reasonable solution.
-
zStart dosen't cause any ram wipes I meant that zStart would run the restore program.
For self modifying code I would like to try to have the program insert a comment when I overflow an array (which I commonly do).
I am not sure how to check for an overflow. I know I could just display text to the screen but SMC is way cooler.
-
SMC generally means modifying the currently-running executable, which is different from the source code. So even if you did this, the results would not be visible later. Simply displaying information like this is the easiest (and the sane) way to go.
-
I have decided to go ahead with the small font program editor. So far I have have figured how to convert back and forth form decimal and tokens (If = 206).
I am not sure whether to go with writing out programs by letters (which would be easier to display and make the editor smaller) or by tokens (which would make the editor much bigger but the saved files smaller).
It looks like reading and writing the programs will be the hardest part (so I can compile code written in the editor or edit it in the basic editor also).
It would be really cool if it could display code like "{L1 +8}" as "boss1hp" if the user declares the name. That way variables can have really long custom names and there (theoretically) is not a name limit.
Any ideas (or ways to do any of this) would be awesome!
-
I am not sure whether to go with writing out programs by letters (which would be easier to display and make the editor smaller) or by tokens (which would make the editor much bigger but the saved files smaller).
It looks like reading and writing the programs will be the hardest part (so I can compile code written in the editor or edit it in the basic editor also).
If you want your files to be usable by anything else on the calculator, tokens are the required format.
It would be really cool if it could display code like "{L1 +8}" as "boss1hp" if the user declares the name. That way variables can have really long custom names and there (theoretically) is not a name limit.
For editing Axe programs, which it looks like is what you're alluding to, I don't think such a feature would need to be supplied by the editor. The Axe language already lets users declare named constants/variables. In your example, the user would declare L1+8→°boss1hp and could then refer to it as the one-byte variable boss1hpr throughout the rest of the code.
Is there any way to convert between the program editor tokens and the display tokens without way too many if statements?
You mean displaying the string represented by a token code? Using the ▶Tok conversion (http://axe.eeems.ca/Commands.html#textCommands) with a display command does this.
-
For the tokens I have decided to have the program written out in letters so it is easier to display and have it convert each command to token form when the user quits.
As I understand Axe has a limit on the number of named variables (around 150?) and this would bypass that since when it is written to the program it would be written as {L1 +8}
I must be missing something on the >Tok command. When I ask it to display {A} (or {A}r) >Tok, it displays a completely different token.
When I tell it to disp If >Tok it outputs Xscl instead (it is reading the if from a program) or a long string of gibberish.
-
For the tokens I have decided to have the program written out in letters so it is easier to display and have it convert each command to token form when the user quits.
I wouldn't suggest this method, but it's ultimately your decision.
As I understand Axe has a limit on the number of named variables (around 150?) and this would bypass that since when it is written to the program it would be written as {L1 +8}
It depends on how long your names are, but it's closer to 1500 than 150. I can't imagine a program using that many named constants/variables, or if it did, it probably wouldn't matter because it would be too large to fit in RAM and actually be editable.
I must be missing something on the >Tok command. When I ask it to display {A} (or {A}r) >Tok, it displays a completely different token.
The OS calls for displaying tokens require a pointer to the token to be displayed. And Axe uses these calls to implement ▶Tok, so the same applies. I presume this decision was made because tokens are almost always displayed as part of a program or string in RAM, and putting the read in the call saves callers from having to do so. Since you're also editing a program in RAM, this decision should actually make your code simpler. Just drop the curly brackets for the memory read.
-
I must be missing something on the >Tok command. When I ask it to display {A} (or {A}r) >Tok, it displays a completely different token.
The OS calls for displaying tokens require a pointer to the token to be displayed. And Axe uses these calls to implement ▶Tok, so the same applies. I presume this decision was made because tokens are almost always displayed as part of a program or string in RAM, and putting the read in the call saves callers from having to do so. Since you're also editing a program in RAM, this decision should actually make your code simpler. Just drop the curly brackets for the memory read.
It works! Since I can use the tokens directly I am definitely using the tokens instead.
How would I write tokens back to the program? "token" -> A doesn't work
-
How would I write tokens back to the program? "token" -> A doesn't work
→{A} for one-byte tokens and →{A}ʳ for two-byte tokens.
EDIT: And if you're using tokens, you probably shouldn't have to have their string data anywhere in your program. You should just be using the token codes, which (as previously suggested) are one- or two-byte values. In case you weren't aware, you can get the value of most tokens in Axe with the Ttoken syntax.
-
"Then"->{A} Puts a completely different character in the program.
edit: I needed the t character.
Is there a way to tell if a token is one or two byte when you display it?
-
Is there a way to tell if a token is one or two byte when you display it?
All two-byte tokens have one of the following hexadecimal values as their first (low) byte:
5C 5D 5E 60 61 62 63 7E AA BB EF
For the purpose of displaying a token in Axe, you shouldn't need to do anything different for one- or two-byte tokens. I guess that could be another reason why the input for displaying a token is a pointer rather than an actual token value. The display function can tell if it's a one- or two-byte token after reading the first byte and then only read the second byte if necessasry.
-
Awesome! The only other thing I need to know (for now) is what is the best way to find a program's size?
Is it with the length( command or with {ptr - 2}?
edit: is there a way to get (not set) the cursor's position?
-
Awesome! The only other thing I need to know (for now) is what is the best way to find a program's size?
Is it with the length( command or with {ptr - 2}?
{P-2}r is the correct way to read the size of a program, appvar, picture, string, or equation variable pointed to by P. Note the r modifier, which was missing from your otherwise correct second suggestion.
edit: is there a way to get (not set) the cursor's position?
Since you're working on a small font program editor, I'm going to assume you mean the graph screen cursor, which is actually called the "pen," rather than the home screen cursor.
The pen cloumn is stored at penCol = 86D7h and the pen row is stored at penRow = 86D8h. Each are one-byte values, so you could read them with {ᴇ86D7} and {ᴇ86D8}. But if you plan on referencing them a lot, you should probably turn these into named variables with statements like ᴇ86D7→°PX and ᴇ86D7→°PY and then reference them with PXʳ and PYʳ.
-
So far it is able to read programs in small font. I will (obviously) add writing next.
The program it reads (itself) is still hardcoded in but here is it so far...
I haven't done anything with the pen yet.
-
So far I have everything done but the ability to add to the program (you can delete).
Is there a way to display the custom tokens? I can't seem to find a good way to choose tokens without creating a program with them or by chaining if statements.
-
Is there a way to display the custom tokens? I can't seem to find a good way to choose tokens without creating a program with them or by chaining if statements.
I'm not sure what you mean. Could you elaborate?
-
When I display tokens to the screen it shows the basic tokens. Is there a way to allow the program to check which tokens should be changed?
I have decided to just create a program to display the tokens.