Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Michael_Lee on August 09, 2010, 12:17:13 pm

Title: A few simple questions...
Post by: Michael_Lee on August 09, 2010, 12:17:13 pm
Hi - Axe is great, isn't it?  I just discovered it last week.
I have a few questions though:
1) How do pointers work?  I think I understand the basic concept, but I'm not entirely sure what the difference is between doing this
Code: [Select]
5->A and
Code: [Select]
5 ->{A}2) Also, I tried using the routine in the User's Manual to try to copy an external variable, but I keep getting this weird sort of hexadecimal thing
Code: [Select]
"varG"->Str1
GetCAlc(Str1)->P
Disp {P}[sup]r[/sup]>DEC          (The triangle with the DEC to the right)
And this gives me weird values - especially if I try storing decimals, large, or negative values to G.  Am I doing this wrong? 

I apologize if any of these questions are stupid...  :(
Title: Re: A few simple questions...
Post by: _player1537 on August 09, 2010, 12:20:59 pm
Do you understand the concept of ram?  There is a way to access the ram, and edit it.  So say that there is some ram at spot 1337 that you want to edit.  One way you could do this is:
1337->A
Data->{A

Another way (faster) would be:
Data->{1337

I'll try to explain it a little better in a minute if someone doesn't beat me (not saying that you shouldn't try to beat me to it)
Title: Re: A few simple questions...
Post by: yunhua98 on August 09, 2010, 12:24:59 pm
I'm not an expert with Axe, and I haven't tried the external variables thing, but I believe the difference between the first two are storing a value to a location and storing a location to a pointer.  (Am I right?)
the first one stores the value to the pointer, while the second one puts the pointer at the location 5 on RAM.
And don't worry about asking questions you think may be stupid, because we are all here to help.

If I'm wrong about this, will someone please correct me?  I find myself having trouble with pointers as well, this may or may not be why.  ;)

Title: Re: A few simple questions...
Post by: Quigibo on August 09, 2010, 12:31:15 pm
Glad you like it!

1) The first one stores the value 5 into the A variable.  The second one stores a value 5 somewhere in ram at the address A.  You can think of memory as a bunch of boxes, so if A were 1000, you'd be putting a 5 into the 1000th box.  But there are only a few boxes you can use (the free ram) since the operating system uses so many of them.  So don't actually try storing anything to {1000} because that's OS territory.  Overwriting OS stuff is a common cause of ram clears.

2) Real Numbers are stored in the most bizarre format so its extremely hard to read them, I will be adding a converter command eventually.  The first byte is some kind of bit field that also controls the negative sign, the next byte holds the exponent and then the next 7 bytes after that holds the number, but in BCD format (binary coded decimal) so you can't just read it off like a number.
Title: Re: A few simple questions...
Post by: _player1537 on August 09, 2010, 12:31:49 pm
The way I read that code is:
store 5 to A
and
store 5 to at A

Because first stores it to the variable A (which is just a location in ram [L1-54 iirc])  and the second one stores to the location of A.  So if A is 666, it will try to store 5 to the location 666
Title: Re: A few simple questions...
Post by: DJ Omnimaga on August 09, 2010, 12:39:57 pm
I recommend against storing to RAM values you are not sure what they are. To store temporary data, I recommend using L1, for example. Those are called SafeRAM areas (idk if I spelled it right) and in L1, for instance, there is about 712 bytes of space to store stuff. Be careful when using the others, though, such as L2 through L6. You need to check the commands.html file to see what they may conflict with.

Also welcome to the forums. Glad you like Axe :)
Title: Re: A few simple questions...
Post by: nemo on August 09, 2010, 01:39:28 pm
just wanted to add in that with external var support, you should generally stick with storing to Strings and appvars. lists, matrices and real variables have complicated formats so they can hold large numbers and decimals.

as for pointers, maybe this will help. imagine RAM as like a train. and each segment of the train is numbered: 0, 1, 2, 3, 4, 5 etc. It's very orderly. to get a segment of the train, you use curly brackets {}. {0} would return whatever number is in the first box of RAM. as quigibo said, do not overwrite this data, as the OS uses it, and you could easily screw up your calculator by just filling random addresses with numbers. However, quigibo has "safe RAM" areas in axe, which you can modify as you wish, as DJ said, they're L1-L6. L1-L6 are called "pointers". i personally like to call them in my head as "markers", since to me they mark segments of the train. each safe RAM segment contains a certain number of boxes. so 5->{L1} stores 5 into the box at L1. now i've been using the term "box" to describe each segment on the train, aka each segment of RAM. for the record, each segment of RAM is 1 byte. i won't get technical, but basically that means you can store between 0 and 255 into each box. if you try 256->{L1}, the numbers loop back around. so L1 will hold the value 0. 0=256. 1=257. i know. crazy. however, variables A-Z+theta can hold up to 65535.

variables have always intrigued me at first, as i never understood them in Axe. one more long paragraph:

A-Z+Theta are pointers. they point to a box number. 0->A does not store the value 0 into A. it tells A to "point" to RAM address 0. remember how L1-L6 are just "markers" on the train of RAM? same thing with variables. basically, you should rarely use curly brackets {} around just a variable, as that will usually turn out to be some information that the OS uses to run, and if overwritten, may RAM clear. basically, variables are like markers of RAM addresses.
Title: Re: A few simple questions...
Post by: Michael_Lee on August 10, 2010, 12:37:42 pm
Okay, so to summarize...
If I do 5->A, the calculator will create a (temporary?) variable, and store 5 to it?
And if I do 5->{A}, the calculator will go to location A in the RAM and overwrite whatever was there then store 5 to it?
And I should avoid using curly braces except for L1 and L2.
Stick to strings and appvars, because the other data types are weird.
Am I right?

Also, I have several more questions:
3) How much is a byte?  I think nemo said that 1 byte can hold up to 255, so would that mean that 1 byte is equal to 2 hexadecimal characters? (like FF would be 1 byte?)
4) DJ Ommimaga said that there are about 712 bytes of space in L1 (and probably L2) - so I would use those two if I wanted to construct a list of some kind?
5) What are the differences between the variables A-Theta and using Str, Pic, and GDB?  Is it safe to use curly braces around those?
6) I think curly braces are used primarily for creating lists in safe RAM spaces - my numbers would be in sequential order.  Is that correct?  What other things can pointers be used for?
Title: Re: A few simple questions...
Post by: nemo on August 10, 2010, 01:09:46 pm
you're somewhat right. you can treat A-Z and theta as normal vars as you would in BASIC (just don't go over 65535, negatives are a little trickier to figure out, and don't try to store a floating point). if you do 5->A, A will be a pointer to the RAM address 5. it's not really necessary to understand this. but you should know that doing Expression->{A} is generally bad, because you're overwriting RAM that the OS may need to function.
curly braces are your friend, if you're using L1-L6 and static pointers (GDB, Pic, Str). quick code example. say you have a list of 5 numbers. 2,12,38,25 and 3. how might you create this list?
Code: [Select]
.HEADER
[020C261903]->GDB1    .Stores the data as hexadecimal
Data(2,12,38,25,3)->GDB2    .Stores the same data in GDB2.
For(A,0,4
Disp {GDB1+A}>Dec,i       .imaginary i. GDB1 can be replaced with GDB2 for the same results.
End

alright. for starters, what are GDB1 and GDB2? they are static pointers. they basically mark some data. each piece of data is only one byte (two bytes is more advanced). curly brackets return the byte that the pointer points to. this is another way of saying that a curly bracket takes the marker (GDB1) and returns whatever is inside of it (2). since data is stored linearly in RAM, we can add one to GDB1 to get the next byte. {GDB1} will return what's at GDB1 (which is 2) and {GDB1+1} will return the next byte (12).

hopefully that helps. it takes awhile to get used to.

and yes, when you're using external variables, strings and appvars are the easiest to deal with.

3) yes. FF is one byte. F is a half-byte (also known as a "nibble"). a bit is either a 0 or a 1. a byte is 8 bits. meaning, a byte is 8 1's or 0's. since there are two possible values a bit can hold (a 0 or a 1), and a byte has 8 bits, a byte can hold 2^8=256 different values. 0-255.

