Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: squidgetx on February 20, 2011, 03:19:54 pm
-
Let's write another tutorial (I'm just in the mood today) Anyway, this'll talk about the VAT, specifically, the symbol table of the calculator where programs, appvars, and protected programs are found. Ever wonder how Axe displays a list of all the Axe programs on your calculator? Well, read on!
1. What is the VAT? (By VAT, I actually mean program table, even though that's not really what VAT means)
The VAT is a chunk of user RAM that keeps track of every program/prot prog and appvar in your calc. If you notice, when you delete a program in archive, you still free up some RAM; that program's table entry is erased.
Every entry in the VAT is backwards (annoying), and structured in the following manner: ==============================================
| -(n+6) -6 -5 -4 -3 -2 -1 0 |
==============================================
| VarName N.Len Page DadrH DadrL Ver T2 T |
==============================================Now for an explanation of each part:
T: Sort of important but not really: the first five bits are used to identify which object type the variable is. We'll get into this later.
T2: Completely useless to us. Ignore.
Ver: Tells the OS whether or not it can be sent across certain OSs. Ignore.
DadrL: More important: Tells us the low byte of the address of this object.
DadrH: The high byte
Page: What flash page? If in RAM, it'll equal 0.
N. Len: How long is the name
And from here, we have the name of the object (backwards)
Now, the location of the VAT is always changing. Fortunately the calculator stores it for us at address $9830. The address of the end of the VAT is stored in $982E.
Here's a code example on how to set up a loop that goes through the VAT, one entry at a time...{e9830}^^r->E //set up
While E>{e982E}^^r //While we're in the VAT
For(F,0,14) //Copy backwards to L1. For some reason I couldn't get Copy()r to work...
{E-F}->{F+L1}
End
...stuff. Now you have your VAT entry sitting in L1...do what you want with it.
E-{L1+6}-7->E //Increment the pointer "position" appropriately. Every entry is a different length, depending on the name length.
End
Now, you can use the value of {L1+3}r+2 as a pointer to the object without even needing a GetCalc statement. This even works with file pointers as well, storing {L1+3}r+2 to {oY1}r and {L1+5} to {oY1+2} allows you to use Y1 normally as well.
-
Nice.
One thing I wanted to say was that the T2 byte actually has some use. DoorsCS uses it to determine what folder a program is in.
-
Nice, should be useful to some people eventually. :D
-
Sorry for reviving, but can we use the VAT to rename variables? I've always wondered why doors can't rename files bigger than ram...
-
I don't believe i've seen a function to do that anywhere
-
While there are no OS functions to rename a variable in RAM, it is possible to do manually with a bit of work. However, it is not possible* to rename a varaible in ROM, since the VAT entry is duplicated in ROM, which cannot be modified.
* Technically possible, but to do correctly would involve a fair amount of manual flash operations essentially equating to a full user archive space defragmentation. There are probably only a couple of assembly programmers who could even pull this off.
-
I made a program for changing a variable's name (in RAM, as @Runer112 pointed out). Essentially, I made a new variable of zero size with the name I wanted. Then I just swapped all the VAT info except the names, and deleted the original.
This is probably the easiest way to do it, though somewhat slow and it requires up to 17 bytes of free RAM available.
-
@Xeda112358 What if you just changed the name directly?
-
@Michael Pang That's also a viable strategy, but an issue arises if the new name length isn't equal to the old. You'd then need to expand or contract the size of the name field of the entry, which would mean also shifting the rest of the VAT and the operator stack in memory.