Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: AngelFish on August 17, 2010, 11:47:11 pm

Title: hexadecimal conversion
Post by: AngelFish on August 17, 2010, 11:47:11 pm
I'm currently working on rewriting Quigibo's HEXPIC sprite editor to work in Axe. The whole thing simplifies a lot due to the added graphics features of Axe over TI-BASIC. However, as far as I can tell, Axe has next to no string support.

The program should work as follows:


The problem is that I can't figure out how to store anything to the strings. In BASIC, all you would do is
Code: [Select]
"0"->Str1
For(A,0,7
1->X
Y+offset->Y
For(B,0,7
X+offset->X
If pxl-Test(X,Y:Then
"1"+Str1->Str1
Else
"0"+Str1->Str1
End
End
End
sub(Str1,2,length(Str1->Str1

Then you simply convert Str1 to Hex, which is also easy in BASIC.

But would anyone know how you might implement something similar in Axe?
Title: Re: hexadecimal conversion
Post by: nemo on August 18, 2010, 12:16:14 am
axe has loads of support for strings. you can load strings. you can manipulate their data directly. you can even export them to OS variable strings! what other support were you looking for?

lastly, here's some code. assume the x and y position of the sprite is 0.
Code: [Select]
GetCalc("Str1",16)->I       .I points to the start of the data at Str1
For(P,0,15      .16 half-bytes
0->C   .Counter
For(T,0,3       .4 pixels per half byte.
e^(3-T)*pxl-Test(P^2*4+T,P/2)+C->C
End
{"0123456789ABCDEF"+C}->{I+P}  .store corresponding hex character into
End

i think this is the most optimized way, though i'm not sure. your sprite data is in str1.

an extremely optimized version in BASIC by yours truly can be found in this thread. (http://www.cemetech.net/forum/viewtopic.php?t=1642&start=80)
Title: Re: hexadecimal conversion
Post by: meishe91 on August 18, 2010, 12:22:00 am
Well I don't know if this helps any right now but a better way in basic to do this is:

Code: [Select]
"_?Str2
For(A,0,7
For(B,0,7,4
8pxl-Test(A,B)+4pxl-Test(A,B+1)+2pxl-Test(A,B+2)+pxl-Test(A,B+3
Str2+sub("0123456789ABCDEF",Ans+1,1?Str2
End
End
sub(Ans,2,16?Str2
Disp Ans

That's what I use, or will use, in my Sprite Maker (http://ourl.ca/6631) in BASIC.

And knowing that nemo is watching this I'm gonna get ninja'd big time :P
Title: Re: hexadecimal conversion
Post by: nemo on August 18, 2010, 12:26:46 am
got you there, meishe (:

by the way, the BASIC version i linked to probably shouldn't be used if speed is important. it's slow. i think i timed it at 3 seconds, and it's about 92 bytes. then i clocked one that was about 120 bytes but it was twice as fast.
Title: Re: hexadecimal conversion
Post by: AngelFish on August 18, 2010, 12:28:23 am
I had no idea you could manipulate strings like that in Axe. Hope you don't mind if I throw that bit into the code, nemo, once I finish up the last few editing features :)
Title: Re: hexadecimal conversion
Post by: nemo on August 18, 2010, 12:33:01 am
yeah, you can do that same thing with any data, aka map data, sprite data, etc. in axe, they're all just numbers.

go for it. by the way, what features are you looking to implement?
Title: Re: hexadecimal conversion
Post by: meishe91 on August 18, 2010, 12:45:23 am
got you there, meishe (:

by the way, the BASIC version i linked to probably shouldn't be used if speed is important. it's slow. i think i timed it at 3 seconds, and it's about 92 bytes. then i clocked one that was about 120 bytes but it was twice as fast.

You're just to helpful of a person to leave this without a quick answer :P Ya, mine is 114 bytes but is twice as fast as your 95 byte one.

Glad you got an answer, Qwerty.55.
Title: Re: hexadecimal conversion
Post by: AngelFish on August 18, 2010, 12:47:13 am
The features I currently have written and debugged:

Moving cursor(s)
Plot pixel/invert pixel
Plot all pixels
Invert pixels
Plot all pixels in a row
Plot all pixels in a column
Exit to Hex code

I'll definitely be adding an Erase all pixels feature, an Erase all in Row feature, and an Erase all in Column. I'm going to try to implement "flip grid horizontally," and "Flip grid vertically" as well.
Title: Re: hexadecimal conversion
Post by: DJ Omnimaga on August 18, 2010, 12:49:59 am
Sounds like a nice project ^^. I wished that would be ported to Axe at one point.
Title: Re: hexadecimal conversion
Post by: nemo on August 18, 2010, 12:50:07 am
qwerty, may i suggest real-time hex display? the hex routine i wrote in this thread would take a few seconds to execute under TI-Basic, but with Axe it's not even humanly noticeable. maybe you could get hex to display every time you change a pixel on the screen? if you do this, you'll find flipping/rotating much easier, since you can then use the built-in functions for it.
Title: Re: hexadecimal conversion
Post by: AngelFish on August 18, 2010, 12:56:18 am
I don't have room for a full Hex display. The grid is a 73x57 object and reducing it would mean that I'd have to recode all of the sprites or eliminate them. But I could use the real time hex code to draw a stationary sprite to illustrate how the final code will look.

@DJ, I'm writing it in Axe, so porting would essentially just be optimization, which I assure you my code could get.

Also, the Erase all feature is coded and working.

EDIT:

Nemo, I'm not sure I understand the routine you posted. Where does the Hex string store to and how would the user call it? Would it be {I+P} and Rcl {I+P}?

Also, since strings are numbers, could I use a For() loop to store generate the binary strings like

Code: [Select]
pxl-Test(X, Y)+"Str1"->Str1
Title: Re: hexadecimal conversion
Post by: Quigibo on August 18, 2010, 01:39:43 am
Hey that's cool!  Porting a program an excellent way to learn Axe given a background in BASIC.

By the way, would a >Hex command be useful?  I already have a >Dec, >Char, and >Tok so in a similar way I can add a >Hex.  There is even a really cool optimization for it that uses the daa instruction which is something I've never used but always wanted to.
Title: Re: hexadecimal conversion
Post by: Runer112 on August 18, 2010, 04:00:06 am
qwerty, may i suggest real-time hex display? the hex routine i wrote in this thread would take a few seconds to execute under TI-Basic, but with Axe it's not even humanly noticeable. maybe you could get hex to display every time you change a pixel on the screen? if you do this, you'll find flipping/rotating much easier, since you can then use the built-in functions for it.

That sounds exactly like my sprite editor. :P But thanks for reminding me about it, I should work on it a bit more.
Title: Re: hexadecimal conversion
Post by: calcdude84se on August 18, 2010, 09:25:29 am
Hey that's cool!  Porting a program an excellent way to learn Axe given a background in BASIC.

By the way, would a >Hex command be useful?  I already have a >Dec, >Char, and >Tok so in a similar way I can add a >Hex.  There is even a really cool optimization for it that uses the daa instruction which is something I've never used but always wanted to.
Using daa seems so out of place in Axe... go ahead and add it ;D
Title: Re: hexadecimal conversion
Post by: nemo on August 18, 2010, 12:14:59 pm
That sounds exactly like my sprite editor. :P But thanks for reminding me about it, I should work on it a bit more.

cause i like real-time hex display (:

By the way, would a >Hex command be useful?  I already have a >Dec, >Char, and >Tok so in a similar way I can add a >Hex.  There is even a really cool optimization for it that uses the daa instruction which is something I've never used but always wanted to.


yesssss. do it.

qwerty: here's a very commented version of the code.
Code: [Select]
GetCalc("Str1",16)->I       
.GetCalc() is used to write to external variables. it reads "Str1" and locates the OS variable Str1
.It then makes Str1 16 bytes (which is equivalent to 16 characters) long.
.Storing this to pointer "I" will allow us to read and write to the data currently in OS var Str1.
For(P,0,15      .
.Loop through 16 times, as an 8x8 sprite has 16 hex characters
0->C   
.A holder variable, to get each value of the hex string. a better explanation below.
For(T,0,3       
.there are 4 pixels needed to test to determine. why 4 pixels?
.because a hex character can hold values 0-F, or 0-15.
.if you take 4 pixels as a binary string of 0's and 1's, the highest value
.possible is 16, or 2^4.
e^(3-T)*pxl-Test(P^2*4+T,P/2)+C->C
.This is tricky. first, the correct power of two is calculated. e^(3-T)
.which returns either a 8, 4, 2, or 1 depending on the value of T.
.pxl-Test() returns a 1 or a 0. if there's no pixel, the value won't be added.
.If there's a pixel, e^(3-T) will be multiplied by 1, added to C giving the value of the half-byte.
.P^2*4+T,P/2 is some arithmetic explained below.
End
{"0123456789ABCDEF"+C}->{I+P} 
.the part in quotation marks is 16 characters long. this means it's 16 bytes long.
.the curly {} brackets get the byte (in this case, a character) at a pointer.
."0123456789ABCDEF" is a pointer, and so is the variable C.
.Since C contains the value of the halfbyte, when you add the part in quotations to C,
.you get the corresponding character in the string to the value of the half-byte.
.Remember how I points to our OS var Str1? now it's storing our hex character
.into the string. P shifts the characters along the string.
End

alright. a little spiel about hex, binary and hex characters:

0111. this is a binary string. each value is either 1 or 0. to get the value in decimal, you start at the very rightmost bit (a bit is a 1 or a 0). the rightmost bit is 1. add 1 to your running total. then go left, to the next bit. the bit is also 1. however, binary and the powers of two are very related. this bit is worth 2. add two to the running total, you get 3. the next bit is also a one. this bit is worth 4. add it to your total, and you get 7. the next bit is 0 and therefore doesn't contribute. 0111binary = 7 decimal. 1111 = 15 decimal, because the last bit is worth 8 in decimal.

binary's pretty simple. you start at the rightmost bit, and count that as "1", multiply it by two and that's the value of the next bit, etc.

so try to decipher 01100101.
start from the right. you get 1+0+4+0+0+32+64+0 = 101.
some terms: 1 bit is either a 1 or a 0. a byte is 8 bits long. therefore, a half-byte is 4 bits long. a half-byte is also called a "nibble".
a hex character is 0-F, and therefore can hold 16 values. a half-byte can also hold 16 different values. general rule: 2^(# of bits) = numbers of possible values that can be held.

whew. alright... last thing. the arithmetic. (P^2*4+T,P/2).
the first expression is P^2*4+T.  P^2 is P modulus two, or the remainder after division. therefore, P^2 can either return a 1 or a 0. this is to determine which half-byte we're testing, the first or second? if it's the first, P^2 returns a 0, and multiplied by 4 does nothing and the pxl-Test() is determined by the value of T. otherwise, it adds four, and tests the second half-byte.
P/2 is rather simple, but it's a little neat that axe drops decimal points.
since P holds values 0-15 in the for loop, P/2 will return the following:
0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7.
this way, the Y coordinating of the Pxl-Test is the same for two iterations of the For() loop, so we can get both Half-bytes in the row of the sprite.

hope that makes some sense.. i kinda got carried away, maybe, probably
Title: Re: hexadecimal conversion
Post by: ztrumpet on August 18, 2010, 12:52:53 pm
Hey that's cool!  Porting a program an excellent way to learn Axe given a background in BASIC.

By the way, would a >Hex command be useful?  I already have a >Dec, >Char, and >Tok so in a similar way I can add a >Hex.  There is even a really cool optimization for it that uses the daa instruction which is something I've never used but always wanted to.
Do it! ;D
Title: Re: hexadecimal conversion
Post by: DJ Omnimaga on August 18, 2010, 02:33:38 pm
I would like to see this ^^
Title: Re: hexadecimal conversion
Post by: LordConiupiter on August 18, 2010, 03:39:35 pm
me too!!!
Title: Re: hexadecimal conversion
Post by: AngelFish on August 18, 2010, 05:59:56 pm
I'll release it after I get the hex conversion working and I write the user instructions down. I think I might have gotten a bit crazy with the features, though.

EDIT: I didn't see Nemo's commented code. I'm going to look it over, although it seems to leave the String undefined. I see the reference to the location of the pointer, but not the definition of the pointer itself.

Nemo, when I try the code with a sample string, it doesn't work. Disp Str1 gives me back a blank line. RCL Str1 gives me about 16 While tokens.

BTW: The graphics and the commands are entirely finished and debugged.