Author Topic: New to Axe. (Read 12832 times)

Masinini · « **on:** December 06, 2010, 10:22:50 pm »

Okay, so I loosely understand most of the syntax, with some exceptions. I figure that experimenting will help me learn more.

What I am confused with is Pics and such. I read the read me's and stuff included, and don't get the syntax.
I don't get the pointers, and how I will be able to use them.

Furthermore, I am confused as to what the back buffer and what the buffer is, and how they are different.

jnesselr · « **Reply #1 on:** December 06, 2010, 10:35:40 pm »

Yo, welcome to omnimaga. If you make an introduction topic, we can give you peanuts. ;-)

Now then, I'm glad you choose axe for your development needs. Pointers are both the most complex and yet the most beneficial part of any programming language. First, let me explain pointers. A "pointer" is a variable that points to something else. See, that wasn't that hard. In the example of pics, it is fairly easy. (Everything after ; is a comment)

Code: [Select]

[pic1]->Pic2 ; Absorb the 756 bytes that make up the pic1 variable on the calc into the program.  Pic2 is now the pointer to the first byte of the data for pic1 inside the program.  Pic2 does not mean Picture 2 as in the calculator.
det(12) ; Adds 12 more bytes (all zeros) in order to make the total length 768, as that is the byte-size of the calculator screen.
for(A,0,767) ; A goes from 0 to 767.
{Pic2+A}->{L6+A} ; Since Pic2 is pointing to the first byte of the picture, {Pic2} gets the actual first byte. So, {Pic2+A} gets the first byte, plus some offset. So, {Pic2+1} gets the second byte. This is why we went from 0 to 767 and not 1 to 768.
end ; End to the for loop
DispGraph ; Display the buffer on the screen.

If you had replaced L6 with L3 above, it would have been to the back buffer. Now then, imagine 3 different things. A screen, and two buffers. One is what is being displayed. One is the buffer, and as soon as dispgraph is run, the buffer becomes the screen. The backbuffer is essentially another buffer, just used in case you need two buffers.

Note that the above code should work, but isn't tested. Don't have a calc to really test it.

Masinini · « **Reply #2 on:** December 06, 2010, 11:34:05 pm »

So basically, it points to the byte where the pic is being stored?

Builderboy · « **Reply #3 on:** December 06, 2010, 11:38:06 pm »

Quote from: Masinini on December 06, 2010, 11:34:05 pm

So basically, it points to the byte where the pic is being stored?

You have it precisely right

Masinini · « **Reply #4 on:** December 06, 2010, 11:39:43 pm »

Okay. So if I wanted to display a pic. I would have to draw it, store it, and then recall it based on the bytes?

Builderboy · « **Reply #5 on:** December 06, 2010, 11:51:57 pm »

If you wanted to display a pic, the best way would be to draw it on the graph screen normally (outside of Axe), and then store it to a TiOS picture file. Then inside the program you would do something like this:

Code: [Select]

[Pic1]->Str1
the [Pic1] tells axe that we want the data inside the TiOS Picture variable 1. We then store it into the pointer Str1 (note that Str1 is just a name, its not a string). To Display it on the screen we could do one of 2 things.

Code: [Select]

Str1->DispGraph
Or

Code: [Select]