4) in the Commands document, the lengths of L1-L6 are defined. using L1 is the safest to use, so i'd say that L1 is probably the best to use.

5) i kinda explained this above, but to reiterate. A-Theta are pointers, but the RAM they point to can be changed. Str, Pic and GDB are static pointers. that means you tell them what data to point to at the beginning of the program, and they will point there throughout the program. using curly braces around Str, Pic and GDB is definitely ok.

6) curly braces are used to get a value from a pointer. it's very useful for lists of numbers, such as map data. i'm not sure what other things pointers can be used for, a computer/ASM programmer probably uses them more creatively.
Title: Re: A few simple questions...
Post by: Michael_Lee on August 13, 2010, 01:48:27 pm
Mm - I've been messing around with pointers for a couple of days now, and I think I've sort of got the hang of it - or at the very least, I'm not going to do something stupid.  :P
So, thanks!

I have another question though - in the list of commands, it says something about interrupts - what are interrupts, and how do I use them?
Title: Re: A few simple questions...
Post by: calcdude84se on August 13, 2010, 02:05:18 pm
Interrupts are something the calculator generates at a fixed rate. The normal speed is about 110Hz, or 110 times every second.
FnOff will turn these off. This gives you slightly faster speed, and you can do some stuff you normally couldn't because the OS would mess with it (Like linking). However, you cannot use the normal getKey, but you instead have to use getKey(9) et al. (Well, if you use fnInt( you can't. But otherwise it would just turn them back on anyway) FnOn turns these back on.
fnInt( can be used to make your own interrupt. The normal interrupt is the OS's and does stuff like check for keys, link activity, etc. To use your own interrupt, you use fnInt(LB,F), where LB is the subroutine you want to execute on the interrupt and F is how often to execute it. It can be 0, 2, 4, or 6 and must be a constant, not a variable.
Say you had a subroutine I. To make it an interrupt that executes as often as possible, you can use fnInt(I,0 to set it up.
The routine I will execute at 110Hz. Note that you shouldn't use DispGraph or either of its modified versions in an interrupt.
In addition, DispGraphrr might need an FnOn after it because it disable interrupts.
Title: Re: A few simple questions...
Post by: FinaleTI on August 13, 2010, 03:38:24 pm
In addition to calcdude's post, in the latest version of Axe, there is a bug involving the label you use for an interrupt.

Quote from: Runer112
Actually, you may be onto something. I assumed 0.4.3 fixed the label errors, but apparently it didn't. The problem appears to be with the fnInt()  command. As far as I can see, the problem is that, using whatever shortened character set Quigibo uses to store label name data (if I had to guess, 0-9 A-Z), the first character of the label name called is always misinterpreted. It seems that this character is stored with a value 10 less than what it should be. In one of my programs, I want to enable "INT" as an interrupt. When compiling, fnInt(INT,6) throws a missing label error, claiming that "8NT" is missing. fnInt(ZNT,6)  throws an error, claiming that "PNT" is missing. In both of these names returned, the first character has a value 10 less than what it should be. fnInt(SNT,6), however, compiles correctly, as S is 10 letters ahead of I in the alphabet.

This error only appears to happen with fnInt(), not sub() or Goto.
Title: Re: A few simple questions...
Post by: AngelFish on August 16, 2010, 12:42:05 am
I'm not entirely sure about the variables in Axe either.

I was trying to code a basic gravity simulation using a single pixel as a ball. What I ended up writing was:

Code: [Select]
.AA
ClrDraw
47->X
5->Y
0->V
Rect(0, 60, 96, 4)
For(A, 0, 200)
DispGraph
V-9.8->V
Y+V->Y
Pxl-On(X,Y)
Pause
If Y+2V>60
-V->V
End
End

When the code is compiled and run, it displays the initial graphics and then runs the rest of the program without moving the pixel. Looking at the documentation accompanying Axe, I can see that the included Pong program uses similar variable assignment, so I'm unsure of what exactly the problem is. Any help would be greatly appreciated. Axe takes a bit of getting used to, although the speed is a breath of fresh air after TI-BASIC.
Title: Re: A few simple questions...
Post by: Builderboy on August 16, 2010, 12:47:09 am
Well im not sure what the compiled program is doing, but i know what the problem is

V-9.8->V

Axe works with integers only, so this line doesn't do what you think it does.  I am surprised it actually compiles, but it might have to do with the fact that a period designates the start of a comment.  My guess is that it is reading the code like this

V-9

Which doesn't do anything to V, and so your velocity never changes, and your pixel doesn't move.
Title: Re: A few simple questions...
Post by: AngelFish on August 16, 2010, 01:14:54 am
No decimals? I suppose that I'd have to approximate with 10, then. That works, although it appears that I'll have to modify my formulae to get a more realistic "bounce." This simulation would be a lot more suited to a mathematically inclined language like TI-BASIC. Oh well, what's a challenge if not a chance to learn [and clear your RAM in the process]?
Title: Re: A few simple questions...
Post by: Builderboy on August 16, 2010, 01:22:26 am
There is a way to get a kind of 'cheating' decimals, although it can be hard to grasp.  Lets represent all of our numbers x256.  So 1 would be 256, 17 would be 4352 and so on.  This means that we can represent numbers with an integer, but with more precision.  128 becomes .5, 400 becomes 1.5625, and so on.  All the math is the same, all that needs to change is your display.  Instead of

Pxl-On(X,Y

you would do

Pxl-On(X/256,Y/256

And this gives you much more precision.  You might want to experiment with this, as it can be quite useful, but it isn't necessary to make a great game.
Title: Re: A few simple questions...
Post by: Quigibo on August 16, 2010, 01:25:45 am
What you can do is "inflate" the value to get more accuracy.  256 is a great number since it's very optimized in both division and multiplication.  Since Axe variables hold 16-bit numbers, you can use the lower byte as the decimal and the higher byte as the number.  9.8 can be represented by 9 + 205/256.  You get your inflated number by multiplying by 256 so that's 9*256 + 205 = 2509 == 9.8 as an inflated decimal.  You can treat this number like any other number.  If you add 1 to it, you're really adding 1/256th and adding 256 is like adding 1, etc.  When it comes time to display the point, just divide by 256 so that you recover the integer part for the pixel.  So you're doing math with the precision of 1/256th and then just drawing it to the nearest pixel.

EDIT: Damn!  I knew I'd be ninja'd :P
Title: Re: A few simple questions...
Post by: jnesselr on August 16, 2010, 01:31:37 am
Actually, since it is just to the tenth's place, you could simply have another variable to use as the tenth's place.  Then, subtract the 8 from it.  If it wraps around, say to 248 and above, then subtract one off the integer counter, and change the decimal to the appropriate number by subtracting 246. Just remember that a negative number is really that number +256. so -8=248.

This works in theory, and should work in code, although is not tested.

[edit] double ninja'd, but with a different  response.
Title: Re: A few simple questions...
Post by: Builderboy on August 16, 2010, 01:34:29 am
but wont it wrap around to 65536 since Axe is 16bit?
Title: Re: A few simple questions...
Post by: jnesselr on August 16, 2010, 01:35:25 am
Not unless he is dealing with 16 bit, I don't think.
Title: Re: A few simple questions...
Post by: Builderboy on August 16, 2010, 01:37:23 am
But axe variables are 16bit by nature
Title: Re: A few simple questions...
Post by: AngelFish on August 16, 2010, 02:38:27 am
Builderboy, how did you implement gravity in Zedd? I'm pretty sure my formula Y-VT² is off.
Title: Re: A few simple questions...
Post by: Builderboy on August 16, 2010, 03:36:32 am
Code: [Select]
.AA
ClrDraw
47->X
5->Y
0->V
Rect(0, 60, 96, 4)
For(A, 0, 200)
DispGraph
V-9.8->V
Y+V->Y
Pxl-On(X,Y)
Pause
If Y+2V>60
-V->V
End
End

Just wanted to point out some other things that you might want to change.  First off, there is no Implied multiplication in Axe, so things like 2V dont wok.  You need to do 2*V.  Secondly, there is no PEMDAS, everything is evaluated left to right.  So Y+2*V is really (Y+2)*V.  You should change it to V*2+Y.

Also, note that your initial velocity is 0, and then you Subtract 9 from it, making it negative.  This moves your pixel *up*, not down.  And whats more is that it will keep moving up indefinitely because you are waiting for it to go below the screen, but it just went off the top.

As for gravity, how it is done is simple.  There is a variable for velocity for each object, and ever frame, the position is incremented by the velocity, and the velocity is incremented by the acceleration.  For a deeper explanation you might want to check out my tutorial on Gravity and Acceleration over here: http://ourl.ca/4279
Title: Re: A few simple questions...
Post by: AngelFish on August 16, 2010, 09:44:03 pm
What you can do is "inflate" the value to get more accuracy.  256 is a great number since it's very optimized in both division and multiplication.  Since Axe variables hold 16-bit numbers, you can use the lower byte as the decimal and the higher byte as the number.  9.8 can be represented by 9 + 205/256.  You get your inflated number by multiplying by 256 so that's 9*256 + 205 = 2509 == 9.8 as an inflated decimal.  You can treat this number like any other number.  If you add 1 to it, you're really adding 1/256th and adding 256 is like adding 1, etc.  When it comes time to display the point, just divide by 256 so that you recover the integer part for the pixel.  So you're doing math with the precision of 1/256th and then just drawing it to the nearest pixel.

Let's say that 47->X and 32->Y, with velocities U and V respectively.

So, it would be something like
Code: [Select]
While 1
256*X+U->X
256*Y+V->Y
Pt-On(X/256, Y/256, Pic1)
End

 or am I not understanding this? I think I'm okay with the N mod 256 part, but I'm not sure if this is precisely that.
Title: Re: A few simple questions...
Post by: Runer112 on August 17, 2010, 12:18:40 am
What you want is the initial conditions 47*256→X and 32*256→Y, and then use code like the following:

Code: [Select]
While 1
X+U→X
Y+V→Y
Pt-On(X/256, Y/256, Pic1)
End
Title: Re: A few simple questions...
Post by: AngelFish on August 17, 2010, 12:55:13 am
I really am new to this language. I've tried to rewrite the program like that at least a half dozen times without success.  It kept producing weird results, until the last time.
Title: Re: A few simple questions...
Post by: Michael_Lee on August 27, 2010, 12:55:27 pm
I think I'll revive this thread...  with a new question!

I've tried using 'input' on Axe 0.4.4, but it keeps spewing this weird string of characters at the start.  I've attached a gif that shows what I'm talking about.
This is my code:
Code: [Select]
.INPUT
ClrHome
input->A
Disp A,i            //The i is the imaginary i for newline
Repeat getKey
End

What am I doing wrong, and how can I get rid of that string at the start?
Title: Re: A few simple questions...
Post by: Raylin on August 27, 2010, 01:53:37 pm
I think that your input is actually unreadable right now.
Try using a >Char after something.
Title: Re: A few simple questions...
Post by: Quigibo on August 27, 2010, 03:00:45 pm
That shouldn't be happening.  Is anyone else getting that?
Title: Re: A few simple questions...
Post by: Tribal on August 27, 2010, 04:47:29 pm
I typed the program given exactly and it doesn't do it to that extent per se, but when I typed in 'TEST' it appended a 'v' to the output the first time few times I tried it until I recompiled.
Title: Re: A few simple questions...
Post by: Michael_Lee on August 27, 2010, 05:43:40 pm
@Raylin:
I tried appending >Char to Disp A; it just outputted an ñ (an n with a tilde). 
Then I tried using >Tok (because I think the documentation mentioned something about tokens in the "input" entry), which returned a square then an x with a line over it.

I tried deleting and reinstalling a freshly downloaded version of Axe, but it did the same thing, plus now it appends an italic 'n' whenever I try typing in something, even after I recompiled.


On a tangent, is it possible to use 'input' on the graph screen instead of the homescreen?