Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Link on August 29, 2012, 02:05:01 pm
-
Well, was porting a few of my programs from Ti-Basic to Axe, and I've hit a stumbling block. I went through the docs, but can't figure out how to properly use lists in Axe (along with getkey).
Here is my first try for the Axe code:
:For(A,1,4)
:Repeat Ans
:getKey→K
:End
:Copy(K,L1(A))
:End
This waits for 4 key-presses and puts them in a list, but it doesn't work. For some reason Getkey only has unicode garbage, and even that doesn't seem to be saved to the list.
What am I doing wrong?
-
First of all, what is Axe 1.2.5 ? ???
Next thing, the getKey routine sucks. Using getKey(#) is a lot faster. But I xan see why you need the basic getKey command in your program so don't change it if you don't want :)
Also, the Copy() command copies from one pointer to another and needs a size argument, so yours should not work, and even with a third argument, it won't work. I guess what you want to do is K→L1(A) but it won't work either, see next point :P
Finally, the L1 list doesn't exist. L1 is a pointer to some free memory location.
You need to replace all your L1(A) by {L1+A}
This should work then :)
[edit] I didn't see it two minutes ago but you are using Ans, which is not an Axe variable.
Just replace this
Repeat Ans
getKey→K
End
by this
getKeyr
→K
or this
0
Repeat
getKey
End
→K
-
Thanks, really appreciate it :D also I meant Axe 1.1.2, was probably thinking about something else :p. Also it works :D Gotta love axe.
-
Thanks, really appreciate it :D
No problem. Omnimaga is really the place to be if you need help with Axe. I got help too when I needed it so I am just giving back ^^
Also, I edited my post like 9 times, not sure if you saw the last version of it.
Moreover, I only think of it now but {A+L1} is more optimised than {L1+A} ;)
-
When I saw the title I was starting in fact to wonder where you got Axe 1.2.5 O.O
By the way welcome to the forums. I hope you enjoy your stay and Axe programming.
Just an off-topic question: Noticing your location in your profile, do you live right on the US/Canada border?
-
Yea, mistake on my part, also thanks :D, Finally No, I do move quite often between them, about very few months. Also do you think you can tell me what's wrong.
Now I have the lists (L6), and put data in it with K->{B+L6}. However it doesn't seem to actually be put in the list?
-
Are you drawing anything to the screen? Remember that L6 is actually the main buffer that holds the screen data, so if you use any drawing or text commands it'll overwrite whatever you have there. (Same thing with L3 and grayscale drawing commands, since L3 is the buffer used in grayscale drawing.)
-
Whoa, did not know that. should I use L1 instead then?
-
It's all in the documentation (Commands.html):
L1 = 714 bytes (saveSScreen) Volatility: LOW
L2 = 531 bytes (statVars) Volatility: LOW (Do not use this area when custom interrupts are enabled, including Mirage OS)
L3 = 768 bytes (appBackUpScreen) Volatility: MED (Saving to back-buffer will corrupt)
L4 = 256 bytes (tempSwapArea) Volatility: MED (Corrupt when archiving/unarchiving in program)
L5 = 128 bytes (textShadow) Volatility: MED ("Disp","Output", and "ClrHome" will corrupt)
L6 = 768 bytes (plotSScreen) Volatility: HIGH (Any buffer drawing will corrupt)
-
Hmm, i'll try to do a custom list then. But when I do say LKEY, it says it doesn't exist?
-
You have to define LKEY first. The L1–L6 pointers already point to specific addresses in RAM—that's why you can use them. If you need more data space, you'll need to clear enough room for it in your program using Buff( and assign it a GDB#, Str#, or Pic# name. For example, you could do:
Buff(256)→GDB0
Now you have a two hundred fifty-six–byte area you could use like any of the L1–L6 areas.
The difference is that the new buffer you created is actually in the program memory, so that command instantly adds 256 bytes to the size of your program.
-
Oh, okay then, is it possible to create something with Buff that is permanent?
-
What do you mean by "permanent"?
-
Something not in program memory, something that can be accessed from multiple programs?
-
You'll have to store it in a user variable, like an appvar. There's a tutorial on it here (http://www.omnimaga.org/index.php?action=articles;sa=view;article=58).
-
Okay, thanks, last question, I compiled my axe program, but when I try to edit the soucre again, everything is black and white random letters, jittering and then crashes and RAM clears. The rest of the calc is fine though.
-
Your program probably corrupted the RAM at some point. That may not cause a crash immediately.
-
So, would a RAM clear fix that?
-
Yep. Get used to it—RAM clears will be your friend :D
-
That didn't work, actually I can't seem to edit any of my programs.
-
what exactly did you do, and what exactly are you seeing?
oh, and expanding upon the idea from earlier, axe doesn't have any high level data structures whatsoever; everything in RAM is just a byte to it, and it is up to you as the programmer to determine how to interpret that byte/whether or not it is within a free ram area, to which you can write without affecting anything, or a chunk of ram in use by something else. L1 is not a variable, but rather a pointer (the address number of a specific byte in ram) that is a free area your programs can write to without fear of corrupting anything. that free space is only 714 bytes, though (it's actually 768, but the first chunk is used by axe's variables a-theta, which can be moved with the #Realloc command). if you write to a byte greater than {L1+713}, you will be writing to space that other OS processes use, and thus can corrupt things quite easily.
-
I have no idea, just using my calculator, What I see depends, sometimes it shows text, with unicode symbols and stuff. Flashes black and white *.*. Then freezes the calc. Other times just a simple RAM RESET after a blank screen and flash of the word "PROGRAM"
Edit
Solved it with a full flash clear.