Well, you don't want to overwrite other stuff, which might happen

IIRC there's a b_call(insertMem) or something like that. Dunno how it works, though.

Also, you could create a new var each time it updates, then delete the old one. Might be slow, but probably not that slow.

But the most secure way to edit stuff that I know of is probably to make a var that's sufficiently large to begin with

Could anyone tell me how to move the pointer back by one entry in the VAT?

It's kinda weird since each VAT entry is a different size, but to go to the next VAT entry (backwards), here's what you do. I haven't tested it yet, but it should work.

If A is the VAT pointer pointing at the first byte of the current entry, first subtract 6 to get to NL (the byte that tells you the length of the name of the VAT entry):

Code: (Axe) [Select]

:.A is currently at the first byte of the VAT entry
:A-6→A

Then subtract the value stored there, which should move you to the end of the VAT entry:

Code: (Axe) [Select]

:.A points to a value that tells you how long the rest of the VAT entry is
:A-{A}→A

Then subtract one more to get to the first byte of the next entry:

Code: (Axe) [Select]

:.A is at the end of the VAT entry
:A-1→A

To put it together:

Code: (Axe) [Select]

:A-6→A-{A}-1→A

For more info, here's a page that tells you how the VAT basically works.

Umm, I don't think that would work... That's just another way of doing what Quigibo's code that goes to the next entry does.

Like a linked list, it is impossible to transverse the list backwards.  You would have to start at the beginning again and then iterate through the list until you get to the N-1th item.  Generally this is pretty fast though unless you have over 9000 items on your list.  That's how the calculator "scrolls up" on your program list*.

*_{kind of becasue it also has to sort alphabetically.}

Oh really? I beg to differ:

Code: [Select] .Get Previous Entry .Returns 1 if start of VAT or 0 otherwise Lbl VPV P+1→P While {P+1→P}≥8+({P+2}≤ᴇ40) End P+6→P={ᴇ9830} Return

Code: (Explanation of what the hell I'm doing) [Select] Skip the first byte in case it's the F# byte for a list or a DCS folder # Keep advancing until {P+1→P} is a valid NL and {P+2} is a valid DAH Optimized version of Repeat {P+1→P}≤8 and {P+2}≥ᴇ40 Move forward 6 bytes to start of entry and signal if at start of VAT

Unless some cretin (possibly the same one who left the CPU in Mode 2) messed with the VAT so a name besides L₁-L₆ contains a byte with a value of less than or equal to 8 in it, this should work. (Can someone please verify my belief that DAH will always greater than or equal to 0x40?)



*Pats self on back for doing something even Quigibo thought was impossible*


EDIT: Will also correctly deal with DCS folders!

What about pictures, strings, and lists?  Those have a _E00-_E09 byte built into their name and could incorrectly be read as a valid NL.  I'm not saying its impossible to do, I'm saying its impossible to do and have it work correctly in every possible situation.  I'm sure someone could have some kind of hacked variable or something that would break your system.

Well I know pictures are stored in the other section of the VAT, and although I'm not sure about strings, I believe they are also stored in the other section. However, lists are in the section we're concerned with, which is the point of the {P+2} check. If the name is a two-byte token for L₁-L₆ and {P} is detected as the byte in the token less than or equal to 8 (the byte of the name found earlier in RAM), then {P+2} will always be NL, which can never be greater than or equal to 0x40. If {P} is the NL byte, though, then {P+2} will be DAH, which is always greater than or equal to 0x40, so this will be positively identified.

And yes, if someone has hacked, invalid VAT entries, that could potentially break my system, but there's really no reason that should ever happen. Unless they were mucking around with the VAT themself, in which case it's their fault anyways if VAT reading code fails.


EDIT: Speaking of hacked VAT entries, I just remembered that DCS makes programs called "%FLDn" to handle its folders, where n can be any byte, so could be less than or equal to 8. However, this would be avoided in the initial skip over the first byte, which I originally had only in case it was a formula byte for a list. Now it looks like the skip performs double duty

Hi everyone! This is my first post as this is the topic that finally made me join the community.
Anyways, I spent a while looking through the list of b_calls and their documentation in the Ti 83+ SDK System Routine documentation, and noticed 2 very interesting routines. On pages 381-384, the routines FindAlphaUp, and FindAlphDn can be found. They are (I think) the routines the OS uses to search the vat. It can search partial names, all types, and some other stuff. I would think making axioms or just putting the commands into Axe itself would be the best way of searching the VAT. (I've been wanting this for a while).

EDIT: No, I am not an ASM programmer so I cannot do it myself. I am just good at finding information.

Hey Binder News, welcome to the forums

(For a short second I thought you were a bot, due to the "News" part of the nickname, until I saw you had an avatar and a calculator post )

Well you would probably need to ask in the Features Wishlist topic, as he will see it faster there. However he is busy so he might still take a while to respond.