Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: yunhua98 on October 18, 2010, 05:48:38 pm
-
Is there a way to access moar variables in Axe? Like the Finance variables for BASIC, or something like lists? or can the Axe lists do this? if so, I need to figure out how to do it. ;)
TIA 8)
-
if you need more variables, there are several option open to you. In portal, i use memory locations for many variables. Like {L1+13}r is the same speed and takes the same amount of memory as the variable A.
-
{address}r is the same as a regular variable.
Ex:
{L1}r
{L1+8}r
{L4}r
{oA}r (This is the same as just doing A)
Good luck. :)
Edit: Ninja'd O0
-
could you elaborate on that a bit? How would you know which ones are usable?
EDIT: I was replying to Builderboy
-
you can use any portion in the free RAM areas L1-L6 as your own variables.
-
you can use any portion in the free RAM areas L1-L6 as your own variables.
I see, so if I did 5->{L1}, and then wanted moar variables, I would do 42->{L1+1} but if I wanted to store a two byte number, would I do 256->{L1+2}r?
-
yes. be careful about it though. if you do 256->{L1+2}r, make sure you don't try to make a variable at {L1+3}, because this is already being used by the two byte variable at L1+2
-
which RAM area would be best and most stable to use?
-
L1. Read up on it in the commands list if you want more info. :)
-
And don't write beyond the limits of L1. That is called an overflow error and strange and terrible things will happen to your calculator as a result.
-
yeah... just don't use more than 700 bytes worth of variables and you'll be fine (like you even need 350 variables)
-
L1. In that area of safe RAM (the 54 bytes before where L1 points) is where the built-in 27 variables reside, too.
EDIT: Mega ninja'd.
-
Note that in some cases, using L2 might cause incompatibility with MirageOs for the people that still uses it. It conflicts with Mirage's interrupts.
I personally use L1 most of the time.
-
ok, thanks guys! as for the commands list, well, lets just say I find it a bit hard to understand at times. :P
EDIT: 600 posts!/me anticipates becoming evil. >:D
-
Btw with L4, it talks about corruptions with the Archive/Unarchive. Does it means the Axe archive/unarchive commands or the entire TI-OS after exiting your program?
-
It means that if you unarchive/archive in Axe during the running of your program, the data in L4 will no longer be there. :)
-
Oh, and yunhua98, use 2-byte storage for most uses. It's one byte less than one-byte vars (weird, I know, but that's just how it works).
-
It means that if you unarchive/archive in Axe during the running of your program, the data in L4 will no longer be there. :)
Ah ok, good to know. I was worried that weird crap could happen during archving/unarchving
-
Oh, and yunhua98, use 2-byte storage for most uses. It's one byte less than one-byte vars (weird, I know, but that's just how it works).
...wait really? I never knew that :x
-
Oh, and yunhua98, use 2-byte storage for most uses. It's one byte less than one-byte vars (weird, I know, but that's just how it works).
Waitwhat? Two byte storage is one byte *less* than one byte? ???
-
Yeah, it's weird, but I think I know why.
is one byte less than
because in Axe, numbers are treated as two-byte numbers for all operations (because it's all stored in HL, which is a two-byte register). So when Axe sees that 1, it loads 0001h to HL. Then when you store it to a one-byte space, it has to first load L (the single-byte portion of HL) to A (which is like HL for one-byte numbers), then stores it from A. On the other hand, if you're storing to a two-byte space, it just stores HL straight there.
EDIT: Of course, if Axe 2.0 (or whatever that was called) uses one-byte operations, it won't be this way :)
-
Ooooooh gotcha i didn't know you meant memory in code, i thought you meant 2 bytes numbers used 1 less byte for storage than 1 byte numbers ;D
-
No, TI's code isn't that bad XD
-
At least not the RAM addressing part of their code...