Copy(Str1,L6,768
Dispgraph

The first routine tells Axe to take the data dirrectly at Str1 and put it on the screen. The second routine uses a copy function to take 768 bytes (the same size of the screen) and put it at L6 (which is the location of the Main Buffer). All dispGraph does is take the data at L6 and put it onto the screen. Most commands deal directly with L6, and not the screen itself, since it is faster.

DJ Omnimaga · « **Reply #6 on:** December 07, 2010, 12:37:30 am »

By the way welcome on the forums and happy birthday, noticing the board index event notifications and your profile.

Michael_Lee · « **Reply #7 on:** December 07, 2010, 01:34:30 am »

Well, the main time I use pointers is when I want a list of some sort.
While Axe may have variables built in, it doesn't exactly come with a 'list' variable like TI-Basic does.

Therefore, pointers are most commonly used (by me, at least) for when I want a list.

I access a portion of free ram by using L1, which when compiled, returns an address to the start of a portion of free ram (710 bytes in a row that isn't used by anybody but YOU).

So if I do {L1+5}, that would return the 5th byte (counting up from zero) after wherever L1 is. So I could do

Code: [Select]

For(A,0,5)
    A+9->{L1+A}
End

And that would be sort of like a list with six elements
('L1+0' is an address, and the value stored at that address would be nine; 'L1+1' is an address, and the value stored at that location is 10, etc.)

Pointers can also be used for things like linked lists, although I've never used them, nor do I really know what I would use them for.

Masinini · « **Reply #8 on:** December 09, 2010, 03:53:31 pm »

So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?

And I was reading a guide by sircpm, and it said when I see something like

[0a3ff0457f-pic1, its using hexadecimal? And is that making pic1 point somewhere, or is storing bytes to the area that pic1 already points to?

ztrumpet · « **Reply #9 on:** December 09, 2010, 04:12:55 pm »

Quote from: Masinini on December 09, 2010, 03:53:31 pm

So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?

Not quite. They're two seperate buffers. Normally you only want to display the front one, so you'd use Dispgraph (^r and ^rr are for Greyscale). Normally the Back Buffer is for storing stuff you don't want changed while you change something on the front buffer. If you want to ever display the back buffer, you can just do L3->DispGraph.

Quote from: Masinini on December 09, 2010, 03:53:31 pm

And I was reading a guide by sircpm, and it said when I see something like

[0a3ff0457f-pic1, its using hexadecimal? And is that making pic1 point somewhere, or is storing bytes to the area that pic1 already points to?

It creates a new 4 bite (8 nibble) section of data at the bottom of your code. So it would look like this:

Code: [Select]

<code here>
Return (Don't actually put this in your code - It's automatically added at the bottom of each program.)
[0A3FF0457F]

I hope this helped, and welcome here!

AngelFish · « **Reply #10 on:** December 09, 2010, 04:18:32 pm »

Quote from: ztrumpet on December 09, 2010, 04:12:55 pm

Quote from: Masinini on December 09, 2010, 03:53:31 pm
So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?
Not quite. They're two seperate buffers. Normally you only want to display the front one, so you'd use Dispgraph (^r and ^rr are for Greyscale). Normally the Back Buffer is for storing stuff you don't want changed while you change something on the front buffer.

I prefer to think of them as two different screens that the calculator rapidly switches between when using greyscale.

Masinini · « **Reply #11 on:** December 09, 2010, 04:20:50 pm »

...I just feel more confused now.

So the back buffer holds a background perchance, that you don't want changed, while the regular buffer holds a character that changes as you press buttons?

And I am still conffuzled by the whole 8-bit nibble thing. How is that useful when creating graphics, for example.

AngelFish · « **Reply #12 on:** December 09, 2010, 04:24:47 pm »

Let's say you used the Sprite command Pt-on(X,Y,[0123456789ABCDEF]. This draws the sprite data to an 8x8 section in L₆. If you were to do Pt-on(X,Y,[0123456789ABCDEF])^r instead, the data would be drawn to the same location, but this time in L₃. When you use the Dispgraph command, it takes all of the data in L₆ and it draws it to the screen (the LCD RAM if you want to be technical). When you do L₃->Dispgraph though, it takes the data in L₃ and it writes that to the screen instead.

The 8 bit thing is just a function of how the calculator's memory was designed. It turns out that the calculator was built so that 8 bits fit into something known as a "byte." Since the calculator automatically addresses everything in terms of bytes rather than individual bits, it makes it easier to use 8 bits instead of another system.

PS: Nibbles are half of a byte or four bits. I'd recommend staying away from them until you get a little more familiar with the language.

Masinini · « **Reply #13 on:** December 09, 2010, 04:27:04 pm »

That helps. A lot.

So in An example program from the Axe download, called starship demo or something.

I was messing around and the creator used hexadecimal to draw graphics. How.

AngelFish · « **Reply #14 on:** December 09, 2010, 04:35:09 pm »

Hexadecimal is just a short way to encode binary. For example, let's say that you wanted a sprite that looked like this:

Code: [Select]

where the 1's are pixels that are turned on, you would be able to turn that image into the hex sequence 6996, where every row is a hex number. With Axe, sprites are 8x8, so you need four such images like this:

Code: [Select]

Notice how I just tiled the image four times. So, reading the hex across would be 66 99 99 66 66 99 99 66, where every pair of numbers is a full byte and a row.

Author Topic: New to Axe. (Read 12832 times)

Masinini

New to Axe.

jnesselr

Re: New to Axe.

Masinini

Re: New to Axe.

Builderboy

Re: New to Axe.

Masinini

Re: New to Axe.

Builderboy

Re: New to Axe.

DJ Omnimaga

Re: New to Axe.

Michael_Lee

Re: New to Axe.

Masinini

Re: New to Axe.

ztrumpet

Re: New to Axe.

AngelFish

Re: New to Axe.

Masinini

Re: New to Axe.

AngelFish

Re: New to Axe.

Masinini

Re: New to Axe.

AngelFish

Re: New to Axe.