Omnimaga

Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on February 01, 2010, 03:52:51 am

Title: Axe Parser
Post by: Quigibo on February 01, 2010, 03:52:51 am
Axe Parser
Alpha 0.0.1



WARNING:
This is still an alpha version.  It is not stable and you should not run this on any calculator that has anything intellectually valuable in the RAM.  Just for liability reasons, I will also add that there is a non-zero possibility your archive might not be safe either.

Description:
It is a new programming language for the calculator.  It is typed directly into a program just like BASIC and with a similar syntax.  Unlike BASIC however, this is a compiled language, not an interpreted one.  The program gets compiled into an assembly program.  In the future you will be able to make Ion, MirageOS, and Doors programs; possibly apps too.

Advantages:

You basically get the simplicity of BASIC programming but with nearly the same size, speed, and compatibility of assembly programs.  You won’t need “Shells” or “Libraries” to run the programs.  They are just like any other assembly program.

Syntax:
It is similar to BASIC, but also very different.  First, it has an extremely loose syntax.  You know how you can leave the end parenthesis off of BASIC commands and do multiple same-line DelVars?  It’s like that on steroids (if you so choose).  For instance: the store “->” can be used in expressions like A+B->C+1->D so now C holds A+B and D holds A+B+1.

Differences With BASIC:

I will be re-defining a lot of commands.  Most are usually unused anyway, but some are not.  For instance, “DiagnosticOff” turns off the run indicator.  But “sub()” now runs a subroutine since you will be able to take characters from a string the same way you do with lists in the future.

Variables and Numbers:
All numbers and letters A-Z are 16-bit unsigned integers.  Unlike BASIC variables, they don’t reside in the user ram so they take up zero memory.  You might want to read about unsigned numbers on Wikipedia or something if you are not familiar with it.

User Defined Variables:
Things like strings, lists, sprites, and floats will be defined by the user.  However, I haven’t gotten to that point yet, but expect that soon.



There is no UI right now.  Select your program, which must be in RAM, from the list, which is not in alphabetical order, and it will compile into a program called “LOL”, you can’t name it right now.  I figured I’d get the compiler working before I get back to the UI.  I’ve also attached a document with the complete instruction set so far.

I’d like to hear your thoughts :)
I have too many ideas right now to put on paper.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 01, 2010, 04:14:52 am
This is really nice. I also like that this programming language went further than planning stages so far, unlike many others I've seen in the TI community before. It also seems to be quite functional alerady so it's quite promising. I always dreamed of a TI-BASIC alike (or close) language that could be compiled into ASM code. I am sure a lot of people would use this for smaller games too, because not only they could easily do fast games, but they wouldn't even need to learn a new language from scratch, just some minor differences in yours. Plus the fact it uses the on-calc editor makes it even greater (providing they always keep a copy of their program archived or backed up on their comp in case they mess up), plus people can edit their code in TI-Graph Link or view it in SourceCoder.

Anyway, I read some of the progress so far in the past weeks when we talked on Yahoo and it's pretty promising and I am confident this project will reach states where we can build entire games with it and maybe even get finished. As soon as I heard about it, I told myself this is guaranteed to get a subforum when announced.
Title: Re: Axe Parser
Post by: Quigibo on February 01, 2010, 04:22:06 am
Yes, I am hoping it will be all that and more.  ;)

By the way, since this is a lot to take in, here is an example program to simply display the "getkey" codes for each key (which are different from the BASIC getkey.  Its the GetCSC codes for all you asm programmers)
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 01, 2010, 04:49:28 am
In other words, the code in real TI-BASIC, omitting the command to disable the run indicator (since it's impossible without abusing ASM libs), would be:

Code: [Select]
ClrHome
0->K
While K=/=15
Getkey->K
If K=/=0
ClrHome
Disp K
End:End

In case anyone gets a bit confused at some of the order
Title: Re: Axe Parser
Post by: Silver Shadow on February 01, 2010, 06:41:09 am
 :o
Amazing!
Axe Parser
Alpha 0.0.1



WARNING:
This is still an alpha version.  It is not stable and you should not run this on any calculator that has anything intellectually valuable in the RAM.  Just for liability reasons, I will also add that there is a non-zero possibility your archive might not be safe either.
Thanks for warning us, I'll try it once I backup my calc files or finish Crystal Defenders.
Title: Re: Axe Parser
Post by: Galandros on February 01, 2010, 09:04:44 am
Seems promising. And is compiled, that was sort of a surprise.

Subroutines in this kind of thing are important.

You are using the TI-BASIC editor, that is neat. Although I always wanted a small font TI-BASIC editor like you see in the BBC Basic.
I am waiting for new commands. :)
Title: Re: Axe Parser
Post by: calc84maniac on February 01, 2010, 11:18:41 am
Nice job man! I've never been able to get past the planning stage for anything like this :P

Edit: I'll be glad to write multiplication and division routines if you need me to

Edit3: Removed Edit2 for stupidity
Title: Re: Axe Parser
Post by: ztrumpet on February 01, 2010, 04:08:42 pm
This is awesome!  I really like this!  I can see my self programming in this language.  It's incredibly cool!  I love the fact it is compiled.

---I read through the Documentation and this is what went through my mind---
Apps?  How do you make large Apps if the source file can only be 1.25ish pages large, due to lack of RAM?
How do you use the predefined A - Z and Theta?  And what about Theta?
Comments!!!  Yay!  That's great.  Can you have comment blocks?  (Like ' ' to ' ' mabey?)
Can you include the ++ and -- operators from C++? Mabey they could be just + and - , but only take one operand.   (And if Ans works the same, can these not alter Ans?)
Does the Ans Variable work the same way as in basic?
If you Pause, and the run indicator is off, does it stay off?
YES!!!  I can Asm(Hex-Code-Here!)
I love LBL!  It's really cool!
ReturnIf == Awesome!
How does Disp work when you get to the end of a line?
Can getKey ever go back to the getKey of basic, or is it always GetScanCodes?  (I don't mind the change, but I'm wondering if others think this. :) )
Thanks for giving the Diagnostics commands (That in my opinion should always be on) some real purpose. :P  It's not that they are unused, it's just they are so seldom used and never used in games. :D

This is so cool! I can't wait for more commands, so we can see how much faster this is!
This is great!

Edit:  I looked at it more, and had more thoughts:
Earlier when I said ' ' it's two single qoutes. (clarification)
I love the new use of DispGraph! :D
While is still PreTest, and Repeat is still PostTest, right?
Can you check if sub( has a comma in it, and if so use it like it is in TiBasic? (If it dosn't have a comma, it's subroutien.)
__=Var means what equals Var?  And is the underscore a space?  Is it Ans?

Thanks!
Title: Re: Axe Parser
Post by: Quigibo on February 01, 2010, 05:36:44 pm
Okay, that's like a million questions, but I will attempt to answer them all:

Quote
Apps?  How do you make large Apps if the source file can only be 1.25ish pages large, due to lack of RAM?
When its finished, it will allow the source programs to be in archive.  You will also be able to include subprograms in your programs like the "include" feature in C.  If it compiles to an app, it will have to be a one page app since it will be too complicated to switch pages with anything that resembles basic.  But that's still 16k, which is large enough for most applications.
Quote
How do you use the predefined A - Z and Theta?  And what about Theta?
They are stored in the saveSScreen ram location.  I have not included theta yet because I am still considering using it for some other purpose.
Quote
Can you have comment blocks?
You can do single line comments, but I feel that inline comments will just make the code very unreadable.
Quote
Can you include the ++ and -- operators from C++?
I might.  A++ can save 2 bytes when assembled instead of doing A+1.
Quote
Does the Ans Variable work the same way as in basic?
No, I no longer use it, its pointless.  If you have no argument, it automatically assumes the last expression.  But it must immediately follow or it will just be garbage.
Quote
If you Pause, and the run indicator is off, does it stay off?
Yes
Quote
How does Disp work when you get to the end of a line?
Disp is not fully functional right now.  I only included it so I have some type of output to test everything.  Nothing will display at the end of the line.  It will work like it does in BASIC when its finished.
Quote
Can getKey ever go back to the getKey of basic, or is it always GetScanCodes?
Probably not, but I will have a directkey command in the future (for multiple key presses)
Quote
While is still PreTest, and Repeat is still PostTest, right?
Its pretest right now... was it post test in basic?  I've never used it before, but that would be very easy to change and also save 3 bytes.
Quote
Can you check if sub( has a comma in it, and if so use it like it is in TiBasic? (If it dosn't have a comma, it's subroutien.)
Nope.  You will be able to do substrings like this: Str(5) gets 5th character in string.
Quote
__=Var means what equals Var?  And is the underscore a space?  Is it Ans?
Yes, basically any expression, variable, number, or Ans before it.
Title: Re: Axe Parser
Post by: ztrumpet on February 01, 2010, 06:56:52 pm
Quote
Okay, that's like a million questions, but I will attempt to answer them all:
Thanks! ;D
Quote
Quote
Can getKey ever go back to the getKey of basic, or is it always GetScanCodes?
Probably not, but I will have a directkey command in the future (for multiple key presses)
That sounds great!  Does this mean you could hold down 2nd, Enter,  and Down at the same time and getKey would equal 1, 9, and 54 at the same time?
Quote
Quote
While is still PreTest, and Repeat is still PostTest, right?
Its pretest right now... was it post test in basic?  I've never used it before, but that would be very easy to change and also save 3 bytes.
Yes, it is post test in basic.  :)
Quote
Quote
Can you check if sub( has a comma in it, and if so use it like it is in TiBasic? (If it dosn't have a comma, it's subroutien.)
Nope.  You will be able to do substrings like this: Str(5) gets 5th character in string.
How do you access multiple characters like:
sub("Name1Name2Name3",5(2)-4,5
This returns "Name2".  Can you access multiple characters in your other way.  If so, then you don't need sub( for sub.  :)

I have another 2 questions.  That makes 1,000,002 questions. :D:
Can you use the operators like xor and = like "Var1=Var2" or do they need to be "Var1: =Var2"?
Do you plan to use the operator not( for anything?

Thanks!
Title: Re: Axe Parser
Post by: Builderboy on February 01, 2010, 09:56:02 pm
Wow, this is great!  I have seen/heard things where people have tried stuff like this before, but as calc84 said, none of them ever got past planning stages.  Just the fact that you have gotten this far is amazing.  Writing an asm compiler in asm ^^.  Well i for one can't wait to try this out, although i will have to back up my calc first just to be safe :P
Title: Re: Axe Parser
Post by: TIfanx1999 on February 01, 2010, 11:42:35 pm
Quote
Can you include the ++ and -- operators from C++?
Quote
I might.  A++ can save 2 bytes when assembled instead of doing A+1.
I'm not very familiar with C++, but if I understand properly the ++ and -- commands do Variable +/-1 ==Variable? IE A++ would increment A by 1 and store the new value to A? If this is correct you could use the IS>( for ++ and DS<( for --. They are commands that aren't really used in BASIC and act somewhat similarly anyway. I should also take a moment to mention that this looks like a very promising undertaking. Can't wait to see how it develops!
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 02, 2010, 01:50:50 am
Another thing I love about this project is how the produced programs are not dependent on the application. I mean, when running a FastRPL game you need the FastRPL app installed on the calc, same with BBC Basic. Since these apps are huge, this limits the amount of games or programs you can have on your calc at once. Not to mention many people like to be able to run their programs either from the PRGM menu using Asm( or from a popular shell like Ion/MirageOs

@Art_Of_Camelot: IS/DS commands were useful back in the TI-81 and first-gen Casio BASIC days, as back then For( didn't exist on these calcs
Title: Re: Axe Parser
Post by: Geekboy1011 on February 02, 2010, 01:51:18 am
hmm this looks amazing i think whenin get my second calc back(lent it to someone they really needed it got there other stolen X.x) i think im gonna put this on it and find ways to corrupt the os XD jk this really looks amazing though
Title: Re: Axe Parser
Post by: bwang on February 02, 2010, 02:18:55 am
Quote
Another thing I love about this project is how the produced programs are not dependent on the application. I mean, when running a FastRPL game you need the FastRPL app installed on the calc, same with BBC Basic. Since these apps are huge, this limits the amount of games or programs you can have on your calc at once. Not to mention many people like to be able to run their programs either from the PRGM menu using Asm( or from a popular shell like Ion/MirageOs
But so many people have 84+'s these days, where the 48KB doesn't really matter.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 02, 2010, 02:24:27 am
Yeah true, altough there's still a good 83+ userbase. But I guess you are right
Title: Re: Axe Parser
Post by: Silver Shadow on February 02, 2010, 03:04:43 pm
*Silver Shadow asks if there will be sprite support.*
If it is implemented in the nearby future, I might use Axe Parser for my Crystal Defenders port.

I am also completely free for any kind of beta-testing or GUI design. If you want of me that is. :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 02, 2010, 03:35:37 pm
There is, it will use RecallPic and the like I think. Pictures will change from 96x64 size to 8x8 I think.
Title: Re: Axe Parser
Post by: Geekboy1011 on February 02, 2010, 04:27:47 pm
hmm i havent read the readme yet but will there be support for read/writing flashram?
Title: Re: Axe Parser
Post by: Quigibo on February 02, 2010, 06:02:53 pm
Axe 0.0.2 (http://ourl.ca/4060)

New update!  I made my first game using Axe Parser.  Its a grayscale platformer, try it out!






Just kidding, its a guess the number game, but hey, its a start  ;D
Title: Re: Latest Updates
Post by: Eeems on February 02, 2010, 06:14:10 pm
w00t! sweet!
btw, how did you do the rand? did you use ion's routine? or did you make your own?
Title: Re: Latest Updates
Post by: ztrumpet on February 02, 2010, 06:19:44 pm
Awesome!  I can't wait to see what else you do!  Great job so far!
Title: Re: Axe Parser
Post by: Builderboy on February 02, 2010, 07:37:00 pm
Hmmm, it seems the - character is not supported correctly in Strings?  It becomes a q on my 84SE
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 02, 2010, 11:15:00 pm
Nice! I think I'll give this a real try soon, and by that I mean start writing my own stuff
Title: Re: Axe Parser
Post by: Quigibo on February 02, 2010, 11:20:56 pm
Hmmm, it seems the - character is not supported correctly in Strings?  It becomes a q on my 84SE
Thanks for pointing that out!  Unfortunately, TI decided that the single character tokens are not the same as their corresponding ascii values.  I've already re-routed the question mark, exclamation mark, and space.  I haven't done + or - yet, I'll get to those next time.

Tokens are no longer displayable (no one really uses them anyway) you'll have to just type them normally.  But they do allow you to type some cool non standard characters.  For instance the "Output(" token will display the black cursor box.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 02, 2010, 11:33:20 pm
oooh nice to know, a chart containing the equivalent of each should be made because Basic programmers using ASCII characters for tilemaps and the like may find them very useful.
Title: Re: Axe Parser
Post by: ztrumpet on February 03, 2010, 07:45:57 am
Woah, that's neat.  I can't wait to see a chart. :)
Title: Re: Latest Updates
Post by: Silver Shadow on February 03, 2010, 02:59:15 pm
Yepeee!
Title: Re: Axe Parser
Post by: Quigibo on February 03, 2010, 05:06:42 pm
Does anyone know a fast routine for dividing two unsigned 16-bit registers?
Title: Re: Axe Parser
Post by: calc84maniac on February 03, 2010, 05:28:22 pm
Does anyone know a fast routine for dividing two unsigned 16-bit registers?
Hehe, I offered on the previous page ;D

Code: [Select]
div_hl_de:
; BC = HL/DE, HL = remainder

ld a,h
ld b,l
ld hl,0

scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a

ld c,a
ld a,b

scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a
scf \ rla \ adc hl,hl \ sbc hl,de \ jr nc,$+4 \ add hl,de \ dec a

ld b,a
ret
Note: Code is untested, so tell me if there are problems
Title: Re: Axe Parser
Post by: Quigibo on February 03, 2010, 05:45:25 pm
When I said fast, I didn't expect unrolled fast ;)  I'd prefer the smallest code possible that doesn't use a naive method.

I think I see the pattern though.  I can just figure out how to roll it up again. 

Here is the super efficient HL*DE multiplication routine I'm using, only 14 bytes  :)  The real routine is a little bit bigger just because it has to find which of the two arguments is smallest and exchange them if necessarily.
Code: [Select]
_DE_Times_L:
xor a
ld h,a
ld a,l
ld l,h
_Loop:
rra
jr nc,_Skip
add hl,de
_Skip:
sla e
rl d
or a
jr nz,_Loop
ret
Title: Re: Axe Parser
Post by: calc84maniac on February 03, 2010, 05:51:25 pm
Hold up, found a more efficient method (and I put it into loops just for you ;D)

Code: [Select]
div_hl_de:
; BC = HL/DE, HL = remainder

xor a
sub e
ld e,a
sbc a,a
sub d
ld d,a

ld a,h
ld b,l
ld hl,0
ld c,8

div_loop_1:
rla
adc hl,hl
add hl,de
jr c,$+4
sbc hl,de
dec c
jr nz,div_loop_1
rla

ld c,a
ld a,b
ld b,8

div_loop_2:
rla
adc hl,hl
add hl,de
jr c,$+4
sbc hl,de
djnz div_loop_2
rla

ld b,a
ret
Title: Re: Axe Parser
Post by: ztrumpet on February 03, 2010, 07:46:14 pm
That's awesome code!  ;D Great job on it, though I only kinda understand. (The time for explaining is not now, so you don't need to explain it to me now. :) )
Title: Re: Axe Parser
Post by: Quigibo on February 03, 2010, 11:11:55 pm
Thanks for that division routine, but I found this one and its a lot smaller.

Code: [Select]
HL_div_DE:
ld a,h
ld c,l
ld hl,0
ld b,16
__DivLoop:
sll c
rla
adc hl,hl
sbc hl,de
jr nc,__DivSkip
add hl,de
dec c
__DivSkip:
djnz __DivLoop
ld h,a
ld l,c
ret

I'm just a little bit worried about the use of the sll command, will that sacrifice compatibility with the Nspire?
Title: Re: Axe Parser
Post by: calc84maniac on February 03, 2010, 11:45:58 pm
Thanks for that division routine, but I found this one and its a lot smaller.

Code: [Select]
HL_div_DE:
ld a,h
ld c,l
ld hl,0
ld b,16
__DivLoop:
sll c
rla
adc hl,hl
sbc hl,de
jr nc,__DivSkip
add hl,de
dec c
__DivSkip:
djnz __DivLoop
ld h,a
ld l,c
ret

I'm just a little bit worried about the use of the sll command, will that sacrifice compatibility with the Nspire?
You are correct. You can replace it with "scf \ rl c" though

Edit:
Also, if you haven't done this already, I'd like to suggest that you auto-generate multiplication algorithms when multiplying by constants. Like A*9 would become:
Code: [Select]
ld hl,(var_a)
ld d,h
ld e,l
add hl,hl
add hl,hl
add hl,hl
add hl,de
Title: Re: Axe Parser
Post by: Silver Shadow on February 04, 2010, 07:56:41 am
Thanks for that division routine, but I found this one and its a lot smaller.

Code: [Select]
HL_div_DE:
ld a,h
ld c,l
ld hl,0
ld b,16
__DivLoop:
sll c
rla
adc hl,hl
sbc hl,de
jr nc,__DivSkip
add hl,de
dec c
__DivSkip:
djnz __DivLoop
ld h,a
ld l,c
ret

I'm just a little bit worried about the use of the sll command, will that sacrifice compatibility with the Nspire?
I definitely want this to work on the NSpire, so could you use another method instead?
Title: Re: Axe Parser
Post by: Eeems on February 04, 2010, 09:40:15 am
 think calc84 gave a way that works.
Title: Re: Axe Parser
Post by: Quigibo on February 04, 2010, 04:04:22 pm
Yeah, its only one byte more for the compatibility.  Worth it. ;)

Quote
Also, if you haven't done this already, I'd like to suggest that you auto-generate multiplication algorithms when multiplying by constants.
I probably will for powers of 2, but I don't think there will really need to be such high speed math operations, I mean, I don't think anyone will be making a first person shooter or anything.  But I guess if a few microseconds are important enough to account for the program size increase, you can always add some Hex code to do the faster multiplication.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 04, 2010, 06:48:34 pm
I am confused by what this means. Does it means it would be only possible to mutiply by 2, 4 and the like? It might become an issue for example if I did a small RPG where your max HP and attack power was like 101 x character LV
Title: Re: Axe Parser
Post by: Quigibo on February 04, 2010, 06:54:02 pm
No, no, it just means that multiplying by powers of 2 will use a smaller, faster code that multiplying the regular way.  Its just an optimization.  Even things like +1 and +2 can be optimized.

Probably won't be in the next release, but I'll get to automatic optimizations eventually.
Title: Re: Axe Parser
Post by: calc84maniac on February 04, 2010, 06:54:17 pm
I am confused by what this means. Does it means it would be only possible to mutiply by 2, 4 and the like? It might become an issue for example if I did a small RPG where your max HP and attack power was like 101 x character LV
He's just saying that it would be slower to multiply by anything else because it would call a general routine instead of adding manually

Edit: Ninjaaaaa
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 04, 2010, 06:55:03 pm
aaaah ok, I see, thanks for clarifying
Title: Re: Axe Parser
Post by: Builderboy on February 04, 2010, 06:55:27 pm
I think (but i'm not sure) is that when multiplying by any arbitrary number, it uses the general multiplication routine, but when multiplying by 2, you use the dedicated x2 routine?

EDIT: nice Ninja there Quigibo :P
EDIT2: Double ninja  :o
EDIT3: Damn Triple ninja :(
Title: Re: Axe Parser
Post by: Quigibo on February 04, 2010, 06:57:40 pm
I think (but i'm not sure) is that when multiplying by any arbitrary number, it uses the general multiplication routine, but when multiplying by 2, you use the dedicated x2 routine?

Correct.  The general x2 routine is to add the number to itself :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 05, 2010, 02:49:00 am
I removed all replies from the updates thread and moved them here.
Title: Re: Axe Parser
Post by: Quigibo on February 05, 2010, 03:22:16 am
The new update 0.0.3 is here.  Finally got around to parenthesis, those things were Tricky!
Title: Re: Axe Parser
Post by: AaroneusTheGreat on February 05, 2010, 03:28:33 am
I'm coming in pretty late in the news of this but really amazing work Quigibo. I'd love to take this for a test drive as soon as I can, I used to love to program in basic but when I learned C and ASM, I slowly phased it out of my repertoire due to speed issues (I know people have made amazing ways around this recently, this wasn't available back then to severely date myself here) and the fact that I needed to focus on other things in RL as well. I'd really love to see this thing reach a complete and optimized state so that we can see what amazing things I'm sure will be made with it. Good luck and keep it up! 
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 05, 2010, 03:31:29 am
Glad to see update :)

I am really gettin curious about the speed. One thing, though, is that people won't see the full speed potential until sprites functions and the like are implemented, because the TI-OS text routines, especially on home screen, are very slow by themselves. It can be seen when you try ASM games that are mostly text
Title: Re: Axe Parser
Post by: AaroneusTheGreat on February 05, 2010, 03:47:38 am
I agree with Kev, if you find a way to implement access to the built in math functions too it will greatly improve the effectiveness and functionality of this project. just a helpful hint

EDIT:

if I'm not mistaken there's a plethora of info on the hex codes for the functions and such if you search ticalc.org.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 05, 2010, 05:23:50 am
I think the only way to speed up anything related to text display is to have a custom font routine, though. I am not sure how easy it would be to implement such thing for Axe parser, especially for home screen stuff, where it might be impossible.
Title: Re: Axe Parser
Post by: calc84maniac on February 05, 2010, 08:01:00 am
I think the only way to speed up anything related to text display is to have a custom font routine, though. I am not sure how easy it would be to implement such thing for Axe parser, especially for home screen stuff, where it might be impossible.
I think the problem here is that the output ASM program has to work on its own, so all the font data and routines would be unnecessary overhead
Title: Re: Axe Parser
Post by: TIfanx1999 on February 05, 2010, 08:32:43 am
Oh ,that's right! It would bloat your program by the size of the font display routine(s) and the sprites needed for font(s).
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 05, 2010, 11:52:48 am
Yeah that too, which is why it's best to not implement such thing.
Title: Re: Axe Parser
Post by: ztrumpet on February 05, 2010, 04:35:48 pm
Version 0.0.3!!  Yay! ;D

I'm glad this is progressing nicely. It's going to be something that I code little games in, like the two (or three) I've released this week. :D
Title: Re: Axe Parser
Post by: Quigibo on February 15, 2010, 03:03:53 pm
New version out.  I bet you can't do THIS in basic:
(http://www.omnimaga.org/index.php?action=dlattach;topic=1463.0;attach=719)
Its a game of life simulator.  It is horribly unoptimized since I haven't added pointers yet, but its fast enough to really see the speed difference with BASIC.

By the way, please do not post in the updates thread.  Whatever you would post there, post here instead, this is the discussion thread.
Title: Re: Axe Parser
Post by: Eeems on February 15, 2010, 03:07:43 pm
sweet! cant wait to try it!, also, I love the example :P
Conway's Game of Life FTW!

EDIT: oops sorry, I forgot x.x
Title: Re: Axe Parser
Post by: ztrumpet on February 15, 2010, 03:54:13 pm
Awesome!  I can't wait to try it.  Is it stabile enough to put on my calc?

I'm confused over this:
Quote
""           Creates a non-terminating string in memory.
""→NAME Creates a terminating string in memory and names it.
What makes one terminating, and the other non terminating?

Edit: Wow!  I love the way it compiles. ;D It's excellent.
The example program is very well done.  Great job on it too. ;D
________________________

Quote
Quote
While is still PreTest, and Repeat is still PostTest, right?
Its pretest right now... was it post test in basic?  I've never used it before, but that would be very easy to change and also save 3 bytes.
Yes, it is post test in basic.  :)
I noticed this hasn't been fixed, and I was wondering if you'd forgotten about it. :D
Thanks!
Title: Re: Axe Parser
Post by: Quigibo on February 15, 2010, 04:21:30 pm
Terminating means that the string will end.  Literally, it means a null character is added to the end so that it knows when it gets to the end of the string. If you type:

"HELLO"[20]"WORLD"->Str1
Disp Str1

It will print "HELLO WORLD" since 20 is Hex for space.  The hello part of the string will not terminate so it will continue to the rest of the data.

"HELLO"[]->Str1
" WORLD"[00]
Disp Str1

This also will print out "HELLO WORLD" since hello is NOT terminated in that first line so it continues to print the data until it reaches the null character.

EDIT: Oh about the pretest/posttest.  Turns out it would be actually more code if I did that so I don't know if I will change that in the future.
Title: Re: Axe Parser
Post by: ztrumpet on February 15, 2010, 05:41:22 pm
Oh, okay.  Thanks for the clarification. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 16, 2010, 12:03:20 am
WOW awesome, glad to see new updates :)

That said, could this be the first time a TI programmer respects a deadline in history? :O
Title: Re: Axe Parser
Post by: trevmeister66 on February 16, 2010, 01:08:57 am
That looks awesome. Im really looking forward to a BASIC replacement that's much easier to learn than ASM. Keep up the good work!
Title: Re: Axe Parser
Post by: calc84maniac on February 16, 2010, 01:53:02 am
WOW awesome, glad to see new updates :)

That said, could this be the first time a TI programmer respects a deadline in history? :O
/me glares at Spencer...
/me glares in a mirror...

Edit: Hold up, I don't set deadlines. I'm innocent! 8)
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 16, 2010, 01:53:28 am
You both did? :O

I myself never did actually x.x, generally the programs got released either later or... earlier :P
Title: Re: Axe Parser
Post by: calc84maniac on February 16, 2010, 01:54:45 am
You both did? :O

I myself never did actually x.x, generally the programs got released either later or... earlier :P
Nah, I was glaring because of procrastination
Title: Re: Axe Parser
Post by: Quigibo on February 16, 2010, 01:31:45 pm
Its pretty easy for me to make deadlines in Axe Parser.  Since there really is no end to addable features, I can just keep adding things until I run out of time and then release what I have.  Unlike games, an unfinished parser is still functional.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 16, 2010, 02:16:05 pm
Aaaah ok I see ^^. Yeah finished games are hard to set deadlines for. People who frequented TI forums around 2004-05 probably noticed I never set public deadlines for my projects back then, even thought I programmed at a rapid rate. My motto was "It will be done when it's done". A game can be functional and fun even if not finished, but often you can't even beat it or you may encounter bugs preventing you from beating it.
Title: Re: Axe Parser
Post by: Eeems on February 17, 2010, 07:28:18 pm
well I finally got this one on my calc, I'll test it and hopefully I can make headway on a game I'm making with it :P
Title: Re: Axe Parser
Post by: Builderboy on February 17, 2010, 08:02:44 pm
I'm waiting until isKeyDown is implemented before i try to make a game.  I have started on some very neat graphical demo's that i might post soon though ^^
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 12:11:17 am
Hoping you won't ditch serenity :P
Title: Re: Axe Parser
Post by: Builderboy on February 18, 2010, 12:29:29 am
Nooo stop worrying DJ, I don't ditch projects :) I may reach periods of slow/no activity, but be assured it will pick up again.  Same thing happened with many other big projects I have worked on, most memorably Trapped, where i had almost half a year go by before i picked it up again.

Either way, i will most likely just be experimenting with simple arcade games and graphical demo's with Axe, I have enough on my plate, and I can't bring myself to start another large Calc project while Serenity is still unfinished.
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 12:30:54 am
Ah, well it's kind of harder to set that up from what I understand.
So I finished making a game and it runs pretty fast :D I had to slow it down D:
it's a space shooter where you have to destroy the incoming enemies. You have a laser and they move randomly and slowely move towards you when it reaches you you lose health, and every time you kill it you get some points :D
also there is a health Gage for you and for them on the bottom of the screen. And this is fully graphical :p
I'll try to get the source up soon
right now it's only 1592 bytes assembled and 679 with comments unassembled :p
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 12:31:01 am
aaah ok phew. I really have been looking forward for Serenity for a long while x.x
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 12:48:14 am
Can't wait for the arcade games! And serenity!

I just added score display at te end of the game, and this is actually quite hard. It usually takes two passes to kill the enemy x.x I'll have to add a menu with speed and difficulty (so like your health and theirs.)

edit: was able to cut the size down to just over 1600 bytes
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 12:57:48 am
Screeniez soon? :D
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 01:59:53 am
Possibly, I'd have to get it on the comp first, so possibly tomorrow.
Title: Re: Axe Parser
Post by: Builderboy on February 18, 2010, 02:04:38 am
Wewt I made my first simple game! ^^ Its the classic helicopter game where you are flying in a cave an you try not to touch the walls, but they keep getting closer... :P I made use of the Asm() function to get scrolling, and it works very nicely ^^

(http://i199.photobucket.com/albums/aa72/builderboy2005/SCREENIE.gif)

I'll post the source and program too for all os those who want to take a peek at the source, maybe give me a few pointers :D
Press up to go up, gravity takes care of the rest!

Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 09:52:48 am
Amazing! Can't wait to take a look!
Title: Re: Axe Parser
Post by: ztrumpet on February 18, 2010, 04:18:35 pm
Awesome!  Great job!
I can't wait for Serenity also. ;)
Title: Re: Axe Parser
Post by: Quigibo on February 18, 2010, 04:25:43 pm
That's awesome!  ;D  I can't wait to see everyone's projects! I'll open a new thread for posting programs after the next release!

Just so everyone knows, I temporarily do not have internet right now, I'm basically checking everything once or twice a day at school or at the library.  So I can't respond to things quickly.

By the way, I already have sprites working in the next release, but I have to get pointers working before I can release it since the routines rely on pointers.  Expect 0.0.5 sometime this weekend.  At that point, games will be quite nice looking and can get relatively complex.  I may or may not have lists working (variable pointers) but there will be other ways around that in the mean time.  After that, I will focus a bit more on the Axe GUI, especially naming programs  ;), and safety features.
Title: Re: Axe Parser
Post by: Galandros on February 18, 2010, 04:40:59 pm
The game of life program and the helicopter game (I think it is more a cave dweller) show already the potential on this. But there is plenty still available, I think.

Keep up!
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 05:33:12 pm
yay can't wait for the new version! and here is the source for two games :P

EDIT: here is a screenshot of the first one
EDIT2: here is the screenshot of the most recent one
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 06:13:01 pm
Wow darn I just tried that Cave Runner game and that's impressively FAST! Nice job Builderboy on it and Quigibo on the parser.

Quigibo I hope you get internet back soon x.x, did your ISP had troubles or stuff like this? I remember once I lost access for half a year and it sucked but it was for a different reason x.x

Back on the topic, I am curious if in the future, generated programs will be a bit smaller or the same size as their BASIC counterpart?I noticed the Cave thing is twice bigger in ASM form than the source x.x
Title: Re: Axe Parser
Post by: ztrumpet on February 18, 2010, 06:37:02 pm
Eeems! Nice! I really like the version of Hunt. ;D  The "hit enemy" animation is great!
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 06:44:04 pm
Thanks ztrumpet! I went through lots of different versions before coming up with this one.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 07:00:37 pm
Btw is it me or does that version of hunt seems to run at the same speed as the pure ASM one? o.o
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 07:05:09 pm
Yeah it does because it's all dependant on registering keypresses, it waits for one, so it's going to have a maximum speed.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 07:10:42 pm
Aaaah ok yeah x.x, now imagine if you used custom getkey and sprite routines XD, you would need to slow it down else it would be uncontrollable XD
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 07:57:15 pm
Lol well not really because I'd still make it wait for a keypress :p
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 08:29:11 pm
yeah but I mean if you hold down a key :P and allowed holding down keys :P
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 08:34:39 pm
oh yeah :P lol well I'm ok with the speed it runs at, because it's pretty much the same speed on any calc :P
hmm, just had a thought, does Axe Parser put you in 15Mhz mode on 84+(SE)?
Title: Re: Axe Parser
Post by: ztrumpet on February 18, 2010, 09:01:32 pm
I'm pretty sure since it's an Asm program, it will run faster (15Mhz) on the 84+/se calcs.  Can someone back me up? :)
Also, the "fast" speed is 15Mhz but what is the slow speed (83/83+).  Thanks! ;D
Title: Re: Axe Parser
Post by: Eeems on February 18, 2010, 09:02:47 pm
well actually apparently the 84+/se needs to be set to 15Mhz for ASM....but I don't know...
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 18, 2010, 09:07:22 pm
when you play a game like Galaxian or Gemini, the calc is slowed down to 6 MHz when launched. I think some games manages to set the calc to run faster for certain game tasks and even during entire games, though.
Title: Re: Axe Parser
Post by: Quigibo on February 18, 2010, 10:00:28 pm
The reason for the down internet is that I just moved closer to the college and I haven't gotten the internet service yet.

Games will most likely not be comparable to the size of the source.  There are several reasons for that.  First of all, many of the routines can be smaller (like Dispgraph) if they use the built-in operating system calls, but that would really defeat the purpose of this project, so I am writing my own faster routines.  Secondly, Axe source code can be made more compact than BASIC source code of the same program, so that kind of gives a bias to the file size numbers.  Lastly, you have to re-learn how to optimize code.  Similar to how there are so many tricks in basic to reduce size and/or increase speed, there are many many more shortcuts in Axe.  For instance, A+1 results in smaller code and faster speed than 1+A.

Don't forget, I still have a lot more optimization to do.  I've already made a lot of improvements for the next version, its already producing 15% smaller code and there are still many more optimizations to do.  Another thing that will be added in the future will be shell support meaning that some routines will simply be calls to the shell functions, greatly reducing the file size.  In the future, I would expect well optimized Axe Parser code to be approximately 1-2 times the size of its source, and only about 1.5 times the size of a pure assembly equivalent.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 19, 2010, 02:15:46 pm
Oooh ok I see. In my case I still lived at my mom's and she felt I spent too much time online so she got rid of my access, even thought I was the one paying all of it and that I was adult x.x, don't wonder why I moved out the summer after... (see what it did to Omnimaga from Feb to Jun 07 (http://www.omnimaga.org/images/graph.png))

I recommend writing your own routines, personally, providing it's not tasks close to impossible (I heard doing an horizontal line routine in ASM can be extremly hard), because ROM Calls are often slower in general than if you do it yourself.

I don't really mind if the compiled programs are the exact same size as the source, though, altough smaller will give more freedom in what we want to create ^^

On a side note: how much RAM is needed to compile a program besides the source RAM + the RAM the compiled program will take?
Title: Re: Axe Parser
Post by: Quigibo on February 19, 2010, 02:52:23 pm
Well in the future, the source will be archived as it is being compiled.  No RAM is used in Axe itself, so you have the entire free ram to create the executable.

By the way, that cave scroller game got reduced by about 50 bytes when I compiled it with the new automatic optimizations, plus I reduced it another 50 bytes from simple optimized source code tricks.  An additional 50 bytes or so could be shaved off by using Ion routines.  There is even more that can be done, but I'm just demonstrating that the file size you see now will in no way be the final size when I finish this project.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 19, 2010, 03:03:48 pm
aaah cool, will it be hard to implement, tho? I heard writing to flash can be quite a challenge, unless for example, the program would be compiled completly in RAM, then archived (which would require more RAM). I could be wrong, though.
Title: Re: Axe Parser
Post by: Quigibo on February 21, 2010, 09:28:25 pm
New update is here!  Expect a new update every Sunday from now on I think.

This version is much more powerful, but still lacks data structure manipulation for complex games (you know, lists and matrices and stuff).  But that will be what I'm going to work on next.

I also included a tiny optimization tutorial with some stats.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 21, 2010, 09:48:33 pm
Darn that's impressive! Glad you got so much done so far, and that game runs so friggin fast compared to BASIC. Nice job on the project so far ^^, I'm glad finally an alternative BASIC language is going further than just speculation and mockups
Title: Re: Axe Parser
Post by: jsj795 on February 21, 2010, 10:05:18 pm
WOW! Lovely! I would definitely use this for the TLM sequel if I make one!
I love the screenshot too! They are AWESOME
Goob job, and keep up the great work!
Title: Re: Axe Parser
Post by: Raylin on February 21, 2010, 10:31:01 pm
Question.
Can xLib commands be parsed as well?
Title: Re: Axe Parser
Post by: Eeems on February 21, 2010, 10:43:58 pm
No they can't, this isn't anything like standard BASIC, it's got it's own command set.
Title: Re: Axe Parser
Post by: Quigibo on February 22, 2010, 02:51:36 pm
I've never used xLib, but if there's any commands from there you would like to see in Axe Parser, you can always request them.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 03:36:18 pm
It would be interesting to see:

*[ON] Break toggle on/off
*Tilemapping
*Text Modes
*Draw Shape (a MUST)
*Celtic III filesystem (the ability to make an AppVar and such.)
*Background Hex Sprite scrolling

:D
Title: Re: Axe Parser
Post by: ztrumpet on February 22, 2010, 03:36:40 pm
I really like the new commands!
Can we do getKey(101)?
All the new commands are excellent, but I think Horizontal and Vertical are the best. ;D

Oh, and the Optimizing Tricks are excellent. :)
Title: Re: Axe Parser
Post by: Eeems on February 22, 2010, 06:34:47 pm
@ProphetsDementia: actually you could just make your own macro for drawshape you know...but it would be nice to have it supported...
and [ON] is already toggled off, so you don't need to worry about it...but it would be nice if you could use the [ON] key for something...I've also already requested the Celtic III commands, which I think would be a must :P. I'm also sure you could do the scrolling hex sprite background yourself as well...
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 07:09:55 pm
Define macro, sir.
Title: Re: Axe Parser
Post by: Builderboy on February 22, 2010, 07:38:49 pm
I believe he just means that you could write your own graphics routine using the given graphics commands and use them as subPrograms in your program.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 07:53:34 pm
Also, how fast are we talking about for this Axe Parser?
Nearly fast enough isn't specific enough for me.
Is there a considerable difference in speed in relation to ASM?
And when should I start programming in this language?
I don't want to start a program just to scrap it because of a new version that came out.
Title: Re: Axe Parser
Post by: Eeems on February 22, 2010, 07:59:20 pm
It's about 1.5x the speed of straight asm, and you won't have to worry about scrapping it, all new versions do is add new commands, so at most you will have to modify it a bit or update a command if there is a change in syntax, which hasn't happened yet.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 08:04:28 pm
Hot damn.
And, it's still BASIC? :D
Title: Re: Axe Parser
Post by: Builderboy on February 22, 2010, 08:08:51 pm
It's about 1.5x the speed of straight asm, and you won't have to worry about scrapping it, all new versions do is add new commands, so at most you will have to modify it a bit or update a command if there is a change in syntax, which hasn't happened yet.

A-what?  1.5x slower you mean right?  Its definetly not faster :P
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 08:09:32 pm
Buzzkill, Builder. Buzzkill. D:
I am slightly saddened by this fact.

But, any speed boost in BASIC is an upgrade.
That much is true.
Title: Re: Axe Parser
Post by: calc84maniac on February 22, 2010, 08:15:16 pm
Buzzkill, Builder. Buzzkill. D:
I am slightly saddened by this fact.

But, any speed boost in BASIC is an upgrade.
That much is true.
It's not Basic. It's a whole new language that takes some of the Basic syntax.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 08:16:29 pm
Intriguing.
How different are we talking?
Is it still readable?
Title: Re: Axe Parser
Post by: Eeems on February 22, 2010, 08:45:06 pm
Oops you are right, 1.5x slower....
It's a lot like basic, but it has way more capabilities, like build it sprite commands and such. Right now that and the speed is all it has over basic, but as more commands are added it will get way better.

And yes, it's still very readable.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 09:04:35 pm
So, how does this work?
Does the Parser just sit in Archive as an ASM program?
Or is it an APP?
Title: Re: Axe Parser
Post by: ztrumpet on February 22, 2010, 09:13:11 pm
You type a program up as a basic program.  Then you run the Axe App and select your program.  Then it compiles and (since it only supports one program name currently) you type "Asm(prgmLOL" and rum it.  That's about it. ;)
Title: Re: Axe Parser
Post by: Quigibo on February 22, 2010, 09:13:31 pm
Just fyi, 1.5x slower was an upper estimate.  Most games will spend the vast majority of their CPU time drawing sprites and copying the buffer to the screen, which is same speed as pure ASM anyway, so there will be no considerable difference with regular asm speed.  The slowdown would only be noticeable if you had to do intense computations like trying to do 3d graphics or large particle effects or something like that.  In the case where you do need some "really fast processing" you can always write it in assembly and include it in the program.  You could for instance import an entire ray casting engine into the program but write the actual game mechanics in axe parser and it would probably be a lot easier to program than if the entire thing were assembly and run at about the same speed.

@ProphetsDementia
If you want to see how it works, download the latest version.  It comes with 4 example programs so you can get an idea about how the syntax looks.  I also included a complete instruction set.

I am trying very hard to make sure that every new version only adds features and is reverse compatible with older versions.  Occasionally I may have to make some changes, but they will always be minor and easy to fix.
Title: Re: Axe Parser
Post by: Raylin on February 22, 2010, 09:26:28 pm
MY GOD.
Axe-compiled programs FLY on 84+ SE's!

EDIT: What the hell? I can't spell today.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 23, 2010, 01:53:55 am
Btw I don,t remember if I asked this or if someone asked this, but does Axe programs run at the same speed on both 15 MHz calcs and the 6 MHz 83+, like other ion/mirage games?
Title: Re: Axe Parser
Post by: Galandros on February 23, 2010, 08:58:41 am
Btw I don,t remember if I asked this or if someone asked this, but does Axe programs run at the same speed on both 15 MHz calcs and the 6 MHz 83+, like other ion/mirage games?
I think Axe runs faster in 15Mhz because it makes use of the faster speed available.
Title: Re: Axe Parser
Post by: calc84maniac on February 23, 2010, 02:34:21 pm
Btw I don,t remember if I asked this or if someone asked this, but does Axe programs run at the same speed on both 15 MHz calcs and the 6 MHz 83+, like other ion/mirage games?
I think Axe runs faster in 15Mhz because it makes use of the faster speed available.
Nah, Axe programs run in 6MHz. I tried running in 15MHz and the Fastcopy routine failed. :( Quigibo, you should use a Safecopy routine so people won't need to use ALCDFIX with Axe programs. Also, running the Axe parser in 15MHz mode could really speed up compiling times.
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 23, 2010, 03:07:09 pm
oh right the broken LCD drivers... x.x
Title: Re: Axe Parser
Post by: Quigibo on February 23, 2010, 04:50:56 pm
Oh, I though it was in 15MHz mode by default... I'll try that.  But wouldn't safe copy make the routine really slow?  And if that's the case, why not just use GrBufCpy since isn't that what it does already?

I currently have reading and writing to ram working now, it was surprisingly simple to add.  But as I was using it, I realized that it would be an extreme convenience to have built-in data structure support that allows for adding, removing, reading, and writing data from a predetermined stack in ram.  I'll have to come up with some really clever syntax though, it'll be tough.
Title: Re: Axe Parser
Post by: Eeems on February 23, 2010, 05:10:24 pm
I can't wait for that!
Title: Re: Axe Parser
Post by: ztrumpet on February 23, 2010, 05:31:35 pm
Sounds great! I can't wait as well. ;D
Title: Re: Axe Parser
Post by: calc84maniac on February 23, 2010, 05:40:53 pm
But wouldn't safe copy make the routine really slow?  And if that's the case, why not just use GrBufCpy since isn't that what it does already?
The only difference with safe copy as opposed to fast copy is that it uses a loop to poll the LCD port and wait until it's ready for data. DoorsCS uses this as its fast copy routine. GrBufCpy, on the other hand, is simply a slow TI routine no matter how you look at it.
Title: Re: Axe Parser
Post by: Quigibo on February 28, 2010, 04:44:13 am
Alright, the moment you've all been waiting for, Axe Parser 0.0.6 is finally out, widening the range of what is possible by a HUGE amount.  This is the last of the 0.0 series.  In 0.1 I will be working on improving the GUI, error handling, and safety features until it is somewhat acceptable.  I might also throw in a new command or two every so often.

Looking forward to seeing some new projects. :)
Title: Re: Axe Parser
Post by: trevmeister66 on February 28, 2010, 04:49:25 am
Woot Woot! *off to download new version*
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 28, 2010, 05:55:33 am
WOW darn you keep impressing me more and more. It's amazing to see a TI-BASIC like language (that is actually almost TI-BASIC since it uses the BASIC tokens as they were intended for or close) run at such speed and so many sprites moving around without slow downs. That sure deserves a ticalc feature when this comes out. In fact even in its current completion state it would, IMHO.

Plus there are alerady nearly entire games produced in such short amount of time. That goes to show how sometimes BASIC can let people do stuff incredibly fast due to the higher level syntax (altough larger than straight asm programming)

Btw, I assume people will upload their games in TI-83 Plus Assembly Games at ticalc, right? Because for 68k, all C games are uploaded in assembly sections, even thought they were not originally written in assembly. I encourage authors to provide their Axe source code with their releases to encourage people to learn the language more ^^
Title: Re: Axe Parser
Post by: ztrumpet on February 28, 2010, 10:03:03 am
Quigibo, awesome!  This looks great! :D

I think I'll concentrate more on Elmgon for the next week-or-more, but I can't wait to work with pointers!  Excellent job!  ;D
Title: Re: Axe Parser
Post by: Builderboy on February 28, 2010, 12:37:12 pm
Wow this is incredible, cant wait to get back from vacation to go download this immediately ^^

Out of curiosity, when using the PlotScreen *high* volatility RAM, does that allow you to write to the screen buffer as RAM instead of as Pixels? 
Title: Re: Axe Parser
Post by: Quigibo on February 28, 2010, 12:42:54 pm
Not instead, it IS the pixels.  You can write directly on the screen that way if that's your intention.  You're not always using the buffer though, like in a text only game you could write to there as actual storage.

Don't forget to clear some of these buffers.  Like if you don't end the program with a ClrHome but you used the text shadow, you will get garbage on the screen when the program quits.
Title: Re: Axe Parser
Post by: Builderboy on February 28, 2010, 12:49:28 pm
Well i mean you could write a whole row of 8 pixels with one byte, just because of the way the data is stored, and that could make for some very interesting and fast effects :)

It also could allow for faster line drawing (horizontal anyway XD) since we wouldn't have to write to each horizontal byte 8 times to fill it up.  For vertical your pretty much out of luck :P Now i need to reserect my scrapped line drawing routine and make something fun.
Title: Re: Axe Parser
Post by: Quigibo on February 28, 2010, 04:04:21 pm
Right, a horizontal line can be written like this:

:Lbl HL
:*12->B
:For(A,0,11)
:255->{B+A+L6}
:End
:Return

Called like this:
:Xsub(HL)
Title: Re: Axe Parser
Post by: calc84maniac on February 28, 2010, 10:40:54 pm
Quigibo, the program list goes incredibly slowly now that you're alphabetically sorting (I have well over 100 programs, I'd say). Could you at least add pressing letter keys to jump to the letter?
Title: Re: Axe Parser
Post by: Silver Shadow on March 01, 2010, 01:27:11 am
How about just making Axe programs with headers?
Title: Re: Axe Parser
Post by: Quigibo on March 01, 2010, 02:02:55 pm
That wouldn't fix the speed issue though.

Hmm... is it possible to sort the symbol table alphabetically before stepping through it?  That way everything would already be in order and it wouldn't have to be sorted as its going through the list.  Is there a bcall for that?  If not, is it as simple as swapping the entries, or are there other dependent pointers I have to change?
Title: Re: Axe Parser
Post by: Galandros on March 01, 2010, 02:18:04 pm
Hmm... is it possible to sort the symbol table alphabetically before stepping through it?  That way everything would already be in order and it wouldn't have to be sorted as its going through the list.  Is there a bcall for that?  If not, is it as simple as swapping the entries, or are there other dependent pointers I have to change?
There is an assembly program for that already and the source code is available.
Here it goes:
http://www.ticalc.org/archives/files/fileinfo/326/32691.html
Title: Re: Axe Parser
Post by: ztrumpet on March 01, 2010, 05:36:53 pm
How about just making Axe programs with headers?
I myself like this solution best...
It seems like there would be less clutter. :D
Title: Re: Axe Parser
Post by: Quigibo on March 01, 2010, 06:08:10 pm
While we're on the topic of headers, would you prefer large advanced headers or a simple one.  What I mean by that, is that you can store other information in the header like what shell it should compile to, the name of the output file, some setting to optimize more for speed or size, and other stuff.

But that information doesn't have to be in the source file, you can enter all that data into Axe Parser itself and it will save your settings so you don't have to re-enter that information every time you compile.

I kind of prefer the later since the big headers will just be more to learn and increase source file sizes, but what do you all think about it?

Another thing I was thinking about is maybe instead of a header, you just have to end the program name with a "theta" or something.  This doubles as both a header AND it prevents you from trying to output to a file with the same name.  So if you're making a pacman game, then the source file would be "PACMANθ" and it would compile to "PACMAN" as the output.  You would probably also have the option of naming it something else in case you need 8 letters or something.
Title: Re: Axe Parser
Post by: Builderboy on March 01, 2010, 06:16:37 pm
The way I would personally like it is simple one-line headers (something akin to MirageOS headers in Basic, but not exactly the same) and then options in the App to control other options and program output.  And i have seen games (such as factory theta for example) that do end in theta, so thats not an entirely foolproof method. 
Title: Re: Axe Parser
Post by: ztrumpet on March 01, 2010, 06:24:14 pm
The way I would personally like it is simple one-line headers (something akin to MirageOS headers in Basic, but not exactly the same) and then options in the App to control other options and program output.  And i have seen games (such as factory theta for example) that do end in theta, so thats not an entirely foolproof method. 
I think the same as Builderboy...

I think a heading like
:"AXE
would be sufficient and there would be other options in the App as well.
Title: Re: Axe Parser
Post by: Eeems on March 01, 2010, 06:25:42 pm
I'm with Builderboy on this one.
Title: Re: Axe Parser
Post by: Builderboy on March 01, 2010, 06:34:53 pm
I think a heading like
:"AXE
would be sufficient and there would be other options in the App as well.

Well any MirageOS program called Axe would show up then :P
Maybe just 'Axe? Since ' is the symbol for comments anyway?
Title: Re: Axe Parser
Post by: calc84maniac on March 01, 2010, 06:35:54 pm
I think a heading like
:"AXE
would be sufficient and there would be other options in the App as well.

Well any MirageOS program called Axe would show up then :P
Maybe just 'Axe? Since ' is the symbol for comments anyway?

This ^^^
Title: Re: Axe Parser
Post by: ztrumpet on March 01, 2010, 06:38:24 pm
I think a heading like
:"AXE
would be sufficient and there would be other options in the App as well.

Well any MirageOS program called Axe would show up then :P
Maybe just 'Axe? Since ' is the symbol for comments anyway?

This ^^^
Genius!
This ^^^
Title: Re: Axe Parser
Post by: Geekboy1011 on March 01, 2010, 06:47:37 pm
that is awsome and i think that is a good idea as well
Title: Re: Axe Parser
Post by: Builderboy on March 01, 2010, 06:49:52 pm
Hahaha thanks guyz :D
Title: Re: Axe Parser
Post by: Eeems on March 01, 2010, 07:16:41 pm
that is a good idea! I'm still with Builderboy :P
^^
Title: Re: Axe Parser
Post by: Quigibo on March 01, 2010, 09:05:53 pm
Actually, I was thinking of changing the single quote to be an ascii character constant like 'A'.  Not sure what will replace it yet, maybe the decimal point since I haven't used it yet and its a single key press instead of [2nd][angle][down][enter]

How about .NAMEHERE which is tells the compiler what to name the compiled program by default.  The output name can be changed, but that will be what is already typed into the box when you first try to compile.  It seems like a nuisance to have to add 4 characters .AXE that aren't going to be used at all, at least they should do something.
Title: Re: Axe Parser
Post by: ztrumpet on March 01, 2010, 09:26:43 pm
Actually, I was thinking of changing the single quote to be an ascii character constant like 'A'.  Not sure what will replace it yet, maybe the decimal point since I haven't used it yet and its a single key press instead of [2nd][angle][down][enter]
I like that idea, but does it rule out floating point numbers?
Title: Re: Axe Parser
Post by: Eeems on March 01, 2010, 09:36:51 pm
That sounds good
although if you want compiler commands then you could use the . So something like adding support to 84+ specific code stuff so like

.IF 83+=!VER
-code here-
.ELSE
-code-
.END

so you could add some compiler commands and such.
Title: Re: Axe Parser
Post by: Quigibo on March 01, 2010, 10:58:53 pm
Actually, I was thinking of changing the single quote to be an ascii character constant like 'A'.  Not sure what will replace it yet, maybe the decimal point since I haven't used it yet and its a single key press instead of [2nd][angle][down][enter]
I like that idea, but does it rule out floating point numbers?
Floats would be prefixed with "Float" so it wouldn't matter, but I don't plan on adding floats until near the end.  Its really an advanced feature.

And Eeems, anything like that I would implement would probably be with the regular if statement.  I Don't think there is any reason to have preprocessor statements since that stuff is taken care of by options in the compiler.  You don't need a preprocessor to handle different headers for instance since they are added automatically by the parser.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 02, 2010, 12:09:25 am
maybe something like MirageOs but put an additional token in front of it, like ANOVA("PRGMNAME for example
Title: Re: Axe Parser
Post by: Eeems on March 02, 2010, 12:36:00 am
Well what about if you had specific code for 84+'s and some for 83+'s and you wanted the compiler to smartly compile it, like a clock function that calls the clock on one, and for the 83+ it just uses cycles or something.
It would help for the more advanced users.
Title: Re: Axe Parser
Post by: ztrumpet on March 02, 2010, 04:33:36 pm
Well what about if you had specific code for 84+'s and some for 83+'s and you wanted the compiler to smartly compile it, like a clock function that calls the clock on one, and for the 83+ it just uses cycles or something.
It would help for the more advanced users.
I like this idea and I think it would be a nice feature. :)
Title: Re: Axe Parser
Post by: Builderboy on March 02, 2010, 10:08:52 pm
Well what about if you had specific code for 84+'s and some for 83+'s and you wanted the compiler to smartly compile it, like a clock function that calls the clock on one, and for the 83+ it just uses cycles or something.
It would help for the more advanced users.

Well do we want it to compile smartly or run smartly?  Most likely Axe programs will be released as just regular asm programs, and the user wont even ever need to touch the Axe compiler, so having a smart compiler wouldn't make much sense.  What would be better is if the clock function worked different ways on different calculators.
Title: Re: Axe Parser
Post by: Eeems on March 02, 2010, 10:31:56 pm
Well I would be ok with compiling smartly. We could just give out the source and people could compile it themselves. Unless we send it to ticalc then we would just make different versions. Running smartly would make it run slower.
Title: Re: Axe Parser
Post by: calc84maniac on March 02, 2010, 11:02:59 pm
Well I would be ok with compiling smartly. We could just give out the source and people could compile it themselves. Unless we send it to ticalc then we would just make different versions. Running smartly would make it run slower.
How often are you going to have to check calc type though? It's not that slow anyway.
Title: Re: Axe Parser
Post by: Eeems on March 02, 2010, 11:43:16 pm
True, although it adds size to the program that can be cut out. And sometimes people will need to do lots of checking.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 02, 2010, 11:58:22 pm
I am confused about what is compiling "smartly"
Title: Re: Axe Parser
Post by: Eeems on March 03, 2010, 12:27:39 am
So if it is on a 15MHZ calc it will compile certain code and on 6MHZ it will compile something else. That makes it easier to compile for timing and such.
Title: Re: Axe Parser
Post by: calc84maniac on March 03, 2010, 09:56:18 am
So if it is on a 15MHZ calc it will compile certain code and on 6MHZ it will compile something else. That makes it easier to compile for timing and such.
Once there is timing support, it will probably be independent of clock speed anyway (using interrupts)
Title: Re: Axe Parser
Post by: ztrumpet on March 03, 2010, 04:18:29 pm
Well what about if you had specific code for 84+'s and some for 83+'s and you wanted the compiler to smartly compile it, like a clock function that calls the clock on one, and for the 83+ it just uses cycles or something.
It would help for the more advanced users.
Well do we want it to compile smartly or run smartly?  Most likely Axe programs will be released as just regular asm programs, and the user wont even ever need to touch the Axe compiler, so having a smart compiler wouldn't make much sense.  What would be better is if the clock function worked different ways on different calculators.
This is a very good point!  Can there be support for both options? :D
Title: Re: Axe Parser
Post by: Eeems on March 03, 2010, 06:12:08 pm
hmm, well with interrupts that wont be an issue...so I don't really know what I want then.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 03, 2010, 09:51:35 pm
Aaah I see, thanks for the info
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 04, 2010, 10:25:55 pm
Btw, I like how Axe Parser is still under 4 pages of Flash APP. I don't mind very large programs myself, but sometimes it's cool to have a lot of free space when developing, especially for quick backup purposes (groups)
Title: Re: Axe Parser
Post by: Quigibo on March 05, 2010, 11:32:49 am
lol, Axe Parser is still only about 9kb, half of the page!  Probably because there's no graphics, level data, music, etc. which took up over half of Pyoro's 12kb.  I am planning to add some graphics for menus and stuff, but I'm not expecting to use any more than 2 pages total by the end.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 05, 2010, 02:45:00 pm
yeah I noticed when checking the APP size on my PC. I just divided its size by 2 to give me an idea on the space remaining (APPS on a PC are about twice larger than on calc)

Don't add too much graphics, though, it's not really necessary. What I think is that for compiling, just having every non-axe programs hidden from the list should be fine. Probably by having for example .ANOVA(FINAL FANTASY 83 on the first line of the program, then this program would show up in the list. And allowing to go down instantly in the menu by pressing UP at the top of it or going back up when pressing DOWN at the bottom of the list might help too, especially when we have 20-30 programs showing up
Title: Re: Axe Parser
Post by: trevmeister66 on March 05, 2010, 03:10:52 pm
I kind of have to disagree with you a bit DJ, I think graphics is pretty important (although he really doesn't need to add too much, it's already amazing), but, at least from my point of view, Axe is a program that will let the most basic BASIC programmers make games at assembly level with equal graphics and speed, and I think that being able to do most of the graphic capabilities of actual ASM programs is important. But that's just my opinion, and I do agree that other things should also be focused on.
Title: Re: Axe Parser
Post by: calc84maniac on March 05, 2010, 03:31:02 pm
I kind of have to disagree with you a bit DJ, I think graphics is pretty important (although he really doesn't need to add too much, it's already amazing), but, at least from my point of view, Axe is a program that will let the most basic BASIC programmers make games at assembly level with equal graphics and speed, and I think that being able to do most of the graphic capabilities of actual ASM programs is important. But that's just my opinion, and I do agree that other things should also be focused on.
He's talking about graphical user interface for compiling programs
Title: Re: Axe Parser
Post by: trevmeister66 on March 05, 2010, 03:31:58 pm
I kind of have to disagree with you a bit DJ, I think graphics is pretty important (although he really doesn't need to add too much, it's already amazing), but, at least from my point of view, Axe is a program that will let the most basic BASIC programmers make games at assembly level with equal graphics and speed, and I think that being able to do most of the graphic capabilities of actual ASM programs is important. But that's just my opinion, and I do agree that other things should also be focused on.
He's talking about graphical user interface for compiling programs
Ah fair enough. I take back what i said.. heh.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 05, 2010, 03:37:35 pm
Yeah that's what I meant, I really was talking about fancy GUIs. If he decided to make the Axe APP so it has a grayscale program list with 3D animations with rotating program name texts, it would take unnecessary space IMHO. In games, I like to have a lot of graphical abilities. Of course, personally if someone releases an ASCII game I'll still play it, though. Unlike some other people, I don't only play games just for graphics.
Title: Re: Axe Parser
Post by: trevmeister66 on March 05, 2010, 03:42:57 pm
Yeah that's what I meant, I really was talking about fancy GUIs. If he decided to make the Axe APP so it has a grayscale program list with 3D animations with rotating program name texts, it would take unnecessary space IMHO. In games, I like to have a lot of graphical abilities. Of course, personally if someone releases an ASCII game I'll still play it, though. Unlike some other people, I don't only play games just for graphics.
Yeah, I completely agree with that. I just misunderstood what you had posted before :) Plus I really do like ASCII games, although I don't think I would program an ASCII only game with Axe, but that's just me.
Title: Re: Axe Parser
Post by: Silver Shadow on March 05, 2010, 03:48:14 pm
Yeah that's what I meant, I really was talking about fancy GUIs. If he decided to make the Axe APP so it has a grayscale program list with 3D animations with rotating program name texts, it would take unnecessary space.
lol
That kind of GUI would be freakin' awesome!!! :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 05, 2010, 04:03:56 pm
Yeah that's what I meant, I really was talking about fancy GUIs. If he decided to make the Axe APP so it has a grayscale program list with 3D animations with rotating program name texts, it would take unnecessary space IMHO. In games, I like to have a lot of graphical abilities. Of course, personally if someone releases an ASCII game I'll still play it, though. Unlike some other people, I don't only play games just for graphics.
Yeah, I completely agree with that. I just misunderstood what you had posted before :) Plus I really do like ASCII games, although I don't think I would program an ASCII only game with Axe, but that's just me.
Don't do an ASCII-only game with Axe. I don't recommend it, because due to TI's slow text routines, such game will run considerably slower than a game using sprites. Notice how every text-based demos seems to run much slower than the graphical stuff so far
Title: Re: Axe Parser
Post by: Raylin on March 05, 2010, 08:18:48 pm
I believe I made a topic for it already.
But, I'm entering a competition for a scholarship using xLib and BASIC.
Lemonade Tycoon is my game.

Now, here's where it comes together.

I'm using a Presentation Link and a TI ViewScreen.
I ran my program that uses xLib. It shows up fine on the calc...
but it's got the wavy screen on the screen.

AND IT'S JUST THAT PROGRAM.
Everything up to that point (the PRGM menu, the Home Screen, the Graph Screen) displayed fine.

Can Axe screw up xLib programs?
Title: Re: Axe Parser
Post by: calc84maniac on March 05, 2010, 08:25:28 pm
I believe I made a topic for it already.
But, I'm entering a competition for a scholarship using xLib and BASIC.
Lemonade Tycoon is my game.

Now, here's where it comes together.

I'm using a Presentation Link and a TI ViewScreen.
I ran my program that uses xLib. It shows up fine on the calc...
but it's got the wavy screen on the screen.

AND IT'S JUST THAT PROGRAM.
Everything up to that point (the PRGM menu, the Home Screen, the Graph Screen) displayed fine.

Can Axe screw up xLib programs?
Where does Axe fit into all of this? And Axe does not install any OS hooks or anything like that.
Title: Re: Axe Parser
Post by: Raylin on March 05, 2010, 08:36:14 pm
Perhaps Axe-compiled programs, when executed, leave some malevolent artifacts... ?
I was playing around with bytes before this happened.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 05, 2010, 09:46:40 pm
I doubt Axe can screw up programs like this. If it did, it's because you messed with the pointer stuff or used inline assembly. As mentionned in the documentation at the bottom, some pointers can cause instability on the calc. I assume bytes stuff can also pose problems if not used properly too.

In any case, always backup your stuff before testing anything, though. You must never take any chance, especially considering xLIB and Axe are not finished and that there can be errors on both sides (xlib/axe or your code)
Title: Re: Axe Parser
Post by: Raylin on March 06, 2010, 09:48:09 am
Okay then. Found my problem.
It's good now.

Question about Axe, though.
Say you wrote the following code:

Code: [Select]
:15->{A+1}
:Disp {A+1}>Dec

How big do those defined bytes get?
Title: Re: Axe Parser
Post by: Eeems on March 06, 2010, 11:31:11 am
Well...ummm...where is A x.x
that's pretty dangerious actually, because whatever te value in A is, that's where you are playing around with. I would recommend using L1/2/3 or maybe defining the bytes in the program with Str1/2/3 etc.
If you define them in the program then it is only as big as you made it. Otherwise if you use L1/2/3 then you would have to look in the documentation to see.
Title: Re: Axe Parser
Post by: Builderboy on March 06, 2010, 06:38:26 pm
Yeah thats incredibly dangerous, I'm surprised you didn't clear your ram that way O.O
Title: Re: Axe Parser
Post by: Quigibo on March 06, 2010, 06:46:49 pm
How do you know he didn't do this first:
:L1->A

I use that trick all the time when I have a lot of math like:
:Y*8+X+L1->A

Because that way it can become:
:{A}->B
:15->{A}

Which saves memory and speed if you call it a lot.
Title: Re: Axe Parser
Post by: Builderboy on March 06, 2010, 06:50:22 pm
True, so i guess the question would be Where it A?
Title: Re: Axe Parser
Post by: Raylin on March 07, 2010, 07:46:28 am
I directly assigned that value to {A+1}.
So, that was bad...?

EDIT: Anyone else wake up and immediately log on to Omnimaga, eagerly anticipating the new Axe release every Sunday?
Title: Re: Axe Parser
Post by: Eeems on March 07, 2010, 12:00:20 pm
Yeah that could be bad if A wasn't set to a safe area then who knows where you put that value x.x

I did too :p
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 12:46:12 pm
OH! Also, one thing:

When Axe will support Mirage and Ion (and DCS since MOS/Ion progs shows in it), it will be important to be careful to not use RAM areas in your games that are used in MirageOs. I remember Zelda: Dark Link Quest used an ASM utility that did and when exiting Mirage (back when it was in beta, the game showed in Mirage) it crashed. I heard xLIB sometimes had issues, too, with this.
Title: Re: Axe Parser
Post by: Raylin on March 07, 2010, 12:56:20 pm
Seconded.




LOL THIS IS NOT SPAM.
Title: Re: Axe Parser
Post by: ztrumpet on March 07, 2010, 02:06:04 pm
OH! Also, one thing:

When Axe will support Mirage and Ion (and DCS since MOS/Ion progs shows in it), it will be important to be careful to not use RAM areas in your games that are used in MirageOs. I remember Zelda: Dark Link Quest used an ASM utility that did and when exiting Mirage (back when it was in beta, the game showed in Mirage) it crashed. I heard xLIB sometimes had issues, too, with this.
Yeah, it's too bad that Mirage relies on so much.  :(
You could make your program show up in mirage by putting this on the first line:
Asm(BB6DC930)
However, it may crash, so I'm not trying it. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 03:05:30 pm
This is getting a bit offtopic, but is it possible to have a MOS program not have any icon? If so, would it save much space? I ask since sometimes, every byte counts :P
Title: Re: Axe Parser
Post by: ztrumpet on March 07, 2010, 04:39:33 pm
Yes, it is.  The Hex code I gave earlier is for ion programs, and those don't even have a picture with them. :)
I think that's the smallest size you could have for a Mirage program.  It's only 4 bytes bigger than a non-ion program after it's compiled. (I think)
Title: Re: Axe Parser
Post by: Quigibo on March 07, 2010, 04:47:08 pm
It should be Asm(C930)  The assembly header is automatically added by the parser.
Title: Re: Axe Parser
Post by: ztrumpet on March 07, 2010, 04:53:15 pm
It should be Asm(C930)  The assembly header is automatically added by the parser.
Right, I forgot about that.  :)

What I posted was AsmProgAsmProg<hex code here> :D

What would happen if you tried this?  Would the calc crash?
Title: Re: Axe Parser
Post by: Quigibo on March 07, 2010, 05:01:02 pm
No, it translates to:
  cp e
  ld l,l
Which are harmless commands.  The main issue is that MOS won't read it and using Asm() will immediately quit so you can never run the code.


In other news, Axe 0.1.0 is here!  I haven't added much, but I figured that I should release what I have anyway.  College is really taking a toll on my free time so I won't be working as fast as I have in the past.  But I'll still try to add a new update every Sunday even if its minor.
Title: Re: Axe Parser
Post by: Eeems on March 07, 2010, 05:11:43 pm
YAY! can't wait to try it!
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 05:13:22 pm
wow awesome, these releases comes out so fast still. Nice work. I'll install asap!
Title: Re: Axe Parser
Post by: ztrumpet on March 07, 2010, 08:30:38 pm
Awesome!  I can't wait to try it! ;)
Title: Re: Axe Parser
Post by: agent84 on March 07, 2010, 08:51:25 pm
this seems interesting... might take a look if i get the time.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 09:00:57 pm
it would be cool if you got back into programming ^^
Title: Re: Axe Parser
Post by: agent84 on March 07, 2010, 09:31:24 pm
ehhhh, i havent done much programming in months, due to the hectics of college admissions/SATS/random crappiness of life.
I've been thinking i might get into the Apple/iPhone market, and learn to make games on the iPhone/iPod Touch.  I was never much of a calculator programmer, so to me, everything you guys do on this site is pretty amazing.

This Axe program seems like an interesting concept, however, and I might look into it.  Good work, Quigibo!
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 09:33:17 pm
Well the cool thing with BASIC is that it's not too hard to learn. The issue with TI version, though, is the slow speed. But I can understand how the smaller screen and processor can be less attractive toward people.
Title: Re: Axe Parser
Post by: Eeems on March 07, 2010, 09:36:38 pm
Agent84: if you do get into itouch/iPhone developmet, I'll happily beta test for you.
Title: Re: Axe Parser
Post by: agent84 on March 07, 2010, 09:40:23 pm
yea, the main reason I got into BASIC, was that it took me about 10 minutes to get all the basic commands down, and about a couple days to get a working game.  Its a really simple, yet surprisingly deep programming language.  you cant say the same for most other widely used languages.  the reason why most ppl decide not to get into TI BASIC, is because their ignorance towards the platform, and automatically rejecting it, without even taking a look into the programming aspects of it.  When the reality is, that its actually not that bad, and with some effort, can be used to make something great.


EDIT: Eeems:  I dont see that coming for at least 5-6 months.  And its only a possibiliy, it will depend on how much time/effort i will have.  Thanks for the offer, though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 09:51:27 pm
I personally never got able to get far in more complex languages. I did some VB6 and RPG Maker 2003, that's about it. I get an headache at trying to understand C, Java, PHP, RPL and the like x.x

Just trying to do one of the most basic PHP task (modifying echo'ed HTML code on the forum somewhere) took me 5 hours x.x

Now, with that Axe thing that came out, BASIC coders now have more freedom if they want to make arcade games. With BrandonW or Will_W basic interpreters, it will give them two more options if these two softwares comes out too, plus with two softwares entering in the scene, it gives Quigibo competition and might even encourage him to add even more features to Axe on later releases, and maybe the authors could share ideas in the future.

As for iPhone, I think Builderboy has one too, I'm not sure about other members. Some might be interested if you ever create new games in the future
Title: Re: Axe Parser
Post by: Eeems on March 07, 2010, 10:19:06 pm
Yeah both me and bboy have an itouch.
Title: Re: Axe Parser
Post by: trevmeister66 on March 07, 2010, 10:29:14 pm
I also have an itouch, so I would gladly beta test any games.
Title: Re: Axe Parser
Post by: Raylin on March 07, 2010, 11:05:14 pm
Just testing out the commands.
Axe 0.1 still throws out random errors when parsing.
Is this still supposed to happen?
Title: Re: Axe Parser
Post by: trevmeister66 on March 07, 2010, 11:07:51 pm
Just testing out the commands.
Axe 0.1 still throws out random errors when parsing.
Is this still supposed to happen?
Are you sure its a random error? Or does it have something to do with your source?
Title: Re: Axe Parser
Post by: Raylin on March 07, 2010, 11:23:01 pm
I compiled the example program (STARSHIP).
The first time throws back an error.
Second time on works.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 11:29:27 pm
On the previous version, I remember sometimes it failed to compile. It generally happened if I grouped everything, reseted my RAM then ungrouped everything, then tried compiling a program within a fresh RAM for the first time. That happened with the examples too. Usually, retrying twice or three times fixes it.

Title: Re: Axe Parser
Post by: trevmeister66 on March 07, 2010, 11:31:21 pm
That's a weird bug though. I don't see why it would work the 2nd or 3rd time, but not the first.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 07, 2010, 11:37:18 pm
Yeah it's strange x.x

I guess Quigibo will have to look into this x.x

I believe this bug was even mentionned before in a previous page, but this topic grow quickly :O
Title: Re: Axe Parser
Post by: Eeems on March 08, 2010, 12:51:01 am
Yeah it's because the vat shifts around because the program increases in size as it assembles, and every so often the address if the program changes so it's not looking in the right spot. So unfortunatly there is nothing he can do as of yet.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 08, 2010, 02:15:23 am
Aaah I see why, now.

Btw I decided to print Axe 0.1 doc because it was getting annoying to check on the comp. Now I can code away from the comp screen without getting sidetracked too much by the power of Youtube :P :D
Title: Re: Axe Parser
Post by: ztrumpet on March 08, 2010, 06:54:14 am
lol, nice DJ! :D

I hope Quigibo can find a solution! ;D
Title: Re: Axe Parser
Post by: Radical Pi on March 08, 2010, 11:32:09 am
Wow, this language looks powerful! And also very different from the Basic that I remember. I see that it's still pretty early in development though, so how much is the syntax going to change over the coming months? Should I start learning how to use it now, or should I wait for it to stabilize a little more (or is it already fairly stable)?
Either way I can't wait to get my hands on this :D
Title: Re: Axe Parser
Post by: trevmeister66 on March 08, 2010, 12:03:20 pm
Wow, this language looks powerful! And also very different from the Basic that I remember. I see that it's still pretty early in development though, so how much is the syntax going to change over the coming months? Should I start learning how to use it now, or should I wait for it to stabilize a little more (or is it already fairly stable)?
Either way I can't wait to get my hands on this :D
From what I've seen, it's pretty stable. I don't know if you've seen some of the games made already by Axe, but you can do a lot already in the early stages of this program.
Title: Re: Axe Parser
Post by: Quigibo on March 08, 2010, 01:47:20 pm
I'm currently working on that bug.  I'm getting very close.  I'll let you know when I fix it.

The language itself is pretty stable in my opinion.  New commands are going to be added so some larger routines can be replaced by a single instruction later on.  But I don't have any concerns at the moment for reverse compatibility.  If it works on 0.1.0 then it should almost surely work on the final release.  If I do make any major changes, I always list them on the updates.  I've only had to do this once so far and I don't see myself needing to in the near future.
Title: Re: Axe Parser
Post by: Quigibo on March 13, 2010, 03:00:56 pm
I don't think I'll have an update ready this weekend, I'm really really busy.

I am considering changing all math to signed math and then adding a new command set to do unsigned math.  This will only affect multiplication and division with very large/negative numbers and possibly the modulo operation.  I consider this a major change so I'd like some opinions since it can make some older programs incompatible.  Only minor changes usually need to be made though.  Singed math limits multiplication and division to values between -32768 to 32767 instead of 0 to 65535 so you can divide and multiply negative numbers, but then the maximum magnitude of the numbers is half of what it was.  Don't forget, you can STILL do unsigned math, but it will be a different command.  I think making the default signed instead of unsigned makes the language a little simpler for beginners.  I hope no one will mind the inconvenience of having to rewrite some of their programs that really on unsigned math tricks.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 13, 2010, 07:15:44 pm
Mhmm, you will have to choose an easy command for unsigned, though, so the source won't get massive and hard to understand. I personally don't mind the 32767 limitation altough I would hate if the new command was a major hassle to use. Couldn't you set the new command for the signed ones instead? It might save most people a lot of hassle, especially if alerady a lot of people are using Axe in the community.

However, the big advantage is definitively negative numbers, because when I will perform for example physic movement like jumping/falling, the inability to store negative values to variables can cause some issues during movement coding, since for example instead of a -1 to +1 range, the jumping would be 0 to 2, so instead of Y+J->Y, I am forced to do Y+J-1->Y or something like that.

Good luck with your school stuff, I hope they don't overload you with full of work even more x.x
Title: Re: Axe Parser
Post by: Builderboy on March 13, 2010, 08:41:30 pm
Well, there is a kind of genius to unsighned numbers in that you *can* store negative number as long as you are only doing addition and subtraction.  Lets say we wanted to store -1.  That would end up being 65535 in unsigned integers.  This is obviously not a negative number, but lets see what happens when we add 5 to it.  65535+5 = 65540.  But wait!  Integers can only go up to 65535! So the number wraps around to 4.  Did you see that?  We effectively subtracted 1 from 5, even though we added two positive numbers!  This is very very useful because it means you can do things in Axe like:

Code: [Select]
-1->A
5+A->B

And B will equal 4.  The only problem arises when you do multiplication or division, in which case the fact that negative numbers are not negative becomes apparent.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 13, 2010, 09:07:44 pm
yeah I like the looping back. Very useful for some stuff. One thing, though: can problems arise from that? In Final Fantasy 7, if damage power gets insanely high, the displayed damage will be glitchy as hell. Is it safe for example to have a variable increment and keep looping non stop for a very long period of time?

Title: Re: Axe Parser
Post by: Quigibo on March 13, 2010, 09:57:40 pm
The looping around effect happens regardless of sign.  0 decrements to 65535 the same way -32768 decrements to 32767.  Like I said, addition and subtraction are not affected by this change.  -1 is still -1.  The only time it would change is when you multiply and divide with numbers larger in magnitude than 32767.  And I should also mention that the inequality operators will also be affected.

The looping goes on forever if you keep passing the limit.  Unlike Basic, you will never get an overflow error, it will just overflow in such a way that only the least significant bits, that is to say the 16 bits on the rightmost side of any result larger than 16 bits, will be returned.  That's why its very important to put caps on things like scores, health, and lives that you definitely DON'T want to loop around once they overflow.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 13, 2010, 10:04:48 pm
Aaah ok.

Generally, in my RPGs, damage and HP are 9999 max, but if my defense system uses multiplying/dividing, like most of my games, then it can be problematic for example if I cast Holy at maxed out stats against a zombie. The trick would be to either have defense be substracted from damage and have damage never go below 0. That can be a bit problematic when it comes to balancing the game, though. Another trick, which is the easiest, is to go the Final Fantasy 13 way and just get rid of defense altogether.

Generally, I recommend under such limits to set HP to like 999 max, though, so you have less worries. For gold, 999 or 9999 can do. Zelda had 999 after all :P
Title: Re: Axe Parser
Post by: ztrumpet on March 13, 2010, 10:05:34 pm
I'm okay with the change, but I wonder about Builderboy.  A lot of his stuff has things like (#>65000) in it, so he can use negative numbers.  If Builderboy's up for it, then I doubt if there would be much more headaches.  I am fine with the change myself. :)
Title: Re: Axe Parser
Post by: Builderboy on March 13, 2010, 10:11:10 pm
I would love love love for signed numbers, because yeah, for now i have been doing things like

Code: [Select]
If(A>30000)
-(-A*5)->A
Else
A*5->A
End

to multiply numbers, which is a bit annoying.  It gets even worse for inequalities.  Instead of

Code: [Select]
A<10
You need to do things like

Code: [Select]
A<10 OR (A>65326)
Currently there are glitches in the Portal engine that would be fixed with signed numbers :)
Title: Re: Axe Parser
Post by: ztrumpet on March 13, 2010, 10:13:14 pm
Code: [Select]
If(A>30000)
-(-A*5)->A
Else
A*5->A
End
Ah, after reading that I finally understand your code now!  ;D

I'm glad you're up for it.  :)
Bring on the signed numbers!  :D
Title: Re: Axe Parser
Post by: Quigibo on March 13, 2010, 10:22:32 pm
Unfortunately, it does make slightly larger code and it means you can't use the optimizations anymore, but its still a lot less than what Builderboy has been doing.  You can still use the optimizations with unsigned math though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 13, 2010, 10:35:14 pm
btw I had an idea that is not directly related to Axe itself, but more the sprite editor: It would be cool to be able to convert sprites to hex from anywhere on the graph screen because while the editor is good, it can be a bit slow to make sprites. I prefer to edit my graphics in MS Paint or Photofiltre Studio on the computer, or directly on the graph screen. I tried removing the part of the code I would need for that but I couldn't understand most of it since I have trouble reading other people's code.

Or maybe someone else could write this tool?
Title: Re: Axe Parser
Post by: Quigibo on March 13, 2010, 10:40:22 pm
I use this when writing asm programs for large pictures:

http://www.ticalc.org/archives/files/fileinfo/134/13415.html

Just set the output to hex.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 13, 2010, 10:45:39 pm
Mhmm that might work (hoping it does in Windows 7 too :P)

I think I should maybe include this in the downloads section if it does, because it's a nightmare to edit sprites directly in hex x.x
Title: Re: Axe Parser
Post by: meishe91 on March 14, 2010, 12:19:45 am
So what is this signed and unsigned number system? I'm quite confused.
Title: Re: Axe Parser
Post by: Builderboy on March 14, 2010, 12:58:56 am
Well, in the calculator there are no negative numbers.  Negative signs can't be programed into binary i guess you could say :P This is why its called unsigned.  But, negative numbers are very useful in many ways, so you can sign a number which makes it behave like tis negative, even though it is still represented as a positive number in the calculator.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 14, 2010, 03:19:41 am
this page might clear things up:

http://en.wikipedia.org/wiki/Integer_(computer_science)

I have to look at it again all the time because I always forget about each types. x.x Basically, the shorter the integer, the fewer RAM it takes. In z80 assembly you can choose which one to use, altough I don't know if there's a cap. For a RPG, you will want to use 1 byte integers for map coordinates, area ID, LV, ATK, DEF, MAG and SPD, 2 bytes for map ID, HP/MP and damage points, unless these can easily overflow and it's too hard to work around, and 4 byte for other stuff that requires much longer numbers.
Title: Re: Axe Parser
Post by: meishe91 on March 14, 2010, 05:26:33 am
Hmmm ok. Thanks guys. I will have to read that page.
Title: Re: Axe Parser
Post by: calc84maniac on March 14, 2010, 09:12:07 am
According to that page, multiplication doesn't need to be changed for signed values. I think this is correct, because we are only getting a 16-bit result. So signed multiplication will probably work just fine with the current version of Axe :D

Edit:
Never mind, I was wrong. I think there may be some problem with the current multiplication routine.
Title: Re: Axe Parser
Post by: Quigibo on March 15, 2010, 11:30:34 pm
Hope everyone likes the new update.  Should make a few things a little easier.  I haven't converted to signed numbers yet since I still have a lot more routines to change.  I haven't even tested some of the new commands yet other than trivial examples because I've been busy, but I think they all work.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 15, 2010, 11:35:45 pm
Nice to see a new update out!

However, I do not understand most of the new features are about. Someone will really need to make a screenshot showing them in actions with the results and show some source code or something, cuz it is getting beyond my learning capacities (too low level)
Title: Re: Axe Parser
Post by: Quigibo on March 15, 2010, 11:46:17 pm
The only real low level command is the int() which is the sign extension command.  You would mostly use this command when you need to store negative numbers into the RAM in an array.  Negative numbers need 2 bytes since they behave like large positive numbers.  But since you can only store one byte then when you go to read it it will turn into a really small number.  Try doing this:

-1->{L1}
Disp {L1}>Dec

This will not display the 65535 that it is supposed to, instead it will be a smaller positive number.  The way around this is sign extension.  So if you do this instead:

Disp int({L1})>Dec

It will return the correct value.  This only works when the stored value is between -128 and 127.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 12:07:31 am
mhmm ok, I understand this one now. However, I think you migth want to specify this into more details in the doc because I alerady saw this:

Quote
int(EXP)   Returns a sign extention for the expression. Converts a signed byte in the range -128 to 127 into a 16 bit number in the same range.
And it was really cryptic. I totally couldn,t understand what you meant by that. "Returns a sign" to me sounds like it returns 1 if the sign is negative and 0 if it isn't, and stuff like that.

And I cannot understand this at all either:

Quote
Fill(PTR1,SIZE)   Whatever byte is already at the location Ptr1 is copied to Size more consecutive bytes. Zero is not a valid Size.
conj(PTR1,PTR2,SIZE)   Size bytes starting from the location Ptr1 are copied to the location at Ptr2. Zero is not a valid Size.
expr(PTR1,PTR2,SIZE)   Size bytes starting from the location Ptr1 are exchanged with the bytes starting at the location Ptr2. Zero is not a valid Size.

Plus another thing I don't get: what is Size for? I know Ptr seems to involve pointers, but I just don't get it... all I get is that conj is for Copy and expr is for exchange, since it's in the new features list

And what are Hexadecimal constants and ASCII constants for? And what are they at all? I ran a CTRL+F in the command list, and both these things returned no results. To me it seems like it's more the documentation that is getting more and more in the style of low level programmers (explained in a way that can only be understood by tech savy people, specifically low-level language programmers). You did a very good job at writing the command list so far, though. I could understand a lot of stuff and thank you for explaining all this stuff and even the tutorials and examples. It,s just that I just can't understand any of this and it is starting to discourage me, as I though Axe was meant to remain a language easy to understand :/. If even after you explain in more details I don't get it, I hope you promise these commands will not be essential in future Axe versions to have decently optimized Axe games, right? Else I am starting to fear I might have to give up on the whole language or team up with someone else for optimizing. Sorry :(
Title: Re: Axe Parser
Post by: Builderboy on March 16, 2010, 12:15:02 am
Quote
Fill(PTR1,SIZE)   Whatever byte is already at the location Ptr1 is copied to Size more consecutive bytes. Zero is not a valid Size.
conj(PTR1,PTR2,SIZE)   Size bytes starting from the location Ptr1 are copied to the location at Ptr2. Zero is not a valid Size.
expr(PTR1,PTR2,SIZE)   Size bytes starting from the location Ptr1 are exchanged with the bytes starting at the location Ptr2. Zero is not a valid Size.

Ack that could be put better i think.  Try this on for size DJ

Fill(P,L) Takes the first value at the location pointed to by 'Pointer' and copies it to the next L elemends in RAM.  Or if you want a list metaphore, it takes the first value in List P and copies it to the next L elements in the List.

Conj(A,B,L) Continuing the List metaphor, copy all the elements in List A from 0 to L into List B

Expr(A,B,L) Swap all the elements in Lists A and B up to Element L

EDIT: Nija'd by some better examples and code :P
Title: Re: Axe Parser
Post by: calc84maniac on March 16, 2010, 12:16:16 am
I'll give some examples of these commands in use. For example, instead of doing this to fill the 6 bytes at L1 with zeros:
Code: [Select]
:For(X,0,5
:0->{L1+X
:End
You can do this:
Code: [Select]
0->{L1}
Fill(L1,6

The conj( command is just used to copy a number of bytes from one location to another, like if you want to copy 10 bytes from L1 to L2. Here is the old way:
Code: [Select]
:For(X,0,9
:{L1+X}->{L2+X
:End
And here is the new way:
Code: [Select]
:conj(L1,L2,10
expr( does a similar thing, but it exchanges, or swaps, the data at the two locations.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 12:37:12 am
Mhmm ok, because the way it is explained in the doc seems like something totally different. I think it may be best to clarify in the doc that fill does the same thing as the BASIC command, but for pointers instead of lists. Also if I read Builderboy way, I still doN,t get it. To me it seems like he's saying Fill just copy one list element to the next one, not fill the entire list with an element.

About Conj, what if we want to do For(X,9,12:{L1+X}->{L2+X:End?

Also are lists defined the same way as other stuff? Like at the beginning of a program I just do {2,34,5,23,0->L1?
Title: Re: Axe Parser
Post by: calc84maniac on March 16, 2010, 12:57:52 am
Mhmm ok, because the way it is explained in the doc seems like something totally different. I think it may be best to clarify in the doc that fill does the same thing as the BASIC command, but for pointers instead of lists. Also if I read Builderboy way, I still doN,t get it. To me it seems like he's saying Fill just copy one list element to the next one, not fill the entire list with an element.

About Conj, what if we want to do For(X,9,12:{L1+X}->{L2+X:End?

Also are lists defined the same way as other stuff? Like at the beginning of a program I just do {2,34,5,23,0->L1?
For that example, you would want conj(L1+9,L2+9,4

And remember that L1-L6 are just areas of RAM. So, you will need to initialize data just like for a sprite (you will have to convert the values to hex), and store to a String or Pic or something. Then, you should copy your String/Pic to one of the defined RAM areas. (I suppose technically, you could modify the data while it's in the program, but that only works correctly for no-stub)

Edit: Example code
Code: [Select]
:[0222051700->Pic1
:conj(Pic1,L1,5

Edit2:
Also, remember that Quigibo is planning for real array support later. So it should get easier.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 01:00:16 am
mhmm ok, that gets even worse now... can anyone write a basic program to convert lists to hex/axe format?
Title: Re: Axe Parser
Post by: Builderboy on March 16, 2010, 01:05:58 am
Or better yet, ask Quigibo to implement a traditional looking List format for axe source :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 01:10:55 am
Well I just suggested this now. But yeah it is getting quite confusing. I guess he ddint't have time to write more doc, altough maybe someone could actually help.

The way I see it it seems like I am pretty much doomed to stick with TI-BASIC for life, but again, maybe I am just misinterpreting the doc :/
Title: Re: Axe Parser
Post by: Quigibo on March 16, 2010, 12:38:03 pm
Sorry about the doc.  You're right, I didn't have time. I added the documentation the last minute because I was on my laptop in the library and I realized my battery was running low so I scrambled to put it together as fast as I could.  Still don't have internet yet, probably won't for a while, but I don't mind since I'm trying not to be too distracted from my school work and I'm at school almost every day anyway so I just use it there.  I'll try to make it more clear in the next version.

Also you mentioned that you didn't see the hex and ascii constants?  Those are just alternative ways to write numbers.  Its in the middle of the doc somewhere.

Instead of 11->A it is sometimes more convenient to write E000B->A as hexadecimal, especially when you want to access certain locations in the RAM since they are defined in hex, not base 10.  Its a pretty low lew command though, you generally won't need it, but it was requested so I figured I might as well since at the same time I was doing ASCII constants.

You might be familiar with ASCII already, but each character is represented by a number.  So if you need to display a single character, than instead of Disp "A" you can do Disp 'A'>Frac which saves some bytes.  But you'll most often use this when reading from a string and comparing the characters to another character.  Also, this makes it easy to store data using strings instead of hex since they are easier to read.  Entire maps can be made with a string since you can make statements now like If {Str1+X}='A'

Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 02:15:36 pm
Ouch I do hope you did not have crap going on like money issues or the like (no longer being able to afford internet) x.x, or parents cutting your access for any reasons... the later happened to me in 2007, because I spent too much time online. Ended up with barely any way to access Omnimaga for almost half a year.

Don't worry too much about it, though. One issue is that I got an hard time understanding stuff, even in my own language (french).

As for the ASCII/Hex constant, for example, I still can't find them in the doc. This pic is a proof (latest Axe version):

As for ascii I know the chars are assigned to an ASCII number, altough yeah I might use normal text instead since it would be very hard to write entire NPC conversations in ASCII, char by char, not to mention the source code would become insanely huge, limiting myself in memory x.x
Title: Re: Axe Parser
Post by: calc84maniac on March 16, 2010, 02:27:47 pm
Just search for "ASCII" and you should find it, I think
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 02:31:00 pm
This?

Quote
'CHAR'   The expression becomes the ASCII value of the single character between the apostrophes. It can even be another apostrophe.

Or maybe this?

Quote
Disp EXP▶Dec   The value of the expression is displayed at the current cursor position in base 10. The cursor is then advanced 5 spaces.
Disp EXP▶Frac   The ASCII character the expression represents is displayed at the current cursor position. The cursor is advanced. A new line is added if it hits the edge.
Title: Re: Axe Parser
Post by: Quigibo on March 16, 2010, 02:35:57 pm
'CHAR' is new.  So is EHEX.
Title: Re: Axe Parser
Post by: calc84maniac on March 16, 2010, 02:39:28 pm
This?

Quote
'CHAR'   The expression becomes the ASCII value of the single character between the apostrophes. It can even be another apostrophe.
Yep, that would be it. Like, if you read a byte, B, from a string you can check to see if it is "A" by doing:
Code: [Select]
If B='A'instead of the more cryptic
Code: [Select]
If B=65
This really helped the readability of my BrainF*** compiler
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 02:48:59 pm
Thanks

Not sure if I get how EHEX works, though. Does it converts a base 10 number to hexadecimal or vice-versa?
Title: Re: Axe Parser
Post by: Gale on March 16, 2010, 04:14:27 pm
okay, i know i must sound like a huge idiot for asking this, but how does axe work? for my calc at least, i just load up the app, select one of my programs and it give me an error. and the parsing doesn't seem to work for me. do i have to activate something?
Title: Re: Axe Parser
Post by: trevmeister66 on March 16, 2010, 04:20:58 pm
Well it you have to use the Axe specific syntax ONLY in your program. You can't have any BASIC Syntax whatsoever, so that could be the problem.
Title: Re: Axe Parser
Post by: Gale on March 16, 2010, 04:33:05 pm
ohhh. yeah, i thought it just automatically converted. so once i make it all axe syntax, i just run it through the application and then run it like a normal program? or do i have to run it with asm(    ?
Title: Re: Axe Parser
Post by: trevmeister66 on March 16, 2010, 04:34:10 pm
Yes once you convert it to Axe syntax, you run Axe App, and then you do Asm(prgmLOL
Title: Re: Axe Parser
Post by: Gale on March 16, 2010, 04:34:59 pm
okay thanks :)
Title: Re: Axe Parser
Post by: trevmeister66 on March 16, 2010, 04:44:45 pm
No problemo
Title: Re: Axe Parser
Post by: ztrumpet on March 16, 2010, 06:24:28 pm
Quigibo, can you show another example using the int( command?  I can't figure out how to use it, and I'd like to know how. :)

DJ, EHex just puts the hex number into Base 10.  Here are some examples:
E0001 = 1
E0009 = 9
E000F = 15
EFFFF = 65535
E001F = 31
All it does is convert from base 16 to base 10.  Does that make sense?
Note: Remember it must be 4 characters long after the E.  :)
Title: Re: Axe Parser
Post by: Quigibo on March 16, 2010, 06:37:02 pm
More generally, here is what int(x) does:

if 0<x<127, then
int(x)=x
if 128<x<255, then
int(x)=x-256

(those should be "less than or equal to" signs)
So it turns 255 into -1, 254 into -2, 253 into -3... but keeps positive bytes the same.
Title: Re: Axe Parser
Post by: ztrumpet on March 16, 2010, 08:46:28 pm
Hmm, I see.  Can you give an example when this would be useful?  I can't come up with anything, but I'm sure it's useful when used right. :)

On a side note, the documentation doesn't include the { and }.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 16, 2010, 11:55:13 pm
aaah I think I see now. I'll need to restudy these some more. Compiling them in one area (like the doc) will come very handy once Axe is out to public :)

Thanks for the help!
Title: Re: Axe Parser
Post by: Quigibo on March 17, 2010, 02:03:23 pm
The {} actually are in the doc in the middle, but I am getting the feeling that the doc is starting to get so large, that I really should divide it into categories like Math, Data, Constants, etc. to make individual commands easier to find.

int() is almost always used with {}, in fact, I might even change it to imply the brackets.  But right now, its like this:

say you have a data structure like this:
[-2,-1,0,1,2]
And you want to display 2 more than the number so your program looks like this:

-2->{L1}
-1->{L1+1}
0->{L1+2}
1->{L1+3}
2->{L1+4}
For(A,0,4)
Disp {L1+A}+2>Dec
End

Try it.  It doesn't return the right number since even though FF is -1 for an 8 bit number, it is actually 00FF as a 16 bit number.  That value is 255, not -1 as a 16 bit.  So we need to extend the sign.  In general, that means that 00xx has to become FFxx so our 00FF becomes FFFF which IS -1.  This is the low level explanation.  You don't need to know the technical details of HOW it works, just know that it preserves the sign when reading bytes in RAM.

Now try this:

-2->{L1}
-1->{L1+1}
0->{L1+2}
1->{L1+3}
2->{L1+4}
For(A,0,4)
Disp int({L1+A})+2>Dec
End

Tada!
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 17, 2010, 02:53:33 pm
aaah ok I see, I'll try more later :)
Title: Re: Axe Parser
Post by: ztrumpet on March 17, 2010, 04:44:29 pm
Ah, I see! Thanks! ;D

This could really help me with compression! :D
Title: Re: Axe Parser
Post by: SirCmpwn on March 17, 2010, 05:20:36 pm
-2->{L1}
-1->{L1+1}
0->{L1+2}
1->{L1+3}
2->{L1+4}
For(A,0,4)
Disp int({L1+A})+2>Dec
End

So does this method allow you to store large numbers in {L1+A} for example?  Because when I was playing around with it today it looked like my 16 bit numbers were being stored wrong.
Title: Re: Axe Parser
Post by: Quigibo on March 17, 2010, 09:35:55 pm
No, you only have 8 bits numbers in each location.  Using int() just allows those numbers to be between -128 and 127 instead of 0 to 255.  Anything outside those ranges will give inaccurate numbers.  More technically, it will instead be the number modulo 256, but I doubt you will ever need to exploit this detail.
Title: Re: Axe Parser
Post by: Quigibo on March 19, 2010, 08:13:09 pm
I've finished rewriting the commands list document.  It should be easier to understand and find commands.  Also, you can name programs now.  You'll see those Sunday probably.

On an unrelated note, I find it very funny that every time someone mentions a new project on these forums, everyone is immediately asking if it is/was/is going to be made using Axe Parser.  Now I realize that its a pretty neat toy at its current state, but realistically its not ready for the majority of applications yet.  There are still a lot of important features that I have been putting off like saving to files.  Not only that, but I don't feel that its as stable as it appears to be.  Major changes to the functions are coming soon.  I feel I should warn everyone ahead of time of some of these changes (not all in the next release):


I can foresee some other potential changes in the future.  I'd say my command set is probably about 30-40% complete right now so there are still TONS of commands I still have to add.  I do still go through the features list from time to time, so be patient if you don't see your request show up, I'll get to it eventually.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 19, 2010, 08:46:07 pm
Yes, I'm happy to finally see program naming ^^ no more need to abuse the MirageOS 1.1 ungroup glitch (see calc news and discussion)!

I think people probably just ask if it's gonna be in Axe because of what it can do alerady at the moment, and until this post, they probably were not aware that everything would change so much in later versions, especially that we got told a few times before that the changes in the syntax would be minor in overall. Most projects are also quite small, so they won't be that hard to modify for newer Axe versions (unless the entire format in which sprite data is stored will change). People probably just didn,t want to wait and probably either don't mind changes in future versions or were not aware they would be that drastic. Plus, projects that will be almost completly done before Axe is finished can be released, since they are compiled and doesn,t require the latest axe version to run, once compiled. I don't think it's funny that ppl asks if it's gonna be made with Axe. The language may not be finished but it can alerady do entire games, so that's an expected reaction you would not get with much other languages.
Title: Re: Axe Parser
Post by: ztrumpet on March 19, 2010, 09:00:43 pm
I'm okay with some loss of compatibility. :)

Oh, and DJ, I don't think he's trying to be narrow minded.  I think it's just a remark showing how much Axe is looked at to be such an major program that it is. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 19, 2010, 09:06:28 pm
Yeah Idk, just making sure that not too many ppl take it the wrong way. Maybe it could make some projects authors feel badmouthed and less motivated from working on their projects x.x
Title: Re: Axe Parser
Post by: Quigibo on March 20, 2010, 03:49:38 pm
Yeah, I mean that in a good way not a bad way.  I enjoy seeing the increased popularity of Axe Parser, but I was just pointing out that it seemed a little over-hyped as if it were already finished.  If its this popular already, I can't even imagine the results when its done ;)

By the way, those changes are not that major.  I don't think a single example program I've made so far would need to be modified at all.  Mainly it will affect people who already have complicated code.  I was just pointing out that there were going TO BE changes, even though they are small, since I had stated earlier that I thought there weren't going to be any.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 20, 2010, 11:18:48 pm
I definitively think it gets so much attention because it is what z80 BASIC programmers have been looking for years and like BBC Basic, your project was done the right way. Believe me, I've been browsing calc sites for years and saw so many alternatives to BASIC and ASM before. Regardless of what language it was (C, Java, hybrid, RPL or totally new ones like MLC), either their authors were too ambitious or the line at which they find something easy to learn was way too high (causing the new language to not even be easy to learn as it was advertised). The big plus is that within the first month you came out with a set of commands that allows people to make entire games. I mean, look at many of the sample programs released by members: all they need to add is title screens and the game is finished. Of course, in later versions people who are patient will be able to do even more, though, but what I mean is that your project may be at version 0.1.x, but it's alerady amazing now. I can,t wait for what new features it will have in next versions, though.

Glad to hear the changes will not be that huge, too.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 04:58:36 pm
SOUND!

EDIT: and nice to see text to buffer was finally added ^^

Lots of new functions added in this version, gonna check out. :)
Title: Re: Axe Parser
Post by: Quigibo on March 21, 2010, 05:03:05 pm
New update!  I can't believe I added so much, I guess most of it was simple.  Anyway, you can name your programs now and I think the most useful added feature is the double byte reading and writing.  So if you have a number larger than 255 you want to store, like a score for instance, you can store it to memory using S->{L1}r.  That means it writes the first part of the number to {L1} and the second part of the number to {L1+1} so the entire 2 byte number is saved.  Same goes for reading, you can read the entire byte.  Be careful though, because when you have arrays and things make sure you step by 2 instead of 1 since each number takes up 2 bytes.

Also, I reworded almost the entire commands list to make it less technical.  If you have a specific low level question about a command I can answer it here because I intentionally left out a lot of those details to make it as simple a definition as possible for those used to higher level languages.
Title: Re: Axe Parser
Post by: _player1537 on March 21, 2010, 05:06:28 pm
what does the documentation mean when it says "Calculator should exit in this mode if changed!"?  Does it mean that when the program is done it will continue to write small, or to the buffer, or inverse, or the normal ones?
Title: Re: Axe Parser
Post by: Quigibo on March 21, 2010, 05:12:10 pm
Yes it will.  It won't cause any crashes, and the calc will fix itself eventually once it needs to change the flags again, but its not a desirable effect.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 05:20:00 pm
Hey, about sound, I just tried in wabbitemu and it sounds very different from any other sound program I tried before. I don't know if this is exact, but it would sound more like triangle waves than square waves. Also, none other sound program I tried before could produce sound this acute. I kinda like it in some ways, plus I like the kind of effects some sounds causes. Had that first sound in the demo program been less acute, it could be used as earthquake sound

Now I guess next is the Axe rickroll
Title: Re: Axe Parser
Post by: trevmeister66 on March 21, 2010, 05:46:10 pm
Epic update. I'll definitely be trying some new programs out once I get back from work.
Title: Re: Axe Parser
Post by: Quigibo on March 21, 2010, 05:46:52 pm
Yeah, wabbitemu does sound a bit different than on the calc, I think the calc is a bit cleaner.  But mostly it heavily depends on what the time delay for the sound.  The longer the delay, the better the sound sounds.  Since the delay is in units of about 5-10 micro seconds, you should have pretty long delays.  On the other hand, you probably can make an earthquake sound if you lower the frequency (raise the wave value).

By the way, this routine is a near identical copy to what I used in Pyoro.  In Pyoro, each tone would have had 3000 as the "TIME" argument.  I'm sure someone here will make a routine that plays sound from a music file in ram.  You can get the notes for Pyoro in its music.inc source code.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 06:39:56 pm
oh it sounds different on wabbit? I guess maybe I should just try on calc if I can find my adapter then x.x

Title: Re: Axe Parser
Post by: ztrumpet on March 21, 2010, 06:45:38 pm
This is a really awesome update!  I can't wait to put this on my calc and try it! ;D

I really like the tone command! :D
Title: Re: Axe Parser
Post by: Eeems on March 21, 2010, 06:49:37 pm
The sound will go well with what I am working on :P
thanks for the update! can't wait to get it on my calc.
Title: Re: Axe Parser
Post by: Builderboy on March 21, 2010, 06:53:40 pm
Yesssss!  Loove the sound addition, can't wait to test it on calc, although it might take me a while to get my alligator clips out :D i don't have any adapter so i have to make one :P.  Love all the new commands, the 2 bit manipulation is especially awesome.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 06:55:58 pm
One thing I wonder and will have to test: For sounds that lasts for an extremly short while, would the quality still be tolerable? If so, I am curious if actual chords could be done (quickly alternating between 3 pitches)...
Title: Re: Axe Parser
Post by: SirCmpwn on March 21, 2010, 07:09:54 pm
++!
The 16 bit storage will make Half Life 2 so much easier.  Plus sound!  Ooo, now the title screen won't just look pretty for a couple seconds, now it will make that one sound that is played in Source games when the Valve logo is displayed.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 08:57:01 pm
yeah pretty interesting indeed and seems not too hard to use. It will be very useful in some games
Title: Re: Axe Parser
Post by: _player1537 on March 21, 2010, 10:11:49 pm
Can anyone help please?

I have this line of code:
Code: [Select]
For({Pic99+3},0,{Pic99+2}
This line compiles fine, but if I add an "End" later then the compiler gives me a "Block" error.  I was able to use Pic99 before this part, and it is 4 bytes long
Title: Re: Axe Parser
Post by: calc84maniac on March 21, 2010, 10:19:23 pm
Can anyone help please?

I have this line of code:
Code: [Select]
For({Pic99+3},0,{Pic99+2}
This line compiles fine, but if I add an "End" later then the compiler gives me a "Block" error.  I was able to use Pic99 before this part, and it is 4 bytes long
I think the first argument is required to be a variable, not a memory location.
Title: Re: Axe Parser
Post by: _player1537 on March 21, 2010, 10:20:27 pm
Thanks, I switched in a variable instead, and it worked.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 21, 2010, 10:26:52 pm
Yeah, I'm not really sure if pointers can work this way x.x
Title: Re: Axe Parser
Post by: Quigibo on March 22, 2010, 01:48:29 pm
You *could* use a memory location, but I don't support that right now.  I'm surprised that compiled, I should fix that so it gives an error.
Title: Re: Axe Parser
Post by: Gale on March 23, 2010, 04:56:17 pm
is this text command supposed to have text on the home screen rather than the graph screen?

Title: Re: Axe Parser
Post by: DJ Omnimaga on March 23, 2010, 08:46:22 pm
Question Quigibo:

Can Axe compiled programs run into problems if the executable code (minus the data) is over 8000 bytes?

Quote from: #omnimaga IRC channel
[20:32:26] <@calc84> DJ_Omni: I think the larger executable sizes is fine because it's still less than a 16KB app that has to be packaged with it :)
[20:33:13] * Tribal ([email protected]) has joined #omnimaga
[20:33:14] * Netbot45 sets mode: +o Tribal
[20:33:14] <@Netbot45> [Tribal] If you are near to the dark, I will tell you 'bout the sun...
[20:34:56] * Jarvis_ ([email protected]) has joined #omnimaga
[20:34:56] * Tribal sets mode: +v Jarvis_
[20:35:44] <@Tribal> !uptime
[20:35:44] <+Jarvis_> I have been awake for 1min 1sec
[20:35:49] <@Tribal> rrawr
[20:35:55] <@DJ_Omni> calc84 what are you replying to?
[20:36:11] <@DJ_Omni> !uptime
[20:36:11] <+Jarvis_> I have been awake for 1min 27secs
[20:36:16] <@DJ_Omni> oh
[20:36:47] <@calc84> just general discussion
[20:36:55] * @HAL ([email protected]) Quit (Ping timeout: 360 seconds)
[20:36:57] <@calc84> since we have talked about this before
[20:37:02] <@DJ_Omni> but idk what you are talking about calc84 x.x
[20:37:05] <@calc84> Axe
[20:37:09] <@DJ_Omni> could you give me the context?
[20:37:19] * HAL ([email protected]) has joined #omnimaga
[20:37:20] * Tribal sets mode: +v HAL
[20:37:27] <@DJ_Omni> the post in particular, preferably
[20:37:28] * Netbot45 sets mode: +o HAL
[20:37:41] <@calc84> like, you were talking about how big the compiled programs were compared to the source
[20:37:59] <@DJ_Omni> oh ok
[20:37:59] <@DJ_Omni> but
[20:38:09] <@DJ_Omni> what if a prog is larger than 24389 bytes
[20:38:19] <@DJ_Omni> how will ion/mirage unarchive it to run it
[20:38:35] <@DJ_Omni> axe cannot compile into flash app atm
[20:39:06] * @Jarvis ([email protected]) Quit (Ping timeout: 493 seconds)
[20:39:11] <@Netham45> The calc can't run anything bigger than 16384 bytes, iirc.
[20:39:15] <+Iambian> You mean, what happens if the executable portion is over number a little over 8000?
[20:39:29] <+Iambian> The execution boundary is at $C000
[20:39:36] <@calc84> hmm, true, Iambian
[20:39:40] <+Iambian> You start at $9D95
[20:39:46] <@DJ_Omni> i was talking about the program size
[20:39:48] <@DJ_Omni> i mean
[20:39:50] <@DJ_Omni> in ram
[20:39:52] <@DJ_Omni> before running
[20:39:59] <@calc84> so most of the program would be data if you have 24K size
[20:40:04] <@DJ_Omni> if you have a 8xp file that is 65536 bytes
[20:40:08] <@DJ_Omni> er
[20:40:10] <@DJ_Omni> 65535
[20:40:23] <+Iambian> The linker wouldn't accept it.
[20:40:23] <@Netham45> oh
[20:40:23] <@DJ_Omni> how do you run such program in ion?
[20:40:30] <@DJ_Omni> ion will not even be able to unarchive it
[20:40:31] <@Netham45> knowing the OS, it'd just do a RAM reset.
[20:40:43] <@DJ_Omni> ion must unarchive stuff before running it
[20:40:49] <@DJ_Omni> it wont run programs directly from archive
[20:40:53] <@calc84> and at some point, external appvars will be supported
[20:40:54] <+Iambian> I *have* sent a 65500 byte program before. The OS *will* accept it into FlashROM
[20:41:07] <@calc84> asm programs have this size problem too
[20:41:08] <@Netham45> Iambian, what happened when you unarchived it?
[20:41:16] <+Iambian> The OS *will* give the memory error.
[20:41:21] <+Iambian> If you try to unarchive it.
[20:41:22] <@DJ_Omni> maybe in the future, if axe produces a much larger than allowed program, it could simply split the data in another file?
[20:41:23] <@calc84> but it doesn't really happen for most games/programs
[20:41:32] <+Iambian> Still.
[20:41:49] <@DJ_Omni> also about the 8000 byte limit
[20:41:52] <+Iambian> Doesn't Axe refuse to generate programs that are above known limits? Isn't that something that every ASM programmer should know?
[20:41:58] <@DJ_Omni> does it means if my axe program compiled code ends up larger
[20:42:05] <@DJ_Omni> that my program will not run properly?
[20:42:11] <@DJ_Omni> i mean just the code, not the data
[20:42:16] <@calc84> if the code section is larger, correct
[20:42:20] <+Iambian> DJ_Omni: That truly depends on how Axe assembles that program.
[20:42:22] <@DJ_Omni> ouch x.x
[20:42:27] <@DJ_Omni> that might pose a problem
[20:42:35] <@Netham45> we could all just get 73's and use the hacked 83 OS on them
[20:42:37] <@DJ_Omni> maybe an asm expert should ask quigibo if he thought about that
[20:42:41] <+Iambian> If data is attached at the end of the program, then it'll be fine as long as the executable portion is below address $C000

This 8 KB executable limit is something that hasn't been discussed much in the TI community in the past 4 years, because most game programmers uses Flash APPs now, which aren't hit by this limit.
Title: Re: Axe Parser
Post by: Quigibo on March 23, 2010, 09:57:52 pm
I actually ran into this exact problem when I made Pyoro.  That's the main reason I turned it into an app.

However!  I am pretty sure that mirageOS and other shells CAN read files larger than 8kb, so you would just be forced to use a shell if you needed the extra room.  Another alternative is to split the program into multiple subprograms and then read them all with GetCalc() which is a command not implemented yet.

EDIT: and yes, data is attached to the end of the program.
Currently, the structure is this:

Header - Program And Subs - Data

But in the future, there will probably be a third pass for extra efficiency and the new order will be:

Header - Program - Subroutines - Data

Right now, no checks are done, but I wouldn't recommend making an 8000+ byte program until the parser is finished anyway.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 23, 2010, 10:00:56 pm
Yeah if I remember, Mirage had no issues with that 8 KB limit, altough I am not experienced in the ASM domain. I just heard it so many times on MaxCoderz old board around 2003-04, and heard it when MLC language was being worked on. I think sub-programs will help a lot, though. Did you check the code for Metroid II Evolution/Expansion? I think that out of the 130 KB of code, only like 15 KB is the game engine and another 16 KB for xLIB. The rest is just map data. For Illusiat 13 I think about 40% of the game size is also map data
Title: Re: Axe Parser
Post by: calc84maniac on March 23, 2010, 10:05:34 pm
The problem that DJ is talking about is the limit of executable code. Even when loading from shells or loading data from external programs, you are still limited to 8-9 KB of executable code.
Title: Re: Axe Parser
Post by: Quigibo on March 23, 2010, 10:20:32 pm
I'm just going to mention that if you have over 8kb of executable code, you should probably consider assembly and flash apps.  Even if I somehow got programs to compile to flash applications, you are still limited to 16kb of total data per page and anything above that involves page swapping which is an advanced procedure even for asm programmers.  Not only that, but it would be impossibly difficult to automate this within the parser.

As much as I would like programmers to be able to use Axe without needing to know assembly, there is a real hardware limit and past that point requires assembly knowledge.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 23, 2010, 10:26:23 pm
I hope the executable code limit won't hinder programming for axe too much x.x

But do you think dividing games in sub-programs could fix this?
Title: Re: Axe Parser
Post by: SirCmpwn on March 23, 2010, 10:27:52 pm
Maybe you could put the maps in a seperate variable than the main program, and keep them in the archive?
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 23, 2010, 10:31:11 pm
That's what I thought, and for NPC convos, have the text externally too, and call a subroutine to display that text. Same would go if your game is complex enough to have NPC movement patterns during events. They would have to be stored in lists, then ran through a subroutine for the char movement. If the 8 KB code limit doesn't include any data, I am fairly certain it would be easy to work around this limit. Dying Eyes is apparently unoptimized, yet it did it.
Title: Re: Axe Parser
Post by: ACagliano on March 25, 2010, 09:00:34 am
How do you use commands like Input and Prompt in Axe?
Title: Re: Axe Parser
Post by: Eeems on March 25, 2010, 09:14:26 am
Well someone has made an input routine, but currently there are no commands or input/prompt yet.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 25, 2010, 09:33:38 am
I guess maybe Quigibo could throw in TI input routine for this, since it isn't really something requiring speed.
Title: Re: Axe Parser
Post by: SirCmpwn on March 25, 2010, 09:34:44 am
That's actually a good idea!  I could make a small routine that does that at some point.
Title: Re: Axe Parser
Post by: _player1537 on March 26, 2010, 01:40:50 am
whenever you store something to a pic/str/gdb does it work in order, ie if you had "[00]-->Pic1 \ [11]-->Str1" would the end of the program be "0011" or "1100"?
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 28, 2010, 12:55:08 pm
Just so it is clear:

If the 8 KB code limit is ever an issue, will sub-program support allow for 8 KB of code per sub-program, or total?
Title: Re: Axe Parser
Post by: Gale on March 28, 2010, 01:02:56 pm
whenever you store something to a pic/str/gdb does it work in order, ie if you had "[00]-->Pic1 \ [11]-->Str1" would the end of the program be "0011" or "1100"?
it would be 0011
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 29, 2010, 02:06:27 pm
Btw how much space have you left in the app?
Title: Re: Axe Parser
Post by: Quigibo on March 29, 2010, 02:13:36 pm
The space an app can have in one page starts at $4000 and ends at $8000.  I am at $6075 right now.  So I just passed the halfway point recently.  That translates to 8309 bytes btw.  A lot of that code I'm not even using right now.  Its just sitting there until I write some code to use it.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 29, 2010, 02:20:27 pm
wow nice, smaller than I expected. This means there are big chances that the first public release will fit in one single page, right? But again, the title screen will take 768 bytes so just that will add a lot x.x
Title: Re: Axe Parser
Post by: Quigibo on March 29, 2010, 02:25:38 pm
Nah, I can always compress it.  I haven't even optimized my regular code yet either.  I have a feeling that the parser will be a one page app until maybe very close to the FINAL release.  If I do need to expand it beyond a page, I will include a bunch of helper programs, manuals, and demos in the extra space.  If not, the helper programs will be in a separate app.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 29, 2010, 02:30:20 pm
Oh if you can compress it more I guess it should be fine then ^^

I personally don't mind double-page apps, I was just surprised it was so small, still ^^
Title: Re: Axe Parser
Post by: trevmeister66 on March 29, 2010, 02:36:14 pm
Yeah I agree with DJ. App Size doesn't really bother me much since it's in Archive, but then again, if it manages to stay a 1 page App vs. a 2 page app, then I can have more games on my calc :)
Title: Re: Axe Parser
Post by: Galandros on March 29, 2010, 02:37:47 pm
For a compiler 8KBs seems really small.
Title: Re: Axe Parser
Post by: Raylin on March 29, 2010, 05:42:30 pm
Agreed.
Although I can't see why size is a problem...

DAWG is like... over 94000 bytes.

NO OVER 9000 JOKES.
D:<
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 29, 2010, 11:07:02 pm
Yeah same here. I think what people would not like is if the app was like 7 or 8 pages, though, because then they can barely hold any tools and game backups on their calc if they use a regular 83+, especially if they need MirageOs.

Keep in mind, though, that if the final app size is like 64 KB, it won't be that bad compared to if it was an interpreter. FastRPL and BBCBasic interpreters are like 4 pages each, I think, but the problem is that you need them to run games made with them. Since Axe is compiled, the player won't even need Axe Parser on his calc to play your game.
Title: Re: Axe Parser
Post by: ztrumpet on March 31, 2010, 08:33:07 pm
Wow, I had no idea Axe will be so small!  This is really cool!  My vote is for the 2 page App including the helper programs, but if the parser still fits in one page, then I'd make two versions, on with two Apps and one with two Pages.  Does this sound possible? ;D
Title: Re: Axe Parser
Post by: meishe91 on March 31, 2010, 09:15:16 pm
What exactly are pages?
Title: Re: Axe Parser
Post by: ztrumpet on March 31, 2010, 09:22:22 pm
A page is just over 16000 bytes, and Applications can only be in multiples of these pages.  That's why Apps are always in multiples of 16384 bytes. :D
Title: Re: Axe Parser
Post by: meishe91 on March 31, 2010, 09:36:42 pm
Oh ok, can you have an app less than 16384 bytes?
Title: Re: Axe Parser
Post by: _player1537 on March 31, 2010, 09:38:07 pm
no, you have to fill each app that takes up less than that with just zeros so that it equals 16384 bytes
Title: Re: Axe Parser
Post by: ztrumpet on March 31, 2010, 09:39:53 pm
no, you have to fill each app that takes up less than that with just zeros so that it equals 16384 bytes
Player is right. :)  Even if you only have 20 bytes of code in the App, it would still be 16384 bytes. ;D
Title: Re: Axe Parser
Post by: meishe91 on March 31, 2010, 09:51:41 pm
Well that sounds a little pointless...but ok :P I understand (Lame TI people for not making apps making user friendly and space efficient :P)
Title: Re: Axe Parser
Post by: cooliojazz on March 31, 2010, 10:48:02 pm
Hey, i need a bit of help, considering this is baffling me to the point my head exploding.
Code: [Select]
.MUSICAL
[0000000038444438     //These are all the different sprites.  They are actually on one line, i just
040404043C444438      //spread them out so you can see them
040404043C7C7C38
040605043C7C7C38
040605063D7C7C38
0000000000000000]→Pic1
4→{L1}            //Initializes stuff not really important to this part of the program.
2→{L1+1}        //Well, it was.  Then i deleted the part that used it in frustration
5→{L1+2}
2→{L1+3}
50→{L1+4}


DiagnosticOff                    //This is the happy little intro screen that works perfectly fine
Repeat getKey                  //It just displays random notes with a title.  I like it :)
For(X,0,11
For(Y,0,7
Pt-Off(X*8,Y*88*(rand/13107)+Pic1
End
End
DispGraph
Output(2,0,"Unreal Music"
Output(4,1,"Notator"
End


Lbl MN
ClrDraw
Pt-Off(0,0,Pic1         //This is a remanant I left for example.  No matter what i put, it will not draw any of the sprites
DispGraph                //(I have tried all the ones I defined above)  Nor will any of the other sprite routines work.
Output(0,1,"O"         //This is just to show, this still works.  So does the horizontal line drawing routine which used to be here...
While 1
0→K
Repeat K                //Yes, i know this is a lot of pointless code.  Remember that deleting i mentioned above? this is what remains
getKey→K
ReturnIf K=15
End
End
.....(There's more, but the rest doesnt matter)

So can any body tell me what i'm doing wrong, i f i'm doing anything wrong, cause i really dont think i am... :(
Title: Re: Axe Parser
Post by: _player1537 on March 31, 2010, 10:55:48 pm
would you mind posting the .8xp file?
Title: Re: Axe Parser
Post by: cooliojazz on March 31, 2010, 11:01:23 pm
Umm, sure...
Title: Re: Axe Parser
Post by: _player1537 on March 31, 2010, 11:06:36 pm
I get an incompatible type for that file...
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 31, 2010, 11:11:29 pm
cooliojazz did you create it from SourceCoder? I heard SC caused files to not be transferable sometimes
Title: Re: Axe Parser
Post by: cooliojazz on March 31, 2010, 11:13:35 pm
No, that was directly transfered from my calculator.  And the other one i manually typed up :P
Title: Re: Axe Parser
Post by: Eeems on March 31, 2010, 11:39:30 pm
Sounds like corruption x.x
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 12:55:22 am
mhmm idk then, it's weird x.x

You may want to try another linking software, else, maybe type the code from the post on the comp or something and save it in 8xp
Title: Re: Axe Parser
Post by: Builderboy on April 01, 2010, 01:02:29 am
Hmmm try putting a pause 200 after the DispGraph just to make sure the sprite isnt being erased real quick like
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 01:33:56 am
did you got it to work? If so could you upload the 8xp you have?
Title: Re: Axe Parser
Post by: Builderboy on April 01, 2010, 01:37:31 am
No i was just suggesting a possible way to fix the code, i didnt get it to work either :/
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 01:43:13 am
oh ok :(
Title: Re: Axe Parser
Post by: Quigibo on April 01, 2010, 03:49:25 am
You have a subroutine called "MN" but you never call to it from the main loop... that would explain why it doesn't do anything.
Title: Re: Axe Parser
Post by: cooliojazz on April 01, 2010, 01:37:28 pm
What main loop? It goes down there after it finishes the intro, no need to be called.  And it's there because future code would call that point.  But i didnt put in that code yet.  And builderboy, since it shows the text, and it would show a horizontal line routine i made as well, i really don't think it's erasing it. =p  And i don't know why you guys are getting errors, i can load it back on as well...  Maybe my OS got screwed up or something...
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 06:57:41 pm
you may want to try to open the file in TI-Graph LInk and then save. Just add a space in the prog, remove it then save, it may fix the file. I sometimes fixed progs this way before (I think for ERR:VERSION, for example)
Title: Re: Axe Parser
Post by: meishe91 on April 01, 2010, 09:36:31 pm
Well I downloaded it and put it on an emulator and ran it through Axe and got a "Bad Symbol" error. (It has happened at 29%, 36%, and 41% but I'm not sure how accurate that really is because it changes...) Is that that error you keep getting Coolio?
Title: Re: Axe Parser
Post by: cooliojazz on April 01, 2010, 10:11:54 pm
No, it compiles just fine.  It just doesnt run as suppossed to.  i put it all in the code as comments in the first post...
Also, this version i was actually able to open in an emulator. (the last i couldnt either)...
Title: Re: Axe Parser
Post by: meishe91 on April 01, 2010, 10:28:08 pm
Huh, that's really weird. I still get a "Bad Symbol" error when trying to compile in TilEm (for both files) and on WabbitEmu I get it for the second one (the first one makes it say there isn't enough Ram/Archive space)
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 10:28:50 pm
ok so I saw a friggin awesome title screen, but when I pressed ENTER, calc turned OFF then I got a RAM cleared :(

It did send fine to WabbitEmu, though
Title: Re: Axe Parser
Post by: meishe91 on April 01, 2010, 10:33:49 pm
Ya, same here. Awesome title screen with flashing music notes (some clipping issues) but then I got a RAM clear.
Title: Re: Axe Parser
Post by: cooliojazz on April 01, 2010, 10:40:28 pm
Yay, a fan of the title screen!  And basically, i uploaded it to source coder, verified it showed the right code then saved it.  It seemed to work.  Sadly not so much.  I tried compiling it and rerunning it using that version, and it just wouldnt go on on screen press... so i think my calculator is screwed up.  So, i think i'm going to try completely rewriting it on my sisters calc and see if i get the same set of errors that are popping up...
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 01, 2010, 10:45:16 pm
what OS do you use?
Title: Re: Axe Parser
Post by: meishe91 on April 01, 2010, 10:46:49 pm
A suggestion for the title screen. I would make the flags (I can't remember the correct terms; the things making the notes eighth and sixteenth notes) last longer or something because you can't really tell when they are on (mainly the sixteenth note one). But it really does look good so far :)
Title: Re: Axe Parser
Post by: cooliojazz on April 02, 2010, 12:05:30 am
Well, I retyped it all on another real calc, a virtual one, makes no  difference.  They all crash on that second Pt-Off statement, or ignore it in my calculators case.  Dj, mine and my sisters, the two real ones i tried it on, are both 5.23.  The virtual was 2.41.  So, i have ruled out a corrupted file for reason of failage, tho i do still think my calculator corrupts them...
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 02, 2010, 12:06:31 am
er the one i tried it on was 2.41 too. I did not try on real calc yet

could you type the entire source code again as it is now? Maybe quigibo could help if it's a program issue
Title: Re: Axe Parser
Post by: cooliojazz on April 02, 2010, 12:19:45 am
Code: [Select]
:.MUSICAL
:[0000000038444438040404043C444438040404043C7C7C38040605043C7C7C38040605063D7C7C380000000000000000]→Pic1
:
:
:DiagnosticOff
:ClrHome
:Repeat getKey
:For(X,0,11
:For(Y,0,7
:Pt-Off(X*8,Y*8,8*(rand/13107)+Pic1
:End
:End
:DispGraph
:Output(2,0,"Unreal Music
:Output(4,1,"Notator
:End
:
:
:Lbl MN
:ClrDraw
:Pt-Off(0,0,Pic1  if this is here, it crashes/doesnt work. otherwise life is good.
:DispGraph
:While 1
:
:ReturnIf getKey(15)
:End
:
:
:Lbl PS
:0→X
:While {L1+X}≠50
:For(A,0,{L1+X+1}
:{L1+X}→B
:SinRegB2/4+(B*14)+269,10000
:End
:X+2→X
:ReturnIf getKey(15)
:End
there ya go
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 02, 2010, 12:23:36 am
gah sourcecoder sure has trouble saving files x.x

It fails at sending to emu :/

EDIT: nvm forgot to name the prgm x.x

However yeah I still get a RAM clear so it's definitively the code :/
Title: Re: Axe Parser
Post by: Quigibo on April 02, 2010, 03:22:28 am
After further investigation, I think it has something to do with the parser and not the source.  I'm going to look into what the problem could be.  Its very weird that this has gone unnoticed until now.  It must be something really specific, probobly something wrong with one of the commands.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 02, 2010, 03:40:37 am
ouch, I hate when I have a project where old bugs pops up so late x.x. When I was working on Illusiat 13, everything worked fine, then when testing after it was 90% done, I found five new bugs in the story/mapping x.x

Good luck fixing it Quigibo!
Title: Re: Axe Parser
Post by: Galandros on April 02, 2010, 07:13:38 am
Sometimes a bug makes you no better option than rewrite some part of the code...

Good luck catching bugs.
Title: Re: Axe Parser
Post by: ztrumpet on April 02, 2010, 11:20:24 am
Good luck finding the bug(s)! :D
Title: Re: Axe Parser
Post by: Raylin on April 02, 2010, 11:33:08 am
I have sympathy for you, good sir.
I do indeed know your plight.

EDIT: I just dl'ed the update.
It is awesome.
Quigibo, you're almost there!

:D

You just need to throw in a way to name those appvars.
Then, you'll be on it!

First download of the update BTW.

EDIT 2: Oh geez.
I lied.

Never mind, Quigibo!
You're good to go!

:D

Nice update!
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 05, 2010, 02:19:22 pm
yeah you can name appvars actually. I don,t know how to access the data from them, though. It seemed quite complicated x.x

Nice to see an update, though. At least, we can finally save to external variables, meaning game progress and no password-save-system (Demon Crest style) hassle :D
Title: Re: Axe Parser
Post by: _player1537 on April 05, 2010, 02:22:35 pm
if you use the appvars for saving, it might be best to encrypt them somehow, as I have heard its quite easy to hack into mario 2.0's appvar to give you extra stuff or something like that.  especcially if you are doing something where one byte (or two) are the items/level/whatever
Title: Re: Axe Parser
Post by: Quigibo on April 05, 2010, 02:42:13 pm
I might be able to write an encryption algorithum eventually.  I'll explain in detail later how to use the new features in the program, I was just too tierd last night.

Just beware the new commands are kind of vulnerable to change since I'm not sure exactly how I'll generalize them to other variables in the future.
Title: Re: Axe Parser
Post by: calc84maniac on April 05, 2010, 02:43:45 pm
if you use the appvars for saving, it might be best to encrypt them somehow, as I have heard its quite easy to hack into mario 2.0's appvar to give you extra stuff or something like that.  especcially if you are doing something where one byte (or two) are the items/level/whatever
Errm, I didn't think Mario 2.0 had an appvar...
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 05, 2010, 02:43:49 pm
Quote
Just beware the new commands are kind of vulnerable to change since I'm not sure exactly how I'll generalize them to other variables in the future.
Aaah, I'm noting this. Will the change be very drastic? Again, in my case, I doubt it would be much hassle to change, because generally, I only use such type of commands in two place in my program (I never really have auto-saving features in my games)
Title: Re: Axe Parser
Post by: _player1537 on April 05, 2010, 02:48:53 pm
if you use the appvars for saving, it might be best to encrypt them somehow, as I have heard its quite easy to hack into mario 2.0's appvar to give you extra stuff or something like that.  especcially if you are doing something where one byte (or two) are the items/level/whatever
Errm, I didn't think Mario 2.0 had an appvar...
eh, It was some game like mario that used an appvar and people could easily hack it
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 05, 2010, 03:00:12 pm
I don,t know which one you mean Player x.x

The Sam Heald mario doesn,t use an APPvar, it saves directly to the program, if any data has to be saved. Maybe it was a different game? I remember hearing about a game being easy to hack, though, and I wouldn't be surprised with Celtic III APPVAR support and CalcSys around
Title: Re: Axe Parser
Post by: Madskillz on April 05, 2010, 03:05:20 pm
I have seen a few hacks with the appvar stuff. I have yet to try this but I really do wanna see how far Quigibo has come. I've been impressed with the progress thus far.
Title: Re: Axe Parser
Post by: meishe91 on April 05, 2010, 11:36:53 pm
Just thought I'd let everyone know, Coolio's title screen does work now!
Title: Re: Axe Parser
Post by: Raylin on April 05, 2010, 11:40:54 pm
Say again?
Explain.
Title: Re: Axe Parser
Post by: meishe91 on April 05, 2010, 11:46:30 pm
What I said or something previous?
Title: Re: Axe Parser
Post by: cooliojazz on April 05, 2010, 11:47:14 pm
Yay! I havent gotten to test it yet :P
Title: Re: Axe Parser
Post by: meishe91 on April 05, 2010, 11:48:32 pm
Ya, it leaves a little thing on the homescreen after a key press but you can just clear it.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 05, 2010, 11:49:05 pm
Say again?
Explain.
he was testing cooliojazz music program, which previously crashed on his calc or emu, and now it works fine
Title: Re: Axe Parser
Post by: indubitably on April 07, 2010, 07:15:59 pm
what does it mean when you get a bad symbol error message?
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 07, 2010, 07:38:19 pm
In most cases, bad symbol means that you used an invalid character or token  in your program.

I'm going to post a new suggestion in the other thread.
Title: Re: Axe Parser
Post by: Quigibo on April 07, 2010, 08:46:33 pm
That's the most common error.  It usually means that you either used an unsupported command/symbol or you used the wrong type of data like using a number when a variable is expected or having a closed parenthesis without an open one.
Title: Re: Axe Parser
Post by: indubitably on April 07, 2010, 11:20:26 pm
I am a little bit confused about modifying existing code to work with axe. I read the included documentation and I didn't see anything about why the values that are stored to the variables are very, well... different.
Title: Re: Axe Parser
Post by: Quigibo on April 08, 2010, 01:39:02 am
I know, I haven't actually made a real tutorial for it yet.  I don't think I will either until its finished.  I might make a mini one when the beta comes out, but other than that, these threads are the only resource for those types of general information.

Speaking of which, whats with all the sudden influx of posts?  Just a few days ago there were only a handful of posts per day in this subforum, and now entire threads get filled up in a matter of hours.  There's got to have been over 100 new posts here just from today alone...
Title: Re: Axe Parser
Post by: meishe91 on April 08, 2010, 01:44:00 am
It's just because we are so awesome like that, that we just can keep discussions going all day :P Nah, really its more from people like you and the creators of Ndless and the like that are attracting people over here. :) (Axe Parser was one of the main reasons I joined at first ;D)
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 08, 2010, 02:22:18 am
I know, I haven't actually made a real tutorial for it yet.  I don't think I will either until its finished.  I might make a mini one when the beta comes out, but other than that, these threads are the only resource for those types of general information.

Speaking of which, whats with all the sudden influx of posts?  Just a few days ago there were only a handful of posts per day in this subforum, and now entire threads get filled up in a matter of hours.  There's got to have been over 100 new posts here just from today alone...
Lol yeah, I noticed a suddent increase in activity there. However the entire Omnimaga forum has been going this way for over a month now. We have hit records in March. I think the IRC post notifier bot helps a lot now, though, because IRC chat users now frequent the board more often.

Yesterday alone was 300+ posts. Sometimes I checked a topic where a new member asked a question, then an hour later it was alerady on page 2 x.x
Title: Re: Axe Parser
Post by: meishe91 on April 08, 2010, 03:03:24 am
Ya, just from when I joined I have seen huge increases in activity (and that was about a month ago that I joined, I believe). It's pretty insane.
Long live Omnimaga! :p
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 08, 2010, 03:05:44 am
Activity really skyrocketed starting in November. October was kinda dead, even UTI had more activity than us, but near the end of that month, I kinda noticed activity wanted to rise, so I had some hope, and then it kept increasing every month. Now let's keep Omni strong ^^
Title: Re: Axe Parser
Post by: Quigibo on April 08, 2010, 04:56:56 pm
Just wanted to give a heads up:

There is a 100% chance that the file management commands will be changing big time.  The main reason is that I've found a way to better generalize the commands (you can now save and edit programs as well as appvars) and also, the current commands use a lot of extra memory for something that really can be done by the programmer instead.  I don't think the difficulty of using the commands will change by much, but I have a feeling it will make more sense.

So moral of the story is; wait until next version to use these.  I'll probably release it tonight or tomorrow because I did a lot of bug fixes recently.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 08, 2010, 05:07:45 pm
nice to hear ^^

I will probably wait a bit more since there was still a bug reported by Cooliojazz or Buildeboy a short while ago IIRC and I am still thinking about ideas on what to make at the moment, as well as debatting if I should use compressed tilemaps or not.
Title: Re: Axe Parser
Post by: meishe91 on April 08, 2010, 05:07:57 pm
Thanks for the update! :)
Title: Re: Axe Parser
Post by: Quigibo on April 11, 2010, 05:09:03 am
New update.

I explain the new file system a bit in the general help file.  But anyway, you have to prefix your names when saving to files from now on.  So if you want to save to an appvar with the name "MONKEY" you have to store the string as "vMONKEY"->Str1.  That 'v' is the prefix for appvars and is not the lowercase 'v', its the one on the [2nd][8] button.  To access programs, you prefix with prgm.  So "prgmMONKEY" will read and write to the program called monkey.  However, you can not create new programs currently.

Another new thing that might need explanation is the new grayscale command.  I haven't added any grayscale drawing commands yet, but I think it can still be useful.  Basically, whatever is drawn on the back buffer will appear gray wherever the front buffer is white.  So it effectively gives you a background layer.  Keep in mind you have to update the display an odd number of times each frame (3 is fine spread out around the code) and you have to make sure sprites update their positions an even number of of draw cycles apart (every other cycle is perfect).  Otherwise they leave a checkered blur.
Title: Re: Axe Parser
Post by: Silver Shadow on April 11, 2010, 09:54:36 am
Another new thing that might need explanation is the new grayscale command.  I haven't added any grayscale drawing commands yet, but I think it can still be useful.  Basically, whatever is drawn on the back buffer will appear gray wherever the front buffer is white.  So it effectively gives you a background layer.  Keep in mind you have to update the display an odd number of times each frame (3 is fine spread out around the code) and you have to make sure sprites update their positions an even number of of draw cycles apart (every other cycle is perfect).  Otherwise they leave a checkered blur.
What do you mean exactly by "draw cycles"?
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 10:54:07 am
I think he means how many times you call the command in the program.
Title: Re: Axe Parser
Post by: indubitably on April 11, 2010, 11:37:25 am
I feel like an idiot, somehow, when I first downloaded axe, I left out the documentation file and I have had the most trouble using axe. I just downloaded the update, read the file, and wow that helps sooooooooooooo much.
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 11:43:50 am
Eh.
Noobish mistake.
:P
It happens.
Title: Re: Axe Parser
Post by: ACagliano on April 11, 2010, 11:54:36 am
Eh.
Noobish mistake.
:P
It happens.

He's right. You will learn eventually never to download anything without documentation.
Title: Re: Axe Parser
Post by: indubitably on April 11, 2010, 12:49:29 pm
yeah I thought the all the documentation everybody was talking about was the optimizing tips and the general help.
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 12:53:45 pm
Naw.
It's the HTML file that is included in the update.

:P
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 11, 2010, 01:23:30 pm
Eh.
Noobish mistake.
:P
It happens.

He's right. You will learn eventually never to download anything without documentation.
The sad part though is that in some cases, when you download something, there's no doc provided or the doc is separate from the binaries x.x

Oh well, that happens ^^

And glad to see new update! I migth give the grayscale commands a try at one point. The way I see it it works like Reuben Quest but using overwrite logic instead of XOR, right?

About the program file access, does this means there's now a way to use the data from programs, such as external levels and map data? Can the data be retrieved directly from archive without unarchiving the program first? If it's possible to retrieve data from external programs, could someone post a routine on how to run sub programs?

Also it might be a good idea to include the stuff explained in http://ourl.ca/4050/84944 in the doc, because in the doc, there's no indication about v and prgm prefixes and the grayscale command isn't explained into as much details.
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 02:42:11 pm
QUESTION: What can you do with the accessing of programs in Axe?
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 11, 2010, 02:53:07 pm
What I thought about is accessing archived data like tilemaps or NPC convos (text) from our main program, so basically, we can have games that takes more than 24 KB of memory by taking advantage of the Flash ROM.
Title: Re: Axe Parser
Post by: calc84maniac on April 11, 2010, 03:58:57 pm
hmm, I doubt reading from flash is supported
Title: Re: Axe Parser
Post by: Quigibo on April 11, 2010, 04:03:44 pm
While you can run executable code from another program, its way too dangerous, so I'm not going to support it right now.  But you can with assembly commands.  Anyway, the main usage is for reading and writing to programs.  Like if you made a new program with HELLO as the first line, you can read that just like you read an appvar, and also write over and modify it.  The advantage is that appvars are not easily editable.  So if you want to make an external level pack come with your game, you might want to consider using a program instead so levels can easily be edited.
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 06:30:46 pm
I keep failing at this...

Okay, so I have:

Code: (prgmA) [Select]
:"RAWR
Code: (prgmB) [Select]
:"prgmA"->Str1
:Disp {Str1}>Frac

Why is this not working?
Title: Re: Axe Parser
Post by: Builderboy on April 11, 2010, 06:35:06 pm
Methinks because strings in Basic programs are not the same as strings in compiled axe programs?  Not sure...
Title: Re: Axe Parser
Post by: ACagliano on April 11, 2010, 06:35:09 pm
You can't display a program. You have to select it, then read the bytes of that line from it, then display THAT.

Am I right?
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 06:44:49 pm
If this is true, how would you read and write data from programs in Axe?
Title: Re: Axe Parser
Post by: SirCmpwn on April 11, 2010, 07:06:46 pm
Code: (prgmA) [Select]
:"RAWR
Code: (prgmB) [Select]
:"prgmA"->Str1
:Disp {Str1}>Frac
Why is this not working?

Take off the {}, its implied.  Also, remove >Frac, unless you just want the first character.
Also, I'm not entirely sure if the prgm token will show right, you may need to spell out p-r-g-m

QUESTION: What can you do with the accessing of programs in Axe?
/me pokes calc84maniac to re-make OTBP Assembler with Axe

If this is true, how would you read and write data from programs in Axe?

You read the data, store it somewhere.  You take the data from where it is stored, and write it.
Title: Re: Axe Parser
Post by: meishe91 on April 11, 2010, 07:29:14 pm
So, I'm assuming that the point of prgmA and prgmB is to display "RAWR" when prgmB is run through Axe Parser while writing this.

So I tried what SirCmpwn said and these are the results I got:

Code: [Select]
PROGRAM:A
"RAWR

PROGRAM:B
"prgma"→Str1
Disp Str1

Output:
►A__________Done

PROGRAM:C
"prgmA"→Str1 //"prgm" is typed out.
Disp Str1

Output:
prgmA_______Done

prgmB and prgmC were the programs run through Axe Parser.
Title: Re: Axe Parser
Post by: Raylin on April 11, 2010, 07:33:28 pm
None of that worked, SirCmpwn. :(

Remember, I am trying to make the calc display RAWR.

EDIT: ninja'd.
Title: Re: Axe Parser
Post by: Quigibo on April 11, 2010, 07:53:10 pm
Its exactly the same as appvars.  It would have to be like this:

Code: [Select]
Prgm A:
:RAWR  <--No quotes here, we're reading raw data.

PrgmAXE:
:"prgmA"->Str1
:GetCalc(Str1)->P
:For(A,0,3)
:Disp {P+A}>Frac
:End

Since the string isn't zero terminated you can't just display it like a regular string. (or maybe it is at the end of the program, I dunno)
Title: Re: Axe Parser
Post by: meishe91 on April 11, 2010, 08:04:55 pm
Yup, that works. Makes a lot of sense too. Thanks, Quigibo. I knew you had to have GetCalc( somewhere but wasn't sure how to use it.

@Quigibo
I was looking at prgmCOUNTER and was trying to retype it in by hand (for practice and such) and wasn't able to make it work because the "v" you store in Str1 at the beginning of the string was a different one. Where is that token found or is it something else that is going wrong?
Anyone can answer this, just wasn't sure what was going on and it's his example.
Title: Re: Axe Parser
Post by: ACagliano on April 11, 2010, 08:38:41 pm
Can Axe read from a program that is locked?
Title: Re: Axe Parser
Post by: meishe91 on April 11, 2010, 09:20:16 pm
Just tried it and yes it does.
Title: Re: Axe Parser
Post by: Quigibo on April 11, 2010, 10:53:02 pm
@Quigibo
I was looking at prgmCOUNTER and was trying to retype it in by hand (for practice and such) and wasn't able to make it work because the "v" you store in Str1 at the beginning of the string was a different one. Where is that token found or is it something else that is going wrong?
Anyone can answer this, just wasn't sure what was going on and it's his example.

I shall quote myself.
Quote
That 'v' is the prefix for appvars and is not the lowercase 'v', its the one on the [2nd][8] button.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 11, 2010, 11:01:28 pm
While you can run executable code from another program, its way too dangerous, so I'm not going to support it right now.  But you can with assembly commands.  Anyway, the main usage is for reading and writing to programs.  Like if you made a new program with HELLO as the first line, you can read that just like you read an appvar, and also write over and modify it.  The advantage is that appvars are not easily editable.  So if you want to make an external level pack come with your game, you might want to consider using a program instead so levels can easily be edited.
Oh, personally I am not certain if I would want to do this, especially if I can use internal sub-routines. What I thought about is reading external data like tilemaps and the like. See for example Metroid II: Evolution. The BASIC code is about 15 KB large, there's xLIB, that is 16 KB large, but tilemap data, stored into a list of sub-programs named prgmM40 through M60 or something like that, are a whooping total of 85 KB.

This is what I was wondering, if you could read external data like this with those routines, and I was wondering if the external program could be archived and be read without getting unarchived (or even copied to RAM)
Title: Re: Axe Parser
Post by: meishe91 on April 11, 2010, 11:06:26 pm
Where did you say that? And thanks, I completely forgot about that key. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 11, 2010, 11:29:59 pm
Where did you say that? And thanks, I completely forgot about that key. :)
In reply to Quigibo post?
Title: Re: Axe Parser
Post by: meishe91 on April 11, 2010, 11:36:04 pm
Ya, my bad. I was wondering where he was quoting from.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 12, 2010, 12:01:33 am
http://ourl.ca/4050/84944

I generally use CTRL+F in Opera, but in some cases, that can fail, especially if the original post was on multiple lines or not copy-pasted
Title: Re: Axe Parser
Post by: meishe91 on April 12, 2010, 12:15:24 am
Oh ok, I never saw that post. My bad. Thanks, DJ.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 12, 2010, 12:18:29 am
No problem :D
Title: Re: Axe Parser
Post by: Quigibo on April 13, 2010, 07:46:16 pm
Anyone know where I can get a list of shell calls with at least some I/O description?  I'm currently planning on supporting Ion, Mirage OS, and Doors CS6 since they seem to be most popular, but let me know if there are others that I should include.  And an update on the project:  The menus look really cool. :)  Thanks again Builderboy for the Logo.  I didn't end up using the whole thing, just the picture of the Axe, but it looks great.
Title: Re: Axe Parser
Post by: meishe91 on April 13, 2010, 07:50:28 pm
I thought that Ion got obsoleted by something else coming out? (DCS6?) I just thought I read that somewhere.
Title: Re: Axe Parser
Post by: Will_W on April 13, 2010, 07:52:14 pm
Ion is still the most common platform because all of the other modern shells will run it.
And for the APIs of the shells, look on ticalc.  Each shell comes with an inc file that should list the calls and their inputs and outputs.
Title: Re: Axe Parser
Post by: Raylin on April 13, 2010, 07:53:41 pm
So, ION > MirageOS?

0_o
Title: Re: Axe Parser
Post by: Quigibo on April 13, 2010, 07:56:02 pm
Well unless I downloaded the wrong file, MOS didn't come with any descriptions in the .inc file, just a list.  And the Ion App didn't come with anything.

Its okay though, I just found out that the DCS website has a description of calls from all 3 shells so I think I can use that.

Ion isn't necessarily better than any shell, its just more compatible.
Title: Re: Axe Parser
Post by: meishe91 on April 13, 2010, 07:58:06 pm
Hmmm, ok. Thanks for the info.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 13, 2010, 07:59:09 pm
True, I had to use it to run TCOL and some other games that would crash in Mirage. Also, it's small, so people who don't want to waste 16384 bytes of archive can just use Ion. It takes out a lot of RAM, tho.

Another advantage of Ion is that there's also a regular 83 (non plus) version, making it easier to port games.
Title: Re: Axe Parser
Post by: Will_W on April 13, 2010, 08:01:12 pm
The only reason to use Mirage over Ion is for the icon and for the extra saferam available only to the 83+.  Ion can use that to on the 83+, but if you use it, you've already broken compatibility, so what's the point?  For running progs, I use MirageOS and CrunchyOS.  When an archived program crashes Crunchy, that program doesn't become corrupted; problem with it is that it's not fully compatible with MOS progs.
Title: Re: Axe Parser
Post by: Raylin on April 13, 2010, 08:10:53 pm
Wait a minute.

Is ION an APP or a program?
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 13, 2010, 08:23:10 pm
No Ion is a 8xp program, like Ashell and Venus. Venus is the Noshell of the regular 83, except unlike Noshell, it's a regular program instead of an app.

What I dislike about Ion is that when you run the installer, you lose about 1600 bytes of RAM until next RAM clear. Sure you can delete the installer afterward but you still have about 22 KB of free RAM instead of 24
Title: Re: Axe Parser
Post by: Quigibo on April 13, 2010, 08:48:29 pm
By the way, another thing I should mention.  I've been thinking about making headers mandatory.  So you will need a header for your program to be compiled and to show up on the program list, clearing up some of the clutter.  The header is simply a comment as your first line of code with the name of the output file.  If you want a description for the shells, then everything after the name in that comment becomes the description.

Good idea or bad idea for mandatory headers?
Title: Re: Axe Parser
Post by: Will_W on April 13, 2010, 08:50:02 pm
an Ion app exists.
Title: Re: Axe Parser
Post by: Raylin on April 13, 2010, 08:53:29 pm
@Quigibo:

I'm all for it.
It would be nice to have mandatory headers to populate the program list.

What are you thinking?
A period in the first line makes it available?
Then, everything after that is custom program name?
Title: Re: Axe Parser
Post by: Will_W on April 13, 2010, 08:55:37 pm
I'd say no to manditory headers.  Maybe use the header system shells use to identify which BASIC progs to run.
the ::"String
Title: Re: Axe Parser
Post by: calc84maniac on April 13, 2010, 08:58:13 pm
I'd say no to manditory headers.  Maybe use the header system shells use to identify which BASIC progs to run.
the ::"String
I don't understand... wouldn't this make all Mirage basic programs show up in the list?
Title: Re: Axe Parser
Post by: Quigibo on April 13, 2010, 09:00:08 pm
Not just a period.  Because then BASIC programs that start with a decimal number get counted.  It has to be a period followed by a letter.  Which is great since program names have to start with letters anyway.  Here is a sample for a header with a shell:

PrgmAXESNAKE
:.SNAKE Slither around and eat the dots!
:<code goes here>

The space between the name and the description is how it tells one apart from the other.
Title: Re: Axe Parser
Post by: Builderboy on April 13, 2010, 09:01:14 pm
I am for mandatory headers for people with many programs in your program menu, it would be a way to sort through them and have a cleaner list.  And i am against using the traditional :String header because then regular Basic MirageOS will show up in the Axe menu, and it could confuse some users.

EDIT: Ninja'd by Will_W with a good point :)

EDIT2: Ninja'd by Quigibo ;D

EDIT3:
Thanks again Builderboy for the Logo.  I didn't end up using the whole thing, just the picture of the Axe, but it looks great.

Thanks ^^
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 13, 2010, 09:13:01 pm
Mandatory header would be a good idea.

an Ion app exists.
Really? URL to it?
Title: Re: Axe Parser
Post by: indubitably on April 13, 2010, 10:34:13 pm
how do I type "->pic1" into the calc?
Title: Re: Axe Parser
Post by: calc84maniac on April 13, 2010, 10:37:05 pm
Use the VARS button to access the Pic, GDB, and Str tokens
Title: Re: Axe Parser
Post by: indubitably on April 13, 2010, 10:38:43 pm
Why are those not in the catalog? :-X lol
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 13, 2010, 10:42:47 pm
I think the catalog was meant to include commands, not var names
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 16, 2010, 06:12:37 pm
Mhmm I've been messing around with L6 a bit. I wanted to figure out how to store data directly to the graph buffer instead of going through the other commands. However I can't really figure out what I am doing wrong that cause nothing to be changed. Here's my code:

Code: [Select]
.OMNOM
[00FFFF77FFFF8BFFFF91000000DFFFABF81F8B00C36E0000->Pic1
Pic1->{L6}
DispGraph
Title: Re: Axe Parser
Post by: calc84maniac on April 16, 2010, 06:18:10 pm
Mhmm I've been messing around with L6 a bit. I wanted to figure out how to store data directly to the graph buffer instead of going through the other commands. However I can't really figure out what I am doing wrong that cause nothing to be changed. Here's my code:

Code: [Select]
.OMNOM
[00FFFF77FFFF8BFFFF91000000DFFFABF81F8B00C36E0000->Pic1
Pic1->{L6}
DispGraph
Oh, you're going to need to use the copy command. Since you have 24 bytes there, you should do conj(Pic1,L6,24)
Title: Re: Axe Parser
Post by: Builderboy on April 16, 2010, 06:19:49 pm
Whoops, your storing the pointer to {L6}, not the data itself.  The command you are probably looking for is conj() which will copy data from one pointer to another.

Conj(Pic1,L6,24)

EDIT: ninja'ed :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 16, 2010, 06:22:58 pm
oh ok x.x

I tried doing DATA->{L6} directly but that gave an ERR: BAD SYMBOL error anyway

As for your command it doesn't work, I now have:

Code: [Select]
.OMNOM
[00FFFF77FFFF8BFFFF91000000DFFFABF81F8B00C36E0000->Pic1
Conj(Pic1,L6,24)
DispGraph
Title: Re: Axe Parser
Post by: Builderboy on April 16, 2010, 06:24:54 pm
What doesn't work?  What goes wrong?  For that matter what is it that you are trying to accomplish? o.O
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 16, 2010, 06:41:26 pm
I just picked random lines from a picture file converted to hex, just for testing. What's supposed to be displayed is that junk (just for testing purposes). However, nothing appears to show up.

I'll do a screenshot I think.

EDIT: Weird nvm. The first prog I made must have screwed up RAM stuff. A simple RAM clear, then retrying again solved the issue. I did not exactly check the data, but now it appears to show something I desire. I'll try later with plain FFFFFF stuff for example, later, to see, in case.

Screenshot attached:
Title: Re: Axe Parser
Post by: SirCmpwn on April 16, 2010, 07:41:41 pm
That screenshot looks right.  You need to have 748 (double check this number) bytes to fill up the screen.
Title: Re: Axe Parser
Post by: Builderboy on April 16, 2010, 07:44:42 pm
Its 768, since the screen is 96 pixels wide and 64 pixels tall = 6144 pixels, but then divide by 8 to get bytes = 768
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 16, 2010, 07:46:40 pm
yeah that's what I thought. Initially my program pretty much included an entire spritesheet. Then I got rid of many data cuz the code to post on forums was a bit long x.x
Title: Re: Axe Parser
Post by: Builderboy on April 17, 2010, 01:16:13 am
Hey I was wondering, if you are usig memory locations as variables, is it any faster to say A than {L1+12}?  Because I have already run out of variables in Portal and I have had to seep into memory locations.
Title: Re: Axe Parser
Post by: Quigibo on April 17, 2010, 03:08:04 am
No.  In fact the variables A-Z really are memory locations located between {L1-52} and {L1-2} or something like that I think.  It just does all the behind the scenes work for you when you use the letters.

However, even though they should be as fast, they won't be just becasue I haven't done the hardcore precompile optimizations yet and probably won't for a long time.  I doubt you'll notice the difference though, it just means that when you do {L1+12} like you say, it adds the 12 during execution.  Arithmetic is super fast though, so don't worry about it.

By the way, I'm thinking of adding a new unsigned division routine for division of constants less than 256.  It would be almost twice as fast and twice as small as regular division.  The drawback is that now you'll be calling 2 separate subroutines for long division (division by variables and constants greater than 256) and short division (by constants less than 256).   If you have to use both in the same program, we're only talking about 15 extra bytes total so its worth it in my opinion.
Title: Re: Axe Parser
Post by: Raylin on April 17, 2010, 08:10:34 am
^++
Agreed and seconded.

Also, are you going to fix the DispGraph(r) command in this update?
I'd like to use it.

:D
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 17, 2010, 12:16:47 pm
That would be nice Quigibo. ^^
Title: Re: Axe Parser
Post by: Quigibo on April 17, 2010, 12:28:05 pm
I've already fixed the DispGraph command.  But I might have to fix it more.  It looks fine in 6MHz mode, but its pretty grainy in 15MHz mode.  If I change the pause times, the opposite happens...  I might have to make it adjust dynamically so both cases look good.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 17, 2010, 01:03:51 pm
i think it might be best to have it so it is based on the calc model the game runs on. In future versions of Axe, Maybe also allow a command for use in Axe programs option menus so the user can manually alter the delays between grayscale updates, since not all calcs have the same grayscale quality at the same levels. Even two 83+ calcs could have different quality between each others.
Title: Re: Axe Parser
Post by: jsj795 on April 17, 2010, 01:53:57 pm
Even two 83+ calcs could have different quality between each others.
Is it because of difference in hardware? Did TI change the hardware during the production of TI83+ just like what they did with the extra ram page in TI84+SE? Anyways, good luck on fixing the greyscale, Quigibo!
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 17, 2010, 02:03:55 pm
I think it's more the LCD. Sometimes, a LCD may not exactly be the same speed as another, for productions reason. Same for the calc processor. Some 84 calcs reports speed of 15.1 MHz instead of 15, for instance. It's like when you buy two identical watches. One may go at a slightly different speed
Title: Re: Axe Parser
Post by: Quigibo on April 17, 2010, 02:26:44 pm
I think the hardware is pretty reliable for the most part.  It's mainly the delay routine I'm using should delay a different amount of time if the calc is in each speed setting.  Currently it does an empty loop until the LCD driver is ready and then it writes the pixel.  I'll figure it out though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 17, 2010, 02:28:55 pm
Aaah ok. I wonder if automatic grayscale commands will slow down program execution a lot? I don't think grayscale quality needs to be perfect, though. As long as it wont flickers horribly.
Title: Re: Axe Parser
Post by: Quigibo on April 17, 2010, 02:38:20 pm
You're talking to a perfectionist here :)  But not necessarily next release, I can always tweak it more later, as long as the final version is perfect gray.

Also, I forgot to mention, the only routines I was able to outsource to the shells so far were all the pixel routines.  They certainly cut down on the program size!  But unfortunately, the shell calls are slower becasue they are not as optimized as the routines I'm using.  Its a small difference, but definitely noticeable in the Game of Life  program.  There's nothing I can do about that though...
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 17, 2010, 02:42:52 pm
Will there be the option to not outsource to specific shell routines in later versions? Or will creating a program for Mirage for example automatically make it use that shell's routines?
Title: Re: Axe Parser
Post by: Quigibo on April 18, 2010, 02:41:50 am
Hmm... I don't know.  Is that an option you would like?  I think generally, you won't notice the slowdowns unless you use the same routine over and over for practically the entire program (Like my Game Of Life example).
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 18, 2010, 04:18:28 am
Well I guess if the speed difference is not that big, then disregard my comment. I was just worried about if somebody needed every single clock cycles he can get in some sort of complex game that it could cause issues.

I want to make World of Warcraft in Axe Parser! D:
j/k I don't even play WoW.
Title: Re: Axe Parser
Post by: Quigibo on April 19, 2010, 02:23:48 am
*Update*

Finally!  I have moved from alpha to beta release.  If you don't upgrade regularly, I would definitely recommend upgrading now since I really improved the user friendliness of it instead of just adding commands this time.  Enjoy!
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 19, 2010, 02:41:17 am
YAY finally 0.2! ^^

I love the menu btw, and the doc design is pretty nice. I need to give this a try again soon, especially now that there is save/load file feature and pic support. I also start to understand appvar storage more now.

I hope there are other people in the TI community who use it, considering what it can do alerady (see Portal X)

Also I think your doc definitively helped (to other forum people, I actually read it earlier) me understand some stuff more. Combined with the command index it shouldn't be too hard to get started up with Axe providing you know TI-BASIC. :)
Title: Re: Axe Parser
Post by: Raylin on April 19, 2010, 06:14:46 am
^++
Agreed and seconded.
The menu is SICK~!
Title: Re: Axe Parser
Post by: _player1537 on April 19, 2010, 06:58:12 am
same, the menus are epic, great job quigibo :)
Title: Re: Axe Parser
Post by: Silver Shadow on April 19, 2010, 07:21:19 am
There is only one thing that could make the menus better: make them in 3D and 8 level grayscale. Oh, and add some lobsters as well! ;D

Seriously, those menus are epic!!!
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 19, 2010, 10:45:27 am
There is only one thing that could make the menus better: make them in 3D and 8 level grayscale. Oh, and add some lobsters as well! ;D

Seriously, those menus are epic!!!
Lol, nah, 16 level grayscale and sound

jk. Lobsters seems like a good idea, though :P
Title: Re: Axe Parser
Post by: calc84maniac on April 19, 2010, 10:57:37 am
There is only one thing that could make the menus better: make them in 3D and 8 level grayscale. Oh, and add some lobsters as well! ;D

Seriously, those menus are epic!!!
Lol, nah, 16 level grayscale and sound

jk. Lobsters seems like a good idea, though :P

Yes, Axe needs to have a theme song to play on the main menu xD
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 19, 2010, 11:03:12 am
I know what song you are thinking about... <.<
Title: Re: Axe Parser
Post by: Eeems on April 19, 2010, 01:30:06 pm
lol!
nice! can't wait for the chance to send it to my calc :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 19, 2010, 01:41:57 pm
I'm printing the doc atm
Title: Re: Axe Parser
Post by: SirCmpwn on April 19, 2010, 05:37:02 pm
Ooo, just noticed that I got credit in the docs, not for doing anything to help with Axe's development, but for being generally awesome.  I feel, well, awesome.  Thanks Quigbo!
Title: Re: Axe Parser
Post by: ztrumpet on April 19, 2010, 06:26:21 pm
I tried to print the command list, and the "Command" column has gibberish.  My dad says it may be because we don't have this font.  It happened at school to me too.  Can you change it so it's printable?  Thanks! :)
Title: Re: Axe Parser
Post by: SirCmpwn on April 19, 2010, 06:32:40 pm
Here you go!
Also as a pdf.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 19, 2010, 11:27:32 pm
In my case, in Opera/Firefox with Quigibo version I had Times New Roman as doc font but in IE it was something like Arial for some reasons. I did not have issues viewing the text, though.
Title: Re: Axe Parser
Post by: Builderboy on April 20, 2010, 01:57:10 am
Congratulations on the public release!  Just wait patiently for your TiCalc feature :) it will be coming shortly no doubt!  It definetaly deserves it, just look at how far Axe has come!  Oh and thanks for the credit :)

and I don't get any display errors, running win7
Title: Re: Axe Parser
Post by: Quigibo on April 20, 2010, 02:07:59 am
In my case, in Opera/Firefox with Quigibo version I had Times New Roman as doc font but in IE it was something like Arial for some reasons. I did not have issues viewing the text, though.

That's interesting because that's exactly the opposite of what happens to me.  Most of the font is supposed to be Arial and all the commands are supposed to be Courier New, that's what Firefox and IE both show on my computer (vista and ubuntu).  It might have something to do with the Unicode rather than the font, but its just temporary since it will all end up in the pdf eventually.
Title: Re: Axe Parser
Post by: SirCmpwn on April 20, 2010, 11:34:43 am
Awesome update by the way.  I really dig the new menu system, especially the fact that the Options menu has a different background than the Main menu, that is a nice touch that is often overlooked.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 21, 2010, 12:40:22 am
Lolwut?

(check Axe Parser download stats)

Does it mean Axe did not get any download so far, or epic fail from ticalc stats? o.o

Again, it was added very late today and it has been avaliable alerady on Omnimaga and some people may not have updated yet.

'though, this was the first time I see this on ticalc, so I thought I would post this. :P

Btw as for tonight, this version got 50 downloads on Omnimaga. This is a total of 594 if we include all Axe Parser versions from 0.0.1 to 0.2.0 (0.0.1 is in the first post of this topic). That's more than any other download on Omnimaga site :P
Title: Re: Axe Parser
Post by: Quigibo on April 21, 2010, 12:43:45 am
No, its being downloaded, I've already been getting emails :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 21, 2010, 12:47:18 am
Lol ok. Then ticalc stats epic failed x.x

All other files uploaded today got at least 1 download. One did not even have a screenshot either and was not a math program (math programs gets a lot of downloads at this time of the year)

Unless the e-mails comes from people who downloaded it on Omnimaga? Do they tell the person downloaded it on ticalc.org?
Title: Re: Axe Parser
Post by: Quigibo on April 21, 2010, 01:04:32 am
Trust me, its getting downloads.  This happened to a few of my other programs as well, so I'm not too surprised.  I don't think missing stats imply that it lacks downloads, I think its something else or a fluke in the system.  Every program gets downloads on the front page no matter how dull or boring it is.  And when it has animated screen shots, its likely to get many.  At a bare minimum, I did download it to double check the file after it got approved there.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 21, 2010, 02:50:08 am
Aaah ok. Well either way it is getting downloads somewhere, which is the positive thing. I think it's definitively a fluke in their system. It's like when some math programs ends up with like 50000 downloads in one week. Usually it gets fixed in a few days, though. It was just strange at first x.x. Normally, when a file gets no download in a week, the last 7 day ranking won't show up. However for a file to not get download in 12 hours after it appears on the site front page, it would really be weird, considering it gets 55 times more traffic than Omnimaga and has animated screenshots. And now you say you downloaded it (altough stats only updates around 11 PM, so if you downloaded it later your download was not counted).
Title: Re: Axe Parser
Post by: TravisE on April 21, 2010, 09:10:32 am
That's weird. I've never seen that before. I didn't see anything obviously wrong on the server, so as others mentioned, it's likely a glitch or something in our system (it would only be the 9500th one I've come across :P). I'd wait about 24 more hours to see if it clears up before worrying too much.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 21, 2010, 11:11:57 am
Maybe it's because it got exactly 666 downloads on its first day, or even OVER 9000, and it broke ticalc.org? :O
Title: Re: Axe Parser
Post by: Quigibo on April 23, 2010, 01:12:13 am
What the...

It probably won't last though.  I remember Pyoro was ranked #1 for a little bit too.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 23, 2010, 01:21:20 am
wow nice, this is a good thing to see after only two days. For a program rating to show up, you need at least 5 votes. This means Axe Parser received 5 ratings alerady. However, script kiddies will most likely do their hit-n-run 1/10 rating spree again and I wouldnt be surprised if people who crashed their calc due to bad coding and not reading instructions rated it 1/10 too. They did with TI-Boy SE anyway x.x

I hope it gets the attention it deserves in the rest of the TI community!
Title: Re: Axe Parser
Post by: trevmeister66 on April 23, 2010, 10:31:46 am
That is pretty epic indeed. Hopefully its gets more and more recognition that it rightly deserves. Great work.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 23, 2010, 04:40:06 pm
That reminds me, I should vote for ità

I may also send a review later, but I will wait since someone else alerady reviewed it and his review will end up missed out

EDIT: Back on the program download stats fail, an example of them today:

http://www.ticalc.org/archives/files/fileinfo/302/30288.html
Dance Dance Revolution: Software Development Kit

Ranked as 1733 on our all-time top downloads list with 9015 downloads.
Ranked as 1 on our top downloads list for the past seven days with 6639 downloads.
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 04:54:50 pm
I just have a bit of a programming question (I'm not sure where else to ask questions like this):

How can you easily work with bits instead of bytes? That is, is there an easy way to pull out the individual bits in a byte, and vice versa?
Title: Re: Axe Parser
Post by: Quigibo on April 24, 2010, 05:59:59 pm
Not yet, but i plan to add support to it soon.
Title: Re: Axe Parser
Post by: meishe91 on April 24, 2010, 06:00:44 pm
What is the difference between bytes and bits? I've never really understood that.
Title: Re: Axe Parser
Post by: trevmeister66 on April 24, 2010, 06:30:34 pm
1 byte = 8 bits.
Title: Re: Axe Parser
Post by: Quigibo on April 24, 2010, 06:32:30 pm
Same as the difference between Hex and decimal, its just the way you write the number

For instance, the number "99" can be written

Hex: 63
Decimal: 99
Binary: 01100011

Binary mostly helps when you have a lot of Boolean variables (true/false) that you want to store into a single byte to save space since you can hold 8 of them per byte.
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 06:33:06 pm
What is the difference between bytes and bits? I've never really understood that.

A bit = 0 or 1
A byte = 8 bits
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 06:37:25 pm
I was wondering Quigibo because I plan on making a project in which tiles will appear in groups of 16 at a time, with each tile being either white or black. This works out very well using rand to generate 16 tiles at once, but it is then somewhat difficult to extract the 16 individual bits.
Title: Re: Axe Parser
Post by: meishe91 on April 24, 2010, 06:42:09 pm
Ah ok. I think I get that a little now. Thanks guys :)
Title: Re: Axe Parser
Post by: Quigibo on April 24, 2010, 06:55:51 pm
Actually, there is a little trick you can use extract them.  Try this:

Input: X is the 16-bit variable

:X->B
:For(A,1,16)
:If B^2
:<What to do if the Nth bit from the right is 1>
:End
:B/2->B
:End

It will iterate and read all the bits.

If you just want a specific bit, the Nth bit on the right, then do this:

Input: X is the 16-bit variable
Input: N is which bit (in range 0-15):
Output: Returns the value of the bit.

:X->B
:For(A,1,N)
:B/2->B
:End
:B^2
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 09:12:57 pm
Actually, there is a little trick you can use extract them.  Try this:

:X->B
:For(A,1,N)
:B/2->B
:End
:B^2

Yes, that's almost exactly what I did character for character. But I'm guessing there are much cleaner and faster methods that can be built-in, yes?
Title: Re: Axe Parser
Post by: Quigibo on April 24, 2010, 09:41:03 pm
Yes.  Actually, I think that would be pretty easy to add.  There would have to be one for setting a bit, resting a bit, reading a bit, and possibly flipping a bit.  The problem is that I can't seem to find any intuitive tokens for it.  Maybe binomcdf()?  But there's only 2 of those and its kind of a long one...

EDIT: Also, I should say that these will only work with a CONSTANT as the bit#.  So you can't have the Xth bit with X being a variable.  Otherwise, the routine you wrote is pretty efficient for it.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 24, 2010, 10:04:07 pm
Mhmm Binomcdf/pdf names are so close to each others, it might get some ppl confused x.x

The bit manipulation functions would be really handy since it makes it would save a lot of space for storing data such as treasure chests open/closed status, if you obtained an item/magic spell, etc
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 11:17:56 pm
Ok, here's a problem I'm getting close (about 1KB) to running into:

How do you compile a program that is large enough to not leave enough free RAM for both itself and the compiled program?
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 24, 2010, 11:19:40 pm
Can you archive the source file before compiling it?
Title: Re: Axe Parser
Post by: Runer112 on April 24, 2010, 11:44:12 pm
Can you archive the source file before compiling it?

Oh wow you can, didn't realize you could :o
Title: Re: Axe Parser
Post by: Runer112 on April 25, 2010, 12:22:12 am
I'm having a bit of trouble getting GetCalc(PTR) to locate things. Is it possible to find the pointer of a previously defined piece of data like GDB01? And if so, why does something apparently straightforward like this not work:

Code: [Select]
:[FF]→GDB01
:"GDB01"→Str01
:Disp GetCalc(Str01)►Dec

Does this possibly have something to do with the fact that GDB0 is a two-byte token? When I display Str01, it doesn't display "GDB01", it displays "a{1". It looks like it's breaking the two-byte GDB0 token into one-byte characters.


EDIT: On closer inspection, it appears this command was meant for AppVars, so this approach probably doesn't make sense anyways. However, my question from the second sentence still stands: How can I get the pointer of a previously defined piece of data such as GDB01, but without actually saying GDB01→something? It would be nice to be able to get the pointer of a piece of data with a variable ID, such as GDBA, where A=01.


ANOTHER EDIT: Just a quick question, would GDB1 and GDB10 be the same thing?



Why do I keep not realizing I'm about to double-post until it's too late  :-[

Title: Re: Axe Parser
Post by: meishe91 on April 25, 2010, 12:50:40 am
Just letting you know, I would watch the double posting. Use the modify button unless Rule #3 (http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=2) doesn't apply in a certain circumstance.

As for you're code and issues with it. I'm afraid I can't help very much. All I can tell is that there are issues with it, just not how to fix it and such.

For the GDB# thing. I don't think there is a GDB10, only GDB0 to GDB9. Could be wrong though, please correct me if I'm wrong.
Title: Re: Axe Parser
Post by: Runer112 on April 25, 2010, 01:03:03 am
Yeah I'm used to forums where double-posting is just fine, so sometimes I don't think to check here. But once I look down at my post(s) and see two in a row I instantly realize :-[


But anyways...

For the GDB# thing. I don't think there is a GDB10, only GDB0 to GDB9. Could be wrong though, please correct me if I'm wrong.

From the documentation:

Quote
Another thing is that Axe allows you to name everything with up to 2 numbers/letters instead of just a single number. The following are all valid names:
Str1
Pic0
GDB4
Str1A
Pic9Z
GDB45
Str66
Pic8C
GDB3X
Title: Re: Axe Parser
Post by: Quigibo on April 25, 2010, 01:11:07 am
All static pointers are distinct.  Even Str1 and Str01 are not the same.  GetCalc currently only works for appvars and programs so graph database files can not be read.

You can kind of get the Nth data pointer if all the data is the same size and declared consecutively.  If you have:
:[C0FFEE]->Str0
:[DECAFF]->Str1
:[CAFE00]->Str2

You can get the Nth pointer here by doing "N*3+Str0"

There is another way to get the Nth arbitrary pointer (not consecutive not the same size) but its a little more complicated and involves pointers to pointers.
Title: Re: Axe Parser
Post by: Eeems on April 25, 2010, 01:15:21 am
GDB0 and GDB10 are two separate pointers. It doesn't use the OS for this so it doesn't use the OS's silly rules about that.
EDIT: Ninja'd
Title: Re: Axe Parser
Post by: Runer112 on April 25, 2010, 01:19:01 am
There is another way to get the Nth arbitrary pointer (not consecutive not the same size) but its a little more complicated and involves pointers to pointers.

Want to clarify for me? Because all my data sets are of different sizes ;D
Title: Re: Axe Parser
Post by: Quigibo on April 25, 2010, 01:31:00 am
Sure, lets say you have 10 blocks of data:

[Data Block 0]->Str0
[Data Block 1]
[Data Block 2]
...
[Data Block 9]

You then make an array with the cumulative sizes for each block like this:

dList(0,size of block 0,total size of blocks 0 to 1,total size of blocks 0 to 2, ... )->GDB1

These should all be 2 byte numbers so end them all with the "r" modifier.

Now, lets say you want the pointer to the Nth block of data, you can get it by doing:

Str0+{N*2+GDB1}r

So if you want the 3rd byte of the 4th block of data, you could do:

{2+Str0+{6+GDB1}r}
Title: Re: Axe Parser
Post by: Runer112 on April 25, 2010, 01:38:07 am
Ok that looks pretty good. Just checking, though, this is a lot of data: 50 blocks totaling almost 10KB. Is it possible/safe to add all this data to just one reference?

EDIT: And while we're on the topic of large amounts of level data (this is data for 50 levels), storing all 50 levels in RAM is obviously not the best way to go. I'll probably end up putting this all into an archived AppVar (or program?), but then the question becomes: How do you extract only one level at a time?
Title: Re: Axe Parser
Post by: meishe91 on April 25, 2010, 01:43:13 am
Yeah I'm used to forums where double-posting is just fine, so sometimes I don't think to check here. But once I look down at my post(s) and see two in a row I instantly realize :-[


But anyways...

For the GDB# thing. I don't think there is a GDB10, only GDB0 to GDB9. Could be wrong though, please correct me if I'm wrong.

From the documentation:

Quote
Another thing is that Axe allows you to name everything with up to 2 numbers/letters instead of just a single number. The following are all valid names:
Str1
Pic0
GDB4
Str1A
Pic9Z
GDB45
Str66
Pic8C
GDB3X

Ah ok, I wasn't aware you could add a second character in Axe to those.

And at that point if it was in an AppVars then that is where GetCalc( comes in handy, I believe.
Title: Re: Axe Parser
Post by: Quigibo on April 25, 2010, 01:48:09 am
It should be as long as all the data is one after the other, but be careful with the size counting!  I think the limit to program sizes is 16k though or something just becasue of the way the RAM is works.  What are you doing that uses that much memory?  Is it picture files or something?  And how is the parser working by the way, I haven't actually tried it with that much data before.

EDIT: As for individual levels at a time, there really isn't an easy way to do that.  You could split the level data into more than one appvar maybe.  Also, you can get more room in the ram if you have the program archive itself at the start (doesn't affect the copy of the program that is actually running).
Title: Re: Axe Parser
Post by: Runer112 on April 25, 2010, 01:58:11 am
The parser seems to be handling the large amounts of data just fine. It takes a second or two to get through it all but it works.



And you were wondering what the data is?

I was wondering Quigibo because I plan on making a project in which tiles will appear in groups of 16 at a time, with each tile being either white or black.

16 bits (2 bytes) * ~50-100 tile groups per level * 50 levels = ~5-10KB
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 25, 2010, 02:02:34 am
Just a head up: backup often before testing! If you're doing it already, fine, but else, you take big risks when testing your stuff (a crash occurs and all your stuff is gone).

I'm saying this often lately, especially to newer members or people starting a new project in a new language or new libs, because on the old Omnimaga forums I saw too many cases of projects dying due to data loss and the author giving up.
Title: Re: Axe Parser
Post by: Quigibo on April 25, 2010, 06:42:52 pm
Hope everyone likes the new update!

I had a bad experience when I accidentally did drawing off-screen.  I couldn't get the calculator to ram clear and removing the batteries wasn't helping either.  I had to actually unscrew the case and remove the little button cell battery to unfreeze the calc.  Anyway, I don't want that to happen to anybody else, so I added a little check when drawing pixels.  Its only 6 more bytes total and any slowdown is negligible compared to the entire routine.  It also allows you to clip lines off the right and bottom sides of the screen if they overextend.
Title: Re: Axe Parser
Post by: Builderboy on April 25, 2010, 07:34:47 pm
its 6 bytes per program, not six bytes per call correct?  Or else that would be very significant :P yayyyy line routine!  This is one i have been waiting for a while, glad its finally in :) and signed division yaayyyyy!  Haha now to go through and re-optimise some of the code i have ;D
Title: Re: Axe Parser
Post by: Quigibo on April 25, 2010, 11:13:02 pm
its 6 bytes per program, not six bytes per call correct?  Or else that would be very significant :P yayyyy line routine!  This is one i have been waiting for a while, glad its finally in :) and signed division yaayyyyy!  Haha now to go through and re-optimise some of the code i have ;D
Yes, for the entire program.  Glad you like the update :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 25, 2010, 11:20:49 pm
Wow awesome! I'm happy to finally see Line support! This will be very useful for drawing game menus, because I don't always want to have to draw borders using sprites.

Keep up the good work!
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 30, 2010, 09:42:16 am
wow ticalc stats epic failed again

Axe currently has 39 downloads and 11 in the past 7 days.

Wasn't it over 80 for both? D:
Title: Re: Axe Parser
Post by: mapar007 on April 30, 2010, 12:00:31 pm
Ticalc must have magic-transferred some stats to me. I suddenly get 100 downloads/week...
Title: Re: Axe Parser
Post by: Quigibo on April 30, 2010, 03:41:13 pm
I had the file renamed in the update, so I think it reset the stats.
Title: Re: Axe Parser
Post by: DJ Omnimaga on April 30, 2010, 04:35:14 pm
Strange x.x, cuz it says "Updated", not "Added". Maybe ticalc thought you meant this as an update and merged both Axe versions and it resetted the count x.x

Oh well, hopefully if it remains updated regulary, it may eventually convince them to feature it. I think if people here starts releasing their Axe game on ticalc.org too it might help. In my case I am waiting until Monday to see if I re-add Illusiat, ROL and Reuben series, Zelda DLQ, XXR and Metroid II Expansion at ticalc. Since a recent event, I was not sure yet about re-adding my files, but if this event never involves more than one or two person, I'll re-add them (they were initially removed after a major peak of such event involving a dozen of people).
Title: Re: Axe Parser
Post by: TravisE on April 30, 2010, 08:17:10 pm
Oh yeah, I think renaming a file on ticalc.org causes the number of downloads for that current week to be reset for whatever reason. I think that it says that somewhere in the FAQ, but I often forget about that myself.

When someone updates a file and wants it renamed, my usual procedure is to rename it, approve it, merge it with the old file that had the old filename, then manually mark it as an update. That's why it shows up as an update on the front page. (There's no way to automatically update and rename a file at the same time; it has to be done like that.)
Title: Re: Axe Parser
Post by: Quigibo on May 02, 2010, 07:24:32 pm
I finally finished rewriting the entire math engine.  The code was getting way too messy and especially with the addition of signed and unsigned versions of math operations.  It was making it way too complicated to optimize the code.  The parser code is now a lot more organized, smaller, faster, and uses fewer variables.  In addition, nearly all of my example programs became a few bytes smaller from my increased auto-opt list.  In my game of life example, it actually shrunk by 9 bytes (1.3% reduction) without changing any code, simply by compiling with the newer version!  Everyone will most likely see small drops in the executable sizes.  These aren't the big optimizations though.  Those will eventually come when I get to look-ahead parsing.

I'm going to focus on some new commands now.  I might have it ready by late tonight, but I'm not sure.  Don't expect too many new things, I spent most of my time swatting bugs and cleaning the code so that future versions will be easier to write.
Title: Re: Axe Parser
Post by: Raylin on May 02, 2010, 07:32:07 pm
Very cool.

On a side note, I never really understood what an auto-opt was.
I read optimizations and that little table...

But, I think I missed the point of it.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 02, 2010, 07:42:12 pm
I finally finished rewriting the entire math engine.  The code was getting way too messy and especially with the addition of signed and unsigned versions of math operations.  It was making it way too complicated to optimize the code.  The parser code is now a lot more organized, smaller, faster, and uses fewer variables.  In addition, nearly all of my example programs became a few bytes smaller from my increased auto-opt list.  In my game of life example, it actually shrunk by 9 bytes (1.3% reduction) without changing any code, simply by compiling with the newer version!  Everyone will most likely see small drops in the executable sizes.  These aren't the big optimizations though.  Those will eventually come when I get to look-ahead parsing.

I'm going to focus on some new commands now.  I might have it ready by late tonight, but I'm not sure.  Don't expect too many new things, I spent most of my time swatting bugs and cleaning the code so that future versions will be easier to write.
cool! Glad to hear!

Do you think tile exporting (from pics) will be ready soon?

@Raylin: yeah same here. I asked Quigibo in the Axe Pages topic and he replied the following:

http://ourl.ca/4573/88037
Title: Re: Axe Parser
Post by: Runer112 on May 02, 2010, 07:49:53 pm
I'm going to focus on some new commands now.

Bit getting/setting? ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 02, 2010, 08:13:21 pm
I'm going to focus on some new commands now.

Bit getting/setting? ;D
I,m confused at what you mean, could you clarify ???
Title: Re: Axe Parser
Post by: Quigibo on May 02, 2010, 09:04:03 pm
He means the native binary/bit support.  I'll see if I have time.  Probably not though, or it might only be partially ready.

The optimizations list has a list of how many bytes each math operation takes up.  Doing A+5 for instance, the plus 5 is not on the list, so it takes the +CONST default size which is 4 bytes.  If you did A+1 instead, the operation would actually be only 1 byte since  adding 1 to a number is very efficient in assembly.  Other things like testing if a number equals 2 used to be a 10 byte command, but its now only a 9 byte command in the new version.

If you ever have the option, always try to use the auto-opt commands.  Like if you're calculating a score or something and you are using X*30 as part of the equation, you might want to consider X*32 instead just becasue it will be smaller if it makes no difference otherwise.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 02, 2010, 09:14:16 pm
True, and sometimes in some games, the score or numbers won't need to be exactly how you desire. For example, if you want max damage to be rand/1024+LV*30 (just an example), why not use *32 instead? In some cases it's not possible, though.

Also for scores, if your game is set so you get 100 points multiples, why not have it so you get one point instead then add the two additional zeros manually? (doing that might actually increase file size, though, in some cases, but it will be easier to work around the 65536 range.

Can't wait for next version of Axe ^^

Also could you awnser my question regarding tile exporting from pics? :D
Title: Re: Axe Parser
Post by: Quigibo on May 04, 2010, 03:44:13 am
Yup, 0.2.2 is here.

Want to clarify some details.  Although there weren't that many new features, I spent a lot of time on other things instead like bugs, optimizations, and more templated parsing.  Also, as far as the tile map absorber, the 8x8 tiles are added from left to right, then top to bottom.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 04, 2010, 04:39:21 am
YAY! Finally, the wait was worth it IMHO :)

Glad to see all that stuff in now

Good job

I will probably update my calc later after I finished compiling the screenshots for the video later

Thanks a lot for this btw :)
Title: Re: Axe Parser
Post by: ACagliano on May 04, 2010, 11:02:29 am
Will you eventually include support for bcalls? Like maybe use "Z-Test(X)", where X is the bcall number? And how about asm flags?
Title: Re: Axe Parser
Post by: Quigibo on May 04, 2010, 12:08:23 pm
The "Fix CODE" commands are Asm flags.  I only have 3 controllable flags right now, but I can always add more.  bcalls are way too low level since they often require registers for input, so you will have to do those with Asm(EFxxxx) where xxxx is the hex code (little endian).

EDIT:
MAJOR MINOR REVISION COMING SOON

I'm announcing this before the next version becasue there is going to be a very big change to how a lot of the commands work and I want to let everyone know if they need to modify their code to accommodate the change.  Let me first explain my reasoning:

Lets say you wrote "If A=5" (assume that A is 5 at this point).  What happens, is first, A is compared to 5.  If they are equal, it returns 1.  Then, it checks to see if the expressions is true, that is to say, that it is not zero.  So it checks if 1 = 0 which it is not, so it will execute the If block.  Now you might see a redundancy here.  A has to be compared to 5 and then the result has to be compared to 0.

EDIT:
I found out that I can not do this, its already pretty efficient here.  However, I do realize that 99% of the time, the logical "and" "or" and "xor" commands are used as Boolean "xor" "or" and "and".  Therefore, I will change them to this (3 bytes less).

Commands this will affect:
If
ReturnIf
While
Repeat

or
and
xor

What you have to change:

EDIT:
Nothing.  The only time you would ever have to modify your code is if you were using the "and" "or" or "xor" commands as low level byte operations instead of logical operations.  If you still need to do bit logic, I will be adding new commands for that.
Title: Re: Axe Parser
Post by: Builderboy on May 05, 2010, 06:31:50 pm
Hey thats pretty cool! :) The speed gain will be definetaly a great and happy gain with PortalX, as so much of my code is if statements and conditionals :O
Title: Re: Axe Parser
Post by: calc84maniac on May 05, 2010, 07:29:52 pm
I have a neat optimization idea you can use for "byte mode". Make the IX register point to the A-Z variable area and use indexing. Should save quite a bit of space since you won't have to load into a register before operating on the variables. The only problem is that the sprite routine and such would have to restore IX afterward.
Title: Re: Axe Parser
Post by: Quigibo on May 06, 2010, 03:26:01 am
hmm... but its the same size to do:
ld a,(var)
and
ld a,(ix+var)
So I don't think it makes a difference.  Don't forget, the byte commands need to use the "a" register, not "hl".

By the way, I don't think my original plan to use flags for the conditionals is going to work, but at least the "and" "or" and "xor" commands are half of what they were.
Title: Re: Axe Parser
Post by: calc84maniac on May 06, 2010, 02:40:52 pm
hmm... but its the same size to do:
ld a,(var)
and
ld a,(ix+var)
So I don't think it makes a difference.  Don't forget, the byte commands need to use the "a" register, not "hl".

By the way, I don't think my original plan to use flags for the conditionals is going to work, but at least the "and" "or" and "xor" commands are half of what they were.
It does make a difference if you do
add a,(ix+var)
as opposed to something like
ld b,a
ld a,(var)
add a,b
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 06, 2010, 10:11:55 pm
wow nice to hear about the change. I can't wait to see the difference. Hopefully code change is not too much, I don,t think my game use the code example you posted
Title: Re: Axe Parser
Post by: Quigibo on May 06, 2010, 11:31:28 pm
Oh yeah.  The only problem is like you said, I have to initialize it at the beginning and then preserve it throughout the code.  Its doable, but I'm not sure how easy it will be.  I'll just wait until I get to that part and then decide if it is simple enough to do it that way.  It would be 4 bytes to initialize it and then 2 bytes to preserve it each drawing command that uses it.  And since this is a very advanced feature anyway, I'm not sure how much it would be used and I don't want to add too much baggage on the normal code size.

Also, I noticed that there is a built-in bcall for division, so that should reduce the size a lot.  Even though the bcalls are generally slower, its using an 16/8 bit routine for smaller numbers instead of the standard 16/16 bit division, so it comes out to the same speed anyway.  I can also generalize this to modulus.

calc84, I have a question.  Do you know if the _HomeUp bcall is supported on all of the 83+ OS's?  I remember it used to not be in the include file or something so I don't know if it was only added after a certain point.  Maybe I'm just crazy and imagining this.

As you can tell, I've been going though the bcall list and I've found a lot of good ones.  However, I don't ever want to compromise speed so most of them won't cut it.
Title: Re: Axe Parser
Post by: _player1537 on May 09, 2010, 11:12:03 am
Where do we get the 'b' for binary numbers?  Is it just the lowercase 'b'?  If so could it be changed to something without needing the lowercase letters?  like EEbinary number, or E(r)binary number, or Ebinary number (r).  (the E's are the scientific notation E)
Title: Re: Axe Parser
Post by: Quigibo on May 09, 2010, 11:54:58 am
Yeah, its the lowercase b.  I added the lowercase toggle to the parser options menu for this reason and I think lowercase letters will be used in the future.  There just simply aren't enough tokens available, let alone ones that make sense in most situations.  I also hate having the lowercase alpha on by default, but I don't mind toggling it while writing a program.  Is there another reason you're against it?
Title: Re: Axe Parser
Post by: _player1537 on May 09, 2010, 12:08:38 pm
It's just annoying to write code with.  IE if I use a bunch of variables and such, then if I don't have it fully thought out, I will press alpha for a variable, maybe decide I don't need a variable, and press it again.  But with lowercase alpha on then I have to press alpha 2 times, I could probably get used to it, or just do as you say and toggle it real quickly.  also, it makes editing a pain if you accidently leave alpha on and you use up or down.
Title: Re: Axe Parser
Post by: Quigibo on May 09, 2010, 12:30:27 pm
I would recommend getting used to it becasue one of my future plans include variable aliases, which is a way to name variables like instead of S, you can call it "Score" but all letters after the first one have to be lowercase to avoid ambiguity.

Or you can be like me and just keep it off by default and only turn it on when you need a lowercase character.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 09, 2010, 02:12:13 pm
One major issue with lowercase letters is that they're 2 byte tokens. Make sure to not overuse it because then source code will grow large pretty quick.
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 12:50:51 am
Honestly, I don't really care how big the source is (within reason) since it will generally be smaller than the executable and it can be archived during parsing.  You would never have a 10000 byte source since the compiled program would likely be around the 16kb limit anyway.

Also, I do have finals coming up soon.  Don't expect much over the next month.  I'll still try to update every week, but there'll probably just be 2 or 3 new things in each version from now on until school ends.  Once summer hits, there will be rapid progress again and 1.0.0 will be finished before the end of summer.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 12:55:46 am
actually Calc84 mentionned somewhere the limit is actually 8.8 KB in Mirage. For the rest it's 8.1, but yeah I see what you mean. If you got a lot of data you migth run out of space quick, though

I hope things goes well with school and that you're not too busy afterward. It would suck to see you go D:
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 05:04:53 am
I'm having a little grayscale crisis.

First of all, it needs to have constant pause times or else it looks really crappy so I can't use the screen delay timer.  If I make the pauses short enough, its speedy fast for 6MHz mode but fails on 15MHz mode.  If its too long, it looks great on 15MHz mode, but really lags in 6MHz mode.  That means, it has to pause a different amount of time depending on if its in 6MHz mode or 15MHz mode.  I can add a check to pause a different amount of time for each mode.  The check is too much code to look good on 6MHz mode unless I fix a few things.  If I use some undocumented instructions, I can speed it up fast enough to look good, but then I lose compatibility with the NSpire.  I could also skip one of the checks to speed it up, but then it still pauses the longer 15MHz pause time when using a regular 83+ thus losing compatibility with the original 83+.

So it seems like a lose-lose-lose situation right now.  I can't seem to find a way to make the routine fast enough yet still compatible with every model at every speed.  I might have to either make separate routines for each speed or just settle with the ugly "checkered" grayscale.  I don't know what to do.

And don't say I'm being too picky about quality.  If perfect gray is not reproducible, it defeats the purpose of the command since then you might as well just flash the images on and off since that flickering would be less annoying than the checkered flickering.
Title: Re: Axe Parser
Post by: Silver Shadow on May 10, 2010, 06:44:35 am
How about having a variable that tells the program what type of delay to do? I mean that for example the default state is 0 so that each time a grayscale is run, it uses the 6MHz delay. However, if you put 1 into it, then the grayscale commands will be using 15MHz delays. And maybe have it so that 2 different programs are compiled when the variable is modified.

Dunno if I made myself clear.   
Title: Re: Axe Parser
Post by: calc84maniac on May 10, 2010, 11:17:35 am
Use HALT for delays?
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 12:50:10 pm
My suggestion would be that you use one routine for each calculator speed. If the program is compiled to run at max speed, insert both routines and if the person runs the game on a 15 MHz calc, it will call the 15 MHz grayscale routine instead of the 6 MHz one. If the game is made to run at 6 MHz the entire time, then during compiling, just include the 6 MHz routine. It might increase file size in the former case, but It seems like it's the only real way to do it.

Quality-wise it was ok for me, altough I could understand that for complex games it might flicker way too much and be hard to keep in sync.

That said, nice to see a new update, though, altough I had 0.2.3 for a day or two, already :P (altough it wasn't finished yet)
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 01:58:35 pm
I'm talking about the draw routine itself, the DispGraphr routine.

I think I will use separate routines for each speed.  You'll basically never use both of them in the same program anyway, so it can only save size and speed.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 02:03:18 pm
Yeah I was talking about that draw routine too.

By never using both of them, do you imply that if we compile a 15 MHz game, that game will not run at all on a 6 MHz calc or vice versa? In that case, I guess authors will have to make sure to never forget to compile two copies of their games before release: one for 83+ users and one for SE users, for authors who want their game to run on all models but run at full 15 MHz speed on faster models
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 02:06:44 pm
If you make a 15MHz-only game, it wouldn't be compatible on the regular 83+ anyway, so there would be no reason to make separate versions.  Otherwise, you would just use the 6MHz gray for both.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 02:14:27 pm
Well, sometimes, people want to make a 15 MHz game, but still allow people to play it on regular 83+ too, even if it means less enjoyable gameplay.

An example of this is Axe Tunnel, Super Mario Smash Dance, Metroid II: Evolution and to a lesser extent, Illusiat series. All those games run without crashing on a regular 83+. They just run about twice slower.

I prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.

Will the Dispgraphr command still be useable in the future with the Full command? If not, then I am afraid I'M gonna have to stick to version 0.2.3 of Axe Parser for future development. That's unless in the future, you add a compiling option that allows the author to sacrify file size to include both routines and a check if their prog is ran on a 6 MHz calc and automatically run the 6 MHz gs routine rather than the 15 MHz one.

I guess it's your choice, though, considering Axe Parser is your very own project. But I'm afraid if future versions breaks cross-calc compatibility for compiled programs, I will no longer be able to participate into testing future versions and will be sticking to 0.2.3, the last cross-compatible version, to make games (it has pretty much everything I need now anyway).

Or is the 6 MHz command gonna be useable in "Full" mode too?
Title: Re: Axe Parser
Post by: Raylin on May 10, 2010, 03:24:09 pm
One thing about the new update:

Can someone please tell me how the new commands would be used?
More specifically, conj()r and the bitwise "and", "or", and "xor".
Title: Re: Axe Parser
Post by: ztrumpet on May 10, 2010, 03:25:17 pm
How about having a variable that tells the program what type of delay to do? I mean that for example the default state is 0 so that each time a grayscale is run, it uses the 6MHz delay. However, if you put 1 into it, then the grayscale commands will be using 15MHz delays. And maybe have it so that 2 different programs are compiled when the variable is modified.

Dunno if I made myself clear.   
This is the best option possible.  I think it would be like this:
If (Calc == 83+)
Then
0->A
Else
80->A  //I have no idea how much extra this should be, so I'll just use 80
End

This value would be stored somewhere and used later like this:

Grayscale_Pause //Like Pause, only it uses the value looked up at the beginning of the program to determine how long to pause

I do not like the idea of breaking cross compatibility.  If you do this, you will lose people.  Hopefully you can just store this value to a little chunk of Safe RAM and add 5 or so more bytes to the program size and keep cross compatibility. :)
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 05:54:01 pm
Quote
I prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.
What you can do is this:

prgm15MHZ
:Full
<some code>
:Normal
:DispGraphr
:Full
<more code>

That way it will do all the game calculations in 15MHz mode but still update the graph in 6MHz mode.  The 6MHz and 15MHz DispGraph routines take the same amount of time since they are limited by the same LCD delay in both cases.

One thing about the new update:

Can someone please tell me how the new commands would be used?
More specifically, conj()r and the bitwise "and", "or", and "xor".

This is a good explanation for the bitwise features:
http://en.wikipedia.org/wiki/Bitwise_operation

As for conjr, these are the same:
conj(L1,L6,100)
conj(L1+99,L6+99,100)r
It copies the 99th byte first then the 98th, the 97th, ... to the 0th byte instead of the other way around.
Title: Re: Axe Parser
Post by: Raylin on May 10, 2010, 07:20:14 pm
Hmm...

What are the applications of such?
I only see redundancy as of right now.
Title: Re: Axe Parser
Post by: calc84maniac on May 10, 2010, 08:30:47 pm
Hmm...

What are the applications of such?
I only see redundancy as of right now.

You mean the backwards copy routine? It's so you can copy overlapping areas. For example, if you wanted to copy 5 bytes from L1 to L1+1, a forward copy would overwrite the later data before it could be used.
Title: Re: Axe Parser
Post by: Quigibo on May 10, 2010, 08:48:34 pm
Also, you can use it for general optimizing.

If you check the source of Starship, I was using a bunch of things like this: conj(A-3,B-3,4)
Which I changed to this: conj(A,B,4)r  Since it doesn't have to do extra subtractions.
Title: Re: Axe Parser
Post by: meishe91 on May 10, 2010, 10:29:55 pm
Hey, just on the grey scale issue thing. Would it be possible to have something like DispGraph(15)r or DispGraph(6)r? That way you could just choose which speed you want and when. I don't know if you already decided or not, but just a thought. Hope it all is going well :)
Title: Re: Axe Parser
Post by: Raylin on May 10, 2010, 10:36:07 pm
That would seem more troublesome than it would be helpful.
You must remember not everyone is smart like us.
People can screw that command up and break the entire program.

Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 10:44:27 pm
Quote
I prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.
What you can do is this:

prgm15MHZ
:Full
<some code>
:Normal
:DispGraphr
:Full
<more code>

That way it will do all the game calculations in 15MHz mode but still update the graph in 6MHz mode.  The 6MHz and 15MHz DispGraph routines take the same amount of time since they are limited by the same LCD delay in both cases.

One thing about the new update:

Can someone please tell me how the new commands would be used?
More specifically, conj()r and the bitwise "and", "or", and "xor".

This is a good explanation for the bitwise features:
http://en.wikipedia.org/wiki/Bitwise_operation

As for conjr, these are the same:
conj(L1,L6,100)
conj(L1+99,L6+99,100)r
It copies the 99th byte first then the 98th, the 97th, ... to the 0th byte instead of the other way around.

Ah ok thanks, that migth work.

Also, while at work, I thought about another idea for my issue: in the future, if you add external libraries, I will just keep my grayscale calling external so if I want to compile my game I do not need to change like 50 grayscale commands in a dozen of sub-programs when I compile for a second set of calculators. I would just change one routine instead.
Title: Re: Axe Parser
Post by: meishe91 on May 10, 2010, 10:51:32 pm
Well I figure as long as there is a short explanation saying something like the six is for 83+ calculators while 15 is for 83+SE/84+(SE). Then you could say that if you want to use the six on the higher calculators that it is more advanced stuff. I don't know. Just seems like a good idea to me though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 10, 2010, 10:57:32 pm
I think if cross calc compatibility is broken with certain commands, there should be a warning in the doc for each commands. If it just breaks compatibility between 6 and 15 MHz mode (like I think), then the command list should simply warn to not use the 15 MHz command on a regular 83+ or in 6 MHz mode and to not use the 6 MHz commands in 15 MHz mode (use Normal beforehand).
Title: Re: Axe Parser
Post by: calc84maniac on May 11, 2010, 12:27:00 am
I actually switch to 6MHz before grayscale display in Chip's Challenge. It's not an uncommon method.
Title: Re: Axe Parser
Post by: meishe91 on May 11, 2010, 12:29:30 am
Just as a quick side question: Does 15MHz have any advantage over 6MHz besides for speed?
Title: Re: Axe Parser
Post by: Quigibo on May 11, 2010, 12:30:48 am
I actually switch to 6MHz before grayscale display in Chip's Challenge. It's not an uncommon method.
Alright, that reinforces my thoughts.  If you want 15MHz grayscale, you will have to switch to 6MHz manually to display it.  Even if some new programmer accidentally tries it in the 15MHz mode, it doesn't crash the calc or anything, it just displays funky garbage on the screen, so its not a big deal.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 11, 2010, 12:31:57 am
ooooh ok, like when I beta tested xLIB on a SE back in its early app days x.x I am kinda glad it won't crash.

Will the 6 MHz command remain DispGraphr btw?
Title: Re: Axe Parser
Post by: ztrumpet on May 11, 2010, 07:44:42 am
I actually switch to 6MHz before grayscale display in Chip's Challenge. It's not an uncommon method.
That makes it sound a lot better.  I now think this is the best method. :D
Would DispGraph automatically put it in 6mhz, or would the user have to do this themselves?
Title: Re: Axe Parser
Post by: Quigibo on May 11, 2010, 12:37:47 pm
I could have it do that for you, but I'd rather the programmer do it themselves since those making 6MHz games won't want to have the extra size increase for a feature they're not using.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 11, 2010, 12:44:54 pm
Does calling the grayscale from a sub-routine slows it down a lot? If not, then I guess this would be the best solution. Otherwise, my big concern ATM is the increase in file size due to having to use Normal:Dispgraphr:Full instead of Dispgraphr. With about 20-30 grayscale commands total, would the increase in code size be considerable?
Title: Re: Axe Parser
Post by: Quigibo on May 11, 2010, 12:51:43 pm
No, a subroutine is negligible unless its called over 9000 times per second.  Typically, the screen updates around 20-60 times a second.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 11, 2010, 12:53:53 pm
Ok thanks. I guess it shouldn't be that bad, then.
Title: Re: Axe Parser
Post by: ztrumpet on May 11, 2010, 04:08:02 pm
I could have it do that for you, but I'd rather the programmer do it themselves since those making 6MHz games won't want to have the extra size increase for a feature they're not using.
Ah, very good point! :)
I like how things are headed.

Full and Normal translate to one byte of code more each, right?
Title: Re: Axe Parser
Post by: Quigibo on May 11, 2010, 07:08:39 pm
2 bytes in the source code if you include the colon.  The actual size in the executable is 9 and 3 bytes for Full and Normal respectively.  Full is a little larger because it also returns if the calculator was successful in running 15MHz mode, which is used to distinguish what type of calculator is being used.
Title: Re: Axe Parser
Post by: ztrumpet on May 11, 2010, 10:15:19 pm
Ah, okay.  Can there be a Full that doesn't return, so it would be smaller and faster if you want it to be?  I'm all for compiled size and speed. ;D
Thanks!
Title: Re: Axe Parser
Post by: kindermoumoute on May 15, 2010, 12:01:55 pm
I am French, I love what you made, I'm still learning axe parser!
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 15, 2010, 12:05:21 pm
Hi and welcome here. Glad you like it!
Title: Re: Axe Parser
Post by: kindermoumoute on May 15, 2010, 12:31:13 pm
Just one question, how do I reuse an image acquired by the program?
I read and I re-read the PDF, I do not understand everything (it would require a translation: p)
Title: Re: Axe Parser
Post by: Raylin on May 15, 2010, 12:34:35 pm
I believe that you store that data into another variable.
Then, use that variable normally.

Code: [Select]
[Pic1]->GDB1
EDIT: Also, does anyone know what DATA→NAME does? Use? Practical application?
Title: Re: Axe Parser
Post by: kindermoumoute on May 15, 2010, 12:37:30 pm
And how to show next?
Title: Re: Axe Parser
Post by: Silver Shadow on May 15, 2010, 12:45:40 pm
Talking about translations, I can make a french version of the PDF. Is it OK with you, Quigibo?
I can also make it in russian, but I doubt that it will be useful... :P
Title: Re: Axe Parser
Post by: kindermoumoute on May 15, 2010, 12:48:29 pm
There are many TI in russia? :p
Title: Re: Axe Parser
Post by: Quigibo on May 15, 2010, 01:45:44 pm
I believe that you store that data into another variable.
Then, use that variable normally.

Code: [Select]
[Pic1]->GDB1
EDIT: Also, does anyone know what DATA→NAME does? Use? Practical application?
You just used exactly what you're asking about in that example.  [Pic1] is the "DATA" and GDB1 is the "NAME".

The problem with using an image in Axe is that unfortunately, the picture files only have 96x63 pixels, so it misses the last row.  Usually what you want to do is just add 12 bytes of white pixels to the bottom or top.  Here is how you display an image right now.  I think I will automate this in the future:

Code: [Select]
:[Pic1]->Pic1        ;Store the picture in memory call it Pic1
:det(12)             ;Add 12 zeros (96 pixels) to the bottom
:conj(Pic1,L6,768)   ;Copy all 768 bytes to the graph buffer
:DispGraph           ;Draw the buffer onto the screen

By the way, there is an even easier way to do it in 0.2.4 (not out yet) that I came up with.  You can draw any buffer to the screen directly without having to copy it to the main buffer first by doing this:

Code: [Select]
:[Pic1]->Pic1        ;Store the picture in memory call it Pic1
:det(12)             ;Add 12 zeros (96 pixels) to the bottom
:Pic1->DispGraph     ;Draw the picture directly onto the screen

EDIT: If anyone wants to do translations of any of the files that's fine.  But they aren't done yet, so they would have to be re-translated in the future so keep that in mind.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 15, 2010, 05:24:57 pm
I agree about translation, it might come useful as long as they're updated too. I personally am unsure if I can take on such large project, though, especially that I do not know the french terms for ASM stuff.
Title: Re: Axe Parser
Post by: kindermoumoute on May 15, 2010, 05:42:58 pm
Thank you, Quigibo
Where could I find native assembly code written in hexadecimal?
Title: Re: Axe Parser
Post by: Quigibo on May 15, 2010, 05:59:41 pm
There are a few of them here:
http://tibasicdev.wikidot.com/hexcodes

But most of those you can already do without needing assembly.  Usually, you would compile some asm yourself and just read off the hex code.  Its mostly if you want to make an Axe/Asm hybrid for improved speed/size/capabilities but still have the ease of use and on-calc programability.
Title: Re: Axe Parser
Post by: meishe91 on May 15, 2010, 06:06:28 pm
So to make those codes on TIDB someone just wrote a program for them (in assembly) and then compiled them into hex?
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 15, 2010, 06:57:35 pm
There is an online hex disassembler by Galandros on http://asmtools.omnimaga.org/asmunsquisher/ . Take a 8xp program then it will give you the HEX data. Just make sure to remove the header and unnecessary stuff, though.

There are also other hex routines on WikiTI http://wikiti.brandonw.net/index.php?title=83Plus:Basic:Tricks_ExecAsm
Title: Re: Axe Parser
Post by: meishe91 on May 15, 2010, 07:14:07 pm
Doesn't the .8xp file have to already be written in assembly?
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 15, 2010, 07:18:37 pm
yeah, you compile your z80 code with the assembler of your choice, create 8xp file, then extract the HEX code with Galandros hex disassembler
Title: Re: Axe Parser
Post by: Quigibo on May 16, 2010, 03:41:14 am
Copying all those grayscale sprites took as long as writing the update almost x.x

Even though grayscale was the main focus of the release, I've found that I've significantly decreased program size with the look-ahead parsing, it was surprisingly simple to write.  I also found a part that was supposed to be optimized but never was in the previous versions and just went unnoticed.  Well, I fixed that too.

Just an explanation for look ahead... there is a situation that you will never be in, but you might think its a bug if you try it.  Its intentional.  Whenever you add or subtract a constant to a pointer like: L1+5, it automatically groups this into a single pointer (L1+5) to minimize runtime calculations.  Constant + Constant = Constant so now it just replaces the number with what it should be before it compiles.  But, that changes the order of operations if you were to do some other operation on the left of the pointer.  Like 2*L1+5 is actually 2*(L1+5).  But you'll never end up doing that really becasue the only operation you ever do to pointers is addition and subtraction anyway.

As an example, Builderboy's Portal X code shrunk by about 6% (almost 500 bytes) with these optimizations alone.
Title: Re: Axe Parser
Post by: Galandros on May 16, 2010, 05:02:51 am
Amazing work, Quigibo. That was a impressive optimization.  ;)
Is there any main optimizations like that left? ;D
Title: Re: Axe Parser
Post by: calcdude84se on May 16, 2010, 08:26:44 am
definitely a very useful optimization. would evaluating the results of calculations with constants at compile time also be practical? it may make source code easier to read, since one can tell where the numbers came from.
Title: Re: Axe Parser
Post by: Builderboy on May 16, 2010, 04:08:24 pm
Yay! This optimization makes me happy :)
Title: Re: Axe Parser
Post by: ztrumpet on May 16, 2010, 05:27:30 pm
Yay, I like this optimization!  Great job Quigibo! ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 16, 2010, 06:16:50 pm
Awesome!

I downloaded the update this morning but I had to go to work early so I couldn't post.

I will try to see if my tunnel game optimizes more with this new version. I hope I don't need to change too much code, tho XD (besides getting the gs at 6 MHz)

It was alerady an awesome project, now I am running out of words to describe it :P

EDIT: Aw, no optimizations found in my tunnel, still same size D:, oh well, awesomes still ^^

Also I'm glad we can now display buffers from a pointed memory location :D
Title: Re: Axe Parser
Post by: Quigibo on May 17, 2010, 02:40:50 am
Amazing work, Quigibo. That was a impressive optimization.  ;)
Is there any main optimizations like that left? ;D

There are many more left.  I only did the most basic of basic look-ahead parsing technique.  Another major optimization will be looking ahead to see if arguments are constant or variable expressions when compiling.  Right now, expressions after each argument are saved as a precaution becasue later arguments might use longer routines that scramble the registers.  But if I can guarantee that all arguments after that point are constant, then I don't need to do all that useless saving.

@DJ, your code probably was optimized.  I had to make the sprite drawing routines slightly larger to accommodate grayscale, however at the same time, there were a couple places that got optimized so it just happened to balance out coincidentally.  ;)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 17, 2010, 12:57:24 pm
Aaaah I see lol that's probably why :D

I really looked a lot at optimizations initially when doing my first Axe game. For the 2nd one (Netham45) I didn't because I wanted to make sure the final size was exactly 666 bytes :P
Title: Re: Axe Parser
Post by: Runer112 on May 17, 2010, 04:59:07 pm
I've been working on the start of a game since yesterday. The first task I undertook was animation of the character you control, as I wanted to get to test out the new 4-level grayscale. The 16x16 sprite has 5 different body positions, with the body outlined in dark gray and filled with light gray, as I plan for the surroundings to be drawn in black and white for contrast. It looks great when he isn't moving much, but when he jumps, the image of him breaks up a lot. When drawn in just 3-level grayscale, it looks much cleaner. Is this just an unavoidable aspect of 4-level grayscale sprites moving quickly?

Below are GIFs of the program displaying 3-level grayscale (above) and 4-level grayscale (below). They play in full speed on my computer, with any luck they will for anyone else viewing them too.
Title: Re: Axe Parser
Post by: ztrumpet on May 17, 2010, 05:00:43 pm
Those look really nice!  Awesome job! ;D
The 4lvl looks a little choppier.  =/
Title: Re: Axe Parser
Post by: meishe91 on May 17, 2010, 05:47:34 pm
Those look awesome! Great job. Though the 4-level gray scale is a little choppy I do like the little outline around the character.
Title: Re: Axe Parser
Post by: Runer112 on May 17, 2010, 06:26:53 pm
Dammit. Just did a bunch of code shifting and re-organizing for my program from 3 posts ago on my computer, and when I tried to send it to my calculator, it said it couldn't because "the device is in a low battery state" >:(

P.S. If anybody has any ideas for efficient raytracing raycasting, feel free to share, because I'll need something of the like for the game I'm working on. ;) In my case though, the floor, walls, and ceiling will simply be composed of black and white squares and the point of view won't change quickly, so I'll probably end up drawing everything the slow way to start and then just shifting things by drawing and erasing lines on the sides. Sort of like video codecs that start by encoding a full key frame but then just encoding changes from frame to frame instead of encoding every single frame.
Title: Re: Axe Parser
Post by: Quigibo on May 17, 2010, 09:20:39 pm
The only way to make it look cleaner is to update the screen more often between frames (slow it down) becasue 4 bit gray needs to be drawn in the same place for 3 frames to guarantee a cycle through all the gray.  That's becasue the pixels stay black for 0,1,2, or 3 times during the duration of 3 frames to get the white, light gray, dark gray, and black.  By contrast, 3 bit gray only needs to be drawn 2 times between frames for a smooth animation (but still, more looks better).  That's why most 4 color grayscale games, like desolate, don't generally feature a lot of motion at once.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 17, 2010, 11:22:15 pm
that looks nice. Usually it's inevitable flicker will occurs when the sprite moves around at very high frame rate. But Quigibo advice should help.
Title: Re: Axe Parser
Post by: Tribal on May 18, 2010, 04:30:32 pm
Raytracing or Raycasting? Raytracing is much more complex, and I do not know of any raytracing ever done on a calculator.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 18, 2010, 04:32:11 pm
There is for the TI-Nspire, but it takes several seconds to render, if I remember
Title: Re: Axe Parser
Post by: Runer112 on May 18, 2010, 06:44:49 pm
Raytracing or Raycasting? Raytracing is much more complex, and I do not know of any raytracing ever done on a calculator.

Whoops my bad. I deliberately looked the two up before I posted that to make sure I didn't mix them up, but I guess I mixed them up anyways lol.
Title: Re: Axe Parser
Post by: Builderboy on May 18, 2010, 11:31:27 pm
Lol so which one is it?  Either way you might want to talk to bwang, he has written both the raycaster, and the raytracer for the nSpire :) And both are quite amazing :O
Title: Re: Axe Parser
Post by: Runer112 on May 19, 2010, 09:46:13 pm
Lol so which one is it?  Either way you might want to talk to bwang, he has written both the raycaster, and the raytracer for the nSpire :) And both are quite amazing :O

Raycasting.
Title: Re: Axe Parser
Post by: Quigibo on May 21, 2010, 01:26:45 am
Just wanted to let everyone know, this weekend is going to be non-existent.  I have a take home midterm in my quantum physics class.  The "take home" part may sound like it would make it easier, but the reason its take home is becasue it would take much longer than the class time to finish the exam.  And its not like we would be able to find help anyway since this is way beyond even the internet's ability.  I estimate it will take me about 20 hours to finish at the current rate I'm finishing problems (its only 4 problems by the way).  Despite being my hardest class, its still the most fun and I'm actually doing pretty well in it.  Wish me luck!

As an effort to concentrate better, I will not be visiting the forums again until Monday.  I will release a new version of Axe Parser tomorrow night even though there really isn't much new I've added.  Some notable features are read/write to the answer variable as a number, and pseudo error scrolling.  What that means is that the program will scroll to the error if you press [prgm] after receiving an error.  However, you cannot exit the app into the program editor, it will instead return you to the home screen.  I still need to figure out how app change hooks work to exit directly into the editor at the troubled spot.  But at least this provides some temporary assistance to help find syntax errors.
Title: Re: Axe Parser
Post by: Builderboy on May 21, 2010, 01:36:06 am
Wow that sounds like a crazy test, good luck with it!  And scrolling to error sounds very nice :) i like that implementation, it works well ^^ Well good luck with your quantum physics! ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 21, 2010, 01:38:23 am
Aaah ok it's fine I understand. I wish you good luck in your exams. However, question, why is it mid-term? Does it means you have school this Summer too?

Anyway nice feature you added, can't wait to try them out! Good luck in your school stuff!
Title: Re: Axe Parser
Post by: Quigibo on May 21, 2010, 01:49:44 am
The grade is 3 midterms and a final.  This is the 3rd midterm.  The word "midterm" is kind of misleading.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 21, 2010, 01:50:46 am
oh ok x.x

weird x.x, I always thought of midterms as tests occuring in the middle of a semester
Title: Re: Axe Parser
Post by: ztrumpet on May 21, 2010, 03:41:54 pm
Wow, that's a long test.  Good luck! ;D
Axe's new release is sounding great! :D
Title: Re: Axe Parser
Post by: TIfanx1999 on May 22, 2010, 08:17:41 am
I estimate it will take me about 20 hours to finish at the current rate I'm finishing problems (its only 4 problems by the way).  Despite being my hardest class, its still the most fun and I'm actually doing pretty well in it.  Wish me luck!
20 hours? Good Gravy man! I wish you the best of luck with it!
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 22, 2010, 05:42:44 pm
Just make sure to resist the temptation to visit the forums too much this weekend, though :P (unlike last night lol)

I often plan to do stuff one evening then end up posting here or IRC and other forums and not doing anything XD

Example is when BrandonW was showcasing his BlueTooth8x project (to send stuff from a calc to another, wireless) over a livestream thursday. We ended up talking to him via text in #cemetech then he replied to us by talking, and ranting about how TI Connect sucks and stuff XD. And at the same time, a Cemetech troll was posting random stupid double-posts that made no sense in his project topic and then the thread basically became 4chan without the pr0n. :P
Title: Re: Axe Parser
Post by: Quigibo on May 24, 2010, 06:04:15 pm
Okay, I'm back.  My estimate was a gross understatement.  I pulled an all nighter last night to finish it.  It was about 25 pages of calculations >.>  So I'll probably sleep later today to catch up on the sleep I didn't get.

Anyway, its good to be back.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 24, 2010, 06:09:04 pm
Ouch x.x that sucks

I hated school projects and homework that took over 2 hours each and I'm the kind of person to quickly get discouraged under pressure (the reason why I dropped out of college years ago). Glad you managed to finish it all. Get some sleep lol, though.

(or maybe not... sometimes that helps someone find more optimizations in his calc projects he wouldn't find in any normal state of mind. j/k ;D)
Title: Re: Axe Parser
Post by: Builderboy on May 24, 2010, 09:47:28 pm
Welcome back Quigibo :) And that sucks about your test D: Seems a bit excessive, oh well at least its done :) Congrats for pulling that all of!  Well done!
Title: Re: Axe Parser
Post by: calc84maniac on May 24, 2010, 09:58:06 pm
Hey, I've been wondering, do you optimize constant memory reads yet? You can simplify those to a simple LD HL,(address) instruction
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 12:23:09 am
Kind of yeah.  "Static Pointer" +- "Offset" optimizes to a single load.  So recalling something like {L1+8} takes the same amount of memory as recalling {L1} itself.
Title: Re: Axe Parser
Post by: calc84maniac on May 25, 2010, 12:25:52 am
Just making sure you weren't going through the whole load like "ld hl,address \ ld a,(hl) \ inc hl \ ld h,(hl) \ ld l,a" like you have to do for non-constant loads.
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 12:28:25 am
Oh yeah, actually I'm pretty sure it isn't now that you mention it.  Definitely easy enough to check for I suppose.  I'll see if I can get it working next version.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2010, 12:30:38 am
What are the planned new features (or optimizations/improvements) for the next version, by the way?
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 12:32:12 am
I haven't started working on it yet, but probably all the stuff I was going to do last week but didn't have time for.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2010, 12:55:58 am
Ok, I forgot what it was though D: I know you were planning to try implementing something to check for possible optimizations by scanning through the code in advance when compiling, but I was not sure for which version it was planned.

EDIT Btw, I noticed that the 3 level grayscale command still works fine even if you forget to set the program to 6 MHz before running the command. I heard before that garbage would be displayed instead starting on Axe 0.2.3. Did you change your mind about the way the commands would work finally?

I am asking since I just compiled my Tunnel clone with Axe Parser 0.2.5 and the game still run without any glitches on my Nspire
Title: Re: Axe Parser
Post by: cooliojazz on May 25, 2010, 04:20:31 pm
I'm wondering, doesn't the getcalc() return a pointer to the start of the data section of a file?  Cause it doesn't seem like it...  I mean, like obviously I can get all the data and stuff, that works fine, but trying to read backwards into the header...
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 04:22:09 pm
It won't glitch on the Nspire or an emulator because they don't need the LCD delays.  But all the hardware is different and some LCD drives are slower than others and vary widely with different models.  Even my own calculator seems to have slightly different timing each time I use it based on the grayscale patterns I receive on what is usually perfect gray (possibly a temperature dependence?), so I would highly recommend switching into 6MHz mode during any grayscale displaying even if it works for your model.

EDIT: You should be able to read backwards into the header with a program or appvar header.  But if you're familiar with assembly, you'll know that the header data depends on the size of the program name and is in a weird backwards order I think (or is that the symbol table entry I'm thinking of).
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2010, 04:24:05 pm
aaah ok thanks for the info. I guess I'll do that in my next update of Axe Tunnel.
Title: Re: Axe Parser
Post by: Raylin on May 25, 2010, 04:25:31 pm
Question: Was SortA() and SortD() implemented yet?
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 04:31:17 pm
Oh yeah, I completely forgot about that!  I actually did add it, but don't use it becasue I forgot to make the arguments in order.  Its currently sortA(size,ptr) but I will change it to sortA(ptr,size) probably.  Or I don't know, which one do you think is more intuitive?
Title: Re: Axe Parser
Post by: Raylin on May 25, 2010, 04:32:40 pm
SortA(PTR,SIZE).

It just makes things uniform.
Title: Re: Axe Parser
Post by: cooliojazz on May 25, 2010, 04:35:19 pm
Umm, i have tried to read the data before the data pointer (which should be the header) but it is most definately NOT the header.  I was trying it with random programs (note: I am VERY familiar with program headers =P) and what came up was definately not a header.  Actually, it normally had the name of the program i was executing it from stuck in there somewhere... =P  Oh, and program headers are always constant.  And i think appvars are the same, not sure tho...
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 04:43:02 pm
Okay, I checked the doc again, and you're right, there is NO header at the variable's data.  There is only the size field.  All the header data is in the symbol table (and each header there is not a fixed size by the way).
Title: Re: Axe Parser
Post by: cooliojazz on May 25, 2010, 04:46:34 pm
Really?  How does it change size? O.o  And ok, well, then is there any way to access those?
Title: Re: Axe Parser
Post by: calc84maniac on May 25, 2010, 07:02:01 pm
Maybe there should be a GetCalc()r command that returns the VAT pointer instead of the data pointer.
Title: Re: Axe Parser
Post by: Builderboy on May 25, 2010, 07:03:23 pm
what kind of fun trickery could you do with the vat data?
Title: Re: Axe Parser
Post by: calc84maniac on May 25, 2010, 07:27:00 pm
Well, you could change the type of variable between program, protected program, and appvar :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2010, 07:30:16 pm
Do you mean you could just convert a PRGM to APPVAR, lock programs, hide them and even convert a string to a picture?

EDIT: or even rename them?
Title: Re: Axe Parser
Post by: calc84maniac on May 25, 2010, 07:47:00 pm
Do you mean you could just convert a PRGM to APPVAR, lock programs, hide them and even convert a string to a picture?

EDIT: or even rename them?
I think so, yes (though renaming to a different name length would be somewhat difficult in Axe)
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2010, 07:54:59 pm
Hmm... I like the idea of having a command to return the VAT pointer, but it seems like it would be too low level to work with.  You would need to know all the equates to change the type for instance and know how that data structure looks in general to change anything.  Although it would be easy to add, I think it would just require too much assembly knowledge which is what I'm trying to avoid in this project.

If I ever do add it, it would be at the very end of the project where I just add a bunch of "undocumented" instructions (which actually are documented separately) but for assembly programmers who want to do some really low level stuff.
Title: Re: Axe Parser
Post by: ztrumpet on May 25, 2010, 08:00:42 pm
I think that's a good idea (the undocumented idea). :D  I'm glad you're back, but wow, that's a hard test!  Also I think it should be SortA(ptr, size). ;D

Oh, and I really like the VAT Pointer idea. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2010, 08:03:19 pm
Nice idea Quigibo. Personally, once the project is nearly done, I would add those lower level commands, but warn the user that those commands are not necessary to make great Axe programs and they are just for people who got ASM knowledge or wants to go lower level. The main doc part needs to remain for higher level language programmers and as user-friendly as possible.

We also need to keep in mind about people who might accidentally mess things up very bad
Title: Re: Axe Parser
Post by: ztrumpet on May 25, 2010, 08:05:57 pm
Nice idea Quigibo. Personally, once the project is nearly done, I would add those lower level commands, but warn the user that those commands are not necessary to make great Axe programs and they are just for people who got ASM knowledge or wants to go lower level. The main doc part needs to remain for higher level language programmers and as user-friendly as possible.

We also need to keep in mind about people who might accidentally mess things up very bad
Yes.


Oooh, I just had an idea!  Can you have an option in the App to compile with [On] to break hook.  It wouldn't be hard, as TI's already written the routines for this already.  If you used custom interrupts, then you could just chain them.  Could you do this for debugging? ;D
Title: Re: Axe Parser
Post by: Quigibo on May 26, 2010, 03:22:50 am
@ztrumpet The [on] interrupt will come eventually.  But keep in mind that only protects you from infinite loops and NOT from writing data in the wrong places.  Also, it does not allow you to to use your own interrupts in this mode, however, you can still add quitting code in the custom interrupt yourself.


Well, I'm rewriting the way number parsing works.  I have to or else I can't implement some new optimizations.  I'm grouping every single routine that can possibly return a constant into a single read-number routine.  That includes Integers, Hex, Binary, Characters, Tokens(new), Pointers, and everything else.  The goal is to make all expressions that evaluate to constants be single constants, not just pointers.

Now, I ran into some really cool syntax problems.  I was going to include multiplication and division in these optimized routines which can really help sometimes.  For instance, when using *256 coordinates you can type 44*256 to make 44 the coordinate and Axe automatically multiplies this precompile time.  But then I realized there was a slight technical problem with doing this.  What if you typed A/2/2 to do faster division?  Axe would automatically optimize this to A/4 which although it is actually optimized in terms of size, it definitely isn't in terms of speed.

So, I think I will only optimize multiplication and division if the first number is a constant rather than if the first operation is a constant operation.  However, I will still optimize addition and subtraction both ways since you never have these problems with those operations becasue there's no speed loss from grouping individual operations.

This might take a while to re-code a bunch of routines to handle the new method, but I've already done the bulk of it and its turning out pretty good so far.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 26, 2010, 03:28:56 am
will this cause some coding syntax changes? Sounds cool btw.
Title: Re: Axe Parser
Post by: Quigibo on May 26, 2010, 03:36:50 am
Nope.  Only size decreases :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 26, 2010, 03:58:01 am
Cool!
Title: Re: Axe Parser
Post by: ztrumpet on May 26, 2010, 08:07:32 am
Cool! :D
I also like that they'll be a [On] interrupt eventually. :)  Thanks! :D
Title: Re: Axe Parser
Post by: Runer112 on May 27, 2010, 06:37:16 pm
I'm a bit confused about getting GetCalc working to make application variables. When I try to make an application variable, it returns a valid pointer, so it would seem that it was successful. However, when going into the AppVars memory management section, it's not there. And it's more than just not visible in the AppVars. The program checks to see if it exists first so it won't create an AppVar if it already exists, and when I run the program again, it says it doesn't and makes a new one. It seems like it's adding the data for the AppVar to RAM but not properly labeling it, because each time I run the program, the amount of free RAM as reported by memory management does decrease. Can anyone explain what's going wrong?

Code: [Select]
.S S
"S"→Str1
GetCalc(Str1)→P
!If P
GetCalc(Str1,9)→P
End
Title: Re: Axe Parser
Post by: Raylin on May 27, 2010, 07:02:38 pm
You need the prefix "v" in the Str1.

That means it should show this:

Code: [Select]
"vS"->Str1
The v is question is [2nd]+[8].
Title: Re: Axe Parser
Post by: guy6020665 on May 27, 2010, 07:41:58 pm
Is there a way to have Axe programs stay the same speed when transfered from an 83+ to 83+SE or 84+/SE?
Title: Re: Axe Parser
Post by: Eeems on May 27, 2010, 07:43:15 pm
Yes, do not put the Full command in the code and it will always run at 6MHz
Title: Re: Axe Parser
Post by: guy6020665 on May 27, 2010, 07:46:40 pm
I don't have the Full command anywhere in my code, but now that I actually think about it, my Archive space is nearly full would that maybe have something to do with it? Because I sent it to another 83+ and it ran faster on her calc.
Title: Re: Axe Parser
Post by: Runer112 on May 27, 2010, 08:00:04 pm
You need the prefix "v" in the Str1.

That means it should show this:

Code: [Select]
"vS"->Str1
The v is question is [2nd]+[8].

Ah yes, right.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 27, 2010, 11:48:16 pm
I don't have the Full command anywhere in my code, but now that I actually think about it, my Archive space is nearly full would that maybe have something to do with it? Because I sent it to another 83+ and it ran faster on her calc.
Strange, this shouldn't be happening. What is the person's OS? If it's a TI-Nspire, then this is why, though (because the Nspire won't emulate 84+ ASM programs at the right speed)
Title: Re: Axe Parser
Post by: Quigibo on May 28, 2010, 12:02:29 am
Archiving and unarchiving things in your program can change speed depending on the number and size of all the programs in the calculator ram and flash.  Other than that, everything should be the same on regular, non-emulator hardware assuming you didn't use full speed mode.

Also, I highly doubt it, but is it possible she overclocked her calc?
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 28, 2010, 12:15:48 am
When the calc is set to 6 MHz, is it set specifically to 6 MHz directly or is it set to 2.5x lower than its regular speed? (example, if the calc is 15 MHz, it will be set to 6. If it's 20, then it will be set to 8. Is it how it works for overclocked calcs?)

If she didn't overclock it, maybe she got it from someone who did, too.
Title: Re: Axe Parser
Post by: Galandros on May 28, 2010, 04:03:44 pm
Congratulations for the feature and news topic in ticalc.org.

You have strong possibilities of winning a POTY or at least gain many votes. :)
Title: Re: Axe Parser
Post by: SirCmpwn on May 28, 2010, 05:36:05 pm
^
That feature is a bit overdue, but its definitely deserved.
Title: Re: Axe Parser
Post by: TIfanx1999 on May 28, 2010, 07:12:17 pm
Hey congratz!  =D
Title: Re: Axe Parser
Post by: Builderboy on May 28, 2010, 08:07:13 pm
Congratulations on the feature!  Axe is still highest rated program i see :] and with 15 votes thats not too shabby! In fact that it excelent!  Especialy for a 9.88 rated review!  Go Quigibo! :D
Title: Re: Axe Parser
Post by: Quigibo on May 28, 2010, 08:13:30 pm
Hey thanks! I just noticed it now :)  Its especially cool they put the tribute video up there too.
Title: Re: Axe Parser
Post by: Builderboy on May 28, 2010, 08:14:33 pm
I think that might be what convinced them to feature it actualy.  Props to Dj too! :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 28, 2010, 11:13:13 pm
Congrats ^^

Now I hope more cool programs are made with it ^^
Title: Re: Axe Parser
Post by: rvw on May 29, 2010, 09:25:33 pm
Hello,

I just saw Axe on ticalc.org. At the moment I don't have a physical calculator to test with, nor do I have a ROM dump on this machine. My comments are based only on the text in "Documentation.pdf". Here's some feedback on it:

Pointers (page 9)
"The 0th byte has the address 0, the 1st byte has the address 1, all the way up to the last byte with the address 65536."

Minor nit-picking:
Actually, there's no such thing as "the zeroth item"; the correct way to say this would be "the first byte has address zero, the second byte has address one". Not exactly intuitive, I know. If you don't want to change this I can understand.

Actual error:
The last byte has address 65535.

Data & Arrays (page 11)

"Disp {A+GDB1},i"
It might be easier to understand to write "GDB1+A" (assuming that Axe understands this; I didn't check, but assume it does). I understand the current notation is not so much wrong, but it could be unclear for beginning programmers.
Since you are very consistent about this notation, I assume there's a reason for it... performance? Can Axe optimize "A+GDB1" better than it optimizes "GDB1+A"? If so, maybe you should explicitely state both are valid, but "A+GDB1" is slightly faster.

"We use the curly brackets to indicate that we want the byte that's at the address of the pointer, not the the value of the pointer itself."
From reading your code samples:
Disp Str1        Displays the contents of the (probably zero-terminated) string starting at the address in Str1.
Disp {A+GDB1}    Displays the value of the single byte at base address GDB1 incremented with offset A.

That's quite a difference from what you're saying in the documentation...

Data & Arrays (page 11)

The comments for one of the pieces of sample code say "BAISC", oops...

An Example Program (page 14)

You're already using the "optimized dual-store":
0->S-1->D
This hasn't been explained yet and is hardly standard notation. Putting a note "see page 17 for details" would be helpful.

Optimization tricks (page 17)

"Evaluate all constant expressions before compiling."
It would be very awesome if you could teach Axe to recognize expressions working on two constants and automatically decide to pre-compute them...

"If the last line of your program is Return, then remove it. Even if it was part of a subroutine, the return is automatically added at the end for you so there's no need to have 2 returns at the end. Saves 1 byte."
Uhm, that saves 1 byte in the source, not in the executable, right?

And about commands.htm:
Fix CODE: Changes how text is drawn. Code must be a constant.
Wouldn't it make more sense to make CODE consist of flags? That way you can set multiple values at once. Especially useful if you want to reset everything at the end of your code.

ReturnIf EXP
Is there a special reason to include this? It seems to be equivalent to If EXP Return End.


Cool project!
Title: Re: Axe Parser
Post by: meishe91 on May 29, 2010, 11:21:57 pm
Hi, and welcome to Omni.

First thing about the stuff on page 11 that you mentioned. Yes, if you put the constants on the end it will run faster. It is explained in the document or in the Auto Opts document provided. I don't think it really matter though just because it is just in a test program to show the functionality.

Another thing, that should really be in the Axe Pages (http://ourl.ca/4573) thread probably.

I'm sure Quigibo will be along sometime soon to answer your questions and such.
Title: Re: Axe Parser
Post by: Quigibo on May 30, 2010, 12:51:43 am
Pointers (page 9)
Actually, there's no such thing as "the zeroth item"; the correct way to say this would be "the first byte has address zero, the second byte has address one". Not exactly intuitive, I know. If you don't want to change this I can understand.

Actually, in computer science, you really DO start counting at zero so you can have a 0th element as part of a list.  I even put a comic in there that mentions something about that.  Thanks for pointing out the other error though.

It might be easier to understand to write "GDB1+A" (assuming that Axe understands this; I didn't check, but assume it does). I understand the current notation is not so much wrong, but it could be unclear for beginning programmers.
Since you are very consistent about this notation, I assume there's a reason for it... performance? Can Axe optimize "A+GDB1" better than it optimizes "GDB1+A"? If so, maybe you should explicitely state both are valid, but "A+GDB1" is slightly faster.

"We use the curly brackets to indicate that we want the byte that's at the address of the pointer, not the the value of the pointer itself."
From reading your code samples:
Disp Str1        Displays the contents of the (probably zero-terminated) string starting at the address in Str1.
Disp {A+GDB1}    Displays the value of the single byte at base address GDB1 incremented with offset A.

That's quite a difference from what you're saying in the documentation...
To answer your first question, sometimes.  If you are adding an arbitrary number like A+492 or some pointer it won't generally make a difference.  But, certain numbers get automatically optimized (smaller size, faster speed) like A+1 or A-256, there is a big list of these "auto-ops" in the zip file.  My intention is to get the programmer in this habit so they don't have to think about it when optimizing their code.  Maybe I'll mention the reason somewhere there, I do mention it at the end in the optimization section.

About your other point, the first one takes a pointer as an argument, which is why it doesn't need the brackets.  The second one is supposed to have a ▶Dec that I forgot to add, fixed than now thanks.  That takes a number as an argument which is why you need the brackets.

Data & Arrays (page 11)

The comments for one of the pieces of sample code say "BAISC", oops...

An Example Program (page 14)

You're already using the "optimized dual-store":
0->S-1->D
This hasn't been explained yet and is hardly standard notation. Putting a note "see page 17 for details" would be helpful.

Optimization tricks (page 17)

"Evaluate all constant expressions before compiling."
It would be very awesome if you could teach Axe to recognize expressions working on two constants and automatically decide to pre-compute them...

I'm not sure what you're talking about with the "BASIC" thing... EDIT: Nevermind, just noticed the spelling :-[

Thanks for the other tips though.  I'll try to add some more stuff.  And the precompile constants I've actually been working on all this week, it will be in the next release.

"If the last line of your program is Return, then remove it. Even if it was part of a subroutine, the return is automatically added at the end for you so there's no need to have 2 returns at the end. Saves 1 byte."
Uhm, that saves 1 byte in the source, not in the executable, right?

Nope, executable :)  Although eventually I'll remove it automatically when compiling so the programmer doesn't have to bother with it.

And about commands.htm:
Fix CODE: Changes how text is drawn. Code must be a constant.
Wouldn't it make more sense to make CODE consist of flags? That way you can set multiple values at once. Especially useful if you want to reset everything at the end of your code.

ReturnIf EXP
Is there a special reason to include this? It seems to be equivalent to If EXP Return End.

That's actually a really cool suggestion!  Are you suggesting that saying Fix 135 would behave the same as Fix 1:Fix 3:Fix 5 ?  That could work, I like the idea!

The special reason is that its convenient for the programmer and its more optimized in the executable than doing an if statement.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 30, 2010, 01:08:51 am
Hi and welcome to Omnimaga!

To respond to Quigibo, I think what he means with "Also, when you're using free ram, it DOES NOT use any program ram like in BAISC." is that you spelt "BASIC" wrong. :P

To respond to our rvw, I like the Fix idea especially. For optimizations, I think Quigibo is planning this for upcoming versions. There might not be a lot of new commands added for a while but lot of parser-related stuff added.
Title: Re: Axe Parser
Post by: rvw on May 30, 2010, 12:14:20 pm
And about commands.htm:
Fix CODE: Changes how text is drawn. Code must be a constant.
Wouldn't it make more sense to make CODE consist of flags? That way you can set multiple values at once. Especially useful if you want to reset everything at the end of your code.
That's actually a really cool suggestion!  Are you suggesting that saying Fix 135 would behave the same as Fix 1:Fix 3:Fix 5 ?  That could work, I like the idea!
Actually, I was thinking about binary flags. There's two possible ways to do this though...
Option 1: BigText = 1, so passing in any odd number (number with lsb set) will enable BigText while any even number (lsb reset) will automatically enable SmallText.
Option 2: make seperate, independent flags for "opposite options". So BigText = 1, SmallText = 2 (next option = 4, etc.).
Benefits option 1: room for more flags (I have no idea whether this is an issue), possibly more intuitive, probably easier to execute (the internal function which gets called when a programmer uses "Fix" would be smaller and faster).
Benefits option 2: it's possible to set one option without changing (and without knowing the current value of) other options (I don't know whether there are any situations where you'd want to do this).
Which option to choose (1, 2 or the approach you suggested yourself) is something you have to decide, I just wanted to point out the possibilities.

Btw, I understand Axe was developed specifically to be editable on-calc. However, I wonder whether you've thought about making a computer version as well? The data structure (source program) both versions see would be identical, so the port should be pretty straight-forward. (Well, except for the .8xp header, but that's not a big issue; the encoding of the content itself is the same, which makes life far easier.) I'm thinking about developing on-calc, then when you've completed your program (when you have to transfer it to a computer anyway if you intend to share it with more people then just a couple of friends), you pull it through a compiler which really tries hard to optimize things as far as possible, potentially using techniques which are just not suitable for the on-calc compiler.

Pointers (page 9)
Actually, there's no such thing as "the zeroth item"; the correct way to say this would be "the first byte has address zero, the second byte has address one". Not exactly intuitive, I know. If you don't want to change this I can understand.
Actually, in computer science, you really DO start counting at zero so you can have a 0th element as part of a list.
Like I said, it's a minor nit-pick; it's more of a linguistics thing than a technical one. I'm a computer science student myself, the standard example I know is "you have five fingers, with indices 0, 1, 2, 3 and 4. The first has index zero, the second has index one, ..., the fifth (and last) has index four." Essentially, ordinal numbers start at "first" (both in computer science and in general) while cardinal numbers start at zero (at least in computer science). With "ordinal numbers" and "cardinal numbers" I mean the linguistic terms.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 30, 2010, 02:09:50 pm
As said in a recent post in one of the recent threads, I don't think Quigibo is planning a computer compiler until the on-calc version is finished. Otherwise, it will slow down development a lot if he got two versions to update at once.

For now, the only way to program Axe on the computer is to use SourceCoder (http://sc.cemetech.net . Note that you need a forum account there to use it) or some other TI-BASIC editors such as TI-Graph Link, and compile your files using Axe APP on WabbitEmu. Also I think Quigibo will be able to add some optimization routines that will not slow down compiling too much on calc. So far it already optimizes some stuff, yet it compiles my 1 KB programs in one second on a 6 MHz 83+
Title: Re: Axe Parser
Post by: TIfanx1999 on May 30, 2010, 03:59:49 pm
I wonder... if BASIC Builder could be used to package an Axe program into an app?? That could be an interesting work-around.
Title: Re: Axe Parser
Post by: Galandros on May 30, 2010, 04:06:21 pm
I wonder... if BASIC Builder could be used to package an Axe program into an app?? That could be an interesting work-around.
That would be interesting. Someone needs to check.
But I don't remember well if assembly programs were included in BASIC Builder.

Still that is not the same thing as running a true ASM apps.
Title: Re: Axe Parser
Post by: Raylin on May 30, 2010, 04:15:13 pm
Checked.
Tried with both the source and the executable.

BASICBuilder compiles fine.
Running the APP throws back a syntax error.

EDIT: Lies and slander! Hold on to your horses!
EDIT 2: Nope. Still doesn't work. Tried to use a BASIC program to link up the two.
Title: Re: Axe Parser
Post by: Hot_Dog on May 30, 2010, 05:42:23 pm
Thank you Thank you Thank you Thank you THANK YOU for including the ability to copy multiple bytes (like LDIR)!!
Title: Re: Axe Parser
Post by: Raylin on May 30, 2010, 05:48:59 pm
I r confus.
Explain your spasm, sir.
Title: Re: Axe Parser
Post by: Hot_Dog on May 30, 2010, 05:53:43 pm
I r confus.
Explain your spasm, sir.

You understand addresses, I'm assuming.  With axe, you can copy a whole bunch of bytes from one address to another.  For instance, axes allows you to have a picture stored inside of an application variable, and then copy the picture to the buffer from the application variable.  In the same way, you can save a picture to an application variable.
Title: Re: Axe Parser
Post by: Raylin on May 30, 2010, 06:08:00 pm
Awesome! :D
Title: Re: Axe Parser
Post by: Builderboy on May 30, 2010, 06:11:47 pm
Not only can you copy, but you can also fill large portions, and exchange large portions :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 30, 2010, 11:53:25 pm
You mean the Conj() command? Because that command is epic. Fill() too. I used it a lot before.
Title: Re: Axe Parser
Post by: Builderboy on May 30, 2010, 11:56:15 pm
Yeah both of them are soo useful :)  Especially when you use Fill() like this

Fill(5->{L1},700

It can fill a memory location in a single line ^^
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 30, 2010, 11:58:10 pm
does that store 5 in 700 bytes?
Title: Re: Axe Parser
Post by: Builderboy on May 31, 2010, 12:00:17 am
Why yes it does :) It takes advantage of the fact that when you do 5->{L1+5}, the value returned in Ans is not 5, but L1+5
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:10:25 am
Is it possible for the stack to get so filled with embedded subroutine calls that it just fails? Because I have a subroutine call in my main program that subsequently calls many embedded subroutines over and over again, and by the time code execution is at the Return for the original subroutine, the program just stops. I put in a line to display some arbitrary value right before the final Return and right after where it should return to, and the first one displays but the second does not.

The involved code:
Code: [Select]
Repeat K=15
  getKey→K
  If K=49
    sub(D)
    Disp 65502>Dec
    Pause 5000
  End
End

Lbl D
  sub(SO)→{L}r
  conj(P-2,L+2,sub(SL)+2)
  If sub(NS)-{V}≠0
    sub(SS)→T
    {V}→A+1→{V}
    conj(T,sub(SS),sub(AL)-(sub(DS))-(sub(SO)))
    {V}-1→{V}
  Else
    {V}-1→A
  End
  conj({V}*2+V+2→T+2,T,sub(AL)-T-2)
  sub(AL)-(sub(SL)+4→T)→J→{V+2}r
  sub(NS)-1→{V+1}
  A^256→{V}
  conj(V,T+L→T,J)
  GetCalc(Str0,J)→V
  conj(T,V,J)
  sub(L)
  Disp 65501>Dec
  Pause 5000
Return

As you can see, there are over a dozen subroutine calls in this subroutine alone, and many of those subroutines call other subroutines. The subroutines called and what they do aren't really important; none of them overwrite memory sections they shouldn't or have Gotos to break code order or call the original subroutine again. The most damning evidence is that in the end, 65501 will display, but 65502 will not. This doesn't make much sense, as "Disp 65502>Dec" should come immediately after "Disp 65501>Dec" in code execution.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 12:11:14 am
Why yes it does :) It takes advantage of the fact that when you do 5->{L1+5}, the value returned in Ans is not 5, but L1+5
aaah ok awesome ^^
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 12:26:49 am
@Runer

Axe doesn't have restrictions on this other than the 150 individual label names.  Its more of a hardware limitation.  I think the stack size is like 400 bytes or something although I have no idea really I'm basically making up this number.  Anyone actually know?

It sounds more like you have a memory leak on the programming side than on the parser side.  Double check that all the subroutines end in Return and that you aren't using goto between subroutines or trapping recursive subroutines, I don't know if you're using those.  Also, it could be some other command that is not subroutine related that is causing it to freeze.
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:30:02 am
@Runer

Axe doesn't have restrictions on this other than the 150 individual label names.  Its more of a hardware limitation.  I think the stack size is like 400 bytes or something although I have no idea really I'm basically making up this number.  Anyone actually know?

It sounds more like you have a memory leak on the programming side than on the parser side.  Double check that all the subroutines end in Return and that you aren't using goto between subroutines or trapping recursive subroutines, I don't know if you're using those.

As I said, the problem can't be with the subroutines called or what they do. None of them leak memory (they never did before the addition of this subroutine call, and using a lot of displays at the end of this subroutine, I could determine that all variables and such have the same values they had at an earlier point in the program, which worked correctly) , use Gotos, etc. If they did, the program execution would never reach the last few lines of the original subroutine called, "Disp 65501>Dec," and it does. However, it doesn't reach the lines that should run immediately after the return, like "Disp 65502>Dec."
Title: Re: Axe Parser
Post by: Builderboy on May 31, 2010, 12:30:54 am
well maybe you can post your code so we can actualy see what is going on.  Its possible there might be something you are missing, or hardware thats going wrong
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:32:19 am
well maybe you can post your code so we can actualy see what is going on.  Its possible there might be something you are missing, or hardware thats going wrong

Good luck, even with some explanatory comments:
Code: [Select]
.SPREDIT Sprite Editor

.PIXEL SPRITES
.5x5
[F8F8F8F8F8000000]→Pic1
.3x3
[E0E0E00000000000]
.2x2
[C0C0000000000000]

.BLANK SPRITE
[0000000000000000000000000000000000000000000000000000000000000000]→Pic0

.HEX KEYS
∆List(33,34,26,18,35,27,19,36,28,20,47,39,31,46,38,30)→GDB1

.HEX TEXT
"0123456789ABCDEF"→Str1

.APPVAR NAME
"vSPREDIT"→Str0

.HELP TEXT
"2ND:  INVERT PIXEL"→Str00
"ARROW KEYS:  MOVE CURSOR"→Str01
"0-F:  HEX INPUT"→Str02
"DEL/STAT:  HEX NAVIGATION"→Str03
"F2:  NEW 8X8 SPRITE"→Str04
"F3:  NEW 16X16 SPRITE"→Str05
"+/-:  CHANGE OPEN SPRITE"→Str06
"CLEAR:  EXIT"→Str07

sub(I)
  .Disp {V}>Dec
  .Disp {V+1}>Dec
  .Disp {V+2}>Dec
  .Disp i
  .Disp {V+3}>Dec
  .Disp {V+4}>Dec
  .Disp {V+5}>Dec
  .Disp i
  .Disp {V+6}>Dec
  .Disp {V+7}>Dec
  .Disp {V+8}>Dec
  .Disp i
  .Disp {V+9}>Dec
  .Disp {V+10}>Dec
  .Disp {V+11}>Dec
  .Disp i
  .Disp {V+12}>Dec
  .Disp {V+13}>Dec
  .Disp {V+14}>Dec
  .Disp i
  .Disp {V+15}>Dec
  .Disp {V+16}>Dec
  .Disp {V+17}>Dec
  .Pause 10000
.<MAIN LOOP>
Repeat K=15

  getKey→K

  .KEYPAD CHECK
  sub(K)

  .HELP CHECK
  If K=53
    ClrDraw
    Fix 0
    Str00→{L₁}ʳ
    Str01→{L₁+2}ʳ
    Str02→{L₁+4}ʳ
    Str03→{L₁+6}ʳ
    Str04→{L₁+8}ʳ
    Str05→{L₁+10}ʳ
    Str06→{L₁+12}ʳ
    Str07→{L₁+14}ʳ
    For(A,0,7)
      Text(0,A*8,{A*2+L₁}ʳ)
    End
    DispGraph
    Repeat getKey≠0
    End
    sub(L)
  End

  .CHANGE SPRITE
  If K=10 and (sub(NS)≠{V})
    {V}+1→{V}
    sub(L)
  End

  If K=11 and ({V)≠1)
    {V}-1→{V}
    sub(L)
  End

  .NEW 8X8 SPRITE
  If K=52
    8sub(N)
  End

  .NEW 16X16 SPRITE
  If K=51
    16sub(N)
  End

  .DELETE SPRITE
  If K=49 and (sub(NS)≠1)
    sub(D)
    Disp 65502>Dec
    Pause 5000
    sub(L)
  End

  .CHANGE PIXEL CHECK
  If K=54
    sub(IP)
  End

  0→H

  .HEX MOVE FORWARD CHECK
  If K=32
    0→D
    3→K
    3-X^4→W
    For(A,0,W)
      If sub(K)=0
        65533→Z
        sub(MC)
      End
    End
    1→D
    sub(DG)
  End

  .HEX BACK UP CHECK
  If K=56
    0→D
    2→K
    X-1^4→W
    For(A,0,W)
      sub(K)
    End
    1→D
    sub(DG)
  End

  16→H

  .HEX ENTRY CHECK
  For(A,0,15)
    If K={GDB1+A}
      A→H
    End
  End

  .HEX ENTRY EXECUTION
  If H≠16
    0→D
    3→K
    H→N
    0-(X^4)→Z
    sub(MC)
    For(A,0,3)
      A+4sub(GB)sub(SP)
      If sub(K)=0
        65533→Z
        sub(MC)
      End
    End
    1→D
    sub(DG)
    16→H
  End

End

.<EXIT CLEANUP>
ClrDraw
DispGraph
Fix 0
Fix 4
Fix 6
Archive Str0

.<SUBROUTINES>
.CHECK IF CAN MOVE CURSOR
Lbl K
  If K=3 and (X+Y≠14 or (S=16 and (Q≠3)))-(K=2 and (X+Y≠0 or (S=16 and (Q≠0))))→Z or (K=1 and (Y≠7 or (S=16 and (Q≤1)))-(K=4 and (Y≠0 or (S=16 and (Q≥2))))→θ)→M
    sub(MC)
  End
  M
Return

.CHECK IF DISPGRAPH NEEDED
Lbl DG
  If D≠0
    sub(UH)
    If S=8
      0→E
      56→F
    Else
      65→E
      16→F
    End
    sub(PH)
    Output(0,0)
    DispGraph
  End
Return

.UPDATE HEX
Lbl UH
  If S=8
    For(A,0,7)
      conj(A+22*12+10+L†,A+P,1)
    End
  Else
    For(J,0,1)
      For(T,0,1)
        For(A,0,7)
          conj(J*8+A*12+T+9+L†,J*2+T*8+A+P,1)
        End
      End
    End
  End
Return

.PRINT HEX
Lbl PH
  For(A,0,sub(SL)-1)
    If Q*8+Y=A
      X≥4+254→I
    End
    {A+P}sub(BH)
    If Q*8+Y=A
      A*2+(X≥4)→I
    End
  End
  If S=8
    I*6→E
    56→F
    For(J,0,95)
      Pxl-Off(J,55)
    End
  Else
    I^8*4+65→E
    I/8*6+16→F
    Line(64,0,64,63)
    For(J,0,3)
      J*12+16→T
      Line(64,T,95,T)
    End
  End
  If E≠0
    Line(E-1,F,E-1,sub(CS)+F+5)
  End
  For(J,0,sub(CS)+4)
    If E+J>0 and (E+J≤96)
      Pxl-On(E+J-1,S=16*7+F-1)
    End
  End
Return

.BYTE TO PRINTED HEX
Lbl BH
  →B
  B/16+Str1sub(PC)
  If I≥254
    I-1→I
  End
  B^16+Str1sub(PC)
Return

.PRINT CHARACTER
Lbl PC
  →U
  If I=254
    Fix 3
  End
  If S=16*3+90≠E
    Text(E,F,{U}>Frac)
  Else
    If S=8
      For(J,0,sub(CS)+5)
        pxl-Test(91-(sub(CS)),F+J)→{J+L₁}
      End
      Text(91-(sub(CS)),F,{U}>Frac)
      For(J,0,sub(CS)+5)
        For(T,0,sub(CS)+3)
          If pxl-Test(94-T,F+J) xor pxl-Test(95-T,F+J)
            Pxl-Change(95-T,F+J)
          End
        End
        If {J+L₁} xor pxl-Test(91-(sub(CS)),F+J)
          Pxl-Change(91-(sub(CS)),F+J)
        End
      End
    Else
      Text(66,1,{U}>Frac)
      For(J,0,5)
        For(T,0,3)
          If pxl-Test(69-T,J+1) xor pxl-Test(96-T,F+J) and (T≠0)
            Pxl-Change(96-T,F+J)
          End
          Pxl-Off(69-T,J+1)
        End
      End
    End
  End
  If I=254
    Fix 2
  End
  S=8*2+E+4→E
  If 93-(sub(CS))<E
    S=16*65→E
    sub(CS)+F+6→F
  End
Return

.MOVE CURSOR
Lbl MC
  sub(DC)
  If S=8
    If X+Z→X=8
      0→X
      Y+1→Y
    End
    If X=65535
      7→X
      Y-1→Y
    End
  Else
    If X+Z→X=8
      0→X
      If H=16
        Q+1→Q
        If sub(QX)=0
          If Y+1→Y=8
            0→Y
          Else
            Q-2→Q
          End
        End
      Else
        If Y+1→Y=8
          0→Y
          Q+1→Q
        End
      End
    End
    If X=65535
      7→X
      If H=16
        Q-1→Q
        If sub(QX)≠0
          If Y-1→Y=65535
            7→Y
          Else
            Q+2→Q
          End
        End
      Else
        If Y-1→Y=65535
          7→Y
          Q-1→Q
        End
      End
    End
  End
  If Y+θ→Y=8
    0→Y
    Q+2→Q
  End
  If Y=65535
    7→Y
    Q-2→Q
  End
  sub(DC)
  sub(DG)
Return

.DRAW CURSOR
Lbl DC
  If S=8
    Pxl-Change(X*6+4,Y*6+4)
  Else
    Pxl-Change(sub(QX)+X*4+1,sub(QY)+Y*4+1)
  End
Return

.INVERT PIXEL
Lbl IP
  If S=8
    Pt-Change(X*6+2,Y*6+2,Pic1)
    Pt-Change(X*2+57,Y*2+18,Pic1+16)
    Pxl-Change(X+80,Y+22)
  Else
    Pt-Change(sub(QX)+X*4,sub(QY)+Y*4,Pic1+8)
    Pxl-Change(sub(QX)+X+72,sub(QY)+Y)
  End
  sub(DG)
Return

.SET PIXEL
Lbl SP
  If =1 xor (sub(PT))
    sub(IP)
  End
Return

.PIXEL TEST
Lbl PT
  If S=8
    pxl-Test(X+80,Y+22)
  Else
    pxl-Test(sub(QX)+X+72,sub(QY)+Y)
  End
Return

.GET BIT
Lbl GB
  →B
  N→O
  For(C,1,7-B)
    O/2→O
  End
  O^2
Return

.SET BIT
.Lbl SB

.Return

.CONVERT QUADRANT TO X
Lbl QX
  Q=1 or (Q=3)*8
Return

.CONVERT QUADRANT TO Y
Lbl QY
  Q≥2*8
Return

.CHARACTER SIZE MODIFIER
Lbl CS
  S=8*2
Return

.LOAD SPRITE
Lbl L
  ClrDraw
  0→D
  sub(DS)+(sub(SO))+V+2→P
  Fix 0
  Fix 3
  Text({V}<10*4+81→A,0,{V}>Dec)
  Fix 2
  If A≠81 or ({P-2}=8)
    Line(A-1,0,A-1,6)
  End
  Line(A,6,87,6)
  For(J,0,6)
    conj(J*12+10+L†→A,A+1,1)
    conj(Pic0,A,1)
  End
  If {P-2}=8
    sub(8)
    0→J
  Else
    sub(16)
    3→J
  End
  For(Q,0,J)
    For(Y,0,7)
      sub(LR)
      For(X,0,7)
        If sub(PT)
          sub(IP)
        End
      End
      sub(LR)
    End
  End
  1→D
  sub(IV)
  sub(DC)
  sub(DG)
Return

.LOAD SPRITE ROW
Lbl LR
  conj(Q*8+Y+P,S=8*22+(sub(QY))+Y*12+(sub(QX)≠0)+(S=8)+9+L†,1)
Return

.NEW SPRITE
Lbl N
  →S
  sub(DS)→J
  sub(NS)+1→{V+1}
  sub(NS)→{V}
  conj(V,L₁,sub(AL))
  J+L₁→O
  If sub(AL)-J→C≠0
    conj(O+C-1,O+C+1,C)ʳ
  End
  C→{O}ʳ
  S→{sub(AL)+L₁+2→C}
  2→{C+1}
  conj(Pic0,C+2,sub(SL))
  GetCalc(Str0,sub(AL)+(sub(SL))+4→T)→V
  T→{L₁+2}ʳ
  conj(L₁,V,T)
  sub(L)
Return

.DELETE SPRITE
Lbl D
  sub(SO)→{L₁}ʳ
  conj(P-2,L₁+2,sub(SL)+2)
  If sub(NS)-{V}≠0
    sub(SS)→T
    {V}→A+1→{V}
    conj(T,sub(SS),sub(AL)-(sub(DS))-(sub(SO)))
    {V}-1→{V}
  Else
    {V}-1→A
  End
  conj({V}*2+V+2→T+2,T,sub(AL)-T-2)
  sub(AL)-(sub(SL)+4→T)→J→{V+2}ʳ
  sub(NS)-1→{V+1}
  A^256→{V}
  conj(V,T+L₁→T,J)
  .Disp {T}>Dec
  .Disp {T+1}>Dec
  .Disp {T+2}>Dec
  .Disp i
  .Disp {T+3}>Dec
  .Disp {T+4}>Dec
  .Disp {T+5}>Dec
  .Disp i
  .Disp {T+6}>Dec
  .Disp {T+7}>Dec
  .Disp {T+8}>Dec
  .Disp i
  .Disp {T+9}>Dec
  .Disp {T+10}>Dec
  .Disp {T+11}>Dec
  .Disp i
  .Disp {T+12}>Dec
  .Disp {T+13}>Dec
  .Disp {T+14}>Dec
  .Disp i
  .Disp {T+15}>Dec
  .Disp {T+16}>Dec
  .Disp {T+17}>Dec
  .Disp i
  .Disp J>Dec
  .Pause 10000
  GetCalc(Str0,J)→V
  conj(T,V,J)
  .ClrDraw
  .ClrHome
  .Output(0,0)
  .Disp {V}>Dec
  .Disp {V+1}>Dec
  .Disp {V+2}>Dec
  .Disp i
  .Disp {V+3}>Dec
  .Disp {V+4}>Dec
  .Disp {V+5}>Dec
  .Disp i
  .Disp {V+6}>Dec
  .Disp {V+7}>Dec
  .Disp {V+8}>Dec
  .Disp i
  .Disp {V+9}>Dec
  .Disp {V+10}>Dec
  .Disp {V+11}>Dec
  .Disp i
  .Disp {V+12}>Dec
  .Disp {V+13}>Dec
  .Disp {V+14}>Dec
  .Disp i
  .Disp {V+15}>Dec
  .Disp {V+16}>Dec
  .Disp {V+17}>Dec
  .Disp i
  .Disp J>Dec
  .Pause 10000
  Disp 65501>Dec
  Pause 5000
Return

.NUMBER OF SPRITES
Lbl NS
  {V+1}
Return

.APPVAR LENGTH
Lbl AL
  {V+2}ʳ
Return

.SPRITE LENGTH
Lbl SL
  If S=8
    8
  Else
    32
  End
Return

.SPRITE OFFSET
Lbl SO
  {{V}*2+V+2}ʳ
Return

.SPRITE START
Lbl SS
  sub(DS)+(sub(SO))+V
Return

.ALL SPRITE DATA START
Lbl DS
  sub(NS)*2+4
Return

.INITIALIZE 8X8 SPRITE EDITING
Lbl 8
  Fix 1
  sub(IV)
  8→S
  Line(0,0,50,0)
  Line(50,0,50,50)
  Line(50,50,0,50)
  Line(0,50,0,0)
  Line(55,16,74,16)
  Line(74,16,74,35)
  Line(74,35,55,35)
  Line(55,35,55,16)
  Line(78,20,89,20)
  Line(89,20,89,31)
  Line(89,31,78,31)
  Line(78,31,78,20)
Return

.INITIALIZE 16X16 SPRITE EDITING
Lbl 16
  Fix 0
  sub(IV)
  16→S
  Line(70,0,70,15)
  Line(89,{V}≥10*7,89,15)
Return

.INITIALIZE POSITION VARIABLES
Lbl IV
  0→Q→X→Y
Return

.PRIMARY INITIALIZATION
Lbl I
  DiagnosticOff
  Full
  Fix 5
  Fix 7
  UnArchive Str0
  !If GetCalc(Str0)→V
    GetCalc(Str0,4)→V
    ∆List(0,0,4r)→GDB0
    conj(GDB0,V,4)
    8sub(N)
  Else
  sub(L)
  End
  0→K
Return

.<VARIABLES>
.A=temp
.B=bit number (bit subroutine use)
.C=temp
.D=DispGraph needed
.E=text x position
.F=text y position
.H=hex entry
.I=invert character marker
.J=temp
.K=getKey
.M=can move
.N=number input to bit subroutines
.O=bit subroutine temp
.P=pointer to working sprite
.Q=quadrant
.R=sprite number overlay timer
.S=sprite size
.T=temp
.U=text
.V=pointer to appvar
.W=temp x position
.X=x position
.Y=y position
.Z=change in x position
.θ=change in y position

The problematic situation occurs when sub(D) is called here (the only place it is called) and does not return:
Code: [Select]
 .DELETE SPRITE
  If K=49 and (sub(NS)≠1)
    sub(D)
    Disp 65502>Dec
    Pause 5000
    sub(L)
  End

As I said, the last lines of sub(D) execute properly, and seeing as I had no problems with any of the code called in sub(D) before, I don't think the code called is the problem.
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 12:40:43 am
What you're describing is exactly a subroutine problem.  What happened is that there was probably a "push without a pop" somewhere in the code so that by the time it get to the return, it has changed the stack order becasue something else was pushed, hopefully a label and not a number since Axe doesn't allow you to use the stack directly, and so it is actually returning not to the place from where it was called but some other place instead, or a random location if a number got pushed.

I would recommend a more thorough debugging.  Try this: Disp Asm(E1E5)>Dec,i Put it at the beginning of the subroutine and then again at the end.  If the numbers displayed are not the same number, you have a leak somewhere.  The difference between the numbers divided by 2 tells you how many levels off you are.
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:41:45 am
What should I look for as possible causes of a leak? I don't have any Gotos, so I know that can't be it.

EDIT: The two "Disp Asm(E1E5)>Dec" commands don't return the same value :(

EDIT 2: Working down the exact line that messes up the stack. And yes DJ Omnimaga, I know how the stack works with pushing and popping.

EDIT 3: Found the exact line. Checking out all the values in it now.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 12:44:36 am
Quigibo, it would be nice to maybe describe what involves pushing/poping and the stack when it comes to Axe code, because it is ASM stuff that isn't referenced in the Axe manual, so it might be confusing to Axe programmers that doesn't know ASM.
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 12:48:24 am
Quigibo, it would be nice to maybe describe what involves pushing/poping and the stack when it comes to Axe code, because it is ASM stuff that isn't referenced in the Axe manual, so it might be confusing to Axe programmers that doesn't know ASM.
As I said before, Axe doesn't allow you do use the stack unless you use your own assembly code, that's why I never mention it.

Runer, are the numbers off by 2 or by a lot?  Try putting it in your other subroutines and see if you narrow down the one that changes it.
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:50:03 am
Runer, are the numbers off by 2 or by a lot?  Try putting it in your other subroutines and see if you narrow down the one that changes it.

Off by a lot. I have it down to a specific line now, it's a conj() line so it could definitely be the culprit.

EDIT: Well there's your problem, the conj() size is supposed to be fairly small but it's over 4000.

EDIT 2: FIXED IT  ;D ;D ;D Thanks for the stack inspection assembly code Quigibo, that helped a lot.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 12:52:33 am
But you mentionned it a few post ago, which is why I asked D:
there was probably a "push without a pop" somewhere in the code so that by the time it get to the return, it has changed the stack order becasue something else was pushed, hopefully a label and not a number since Axe doesn't allow you to use the stack directly, and so it is actually returning not to the place from where it was called but some other place instead, or a random location if a number got pushed.
I got confused there, considering Axe doesn't use the stack, yet you mention his code might be doing stuff to it. Or is push/pop something that has nothing to do with the stack?
Title: Re: Axe Parser
Post by: Builderboy on May 31, 2010, 12:57:30 am
Hah, wow if that isnt spaghetti code i dont know what it ;D I was jumping around with the find button to see if any of the Lbls called eachother in a loop or something.  Sometimes i was jumping around for 8 or more Lbls before i got to an end :P
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 12:58:29 am
Hah, wow if that isnt spaghetti code i dont know what it ;D I was jumping around with the find button to see if any of the Lbls called eachother in a loop or something.  Sometimes i was jumping around for 8 or more Lbls before i got to an end :P

Well more embedded subroutines certainly makes it nastier, but it saves space ;)
Title: Re: Axe Parser
Post by: _player1537 on May 31, 2010, 12:58:56 am
basically, pushing/popping means this: (hope I do a good job) the calculator has a stack of hex numbers (like the ones you would recieve by doing "{L1}(r)" ) and when you "push" you are putting a numbers values onto the stack, like HL (or the main numbers you are using in axe).  HL get put onto the stack and saved for later use (like when you reach a "pop") when you pop it off the stack, it gets put in the place of whatever register (read: HL, the main number again) so that you can use it for math some more, however popping it off the stack gets rid of the number that was on it, so you can't continually pop and pop, or else you will run the stack down, and get the equivilent of a segfault (iirc) and the calc will crash.  I probably got ninja'd but oh well
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 12:59:21 am
Whenever you call a subroutine, you "push" the place its supposed to return to into the stack so it knows where to go back to in the code when it reaches the Return, which then "pops" the stack.  Also, I wasn't sure at the time of writing if he did use any assembly code which is why I was explaining it at a lower level.

Glad you found the error :)
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 01:01:38 am
Whenever you call a subroutine, you "push" the place its supposed to return to into the stack so it knows where to go back to in the code when it reaches the Return, which then "pops" the stack.  Also, I wasn't sure at the time of writing if he did use any assembly code which is why I was explaining it at a lower level.

Glad you found the error :)

When I'm finished with it I'll make sure to post my project. It's a really nice (albeit BIG) sprite editor that can store multiple sprites of either 8x8 or 16x16, and has support for hex entry and live hex display. :) That messed up subroutine was the delete sprite subroutine. After that I'll probably want to add move/copy commands and it'll pretty much be done. Until I get grayscale working.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 01:02:59 am
I would rather use a lot of subroutines if I am gonna re-use pieces of code several times and it can save space. Otherwise, there's a lot of repetitive code.

Without sub-routines and sub-programs, stuff like this (http://www.ticalc.org/archives/news/articles/14/146/146343.html) would be impossible. :P


Whenever you call a subroutine, you "push" the place its supposed to return to into the stack so it knows where to go back to in the code when it reaches the Return, which then "pops" the stack.  Also, I wasn't sure at the time of writing if he did use any assembly code which is why I was explaining it at a lower level.

Glad you found the error :)
aaah ok, thanks for explaining. Makes more sense now ^^

Quote
When I'm finished with it I'll make sure to post my project. It's a really nice (albeit BIG) sprite editor that can store multiple sprites of either 8x8 or 16x16, and has support for hex entry and live hex display
I,m glad you fixed it. Can't wait to see it in action :)

Also glad to see more and more Axe coders. I guess it was a good thing I work on that video x.x
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 01:31:25 am
Sprite deleting works now :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 01:42:00 am
Nice ^^

Feel free to start a new thread for your project btw, since it might easily get lost in this topic in a week or two (due to the high post rate) :P
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 01:51:26 pm
I'm just going to post this here for people who want to post more accurate-looking code. These are special characters to better represent calculator symbols:

Code: [Select]

L₁
L₂
L₃
L₄
L₅
L₆
θ
∆List



·



²
ʳ
▸Frac
▸Dec
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 01:57:15 pm
I generally just use SourceCoder, but it can screw up small 2,3,4, etc for list tokens.
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 02:01:19 pm
I just use TI's program editor that came with older versions of TI Connect 8)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 02:03:09 pm
Oh yeah that one, I never tried it personally so I can,t tell. In my early calc programming days, we used TI-Graph Link

Personally I prefer programmign on the calc, though. I type faster on it when programming in BASIC or Axe :P
Title: Re: Axe Parser
Post by: ztrumpet on May 31, 2010, 02:05:26 pm
Oh yeah that one, I never tried it personally so I can,t tell. In my early calc programming days, we used TI-Graph Link

Personally I prefer programmign on the calc, though. I type faster on it when programming in BASIC or Axe :P
I do the exact same thing. :D
(If only I got graphlink to work at home... )
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 02:15:32 pm
I like using TI ProgramEditor for a few reasons. Firstly, the program is always stored on your computer and you don't have to worry about it's safety. Secondly, running it through an emulator that you don't have any important data on and that can't become damaged is always nice. Thirdly, you can view indented code much more easily, which I always do to make the program more understandable. Fourthly, there's no taking a minute to scroll from one part to another in massive programs, which is helpful for projects such as the monstrous sprite editor I'm working on now, the compiled code of which just passed 7,000 bytes. Finally, it's easy to move around code. This often comes in handy when I realize I perform certain actions multiple times in the program and that I could save space by instead making that code into a subroutine and just calling it from those multiple places.

EDIT: In response to DJ's post below me, you know it only takes all of like 3 seconds to drag and drop the file to the emulator. :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 31, 2010, 02:17:38 pm
It probably depends of opinions. Personally I always liked to be able to almost instantly try my program rather than having to send it to an emu all the time. Again, it might be due to the fact the first 2.5 years I've programmed for calcs, I had no computer at home so I got used to program on calc.

That said, the long scrolling and the risks of RAM clears can be a bit annoying, though.
Title: Re: Axe Parser
Post by: Runer112 on May 31, 2010, 03:51:48 pm
What is the best way to go about resizing an AppVar but not losing the data that was in it before? I'm pretty sure that the pointer to an AppVar doesn't necessarily stay the same between re-initializations, so I just copy all the data to L₁ and then copy it back to the new pointer, but that will end badly if the AppVar becomes larger than the free RAM at L₁.
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 04:02:34 pm
Create the new appvar first, copy the old one to the new one, then delete the old one.  It works as long as the appvars are much smaller than the 24k of user ram, which they should be.  You can always check to make sure the appvar was created successfully before copying by making sure the pointer is not null.
Title: Re: Axe Parser
Post by: Quigibo on May 31, 2010, 07:01:49 pm
IMPORTANT UPDATE!

Unfortunately, or fortunately depending on how you look at it, one of the new optimizations will change the way you optimize your code.  When saving to a pointer at a static location, the return value will now be the value stored rather than the address that is being saved to.  This rule does NOT apply to locations with variable addresses like {A} or {B+L1+8}, those will remain the same as before.  Its when you save to pointers like {L1+4} or {Str1-16} that this will affect.   Both 1 byte and 2 byte storage are affected the same way.

The advantages vastly outweigh the inconveniences however.  Realize that after this release, saving to static addresses will have the EXACT SAME efficiency and code size as saving to a regular variable.  {L1+9}r+1->{L1+9}r for instance will be the same size code as A+1->A in the executable.  That saves about 4 bytes for every time you read a static pointer and 3 bytes every time you save to one.  The speed increase might be noticeable too if you use these in loops a lot.

If you still want to do tricks like this: Fill(0->{L1},100)  You can still write Fill(0->{L1}rL1,100) and it should be the same sized code in the executable.  The double byte storage is actually smaller and faster than single byte storage when using static locations by the way.  Just making sure I warn everyone first before anyone panics if their executable doesn't work right in the next version.  This is the second wave of major optimizations and the first REAL look-ahead parsing with actual backtracking and I've still got many more to go.
Title: Re: Axe Parser
Post by: Hot_Dog on May 31, 2010, 07:11:20 pm
Can you read from an archived appvar using axe?
Title: Re: Axe Parser
Post by: calc84maniac on May 31, 2010, 08:00:28 pm
No you can't, unfortunately. I've been thinking it could be a good idea to have some file reading functions that work regardless of whether it is located in Archive or RAM. The way I'm thinking it could work is that you open a file for reading, and it internally stores a pointer and page number. Then you would call the file read functions, which could read a byte, read two bytes, or copy a chunk of data (given the offset from the beginning of the file).
Title: Re: Axe Parser
Post by: Quigibo on June 01, 2010, 12:55:51 am
I wish there were more tokens for this, its too bad there aren't many intuitive ones that could work for this purpose.

I am hoping that later in development, there will be an option to install an "Axe Language" pack which changes token names to more intuitive namings so then I won't have these restrictions.  You can then disable them if you need to use the calc for math and BASIC programming.  It seems very possible since there are already apps out there that change the tokens to other languages like Spanish or French.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 01, 2010, 02:37:51 am
The update seems nice, altough I don't really get it much, still x.x

Could you give an example of code that will require to be changed after the update? I mean, post the code compatible with Axe 0.2.5 and how it should be written for Axe 0.2.6.

Unless I am misunderstanding your post?

So far I have never used any static pointer location, though, so even if your update changes some syntax when using static pointers, it shouldn't make much differences for my current programs.

Can't wait for the update, though ^^
Title: Re: Axe Parser
Post by: calcdude84se on June 01, 2010, 06:00:27 pm
It wouldn't change the actual bytes, just how the tokens look. If you've ever played around with the language localization apps, you'll notice that you can switch between languages and your programs will be fine.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 01, 2010, 07:35:27 pm
I think language apps also does something like Omnicalc fonts. With the German/Deusthce app, one of the char changes to a weird german-B-like char
Title: Re: Axe Parser
Post by: ztrumpet on June 01, 2010, 07:41:52 pm
I think this important update is a great idea.  Keep up the awesome work Quigibo! ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 02, 2010, 12:32:45 am
Darn that 3D racing game was epic ^^

Nice update Quigibo!
Title: Re: Axe Parser
Post by: Raylin on June 02, 2010, 12:48:21 am
How do you use the interrupts?
Title: Re: Axe Parser
Post by: Builderboy on June 02, 2010, 12:51:53 am
There doesnt seem to be any documentation on them o.O for now all i can see is use with the Stop command

Also that 3D game kicks Ass ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 02, 2010, 01:02:48 am
I am wondering too XD

I assume it will use the code from a sub-routine in particular, providing it's a certain size maximum, right? (I think it gets copied to L1 or something, if I recall correctly)
Title: Re: Axe Parser
Post by: Quigibo on June 02, 2010, 01:04:18 am
Thanks!  I made the game in about 4 hours when I was bored, which I think is pretty good because it would have taken much much longer if it was in assembly.  I figured that since so many other people used Axe to made a tunnel clone, I would do the same... only differently.

The interrupt commands are fairly useless right now.  All of them are 1 byte each and so the Stop command is really efficient for quick pauses.  Each one is around a Pause 40ish and you can do :Stop:Stop:Stop:Stop up to about 8 times I think and still be less bytes than the normal pause command.  Make sure you have enabled interrupts first!

EDIT: By the way, is the new version working right for everyone's code?  I only tested it with the example programs, they all seem to work, but since I rewrote so many routines there is bound to be something I missed.  Just want to make sure I didn't make any stupid mistakes before I update the one on ticalc.
Title: Re: Axe Parser
Post by: Builderboy on June 02, 2010, 01:08:22 am
I dont think the routine is copied into L1, i think that was for something like a vector table or something?  I dont remember, not sure if its right :P
Title: Re: Axe Parser
Post by: Quigibo on June 02, 2010, 01:11:26 am
Oh no, no!  These aren't custom interrupt routines (im 2)!  These are the OS interrupts (im 1), they don't do much as you can see right now, but they will come in handy when I do add custom interrupt support.
Title: Re: Axe Parser
Post by: Builderboy on June 02, 2010, 01:14:47 am
ah i see, thanks for clarifying :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 02, 2010, 01:15:18 am
I tried with Axe Tunnel and it seems to work pretty well, Quigibo. Also It seems to no longer do the 65535 bytes thing in MirageOS anymore.
Title: Re: Axe Parser
Post by: Silver Shadow on June 02, 2010, 02:45:30 am
I just noticed that in 0.2.6 you mention turning on and off interrupts, but you never actually explain how to create one.
Title: Re: Axe Parser
Post by: Builderboy on June 02, 2010, 03:42:30 am
That's what I thought.  So yes, you can use that optimization.  So you can do things like 2->{1->{L6}+1} but the code can get pretty crazy looking really fast.

:( so this is changed after all?
Title: Re: Axe Parser
Post by: Quigibo on June 02, 2010, 03:49:17 am
Yes, but the way it optimizes now, its actually more optimized to type it normally than it was doing it the "optimized" way before :)

1->{L6}
2->{L6+1}

Doing this is only 12 bytes now.

2->{1->{L6}+1}

This used to be more than 20 bytes I think in the old version.

EDIT: actually, you can do this now that I think about it:

1->{L6}+1->{L6+1}

That's only 10 bytes!
Title: Re: Axe Parser
Post by: Silver Shadow on June 02, 2010, 01:14:24 pm
And what about interupts?
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 02, 2010, 01:21:48 pm
From what I could understand, the interrupt commands currently implemented simply pauses your program for a while, but I couldn't understand much better. Basically no custom interrupt code support yet
Title: Re: Axe Parser
Post by: ztrumpet on June 02, 2010, 05:01:22 pm
I like the updates!  Once I rearrange the stuff on my calcs (after my math and chem exams) I'll finally be able to work with Axe again.  It's been too long, and I know I've missed Axe. ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 02, 2010, 11:44:02 pm
(as long as you don't kill Elmgon :P)
Title: Re: Axe Parser
Post by: jsj795 on June 02, 2010, 11:49:39 pm
Quick question about Axe... Is there any way to make a timer within a game that is consistent (which means even if the game is using heavy processing power, like updating the screen with multiples of sprites)?
Or do I have to wait for the custom interrupt to be implemented?
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 03, 2010, 01:27:43 am
For that I am afraid you'll need to use interrupts (when custom ones are supported)
Title: Re: Axe Parser
Post by: LordConiupiter on June 03, 2010, 04:53:36 pm
I don't know exactly what is the reason for it, but my program that started within a second with version 0.2.5, now takes 2 seconds to startup. is this perhaps because of the interrupts? of could it be so because of I start my program with a pretty complex for-loop? Has that become slower?
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 03, 2010, 05:36:28 pm
This is strange, this shouldn't be happening I think.
Title: Re: Axe Parser
Post by: Quigibo on June 03, 2010, 07:02:42 pm
I don't know exactly what is the reason for it, but my program that started within a second with version 0.2.5, now takes 2 seconds to startup. is this perhaps because of the interrupts? of could it be so because of I start my program with a pretty complex for-loop? Has that become slower?

Are you unarchiving something at the start of the program?  Garbage collecting can make it go much faster if archiving/unarchiving begins to slow down over time.
Title: Re: Axe Parser
Post by: yoman82 on June 04, 2010, 03:00:19 pm
Has anyone mentioned a Memcheck utility yet?
Title: Re: Axe Parser
Post by: guy6020665 on June 04, 2010, 04:43:26 pm
Is it possible to do multiple continuous AI's for say 3-4 computer characters in axe?

I'm asking because i'm thinking of making a game with multiple computer characters for the contest
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 04, 2010, 05:36:25 pm
Has anyone mentioned a Memcheck utility yet?
Do you mean something to display the free RAM and archive on the screen, for example, or check to make sure there are enough RAM?
Title: Re: Axe Parser
Post by: yoman82 on June 05, 2010, 04:20:45 pm
Yep, that's what I'm curious about.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 05, 2010, 05:29:56 pm
I would really like to know. For archive, I am thinking about a way at the moment, because I think I saw where archive is stored in the RAM. I need to test, though.
Title: Re: Axe Parser
Post by: Runer112 on June 07, 2010, 05:16:27 pm
I remember Quigibo mentioning a while ago that statements like "If A" may not work in some situations any more. Why was this again?
Title: Re: Axe Parser
Post by: yoman82 on June 07, 2010, 05:17:31 pm
Uh-oh... That could bork a lot of stuff.
Title: Re: Axe Parser
Post by: Quigibo on June 07, 2010, 05:43:48 pm
I remember Quigibo mentioning a while ago that statements like "If A" may not work in some situations any more. Why was this again?

I didn't end up doing that since my logic was flawed.
Title: Re: Axe Parser
Post by: Hot_Dog on June 07, 2010, 06:21:41 pm
I don't understand what I'm doing wrong, but the calculator doesn't seem to read values from my appvar called Human1.  I know that my application variable has the values 17, 17 and 17 put together, but the calculator is not detecting this, probably because of something I'm doing wrong.  Here's some crude code:

Code: [Select]
For(A,0,65333)
Output(1,1,A->Dec)
{A}->B
{A+1}->C
{A+2}->D
If B=17 and C=17 and D=17
Disp 4999->Dec
End
End

The application variable is in RAM.
Title: Re: Axe Parser
Post by: FinaleTI on June 07, 2010, 06:25:27 pm
Are you correctly locating the pointer of the appvar? Perhaps if you did GetCalc("vHuman1")->A, you would get the correct pointer and then you shouldn't have any problems getting the correct data.

Edit: Forgot the "v" in the appvar reference.
Title: Re: Axe Parser
Post by: cooliojazz on June 07, 2010, 06:25:59 pm
Well i don't think theres is any order of operations at all besides straight left to right. so maybe try changing
If B=17 and C=17 and D=17
to
If B=17 and (C=17) and (D=17)
Title: Re: Axe Parser
Post by: Hot_Dog on June 07, 2010, 07:22:21 pm
Ah, that would do it
Title: Re: Axe Parser
Post by: nemo on June 07, 2010, 09:52:40 pm
EXP1·EXP2
EXP1+EXP2
EXP1☐EXP2

Returns respectively the bitwise "and", "or", and "xor" of the two expressions. These are the plot style tokens.

can someone explain to me how these work?
Title: Re: Axe Parser
Post by: Runer112 on June 07, 2010, 11:02:59 pm
EXP1·EXP2
EXP1+EXP2
EXP1☐EXP2

Returns respectively the bitwise "and", "or", and "xor" of the two expressions. These are the plot style tokens.

can someone explain to me how these work?

These compare each bit in EXP1 individually against the bit in the same location in EXP2. Some examples follow.


255 (00FFh, 0000000011111111b) and 43690 (AAAAh, 1010101010101010b) = 170 (00AAh, 0000000010101010b)

      0000000011111111b
and 1010101010101010b
      0000000010101010b

255 (00FFh, 0000000011111111b)  or  43690 (AAAAh, 1010101010101010b) = 43775 (AAFFh, 1010101011111111b)

      0000000011111111b
or   1010101010101010b
      1010101011111111b

255 (00FFh, 0000000011111111b)  xor 43690 (AAAAh, 1010101010101010b) = 43605 (AA55h, 1010101001010101b)

      0000000011111111b
xor  1010101010101010b
      1010101001010101b

Title: Re: Axe Parser
Post by: meishe91 on June 07, 2010, 11:03:46 pm
What is the third equation? The symbol is a square.
Title: Re: Axe Parser
Post by: calc84maniac on June 07, 2010, 11:19:09 pm
It's a square on the calculator, too :)
Title: Re: Axe Parser
Post by: meishe91 on June 07, 2010, 11:29:55 pm
There is a square symbol O.O I mean I knew there was a solid black character but I didn't think it was accessible. Unless this is something completely different :P

It just looked like one of the squares that displays when a character can't be shown, that's why I asked :P
Title: Re: Axe Parser
Post by: calc84maniac on June 07, 2010, 11:31:50 pm
It's the little square that is used in Stat Plots. You can get it from 2nd+PLOT or the catalog.

Edit: Actually, all three of these symbols are found there.
Title: Re: Axe Parser
Post by: Builderboy on June 07, 2010, 11:39:01 pm
you can access it from the catalogu, it looks like a small (3x3) black box.  You can also access all 3 of these tokens by pressing [2nd] [Y=] and then go over to [Mark] (note you have to be editing a program)

EDIT: Ninja'd :P
Title: Re: Axe Parser
Post by: meishe91 on June 07, 2010, 11:40:54 pm
Oh! It's those tokens. I thought the first to were multiplication and addition :P Now I know which ones. Thanks :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 08, 2010, 01:38:46 am
Could anyone explain a scenario in which that stuff might be useful in a game? I know what it does but I am just curious how useful it can be?
Title: Re: Axe Parser
Post by: Builderboy on June 08, 2010, 01:49:54 am
Mmm using these expressions as opposed to the normal AND OR and XOR is going to be doing some fairly advanced optimizations, so its difficult to say for sure.  For now we will probably just be using them to set, erase, and toggle bits inside of 2 byte numbers.
Title: Re: Axe Parser
Post by: cooliojazz on June 09, 2010, 02:12:29 pm
Ok, I have this code:
Code: [Select]
.APFIND
ClrHome
{є9830}→H
Disp H►Dec
Repeat getKey:End
ClrHome

Lbl ML
7→C

Lbl FL
ReturnIf getKey(15)
{є982E}→D
If H(>/<)D:Goto D:End

(More code which doesnt matter cause it always executes that line ^^)

Lbl D
Disp H►Dec
Disp D►Dec
Now the problem is, that first part always is showing H as 61.  But, that goto statement ALWAYS executes regardless if I put < or >. I put <, and the second time it shows H, it'll show 61. (D is 102) If I put > though, It'll show up as 65389.  Any help to why this is happening...
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 09, 2010, 02:16:24 pm
THis is strange. I thought H > and < shouldn't update the variables used in it x.x
Title: Re: Axe Parser
Post by: ztrumpet on June 09, 2010, 02:36:59 pm
Could anyone explain a scenario in which that stuff might be useful in a game? I know what it does but I am just curious how useful it can be?
I think they're most useful when dealing with binary numbers or sprites. :)
Title: Re: Axe Parser
Post by: Runer112 on June 09, 2010, 03:34:15 pm
This isn't exactly relating to Axe Parser, but I figure this would be a place where people might be able to answer my question: Is there any way to retrieve a compiled program from Wabbitemu? I'd normally use my physical calculator but I can't manage to get the link to work any more.
Title: Re: Axe Parser
Post by: calcdude84se on June 09, 2010, 03:36:06 pm
in the newer versions, under the calculator menu, there is a "variables" menu item. Find your program, and drag and drop to the desktop, or wherever you want it.
Title: Re: Axe Parser
Post by: Runer112 on June 09, 2010, 03:59:54 pm
Ah thank you, I saw the variables command before but I figured that was talking about actual variables like A, B, C.
Title: Re: Axe Parser
Post by: SirCmpwn on June 09, 2010, 04:01:00 pm
Programs are people, too.
Title: Re: Axe Parser
Post by: Happybobjr on June 09, 2010, 06:12:54 pm
Programs are people, too.

may i add this to my list of amazing quotes?
Title: Re: Axe Parser
Post by: SirCmpwn on June 09, 2010, 07:21:47 pm
Of course.
Title: Re: Axe Parser
Post by: Runer112 on June 09, 2010, 10:28:00 pm
I'm just checking, because I thought somebody said this a while ago... can a program archive itself at the beginning of execution? And if so, what's a good way to make sure it exits in the same status as it began? With a variable?
Title: Re: Axe Parser
Post by: Quigibo on June 09, 2010, 10:37:31 pm
@cooliojazz
I'm not sure what those addresses you're reading from are, maybe the ones to get the free ram?  Those would be 16-bit numbers, not bytes so you have to read them with the r modifier at the end to get the whole thing.  I'm guessing that should fix the error.

@Runner112
Yes and Yes.
Title: Re: Axe Parser
Post by: ztrumpet on June 09, 2010, 10:39:54 pm
can a program archive itself at the beginning of execution?
A basic program cannot archive itself when it's running, but an Asm program could possibly pull it off, just make sure it wouldn't write back over the original location.  It would probably be unstable, though, so I'd try to stay away from it. :)
Of course, before you take my word as "100% true", let's let an actual Asm programmer respond. ;D

Edit: Ninja'd.
Title: Re: Axe Parser
Post by: Runer112 on June 09, 2010, 10:40:15 pm
To figure out a program's starting status in/out of archive, you can use GetCalc(), right? Will turn up 0 if archived and anything else if not?
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 09, 2010, 11:17:25 pm
It will return 0 if archived (or missing)
Title: Re: Axe Parser
Post by: Raylin on June 11, 2010, 08:56:47 am
[offtopic]Axe Parser 0.3.0 needs to come out so I can actually start my contest entry.[/offtopic]
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 11, 2010, 09:38:35 am
I think he's extremly busy with school finals.

I personally don't expect a release until maybe like next week up to maybe middle of July in worst cases (if somehow he finishes school at the very end of June like some people), or even September if he leaves in vacation somewhere without internet access for all Summer long afterward. 0.2.6 might be what we have to do with for the remainder of the contest, this is something we need to keep in mind.

Also there has been more and more bugs arising since the past version or so it seems. He might have broken something in the parser when changing the math stuff or adding features to the compiler, that he needs to check for and this might take quite a while to fix.
Title: Re: Axe Parser
Post by: Quigibo on June 11, 2010, 04:11:06 pm
Next release will be around Wednesday June 16 if all goes as planned.  Yes, I am extremely busy with finals.  I probably won't log on here much until Monday.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 11, 2010, 07:20:24 pm
Aaah ok. Good luck!
Title: Re: Axe Parser
Post by: ztrumpet on June 11, 2010, 10:20:13 pm
Yes, I am extremely busy with finals.
Good luck with finals. :)
Title: Re: Axe Parser
Post by: cooliojazz on June 11, 2010, 10:41:10 pm
@Quigibo Even though you are correct, it does need to be both bytes for the correct value, that doesnt change the fact that H is different between those two times without me changing it... And no, that is not the places to get free ram...
Title: Re: Axe Parser
Post by: squidgetx on June 15, 2010, 04:50:20 pm
Quick question on text displaying:

Code: [Select]
"XXXXX     ZZZZZZ    YYYYYYY   "->Str1
"XXXXX     "->Str2
While 1
getkey->K
A+(K=3)-(K=2)->A
conj(A*10+Str1,Str2,10
Text(30,30, Str2
End
This displays the proper string, but with random garbage characters afterwards, ie, "XXXXX eoppp"
I tried putting in Fill(Str2+9, 32) after the conj( line to overwrite possible garbage in Str2 with spaces, but with no success. Any thoughts?
Title: Re: Axe Parser
Post by: Quigibo on June 15, 2010, 05:03:56 pm
Hmmm... I tested it and it works for me.  Are you sure Str2 is exactly 10 characters?  Maybe you mistyped it.
Title: Re: Axe Parser
Post by: calc84maniac on June 15, 2010, 05:08:49 pm
Quick question on text displaying:

Code: [Select]
"XXXXX     ZZZZZZ    YYYYYYY   "->Str1
"XXXXX     "->Str2
While 1
getkey->K
A+(K=3)-(K=2)->A
conj(A*10+Str1,Str2,10
Text(30,30, Str2
End
This displays the proper string, but with random garbage characters afterwards, ie, "XXXXX eoppp"
I tried putting in Fill(Str2+9, 32) after the conj( line to overwrite possible garbage in Str2 with spaces, but with no success. Any thoughts?
You didn't initialize A...
Title: Re: Axe Parser
Post by: Quigibo on June 15, 2010, 05:11:30 pm
Yeah, I don't think that was his real code since its an infinite loop on top of that.  I initialized A and changed the "While 1" to "Repeat getkey(15)" when I tested this I should mention.
Title: Re: Axe Parser
Post by: squidgetx on June 15, 2010, 10:12:56 pm
Are you sure Str2 is exactly 10 characters?  Maybe you mistyped it.
there we go...I missed it by one and I guess it messed things up
you guys are right, that's only a boiled down version of my actual code but I actually use infinite loops a lot while working on a project since in Mirage I can always just exit using OnMode lol
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 15, 2010, 10:22:23 pm
Are you sure Str2 is exactly 10 characters?  Maybe you mistyped it.
OnMode
wow didn't even know that and I used Mirage for almost a decade x.x

Is it safe, though?
Title: Re: Axe Parser
Post by: Quigibo on June 15, 2010, 10:28:47 pm
As long as you have interrupts enabled, and don't write data over the L2 free ram, then its safe to use.  But it doesn't save you from buffer overflows or corrupting ram of course.

What I'm curious about is the opposite.  If you disable interrupts, can you use L2 ram area in mirage? (All the DispGraph routines re-enable interrupts so immediately disable them after those).
Title: Re: Axe Parser
Post by: calc84maniac on June 15, 2010, 10:31:49 pm
As long as you have interrupts enabled, and don't write data over the L2 free ram, then its safe to use.  But it doesn't save you from buffer overflows or corrupting ram of course.

What I'm curious about is the opposite.  If you disable interrupts, can you use L2 ram area in mirage? (All the DispGraph routines re-enable interrupts so immediately disable them after those).
Yeah, that sounds right. By the way, if you want, you can add some simple code to preserve interrupt state. Having interrupts enabled for even one microsecond can cause disasters.

Start your routine with this:
ld a,i
push af
di

and end it with this:
pop af
ret po
ei
ret
Title: Re: Axe Parser
Post by: Quigibo on June 15, 2010, 10:42:13 pm
Oh wow!  That's really cool!  I totally forgot about the "ld a,i" instruction, I was about to ask if it was possible to preserve interrupt state.  This seems to be a good way to do it.  Its 6 more bytes I think, but it will surely come in handy when I add custom interrupt support; Just in case someone decides to draw to the screen in their interrupt routine.
Title: Re: Axe Parser
Post by: ztrumpet on June 16, 2010, 11:04:00 am
Oh, wow!  I'd never heard of On + Mode.  That should help me if I get infinite loops in Mirage. :D

Calc, how does this line work?
ret po
Thanks. ;D
Title: Re: Axe Parser
Post by: calcdude84se on June 16, 2010, 11:39:24 am
ztrumpet: when you do "ld a,i" or "ld a,r" the content of the iff1 flip-flop (which tells whether or not interrupts are disabled) is put into the p flag. So, if interrupts were previously disabled, this line returns. If they were enabled, the next two lines enable interrupts then return.
Title: Re: Axe Parser
Post by: Quigibo on June 17, 2010, 01:27:59 am
Okay, first thing, Axe Tokens.  Enable and disable them with Alpha+Vars.  If the screen flashes, you know they have been toggled.  The current token remapping is this:

Code: [Select]
conj <-> Copy
Expr <-> Exch
SinReg <-> Freq
det <-> Zeros
int <-> sign
>Frac <-> >Char
deltalist <-> Data
Repeat <-> Until
Tangent <-> Bitmap

Let me know if you all like it.  I might decide to make it  quote unquote 'Mandatory'.  Like the code would be pretty unreadable without it.

I modified my RPG demo to use subroutines if you want to look at it.  Basically, you call it with up to 6 arguments and then in the subroutines, the arguments turn into r1 through r6.  Do not use subroutines with arguments in subroutines with arguments otherwise there could be conflicts since they all share these values.  While these new variables can be used outside of subroutines, it is discouraged because they get erased every time you call a subroutine with arguments.

EDIT: Oops, I just realized I accidentally switched Fill( with Zeros( instead of det(.  I'm releasing another version soon to fix stupid typos like this.  I think that will be the pattern from now on.  Big improvements followed by corrections.  I'll wait to see what other corrections need to be made first of course.
Title: Re: Axe Parser
Post by: Magic Banana on June 17, 2010, 01:32:41 am
Axe Parse 0.3.0 just came out.

Title: Re: Axe Parser
Post by: calc84maniac on June 17, 2010, 01:40:06 am
Ooh, base 2 logarithm/exponent can be useful for a simple floating-point implementation.

Come to think of it, to improve the usefulness of fixed-point values (see: sin/cos), you should make an alternate multiplication routine, "**", to multiply two numbers but return the top 16 bits of the 32-bit result. Currently, there is no easy way to do that.
Title: Re: Axe Parser
Post by: Quigibo on June 17, 2010, 01:45:50 am
Ooh, base 2 logarithm/exponent can be useful for a simple floating-point implementation.

Come to think of it, to improve the usefulness of fixed-point values (see: sin/cos), you should make an alternate multiplication routine, "**", to multiply two numbers but return the top 16 bits of the 32-bit result. Currently, there is no easy way to do that.

That's a good idea.  Design me a little routine and I'll add it.  I'm not sure how to approach it :)
Title: Re: Axe Parser
Post by: Raylin on June 17, 2010, 01:46:14 am
A little more explanation on your Tangent command please?
Title: Re: Axe Parser
Post by: Quigibo on June 17, 2010, 01:49:13 am
Ah yes, the good ol' bcall(_DisplayImage)

Here is how you use it.  Define the sprite like this:
Data(height,width)->Pic1
[row1]
[row2]
...
[last row]

Then, when you want to display the sprite:
Tangent(X,Y,Pic1)
Title: Re: Axe Parser
Post by: calc84maniac on June 17, 2010, 01:50:40 am
Is width in pixels or bytes? If it's not a multiple of 8 pixels, do you pad the last byre?
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 17, 2010, 01:56:30 am
wow nice to see new versions out! I may not use the new tokens personally since I am already used to the old ones, but other people might do. I also hope both the old and new tokens are documented in future versions so people used to the old one won't get confused
Title: Re: Axe Parser
Post by: Raylin on June 17, 2010, 02:15:02 am
This new version of Axe is officially epic!

Now, to just figure out how to animate those sprites in the new format...
Title: Re: Axe Parser
Post by: Runer112 on June 17, 2010, 03:47:11 am
2 questions:


EDIT: Actually, 3 questions:


EDIT AGAIN: Nevermind about that third question, just noticed you added extra Fix commands for that.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 17, 2010, 04:09:46 am
Question regarding Tangent, Is it set to automatically draw to the screen by default unlike the rest of the drawing commands? And if it is, why so?
Title: Re: Axe Parser
Post by: Quigibo on June 17, 2010, 04:16:32 am
TI sets it up for displaying to the screen by default.  I wish they had chose the buffer since that's more useful, oh well.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 17, 2010, 04:22:26 am
I see, but why the tangent function in Axe in particular? I think I am misunderstanding what's the goal of tangent totally.

Is Tangent() used to display sprites larger than 8x8? If so, then if TI sets tangent to display to the screen by default, why doesn't this happen with your 8x8 routine? Texas Instruments definitively makes no sense at all... (like how stuff drawn on the home screen seems to update without DispGraph)
Title: Re: Axe Parser
Post by: Magic Banana on June 17, 2010, 04:53:01 am
I think he picked Tangent() because he ran out of graphing tokens and that was left. I think that it draws an X by Y sprite wherever on the screen and you just tell it (not exactly sure how though) the rows and columns of the sprite and then just give it the hex for whatever you want to draw. I'm still confused on how to exactly use this, so some clarification would be nice.
Title: Re: Axe Parser
Post by: Quigibo on June 17, 2010, 05:09:17 am
The Tangent() command uses an OS bcall which is much slower than the 8x8 sprite drawing routines, but its still fast enough for most things and more convenient than drawing a bunch of 8x8s and it takes up hardly any memory in the program.  Because its an OS routine, they decide how the flags affect it so I really can't do anything about that other than tell you to change the flags with the Fix commands.

Also, I know it clips the sprites, but the documentation for that command (_DisplayImage) says that you cannot draw the image totally off the screen for some reason.  I don't know if that means it will corrupt ram or something so use with caution if you draw completely off screen.

Oh another thing, I should mention.  It uses Pt-Off() logic to draw the sprite.  That is, it erases behind it as it draws.
Title: Re: Axe Parser
Post by: meishe91 on June 17, 2010, 05:17:58 am
Could you give a short example of how it works? Like a legitimate Axe code one, not pseudo-code. I just don't quite understand how to use it.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 17, 2010, 09:01:02 am
The Tangent() command uses an OS bcall which is much slower than the 8x8 sprite drawing routines, but its still fast enough for most things and more convenient than drawing a bunch of 8x8s and it takes up hardly any memory in the program.  Because its an OS routine, they decide how the flags affect it so I really can't do anything about that other than tell you to change the flags with the Fix commands.

Also, I know it clips the sprites, but the documentation for that command (_DisplayImage) says that you cannot draw the image totally off the screen for some reason.  I don't know if that means it will corrupt ram or something so use with caution if you draw completely off screen.

Oh another thing, I should mention.  It uses Pt-Off() logic to draw the sprite.  That is, it erases behind it as it draws.
mhmm I see. Thanks for the info. Would it be slower to use a Tangent() with 16x16 sprites than a for() loop with 4 8x8 Pt-Off() sprites?
Title: Re: Axe Parser
Post by: yoman82 on June 17, 2010, 04:18:54 pm
Great work, I love the new tokens thing. Any chance of integrated TIBASIC in the next version?
Title: Re: Axe Parser
Post by: calc84maniac on June 17, 2010, 04:20:37 pm
The Tangent() command uses an OS bcall which is much slower than the 8x8 sprite drawing routines, but its still fast enough for most things and more convenient than drawing a bunch of 8x8s and it takes up hardly any memory in the program.  Because its an OS routine, they decide how the flags affect it so I really can't do anything about that other than tell you to change the flags with the Fix commands.

Also, I know it clips the sprites, but the documentation for that command (_DisplayImage) says that you cannot draw the image totally off the screen for some reason.  I don't know if that means it will corrupt ram or something so use with caution if you draw completely off screen.

Oh another thing, I should mention.  It uses Pt-Off() logic to draw the sprite.  That is, it erases behind it as it draws.
mhmm I see. Thanks for the info. Would it be slower to use a Tangent() with 16x16 sprites than a for() loop with 4 8x8 Pt-Off() sprites?
It probably would be slower -- this is TI-OS we're talking about.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 17, 2010, 11:44:11 pm
Aaah ok. Well I think I will most likely use regular sprites, unless I'm really low on memory
Title: Re: Axe Parser
Post by: Hot_Dog on June 18, 2010, 12:13:07 am

Also, I know it clips the sprites, but the documentation for that command (_DisplayImage) says that you cannot draw the image totally off the screen for some reason.  I don't know if that means it will corrupt ram or something so use with caution if you draw completely off screen.



As I recall, the RAM, or at the very least the screen RAM, is corrupted.  Incidentally, does it take a lot of memory to write an any-size sprite routine?  I know it's not true when there's no clipping, but I don't know when there's clipping involved.
Title: Re: Axe Parser
Post by: guy6020665 on June 18, 2010, 11:25:17 pm
Is there a way to rewrite pictures files with axe because i get an error when i try something like this

Code: [Select]
If getkey(1)
[0000000000000000->Pic1
end
If getkey(2)
[FFFFFFFFFFFFFFFF->Pic1

By the way the above code is only an example
Title: Re: Axe Parser
Post by: Raylin on June 18, 2010, 11:28:47 pm
Nope. Those kind of variables are static pointers.
Once you write data in them, they stay that way.
Title: Re: Axe Parser
Post by: meishe91 on June 19, 2010, 12:01:23 am
Ya, what Raylin said is right. What you can do however is something like

Code: [Select]
[FFFFFFFFFFFFFFFF
0000000000000000]→Pic1
If getKey(1)
0→A
End
If getKey(2)
8→A
End
Pt-On(0,0,Pic1+A

Obviously not the best method but a general idea, hopefully.
Title: Re: Axe Parser
Post by: nemo on June 19, 2010, 09:49:09 am
optimized:
Code: [Select]
0→A
[0000000000000000→Pic1
[FFFFFFFFFFFFFFFF
Pt-On(0,0,getKey(2)*8→A+Pic1

Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 10:40:42 am
Random question: are Pauses in clock cycles? For example, would a Pause 500 halt execution of everything for 499 clock cycles?
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 10:47:54 am
Most likely. I noticed a huge difference in pauses when going between 6 and 15mhz while testing my programs.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 10:48:24 am
was it like 2-2.5x faster or even faster?

On my 83+ there are things that won't necessarly go just 2.5x slower. For example, when exiting Axe parser, there is a 2 seconds pause.
Title: Re: Axe Parser
Post by: calc84maniac on June 19, 2010, 10:52:59 am
was it like 2-2.5x faster or even faster?

On my 83+ there are things that won't necessarly go just 2.5x slower. For example, when exiting Axe parser, there is a 2 seconds pause.
Eh, it seems that Quigibo is unarchiving the AxeData appvar and rearchiving it every time you run the app. Quigibo, does it really need to be archived? It just holds a couple of options...
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 10:55:32 am
Yeah, I'd say it's about 2-2.5x faster in Full for whatever pause you set it to.

Yeah, I've had the Axe parser take a little bit to exit. Usually garbage Collecting gets things back up to speed.
If it's really bogging down your calc, you can delete the App and just transfer it again. I noticed that seems to speed up the parsing time. It seems to me like the more it's used, it slows down just a little bit, but after you clean some stuff, it goes right back to speed.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 11:05:02 am
was it like 2-2.5x faster or even faster?

On my 83+ there are things that won't necessarly go just 2.5x slower. For example, when exiting Axe parser, there is a 2 seconds pause.
Eh, it seems that Quigibo is unarchiving the AxeData appvar and rearchiving it every time you run the app. Quigibo, does it really need to be archived? It just holds a couple of options...
woops I didn't see that. X.x. IMHO it might be best if it was left unarchived. I sure don't mind re-enabling lowercase manually and setting up the shell again when going back in the APP next time.
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 11:09:32 am
^Yeah, I'd be fine with that too. I just leave it on no-shell all the time anyway. Besides, I already have like 3 other programs for enabling lowercase, so it wouldn't be a problem.
Title: Re: Axe Parser
Post by: meishe91 on June 19, 2010, 12:33:08 pm
optimized:
Code: [Select]
0→A
[0000000000000000→Pic1
[FFFFFFFFFFFFFFFF
Pt-On(0,0,getKey(2)*8→A+Pic1



Oh, I wasn't aware you could use getKey like that. So I'm guessing it returns a one if it is pressed and a zero otherwise?
Title: Re: Axe Parser
Post by: Quigibo on June 19, 2010, 12:36:22 pm
was it like 2-2.5x faster or even faster?

On my 83+ there are things that won't necessarly go just 2.5x slower. For example, when exiting Axe parser, there is a 2 seconds pause.
Eh, it seems that Quigibo is unarchiving the AxeData appvar and rearchiving it every time you run the app. Quigibo, does it really need to be archived? It just holds a couple of options...

This is true I forgot about that.  I think I will only unarchive/archive at the end from now on if you actually changed any options.

EDIT: And pauses are directly proportional to clock cycles.  However each number on the pause is around 3350 clock cycles I believe.
Title: Re: Axe Parser
Post by: nemo on June 19, 2010, 12:38:22 pm
meishe91: i'm not sure it'll work all the time under every circumstance, but my snippet of code works. (of course if you add in a dispgraph)
Title: Re: Axe Parser
Post by: meishe91 on June 19, 2010, 12:46:46 pm
meishe91: i'm not sure it'll work all the time under every circumstance, but my snippet of code works. (of course if you add in a dispgraph)

Ah ya, I was just referring to how you are using getKey as a test statement that returns one or zero. Ya, I also realized that we need the DispGraph :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 01:01:04 pm
was it like 2-2.5x faster or even faster?

On my 83+ there are things that won't necessarly go just 2.5x slower. For example, when exiting Axe parser, there is a 2 seconds pause.
Eh, it seems that Quigibo is unarchiving the AxeData appvar and rearchiving it every time you run the app. Quigibo, does it really need to be archived? It just holds a couple of options...

This is true I forgot about that.  I think I will only unarchive/archive at the end from now on if you actually changed any options.

EDIT: And pauses are directly proportional to clock cycles.  However each number on the pause is around 3350 clock cycles I believe.
mhmm that would mean Pause 1000 is approximately 3350000 clock cycles?
Title: Re: Axe Parser
Post by: Quigibo on June 19, 2010, 01:04:59 pm
Well, think about it this way:  What does 6MHz stand for?  That's 6,000,000 cycles per second so 3,350,000 clock cycles in a command that should take around a second seems very reasonable.
Title: Re: Axe Parser
Post by: calc84maniac on June 19, 2010, 01:06:18 pm
3,350,000 sounds more like half a second...
Title: Re: Axe Parser
Post by: Quigibo on June 19, 2010, 01:07:54 pm
Well, I'm assuming that the interrupts are taking up the extra time then.

EDIT: actually, I just used a stopwatch, half a second per 1000 on the pause seems a lot closer.
Title: Re: Axe Parser
Post by: SirCmpwn on June 19, 2010, 01:09:35 pm
I've noticed that there are problems with Pause on Full, did you factor that into the Pause command?
Maybe it would be more accurate to DI beforehand.
Title: Re: Axe Parser
Post by: calc84maniac on June 19, 2010, 01:12:01 pm
I've noticed that there are problems with Pause on Full, did you factor that into the Pause command?
Maybe it would be more accurate to DI beforehand.
Perhaps that should be left to the user. getKey won't detect keys pressed during a Pause if interrupts are disabled.
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 01:18:11 pm
I've noticed that there are problems with Pause on Full, did you factor that into the Pause command?
Maybe it would be more accurate to DI beforehand.

Well since Pause is just in clock cycles, couldn't you just do something like Pause X and if Full then 2.5X->X?
Title: Re: Axe Parser
Post by: SirCmpwn on June 19, 2010, 01:18:58 pm
Maybe, if 2.5 worked in Axe :P j/k
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 01:20:32 pm
Oh yeah :P
Be creative.
5/2*X?

EDIT:wait a second. I might have to think about this one ...
Title: Re: Axe Parser
Post by: SirCmpwn on June 19, 2010, 01:20:55 pm
X*10/25
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 01:23:52 pm
X/2+2X is pretty close.:)
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 01:24:23 pm
Well, think about it this way:  What does 6MHz stand for?  That's 6,000,000 cycles per second so 3,350,000 clock cycles in a command that should take around a second seems very reasonable.
So Pause 6000 would take a second on 83+ and 0.4 on SE?
/me is confused with all those numbers ;D (I guess it doesn't matter much, since we can simply trial and error until it's at the speed we want)
Title: Re: Axe Parser
Post by: Quigibo on June 19, 2010, 01:25:54 pm
First of all the proper number is X*15/6.  Second of all, I would never do this becasue its a complete waste of code.  Instead, you can do "Pause 2000*15/6" for an equivalent 2000 timed pause in 15MHz mode since Axe precompiles constants now.
Title: Re: Axe Parser
Post by: SirCmpwn on June 19, 2010, 01:25:55 pm
X/2+2X is pretty close.:)
X*25/10 is exact :)
Title: Re: Axe Parser
Post by: Magic Banana on June 19, 2010, 01:28:55 pm
I think Pause 6000 is like 3 seconds on 83+ and a little over 1 on SE.

X/2+2X is pretty close.:)
X*25/10 is exact :)

Lemme just ... yep. Mine works for even numbers only. Whoops. That one works for everything.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 19, 2010, 07:30:31 pm
Mhmm

Quote
SetupEditor is no longer needed or supported.

This function is still intact in the command list.

Also I noticed it still says 0.2.5 in the doc at the top of every page in the PDF.

Just small details I wanted to point out :P
Title: Re: Axe Parser
Post by: Quigibo on June 20, 2010, 02:31:43 am
Although I didn't exactly keep my promise that I would have a toggle in the parser to have both token spellings, it was only becasue I didn't have time to make a new graphical menu to handle this and I wanted to release it tonight instead of waiting until tomorrow when I'm going to be busy.  However, you can still toggle it simply by removing the dot in the header as the screenshot shows.

The application compiling betas are coming shortly.  They will be emailed in the next hour.  If you don't get an email, you will just have to wait until 0.3.2 which will have the feature assuming there aren't any major problems with my current routines.

Let me know what you think of the new features  :)

EDIT: Actually I found one more bug with the error scrolling I'm going to try to fix so you might have to re-download 0.3.1.  Betas will take a little longer becasue of this.
Title: Re: Axe Parser
Post by: Builderboy on June 20, 2010, 02:34:20 am
That token changing is magnificent!  The fact that all the tokens are tied to that one character, and it manages to update the tokens correctly when you change the data... outstanding, i have no idea how that would be done XD I will have to play with this a lot :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 20, 2010, 03:26:47 am
Yeah I saw this and it was quite cool. Btw your program was rather small. Does it supports instant goto? I couldn't notice since it didn't need to go down very far.

Nice to see a new update, though, good luck fixing the issue and with app compiling.
Title: Re: Axe Parser
Post by: Quigibo on June 20, 2010, 05:50:46 am
Its a really strange bug that I can't seem to understand.  It appears to be something wrong with the OS bcalls.  It doesn't scroll to the correct location when the programs are too large.  I can't really see where the limit is right now, but its at least 6kb but probably closer to 10kb.  It has nothing to do with the asm executable limit since the source is not being executed and is simply being read, so that isn't the problem.  I'll have to figure this out later.

And yes, the scrolling should be instant now.  I had to fix that too.

Betas coming now.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 20, 2010, 11:25:35 am
Aaah ok. Good luck on the bug
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 21, 2010, 02:32:02 am
Little question. Is it safe to draw sprites extremly far on the screen? I tried and past 256 it seemed to loop back, but I was curious if crashes could occur?
Title: Re: Axe Parser
Post by: _player1537 on June 21, 2010, 02:35:38 am
I think what axe does is take the X and mod it by 256, ie X^256.  AFAIK it should not make any crashes.
Title: Re: Axe Parser
Post by: ztrumpet on June 21, 2010, 09:50:26 am
Nice update Quigibo! :D
Title: Re: Axe Parser
Post by: Hot_Dog on June 21, 2010, 10:08:47 am
Well, I'm assuming that the interrupts are taking up the extra time then.

EDIT: actually, I just used a stopwatch, half a second per 1000 on the pause seems a lot closer.

What would happen if you used interrupts themselves for timing?  For instances, have a little counter in the interrupt section, and everytime you have an interrupt, increase the counter, and then when the counter reaches a certain number, that's a second?
Title: Re: Axe Parser
Post by: calc84maniac on June 21, 2010, 10:12:12 am
Well, I'm assuming that the interrupts are taking up the extra time then.

EDIT: actually, I just used a stopwatch, half a second per 1000 on the pause seems a lot closer.

What would happen if you used interrupts themselves for timing?  For instances, have a little counter in the interrupt section, and everytime you have an interrupt, increase the counter, and then when the counter reaches a certain number, that's a second?
We could probably do that once he adds support for custom interrupt routines. Until then, we can use the Stop command to do an interrupt-based delay and save power, too :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 21, 2010, 12:10:18 pm
custom interrupts, even if they are small, would be very cool ^^

One concern I have, though: what would happen if Freq/Sinreg was used in interrupts, though?
Title: Re: Axe Parser
Post by: Magic Banana on June 22, 2010, 08:23:31 pm
Quick question.

How exactly is Getkey(0) supposed to be used? When I try to store it into a variable, it turns up being some number between ~240 - 255, with no patterns whatsoever in it.
Title: Re: Axe Parser
Post by: ztrumpet on June 22, 2010, 08:25:52 pm
You can wait for the user to press any key with:

:Repeat getKey(0)
:End
:While getKey(0)
:End

(It's useful to have the second loop to let them release the key. :) )
Title: Re: Axe Parser
Post by: qazz42 on June 22, 2010, 08:44:39 pm
Sadly, I wont be able to use this considering I am still learning Basic  :/

But looks good though I will say that.
Title: Re: Axe Parser
Post by: Magic Banana on June 22, 2010, 08:56:23 pm
Ah, alright. I can see where that might have it's uses.
Title: Re: Axe Parser
Post by: Quigibo on June 22, 2010, 08:58:13 pm
I was about to encourage you to learn it alongside BASIC, or as an alternative, but then I remembered I don't really have any comprehensive tutorials yet, just a simple one that already assumes you know BASIC.  I really should update my tutorial one day and expand it to be actually complete, I just haven't had time unfortunately.  The amount I'd have to write seems really overwhelming to me :-\
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 23, 2010, 12:14:21 am
One question: is it true that Getkey(0) and getkey doesn't work in WabbitEmu? I think I remember Player1537 having issues with it in his RPG entry, when he made the screenshot, and I recall having issues with my Tunnel game as well, where it just seemed to ignore those
Title: Re: Axe Parser
Post by: Runer112 on June 23, 2010, 12:18:15 am
Both work just fine for me, DJ Omnimaga.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 23, 2010, 12:20:29 am
Weird x.x

Maybe it is specific to computer hardware and what version of wabbit you use. I think there is a regular version and a .NET one. I forgot which one is the best.

At least the positive thing is that it works well on calc. That's what matters
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 24, 2010, 11:46:56 pm
Question about L1/SaveSScreen:

If the data in this is modified, will the calc mess up on the next Auto Power Down/APD?

I am wondering because I just saw this: http://wikiti.brandonw.net/index.php?title=83Plus:RAM:86EC

Quote
Before using for data storage, ensure that the calculator will not APD™ by disabling it with B_CALL DisableApd.
Title: Re: Axe Parser
Post by: calc84maniac on June 25, 2010, 01:56:30 am
Question about L1/SaveSScreen:

If the data in this is modified, will the calc mess up on the next Auto Power Down/APD?

I am wondering because I just saw this: http://wikiti.brandonw.net/index.php?title=83Plus:RAM:86EC

Quote
Before using for data storage, ensure that the calculator will not APD™ by disabling it with B_CALL DisableApd.
Nope. What happens is that when it APDs, the current data on the LCD is put into savesscreen, and then when it powers up, savesscreen is copied back into the LCD. A side effect of this is that any of your own data that was in savesscreen will be overwritten.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 25, 2010, 02:16:59 am
Aaah ok, thanks for the info. I should be safe, then.
Title: Re: Axe Parser
Post by: cooliojazz on June 25, 2010, 01:56:52 pm
I have a question.  I have a routine thats always drawing 13x8 sprites on the screen.  It moves in half tiles, so its either drawing one whole tile off the screen, or drawing two half tiles.  Now, whenever it draws the half tiles it slows down a LOT.  Why would this be, cause when it draws the 13th normally, it doesnt take any time since its off screen, or cause its having issues drawing it half on the screen, or what?  (And I checked my code, nothing but the drawing changes when it shifts)
Title: Re: Axe Parser
Post by: Quigibo on June 25, 2010, 02:13:39 pm
That's just becasue the sprite has to be shifted before it can be drawn when it is not aligned with the grid on the LCD ram.  The effect is most noticeable with Pt-Off() becasue that routine is particularly fast when its aligned and particularly slow when its not.  There really isn't much you can do, other than add more pauses when the grid is aligned.  This only applies to horizontal alignment by the way, not vertical so something along the lines of "!If X^8" would detect the alignment.
Title: Re: Axe Parser
Post by: cooliojazz on June 25, 2010, 02:15:54 pm
Ahh, ok, makes sense, thanks for that. Grr, I'll just have to see how i can work around that... :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 25, 2010, 06:17:23 pm
Darn I didn't realize I would have to deal with this problem x.x. I hope the slowdowns aren't too drastic

EDIT: nvm. The program I have already sometimes does that. The slow down is not that bad, altough it is a bit noticeable.

It is kinda bad if you need to draw an entire tilemapper every frame, though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 26, 2010, 12:50:03 am
Question:

Is

{L1+44}+C->{L1+44}

faster than

F+C->F

?

I am wondering since the former uses 16 bit numbers while the later uses 8 bit
Title: Re: Axe Parser
Post by: Deep Toaster on June 26, 2010, 01:08:57 am
I think you mean the latter is 16 bit and the former is 8.

And do I see a double-post by DJ :) Or did someone delete a post?

I can't answer that question (sorry), but I have a related question that someone could answer along with his: Is there any way to get 16-bit signed numbers, like int(L1)r (which doesn't work, by the way)?
Title: Re: Axe Parser
Post by: Quigibo on June 26, 2010, 01:10:14 am
No, its ever so slightly slower since it has to convert the 8 bit number into a 16 bit number (since C is a 16 bit number) in order to do the addition and then convert it back again to an 8 bit number.  The fact that its 3 bytes larger I think? is the greater concern than the speed though.  Its actually an optimization if you can store all your variables with constant addresses as 16-bit variables if you have enough ram.  Variable addresses however ARE more optimized as 8 bit than as 16 bit.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 26, 2010, 01:17:30 am
I think you mean the latter is 16 bit and the former is 8.

And do I see a double-post by DJ :) Or did someone delete a post?

I can't answer that question (sorry), but I have a related question that someone could answer along with his: Is there any way to get 16-bit signed numbers, like int(L1)r (which doesn't work, by the way)?
oh right yeah, my mistake x.x. As for the double-post, there were 6 hours between both posts, so I am within the rules :P

No, its ever so slightly slower since it has to convert the 8 bit number into a 16 bit number (since C is a 16 bit number) in order to do the addition and then convert it back again to an 8 bit number.  The fact that its 3 bytes larger I think? is the greater concern than the speed though.  Its actually an optimization if you can store all your variables with constant addresses as 16-bit variables if you have enough ram.  Variable addresses however ARE more optimized as 8 bit than as 16 bit.
Oh right I forgot about the fact variables remain 2 bytes and have to be converted when using inside addresses x.x. MY bad. I guess I'll need to be careful to what I choose depending of if speed is really a huge concern or not.
Title: Re: Axe Parser
Post by: Deep Toaster on June 26, 2010, 01:22:57 am
Also, is there a way to use the variables A through Z and Θ as 8-bit data? I've used up all of them, and I'm resorting to using data in from L1 onwards, even though most of the bytes are still empty since most of the data could have been 8-bit numbers.
Title: Re: Axe Parser
Post by: Builderboy on June 26, 2010, 02:43:47 pm
As far as i know, no.  Since whenever you store to a variable, it updates all 16 bits, clearing out any data you would want to store elsewhere.  If you really really really wanted to you could write your own routine to store and retrieve from the variable locations, but thats only if you really want those 27 extra bytes :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 26, 2010, 02:47:02 pm
would storing to the first byte of A be for example 0->{A} and the 2nd byte 0->{A+1}?
Title: Re: Axe Parser
Post by: Builderboy on June 26, 2010, 02:49:41 pm
Not quite, since A is the number of the variable, not the location.  A is located at location 34542, or more commonly known as L1-54.

0->{L1-54}   and 0->{L1-53} i believe would work.
Title: Re: Axe Parser
Post by: Quigibo on June 26, 2010, 02:52:14 pm
Don't use that method long term.  The location of the variables will eventually be switching to a different location at the end of L1 instead of the beginning.
Title: Re: Axe Parser
Post by: Builderboy on June 26, 2010, 02:55:42 pm
Whats the reason for moving them?
Title: Re: Axe Parser
Post by: calc84maniac on June 26, 2010, 03:02:36 pm
It was my suggestion, so that when he eventually makes 8-bit math mode it can decrease code size a bit (because the end of L1 is next the system flags area)
Title: Re: Axe Parser
Post by: Quigibo on June 26, 2010, 03:04:09 pm
There is a size optimization I can do when I get to doing byte mode which allows me to reference the variables from a relative location using the IY register instead of an absolute location.  This is becasue IY is located slightly after the free ram area in L1 for normal OS uses.  I'm still not 100% sure I will have time for that in Axe 1.0.0 because it might end up being a 2.0.0 thing if I don't have time to finish it.  Its an ambitious feature requiring the addition of many new routines.

EDIT: Ninja'd  Maybe I'll move them now as a precaution so that people can use the L1 hack to reference them more reliably.
Title: Re: Axe Parser
Post by: calc84maniac on June 26, 2010, 03:06:38 pm
There is a size optimization I can do when I get to doing byte mode which allows me to reference the variables from a relative location using the IY register instead of an absolute location.  This is becasue IY is located slightly after the free ram area in L1 for normal OS uses.  I'm still not 100% sure I will have time for that in Axe 1.0.0 because it might end up being a 2.0.0 thing if I don't have time to finish it.  Its an ambitious feature requiring the addition of many new routines.

EDIT: Ninja'd  Maybe I'll move them now as a precaution so that people can use the L1 hack to reference them more reliably.
Actually, maybe you could make a way in the parser to reference variable locations so it will never break things. Perhaps the lowercase versions?
Title: Re: Axe Parser
Post by: Quigibo on June 26, 2010, 03:13:14 pm
That would be clever!  However, I am probably going to be using more lowercase characters to prefix more constant types like key codes, bcalls, tokens, useful ram pointers, etc.  But I could do the same thing.  Like maybe pA gets compiled as "Pointer to A" so you can do {pA} to get it.
Title: Re: Axe Parser
Post by: SirCmpwn on June 26, 2010, 06:17:40 pm
If you are using lowercase tokens, you may want to modify the token hook to replace the two byte lowercase letters TIOS makes with proper one byte letters, and make the token hook display them correctly.
Title: Re: Axe Parser
Post by: Builderboy on June 26, 2010, 07:19:13 pm
How would it know the difference between lowercase and uppercase then?  Since they would be using the same token o.O
Title: Re: Axe Parser
Post by: SirCmpwn on June 26, 2010, 07:22:22 pm
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.
Title: Re: Axe Parser
Post by: calc84maniac on June 26, 2010, 07:30:31 pm
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.
I don't really see much point in this. First of all, they won't be used very much in the source and secondly, there won't be any size change in the executable. Also, "A" is 41h in ASCII and so is the TI-Basic token. "a" is 61h in ASCII.
Title: Re: Axe Parser
Post by: Builderboy on June 26, 2010, 07:37:02 pm
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.

Mmm i dont see how this would work.  I think you might be mixing up characters and tokens.  Tokens are what the editor uses, characters are only what the tokens are made out of.  Are you suggesting overriding 26 tokens with new character sets?
Title: Re: Axe Parser
Post by: Deep Toaster on June 26, 2010, 07:47:09 pm
On a related topic, is there a way to permanently change the font for the character set, not with an override like in Omnicalc, but with an actual change to the ROM OS?
Title: Re: Axe Parser
Post by: FinaleTI on June 26, 2010, 07:52:59 pm
Don't you mean OS?
Cuz the rom is either the file used by emulators to emulate the device or ROM is Read Only Memory.
Or is the data defining what the font looks like located in the ROM? I'd think it would be in the TI-OS data which is in the RAM, but I'm not an assembly programmer, so I wouldn't know.
Title: Re: Axe Parser
Post by: Deep Toaster on June 26, 2010, 07:59:21 pm
I thought that the OS was in ROM, so the words could be somewhat interchangeable, but I might be wrong. I changed it above.

And another thing:
Title: Re: Axe Parser
Post by: FinaleTI on June 26, 2010, 08:09:30 pm
I'm pretty sure the OS is in some of the hidden portion of the 32KB (I think) of RAM that all 83s and 84s should have. 24KB of this is User RAM, but the rest of it isn't normally accessible by the user. ASM programs can access it though. The 32KB isn't part of the 48-128KB extra RAM(I know 84s have this much, but I'm positive the 83s have less).
Could an assembly programmer possibly clarify this?
Title: Re: Axe Parser
Post by: calc84maniac on June 26, 2010, 08:22:21 pm
I'm pretty sure the OS is in some of the hidden portion of the 32KB (I think) of RAM that all 83s and 84s should have. 24KB of this is User RAM, but the rest of it isn't normally accessible by the user. ASM programs can access it though. The 32KB isn't part of the 48-128KB extra RAM(I know 84s have this much, but I'm positive the 83s have less).
Could an assembly programmer possibly clarify this?
That part of the RAM is used by the OS, but it is not the OS itself (which is in Archive/FlashROM)
Title: Re: Axe Parser
Post by: FinaleTI on June 26, 2010, 08:24:52 pm
OK. I guess I got a little confused. Sorry for the misinformation.
That would be kinda interesting to be able to permanently overwrite the font set.
Title: Re: Axe Parser
Post by: SirCmpwn on June 26, 2010, 09:52:03 pm
Well, I'm sure you can, assuming you figure out where the OS font is kept.  I'm not entirely sure, but Brandon Wilson probably knows.
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 27, 2010, 12:24:08 am
I would be fine even if the font set was just temporary overwritten by running an ASM program even if it resetted on RAM clears or when the font file was archived, like Omnicalc. I wonder how easy it would be to make such thing possible without having to run an application like Omnicalc? I know it's possible to install Celtic III hooks by running an ASM program, for instance. Would a program like this (or the code) takes a considerable amount of memory?
Title: Re: Axe Parser
Post by: nemo on June 29, 2010, 10:35:06 pm
will bad things happen if i do the following code:
Code: [Select]
For(A,1,8
0→{L3-A}
End
Title: Re: Axe Parser
Post by: DJ Omnimaga on June 29, 2010, 10:45:36 pm
I am not too sure, but something strange happened when I tried to display a tilemap from L1-1 once: the entire tilemap suddently changed to random stuff. This tells me that when going negative, it tried to display L1+65535 (it's not L1+255 because I know in my program the stuff there was not random stuff) then stuff at like 65536,7,8,9, etc.

If this is not what happened, then I am not too sure. Regardless, watch out what you are doing and backup.
Title: Re: Axe Parser
Post by: Builderboy on June 29, 2010, 11:13:16 pm
will bad things happen if i do the following code:
Code: [Select]
For(A,1,8
0→{L3-A}
End


Hmmm most likely something bad will happen, you are writing to a place that is not inside the Safe Ram dedicated to the AppBackupScreen (where L3 is pointing to).  What are you trying to accomplish?
Title: Re: Axe Parser
Post by: nemo on June 29, 2010, 11:38:20 pm
found a bug in my tilemapper and this is the easiest fix. so far nothing malicious has happened. everything works fine with that code in, but that could change.
Title: Re: Axe Parser
Post by: Builderboy on June 29, 2010, 11:45:37 pm
Hmmm i am concerned that something might end up happening, since you are storing in unsafe areas.  Where exactly are you storing your tilemap?
Title: Re: Axe Parser
Post by: nemo on June 30, 2010, 12:01:19 am
L1 - in the future will store the HEX string to output
L2 - tilemap
L3 - tileset
L4 - work area for tile editing.

in the future i'll probably switch L1 and L2 when dealing with tilemaps larger than the screen, but for now my setup works.
the fragment of code setting 0 to 8 bytes before L3 has to deal with editing the tilemap. 2nd displays the next tile, alpha displays the previous tile. when tile 1 is in a position and you use alpha, you should get a blank space. however, the 8 bytes before L3 are displayed. so i put that for( loop in there to correct it. i can't use a blank 8x8 square tile either, since i'm dealing with sizes from 4x4 - 8x8, and if i display a blank square it will erase surrounding parts of the tilemap. also, that costs memory. if this gives me a RAM clear then i'll certainly change it.
Title: Re: Axe Parser
Post by: ztrumpet on July 01, 2010, 11:44:18 am
I'd recommend to STAY AWAY from areas like L3-8 unless you know exactly what you're doing.  Since you don't know what data is stored there it could cause instability.  Could you replace all of your L3s to L3+8, as it would compile to the same size and wouldn't overwrite unknown data? :)
Title: Re: Axe Parser
Post by: Michael.3545 on July 01, 2010, 07:53:57 pm
I just did some investigating with Calcsys.  L3 seems to point to 9872.  (All these values are hex)

Here is what is around that area on my calc:

Code: [Select]
27 bytes of empty space
9866: 00 FF 3E 8D
986A: 03 13 22 70
986E: 00 00 00 00
9872: 6A 98 00 00
all the rest of L3

So there is stuff from 9867 to 986D, but I have no idea what.  You would have written over 4 bytes of stuff on my calc.  Could Axe be using the space for something?
Title: Re: Axe Parser
Post by: Quigibo on July 01, 2010, 08:04:10 pm
To answer these questions:

Code: [Select]
appErr1 equ 984Dh
appErr2 equ 985Ah
flashByte1 equ 9867h
flashByte2 equ 9868h
freeArcBlock equ 9869h
arcPage equ 986Bh
arcPtr equ 986Ch
appRawKeyHandle equ 9870h
appBackUpScreen equ 9872h

It looks like you'd be writing over something that sounds like it has to do with the rawkey hook so I don't know if that's necessarily safe.  Its entirely possible that these are just temporary variables that the OS uses but not for long term storage.  As long as Axe doesn't use any OS routines that use these temporary variables, it should be safe.  I have no idea what would use them though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 01, 2010, 08:20:21 pm
I personally would be careful,  still, though. We never know sometimes x.x

I personally try to take precautions to not go out of bounds.
Title: Re: Axe Parser
Post by: Deep Toaster on July 01, 2010, 10:09:57 pm
Just saw the description for 0.3.2. Really want to update :(
Title: Re: Axe Parser
Post by: Quigibo on July 01, 2010, 10:11:06 pm
I was a little too busy to write an example program before the release, I only got half way done, but I will release that in the routines section instead.  Its an automated sound loader and player that operates in the background using interrupts.  I'm probably forgetting to explain some of the new features, so don't hesitate to ask if you are confused about any wording in the commands list.

Oh yeah!  About the applications, to sign them, transfer them to the computer first.  The next step, I don't know an easy way to do, but what I did was open the app file in a hex editor, remove the garbage header stuff before the first colon, and the signature on the bottom which is hard to find, but it has all $FFs in it I think.  I don't really know the process that well myself, but maybe someone else can explain it.  You then have to save the file as a .hex and import it into Wapsign or rabbitsign to sign it.  Does anyone know of an program that can resign the app without having to go through this trouble?
Title: Re: Axe Parser
Post by: Runer112 on July 01, 2010, 11:15:38 pm
I'm having a bit of trouble displaying two-byte tokens. Does Axe use little-endian, but the operating system does not? Because I'm trying to read from program data, and to correctly read a two-byte token with the first byte (according to it's location in memory) at A, I cannot use {A}r but have to use {A}*256+{A+1}.
Title: Re: Axe Parser
Post by: Quigibo on July 01, 2010, 11:20:05 pm
That's becasue you normally don't load a 2 byte token directly into a register pair.  Normally, the procedure is to read it as a one byte token, then you call a command that checks if that token is a 2 byte token (something I will add later).  Only then do you shift in the second byte.  That's how the OS does it anyway, I'm just using their routines, can't blame me for their stuff :P
Title: Re: Axe Parser
Post by: Runer112 on July 01, 2010, 11:24:18 pm
That's sort of how I'm doing it too:

Code: [Select]
 If {Q}sub(2T)
    Disp {Q}*256+{Q+1}▸DMS
    Q+2→Q
  Else
    Disp {Q}▸DMS
    Q+1→Q
  End

Subroutine 2T checks if the first byte is a two-byte token initializer. But is there an easier way to go about reading and displaying tokens sequentially like this?

EDIT: And on the topic of tokens and reading from programs, can anyone answer this: How can one tell where the end of a program is?
Title: Re: Axe Parser
Post by: Quigibo on July 02, 2010, 12:07:50 am
Hmmm... maybe I will reverse the order of the token then.  Its a relatively trivial thing to do in assembly but it would be more convenient in Axe.  Doe it work right with the Text() command?  That takes a pointer as an argument instead of the token itself.

And to read programs, you first read the size field of the program and then you'll know when you've reached the end.
Title: Re: Axe Parser
Post by: Runer112 on July 02, 2010, 12:25:07 am
And to read programs, you first read the size field of the program and then you'll know when you've reached the end.

You mean the two bytes before the program start?

EDIT: Text() works fine, it handles both one-byte and two-byte tokens correctly, determining which kind is pointed to and correctly displaying it.

EDIT 2: Another question: Where are character/token small font sizes stored? Those would be nice to be able to access, even if manually for now, because I'm trying to print to the screen token by token and I'm wondering how the operating system handles advancing the pen correctly.
Title: Re: Axe Parser
Post by: Deep Toaster on July 02, 2010, 12:34:45 am
After GetCalc( is used to create a new program variable, does the Axe syntax return the first byte of the size field? In other words, does the following code store the size of prgmUNWISE (8) into Ans (sorry, I can't test anything for a while)?
Code: (Axe BASIC) [Select]
"prgmUNWISE"→Str1
GetCalc(Str1,8)
→Ans
Title: Re: Axe Parser
Post by: Runer112 on July 02, 2010, 12:35:40 am
No, that would return the pointer to the start of the created data. Also, as far as I know Axe does not support creating programs with GetCalc() yet, only appvars.
Title: Re: Axe Parser
Post by: Builderboy on July 02, 2010, 12:59:23 am
Im not sure why everybody is having all these problems with 2 byte tokens vs 1 byte tokens.  Isnt there a BCall that reads directly from a memory location and gives you the token string, either 2 or 1 byte?  I know that i used such a BCall in my program editor so i know such a method exists.
Title: Re: Axe Parser
Post by: Deep Toaster on July 02, 2010, 01:02:50 am
This is a bit off topic, but:
Program editor? Did you make an on-calc IDE? Can I have a link? :D
Title: Re: Axe Parser
Post by: Runer112 on July 02, 2010, 01:08:50 am
I'm starting an on-calc Axe program editor, and the first part is displaying the program correctly, so I have to deal with tokens. With any luck I can get it to work and start adding features like sprite previews, subroutine/data collapsing, copy/paste, and maybe even real-time syntax checking.
Title: Re: Axe Parser
Post by: Builderboy on July 02, 2010, 01:16:14 am
This is a bit off topic, but:
Program editor? Did you make an on-calc IDE? Can I have a link? :D

This is a project im kinda working on half on half off.  Its a small font editor for Basic and Axe programs.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 02, 2010, 01:40:50 am
Wow I like all the new features added. I'M not sure yet if I'll need them in my program but they'll sure eventually come handy in later programs, if I make any, especially interrupts.

Nice job again Quigibo!
/me goes to rate up his new version's post.
Title: Re: Axe Parser
Post by: Deep Toaster on July 02, 2010, 02:16:37 am
/me will join DJ as soon as he gets the new version.
Title: Re: Axe Parser
Post by: ztrumpet on July 03, 2010, 10:49:59 am
Nice update!  I like the new features. ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 10, 2010, 11:29:07 pm
I'm glad to see the new update out! Nice features again. I'll be sure to give the draw shape commands a try tomorrow or monday, providing I am not too tired
Title: Re: Axe Parser
Post by: Quigibo on July 10, 2010, 11:34:34 pm
Yeah so let me go through a few of the new features.

First of all, FP multiplication and high order multiplication are very advanced features.  Odds are if you don't know what those mean you probably won't ever need them.  The only time you do need them is for extremely low level math.

The rectangles are all filled.  The way to make a rectangular border is by drawing 2 rectangles on top of each other or you can just use 4 lines or even 4 rectangles of heights and widths of 1.  By using the back buffer you can actually get some really cool menu boxes with different shades of gray from the border inwards.

The freq() command is no longer totally compatible with my MidiToAxe converter because the lowest note C is now actually so low you can't hear it, however the rest of the notes are still the same.  I'll be updating the converter for the new format later anyway, so you'll just have to wait for that.

I think that sums up most of the FAQs I anticipate.

EDIT: also, I should mention, there are less than 100 bytes left in the app.  I had to do some major parser optimizations to be able to fit everything.  So this is the last version that will fit on a single page.  From now on, Axe will be 2 pages (never more) and the next version will be 0.4.0 because I want to make sure I add enough new features to justify the extra page.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 10, 2010, 11:42:08 pm
Grayscale transparent-ish boxes seems epic ;D

And no problem with Axe being 2 pages, considering everything it offers
Title: Re: Axe Parser
Post by: nemo on July 10, 2010, 11:52:16 pm
which is faster:

drawing a 4x4 black rectangle, then inverting a 2x2 in the center to make a 4x4 outline rectangle

or

8x8 pt-on sprite.
Title: Re: Axe Parser
Post by: Quigibo on July 10, 2010, 11:58:30 pm
I don't know they sound about the same.  You can test these you know with a loop.  Either use an interrupt counter or a stopwatch.

EDIT: By the way, you also have size to consider.  The rectangle routines are nearly the size of the sprite drawing routines and having 2 of them (Rect and RectI) when they don't need to be there is really a lot of extra bytes, probably 200 extra combined.
Title: Re: Axe Parser
Post by: nemo on July 11, 2010, 12:00:11 am
i know, i thought i would ask here though, since you would probably know as the designer of the parser. a quick addendum, would it be faster to draw the 4x4 black rectangle then pixel-off the 4 in the center? or is this again about the same speed? i have some testing to do...

EDIT: speed over size in this scenario. even if speed is marginal for 200 bytes, i'll take it.
Title: Re: Axe Parser
Post by: Quigibo on July 11, 2010, 12:04:44 am
Even as the creator I don't know the speed of the routines since they're different depending on a lot of factors like where they're drawn, how big they are, if there's clipping, etc.  I can only give you a rough estimate without physically testing it.  I could be totally off too.
Title: Re: Axe Parser
Post by: shmibs on July 11, 2010, 12:20:06 am
axe never ceases to impress me
i got the new version just before my recent net 'reprieve', and had plenty of chance to mess around with the new features. i hope to use the grayscale routine i made in my axe entry

keep up the awesome work, i cant wait!
Title: Re: Axe Parser
Post by: squidgetx on July 11, 2010, 10:40:22 am
Looks mad nice

Quote
The signed multiplication is performed using the high byte as the integer part and the low byte as the decimal part returning a number in the same format.

I don't do too much lower level programming, so from what I know this sounds like decimal-multiplication. Which would be extremely useful. My question is, which byte is the high byte? The first one?

Title: Re: Axe Parser
Post by: DJ Omnimaga on July 11, 2010, 12:30:06 pm
I just tried the new rectangle routines and they are pretty nice.
Title: Re: Axe Parser
Post by: Quigibo on July 11, 2010, 04:52:47 pm
Quote
The signed multiplication is performed using the high byte as the integer part and the low byte as the decimal part returning a number in the same format.

I don't do too much lower level programming, so from what I know this sounds like decimal-multiplication. Which would be extremely useful. My question is, which byte is the high byte? The first one?
You can't really think of it as "first" and "second" because they're stored in registers one way and in memory the opposite way.  I don't know a better way of describing it, but the high byte is 2329 and the low byte is 2329 where this is a hexadecimal representation of your favorite number.

2 => E200 = 512
1 => E100 = 256
.5 => E80 = 128
pi => E324 = 804 etc.

Also, the reason there is no FP division is because you can multiply by decimal numbers.  Keep in mind, if the answer is 20 it won't return 20, it will return a number in FP format which is 20*256 so if you want to immediately round and display an FP number X you have to do X//256.

EDIT: I COMPLETELY forgot to mention another feature!  When you absorb pics, they can now be in archive and pictures of larger sizes are now supported and will be imported to their original size.  However it has no effect if imported as a tilemap.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 11, 2010, 05:20:54 pm
Ooh nice to hear about the pics :D

By not having any effect with tilemap import, do you also mean archive?
Title: Re: Axe Parser
Post by: Quigibo on July 11, 2010, 05:24:00 pm
No, I mean it will only import 12 rows and 7 columns of tiles even if the pic is the full 96x64 pixels.  All pics can be read from archive.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 11, 2010, 05:26:02 pm
Aaah ok I see ^^

Well it's nice because it makes development and testing much easier when you dont need to constantly archive/unarchive stuff

Keep up the good work on this quigibo!
Title: Re: Axe Parser
Post by: calcdude84se on July 11, 2010, 06:12:27 pm
Nice to hear about the update, and nice to know about pics and rectangles (I also like being able to do 16*16=32 multiplication)
Quigibo, could you check the documentation for the rectangle routines? It sounds like an added r does nothing and that RectI( always draws to the backbuffer.
Keep up the good work!
Title: Re: Axe Parser
Post by: Magic Banana on July 11, 2010, 06:31:23 pm
It looks to me like he just copied the descriptions for Rect() and RectI() and pasted it to the r commands as well. My guess is that he was just in a hurry to release it so he didn't pay much attention to the documentation.  ;)
Title: Re: Axe Parser
Post by: calcdude84se on July 11, 2010, 06:34:02 pm
Fine by me, I had guessed the correct uses of the commands, but I was hoping he would clarify it for confused others. ;)
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 11, 2010, 07:38:14 pm
Yeah I got confused at those commands. Hopefully should be fixed in next release (or in a small update) ^^
Title: Re: Axe Parser
Post by: calcdude84se on July 11, 2010, 08:38:16 pm
I just tried (or rather am trying) the fractal program. Two words: amazingly awesome! :D
Keep up the good work!
Title: Re: Axe Parser
Post by: Builderboy on July 12, 2010, 01:38:38 am
That fractal program is epic!  I wonder if it could be converted to 4 color greyscale instead of the looping pattern.  Hmm i will have to see if i can get it to work :D

Fantastic update!
Title: Re: Axe Parser
Post by: Quigibo on July 12, 2010, 03:16:48 am
Sorry about the typos in the commands list, I'll fix it next update.

@Builderboy, yeah, its really easy to get 4 lvl gs for the fractal using mod 3, I had it originally, but i thought it was overkill.
Title: Re: Axe Parser
Post by: Builderboy on July 12, 2010, 03:27:17 am
Hmmmm what does *^ do?  There is only that one line definition that i can find, and i dont understand what that means.
Title: Re: Axe Parser
Post by: Quigibo on July 12, 2010, 06:51:05 am
Its pretty interesting actually.  Let me explain using decimal and then you can extrapolate to hexadecimal.

So say you have two 4 digit numbers, always positive.  If you do a multiplication, what is the largest number you can possibly get?  Well, that's simple to find:

9999 x 9999 = 99980001

Notice how we end up with an 8 digit number.  Since our variables can only hold 4 digit numbers, like the input, we have to decide which 4 digits to keep and which ones to throw away.  We have now have 3 methods to choose (only the underlined part is kept):

9999 *   9999 = 99980001
9999 ** 9999 = 99980001
9999 *^ 9999 = 99980001

There is a little more to ** when you have negative numbers because its signed instead of unsigned, but this is basically how all of these commands works.  Don't forget, you won't get these answers on the calculator because my examples are in base 10 for demonstration.
Title: Re: Axe Parser
Post by: Builderboy on July 12, 2010, 01:12:52 pm
Ah i see, so basically you can use *^ for floating point arithmetic?  You would still need to keep track of the decimal point though...
Title: Re: Axe Parser
Post by: Raylin on July 12, 2010, 01:56:56 pm
I know that this may be off-topic but exactly what should we expect in 0.4.0? :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 12, 2010, 02:07:02 pm
I am curious about this too. I wonder if this will include reading from archive and the other options in the poll that are almost tied. I am curious about what other features there will be too.
Title: Re: Axe Parser
Post by: Darl181 on July 12, 2010, 04:08:31 pm
Loading pics...
How do you do that?
I know you do [Pic1] or whatever pic it is but then what?
Title: Re: Axe Parser
Post by: jnesselr on July 12, 2010, 04:28:30 pm
You could do pic1->DispGraph, and it will display on the screen immediately.
Title: Re: Axe Parser
Post by: FinaleTI on July 12, 2010, 04:33:27 pm
You could also try Copy(Pic1,L6,768) to copy it to the buffer. For the back-buffer, you can copy it to L3.
Title: Re: Axe Parser
Post by: Deep Toaster on July 13, 2010, 01:59:22 am
Loading pics...
How do you do that?
I know you do [Pic1] or whatever pic it is but then what?

I'm pretty sure [Pic1] absorbs a picture into the program data (meaning that the data for the TI-OS variable Pic1 (the one you actually use in BASIC programs) is copied directly into the program). So if you had a variable Pic1 that was all blank,

Code: (Axe BASIC) [Select]
[Pic1]→Pic1

is read as

Code: (Axe BASIC) [Select]
[ ... ]→Pic1

where the ... is 756 bytes of 0. It's useful if the BASIC variable Pic1 has the sprites, one after the other, starting from the top left. That way, instead of having to find the hex code of each individual sprite and typing them into the program, [Pic1]→Pic1 will copy it all for you and store it to the static variable Pic1.

Actually, there's a good chance I have no idea what I'm talking about. I've never actually used the command, and I can't use my calculator right now, so I'm just basing this on my interpretation of the documentation. I wouldn't trust me if I were you unless someone else said the same thing :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 13, 2010, 02:01:44 am
Note that in [Pic1]->Pic1, the first Pic1 is not the same as the second. You could store something else to Pic2 in Axe and it would not overwrite your BASIC Pic2, if you get what I mean.

It's like [PicDataToAbsorb]->Pointer
Title: Re: Axe Parser
Post by: Quigibo on July 13, 2010, 02:07:02 am
Deep Thought, you're exactly correct.  The only thing I might add to that, because its a new feature, is that not all OS Pic variables are created equal.  The ones that are made using StorePic are 756 bytes yes, but many pic vars made on the computer are actually 768 bytes since they can edit the last row and so the amount of data it imports will depend on the picture itself.

As for 0.4.0 features, there will be some small GUI changes probably, I'll try to check off some of those wishlist features, and hopefully there will be some more optimizations to make the code smaller possibly involving a third pass.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 13, 2010, 02:10:09 am
I think I remember hearing about pics of over 2 KB in size before, but I totally forgot which program could create those. I believe it might have been a very old xLIB version
Title: Re: Axe Parser
Post by: LordConiupiter on July 13, 2010, 08:16:12 am
well, perhaps that would be used for 7 lvl grayscale or something, because 3 * 768 = 2304?
Title: Re: Axe Parser
Post by: squidgetx on July 13, 2010, 10:37:58 am
Wow...i had never understood that before. Being able to "import" BASIC pics is awesome
Title: Re: Axe Parser
Post by: Darl181 on July 13, 2010, 02:27:16 pm
Another thing. I was reading through the Axe documentation, and it was saying I sould use a Str token for a pointer.  It also said L1-L6 were pointers.  Could a Str token substitute for the Axe-type L1-L6 so I don't have to work around the various corruptions?
Title: Re: Axe Parser
Post by: Builderboy on July 13, 2010, 03:05:13 pm
What corruptions are you talking about?  Im a little confused.  The reason L1-L6 are separated from the pointers like Str pointers is this: L1-L6 are pointers to free places of RAM that are *outside* your program.  Pointers like the Str pointers point to data that is *inside* your program.
Title: Re: Axe Parser
Post by: jnesselr on July 13, 2010, 03:46:59 pm
This is the hardest concept in axe.  Okay, so in basic, you do "Hello"->Str1.  That stores the string "Hello" to the variable Str1.  As a basic programmer, that's all that you have to worry about.  However, behind the scenes, this what happens:
In axe, it's different.  the strings are stored inside the program, and the calculator doesn't have to look them up.  Say I do this: "Hello"->Str1.  It's the same command as before, but in this case, when the program is compiled, the compiler sees that line and does this:
Also, because the strings are zero terminated, and Str1 points to the "H" character in memory, you can do stuff like Str1+3, which points to the second "L" in memory.
So try this program:
Code: [Select]
"HELLOL"->Str1
ClrHome
Disp Str1+3
pause 5000
That routine displays LOL, and then pauses for about 5 seconds.

Now, for the L1-L6 variables.  They are all pointing to locations in memory where you can store things as well.  Try the same program, but replace Str1 with L1.  It doesn't work, does it?  Well, that's because you can't really store into L1 like that.  When using L1, since it's already predefined to certain locations, You can only access it by using {L1+n}, where n is the the byte you want to access, starting with 0.  For example, the first byte of L1 is {L1}.  It takes a while to get use to, but once you do, it's a very powerful feature.  Just remember, Basic is not Axe, and Axe is not basic.
Title: Re: Axe Parser
Post by: LordConiupiter on July 13, 2010, 04:22:01 pm
wow! that's a very clear and complete explanation! could even eventually be used in the documentation :P
Title: Re: Axe Parser
Post by: Quigibo on July 15, 2010, 03:41:34 am
From now on, I'm going to greet people with "Hellol" :P

I'm changing a token name.  You know how programs have the "prgm" token in front of them?  Well, I'm doing the same thing with appvars.  The problem is that its impossible to distinguish between the lowercase "v" and the recursive "v" because they share an identical ascii character.  It has led to confusion in the past, and I think it will do so in the future so I've decided to change it to "apvr" to mimic the way "prgm" is formatted so that it is both distinguishable and recognizable as to how to use it since its interchangeable with prgm.  Thoughts?
Title: Re: Axe Parser
Post by: Magic Banana on July 15, 2010, 04:13:18 am
I like it. It would really help distinguish an appvar v from just a normal lowercase v, especially if some people don't understand that "vString"->Str1 actually pulls from an appvar instead of just being an interesting name for a string.
Title: Re: Axe Parser
Post by: LordConiupiter on July 15, 2010, 05:19:24 am
I would prefer appv in stead of apvr, but that's just a minor thing. It would indeed be very usefull and handy!
Title: Re: Axe Parser
Post by: Darl181 on July 15, 2010, 02:17:16 pm
What I'm talking about is using the strs the same way as the lists.  I mean like instead of
1→{L1+1}
it would be
1→{Str1+1}

As for the corruptions, I'm talking about what the commands list says.
L2--not for MirageOS programs
L5--"disp", "ClrHome", and "output" corrupt
L6--any buffer drawing corrupts

It's in the documentation.
Could the 'strings' be applied to the same use as the 'lists'?
Or are they some different type of pointer?
Title: Re: Axe Parser
Post by: FinaleTI on July 15, 2010, 02:43:56 pm
They are somewhat different. Str1 is a static pointer, while L1 is a saferam area.
Essentially, the difference is that L1 can be freely modified and changed, but has a fixed size. Str1 can also be modified or changed (though it can be a bit more of a pain sometimes), but can have variable size. That said, other programs can access L1, but not the Str1 you've stored in the first program. This is because L1 is stored in a dedicated RAM area, while Str1 is defined as part of your program and temporarily takes up RAM when that program that uses it is run.
Str1 (Or any Str, Pic, or GDB pointer) isn't just used for numbers either. It can be used for strings, sprite data, lists, etc.

For example:
[FFFFFFFFFFFFFFFF]->Pic1
is the same as
[FFFFFFFFFFFFFFFF]->Str1 or even [FFFFFFFFFFFFFFFF]->GDB3Z.

What you point to depends on what you need the data for.

Also, the 'corruptions' don't always corrupt the saferam area.
For example, modifying L6 modifies the buffer, so you can use it for various things such as an aligned 16x16 sprite routine or flipping the screen.
L3 acts the same way, except that it modifies the back-buffer.
Title: Re: Axe Parser
Post by: qazz42 on July 16, 2010, 03:26:12 pm
I feel retarded in asking, but how do you display variables? If I just say

:Disp A

I get some retardedness from that calc

P.S. I read both manuals, good job dude, I like it
Title: Re: Axe Parser
Post by: nemo on July 16, 2010, 03:29:47 pm
Disp A                       gives you the garbage located at pointer A.
Disp A>Dec                gives you the decimal value of A.
Disp A>Char/>Frac      gives you the corresponding ASCII character.

so to answer your question, add >Dec on the end of A to display the value.
Title: Re: Axe Parser
Post by: Builderboy on July 16, 2010, 03:30:02 pm
What you are looking for is Disp A>Dec. (The >Dec can be found under the math menu)

>Dec tells the compiler to display as a number.  Without this, Axe tries to display the String that is A, haha which there is none so it messes up and displays Strings from places in Memory.

EDIT: Ninja'd :P
Title: Re: Axe Parser
Post by: calcdude84se on July 16, 2010, 03:30:39 pm
Disp A>Dec, where >Dec is the token in the math menu.
When you do Disp A, you display a string starting at the Ath byte of memory.
Edit: Double-ninja'd :P
Title: Re: Axe Parser
Post by: qazz42 on July 16, 2010, 03:32:26 pm
Ah, and to clear something up, when you make sprite using hexpix, you havve to store it into a pic, and THEN recall it?
Title: Re: Axe Parser
Post by: Builderboy on July 16, 2010, 03:35:38 pm
What do you mean by Store it into a pic?  If by store into a pic, you mean recall the Hex and store it to a pointer

[FFABABA101010122]->Pic1

Then that is correct.  You can then display the sprite by using Pt-On(X,Y,Pic1
Title: Re: Axe Parser
Post by: nemo on July 16, 2010, 03:35:52 pm
hexpix? what program is that?
Title: Re: Axe Parser
Post by: Builderboy on July 16, 2010, 03:36:43 pm
Its the Sprite to Hex program bundled with Axe, under tools
Title: Re: Axe Parser
Post by: calcdude84se on July 16, 2010, 03:37:26 pm
He means the HEXPIC program in the tools directory of the download. I've never used it, so I can't answer.
Edit: ninja'd again :P
Title: Re: Axe Parser
Post by: qazz42 on July 16, 2010, 03:37:41 pm
Ok bulderboy, thanks for clearing that up, I see, I was using recall pic, not pt-on
Title: Re: Axe Parser
Post by: Builderboy on July 16, 2010, 03:45:10 pm
Yeah no problem :)
Title: Re: Axe Parser
Post by: qazz42 on July 16, 2010, 04:31:06 pm
Damnit, it is still not working, I cant display th pic for some reason ;.;

I put

[hex]-->Pic1
pt-on(0,0,Pic1
Pause


But only get a blank screen, could I have another pointer?
Title: Re: Axe Parser
Post by: calcdude84se on July 16, 2010, 04:32:22 pm
You need to display the screen with DispGraph. Commands such as Pt-On don't draw directly to the LCD, but rather to L6, the buffer.
Title: Re: Axe Parser
Post by: qazz42 on July 16, 2010, 06:16:24 pm
Ah, ok, now it worked, thanks
Title: Re: Axe Parser
Post by: Quigibo on July 17, 2010, 04:21:36 am
Update:

I have reading and writing to ALL external variables working right now, I just need to find a clever way to create and delete them.  I might be getting rid of the delvar command used in labels and make that the delete os var useage like how it works in BASIC.

Also I got direct link port I/O working and I was experimenting with the possibility of a "WaveToAxe" converter.  Right now, at 6MHz, I can just barely make out the "It's a-me Maaario!" clip that came with realsound which is what I'm using as a reference goal.  I will update on my progress later and possibly release it if I can get some decent quality, and it seems very possible.  This is NOT an assembly routine, this is in pure Axe code with the direct port commands in 0.4.0.  Unlike realsound however, the clip is much more compressed.  The realsound clip generates a 2 page app whereas the appvar created with my converter is less than 2KB.  Hopefully I can keep it that low as I start finding ways to increase the quality.
Title: Re: Axe Parser
Post by: Magic Banana on July 17, 2010, 05:31:07 am
That's great to hear you are getting everything working out! :D
I didn't really understand what to use that DelVar for, seeing as how we could already make more Lbls than we need anyway :P

Wow, going from 32kb to just 2? Talk about compression. Looking forward to all the amazing things that are going to be showing up in 0.4.0.
Title: Re: Axe Parser
Post by: qazz42 on July 17, 2010, 12:48:04 pm
But, here is a little problem I pose, realsound has terrrible quaity on the nspire 84 keypad, so if you are planning to base your off of realsound, then the nspire willl be an obstical
Title: Re: Axe Parser
Post by: calcdude84se on July 17, 2010, 05:32:11 pm
Cool! :D Nice to hear. I was never really sure how to use DelVar for labels anyway, and it seems natural to use it for variables.
Nice to hear you implemented direct link port I/O too. Now onto reading directly from archive (and being able to create RAM copies of things too, I hope)
Qazz: It's the Nspire, so it might not be possible to get high-quality sound, or a slightly different routine might have to be used for the Nspire 84+SE. With luck we'll be able to do it though. :)
Title: Re: Axe Parser
Post by: squidgetx on July 17, 2010, 08:28:30 pm
zomg 32k->2k???

still, since the appvar can't be read from flash....

well good for BE users without the massive archive space
Looking good so far
Title: Re: Axe Parser
Post by: qazz42 on July 17, 2010, 08:49:20 pm
Yeah, problem is that EVEN with a different routine, alot of sound programs have a tendency to cause a reset (MT3, calc-mod, etc) Ti-jukebox was the best, but didnt have much dev on it
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 18, 2010, 10:36:20 pm
From now on, I'm going to greet people with "Hellol" :P

I'm changing a token name.  You know how programs have the "prgm" token in front of them?  Well, I'm doing the same thing with appvars.  The problem is that its impossible to distinguish between the lowercase "v" and the recursive "v" because they share an identical ascii character.  It has led to confusion in the past, and I think it will do so in the future so I've decided to change it to "apvr" to mimic the way "prgm" is formatted so that it is both distinguishable and recognizable as to how to use it since its interchangeable with prgm.  Thoughts?
I think that's a good idea. Maybe "appv" would work, too. I get confused a lot too and always end up almost hitting 2nd+ALPHA+ALPHA+6 by mistake x.x

Update:

I have reading and writing to ALL external variables working right now, I just need to find a clever way to create and delete them.  I might be getting rid of the delvar command used in labels and make that the delete os var useage like how it works in BASIC.

Also I got direct link port I/O working and I was experimenting with the possibility of a "WaveToAxe" converter.  Right now, at 6MHz, I can just barely make out the "It's a-me Maaario!" clip that came with realsound which is what I'm using as a reference goal.  I will update on my progress later and possibly release it if I can get some decent quality, and it seems very possible.  This is NOT an assembly routine, this is in pure Axe code with the direct port commands in 0.4.0.  Unlike realsound however, the clip is much more compressed.  The realsound clip generates a 2 page app whereas the appvar created with my converter is less than 2KB.  Hopefully I can keep it that low as I start finding ways to increase the quality.
Nice features!

As for the sound quality for the WaveToAxe thing, it seemed fine to me in the other topic. Low quality but it seemed like Atari 2600 or something. We have to remember it's a calc after all ;)
Title: Re: Axe Parser
Post by: Runer112 on July 18, 2010, 11:45:55 pm
I don't quite remember, can you not use DispGraph/DispGraphrr in interrupts? I was just wondering because I thought I remembered seeing something like this, although it seems like it would be a good way to ensure smooth grayscale.
Title: Re: Axe Parser
Post by: Quigibo on July 19, 2010, 12:42:40 am
When I finish the Doc, I will mention which commands are safe to use with interrupts.  I think only the 4 level grayscale is unsafe, but you NEVER want to have drawing as part of an interrupt because it can interfere with a lot of other things and is very uncontrollable.  You can't really have the LCD routines interrupt driven otherwise you have to disable interrupts when drawing sprites so that the screen isn't drawn with incomplete sprites.  But that's what usually takes up most of the processing and will completely ruin the timing aspect.

Instead, you want to make your interrupt just be a timer and that's it.  That way you can have your main routine wait until its time to draw before actually drawing and only when its ready to draw.
Title: Re: Axe Parser
Post by: Builderboy on July 19, 2010, 01:06:33 am
Was the problem with interrupts being turned off by certain commands fixed? 
Title: Re: Axe Parser
Post by: Quigibo on July 19, 2010, 01:12:31 am
Nope, I still can't figure it out :(
Title: Re: Axe Parser
Post by: Builderboy on July 19, 2010, 01:15:17 am
Oh thats too bad :( Do we know which commands create the problem?
Title: Re: Axe Parser
Post by: Quigibo on July 19, 2010, 01:23:30 am
I'm pretty sure its just the DispGraph commands at the moment but please report if you find any more that do that!
Title: Re: Axe Parser
Post by: Builderboy on July 19, 2010, 01:25:18 am
So if we want to include these commands in our games, should we turn off interups before these commands and then turn them back on? 
Title: Re: Axe Parser
Post by: Quigibo on July 19, 2010, 01:33:57 am
No, they disable them fine on their own, you only need to re-enable them after the command.  Adding that extra FnOn is only an extra byte so not a big deal really.
Title: Re: Axe Parser
Post by: Builderboy on July 19, 2010, 02:09:21 am
Ah, thats true ;D good to know
Title: Re: Axe Parser
Post by: Runer112 on July 19, 2010, 03:08:42 pm
So if we can't use DispGraphrr in interrupts, does anyone have any tips about ways to ensure that grayscale screen updating runs constantly and smoothly? Perhaps some trick to activate the screen update using an interrupt but not actually performing the update inside the interrupt?
Title: Re: Axe Parser
Post by: Magic Banana on July 19, 2010, 06:48:42 pm
I believe that it was mentioned before, but just in case, Using a timer as an interrupt and utilizing the counter to update the screen in steady intervals.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 20, 2010, 08:15:11 pm
As a side note, I moved all the game-related projects that had their own topics outside the Axe sub-forum, because half of the games were posted inside the Axe sub-forum while the other half was posted under Other calculator projects and ideas. I thought it would be best to keep things consistent, and moving all Axe projects inside the Axe sub-forum would have cluttered it too much. I've left non-game projects inside the Axe Parser section, though (as well as the Your Projects, Post and Critique).
Title: Re: Axe Parser
Post by: Quigibo on July 23, 2010, 01:40:00 pm
This is just a general warning because I didn't realize how badly I screwed up the text command in the past.

I completely rewrote all of the Text( commands.  They now have the exact same syntax as Output( meaning you can display more than one thing per use like Text(2,3,"Hello"," World:",A>Dec) for instance.  It also means you can define just the coordinates Text(2,3) or a compressed coordinate Text(3*256+2).  The only problem is that I had to redefine the existing "draw text here" command because that was formatted the same way, but it was a relatively new command so hopefully no one has gotten too comfortable with it.  To replace it, I will add a new command called "Text " with a space and it will act exactly like "Disp " but for small text.  So to reiterate;

Disp     <=> Text
Output() <=> Text()


They can be used interchangeably and have exactly the same syntax.

The thing I was talking about when I said the old text routines were screwed up is that they were very inefficient and I had 2 sets of routines, one for text anywhere and one for text at the current pen location.  Also, the actual coding of the text parsing was quite messy.  I combined everything to a single, smaller routine and organized the code and commands to make it more readable.  I was using ztrumpet's spider game as an example and it shrunk by almost 100 bytes and text wasn't even a part of that game.

Hopefully I will get one more major optimization before the next release because I had a revelation yesterday.  I got to thinking, what's the difference between data and subroutines?  There isn't any!  So I can mix in all the subroutines with the data as if it was data without having to make a 3rd pass which can save a lot of bytes in the executable.  The only side effect to this is that if you are defining 2 blocks of data that are split by a command that uses a subroutine, then the 2 pieces of data are no longer consecutive in memory.  I doubt anyone will have a problem with this though because its always good practice to define consecutive data together without interruptions and I've never seen anyone do it wrong in their code.

Anyway, this will be the first Axe release since the 0.2.x versions that features major optimizations that will reduce the size of just about ALL programs.
Title: Re: Axe Parser
Post by: calcdude84se on July 23, 2010, 01:43:53 pm
Cool, nice to hear you found major optimizations!
Can't wait till tomorrow! :D
Title: Re: Axe Parser
Post by: Galandros on July 23, 2010, 01:59:21 pm
Hopefully I will get one more major optimization before the next release because I had a revelation yesterday.  I got to thinking, what's the difference between data and subroutines?  There isn't any!  So I can mix in all the subroutines with the data as if it was data without having to make a 3rd pass which can save a lot of bytes in the executable.  The only side effect to this is that if you are defining 2 blocks of data that are split by a command that uses a subroutine, then the 2 pieces of data are no longer consecutive in memory.  I doubt anyone will have a problem with this though because its always good practice to define consecutive data together without interruptions and I've never seen anyone do it wrong in their code.
Great work Quigibo.

It affects somewhat disassembly but will be rare someone hand optimize Axe Parser. Maybe some curious will like to learn a bit of assembly from Axe Parser like some guys do with C and assembly.
Title: Re: Axe Parser
Post by: Builderboy on July 23, 2010, 04:43:35 pm
Nice!  Those major optimizations sound like they are really awesome!  I had no idea the Text command was so unoptimized :O Thats cool to see how much smaller it will make programs :]
Title: Re: Axe Parser
Post by: ztrumpet on July 23, 2010, 05:03:15 pm
That's cool!  Thanks for everything Quigibo, and I can't wait for the next update of Axe! ;D
Title: Re: Axe Parser
Post by: Hot_Dog on July 23, 2010, 07:54:22 pm
Quote
Features major optimizations that will reduce the size of just about ALL programs.

Quigibo, excellent work!  /me pays his respects and a slip of gold-pressed latnium
Title: Re: Axe Parser
Post by: Raylin on July 24, 2010, 11:46:03 am
Does 0.4.0 contain any syntax changes that would render old programs useless?
Title: Re: Axe Parser
Post by: ACagliano on July 24, 2010, 12:12:27 pm
Can someone please post in a forum (maybe my Star Trek progress thread) the key codes for Axe. My computer's downloader is not working so I can not download the file, then open the keycodes. I can only view it on a web page or forum. Sorry about the inconvenience.
Title: Re: Axe Parser
Post by: Magic Banana on July 24, 2010, 12:17:24 pm
Here. I think he uses this exact picture in the zip as well. It's the same as the xlib and Celtic keycodes.
(http://tibasicdev.wdfiles.com/local--files/key-codes/xlib-keys.png)
Title: Re: Axe Parser
Post by: ACagliano on July 24, 2010, 12:23:02 pm
thanks
Title: Re: Axe Parser
Post by: calcdude84se on July 24, 2010, 01:02:04 pm
I think that's a little off
/me glances at key 41, which is the [ON] key :P
Except for the [ON] key, which doesn't have a key code (it is the [ON] key), that's correct.
Good luck!
Title: Re: Axe Parser
Post by: nemo on July 24, 2010, 01:02:24 pm
i find it easiest to have  this (http://tibasicdev.wikidot.com/key-codes) bookmarked/favorited.
Title: Re: Axe Parser
Post by: Builderboy on July 24, 2010, 02:49:46 pm
Lol, the ON key will return a number, but then your program will break so it doesnt matter :P Silly xLib!\ ;D
Title: Re: Axe Parser
Post by: Quigibo on July 25, 2010, 02:39:00 am
Sorry, I didn't have time for the update today.  I left in the afternoon for something I thought would take a couple hours, but I didn't get back until almost midnight.  But I should have it tomorrow for sure.
Title: Re: Axe Parser
Post by: Tribal on July 25, 2010, 02:42:55 am
Awesome can't wait, I'm sure it won't kill us to wait another day :D
Title: Re: Axe Parser
Post by: Hot_Dog on July 25, 2010, 11:31:33 am
Sorry, I didn't have time for the update today.  I left in the afternoon for something I thought would take a couple hours, but I didn't get back until almost midnight.  But I should have it tomorrow for sure.

I had a similar story this week.  No worries!
Title: Re: Axe Parser
Post by: Raylin on July 25, 2010, 09:52:23 pm
How to use the link port commands GO!
Title: Re: Axe Parser
Post by: calcdude84se on July 25, 2010, 09:57:02 pm
Cool! Do you mind explaining the significance of being able to use big-endian pointers? ;D
Title: Re: Axe Parser
Post by: Quigibo on July 25, 2010, 10:03:10 pm
There isn't automatic linking yet, so no multilayer games until next version, but you can manipulate the link port directly for applications like sound, interaction with micro controllers, shake detectors, etc. The codes are as follows:  0-both tip,ring high, 1-tip low, ring high, 2-tip high, ring low, 3-both tip,ring low.  I might have ring and tip mixed up.

EDIT: Oh yeah, the main purpose for the big-endian was for reading 2 byte tokens from programs since they're stored in reverse order.
Title: Re: Axe Parser
Post by: calcdude84se on July 25, 2010, 10:13:05 pm
okay, nice to know :)
Title: Re: Axe Parser
Post by: Quigibo on July 26, 2010, 12:03:43 am
DO NOT USE THE APPLICATION COMPILING IN 0.4.0 YET

I'm going to investigate something, but it appears its sometimes writing over the 2nd page of the Axe app itself when it compiles the program.  I will release a 0.4.1 follow-up very soon when I fix it.
Title: Re: Axe Parser
Post by: jnesselr on July 26, 2010, 12:13:02 am
Wait, so couldn't it write over other apps as well?
Title: Re: Axe Parser
Post by: Runer112 on July 26, 2010, 12:14:19 am
I'm having trouble with reading from archive... The following code, when the program I'm trying to read from is out of archive, verifies that the data is in fact in the program:

Code: [Select]
.A
"prgmZIMG"→Str1
Disp GetCalc(Str1)→θ▸Dec
Pause 2500
For(A,0,63)
Disp i
Disp A▸Dec
Disp {A+θ}▸Dec
Pause 500
End

However, when I archive the program I'm trying to read data from and run the following code, the first display is nonzero, suggesting that it successfully located the data, but every byte read equals 65 (decimal).

Code: [Select]
.A
"prgmZIMG"→Str1
Disp GetCalc(Str1,Y₁)▸Dec
Pause 2500
For(A,0,63)
Disp i
Disp A▸Dec
Disp {A+Y₁}▸Dec
Pause 500
End

Any ideas what's going on here? Am I doing something wrong or is Axe doing something wrong?
Title: Re: Axe Parser
Post by: jnesselr on July 26, 2010, 12:22:56 am
65 In binary is 01000001, or 63+2.  The first and sixth bit are set. Your code looks good, so I'm thinking it's probably axe itself.  Try pausing until a key is pressed in the loop, and clear the screen after that.
Title: Re: Axe Parser
Post by: calc84maniac on July 26, 2010, 12:32:34 am
Perhaps you aren't allowed to use Y1 as a second argument to an operation. Maybe Y1+A instead?
Title: Re: Axe Parser
Post by: Quigibo on July 26, 2010, 12:33:56 am
Yeah, its a bug, change it to Y₁+A instead because Y₁ has to be first right now.

EDIT: Wow!  That was a really stupid mistake, I fixed it now.
Title: Re: Axe Parser
Post by: Raylin on July 26, 2010, 12:55:20 am
Hmm.

Will we see an update tonight?
Title: Re: Axe Parser
Post by: Builderboy on July 26, 2010, 01:01:06 am
Awesome job on Axe 0.4.0 :) Although thats too bad about the app compiling D: What seems to be the problem?
Title: Re: Axe Parser
Post by: Quigibo on July 26, 2010, 01:16:56 am
I have no idea, I've had so much trouble with it because the emulators don't pick it up and its usually either extremely rare or extremely hardware specific and there appears to be no pattern with any of it.  It all comes down to me guessing what the problem could be and then hoping I fixed it somehow.  I am going to try another strategy soon...
Title: Re: Axe Parser
Post by: Builderboy on July 26, 2010, 01:32:37 am
Yikes, i hope you can fix it O.O
Title: Re: Axe Parser
Post by: Runer112 on July 26, 2010, 01:29:35 pm
Quick question: can files like Y0-Y9 be reused in a program?
Title: Re: Axe Parser
Post by: calcdude84se on July 26, 2010, 01:31:49 pm
AFAIK yes. Just reuse it with GetCalc.
Title: Re: Axe Parser
Post by: imPersonator on July 26, 2010, 04:34:48 pm
Can Axe write to external variables?  In the documentation it shows how to read them, but not write to them.
Title: Re: Axe Parser
Post by: nemo on July 26, 2010, 04:42:11 pm
yes, you can write to external variables.
Code: [Select]
"Str1"->Str1
"0123456789ABCDEF"->Str2
GetCalc(Str1,16)->A    .the OS var Str1 is created and A is now a pointer to the beginning of the data
Copy(Str2,A,16)

after you exit the program, Str1 will have "0123456789ABCDEF" in it.
Title: Re: Axe Parser
Post by: imPersonator on July 26, 2010, 04:48:03 pm
Thanks! That almost exactly what I was trying (even the same string for Str2), but I didn't have the "->A" part at the end of GetCalc.  Why can't I just use Str1 as the pointer?
Title: Re: Axe Parser
Post by: calcdude84se on July 26, 2010, 04:51:28 pm
Because normally Str1 is, well, a pointer. But it always points to data contained w/in the program.
Also, with 0.4.0, you can inline the text like 'GetCalc("Str1",16)->A'
Title: Re: Axe Parser
Post by: Builderboy on July 26, 2010, 04:58:42 pm
Because when you initilize Str like this:

"Str1"->Str1

Its not initialized as a pointer to the Basic variable Str1, its initialized as a String that you can use in your program, that contains the text "Str1".  GetCalc parses the String, and returns a pointer that actually points to the file/variable that is inside the string.
Title: Re: Axe Parser
Post by: Runer112 on July 26, 2010, 09:28:38 pm
Another quick question: When using GetCalc() to designate space for an appvar, does GetCalc() automatically set all the designated bytes to 0? Or do I have to do that myself with Fill()? And while I'm on the topic of Fill(), the proper way to fill X bytes with a value is Fill(Value→{Pointer},X-1), right?
Title: Re: Axe Parser
Post by: _player1537 on July 26, 2010, 10:20:47 pm
for the first question, no you will need to use Fill() or Copy() to do so (if you want it to be all zeros, fill is what you want).  Personally I haven't used fill(), so I can't help you there
Title: Re: Axe Parser
Post by: Deep Toaster on July 26, 2010, 10:39:49 pm
For the second, no, it's not. I just checked (with Axe 0.4.0). You have to do

Code: (Axe BASIC) [Select]
Value→{Pointer}
Fill(Pointer,X-1)

I think it's because Fill( takes the pointer of the data, but Value→{Pointer} leaves the data value itself. In otherwords, you're Fill(ing the data at pointer Value.
Title: Re: Axe Parser
Post by: Quigibo on July 26, 2010, 11:12:58 pm
Well, you're both partially correct.  If the Pointer is a static pointer, then Deep Thought is correct, because the return value is not the pointer, but the value you're storing to the pointer.  On the the other hand, Runer is correct for non-static pointers such as a pointer to an appvar because then the return value is the location rather than the value stored.
Title: Re: Axe Parser
Post by: Deep Toaster on July 26, 2010, 11:33:57 pm
Oh, so the one line would work if Value was a GetCalc( statement?
Title: Re: Axe Parser
Post by: ACagliano on July 27, 2010, 12:02:32 pm
How exactly do you use the new PORT commands to send data?
Title: Re: Axe Parser
Post by: Raylin on July 27, 2010, 01:32:17 pm
I dunno if those are there to establish a foundation for the automated linking or what...

Perhaps it involves bit manipulation?
Title: Re: Axe Parser
Post by: TIfanx1999 on July 27, 2010, 02:56:04 pm
How exactly do you use the new PORT commands to send data?
There isn't automatic linking yet, so no multilayer games until next version, but you can manipulate the link port directly for applications like sound, interaction with micro controllers, shake detectors, etc. The codes are as follows:  0-both tip,ring high, 1-tip low, ring high, 2-tip high, ring low, 3-both tip,ring low.  I might have ring and tip mixed up.

EDIT: Oh yeah, the main purpose for the big-endian was for reading 2 byte tokens from programs since they're stored in reverse order.

Apparently, it hasn't been implemented yet. Gotta wait till next version.
Title: Re: Axe Parser
Post by: calcdude84se on July 27, 2010, 04:13:20 pm
So, quick tutorial on Port. (And the link port in general)
As you know, the link port has two lines on which to send data, the tip and the ring. Each can be in one of two states, high or low.
When you write a set bit, it pulls that line low, while writing a reset bit allow it to go high.
Bit 0 is the tip and bit 1 is the ring.
Like Quigibo said, you write 0 to let both go high, 1 to pull the tip low and let the ring go high, 2 to let the tip go high and pull the ring low, and 3 to pull both low.
Reading, however, is somewhat different. Instead of a set bit indicating that it is low, a set bit indicates that the line is high. A reset bit indicates that the line is low.
This means that when you read 0, both are low; 1, the tip is high and the ring is low; 2, the ring is high and the tip is low; 3, both are high.
With respect to two connected calcs, a line is read as low if either calc is pulling it low. The line will only be read as high if both calcs are letting it go high.
Hope this helps! :D
Title: Re: Axe Parser
Post by: Hot_Dog on July 27, 2010, 04:27:43 pm
So, what does high and low mean?  Does it mean priority in recieving data, the speed at which data is sent/recieved, or what?
Title: Re: Axe Parser
Post by: Builderboy on July 27, 2010, 04:44:22 pm
This is no data transfer routine if i remember correctly, this is direct access to the hardware, so you have to write your own data sending routines if you want to send actual numbers.  Here is my understanding of the command:

The IO cable has 3 wires, called the tip, ring, and ground.  Ground is not used for transfering data, so we will only concern ourselves with the tip and the ring.  The ring and the tip can either be in two 'states' or voltages, high and low.  The calculator can either "pull" a ring/tip low, or let it go high.  What this means is that if it is "pulled" low, the calculator forces the tip/ring to go into a low voltage.  Even if the other calculator is letting the voltage go high, the tip/ring will still be at low.  Thats where the term "pulling low" comes from, because the calculator "pulls" and forces the voltage.  When the calculator "lets the voltage go high" it does not force it, but only lets it go.  If both calculators let go, the voltage goes high.  If either one (or both) of the calculators is pulling low, the line will be read as low.

To SET the cable, use the #->Port command.
0 lets both lines go high
1 pulls the tip low
2 pulls the ring low
3 pulls both lines low

To READ the port, use the Port->Var command.
0 means both lines are low
1 means tip is high
2 means ring is high
3 means both lines are high

Yeah reading and writing is confuzzling, but thats the way it works unfortunately.  Note that i haven't actually used the link port at all so all of this is conceptual :P if any of this is incorrect please let me know!
Title: Re: Axe Parser
Post by: calcdude84se on July 27, 2010, 04:54:47 pm
Yeah, sorry about that. Low and high are just different states, which are represented by different voltages. It's easiest to just consider it to be a bit (which is all it really is, anyway ;D)
Title: Re: Axe Parser
Post by: Quigibo on July 28, 2010, 04:51:17 am
Let me explain the new masked sprite routine because its really cool.  The first layer is the sprite and the second layer is the mask.  The way it works is that anything drawn on the first layer is going to be black or gray and any bit that is neither in the sprite layer nor the mask layer becomes transparent.  So the codes are 11 for black, 10 for gray, 01 for white, and 00 for transparent.  Think of it like a controlled Pt-Off() that also draws gray since you can control which pixels to see through when drawing.  The routine is slower than the normal sprite drawing but much faster than trying to draw to both layers individually.  Also, due to the choice of color codes, you can use this for monochrome masking as well with the first layer being the sprite you want to draw and the second layer is black in the areas you want to draw over.  However keep in mind that the routine still draws to both buffers so make sure you aren't storing anything there first.  Here is an example

Layer1:
    ████████
  ██        ██
██            ██
██    ████    ██
██    ████    ██
██            ██
  ██        ██
    ████████

Layer2:
    ████████
  ████████████
████████████████
██████    ██████
██████    ██████
████████████████
  ████████████
    ████████

Result:
░░░░████████░░░░
░░██        ██░░
██            ██
██    ████    ██
██    ████    ██
██            ██
░░██        ██░░
░░░░████████░░░░

The crosshatched color means those pixels don't change when drawing the sprite (transparent).

Also, please let me know if you are still getting errors that you were getting before.  I tried to fix as much as I could but since I still can't figure out the problem, that means I'm just guessing so I need your help to see if anything actually got fixed.
Title: Re: Axe Parser
Post by: Raylin on July 28, 2010, 08:52:25 am
Can't download yet.
I'm on a public computer.

How fast is the routine? Can you still animate?
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 28, 2010, 01:23:38 pm
Let me explain the new masked sprite routine because its really cool.  The first layer is the sprite and the second layer is the mask.  The way it works is that anything drawn on the first layer is going to be black or gray and any bit that is neither in the sprite layer nor the mask layer becomes transparent.  So the codes are 11 for black, 10 for gray, 01 for white, and 00 for transparent.  Think of it like a controlled Pt-Off() that also draws gray since you can control which pixels to see through when drawing.  The routine is slower than the normal sprite drawing but much faster than trying to draw to both layers individually.  Also, due to the choice of color codes, you can use this for monochrome masking as well with the first layer being the sprite you want to draw and the second layer is black in the areas you want to draw over.  However keep in mind that the routine still draws to both buffers so make sure you aren't storing anything there first.  Here is an example

Layer1:
    ████████
  ██        ██
██            ██
██    ████    ██
██    ████    ██
██            ██
  ██        ██
    ████████

Layer2:
    ████████
  ████████████
████████████████
██████    ██████
██████    ██████
████████████████
  ████████████
    ████████

Result:
░░░░████████░░░░
░░██        ██░░
██            ██
██    ████    ██
██    ████    ██
██            ██
░░██        ██░░
░░░░████████░░░░

The crosshatched color means those pixels don't change when drawing the sprite (transparent).

Also, please let me know if you are still getting errors that you were getting before.  I tried to fix as much as I could but since I still can't figure out the problem, that means I'm just guessing so I need your help to see if anything actually got fixed.
Wow nice, that will come handy for sure for grayscale games. Nice update. I will try to test app compiling when the app exist at one point, although I cannot promise yet.

Also although I am late on this, the previous update was pretty great too. I also noticed my ball game dropped by a few bytes from 0.3.3 to 0.4.0
Title: Re: Axe Parser
Post by: Magic Banana on July 28, 2010, 04:46:51 pm
So, about that new sprite masking routine, if I were to use it for monochrome sprites, would I need to run it in 6MHz mode or would it be fine in 15MHz mode?

EDIT:Also, just to make sure, if I were to use grayscale sprites with this routine, it's required to run in 6MHz mode, right?
Title: Re: Axe Parser
Post by: FinaleTI on July 28, 2010, 04:54:05 pm
The routine only renders the sprites, you still need to call DispGraphr to display them, so it still needs to be in 6mHz. (I'm pretty sure.)
At least for displaying greyscale. Rendering the sprites should work at either speed, cause I think it's just a modified version of the original sprite routine.
Title: Re: Axe Parser
Post by: Raylin on July 28, 2010, 09:43:20 pm
So, Axe is pulling shenanigans.
Can someone tell me how to use the Pt-Command()->BUFF please?

Thanks.
Title: Re: Axe Parser
Post by: calcdude84se on July 28, 2010, 09:52:12 pm
You use it just like normal, but with the -> followed by the buffer on the end, where BUFF is any 768-byte buffer.
Pt-On(X,Y,Pic0)->L3 is the equivalent of Pt-On(X,Y,Pic0)r, for example.
Title: Re: Axe Parser
Post by: Quigibo on July 28, 2010, 11:05:12 pm
Generally if you're trying to maximize speed, you keep the whole program in 15MHz mode EXCEPT DispGraph with grayscale modifiers and direct keys.  So you can simply do this to update the screen:

:Normal
:DispGraphr
:Full

Title: Re: Axe Parser
Post by: Runer112 on July 29, 2010, 01:14:33 am
I always have the auto opts file open when I'm coding, to try to keep my programs as small as possible. However, this just shows the size of things that are automatically optimized. Could you add a file that doesn't show optimization sizes, but just command/operation sizes in general?
Title: Re: Axe Parser
Post by: imPersonator on July 29, 2010, 11:06:56 am
I'm trying to convert a string to hex data, so if Str1 was "0123456789ABCDEF" then I would want to put [0123456789ABCDEF] into Pic1. Here's what I have so far, but it's not working right.
Code: [Select]
"0123456789ABCDEFG"->Str1
[00000000000000000]->Pic1
For(A,0,7
A*2+Str1->E
{E}-48->C
A*2+Pic1->G
C-((C>9)*7)->H
{E+1}-48->C
C-((C>9)*7)->M
H*16+M->{G}
I'm trying to convert the character values of the letters in Str1 into the numbers they represent.
Title: Re: Axe Parser
Post by: calc84maniac on July 29, 2010, 11:22:45 am
I think A*2+Pic1 should be A+Pic1.
Title: Re: Axe Parser
Post by: imPersonator on July 29, 2010, 11:26:33 am
That worked! Thanks.
Title: Re: Axe Parser
Post by: Runer112 on August 02, 2010, 03:56:11 pm
Does anyone know where the OS stores the current pen X and Y values?
Title: Re: Axe Parser
Post by: Quigibo on August 02, 2010, 04:11:34 pm
Yeah, its E86D7 and E86D8.  I'll eventually have useful addresses tokenized so you won't have to look them up manually.
Title: Re: Axe Parser
Post by: Raylin on August 02, 2010, 07:56:17 pm
Tokenized addresses? What would you use for that?
Title: Re: Axe Parser
Post by: Hot_Dog on August 02, 2010, 08:38:11 pm
Awesome job on the masked sprite routine!  I'm glad to see it finally implemented
Title: Re: Axe Parser
Post by: Runer112 on August 03, 2010, 12:59:31 am
Does anyone know how to change the allocated memory size for something without losing the contained data? For example, how does the operating system accommodate changes in program size while the user is editing a BASIC program?

EDIT - And another question: Is it possible to retain OS-style getKey functionality with custom interrupts enabled?
Title: Re: Axe Parser
Post by: Builderboy on August 03, 2010, 01:07:16 am
There are some complicated OS calls going on in that which involves a lot of data shifting and such.  I dont pretend to be an expert so you might want to hop onto IRC and ask calc84 or Iambian or any other Asm guru out there.
Title: Re: Axe Parser
Post by: Quigibo on August 03, 2010, 01:34:24 am
Yeah, there are several bcalls for that, but one of them is way too complicated for Axe, the other one i might be able to add that basically just allocates X number of bytes to an OS variable.  But every time you do that, you have to update your program pointer (and in fact all pointers n RAM if you're reading from many variables at once) since things move around during memory allocation.

The OS-getkey is definitely a possibility, but it slows down interrupts and produces non-uniform pauses.  I think I will use fnInt()r for that eventually so you can choose.
Title: Re: Axe Parser
Post by: Builderboy on August 03, 2010, 01:41:05 am
That would be a really useful routine for people who want to do some editing to programs :)
Title: Re: Axe Parser
Post by: Raylin on August 03, 2010, 01:42:50 am
I agree.
The OS getKey would be how much slower though?
Title: Re: Axe Parser
Post by: Quigibo on August 03, 2010, 02:16:34 am
Its a lot more than just the getkey routine.  There are other things going on such as the run indicator, silent link checking, and some other OS stuff and that's in addition to what you already have in your interrupt.  Its not terribly slow but its certainly noticeable when speed is really critical.
Title: Re: Axe Parser
Post by: Hot_Dog on August 03, 2010, 02:20:18 am
Plus the fact that any B_CALL routine requires roughly 1075 clock-ticks to enter and leave
Title: Re: Axe Parser
Post by: Builderboy on August 03, 2010, 02:21:54 am
That many?  Is that just the nature of BCalls or just TI stupidness?
Title: Re: Axe Parser
Post by: Hot_Dog on August 03, 2010, 02:26:03 am
That many?  Is that just the nature of BCalls or just TI stupidness?

Probably both.  The calculator needs time to switch between archive pages, and of course, the OS B_CALLS are part of the flash memory.
Title: Re: Axe Parser
Post by: Quigibo on August 08, 2010, 03:07:43 am
In case anyone is wondering what's been going on recently with the lack of the promised Axe update last week, the main reason is the time I've been spending to get the automatic backups working.  I spent about 5 days writing a ton of extra code since the OS did not support the archiving of invisible programs.  After all that testing I finally had it all ready to be uploaded and I sent it to my calculator to do some last minute testing.  That's when it gave me an ERR: Undefined when trying to create a backup.  It turns out the trick I was using was no longer possible on OS 2.4x and so that really set me back.  The only way I saw I could get it done now was writing directly to the flash.  So I wrote routines for that.  Then I realized that not only do I have to write my own routine for that, I have to write my own symbol table searching, vat entry updater, and program creator routines since I can't use the OS's routines given that they no longer support the format.  It just got too crazy and I finally gave up.  So I now have to throw away about a weeks worth of code and start fresh.

The main reason I had to make the files invisible was to be 100% sure that important appvars do not get overwritten accidentally.  But I've though of a simpler way to do that now by checking if a non-backup file of the same name exists first and then refuse to backup the file until you manually delete it, that way you won't accidentally erase it.  But unfortunately, now backups will crowd the memory management list which I really didn't want, but I guess on the plus side you can erase the backups without having to go into the Axe app.

Anyway, the update should be ready now in less than 24 hours I hope.  The backup feature, when it was working on the older OS, is like a night-and-day difference in how you program.  I feel like I would never program without it now because its such a huge convenience.  Its definitely a reason to upgrade if you have an older version.  I fixed a lot of other little bugs too to make it more stable.
Title: Re: Axe Parser
Post by: Raylin on August 08, 2010, 03:24:21 am
Sweet.

So, automatic backups ARE in the next update? o.o
Title: Re: Axe Parser
Post by: Quigibo on August 08, 2010, 03:28:13 am
Yes.  That and about 10 other new things, its going to be a fairly large update.
Title: Re: Axe Parser
Post by: Raylin on August 08, 2010, 03:33:02 am
Full of win. :D
Title: Re: Axe Parser
Post by: Builderboy on August 08, 2010, 03:48:13 am
Yessss automatic backups are going to be so awesome :) Does it take much extra time to make the backups?
Title: Re: Axe Parser
Post by: Quigibo on August 08, 2010, 04:34:09 am
It takes about the same amount of time as if you were to archive a program from the memory management window.  Similar to apps it does wear on the flash, but at least 8 times less wear with large programs than application compiling and you don't have to defragment each time you create a backup, only on the rare occasions when you're asked to garbage collect.

Another thing to note is that backups don't have be automatic.  You can manually create backup copies whenever you want by pressing 'B' in the compile menu in case you're concerned about running out of flash, wear on the flash, or the extra time it takes.  Its also nice if you have a lot of programs you want to backup without compiling them first.
Title: Re: Axe Parser
Post by: jnesselr on August 08, 2010, 10:24:55 am
So what other new features are there?
Title: Re: Axe Parser
Post by: SirCmpwn on August 08, 2010, 11:42:43 am
Nice!
Can you disable this feature, though?
Title: Re: Axe Parser
Post by: jnesselr on August 08, 2010, 02:01:45 pm
Nice!
Can you disable this feature, though?
He said that they don't have to be automatic, so I'm guessing there is an option for it.
Title: Re: Axe Parser
Post by: SirCmpwn on August 08, 2010, 03:01:36 pm
Okay, that's good.
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 08, 2010, 03:51:05 pm
In case anyone is wondering what's been going on recently with the lack of the promised Axe update last week, the main reason is the time I've been spending to get the automatic backups working.  I spent about 5 days writing a ton of extra code since the OS did not support the archiving of invisible programs.  After all that testing I finally had it all ready to be uploaded and I sent it to my calculator to do some last minute testing.  That's when it gave me an ERR: Undefined when trying to create a backup.  It turns out the trick I was using was no longer possible on OS 2.4x and so that really set me back.  The only way I saw I could get it done now was writing directly to the flash.  So I wrote routines for that.  Then I realized that not only do I have to write my own routine for that, I have to write my own symbol table searching, vat entry updater, and program creator routines since I can't use the OS's routines given that they no longer support the format.  It just got too crazy and I finally gave up.  So I now have to throw away about a weeks worth of code and start fresh.

The main reason I had to make the files invisible was to be 100% sure that important appvars do not get overwritten accidentally.  But I've though of a simpler way to do that now by checking if a non-backup file of the same name exists first and then refuse to backup the file until you manually delete it, that way you won't accidentally erase it.  But unfortunately, now backups will crowd the memory management list which I really didn't want, but I guess on the plus side you can erase the backups without having to go into the Axe app.

Anyway, the update should be ready now in less than 24 hours I hope.  The backup feature, when it was working on the older OS, is like a night-and-day difference in how you program.  I feel like I would never program without it now because its such a huge convenience.  Its definitely a reason to upgrade if you have an older version.  I fixed a lot of other little bugs too to make it more stable.
I'm gonna love this backup feature. Glad you figured out the problem. Sometimes those TI changes are annoying x.x. I still remember the whole TI-Boy SE saga. I can't wait for the update ^^

EDIT: By the way, for those who can access OmnomIRC, Netham45 logs from Wednesday has some talk about the above, as Quigibo held a small Axe discussion on IRC that night (although for odd reasons, there seemed to be an unusually low amount of people online that night for a wednesday...). He posted a screenshot, too, showing the backup option.
Title: Re: Axe Parser
Post by: Quigibo on August 08, 2010, 09:55:34 pm
I updated the doc to include more information about the backups and the new library header if you're curious about those.

I fixed my auto-backups now and much faster than I expected so I decided to use the extra time to see if I could easily implement the external library feature that everybody wants.  And that also was surprisingly not too difficult, but the only catch is that you can't nest libraries because each nested library needs 19 bytes of ram and I don't have enough space to have a big array for that.

A cool thing about the libraries is that those of you who hate having to scroll through all that data at the beginning of your program now have a solution!  You can create a separate file that contains nothing but your data in a separate file and then include it as a library as the first line of code in your main program.  The libraries work as direct insertions so its as if the same data were inserted right at that spot.  You can also keep these files archived so that you have even more free ram left to create the rest of your program.

There are a ton of other uses for this as well.   If you want to make a universal library like a physics engine for example, you can make the first line of the library file a jump to the last line so that it can be inserted once anywhere in the code and then the client has access to all the subroutines included in the library file.  Due to the expansion of available names in labels to 3 characters, you can be fairly sure that your label name isn't already taken with some clever prefixes.

And I didn't even start talking about the backups yet.   They are very strait forward so you can probably figure them out without needing any tutorial.  Selecting a backup restores it, pressing "del" deletes it, and pressing "B" on the source creates it.  In the options, there is a new mode to do it automatically.  That's about it, but its extremely useful.  Anyway, enjoy!
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 08, 2010, 11:05:12 pm
Wow I love the new features, especially include files. My data's going there for sure. Can they be archived like the rest of the source? Also does the total amount of memory the libraries and the root program takes have to be equal or higher to your total amount of RAM or can we compile larger stuff? Regardless, it is great, because scrolling through a lot of data can be annoying when debugging for a long while. It's also easier to find the data now.

Good job again Quigibo!
Title: Re: Axe Parser
Post by: Raylin on August 08, 2010, 11:13:51 pm
^This.

EDIT: Tutorial on the EXP1eEXP2 command please?

EDIT 2: Can you put your subroutines in a library too?
Title: Re: Axe Parser
Post by: _player1537 on August 09, 2010, 12:54:20 am
@raylin, if you happen to know assembly, this would be ~equivilant to:
Code: [Select]
bit bit#,A
Basically, say that you have 0000100b stored in A.  Then you do: "Ae5".  This would return 1, "Ae6" or "Ae4" would both return 0.  (did I explain it correctly quigibo?)
Title: Re: Axe Parser
Post by: Quigibo on August 09, 2010, 01:14:00 am
Almost, Ae4 would be 1 and Ae3 and Ae5 would be 0.  You start counting from the 0th bit to the 7th bit.  Its an advanced math command and it shouldn't be needed that often so don't worry too much if it seems confusing.  That particular command is aimed for assembly programmers although they might also hate me since its the reverse order of actual asm, but this convention actually makes more sense since data is usually read left to right like pixel data for instance.
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 09, 2010, 02:46:30 am
To make sure I understand this correctly, Ae0 through Ae2 and Ae6 would be 0 as well, right?
Title: Re: Axe Parser
Post by: calc84maniac on August 09, 2010, 02:56:36 am
Sorry, I'm one of those disgruntled asm programmers who thinks counting should start from the right. :P The way you have it set up, you can't even extract the upper 8 bits of a value. :O
Title: Re: Axe Parser
Post by: Quigibo on August 09, 2010, 03:21:15 am
Right, that's because the bit command e is for 8 bit numbers.  ee will be for 16 bit numbers, also counting from the left, I just didn't have time to add that yet.  Also, I will add the auto-opts next version to extract specific bits.

Another reason for counting from the left is because its much more optimized using the add hl,hl instruction (for 16 bit numbers) than trying to shift the number to the right or adding overhead to negate the bit number, so its a more optimized routine.
Title: Re: Axe Parser
Post by: Raylin on August 09, 2010, 10:05:43 am
Protip

Regardless of what on-calc language you are programming in, you can abuse the backup system in Axe for BASIC programs too.

Code: (BASIC) [Select]
:.<name of program here>
Put that at the beginning of the code and make a backup MANUALLY. Then, erase that line of code from the beginning of the actual program. It probably seems like a big hassle to a lot of people but, if you're chaining hooks from about 3 different APPs, I call it a necessity.
Title: Re: Axe Parser
Post by: Runer112 on August 10, 2010, 03:17:03 am
What exactly are the advantages of compiling to an app currently? And what could they be in the future?
Title: Re: Axe Parser
Post by: Quigibo on August 10, 2010, 04:15:15 am
Mainly that you get the whole 16KB space for execution instead of the roughly 8KB execution limit with regular programs.  It also allows you to allocate much more ram since the program itself is not running from the ram.  There is a possibility of allowing apps to be 2 pages in the future with a second page of data only, but I don't know how feasible that is so I can't say for sure.  There are disadvantages though, so unless memory is an issue, I would just stick with programs.
Title: Re: Axe Parser
Post by: Runer112 on August 10, 2010, 09:49:18 pm
I was just looking at the auto-ops list, and I'm just wondering if all of these entries are correct, because they seem pretty odd. For instance, /10 is not only an auto-opt, but smaller than /2? And //64 is an auto-opt but /64 is not? Not to mention odd things like 16-bit checks being smaller than 8-bit checks.
Title: Re: Axe Parser
Post by: Quigibo on August 10, 2010, 09:57:23 pm
They are all correct, yes.  /10 is only there because there is a B_CALL for that specific number and I figured that if you're going to be dividing by a constant ten, then you're probably trying to display a decimal number or something like that in which case the micro seconds don't matter and its better to have a smaller size.  The division is indeed crazy, but that's correct, it takes more bytes to do a unsigned division by 64 than it does for a signed division (unless someone can come up with a smaller one).  The 16 bit check routines are identical to the 8-bit checks, they just have different numbers since it counts from the left.  Unless you mean the routine itself?  That's due to a speed optimization since an extra byte more than doubles the speed, I took it.

There are a few other cases like that where I take the extra speed instead of a smaller size.  My rule is if 1 byte increases speed more than 50% faster then I don't mind adding it.  That's why *2048 is 6 bytes instead of 5 for instance.
Title: Re: Axe Parser
Post by: Builderboy on August 11, 2010, 02:26:20 am
Tell me, is Bit checking the buffer faster than pixel testing?  If so, how much?
Title: Re: Axe Parser
Post by: Quigibo on August 11, 2010, 03:45:13 am
If you already had the location of the buffer's byte, I would say yes (like from scanning a horizontal line of the screen).  But if you have to find it given just an X and a Y, the extra math to find the particular byte and bit from the buffer is going be less optimized than if you just used the pxl-test command since it does all that math for you but in optimized assembly.
Title: Re: Axe Parser
Post by: ACagliano on August 17, 2010, 07:50:37 pm
Is it possible to convert or otherwise read the HEX data a program contains in Axe? Any of the Disp PTR commands only show the TOKEN.

Lets say I want to tell a user the hex a program contains. So I do:

"progOFFBY1"->Str1A
GetCalc(Str1A)->P

Now lets say I want the first byte of the program:

Disp {P}->Tok  but that only disps the token, like "real(". I want the hex. What do I do?
Title: Re: Axe Parser
Post by: calcdude84se on August 17, 2010, 08:03:51 pm
You'll have to do it by hand. Assuming you don't need T, then the following code will display 2 hex digits corresponding to the data at P.
Code: [Select]
Disp {P}/16->T>=10*7+T+48>Char,{P}^16->T>=10*7+T+48>CharThe condition is to add the right amount to make $30+$10 $41 (which is A)
Title: Re: Axe Parser
Post by: nemo on August 18, 2010, 12:19:26 pm
minor question.

which is faster, pxl-Test(X,Y) or this:
Code: [Select]
.eulers 'e'
{Y*12+(X/8)+L6} e X^8
Title: Re: Axe Parser
Post by: Runer112 on August 18, 2010, 02:08:49 pm
minor question.

which is faster, pxl-Test(X,Y) or this:
Code: [Select]
.eulers 'e'
{Y*12+(X/8)+L6} e X^8


See:

If you already had the location of the buffer's byte, I would say yes (like from scanning a horizontal line of the screen).  But if you have to find it given just an X and a Y, the extra math to find the particular byte and bit from the buffer is going be less optimized than if you just used the pxl-test command since it does all that math for you but in optimized assembly.
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 21, 2010, 03:30:44 am
Nice update again, keep up the good work :)
Title: Re: Axe Parser
Post by: calcdude84se on August 21, 2010, 12:12:47 pm
Nice to see ElseIf and Else!If; that should help reduce some excess End's in programs.
Keep up the good work! :D
Title: Re: Axe Parser
Post by: LordConiupiter on August 21, 2010, 02:07:25 pm
Yes, I'm lovin' it! very nice update again!
Title: Re: Axe Parser
Post by: Hot_Dog on August 21, 2010, 11:02:19 pm
Nice to see ElseIf and Else!If; that should help reduce some excess End's in programs.
Keep up the good work! :D

Agreed!  Great work, Quigibo
Title: Re: Axe Parser
Post by: qazz42 on August 21, 2010, 11:11:26 pm
wait, we have endif and elseif's now?


:O OH EMM GEE!
Title: Re: Axe Parser
Post by: willrandship on August 21, 2010, 11:20:38 pm
Wow...75 pages.

I was wondering: is there a good way to easily get less flickery gray? it bugs me that I can't just type in Pt-On( and Pt-On()r and see some smooth gray! I wouldn't mind typing more, but I don't know what to type :P
Title: Re: Axe Parser
Post by: Runer112 on August 22, 2010, 12:51:56 am
Wow...75 pages.

I was wondering: is there a good way to easily get less flickery gray? it bugs me that I can't just type in Pt-On( and Pt-On()r and see some smooth gray! I wouldn't mind typing more, but I don't know what to type :P

What do you mean? The grayscale methods currently supported by Axe are just about as good as gray gets. The screen on TI-83s and TI-84s weren't built for grayscale, have no automated processes for grayscale, and are relatively slow. As far as im concerned, based on the hardware we have to work with, Axe's grayscale routines do an amazing job.

The only way to get less flickery gray is to update the screen more often. If you're doing things like drawing sprites, a good way to help maximize the update frequency is to make sure you're only drawing things on the screen that moved or weren't there before and actually need to be redrawn. Also, optimize your program for speed as much as you can. Use as little processing power as you can between screen updates, and try to make sure the time between updates is somewhat constant and doesn't have large spikes of processing time used up between two screen updates.

If you wondering why there's no automated process to display grayscale without having to call DispGraphr/DispGraphrr, it's because that would require interrupts to update the screen automatically, but the display routines don't work with interrupts. You wouldn't want that anyways, because it would display the buffer contents a potentially inopportune moments, which could cause tearing (the screen updating while the buffers are being updated, resulting in displaying part of the new image and part of the old).
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 22, 2010, 01:12:01 am
You need to use DispGraphr or DispGraphrr for gs. So far Axe does a nice job as Runer said. For higher quality you need to update often as he says, but keep in mind it may slow down the program a lot if you add too many.

Title: Re: Axe Parser
Post by: Happybobjr on August 22, 2010, 09:05:25 am
the more dispgraphs the faster it goes.
Title: Re: Axe Parser
Post by: shmibs on August 22, 2010, 10:13:37 am
The only way to get less flickery gray is to update the screen more often. If you're doing things like drawing sprites, a good way to help maximize the update frequency is to make sure you're only drawing things on the screen that moved or weren't there before and actually need to be redrawn. Also, optimize your program for speed as much as you can. Use as little processing power as you can between screen updates, and try to make sure the time between updates is somewhat constant and doesn't have large spikes of processing time used up between two screen updates.

If you wondering why there's no automated process to display grayscale without having to call DispGraphr/DispGraphrr, it's because that would require interrupts to update the screen automatically, but the display routines don't work with interrupts. You wouldn't want that anyways, because it would display the buffer contents a potentially inopportune moments, which could cause tearing (the screen updating while the buffers are being updated, resulting in displaying part of the new image and part of the old).

i've done 4lvl with interrupts in axe and it was far less flickery(and that was with the map being updated every time the sprites were). Tearing isnt an issue because with interrupts the screen is being updated so often that user never notices the difference. however, it is very processor intensive, and if your goal is an action game then the dispgraphs are definitely your best bet
Title: Re: Axe Parser
Post by: Happybobjr on August 22, 2010, 02:03:42 pm
^
||

I thought custom interrupts didn't work with 4lvl grayscale
Title: Re: Axe Parser
Post by: qazz42 on August 22, 2010, 02:12:05 pm
I cant seem to find the elseif token x.x
Title: Re: Axe Parser
Post by: calc84maniac on August 22, 2010, 02:34:25 pm
I cant seem to find the elseif token x.x
You just type the Else and If tokens together.
Title: Re: Axe Parser
Post by: Builderboy on August 22, 2010, 02:34:45 pm
I belive you just combine the Else and If tokens? :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 22, 2010, 03:37:33 pm
the more dispgraphs the faster it goes.
If you mean the grayscale refresh, yes. If you mean the program execution, no. In Super Sonic Ball, if I add grayscale then run a for loop executing dispgraphr 100 times, there will be a considerable drop in speed
Title: Re: Axe Parser
Post by: Happybobjr on August 22, 2010, 04:24:37 pm
the more dispgraphs the faster it goes.
If you mean the grayscale refresh, yes. If you mean the program execution, no. In Super Sonic Ball, if I add grayscale then run a for loop executing dispgraphr 100 times, there will be a considerable drop in speed

ya i meant for grayscale refresh.
Title: Re: Axe Parser
Post by: shmibs on August 22, 2010, 07:27:06 pm
^
||

I thought custom interrupts didn't work with 4lvl grayscale

dispgraphrr doesnt, but i didnt use that command
Title: Re: Axe Parser
Post by: Quigibo on August 22, 2010, 07:43:06 pm
There is a difference between using a command while interrupts are on and using one in an interrupt routine.  I think all commands will work fine with intterupts in the background but there are a few like DispGraphrr that don't work in the interrupt routine itself.
Title: Re: Axe Parser
Post by: Happybobjr on August 22, 2010, 07:44:25 pm
oohhhh... thanks i understand
Title: Re: Axe Parser
Post by: Builderboy on August 22, 2010, 08:35:06 pm
And dont some sometimes turn off interrupts accidentally?
Title: Re: Axe Parser
Post by: guy6020665 on August 23, 2010, 05:48:58 pm
How would I read from matrices using axe?

Would I do something similar to the following?

Code: [Select]
"[A]->GDB1
getcalc(GDB1)->A
Disp A(1,1)

Can't actually test this at the moment but I wanted to be able to use an axe program to display the screen faster than a basic one would.
Title: Re: Axe Parser
Post by: FinaleTI on August 23, 2010, 07:08:07 pm
I haven't messed with it myself, but you'll have to read each cell like it is a byte in an Axe matrix. Unfortunately, matrices use floating point numbers, so you have to use the new converter command. You also have to keep in mind each floating point number is 9 bytes.
Title: Re: Axe Parser
Post by: Runer112 on August 23, 2010, 07:18:16 pm
There is no built-in support for reading specific entries from OS matrices or lists. However, the most recent version of Axe (0.4.4) includes the new float{PTR} function, which is the fPart() function. This converts a 9-byte real number from the OS to a 2-byte integer Axe can understand. This would not accurately convert decimal data or numbers that exceed the 2-byte integer limitation (0-65,535), but it should work otherwise.

Anyways, how to apply this to a matrix. The first two bytes of an OS matrix (the 2 bytes before the pointer a GetCalc() would return) are the number of columns and rows. To access the entry in row A and column B, for example, you'd have to do something like the following:

Code: [Select]
"[A]"→GDB1
GetCalc(GDB1)→P
.Number of columns
{P-2}→C
Disp float{A-1*C+(B-1)*9+P}▸Dec

I haven't tried this code myself, so I can't guarantee it will work. But it should (unless I have where the OS stores the rows and columns reversed).

EDIT: I have tried this code, and it works.
Title: Re: Axe Parser
Post by: guy6020665 on August 23, 2010, 07:32:29 pm
There is no built-in support for reading specific entries from OS matrices or lists. However, the most recent version of Axe (0.4.4) includes the new float{PTR} function, which is the fPart() function. This converts a 9-byte real number from the OS to a 2-byte integer Axe can understand. This would not accurately convert decimal data or numbers that exceed the 2-byte integer limitation (0-65,535), but it should work otherwise.

Anyways, how to apply this to a matrix. The first two bytes of an OS matrix (the 2 bytes before the pointer a GetCalc() would return) are the number of columns and rows. To access the entry in row A and column B, for example, you'd have to do something like the following:

Code: [Select]
"[A]"→GDB1
GetCalc(GDB1)→P
.Number of columns
{P-2}→C
Disp float{A-1*C+(B-1)*9+P}▸Dec

I haven't tried this code myself, so I can't guarantee it will work. But it should (unless I have where the OS stores the rows and columns reversed).

EDIT: I have tried this code, and it works.

Thanks

Don't entirely understand it, but if it works, it's good enough for me.
Title: Re: Axe Parser
Post by: guy6020665 on August 24, 2010, 05:16:06 pm
Is there a way to have Axe not scroll down to the next line when outputting to the last space?

This is causing my game to look weird.
Title: Re: Axe Parser
Post by: ztrumpet on August 24, 2010, 05:18:00 pm
Yes, that's easy.  Put a Fix 7 towards the beginning of your program.  Remember to put a Fix 6 towards the end! :)
(Fix 0 - 9 are found next to Float in the Mode menu.) ;D
Title: Re: Axe Parser
Post by: guy6020665 on August 24, 2010, 05:22:48 pm
Yes, that's easy.  Put a Fix 7 towards the beginning of your program.  Remember to put a Fix 6 towards the end! :)
(Fix 0 - 9 are found next to Float in the Mode menu.) ;D

Thanks ztrumpet! Got it working now! Almost no waiting for screen to load!
Title: Re: Axe Parser
Post by: Hot_Dog on August 24, 2010, 06:29:25 pm
I saw the new version of Axe!  Nice job, Quigibo!
Title: Re: Axe Parser
Post by: Hot_Dog on August 25, 2010, 09:08:24 pm
Sorry for the double post.  Are you really adding Mode 7?  If I wasn't stopping programming after S.A.D. (though I'll most likely still be on the site), I would serious use Axe for that.
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 26, 2010, 12:46:50 pm
I'm not sure if he plans this for the next versions. I think it was gonna be an Axiom, though.
Title: Re: Axe Parser
Post by: LordConiupiter on August 31, 2010, 02:02:12 pm
why does Axe need so much space when running a program? I get many times an ERR:OUT OF MEM, while I just have left a little less than the size of my program. this is really very annoying, you know! is this a problem that can easily be fixed? or is it something that is needed for Axe? please help! I'm running out of mem this way! I can't develop any further right now! and how does the read from archive function work exactly? I don't understand the Commands documentation with GetCalc(PTR,FILE) or something like that...
Title: Re: Axe Parser
Post by: Builderboy on August 31, 2010, 02:44:14 pm
Wait, how large is the program you are writing?  My source is about 8000 bytes and it compiles to over 10000 bytes, and i have no problem.  How much free ram do you have left?
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 31, 2010, 04:13:29 pm
ALternatively, you can make your game run through Ion or Doors CS. MirageOS can work too, but I think you can't use interrupts nor L2 in it.

Doing so lets you run Asm() programs with like 100 bytes of RAM left.
Title: Re: Axe Parser
Post by: LordConiupiter on August 31, 2010, 06:03:08 pm
yes, in DCS it's working. my source is about 5000 bytes, and my executable is 6876 bytes, but I'm also using data separatly in Appvars, which are created by a setup Application I wrote in Axe. all with all I have only 6049 bytes left of RAM memory. but DCS handles it, but is a little bit more time-consuming to use, for the startup time...
Title: Re: Axe Parser
Post by: DJ Omnimaga on August 31, 2010, 07:06:35 pm
You can run it from the PRGM menu, though, right? (even without the Asm() command)
Title: Re: Axe Parser
Post by: shmibs on August 31, 2010, 10:11:34 pm
the axe "variables" are stored in the allocated portion just before L1, are they not quigibo(im just guessing here). if i wanted to set them all to the same value with one command instead of [num]->A->B etc could i just use for(A,0,number of vars:0->{L1-[whatever the offset is]+L:end? also, i too am unsure as to how reading from the arch works(probably because i havent read the command lists in a while, but because someone else already brought it up i dont feel guilty about asking XD)
Title: Re: Axe Parser
Post by: Quigibo on September 01, 2010, 12:14:26 am
The user manual has been updated since I added the file commands, if you haven't looked at it recently, try the newest version.

Here is a little more technical insight.  Normally you use pointers to access something in ram, but only 65536 bytes of memory can actually be read because that's all the combinations you can make with only 2 bytes.  That's fine because there's only 2 ram pages anyway corresponding to 32768 bytes total.  But when it comes to reading from the archive, there is MUCH more data, 2 million bytes on the TI-84+SE.  So in order to compensate for this, you have to use files which you can think of as "extended" pointers.  Each file is 3 bytes corresponding to a page number and pointer within that page.  Because the files obviously have to be handled differently, they can only be used in a few commands: Copy(), {}, and GetCalc() are used most often.  If you need to use the data for other things like sprite drawing, you can use the Copy command to copy it to ram and then refer to it using a normal 2 byte pointer.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 01, 2010, 01:38:05 am
Btw the OS is 512 KB, right?
Title: Re: Axe Parser
Post by: LordConiupiter on September 02, 2010, 01:42:25 am
the axe "variables" are stored in the allocated portion just before L1, are they not quigibo(im just guessing here). if i wanted to set them all to the same value with one command instead of [num]->A->B etc could i just use for(A,0,number of vars:0->{L1-[whatever the offset is]+L:end? also, i too am unsure as to how reading from the arch works(probably because i havent read the command lists in a while, but because someone else already brought it up i dont feel guilty about asking XD)
the easiest way is (imo):
Code: (Axe) [Select]
5->A
Fill(L1-56,56

and @quigibo: are can the current 2 Archive pages also be read? when running an App with data stored into GDB1, I can just do a Pt-On(X,Y,GDB1) on my calc, or is this strange?
Title: Re: Axe Parser
Post by: Quigibo on September 02, 2010, 01:52:04 am
Yeah, you can read them, but technically they are considered rom pages since you can't write to them.
Title: Re: Axe Parser
Post by: Builderboy on September 02, 2010, 02:07:10 am
I know that you said you planned to move the variables to the end of SaveScreen.  Is this still planned?
Title: Re: Axe Parser
Post by: LordConiupiter on September 02, 2010, 07:05:52 am
o no! please don't! I'm using this pretty much u know!
Title: Re: Axe Parser
Post by: calc84maniac on September 02, 2010, 09:09:04 am
As long as you also implement the "pointer to variable" command, it should be fine. By the way, if you do that, allow it in inline asm too ;)
Title: Re: Axe Parser
Post by: Deep Toaster on September 02, 2010, 01:11:57 pm
o no! please don't! I'm using this pretty much u know!

Same with me :P I'm reading stuff like {L1-55} to get just the high byte of A, so stuff'll get messed up :(
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 02, 2010, 02:14:15 pm
Mhmm I am not too fond of that change, unless it won't require me to change full of code in my games. (I tend to use L1 a lot).
Title: Re: Axe Parser
Post by: calcdude84se on September 02, 2010, 05:19:12 pm
Well, it doesn't affect normal use of L1. The main problem occurs when you use L1 and subtract something. As long as you don't use L1 to access data outside of it, it should be fine. The problem is if you use L1 to access A, for example.
Title: Re: Axe Parser
Post by: Deep Toaster on September 02, 2010, 06:55:07 pm
What comes before the whole L1/A-Z var group, though?
Title: Re: Axe Parser
Post by: Builderboy on September 02, 2010, 07:33:24 pm
Yeah, moving around the variables would also mess with PortalX, as i use the locations for a large speed operation.  (not that moving them would erase this optimization, i would just have to change some numbers :P)
Title: Re: Axe Parser
Post by: Runer112 on September 06, 2010, 12:05:08 am
I was just asking Iambian how he gets grayscale to work in his project Escheron: Shadow over Ragnoth because I was wondering why it seems that every ASM game does grayscale in interrupts. Why exactly do the grayscale routines for Axe have problems with interrupts?
Title: Re: Axe Parser
Post by: nemo on September 06, 2010, 12:11:33 am
wait, so you can get the high/low bytes of variables by accessing a certain part of RAM? can someone tell me where this RAM starts and where it ends? is it {L1-55} to {L1-1}? that leaves 54 bytes / 2 = 27 variables..
would the following be an optimization?
Code: [Select]
{GDB1+B}^r->A
A/256->C
A^256->D
.optimizes into..
{GDB1+B}^r->A
{L1-55}->C
{L1-54}->D

of course, i'm talking about speed optimization. i know it's a bigger size.
Title: Re: Axe Parser
Post by: Runer112 on September 06, 2010, 01:23:58 am
Is it a bigger size? I believe that is not only faster but a good deal smaller.
Title: Re: Axe Parser
Post by: nemo on September 06, 2010, 01:28:47 am
/256 is 3 bytes and ^256 is 2 bytes, so i don't think so.
-55 and -54 are 4 bytes each. i'm not sure how many bytes accessing a byte at a pointer is though.
Title: Re: Axe Parser
Post by: Runer112 on September 06, 2010, 01:36:49 am
L1-55 is a constant that is evaluated at compile time, and accessing a byte at a constant address only takes 3 bytes. Getting the value of A alone takes 3 bytes as well, let alone operating on it. They are essentially the same, except in one case you specify the constant address and in another Axe specifies the constant address. Accessing one byte and two bytes at a constant address both take 3 bytes. And without the math that needs to be applied, you'll save bytes and speed by just accessing the individual bytes of a variable.
Title: Re: Axe Parser
Post by: nemo on September 06, 2010, 01:42:15 am
thanks for the explanation. what about the following? is there any difference?
Code: [Select]
{GDB1+X}->A
A/16->B
A^16->C
.or
{GDB1+X}->A
{L1-54}/16->B
{L1-54}^16->B
Title: Re: Axe Parser
Post by: Runer112 on September 06, 2010, 01:47:37 am
{L1-54} accesses only one byte. A accesses two bytes, so these aren't the same. {L1-54}r, however, would be equivalent to A I believe. Also, storing the second value to B in the second example would definitely be different. :P
Title: Re: Axe Parser
Post by: nemo on September 06, 2010, 01:49:04 am
yeah, i thought that too, since A now holds a value 0-255 as specified by {GDB1+X}. regardless, this is a cool way to access high/low bytes of variables
Title: Re: Axe Parser
Post by: Quigibo on September 06, 2010, 03:16:50 am
I was just asking Iambian how he gets grayscale to work in his project Escheron: Shadow over Ragnoth because I was wondering why it seems that every ASM game does grayscale in interrupts. Why exactly do the grayscale routines for Axe have problems with interrupts?

There is only one unfixable bug right now which is that after DispGraph commands, you need to turn interrupts back on again because they sometimes get turned off after a while.  Other than that, there is no problem with using interrupts for grayscale.  You have to use them the correct way though like the assembly programmers do.  That means your interrupt just increments a counter and your main program draws the grayscale once the counter gets to a certain point.  You can't have the 4 level routine inside of the interrupt routine itself because it uses the shadow registers for a speed optimization. But like I said, you should never be putting huge routines like that in interrupts anyway so its not a problem.

Personally though, I don't recommend them because they make the code larger and slower.  You should only use them when you are actually using them for their timing.  Games generally update the display pretty regularly anyway.  Even when there is a big variation in the amount of objects in a room, its not too hard to make the grayscale automatically adapt for that by doubling frames.

To answer the other question, this:
{L1-54}r->B

Parses identically to this:
A->B

There is no difference in the executable since this is an auto optimization.  The subtraction is during compile time.

(1)  {L1-54}
(2)  A^256
(3)  {L1-53}
(4)  A/256

In these examples, (1) and (2) do the same thing and both take 5 bytes.  No optimization there.  (3) and (4) also do the same thing, but in this case, (3) takes 5 bytes and (4) takes 6 bytes so there actually is a slight optimization.  Just for reference, r1-r6 as well as the Y0-Y9 files can also be accessed this way, but you would need the exact hex address becasue they aren't simple offsets with any of the L1-L6 buffers.
Title: Re: Axe Parser
Post by: squidgetx on September 06, 2010, 11:20:01 am
quick question: do conditionals speed up execution
example
Code: [Select]
While 1
If A
blah
end
end

!if A, then will the code run almost at the same speed as if the 'blah' wasn't there? in other words, does the program 'skip' the code if the conditional is false, and is that significantly faster than actually executing it?
Title: Re: Axe Parser
Post by: LordConiupiter on September 06, 2010, 11:38:45 am
just out of curiousity: why do you use the 'space': 0x20 in the name of the parser itself, but in the compiled versions the 'zero': 0x00 after the name?
Title: Re: Axe Parser
Post by: calc84maniac on September 06, 2010, 02:32:29 pm
quick question: do conditionals speed up execution
example
Code: [Select]
While 1
If A
blah
end
end

!if A, then will the code run almost at the same speed as if the 'blah' wasn't there? in other words, does the program 'skip' the code if the conditional is false, and is that significantly faster than actually executing it?

This is true.
Title: Re: Axe Parser
Post by: squidgetx on September 06, 2010, 02:59:21 pm
thanks...

time to go on a coding spree in the last 16 hours before school starts
Title: Re: Axe Parser
Post by: Builderboy on September 07, 2010, 07:36:18 pm
So Quigibo, does Axe use short circuit logic?  Or does it purposefully evaluate every single argument of every if Statement?
Title: Re: Axe Parser
Post by: Quigibo on September 07, 2010, 08:01:10 pm
Axe does not use short circuit logic.  It's not on purpose, its just that its more difficult to parse and requires it to read it as a bunch of nested blocks instead of a single statement.  I certainly would want to add it, but at this point it would break too much compatibility with previous versions.  Its something I plan to change in Axe++ which would have a slightly different syntax since it doesn't need to be completely compatible with 1.0.
Title: Re: Axe Parser
Post by: Builderboy on September 07, 2010, 08:24:48 pm
Nested blocks hmmm?  Oh well, i can program it in when i need it ^^ I just thought that assembly naturally did things lice short circuit because it used label jumps to do logic.  So i guess you do logic in a different way?
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 07, 2010, 08:27:27 pm
Would Axe++ be some sort of new Axe language or more like an add-on?
Title: Re: Axe Parser
Post by: calc84maniac on September 07, 2010, 08:43:57 pm
Nested blocks hmmm?  Oh well, i can program it in when i need it ^^ I just thought that assembly naturally did things lice short circuit because it used label jumps to do logic.  So i guess you do logic in a different way?
The logic is actually 8-bit bitwise logic. (This is why things like If A and B might not work as expected and you would need to use If A!=0 and (B!=0) instead)
Title: Re: Axe Parser
Post by: Deep Toaster on September 07, 2010, 10:10:38 pm
I think it's a completely new version of the parser.

That'd be a great idea Quigibo, by the way, since there wouldn't be compatibility issues between two versions of the same program.
Title: Re: Axe Parser
Post by: Runer112 on September 08, 2010, 12:24:24 am
I have a question: Can tempSwapArea be corrupted in ways other than directly calling Archive or UnArchive? Because I'm having problems with data corruption in L4, but nowhere in my program do I archive or unarchive anything. It might just be something wrong with my code, but I've debugged the hell out of it and it seems to be happening, although not randomly, at a certain point in execution that is executed multiple times before that successfully.
Title: Re: Axe Parser
Post by: Quigibo on September 08, 2010, 12:44:47 am
Runer112, I don't know how tempSwapArea is actually used.  The TI Developer's guide claims its only used when archiving, but they have been wrong before.  My gut tells me its probably a bug in your program, but its certainly possible that some other bcall or interrupt could be screwing it up.  Maybe ask another asm programmer exactly what its used for if you're still not convinced.
Title: Re: Axe Parser
Post by: Runer112 on September 08, 2010, 12:49:27 am
Oh, I forgot to mention: I hadn't been using L1 in my program, and replacing all references to L4 with L1 seemed to fix the problem. It seems like it's not my doing that's causing the problem, which unfortunately means I can't fix it. I really don't think I'm missing anything, but if nobody can think of anything I may just have to do more extreme debugging. :-\


EDIT: I was just browsing around randomly, and found this (http://wikiti.brandonw.net/index.php?title=83Plus:RAM:82A5) regarding tempSwapArea:
Quote
If you are using this area for data storage, avoid archiving any variables or using routines such as Regraph.

Maybe something besides archive and unarchive is messing with my data after all? It says "routines such as Regraph," suggesting that there are multiple routines that could corrupt data in tempSwapArea. Any ideas, anyone?


EDIT 2: I don't want to use L1 because I plan to use it later, I might use interrupts so I don't want to use L2, and L3, L5, and L6 are needed for their usual functions. Perhaps I could just use a different area of RAM? Could either appData (8000h) or ramCode (8100h) be a safe alternative?


EDIT 3: After a bit of talking with Iambian, it seems that appData should be safe to use, and the 256 bytes present there should be enough for my purposes. So I guess this issue has been avoided, but it would still be nice to solve it and determine what was corrupting tempSwapArea.
Title: Re: Axe Parser
Post by: guy6020665 on September 14, 2010, 05:38:16 pm
Ok I feel really stupid for not asking this earlier when i realized that i might be entering the contest (I started coding last week).  But what would be the easiest way to display a title screen in Axe?
Title: Re: Axe Parser
Post by: Raylin on September 14, 2010, 05:45:10 pm
[Pic1]->Pic1->DispGraph if I'm not mistaken.
Title: Re: Axe Parser
Post by: meishe91 on September 14, 2010, 05:46:52 pm
[Pic1]->Pic1->DispGraph if I'm not mistaken.

But isn't that only if you have your title screen stored to Pic1 already?
Title: Re: Axe Parser
Post by: guy6020665 on September 14, 2010, 05:49:30 pm
The last time i read the rules everything had to be in just one Axe program, or has that been changed?

Edit: Never mind I got an answer
Title: Re: Axe Parser
Post by: Darl181 on September 14, 2010, 07:23:28 pm
I was just wondering...
What's the new equivelant for the posts/critique thread?
And/or bug diagnostics "Why is it crashing every other minute when it worked half an hour ago?!!?"

The question is, is there a way to just check if something is in archive and not try to create a file.

EDIT:
Level editor.  RAM clear when you press MATH, which is the enemy edit mode.
This worked perfectly until I added the ability to archive/unarchive.
A level appvar is included.
It won't compile in it's current form, just delete the first line.

The name, by the way, is a very compressed "CoRruPTeD EDiTor".  CRPDEDT.
Title: Re: Axe Parser
Post by: Quigibo on September 14, 2010, 07:48:53 pm
The thread you choose is up to you.  I would only report Axe bugs in the bug reports section though, not bugs in your code.

You can check with getCalc("prgmA") first.  If it works, its in RAM.  If it fails, you can next try to read it to a file getCalc("prgmA",Y1) if that works, then its in ROM.  If it fails, it doesn't exist.

So like this:
If getCalc("prgmA")->A
  .RAM
Else
  If getCalc("prgmA",Y1)
    .ROM
  Else
    .NO
  End
End
Title: Re: Axe Parser
Post by: Darl181 on September 14, 2010, 11:22:43 pm
I doubt it's an Axe bug.  It (enemy editing, not archiving/unarchiving) worked fine before.
The code.  That's close to what I did, but it has some extra details such as a level map if it's in RAM or it says "Level Archived" or "No Level".
I guess archiving/unarchiving can wait for V2.
Title: Re: Axe Parser
Post by: calcdude84se on September 15, 2010, 06:42:43 pm
We have archiving and unarchive via the "Archive " and "UnArchive " commands, which take a pointer to a name and return 0 if the operation failed, and IIRC 1 on success :D
Title: Re: Axe Parser
Post by: Darl181 on September 15, 2010, 06:52:19 pm
Archiving and Unarchiving worked fine in themselves, it was just something it caused.  I've found Unarchiving to work fine, no problems, so I've narrowed down the problem to either something caused by the checks or the Archiving process.
Simplified it, got it working, posted it.  This one is stable.
Title: Re: Axe Parser
Post by: nemo on September 15, 2010, 10:45:50 pm
if the batteries are low, will that effect the speed of the calculator? i know this isn't completely axe-related, but it's because i have this grayscale screen with some animated objects, and it's flickering quite a bit. my batteries are low though, and i was still planning on adding more objects on the screen. so if i put in new batteries, should the grayscale get less flickery? or would it not even be noticeable?
Title: Re: Axe Parser
Post by: SirCmpwn on September 15, 2010, 10:50:00 pm
I don't think that matters.  If you have too many objects, there's no way around it, except optimization.
Title: Re: Axe Parser
Post by: nemo on September 15, 2010, 11:00:21 pm
i think i found the major slowdown, but to optimize it for speed it'll add a good 50 more bytes onto the program. i have to take it though :/
Title: Re: Axe Parser
Post by: Builderboy on September 16, 2010, 01:15:40 am
In my opinion 50 bytes is well worth the speed increase.  You'll find i favor speed over size a lot ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 16, 2010, 04:43:35 am
if the batteries are low, will that effect the speed of the calculator? i know this isn't completely axe-related, but it's because i have this grayscale screen with some animated objects, and it's flickering quite a bit. my batteries are low though, and i was still planning on adding more objects on the screen. so if i put in new batteries, should the grayscale get less flickery? or would it not even be noticeable?
I think that only happens on very very old calcs or certain newer ones (83+). I never had that issue on mine, but tr1p1ea reported it I think. I think it was because he was using interrupt-based grayscale, though, and interrupts are slightly slower with low batteries.
Title: Re: Axe Parser
Post by: Darl181 on September 18, 2010, 01:30:00 am
While cleaning out my calc's archive for the umpteenth time, I found something that actually works.
Remember Spacerun? Apparently, I got bored sometime in the early summer and spent some time on it.  I'm not sure if there are any bugs or whatnot, but I remember being kind of addicted to it myself, as I played it a lot.  I don't remember any problems.
There's a GIF in the zip file.
Controls are the same, though now you can use a more finger-friendly scheme of [Y=] and [GRAPH].
Oh, and the three buttons in between pause it.  And MODE.
Press the [^] key to disable the drawinv commands, thus making it run faster (and look weird).
As for the winning screen, just think of something cliché.
It runs a lot faster than in the screenshot.


Afterthought.
What's supposed to be added in axe version 1.0.0?
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 18, 2010, 01:56:07 am
Oh wow I remember that game, it was cool. I hope you finish it! As for bugs when restarting the screen from previous game is not cleared it seems. As it progresses you should also make the bars smaller and smaller to increase difficulty.
Title: Re: Axe Parser
Post by: Darl181 on September 18, 2010, 02:04:39 am
My turn to ask, "what do you mean?"
The bar already depletes.  Do you mean it should deplete faster?
As before, you can modify the source to deplete faster/slower, start with X fuel, and get X fuel from each bar.

EDIT...
Oh, you mean the bars you aim for.  That could be a possibility...
Or the ship can speed up...or both...
I guess I know what I'll be doing while the rest of the class learns how to use the school-issue 83+'s--[teacher speaking]"So this is the GRAPH key, class.  Does anybody know what it does?"
"yeah, you go to the right."
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 18, 2010, 02:06:13 am
Nonono I meant the bars that scrolls down.

Also you didn't answer my question (the what do you mean one) in the other topic :P
Title: Re: Axe Parser
Post by: Darl181 on September 18, 2010, 02:10:11 am
I clarified it--see the red text.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 18, 2010, 02:10:31 am
Ah ok I'll go check
Title: Re: Axe Parser
Post by: Michael_Lee on September 18, 2010, 10:08:16 pm
This might not be the best place for me to ask this, but what exactly is an axiom, and what are they going to be used for?
Title: Re: Axe Parser
Post by: Quigibo on September 18, 2010, 10:15:42 pm
They are assembly language extensions to add new commands to the Axe language.  You could for instance make the sum() token add up all the numbers in a pointed list.  Unlike include files though, the Axioms are written in assembly so they are super optimized.  You can import them with Axiom(EXAMPLE).  After that, you can use all the new tokens that Axiom provides.
Title: Re: Axe Parser
Post by: nemo on September 18, 2010, 11:09:17 pm
I'm going to ask again... Quigibo, can you post the source to the mode 7 engine you made in axe awhile back?
Title: Re: Axe Parser
Post by: FinaleTI on September 19, 2010, 11:07:48 am
How do you read a real var with Axe?
Code: [Select]
"varA"->Str1
GetCalc(Str1)->A
Output(0,0,float{A}>Dec

It always displays zero. What am I doing wrong?
Title: Re: Axe Parser
Post by: Quigibo on September 19, 2010, 02:05:07 pm
Oh, I finally found it!  It uses what's on the screen before you run it as the background.  Arrows move, + and - change incline, no rotation.  Best wabbit setting for grayscale is 6.

FinaleTI, try float{A-2}.  The getcalc() function automatically skips the "size" bytes of a variable, but floats don't have them since they're always the same size (9 bytes) so you need to compensate for that.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 19, 2010, 02:16:28 pm
That looked cool, although it might be a bit impractical in game due to no monochrome support and speed. I am curious how well Jim_e or Calc84maniac's Mode 7 stuff could be implemented as Axiom for use in game.
Title: Re: Axe Parser
Post by: ztrumpet on September 19, 2010, 02:21:28 pm
Wow, that's awesome!  Nice job!
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 19, 2010, 02:22:54 pm
Actually in 15 MHz mode it doesn't actually look too slow. Last time I tried I got rid of the 15 MHz command. I wonder how it would be in monochrome?
Title: Re: Axe Parser
Post by: Darl181 on September 19, 2010, 03:26:00 pm
Wow.  I wonder if there's going to be some F-Zero clone in the next few years or something.
Pretty awesome, 3D in axe.
Title: Re: Axe Parser
Post by: calc84maniac on September 19, 2010, 03:28:36 pm
Wow.  I wonder if there's going to be some F-Zero clone in the next few years or something.
I sure hope there will be. :P
/me looks at his avatar
/me nudges himself
Title: Re: Axe Parser
Post by: Builderboy on September 19, 2010, 03:30:21 pm
Lol yeah silly calc84 :P

I remember that Mode7 Axe engine :D It was super special awesome ^^
Title: Re: Axe Parser
Post by: Darl181 on September 19, 2010, 03:36:21 pm
So that's what that ship's supposed to be?
F-Zero or something else?
Title: Re: Axe Parser
Post by: calc84maniac on September 19, 2010, 03:39:26 pm
http://ourl.ca/2824 (http://ourl.ca/2824)
Title: Re: Axe Parser
Post by: Darl181 on September 19, 2010, 03:47:36 pm
Didn't quite work.
The bar on the right does this odd flashing thing.
The pics are there for a second, then they flicker and disappear like a dramatized dying TV screen.
Compatibility mode or not.
So, what is it supposed to be?

EDIT: I didn't know it would put up the whole pic on the post!!?!

Whoa...Ticalc.org is screwing up as well.
Must be zonealarm or something.

Oh, my parents have some Lorex thing hooked up to this computer.
Cameras throughout the house send the video to this PC.

Could the GIFs be put in a zip, maybe?
Title: Re: Axe Parser
Post by: FinaleTI on September 19, 2010, 05:26:48 pm
Oh, I finally found it!  It uses what's on the screen before you run it as the background.  Arrows move, + and - change incline, no rotation.  Best wabbit setting for grayscale is 6.

FinaleTI, try float{A-2}.  The getcalc() function automatically skips the "size" bytes of a variable, but floats don't have them since they're always the same size (9 bytes) so you need to compensate for that.
Thanks!
On a related note, how would one safely change the size of a matrix using Axe?
Just changing {A-2} and {A-1} appear to change its size, but the matrix usually becomes very volatile then. It can cause a RAM Clear to try and delete the matrix or sometimes even when modifying the entries in the matrix editor. It also shows really weird entries in the matrix editor.
Title: Re: Axe Parser
Post by: Quigibo on September 19, 2010, 05:32:22 pm
You have to create a new matrix the size you want (or use a buffer), copy the old one into the new one, then delete the old one.
Title: Re: Axe Parser
Post by: FinaleTI on September 19, 2010, 05:43:00 pm
Would the size of the matrix be 9 times the number of cells, or what?
Do you have any example code I could see?
Title: Re: Axe Parser
Post by: Quigibo on September 19, 2010, 05:59:39 pm
I'm afraid I don't know either since its TI's crazy formats and I haven't played around with OS variables yet.  If I had to guess though, I'd say its the rows and columns of the matrix and not the number of bytes for each.  I know when you read the size bytes of a list its the number of elements and not the number of bytes so its probably the same for matrices.
Title: Re: Axe Parser
Post by: FinaleTI on September 19, 2010, 06:03:35 pm
I'll play with it, since doing GetCalc("[A]",9) yields a 0x9 matrix.
Title: Re: Axe Parser
Post by: ztrumpet on September 19, 2010, 06:07:39 pm
From Asm in 28 Days:
Quote
Matrix
One byte with the number of columns, one byte with the number of rows. Followed by r × c × 9 bytes, each of which is a real FP-number. Matrices are organized in row-major order.
$03    $02    
$00    $81    $14    $95    $72    $75    $75    $00    $00
$80    $82    $83    $67    $57    $54    $74    $00    $00
$80    $81    $33    $57    $61    $43    $96    $00    $00
$00    $80    $48    $48    $78    $16    $76    $24    $00
$80    $81    $85    $56    $56    $72    $78    $00    $00
$00    $80    $86    $56    $01    $97    $47    $00    $00
[ [14.95727575, -836.7575474, -33.57614396]
  [4.878167624, -85.56567278, 8.656019747 ] ]
I hope that helped! :)
Title: Re: Axe Parser
Post by: FinaleTI on September 19, 2010, 06:14:37 pm
Actually, I think I just figured it out. ;D

It seems to be the 9 times the total number of cells.
So, for a 3x3 matrix:
Code: [Select]
GetCalc("[A]",81)→A
3→{A-2}
3→{A-1}
That causes the 3x3 matrix and fills it with zeros. It doesn't screw up if the matrix previously existed, either.
Title: Re: Axe Parser
Post by: ztrumpet on September 19, 2010, 06:16:22 pm
Nice!  Good luck on it. :)
Title: Re: Axe Parser
Post by: Michael_Lee on September 20, 2010, 02:00:21 pm
Quick question:
If I wanted to access nibbles, I think I use mod and divide.  (Builderboy told me this trick a while back)
Would I do
{L1+3/16}
or
{L1+3}/16
(3 is a random number)
Title: Re: Axe Parser
Post by: Builderboy on September 20, 2010, 02:04:51 pm
That would be {L1+3}/16.  Note that there will be built in nibble support in later version so this wont be needed.
Title: Re: Axe Parser
Post by: Michael_Lee on September 20, 2010, 05:57:21 pm
That would be {L1+3}/16.  Note that there will be built in nibble support in later version so this wont be needed.

Groan...
And THAT'S why my code messed up so horribly.

Title: Re: Axe Parser
Post by: Quigibo on September 20, 2010, 10:17:23 pm
I'm releasing 0.4.5 very soon because I don't want everyone waiting so long for 1.0.0 since its going to take a long time.  In this intermediate version, I will disable Axioms since those are totally under construction right now, but most of the new features and bug fixes will be available.

The command nib{} is the only one where you actually have to do math to the pointer itself.  Like if you have a string of bytes in Str1 then you have to refer to it with nib{Str1*2} since there are twice as many nibbles addresses as there are byte addresses.

The other new thing you'll be able to do is pass by reference commands.  If you are familiar with other languages that use pointers then you might have an idea about what this is, but for those who don't, its a very powerful tool.  Pass by reference is used when you want the function you are using to modify the variables instead of (or in addition to) just returning the result of the calculation.  For instance, say you want to write a function that swaps 2 variables.  You can't just call sub(SWP,A,B) because the subroutine itself only knows the values of A and B and not where to put the result.  So instead you could write the subroutine like this:


:.This is the subroutine.
:.r3 is used as a temporary.
:Lbl SWP
:{r1}r->r3
:{r2}r->{r1}r
:r3->{r2}r
:Return

:.You can call it like this
:sub(SWP,oA,oB)
:.A and B have now swapped their values

So what is going on here?  Well, instead of passing the value of A and B, you pass a pointer to A and B because not only can you read the value by using {pointer}, but you can also write to them as well since you have the pointer at your disposal.  Another way you can take advantage of this systems is by inventing your own data types!  For example, lets say you want a 32-bit double precision integer.  It conveniently fits in 2 Axe variables so you can store them in consecutive addresses like A could be the low word and B could be the high word.  Then, you can pass to the subroutine the pointer to A and the subroutine now has access to A and B because it can read and write to their values with {r1}r and {r1+2}r.  That means, you only need one argument to call the subroutine and you don't need to give it 2 "halves" of the number.  There's probably a billion other uses for this too, but it will definitely make the language more convenient.

I also will take calc84maniac's request from a while back to allow recursive subroutines because all of the Scheme programming I've been doing recently has really opened my eyes to the beauty and the simplicity of using them (even if they are bulkier and less efficient at the assembly side).  If you have no idea what I'm talking about, I'll explain the command with some examples later.  Basically, it automatically saves and restores the r1-r6 variables before and after the call.
Title: Re: Axe Parser
Post by: calcdude84se on September 20, 2010, 10:37:37 pm
Cool! Pass by reference will be less useful than say, in C, because our largest data structures are two bytes ;D
Keep up the good work, can't wait to try it! :)
Title: Re: Axe Parser
Post by: Builderboy on September 20, 2010, 10:55:07 pm
Oh dear, recursive subroutines is going to destroy Portal D: I use r1-r6 as temp variables inside of my object code, so im going to have to make sure that i don't use those across subroutines

As for all of the other features though, that sounds awesome :D

EDIT: Another question, where are R1-R6 stored anyway?  And how much can you recurse before bad things happen?
Title: Re: Axe Parser
Post by: _player1537 on September 20, 2010, 11:06:09 pm
I think they are located in Math<something> It's a small 10-12 byte ram area that math variables or similar are stored.
Title: Re: Axe Parser
Post by: calc84maniac on September 20, 2010, 11:07:41 pm
Oh dear, recursive subroutines is going to destroy Portal D: I use r1-r6 as temp variables inside of my object code, so im going to have to make sure that i don't use those across subroutines

As for all of the other features though, that sounds awesome :D

EDIT: Another question, where are R1-R6 stored anyway?  And how much can you recurse before bad things happen?
Well, my idea was to use sub()r for that. I'm not sure exactly how it's really going to work though.
Title: Re: Axe Parser
Post by: Builderboy on September 20, 2010, 11:15:23 pm
So then they much be pushed onto the stack or something?  Hopefully it can be turned off, or accessible via a different command, since i call some subs many many times in a single frame and i dont need all this extra pushing and popping of 6 two byte integers D:

And if they are being pushed onto the stack, is that 12 bytes ever sub?  So less than 33 recursions until crash D:
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 20, 2010, 11:17:27 pm
I like the swapping idea. It may be very useful in games, like a RPG where you swap your HP with MP or swap HP between two chars, or when moving a char to another party slot.
Title: Re: Axe Parser
Post by: Quigibo on September 21, 2010, 12:16:46 am
Builderboy, no need to panic, nothing is changing with the existing sub() command I am only adding a new command sub()r :)

It only backs up the variables its using so if you call sub(SUB,A,B)r it will only save r1 and r2.  In recursive subroutines, they are saved to the stack.  The actual addresses of r1-r6 are in a really small free-ram area not part of L1-L6.  You can get the actual location now with or1 if you want to pass them by reference or something.
Title: Re: Axe Parser
Post by: Raylin on September 21, 2010, 12:33:26 am
Oh dear. I will need examples for this...
Title: Re: Axe Parser
Post by: Builderboy on September 21, 2010, 01:09:25 am
Builderboy, no need to panic, nothing is changing with the existing sub() command I am only adding a new command sub()r :)

It only backs up the variables its using so if you call sub(SUB,A,B)r it will only save r1 and r2.  In recursive subroutines, they are saved to the stack.  The actual addresses of r1-r6 are in a really small free-ram area not part of L1-L6.  You can get the actual location now with or1 if you want to pass them by reference or something.

Sounds excellent :D And also i forgot that the parser can precompile the push and pop since it already knows how many arguments it has ^^ This is going to be so cool :D
Title: Re: Axe Parser
Post by: ztrumpet on September 22, 2010, 04:41:43 pm
Wow, these all sound like wonderful additions!  I can't wait for 0.4.5! ;D  Awesome! :D
Title: Re: Axe Parser
Post by: LordConiupiter on September 22, 2010, 05:05:27 pm
yeah! reference passing! I realy am looking forward to this update! :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 22, 2010, 11:13:04 pm
I personally can't wait to see how nibble commands works.
/me hopes they save him some trouble in the future for half-byte maps and some data storage.
Title: Re: Axe Parser
Post by: calcdude84se on September 25, 2010, 02:51:55 pm
Just a suggestion, but would it be possible to document which commands have an effect on interrupts?
(I ask mainly because I just learned that Disp >Dec disables them)
Title: Re: Axe Parser
Post by: Michael_Lee on September 26, 2010, 07:09:33 pm
Question: About when do you think 0.4.5 will be out?
I really, really want to use it...
Title: Re: Axe Parser
Post by: Quigibo on September 26, 2010, 07:18:43 pm
I thought it would be last night but after more testing I realized I hadn't actually fixed the nested elseif bug properly for all cases and its taking me forever to fix it.  Once I fix that, it will be ready.
Title: Re: Axe Parser
Post by: Michael_Lee on September 26, 2010, 07:23:54 pm
Ah, so I wasn't imagining the elseif bug.
So... it'll be out maybe in the next seven days?  Please?
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 26, 2010, 07:58:24 pm
Oh I did not mean every single release only happens on sundays, I meant that most did. I think one of them came out on a monday. It's just speculation from me since most releases were weekly or bi-weekly.
Title: Re: Axe Parser
Post by: Darl181 on September 27, 2010, 06:49:48 pm
Quick question.  How large can a compiled program get to be before it crashes?  The TWHG level editor is crashing at erratic places where it's been working fine for months.
Currently, it's at 9593 bytes.  Is that too large?
Title: Re: Axe Parser
Post by: Raylin on September 27, 2010, 06:52:54 pm
Yeah. That's too big. Make it an APP instead and it won't crash anymore.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 07:26:50 pm
Hmm... is it 9593 bytes of just source code, or is it 9593 bytes of both source code and data? (data being HEX stuff)

There is no way to know how large your compiled executable code is, except by getting rid of all HEX data from your program before compiling (backup first of course). If the executable code reaches 8.1 KB, it is the limit of executable code for z80 ASM and Axe 8xp programs. You can have larger file sizes than 9593 bytes as long as the executable code portion of it is under 8.1 KB. Otherwise you need to use an APP.
Title: Re: Axe Parser
Post by: shmibs on September 27, 2010, 08:10:13 pm
/\...but then you get errUndefined messages when compiling(assuming that the data is accessed during the program and isnt just there because) make sure you at least have a [00->Pic11(or whatever other spots are accessed in your program) and then just factor out the 1 byte size of each of those
Title: Re: Axe Parser
Post by: Quigibo on September 27, 2010, 09:12:12 pm
I think I will give a warning message from now on when the size passes 8812 bytes.
Title: Re: Axe Parser
Post by: calcdude84se on September 27, 2010, 09:29:15 pm
I would suggest you only say that when code passes that mark, but then I remembered that you decided to mix subroutines and code ;D
I think that'd be a good idea :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 09:38:28 pm
I think I will give a warning message from now on when the size passes 8812 bytes.
Could you simply display the code size after compiling even when it is under 8812? It might act as a guide for people who are trying to stay under the limit.
Title: Re: Axe Parser
Post by: Runer112 on September 27, 2010, 09:55:06 pm
PRAISE THE ALL-MIGHTY LORD OF CALCULATORS, AXE 0.4.5!
Title: Re: Axe Parser
Post by: Michael_Lee on September 27, 2010, 09:57:41 pm
PRAISE THE ALL-MIGHTY LORD OF CALCULATORS, AXE 0.4.5!

:)
Recursive subprograms!
Title: Re: Axe Parser
Post by: ztrumpet on September 27, 2010, 09:58:14 pm
PRAISE THE ALL-MIGHTY LORD OF CALCULATORS, AXE 0.4.5!

:)
Recursive subprograms!
Yea!
* ZTrumpet thanks Quigibo recursively. ;D
Title: Re: Axe Parser
Post by: Happybobjr on September 27, 2010, 10:03:48 pm
Edit: no longer relevant
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 10:32:03 pm
Nice to see the update!

Nibbles support are so gonna become handy in the future. Should be much easier to deal with them than with the /16 and ^16 trick!
Title: Re: Axe Parser
Post by: SirCmpwn on September 27, 2010, 10:39:17 pm
Recursive subroutines FTW
Title: Re: Axe Parser
Post by: ztrumpet on September 27, 2010, 10:45:42 pm
Recursive subroutines FTW
Agreed.  This will help Blox like nothing else. ;D
Title: Re: Axe Parser
Post by: SirCmpwn on September 27, 2010, 10:47:01 pm
Advance Wars as well.  And HL2.  And pretty much everything.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 10:51:23 pm
I am still unsure what are recursive sub-routines for, but I would need someone who is more visual to explain it to me, otherwise it won't work just with code x.x. I will probably stay away from those personally.
Title: Re: Axe Parser
Post by: shmibs on September 27, 2010, 10:53:56 pm
Direct Nibble manipulation!
DispGraphrr can be used in an interrupt routine now.
Optimized Copy() Fill() and Exch() commands.

each of these will be incredibly helpful in the projects im working on right now. thank you SO much!
Title: Re: Axe Parser
Post by: SirCmpwn on September 27, 2010, 10:54:33 pm
Here you go:
You call subroutine AB with sub(AB,0
0 is stored to R1.  AB is called.
Within AB, you call subroutine CD with sub(CD,1
1 is stored to R1.  CD is called.
CD executes and returns to AB.  R1 still equals 1, though it should equal 0.

Recursive subroutines fix this.
Title: Re: Axe Parser
Post by: calc84maniac on September 27, 2010, 11:00:57 pm
I am still unsure what are recursive sub-routines for, but I would need someone who is more visual to explain it to me, otherwise it won't work just with code x.x. I will probably stay away from those personally.

Here is an example of a factorial routine using recursion:
Quote
:Lbl FCT
:!If r1
:1
:Return
:End
:sub(FCTr,r1-1)*r1
:Return

I think that should work. But factorial routine isn't very optimized this way. Kinda cool anyway, though :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 11:21:06 pm
Ah ok, I see. I assume this is like the following BASIC program

PROGRAM:A
prgmA

but minus the memory leak? Isn't it very hard to exit, though?
Title: Re: Axe Parser
Post by: calc84maniac on September 27, 2010, 11:26:02 pm
It's the !If r1:1:Return:End that allows it to return (so it doesn't continue the recursion once it is called with r1=0)
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 11:26:44 pm
Mhmm ok. I guess I'll have to experiment later x.x
Title: Re: Axe Parser
Post by: calc84maniac on September 27, 2010, 11:29:46 pm
Just be careful not to let it recurse too many times, cause the stack could overflow, causing corruption :O
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 11:30:36 pm
yeah my concern was also the stack. It seems a bit confusing to deal with, though, anyway x.x

I wonder in which kind of game it would be necessary?
Title: Re: Axe Parser
Post by: calc84maniac on September 27, 2010, 11:32:54 pm
I remember writing a Minesweeper game in TI-Basic, and I used a list for a "stack" when flood-filling. I guess it could apply to algorithms like that in Axe, too.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 11:33:35 pm
Ah ok. Would it be particulary necessary in a strategy game or RPG with fog of war like the Joltima RPG?
Title: Re: Axe Parser
Post by: SirCmpwn on September 27, 2010, 11:41:39 pm
It would be useful for calling subroutines within subroutines, which has many applications.
Title: Re: Axe Parser
Post by: Quigibo on September 27, 2010, 11:48:54 pm
Oh!  I forgot to mention something really important about recursive subroutines!

Even thought they take up more space in the program than the regular subroutines, there is a new way to optimize them.  The "last expression" for each argument is the original argument.  What I mean, is that instead of this:

sub(FACr,r1-1)

You can actually write this:

sub(FACr,-1)

Because the r1 is implied.  Same thing applies to r2, r3, etc in the rest of the arguments.  For any actual recursion, its an extremely important optimization since generally you use the previous value in your expression for the next value passed.
Title: Re: Axe Parser
Post by: calcdude84se on September 27, 2010, 11:52:03 pm
Nice to know. Can't wait to try it out! :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 27, 2010, 11:57:05 pm
Interesting, nice to know indeed :D
Title: Re: Axe Parser
Post by: Raylin on September 28, 2010, 02:07:04 am
I would like to know more about the applications of dereferencing, if you don't mind.
Title: Re: Axe Parser
Post by: Quigibo on September 28, 2010, 04:44:40 am
One example is that you can create multi-byte data abstractions.  Lets say you want to define a "vector" which has a 16-bit X component and a 16-bit Y component.  Conveniently, you can store these in consecutive addresses.  Like A would be the X-part and B would be the Y-part.  Now, lets say you want to write a routine that adds 2 vectors and stores the result in a 3rd vector.  You can do this with a singe routine by pasing the pointer to the vector instead of the vector values themselves (since you can only pass 16-bit numbers at a time):

Code: [Select]
:.Add 2 vectors
:.Vector 1 pointer in r1
:.Vector 2 pointer in r2
:.Resultant vector pointer in r3
:Lbl ADD
:{r1}r+{r2}r->{r3}r
:{r1+2}r+{r2+2}r->{r3+2}r
:Return

So the first line you're adding the X components and the second line you're adding the Y components.  You can use this code for example like this:
Code: [Select]
:.Initialize vector A with (10,20)
:10->A
:20->B
:
:.Initialize vector C with (5,-10)
:5->C
:-10->D
:
:.Add the vectors and store the result into vector E
:sub(ADD,°A,°C,°E)

So now the E holds 15 and F holds 10 thus the vector E has value (15,10).  You can also call the same routine with L1 instead of °E for instance which would save the vector to the locations {L1} through {L1+3} instead of to one of the Axe variables.

The best way to think about the dereferenced variables is like you think about the L1-L6 pointers.  Each variable has it's own "free-ram" (exactly 2 bytes of it) so just like you can get a  free ram location using L1, you can now get the ram location of any variable.  The biggest difference is that when you want to read from a variable, you can just type the letter of the variable so it saves you a lot of typing.  If you wanted to get the ram in L1 on the other hand, you would have to do {L1}r.  And yes, that means that {°A}r is exactly the same as just typing A.
Title: Re: Axe Parser
Post by: Raylin on September 28, 2010, 07:52:52 am
Ah. I get it. :)

Thank you, sir.
Title: Re: Axe Parser
Post by: shmibs on September 28, 2010, 08:30:41 am
does this mean that 0->A->B->C etc to J (or some other later value) can now be written as
:for([some variable outside the set to be initialized,0,[number of vars minus one]
:0->{[counter var]*2+°A}rEnd
?

is that more efficient size wise than the huge list above?
Title: Re: Axe Parser
Post by: calc84maniac on September 28, 2010, 09:08:50 am
It might be better to do:
:0->A
:Fill(°A,°J-°A+1


(I assume that °J-°A+1 will be considered as a constant, can Quigibo confirm this?)

Edit:
I just tried it myself, it does indeed seem to be assembled as a constant.
Title: Re: Axe Parser
Post by: Raylin on September 28, 2010, 10:13:42 am
So, in essence, dereferencing is just directly using the variables as chunks of memory instead of changing the value of the variable?
Title: Re: Axe Parser
Post by: Deep Toaster on September 28, 2010, 08:06:33 pm
I think I will give a warning message from now on when the size passes 8812 bytes.

Let's see ... since Axe puts the data on the bottom anyway, maybe you could use that to differentiate the actual code from the data?
Title: Re: Axe Parser
Post by: calcdude84se on September 28, 2010, 08:12:34 pm
What you say would work but for this fact: :(
I would suggest you only say that when code passes that mark, but then I remembered that you decided to mix subroutines and code ;D
Title: Re: Axe Parser
Post by: Deep Toaster on September 30, 2010, 11:31:38 am
What do you mean by mixing subroutines and code? Subroutines should count as part of the code, anyway, because you can execute it, but then the data comes after that, right?
Title: Re: Axe Parser
Post by: calc84maniac on September 30, 2010, 12:36:58 pm
I think he meant mixing subroutines and data.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 30, 2010, 05:55:17 pm
Wasn't there support for inline data too, now?
Title: Re: Axe Parser
Post by: Quigibo on October 01, 2010, 04:56:25 am
There has always been support for inline data with the Asm() command.  It literally just inserts the hex code right there.  But the other data like strings are still added to the data section at the end of the program, it just doesn't assign a name to the pointer.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 01, 2010, 09:45:16 am
Ah right. Thanks for the clarification :)
Title: Re: Axe Parser
Post by: yoman82 on October 01, 2010, 05:12:36 pm
Has there ever been any consideration of inline basic? It was brought up before, and I think it be awesome, however historically basic-asm conversion has been... well, nonexistant.
Title: Re: Axe Parser
Post by: Runer112 on October 01, 2010, 05:18:33 pm
Why would you want inline basic? Axe can pretty much do everything basic can, and more, all faster and better. And what do you mean by "basic-asm conversion?" That's pretty much what Axe is already.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 01, 2010, 05:53:24 pm
He probably just wants to use the same syntax as in TI-BASIC to not have to learn everything, but I am not certain this would be easy to implement. Or maybe he just wants to be able to use some math functions from BASIC inside his axe programs?

IMHO the best solution would be to use multiple sub-programs and make your program or game an hybrid of Axe executables and BASIC programs, like some larger BASIC games that are split in multiple files to save space.

An advantage to using BASIC code would be the smaller file size and getting rid of the 8 KB executable code limit, but then you will have portions of your program that will be much slower.
Title: Re: Axe Parser
Post by: Deep Toaster on October 01, 2010, 10:25:31 pm
I think he meant mixing subroutines and data.

Huh? That wouldn't work, though, because subroutines are runnable and might simply be a label as part of the main program. If it were moved into the data, that would cause a lot of programs x.x
Title: Re: Axe Parser
Post by: calcdude84se on October 01, 2010, 11:06:23 pm
"Subroutines", to my knowledge, does not mean Axe code, but rather the routines used by individual commands, like DispGraphr
Title: Re: Axe Parser
Post by: Deep Toaster on October 01, 2010, 11:08:52 pm
Ohh, I see. Okay, I see the problem now.

Maybe Axe could put the subroutines before the data, and count them separately?
Title: Re: Axe Parser
Post by: calcdude84se on October 01, 2010, 11:16:22 pm
The only problem with that is it would require a more complex, slower compiler. :(
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 01, 2010, 11:42:52 pm
How much slower? Would it be like 1 minute compiling per 10 KB?
Title: Re: Axe Parser
Post by: Raylin on October 02, 2010, 02:24:19 am
Question: Axe can copy data from archived appvars?
Title: Re: Axe Parser
Post by: Runer112 on October 02, 2010, 05:46:44 am
Question: Axe can copy data from archived appvars?

Answer: Yes.

Example:
Code: [Select]
If GetCalc("appvDATA",Y₁)
Copy(Y₁,L₁,256)
Else
.Appvar not found in archive
End
Title: Re: Axe Parser
Post by: yoman82 on October 02, 2010, 10:50:02 am
DJ- I'm talking about mainly making use of the TI BASIC math functions.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 02, 2010, 10:55:58 am
Ah ok. Unfortunately this seems like it would be something hard to do, especially running the BASIC interpreter in the middle of an Axe program. Maybe Quigibo could confirm if it would be easy or not
Title: Re: Axe Parser
Post by: shmibs on October 02, 2010, 11:53:11 am
un diquestion:
is there any fast/efficient way to Or one screen buffer over the other?
i'm trying to avoid a massive for( loop
Title: Re: Axe Parser
Post by: Runer112 on October 02, 2010, 12:14:28 pm
That's pretty much the way to do it. You'd be surprised just how fast one massive For() loop that OR's the contents of both buffers is, though. I calculated that the following loop runs about 40 times per second at 6MHz:

Code: [Select]
Repeat getKey(15)
For(A,0,383)
.That ﹢ symbol is the 16-bit OR operator
{A*2+L₆}ʳ﹢{A*2+L₃}ʳ→{A*2+L₆}ʳ
End
C+1→C
End
Title: Re: Axe Parser
Post by: Quigibo on October 02, 2010, 03:48:41 pm
If you want a really extreme optimization for or-ing the screen, here it is.  It will be noticeably faster and smaller:

Code: [Select]
.# represents the 16-bit or operation
L₆→A
While -768-L₆
{A}ʳ#{A+L₃-L₆}ʳ→{A}ʳ+1→A
End
Title: Re: Axe Parser
Post by: calc84maniac on October 02, 2010, 04:18:53 pm
Infinite loop much? D:

Edit:
Oh, that is the minus sign, not the negative sign.
Title: Re: Axe Parser
Post by: Deep Toaster on October 02, 2010, 08:15:29 pm
That's pretty much the way to do it. You'd be surprised just how fast one massive For() loop that OR's the contents of both buffers is, though. I calculated that the following loop runs about 40 times per second at 6MHz:

Code: [Select]
Repeat getKey(15)
For(A,0,383)
.That ﹢ symbol is the 16-bit OR operator
{A*2+L₆}ʳ﹢{A*2+L₃}ʳ→{A*2+L₆}ʳ
End
C+1→C
End

Whoa, how'd you get the small r to work in a code tag?
Title: Re: Axe Parser
Post by: shmibs on October 02, 2010, 08:59:32 pm
WONDERFUL
that will do nicely, thanks
EDIT:oh, and ʳ is a character of its own
Title: Re: Axe Parser
Post by: jnesselr on October 02, 2010, 09:02:25 pm
That's pretty much the way to do it. You'd be surprised just how fast one massive For() loop that OR's the contents of both buffers is, though. I calculated that the following loop runs about 40 times per second at 6MHz:

Code: [Select]
Repeat getKey(15)
For(A,0,383)
.That ﹢ symbol is the 16-bit OR operator
{A*2+L₆}ʳ﹢{A*2+L₃}ʳ→{A*2+L₆}ʳ
End
C+1→C
End

Whoa, how'd you get the small r to work in a code tag?
"ʳ"  There is a symbol for it. Just copy/paste.
Title: Re: Axe Parser
Post by: Deep Toaster on October 02, 2010, 10:49:19 pm
Nice. Thanks!
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 03, 2010, 04:40:04 am
woah, that's one extreme optimization and routine :O

I will have to study the code hard to understand it but I'm glad to see it is possible to do that. Thanks a lot
Title: Re: Axe Parser
Post by: squidgetx on October 03, 2010, 05:22:45 pm
Quick question: Is this:
Code: (1 byte variable For() loop) [Select]
min→{L1+A}
While {L1+A}<max
{L1+A}+1→{L1+A}
<code>
End

faster than:

Code: (Standard For() loop) [Select]
For(Var, min, max)
<code>
End

?
Title: Re: Axe Parser
Post by: calcdude84se on October 03, 2010, 05:23:30 pm
I would hope a for loop is faster, though Quigibo will have to back me up on this.
Title: Re: Axe Parser
Post by: Deep Toaster on October 03, 2010, 05:32:04 pm
Quick question: Is this:
Code: (1 byte variable For() loop) [Select]
min→{L1+A}
While {L1+A}<max
{L1+A}+1→{L1+A}
<code>
End

faster than:

Code: (Standard For() loop) [Select]
For(Var, min, max)
<code>
End

?


The For( loop is definitely faster if the first one uses one-byte numbers, because in Axe all operations are 16-bit. So in the one with the While loop, the program has to convert the numbers back and forth between 8- and 16-bit, and that takes a bit longer. Plus it's bigger. So use the For( loop :)
Title: Re: Axe Parser
Post by: Quigibo on October 03, 2010, 06:32:43 pm
A while loop is better if you can avoid a comparison operation and use the "0 is false everything else is true" instead:

Code: [Select]
For(A,0,5)
<code>
End

0->A
While -5
<Code>
A+1->A
End

The second one is actually smaller and faster than the first one.  The only reason I can't make this the default behavior for the for loop is actually because if A happens to be above 5 in this example, it would keep counting up until it passes 65536 and loops back to 5 again.  You're basically coding a less optimized for loop here but since you skip the comparison, it actually makes it 1 byte smaller and negligibly faster.
Title: Re: Axe Parser
Post by: Deep Toaster on October 03, 2010, 07:47:31 pm
On a related question,
Code: (Axe) [Select]
:Lbl LP
//code
:Goto LP
would be more efficient than
Code: (Axe) [Select]
:While 1
//code
:End
right? If so, a quick feature request: automatically making While 1 and Repeat 0 infinite loops.
Title: Re: Axe Parser
Post by: calc84maniac on October 03, 2010, 07:48:14 pm
And using a While loop, you can use steps other than 1 :)


Edit:
I got somewhat ninja'd, so I was still talking about For( loops.
Title: Re: Axe Parser
Post by: Deep Toaster on October 03, 2010, 07:52:25 pm
True. And just wondering: Does anyone have an example of where DS<( would be useful?
Title: Re: Axe Parser
Post by: Runer112 on October 03, 2010, 08:59:33 pm
True. And just wondering: Does anyone have an example of where DS<( would be useful?

DS<() Is useful when you have something in a loop/interrupt that you don't want to run every iteration. For instance, if you want to update the screen in a program's main loop or in an interrupt but don't want the screen updating too often (to save processing power for other things), enclose the screen updating portion in something like DS<(A,4) so the screen is only updated every fourth iteration.
Title: Re: Axe Parser
Post by: Deep Toaster on October 03, 2010, 10:08:16 pm
D'oh! I could have used that to save like fifty bytes off Simul :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 03, 2010, 11:58:35 pm
I use DS<() a lot in Supersonic Ball, because the animation speed for sprites/tiles varies from a level to another.
Title: Re: Axe Parser
Post by: Runer112 on October 04, 2010, 03:54:38 pm
While we're on the topic of optimizations... Would something like A-128≥≥0 be more optimized than A≥≥128? And if so, why is the ≥≥CONST entry in Auto Opts.txt listed as taking a whole 11 bytes more than ≥≥0?
Title: Re: Axe Parser
Post by: Deep Toaster on October 04, 2010, 04:00:09 pm
≥≥0 doesn't really require any code at all in ASM. Every other test really does what you did above: it subtracts the value to test for, and see how the answer compares to zero.
Title: Re: Axe Parser
Post by: Runer112 on October 04, 2010, 04:21:53 pm
≥≥0 definitely requires code, as it needs to check the sign bit and return it's inverse. And I'm also wondering why ≥≥CONST is 11 bytes larger than ≥≥0, because it seems to me that it could be optimized to just combine -CONST and ≥≥0 and only be 4 bytes larger.
Title: Re: Axe Parser
Post by: calc84maniac on October 04, 2010, 04:24:31 pm
While we're on the topic of optimizations... Would something like A-128≥≥0 be more optimized than A≥≥128? And if so, why is the ≥≥CONST entry in Auto Opts.txt listed as taking a whole 11 bytes more than ≥≥0?
A-128≥≥0 will fail for 128 values close to -32768. That's because after you subtract 128, they become positive and then the comparison will think it is greater. The ≥≥CONST routine takes this into account.
Title: Re: Axe Parser
Post by: Runer112 on October 04, 2010, 04:55:57 pm
Ah right, I didn't think of that...
Title: Re: Axe Parser
Post by: Darl181 on October 08, 2010, 10:51:50 pm
I'm kind of new to programming, and there are a few things I'm unfamiliar with.
1. What is a nibble?
2. What can you do with nibbles?
3. In what kind of situation would nibbles be useful?
4. How are nibbles used?
Title: Re: Axe Parser
Post by: Quigibo on October 08, 2010, 11:00:24 pm
A one or zero is a bit.
4 bits = 1 nibble
8 bits = 1 byte
16 bits = 1 word

Get it!? Half of a bite!  ;D  It's hilarious how so many terms in computer and electrical engineering are either about food or sex.  It just shows what goes on in the mind of a programmer...

You can hold 2 nibbles in 1 byte so they're mostly used for compression if you don't need 256 possible values and can use just 16 then you're using half the memory.
Title: Re: Axe Parser
Post by: Darl181 on October 08, 2010, 11:04:40 pm
So you could theoretically halve the space a variable takes?
4. How are nibbles used? commands list, right?
Title: Re: Axe Parser
Post by: tloz128 on October 08, 2010, 11:18:30 pm
Um... what computer terms get their names from sex?
Title: Re: Axe Parser
Post by: Quigibo on October 09, 2010, 05:08:25 am
Its mostly electrical terms.  Like male and female connectors, wire strippers, tickler coil, screws, nuts, etc.

You don't "halve" a variable unless you can actually do it.  If the variable has to hold more than 16 possible unique values then a nibble is not sufficiently large enough to hold your data so you would have to use a byte or word instead.  Some tile mappers for instance might always use 16 or fewer tiles per room and so you can load a palette for each group of rooms and then compress the maps to half the size.

Another example is if your character is always aligned to an 8x8 grid, then the X,Y coordinates can be written to a single byte rather than a separate byte for each variable since there are only 12 X possibilities and 8 Y possibilities.  Keep in mind though, that you should only do this if memory is a problem.  Accessing bytes, and sometimes words, is actually fastest and smallest in the program when it comes to reading memory even though the actual data is bigger.
Title: Re: Axe Parser
Post by: Darl181 on October 09, 2010, 12:06:04 pm
That makes sense.  Thanks!

quote author=tloz128 link=topic=1453.msg72139#msg72139 date=1286594310]
Um... what computer terms get their names from sex?
[/quote]
Can't say I've looked into that much...
Title: Re: Axe Parser
Post by: Deep Toaster on October 09, 2010, 06:35:02 pm
FOOD ... j/k ;D

Btw, here (http://ourl.ca/4550)'s an example where nibbles are really useful.
Title: Re: Axe Parser
Post by: Darl181 on October 14, 2010, 12:07:00 am
Another question.
The game I've been working of, TWHG, currently has a basic and space-consuming way of naming the levels.
Code: [Select]
"appvWHGLVL1"→Str01
"appvWHGLVL2"→Str02
"appvWHGLVL3"→Str03
...And so on
"appvWHGLVL9"→Str09

.A is the level number
.↓Reference like this
Str01+(A*9)

I tried optimizing it.
Code: [Select]
"appvWHGLVL0"→Str0V
.A is the level number
A→{Str0V+7}
Ideally, this would change the number in the Str0V and so reference a different appvar.
So far, I haven't had much luck with it.
Does anybody have any ideas how to get this to work? ???
Title: Re: Axe Parser
Post by: Deep Toaster on October 14, 2010, 12:12:56 am
It's because "0" and 0 are different. The character "0" actually has value E30. Plus, appv is really two bytes, so what you'd need to do is
Code: (Axe) [Select]
A+30→{Str0V+8}
instead of
Code: (Axe) [Select]
A→{Str0V+7}
.

EDIT: Haven't tested it myself; can you tell me if it works?
Title: Re: Axe Parser
Post by: Darl181 on October 14, 2010, 12:29:54 am
Compiling...defragmenting(it's an app)...writing...
No, didn't work.  Maybe I could play around with the variables tonight and try to get results.

Hey, just noticed...the next post will be reply #1337
Title: Re: Axe Parser
Post by: Deep Toaster on October 14, 2010, 12:35:54 am
Wait! Sorry, I confused myself for a moment. It's not +8, it's +7.

The +30 should be right, though.

Also, 1337!
Title: Re: Axe Parser
Post by: nemo on October 14, 2010, 06:24:43 pm
It's because "0" and 0 are different. The character "0" actually has value E30. Plus, appv is really two bytes, so what you'd need to do is
Code: (Axe) [Select]
A+30→{Str0V+8}
instead of
Code: (Axe) [Select]
A→{Str0V+7}
.

EDIT: Haven't tested it myself; can you tell me if it works?

the 30 should either be replaced with E30 or 48.
Title: Re: Axe Parser
Post by: Darl181 on October 14, 2010, 06:36:04 pm
So I have to do the little F or something?
Wait, trying to compile now and it's saying
ERR: UNKNOWN ERR
Code: 4535555

I'm using axe version 0.4.5
Title: Re: Axe Parser
Post by: ztrumpet on October 14, 2010, 06:38:55 pm
So I have to do the little F or something?
Use the little E.  Press [2nd] then [,] to get it. :)
Title: Re: Axe Parser
Post by: Darl181 on October 14, 2010, 06:40:46 pm
So I have to do the little F or something?
Use the little E.  Press [2nd] then [,] to get it. :)
Got it.
I don't get why it's not compiling though...

O_o nvm it just compiled.
I guess it garbage collected or something.
Title: Re: Axe Parser
Post by: Michael_Lee on October 14, 2010, 06:51:45 pm
I don't think I quite have the hang of the Exch( command yet - I'm trying to switch the numbers at variables A and B

Code: [Select]
.TEST
30->A
55->B
ClrHome
Disp A->DEC,B->DEC,i
Exch(A,B,2)
Disp A->DEC,B->DEC,i
Pause 5000

This doesn't work - what am I doing wrong?

(Edited)
Title: Re: Axe Parser
Post by: nemo on October 14, 2010, 06:53:40 pm
change Exch(A,B,1) to Exch(A,B,2). axe variables A-Z+Theta are 2 bytes large.
Title: Re: Axe Parser
Post by: Michael_Lee on October 14, 2010, 06:55:31 pm
Okay, tried that, but nothing happened.  The two numbers aren't switching at all.
Title: Re: Axe Parser
Post by: Deep Toaster on October 14, 2010, 06:59:36 pm
A and B are variables, while what you need are the pointers to the variables. Use
Code: (Axe) [Select]
:Exch(°A,°B,2)
instead.

the 30 should either be replaced with E30 or 48.

Whoops, forgot about that :-[
Title: Re: Axe Parser
Post by: nemo on October 14, 2010, 07:01:09 pm
oops, duh. i forgot. axe variables are pointers. when you do Exch(A,B,2), you are swapping the two bytes at A and the two bytes at B. this can cause a ram clear... my apologies. if you run it again, the values will switch back and you shouldn't have a problem though. since exch() is generally used to exchange larger amounts of data your example program is more complex.
 what you want is Exch(°A,°B,2). this gets the pointers to the variables and exchanges them.

ninja'd
Title: Re: Axe Parser
Post by: Deep Toaster on October 14, 2010, 07:02:06 pm
Yeah, so I'd suggest a RAM clear before you do anything else, just to make sure there aren't any weird glitches.
Title: Re: Axe Parser
Post by: Michael_Lee on October 14, 2010, 07:58:37 pm
Sweet.  Problem solved, thanks.
Title: Re: Axe Parser
Post by: Quigibo on October 15, 2010, 02:52:10 am
Its less code (I think) to just use a temporary:

A->r6
B->A
r6->B

But I am considering adding an "ultra temporary variable" (the pi token) to the axe language to allow greater code optimization. It would use the assembly instruction "ex de,hl" to take advantage of the de register for extremely temporary storage when using store commands, small number incrementing/decrementing, power-of-2 multiplication and referencing commands.  Pretty much anything else will destroy this extremely fragile variable.  Using it for an exchange command for instance would look like this:

A->pi
B->A
pi->B

This would only be 14 bytes instead of 18 from the earlier example.  There are other exploits you can take advantage of too.  After a multiplication (non-optimized) the pi variable would hold the high order word of the result so you can essentially compute the high order *^ and regular * multiplication simultaneously.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 15, 2010, 03:27:29 am
I assume this variable would be a bit like Ans, right?
Title: Re: Axe Parser
Post by: Runer112 on October 15, 2010, 04:29:20 am
I assume this variable would be a bit like Ans, right?

It wouldn't be like Ans that much, but I guess I see how it could be a bit similar. Pretty much all loading and numerical operations put the result in the hl register, so hl is more like the Ans of Axe. The point of this is having something like a backup Ans that only takes one-byte instructions to load from and store to, as opposed to three-byte instructions with data in RAM. Any use of this would have to be simple and small, as just about any routine or math call would overwrite its value
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 15, 2010, 05:12:50 am
AH ok I see. That could be pretty handy :D
Title: Re: Axe Parser
Post by: Deep Toaster on October 15, 2010, 05:05:12 pm
That's a great idea! Why ex, though? Wouldn't that mean we wouldn't be able to do
Code: (Axe) [Select]
:A->pi->B
?
Title: Re: Axe Parser
Post by: Quigibo on October 15, 2010, 07:15:06 pm
The ex command is only 1 byte whereas loading a 16 bit register is 2 bytes.  And that statement could still be done like this:

Code: [Select]
:A->B->pi
Title: Re: Axe Parser
Post by: calc84maniac on October 15, 2010, 07:36:31 pm
Aha, I've been wanting this feature for a while, but I thought it might be too much trouble. It would help for interfacing with Asm(), I'm sure :)
Title: Re: Axe Parser
Post by: Deep Toaster on October 15, 2010, 07:37:43 pm
The ex command is only 1 byte whereas loading a 16 bit register is 2 bytes.  And that statement could still be done like this:

Code: [Select]
:A->B->pi

Oh, okay. Make sure that's in the docu, though :)
Title: Re: Axe Parser
Post by: calcdude84se on October 15, 2010, 08:06:20 pm
Aha, I've been wanting this feature for a while, but I thought it might be too much trouble. It would help for interfacing with Asm(), I'm sure :)
Agreed. Perhaps use another token to represent bc, "!" perhaps? It wouldn't be as optimized, because you have to use "ld b,h \ ld c,l" rather than "ex de,hl", but it would definitely help in interfacing with assembly and using bcalls. (Also, any possibility of using a?)
When you make these things official, commands will start having to have a "destroyed" field in the documentation ;D
Title: Re: Axe Parser
Post by: Deep Toaster on October 15, 2010, 08:45:41 pm
Definitely not !. That's not(, remember.

Maybe ??
Title: Re: Axe Parser
Post by: calcdude84se on October 15, 2010, 08:48:53 pm
Perhaps. But realize that "!" is only used right before "If ". It could get another use ;)
I think "!" and "?" could work for bc and a, in either order.
Title: Re: Axe Parser
Post by: Deep Toaster on October 15, 2010, 08:55:50 pm
Perhaps. But realize that "!" is only used right before "If ". It could get another use ;)

For a moment there I thought If !(A=2) was allowed as well ... whoops.

But people might still be confused. What about using de for DE, bc for BC, and a for A? Lowercase letters aren't used except in strings, anyway. Except for bBINARY...
Title: Re: Axe Parser
Post by: calcdude84se on October 15, 2010, 08:59:30 pm
That's 4, 4, and 2 bytes for what could be 1... x.x
Title: Re: Axe Parser
Post by: calc84maniac on October 15, 2010, 11:09:07 pm
Okay, here are my thoughts on using the DE register.

pi and ->pi should be a two-byte load or store. A different method or token should be used for the one-byte swap. This will let it be treated like any other variable, without strange side effects that need to be learned. I know I would miss being able to directly load/store (such as if I want to use DE as a pointer, like {pi+1->pi})

Also, it may be a good idea to change as many operations as possible to trash BC instead of DE to make the pi variable less volatile. If there are any operations that need the ex de,hl to optimize, just ask if you need help optimizing the BC version. For example, the > and <= operations can be done without a swap by setting the carry flag before the sbc instruction.

Finally, a feature request for a /^ operator that returns the quotient and the remainder at the same time.

Edit:
Also, I assume that operators working on pi will be optimized. For example, +pi should compile to one byte of code (add hl,de)
Title: Re: Axe Parser
Post by: nemo on October 16, 2010, 06:18:10 pm
just found something cool. if you *really* don't have any temp variables to exchange two values, the following code should do the trick:

Code: [Select]
. "xor" is the 16 bit plotstyle-box xor, not the actual word xor.
A xor B->A
A xor B->B
A xor B->A


Title: Re: Axe Parser
Post by: Runer112 on October 16, 2010, 06:23:06 pm
just found something cool. if you *really* don't have any temp variables to exchange two values, the following code should do the trick:

Code: [Select]
. "xor" is the 16 bit plotstyle-box xor, not the actual word xor.
A xor B->A
A xor B->B
A xor B->A




Woah, that's a neat trick! I never thought of that. But you could optimize it a bit :P

Code: [Select]
A xor B->A xor B->B xor A->A
Title: Re: Axe Parser
Post by: nemo on October 16, 2010, 06:25:55 pm
i'm not sure if it's more optimized than just A->C: B->A: C->B, though.
Title: Re: Axe Parser
Post by: Runer112 on October 16, 2010, 06:59:25 pm
It's definitely less optimized than that, but I guess it's nice to not have to worry about having a variable to switch them through that you don't need for other things. Although I doubt a program will be using every single byte of safe RAM areas, so it would probably be easiest to just designate a 2-byte pair in a safe RAM area for things like that.
Title: Re: Axe Parser
Post by: ztrumpet on October 16, 2010, 07:32:25 pm
Aha, I've been wanting this feature for a while, but I thought it might be too much trouble. It would help for interfacing with Asm(), I'm sure :)
Agreed. Perhaps use another token to represent bc, "!" perhaps? It wouldn't be as optimized, because you have to use "ld b,h \ ld c,l" rather than "ex de,hl", but it would definitely help in interfacing with assembly and using bcalls. (Also, any possibility of using a?)
When you make these things official, commands will start having to have a "destroyed" field in the documentation ;D
What about using 'e' instead of '!'? ('e' is [2nd] [/])
Title: Re: Axe Parser
Post by: calcdude84se on October 16, 2010, 08:05:08 pm
Euler's e is the bit command ;)
I'm not sure if it could work... It might be able to...
Title: Re: Axe Parser
Post by: ztrumpet on October 16, 2010, 08:06:24 pm
Whoops, I forgot about that. ;)

I still really like the pi idea. :)
Title: Re: Axe Parser
Post by: Quigibo on October 16, 2010, 09:16:16 pm
Even smaller and more intuitive than this:
Code: [Select]
A xor B->A xor B->B xor A->A
Is this:
Code: [Select]
A-B->A+B->B-A->A
First, A' = A - B
Then, B' = A' + B = (A - B) + B = A
Then, A'' = B' - A' = (A) - (A - B) = A - A + B = B

So you've swapped the values without any extra variable usage, and the add and subtract operations are much less code since the 16 bit xor isn't built into the z80 instruction set.  But yeah, a temporary is still smaller and faster.  In the ARM architecture, they're actually the same amount of code and speed so you can do this with no penalty.
Title: Re: Axe Parser
Post by: Deep Toaster on October 16, 2010, 09:58:31 pm
Wow, nice find!

/me tries to understand it
Title: Re: Axe Parser
Post by: squidgetx on October 17, 2010, 12:38:46 pm
Quick question:

When opening files (getcalc(str,Y1) ), does the value Y1 behave like a pointer in the way that, to access the nth byte of the file, you can do {y1+n}?
In other words, is
Code: [Select]
"appvblah"->Str1
GetCalc(Str1)->A
{A+100}
the same as
Code: [Select]
"appvblah"->Str1
GetCalc(Str1,Y1)
{Y1+100}
besides the different locations of appvar blah?
Title: Re: Axe Parser
Post by: Quigibo on October 17, 2010, 05:29:21 pm
Yes.  Y1 can only be used in a very narrow range of commands.  You can only reference them or copy them right now.  But in the future, any command which has the format command{} should work with files.
Title: Re: Axe Parser
Post by: squidgetx on October 17, 2010, 07:41:28 pm
Cool, thanks.
/me goes off to figure out the old way of accessing nibbles
Title: Re: Axe Parser
Post by: Deep Toaster on October 18, 2010, 08:32:45 pm
Just in case, it was A/16 for the top and A^16 for the bottom.
Title: Re: Axe Parser
Post by: nemo on October 19, 2010, 07:40:33 pm
quigibo, i noticed that
Code: [Select]
3->{L1}
->{L1+1}
->{L1+2}
is more optimized than
Code: [Select]
3->{L1}
Fill(L1,3)

when is the point where the latter becomes more optimized?
Title: Re: Axe Parser
Post by: Deep Toaster on October 19, 2010, 07:45:09 pm
Oh, and a feature request: automatically making things like Output(0,0) be equivalent to Output(0) (and Output(0,0,"ERKH") be equivalent to Output(0):Disp "ERKH"). In other words, making it automatically calculate the full two bytes as it compiles.
Title: Re: Axe Parser
Post by: Yeong on October 19, 2010, 08:42:26 pm
I know that Axe came out long time ago...
But what is the pro of the axe over basic?(Or am I so stupid to ask this kind of question?)
If it's better, can you tell me where the tutorial for it is?
Title: Re: Axe Parser
Post by: guy6020665 on October 19, 2010, 08:57:58 pm
The pro(s) of axe over basic are many; speed, sprites, relatively easy greyscale, buffer shifting, and so much more.
As for a tutorial I believe one is included with the Zip file, and I think SirCmpwn was working on one but I don't know the status of it.
Title: Re: Axe Parser
Post by: Yeong on October 19, 2010, 08:58:58 pm
I'm making YEONG RPG right now...
Is it easy to make RPG with Axe?
Title: Re: Axe Parser
Post by: nemo on October 19, 2010, 09:05:43 pm
it's never really "easy" to make an RPG. no matter the language, it's a lot of work. granted, i'd think it's safe to say it's easier to make a better (in terms of speed and graphics, not gameplay) RPG in axe than basic. of course it takes awhile to get used to Axe, though
Title: Re: Axe Parser
Post by: Yeong on October 19, 2010, 09:06:29 pm
Darn it..
"Getting used to it" part is always the hardest part.
Title: Re: Axe Parser
Post by: guy6020665 on October 19, 2010, 09:08:19 pm
Umm  I personally haven't tried an axe RPG so I don't know, but FinaleTI is working on an RPG called Nostalgia so i believe he would be able to best answer your question.

Personally i think that making an RPG with axe shouldn't be too much harder than in Basicif you are experienced in both, but you seem to have not been using axe so it might be harder for you, but if you learn axe well it should be about the same, unless you're planning on doing some extremely creative and complicated things.

If you haven't yet, take a look at Raylin's Rules for RPGs to start
http://ourl.ca/6546

Never mind I already told you about it before.

And a look at Nostalgia
http://ourl.ca/6009

Edit: actually now that i think again i think graphmastur was planning on making TAO Unleashed with axe
Title: Re: Axe Parser
Post by: nemo on October 19, 2010, 09:14:34 pm
"getting used to it" is going to be a part of it no matter what programming language you choose, whether that's TI Basic, Axe, C, Java, ASM or any other language. i'd be lying if i told you it's easy to learn axe. but it's probably a hundred times easier to learn than assembly, no offense to the ASM coders on here. however, if you're "used to" TI Basic, and want some speed/fancier graphics, you could use Xlib or Celtic.
Title: Re: Axe Parser
Post by: ztrumpet on October 19, 2010, 09:36:46 pm
Oh, and a feature request: automatically making things like Output(0,0) be equivalent to Output(0) (and Output(0,0,"ERKH") be equivalent to Output(0):Disp "ERKH"). In other words, making it automatically calculate the full two bytes as it compiles.
I'm pretty sure Axe does this already. ;)

I'm actually working on an Axe RPG right now, Blox. More info on it later, though. ;D
Title: Re: Axe Parser
Post by: guy6020665 on October 19, 2010, 09:40:51 pm
Really ztrumpet? Have you mentioned it before now?

Wow lot's of planned RPG's in axe
Title: Re: Axe Parser
Post by: ztrumpet on October 19, 2010, 09:45:41 pm
It *was* my contest entry, and I've never mentioned it on the forums, save a few references and my sig.  It's physics driven and centers on moving around blocks. :)  Once I work on it again, I'll post info on it. ;D
Title: Re: Axe Parser
Post by: guy6020665 on October 19, 2010, 09:47:07 pm
Cool. (this is making me want to go work on my own RPG)
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 20, 2010, 02:44:32 am
it's never really "easy" to make an RPG. no matter the language, it's a lot of work. granted, i'd think it's safe to say it's easier to make a better (in terms of speed and graphics, not gameplay) RPG in axe than basic. of course it takes awhile to get used to Axe, though
It depends, in BASIC, if the RPG is not super large (like 4 dungeons and one or two towns max) it can be much eaiser in BASIC, because you do not have to spend weeks trying to figure out how you will get something higher than 1 frames per second on a regular 83+ due to all enemies and ships moving around. In a RPG, almost everything is turn-based so you worry so much less about optimizing speed that it makes some RPGs easier to code than any other game in BASIC. However large RPGs are ridiculously long to create.

An example: Illusiat 7, 8 and 9 took me 2 weeks to create each of them. Mortal Kombat (included in Omnipack SE) took me 2 weeks, even though it's a 10x smaller game with shorter gameplay. xLIB xLIB Revolution, which is just a DDR clone with fancy graphics took me 2 weeks as well (mostly coding, not graphics). In Mortal Kombat I spent most of the time trying to increase the speed (and failed since it was back in 2002)
It *was* my contest entry, and I've never mentioned it on the forums, save a few references and my sig.  It's physics driven and centers on moving around blocks. :)  Once I work on it again, I'll post info on it. ;D
Quite ironically, both Omni contests (2009 and 2010) had an entry called Blox in the works but none were finished for the contest. :P Is there a curse on the name or something? D: ({AP} was the one working on the 2009 one)
Title: Re: Axe Parser
Post by: squidgetx on October 23, 2010, 07:05:03 pm
Question: do the r1, r2, r3 vars retain their value after use? ie, would
Code: [Select]
sub(L,1,2,3)
...
Text(0,0,r1>Dec
Text(0,10,r2>Dec
Text(0,20,r3>Dec
...
Lbl L
...
Return

write 1,2,and 3 on the screen?

And if you call a subroutine with no arguments, are these vars preserved?
As in
Code: [Select]
sub(L,1,2,3)
sub(A)
Lbl A
Text(0,0,r1>Dec
Text(0,10,r2>Dec
Text(0,20,r3>Dec
Return
Lbl L
...
Return
also writes 1, 2 and 3 on the screen?
Title: Re: Axe Parser
Post by: FinaleTI on October 23, 2010, 07:35:30 pm
If I'm not mistaken, it shouldn't overwrite them.
Unless you call another subroutine that overwrites them, or you write to them manually, they should stay intact.
Title: Re: Axe Parser
Post by: BlackRabbit on October 23, 2010, 08:48:37 pm
I'm sure this question has been asked several times but how do, or can, you display full-sized pictures? I haven't seen anything about it anywhere.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 23, 2010, 08:58:08 pm
Hi and welcome here :). The best way to do it is to store a TI-BASIC image in  Pic0 through Pic9, then in an Axe program, put [PicNUMBER]->Pointer at the beginning of the code, for example [Pic1]->GDB0. When compiling, this will import the entire picture in the program. To display it, I believe that you do Copy(GDB0,L6,756) then DispGraph or something like that. That would copy the image to the buffer (L6) and DispGraph would display the buffer on the screen.
Title: Re: Axe Parser
Post by: nemo on October 23, 2010, 09:01:24 pm
DJ Omnimaga is correct. one minor thing though is you would do Copy(GDB0,L6,768) instead of Copy(GDB0,L6,756). if you merely want to display the picture, you can also do Pic#->DispGraph.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 23, 2010, 09:10:23 pm
Would 768 add garbage at the bottom, though? I guess he could maybe do a Fill() afterward
Title: Re: Axe Parser
Post by: FinaleTI on October 23, 2010, 09:10:55 pm
DJ Omnimaga is correct. one minor thing though is you would do Copy(GDB0,L6,768) instead of Copy(GDB0,L6,756). if you merely want to display the picture, you can also do Pic#->DispGraph.
Well, that depends. If you stored the picture on calc, it'll only be 767 bytes in the memory menu, and you'll want to use Copy(GDB0,L6,756) because the 64th row is undefined. If you sent it from the computer, it might be 779 bytes in the memory menu, then you can use Copy(GBD0,L6,768) because the pic will contain the 64th row.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 23, 2010, 09:12:16 pm
Oh sending it to the comp increases its size? I totally forgot that was how I created 779 bytes files in the past...
Title: Re: Axe Parser
Post by: Deep Toaster on October 24, 2010, 09:37:01 am
I'm pretty sure you can make it bigger, but I doubt all pictures sent from a comp are automatically changed to 779...
Title: Re: Axe Parser
Post by: FinaleTI on October 24, 2010, 09:38:46 am
If you define rhe 64th row in the picture then send it, it should be 779 bytes.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 24, 2010, 09:20:49 pm
I'm pretty sure you can make it bigger, but I doubt all pictures sent from a comp are automatically changed to 779...
Years ago I remember something about xLIB being able to create pictures as large as 2048 bytes, but then tr1p1ea changed it so sprite 96-192 is feteched from the next pic and 193 to 255 from the other one after. He thought about allowing using sprite/tile IDs up to 65536 but I forgot if he finally did. It has been so long since I last used xLIB.
Title: Re: Axe Parser
Post by: BlackRabbit on October 24, 2010, 09:33:49 pm
Thanks for the info. This will make my life a lot easier. Thank you everybody.   :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 25, 2010, 12:34:08 am
No problem. We're glad to help. :)

Are you planning any projects in particular by the way? :)
Title: Re: Axe Parser
Post by: Runer112 on October 25, 2010, 06:45:51 pm
I'm not sure if this is a bug, intentional, or what, but something interesting I just discovered: lowercase letters not in a string act like a period and turn the rest of the line into a comment. I don't see much of a use to this, but I found out when I was trying to optimize a program by changing a Fill() command to Copy(). The size savings when I did were much larger than I expected, so I was questioning how that was possible with the change I just made. I was using the TI Program Editor bundled with older versions of TI Connect to write the program, and I realized that I had literally written "Copy(" when the actual command was "conj(" which would explain some things. But I found it odd that it actually parsed successfully, treating the first "C" as the variable C and ignoring the rest of the line.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 25, 2010, 06:52:10 pm
Wow, that's weird. Maybe it treats all invalid chars starting a line as a dot?
Title: Re: Axe Parser
Post by: Deep Toaster on October 25, 2010, 07:39:17 pm
I'm not sure if this is a bug, intentional, or what, but something interesting I just discovered: lowercase letters not in a string act like a period and turn the rest of the line into a comment. I don't see much of a use to this, but I found out when I was trying to optimize a program by changing a Fill() command to Copy(). The size savings when I did were much larger than I expected, so I was questioning how that was possible with the change I just made. I was using the TI Program Editor bundled with older versions of TI Connect to write the program, and I realized that I had literally written "Copy(" when the actual command was "conj(" which would explain some things. But I found it odd that it actually parsed successfully, treating the first "C" as the variable C and ignoring the rest of the line.

That's TI-Connect-side, right?
Title: Re: Axe Parser
Post by: Runer112 on October 25, 2010, 09:04:22 pm
I'm not sure if this is a bug, intentional, or what, but something interesting I just discovered: lowercase letters not in a string act like a period and turn the rest of the line into a comment. I don't see much of a use to this, but I found out when I was trying to optimize a program by changing a Fill() command to Copy(). The size savings when I did were much larger than I expected, so I was questioning how that was possible with the change I just made. I was using the TI Program Editor bundled with older versions of TI Connect to write the program, and I realized that I had literally written "Copy(" when the actual command was "conj(" which would explain some things. But I found it odd that it actually parsed successfully, treating the first "C" as the variable C and ignoring the rest of the line.

That's TI-Connect-side, right?

What would be TI-Conncect-side? It doesn't matter where the source came from, lowercase letters are parsed like periods.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 25, 2010, 09:11:31 pm
In SourceCoder, I believe that if you type Copy, it recognize it as conj, so such thing may not happen in SourceCoder.
Title: Re: Axe Parser
Post by: Runer112 on October 25, 2010, 09:17:42 pm
In SourceCoder, I believe that if you type Copy, it recognize it as conj, so such thing may not happen in SourceCoder.

The test I just did with SourceCoder disagrees with this. That would prevent you from typing the literal string "Copy" and SourceCoder isn't designed to be an Axe source editor anyways.
Title: Re: Axe Parser
Post by: Quigibo on October 25, 2010, 09:36:14 pm
Runer, I can't replicate that effect, it just throws a BAD SYMBOL at the 'o' for me as I would expect.  What version are you using?
Title: Re: Axe Parser
Post by: Runer112 on October 25, 2010, 09:50:25 pm
Runer, I can't replicate that effect, it just throws a BAD SYMBOL at the 'o' for me as I would expect.  What version are you using?

0.4.5 :o
Hold on, let me try to get a screenshot.

EDIT: Made a screenshot illustrating the problem. The compiled size of 19 bytes indicates 16 bytes of header/VAT data and 3 bytes for "C".
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 25, 2010, 09:52:19 pm
In SourceCoder, I believe that if you type Copy, it recognize it as conj, so such thing may not happen in SourceCoder.

The test I just did with SourceCoder disagrees with this. That would prevent you from typing the literal string "Copy" and SourceCoder isn't designed to be an Axe source editor anyways.
Strange I thought Kerm implemented the new tokens already X.x. He said he might since he planned to make it for both Axe and BASIC.
Title: Re: Axe Parser
Post by: Quigibo on October 25, 2010, 10:39:02 pm
Oh you're right, it is in 0.4.5 I was using an older version.  It has to do with the disabled axioms which are supposed to be checked once the parser doesn't recognize a token but I commented that all out and put a jump to the error handler instead.  Unfortunately I accidentally made it a conditional jump instead of a normal jump and so it will sometimes not go to the error like it should and just continues on as if it were a comment.
Title: Re: Axe Parser
Post by: Runer112 on October 25, 2010, 10:51:55 pm
You, getting caught using an older version of Axe? :o Lol

Anyways you should check out my approximately over 9000 feature requests. ;)
Title: Re: Axe Parser
Post by: BlackRabbit on October 26, 2010, 06:28:52 pm
Yes. I'm working on a few. One is a huge RPG called Champion. I'm using Axe for that. I'm also working on a new os for the 83+. It's being delayed until after Champion.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 27, 2010, 03:21:28 am
Ah cool! Did you do any other calculator games and programs before? A huge RPG and an OS are both huge undertakings (I'm speaking from experience about RPGs because I made several of them back in 2001-2005), especially the later. If you are still new to programming I would probably suggest making a demo of your RPG, first, then gradually improve from it, or maybe even do a smaller prequel/side game of your RPG, to not start too big either. Otherwise, good luck! :)
Title: Re: Axe Parser
Post by: FinaleTI on October 27, 2010, 04:26:36 pm
What is the max number of labels you can have in a program? Because Runer112 was trying to help me optimize Nostalgia's menu routine and he said he got a ERR:MAX SYMBOLS. Is there anyway around this?
Title: Re: Axe Parser
Post by: nemo on October 27, 2010, 04:30:03 pm
What is the max number of labels you can have in a program? Because Runer112 was trying to help me optimize Nostalgia's menu routine and he said he got a ERR:MAX SYMBOLS. Is there anyway around this?

i think it's something like 100-150. you can always use offsets. for example instead of
Code: [Select]
[HEX]->Pic1 .player1
[HEX]->Pic2 .player2
[HEX]->Pic3 .player3
you can do
Code: [Select]
[HEX]->Pic1 .player1
[HEX]          .Pic1+8  refers to player2
[HEX]          .Pic1+16 refers to player3
etc.
Title: Re: Axe Parser
Post by: squidgetx on October 27, 2010, 04:30:28 pm
What is the max number of labels you can have in a program? Because Runer112 was trying to help me optimize Nostalgia's menu routine and he said he got a ERR:MAX SYMBOLS. Is there anyway around this?

Seconded. I wanna know too ;D

One solution there is around this currently is to use the following type of code change:
Code: [Select]
[hex]→Pic1
[hex]→Pic2
Pt-On(X,Y, Pic1)
Pt-On(X,Y, Pic2)
to
Code: [Select]
[hex]→Pic1
[hex]
Pt-On(X,Y, Pic1)
Pt-On(X,Y, Pic1+8)

Works with strings and regular data as well


edit: wow ninja'd
Title: Re: Axe Parser
Post by: FinaleTI on October 27, 2010, 04:34:40 pm
Well, I meant labels like Goto LBL or sub(LBL). But the tip on static variables is helpful.
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on October 27, 2010, 04:35:46 pm
I wonder if you can use a label as a pointer, like by doing lbl123+64
Title: Re: Axe Parser
Post by: Quigibo on October 27, 2010, 04:50:25 pm
I wonder if you can use a label as a pointer, like by doing lbl123+64
You would never reliably be able to do this because future optimizations would mean that the spacing between some labels would change between every version of the parser.  This would only work if the entire routine were written with an Asm() command so you would know the length of the subroutine ahead of time.

Unfortunately there is no way around the 150 symbol limit to labels, but there are some things you can do to use less labels in general.  First of all, if you aren't calling it as a subroutine, you probably don't need it as a label.  You can instead use a combination of if's and while's to handle those situations properly (remember, most modern programming languages don't even have a goto command).  Another thing, if you have labels that are never used, comment them out becasue they still take up space on the symbol table even if they are never called.
Title: Re: Axe Parser
Post by: BlackRabbit on October 27, 2010, 06:05:19 pm
I've recently completed Warrior 2, another big RPG, in Ti-Basic with xLib. The only problem is that I have an 83+ so I cannot send it to the computer and upload it. I've also done several other projects but not any that I am still prowd of.
Title: Re: Axe Parser
Post by: Runer112 on October 27, 2010, 07:37:02 pm
I wonder if you can use a label as a pointer, like by doing lbl123+64
You would never reliably be able to do this because future optimizations would mean that the spacing between some labels would change between every version of the parser.  This would only work if the entire routine were written with an Asm() command so you would know the length of the subroutine ahead of time.

Unfortunately there is no way around the 150 symbol limit to labels, but there are some things you can do to use less labels in general.  First of all, if you aren't calling it as a subroutine, you probably don't need it as a label.  You can instead use a combination of if's and while's to handle those situations properly (remember, most modern programming languages don't even have a goto command).  Another thing, if you have labels that are never used, comment them out becasue they still take up space on the symbol table even if they are never called.

Quigibo, how exactly does the parser make use of memory during parsing? Have you made use of the whopping 1094 bytes of effectively safe RAM starting at $8000?
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on October 27, 2010, 07:42:35 pm
I've recently completed Warrior 2, another big RPG, in Ti-Basic with xLib. The only problem is that I have an 83+ so I cannot send it to the computer and upload it. I've also done several other projects but not any that I am still prowd of.


this is a bit off topic to respond and I'm sorry, but you CAN transfer it if you buy a certaqin type of cable, or type it up in source coder.
Title: Re: Axe Parser
Post by: BlackRabbit on October 27, 2010, 10:12:30 pm
I've recently completed Warrior 2, another big RPG, in Ti-Basic with xLib. The only problem is that I have an 83+ so I cannot send it to the computer and upload it. I've also done several other projects but not any that I am still prowd of.


this is a bit off topic to respond and I'm sorry, but you CAN transfer it if you buy a certaqin type of cable, or type it up in source coder.

okay. I'll do that.
Quote
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 27, 2010, 11:13:38 pm
I've recently completed Warrior 2, another big RPG, in Ti-Basic with xLib. The only problem is that I have an 83+ so I cannot send it to the computer and upload it. I've also done several other projects but not any that I am still prowd of.


this is a bit off topic to respond and I'm sorry, but you CAN transfer it if you buy a certaqin type of cable, or type it up in source coder.

okay. I'll do that.

Alternatively, if someone else  owns a TI-84 Plus or a TI-Nspire with 84+ keypad and you got a link cable, and that person lets you borrow  his calc, just send your program to his calc, take a mini-USB to USB cable (a camera one will do) then use it to transfer it to the computer from the 84+ calculator. That's what I did with my 83 Plus since I did not have the appropriate cable for a while.
Title: Re: Axe Parser
Post by: FloppusMaximus on October 27, 2010, 11:58:13 pm
Have you made use of the whopping 1094 bytes of effectively safe RAM starting at $8000?
"Safe" I'd have to dispute... sure, all of RAM can be considered "safe" if you disable interrupts and never call any system routines.  And if you're going as far as keyExtend, you're already trashing the keypad-scanning variables, so why stop there?
Title: Re: Axe Parser
Post by: Runer112 on October 28, 2010, 05:53:52 am
Have you made use of the whopping 1094 bytes of effectively safe RAM starting at $8000?
"Safe" I'd have to dispute... sure, all of RAM can be considered "safe" if you disable interrupts and never call any system routines.  And if you're going as far as keyExtend, you're already trashing the keypad-scanning variables, so why stop there?

For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here (http://netham45.org/irc/EfNet/view.php?log=omnimaga.20100908)) when I was considering using this area as temporary storage:
Quote
[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 28, 2010, 07:10:22 am
Is that area used by any shell like Doors, Mirage or Ion?

On an semi-unrelated note, would Axe programs be compilable for CrunchyOS?
Title: Re: Axe Parser
Post by: Broseph Radson on October 28, 2010, 09:16:24 am
None of my axe progs show up in Crunchy
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 28, 2010, 06:16:10 pm
Ah ok. I haven't used Crunchy in 6 years so I totally forgot how we made programs for it. X.x
Title: Re: Axe Parser
Post by: Deep Toaster on October 28, 2010, 07:14:32 pm
On an semi-unrelated note, would Axe programs be compilable for CrunchyOS?

Doesn't Crunchy support all Ion and MOS programs, though?
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 28, 2010, 09:48:37 pm
Yeah I remember it did, but I don't remember if they needed to be re-compiled, compressed or something.
Title: Re: Axe Parser
Post by: FloppusMaximus on October 28, 2010, 11:19:58 pm
For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here (http://netham45.org/irc/EfNet/view.php?log=omnimaga.20100908)) when I was considering using this area as temporary storage:
Quote
[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"
If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?

(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding.  To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)

"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.

The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do.  By safe, we generally mean that
 (1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
 (2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.

In some cases we may also want to consider areas where the RAM is already in use, but
 (a) it can be easily reset to its default settings,
 (b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
 (c) the user won't mind us trashing his or her data.

In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances.  As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.

As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits.  Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called.  In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.
Title: Re: Axe Parser
Post by: squidgetx on October 29, 2010, 03:48:07 pm
random question: is it worth it to put this code in a subroutine?

<exp>*22+GDB0+<constant>..... so it looks like sub(0r,<exp>,<const>).....lbl 0 : r1*22+GDB0+r2

I would almost always need the r when calling this routine, and I suspect that the size of calling sub(lblr) with two arguments to be loaded might be bigger than just typing it out every time. Can anyone confirm? Also, I will be using this snippet of code only around 15 times throughout
Title: Re: Axe Parser
Post by: Munchor on October 29, 2010, 03:50:21 pm
Has anyone tried running Axe Parser in TI NSpire w/ 84+ keypad?

I can't, when I open the application Axe what shows up immediately is the Compile list and I can't compile them due to Unknown Error (and they are written in Axe, for sure).

Any ideas?
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 29, 2010, 05:23:37 pm
I did and I can get it to work fine. There might be something wrong with your TI-Nspire. Have you tried reinstalling the OS?
Title: Re: Axe Parser
Post by: Runer112 on October 29, 2010, 07:28:20 pm
random question: is it worth it to put this code in a subroutine?

<exp>*22+GDB0+<constant>..... so it looks like sub(0r,<exp>,<const>).....lbl 0 : r1*22+GDB0+r2

I would almost always need the r when calling this routine, and I suspect that the size of calling sub(lblr) with two arguments to be loaded might be bigger than just typing it out every time. Can anyone confirm? Also, I will be using this snippet of code only around 15 times throughout

If you use a line with that format only once or twice, it would be optimal to just to type it all out in those instances. If you use it more than twice, the most optimized way would be as follows:
Code: [Select]
<exp>sub(22)+GDB0+<constant>
Lbl 22
Return *22



EDIT: So as not to double post, I'll add this as an edit. It is, however, completely unrelated.
For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here (http://netham45.org/irc/EfNet/view.php?log=omnimaga.20100908)) when I was considering using this area as temporary storage:
Quote
[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"
If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?

(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding.  To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)

"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.

The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do.  By safe, we generally mean that
 (1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
 (2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.

In some cases we may also want to consider areas where the RAM is already in use, but
 (a) it can be easily reset to its default settings,
 (b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
 (c) the user won't mind us trashing his or her data.

In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances.  As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.

As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits.  Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called.  In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.

You were right, I did accidentally look over the fact that baseAppBrTab is present in this area of RAM. That's why I later searched for Iambian's reference to bcall($5011). I know it does not "Restores first 1087 bytes in RAM," and I'm sure Iambian does too. But it restores the data in baseAppBrTab. As long as this bcall was called after use of this RAM area and hooks/interrupts didn't try to use it while you were (which I believe should be relatively easy to ensure), it should be okay to use it.

I also did know that a lot of the other data areas in there were used by system routines, but for the purpose of parsing, during which I would assume very few bcalls are used (key input bcalls are included in those not used), it would be okay to fill these areas with your own data.

However, I did completely forget one very important thing: Axe is an application. So it probably shouldn't be using baseAppBrTab at all. Or ramCode for that matter, located at $8100. So you're right, now that I think about this again, this area of RAM isn't entirely safe to use. Although appData (256 bytes starting at $8000) and tempSwapArea (323 bytes starting at $82A5) are large blocks that should be safe to use.
Title: Re: Axe Parser
Post by: squidgetx on October 29, 2010, 07:50:24 pm
Code: [Select]
Lbl 22
Return *22

Wow...didn't know you could do that. Thanks!

And also; what if I didn't need the r? Would it make a difference?
Title: Re: Axe Parser
Post by: Deep Toaster on October 29, 2010, 07:58:30 pm
Code: [Select]
Lbl 22
Return *22

Wow...didn't know you could do that. Thanks!

Yeah, you can start a line with a command like * or →. In Axe, it just operates it on the last value returned, kinda like Ans.
Title: Re: Axe Parser
Post by: Runer112 on October 29, 2010, 08:41:01 pm
Code: [Select]
Lbl 22
Return *22

Wow...didn't know you could do that. Thanks!

And also; what if I didn't need the r? Would it make a difference?

Yeah, in Axe commands don't need to be directly linked. Evaluating <exp> would put it's value into what you could call the "Ans of Axe" (the hl register), and you can act upon that value whenever you want. It doesn't have to be in a command on the same line, or in this case, even in the same general area of the program.

You can do some pretty crazy stuff using this. The most basic example would be something like this:
Code: [Select]
0→A→BYou're not actually saying 0→B, but because storing variables doesn't overwrite the "Ans of Axe," the value will remain and can be put in B. If you want to see a more advanced use of this, take this code for example, which I'm using in what I'm working on now:
Code: [Select]
Vsub(DM3)
...
Lbl DM3
  abs()-{r₁}
Return
The absolute value command doesn't even have an argument! But it doesn't care, it will operate on whatever is in "Ans." Entering an expression or value inside the parentheses would be a more logical way to put a value in "Ans" for the command to operate on, but if you don't enter anything there, "Ans" will simply stay as it was before the command was reached (in this case, with the value of V) and the absolute value of that will be calculated.


Also, adding the r to subroutine calls bloats the call a fairly large amount. Calling a subroutine always costs a base of 3, but without the r modifier, each argument takes 6 bytes, whereas calling a subroutine with the r modifier costs 15 bytes for each argument.
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 29, 2010, 08:44:25 pm
Unfortunately I do not understand the stuff explained in the long post on the other page very well, regarding that large RAM area, but basically, if someone was to use it, what would he need to do before exiting his Axe program to ensure that no problem occurs after exiting? Or is that RAM area updated by the TI-OS even during ASM code execution?
Title: Re: Axe Parser
Post by: squidgetx on October 30, 2010, 10:54:08 am
On a related but not related note, how large are the Rect(), RectI(), Rect()r, and RectI()r routines?
Title: Re: Axe Parser
Post by: nemo on October 30, 2010, 11:53:16 am
On a related but not related note, how large are the Rect(), RectI(), Rect()r, and RectI()r routines?

about as large as the sprite routines
Title: Re: Axe Parser
Post by: squidgetx on October 30, 2010, 11:58:40 am
...How big are the sprite routines?
Title: Re: Axe Parser
Post by: Runer112 on October 30, 2010, 12:31:24 pm
On a related but not related note, how large are the Rect(), RectI(), Rect()r, and RectI()r routines?

Rect():   114 bytes
RectI():   114 bytes

Rect()r and RectI()r are just modified calls to the Rect() and RectI() routines, respectively.

...How big are the sprite routines?

Pt-On:   126 bytes
Pt-Off:   134 bytes
Pt-Change:   126 bytes

Like with the rectangle routines, back buffer calls are just modified calls to these routines.
Title: Re: Axe Parser
Post by: squidgetx on October 30, 2010, 12:33:36 pm
Ok; good. I'm going through all my code checking that my subroutines are actually worth having as subroutines using the 15byte-per-argument r. My window drawing routine saves about 393 bytes per call :)

I'm going to assume it's not worth it to make a routine that just does PtOn(r1,r2,r3) though...right?
Title: Re: Axe Parser
Post by: Happybobjr on October 30, 2010, 12:34:12 pm
On a related but not related note, how large are the Rect(), RectI(), Rect()r, and RectI()r routines?

Rect():   114 bytes
RectI():   114 bytes

Rect()r and RectI()r are just modified calls to the Rect() and RectI() routines, respectively.

...How big are the sprite routines?

Pt-On:   126 bytes
Pt-Off:   134 bytes
Pt-Change:   126 bytes

Like with the rectangle routines, back buffer calls are just modified calls to these routines.

thanks that really changes how i code
Title: Re: Axe Parser
Post by: Quigibo on October 30, 2010, 03:24:35 pm
Those are the sizes of the subroutines, not the calling routines.  The first time you use Pt-On for instance, it creates the subroutine in the data section.  Then, it calls to that routine.  Each call after that no longer has to recreate that routine anymore and just links to the one that already exists.  The only time you would want to put an Axe call in a subroutine is if you're always using a specific combination of arguments over and over again in the code.

If you want to know the calling overhead, compile "Pt-On(1,2,3):Pt-On(4,5,6)" and subtract that size with "Pt-On(1,2,3)" and that's your calling overhead.
Title: Re: Axe Parser
Post by: Darl181 on November 04, 2010, 01:39:23 am
I've been wondering about the Circle( command, ever since I tried to implement certain enemy movements in TWHG.
Can the radius be negative?
If not, will abs( work?
If neither, what detrimental effects might a negative-value radius cause?
Title: Re: Axe Parser
Post by: Builderboy on November 04, 2010, 01:47:02 am
a circle with a negative radius makes weird graphical errors happen, and Abs() should fix it although why is your radius going negative in the first place?
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 04, 2010, 03:35:32 am
Oh wait do you mean the weird fractal thing that occurs when it is negative? Quigibo posted a screenshot of it somewhere...

EDIT: On an off-topic note, awesome avatar Darl181. :D
Title: Re: Axe Parser
Post by: Deep Toaster on November 04, 2010, 12:02:25 pm
Oh wait do you mean the weird fractal thing that occurs when it is negative? Quigibo posted a screenshot of it somewhere...

EDIT: On an off-topic note, awesome avatar Darl181. :D

I can't seem to find it. But it looked pretty awesome. I remember a discussion of whether or not to add an absolute value into the command itself...
Title: Re: Axe Parser
Post by: AngelFish on November 04, 2010, 01:23:38 pm
That's actually really cool.

I made a quick program demonstrating it. The effect could be useful for games and such.

(http://img.removedfromgame.com/imgs/1288891403-Circle bug.gif)
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on November 04, 2010, 01:25:06 pm
*cough* sniper 101's super weapon *hack* happybobjr *wheeze*

...what? ;)
Title: Re: Axe Parser
Post by: AngelFish on November 04, 2010, 01:26:43 pm
Or as a Missile target in Battlefield ;)
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on November 04, 2010, 01:28:58 pm
that' not ASCII/homescreen based :P
Title: Re: Axe Parser
Post by: AngelFish on November 04, 2010, 01:36:51 pm
that' not ASCII/homescreen based :P

You're forgetting that the full power of WFRNG was coded using only BASIC and the homescreen. BASIC can do anything, even beat the speed of Assembly!
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on November 04, 2010, 01:37:47 pm
that' not ASCII/homescreen based :P

You're forgetting that the full power of WFRNG was coded using only BASIC and the homescreen. BASIC can do anything, even beat the speed of Assembly!

you're right, it can almost process as fast as light :D in some versions at least
Title: Re: Axe Parser
Post by: Deep Toaster on November 04, 2010, 04:44:32 pm
Wow, it does look pretty 3D... But it'll seem strange when several projects are released simultaneously with the exact same style of crosshairs :D
Title: Re: Axe Parser
Post by: Happybobjr on November 04, 2010, 05:11:52 pm
*cough* sniper 101's super weapon *hack* happybobjr *wheeze*

...what? ;)

cough cough... really, i am very sick.  I bet i can make a missile that will eliminate all pedestrians.

It could cost 500 shop points,  and take away 1000-2000 (or maybe 25 per pedestrian) score points.  My current problem w/ sniper 101 is the lack of remaining variables.  And i hate using  L1  because that is where i use my pedestrian info.  I suppose i could put it at the end of it though, as no one would go past lvl 200 in ffa mode (example: Phoenix )

this is after i am finished on two player shooter though.

I got my 7 foot cable,  but i haven't got a chance to borrow a friends ti-84 because the cable came with a cold.  Once again ti-strikes.
Title: Re: Axe Parser
Post by: nemo on November 04, 2010, 05:28:35 pm
there are a lot of places to store more variables though... L4, L5, L3 if you aren't doing grayscale L2 if you don't mind its interrupt-changing qualities.
Title: Re: Axe Parser
Post by: AngelFish on November 04, 2010, 05:29:44 pm
Plus the various holes in RAM that the OS has, if you feel like going into Assembly.
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on November 04, 2010, 06:12:48 pm
*cough* sniper 101's super weapon *hack* happybobjr *wheeze*

...what? ;)


cough cough... really, i am very sick.  I bet i can make a missile that will eliminate all pedestrians.

It could cost 500 shop points,  and take away 1000-2000 (or maybe 25 per pedestrian) score points.  My current problem w/ sniper 101 is the lack of remaining variables.  And i hate using  L1  because that is where i use my pedestrian info.  I suppose i could put it at the end of it though, as no one would go past lvl 200 in ffa mode (example: Phoenix )

this is after i am finished on two player shooter though.

I got my 7 foot cable,  but i haven't got a chance to borrow a friends ti-84 because the cable came with a cold.  Once again ti-strikes.

Hope you feel better soon, happybobjr!

I once got sick after a friend borrowed my calc for a few minutes :(
Title: Re: Axe Parser
Post by: Runer112 on November 04, 2010, 06:36:41 pm
Plus the various holes in RAM that the OS has, if you feel like going into Assembly.

You don't need to use assembly, as Axe is already capable of accessing any addressable RAM area. A good suggestion would be E8000, which has 256 bytes of space you can uses as temporary RAM.
Title: Re: Axe Parser
Post by: ASHBAD_ALVIN on November 04, 2010, 06:38:51 pm
I wasn't aware of that area... what is it called in the .inc file?
Title: Re: Axe Parser
Post by: Runer112 on November 04, 2010, 06:48:53 pm
I wasn't aware of that area... what is it called in the .inc file?


appData I believe.
Title: Re: Axe Parser
Post by: Deep Toaster on November 04, 2010, 07:45:21 pm
Yep, and if you're really out of places to store to, you can create a new local var (like GDB00) and use it as storage.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 04, 2010, 10:44:22 pm
Is it 100% safe to store stuff in E8000, though?
Title: Re: Axe Parser
Post by: calc84maniac on November 04, 2010, 11:01:04 pm
I wouldn't assume so. If I remember correctly, that area is destroyed by Garbage Collecting, so it might be touched by other OS routines too.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 04, 2010, 11:16:49 pm
Ok, no important stuff needed while using BASIC or other TI-OS commands is stored there that could crash the calc if deleted?
Title: Re: Axe Parser
Post by: AngelFish on November 04, 2010, 11:24:48 pm
Plus the various holes in RAM that the OS has, if you feel like going into Assembly.

You don't need to use assembly, as Axe is already capable of accessing any addressable RAM area. A good suggestion would be E8000, which has 256 bytes of space you can uses as temporary RAM.

I probably should have remembered that, given how much one of my projects directly addresses RAM :P
Title: Re: Axe Parser
Post by: squidgetx on November 07, 2010, 06:06:45 pm
random question: how many bytes is a name string? is the appv token 1 byte? are lower case letters 2 bytes still?

so for example: how large is this name string: "appvAbcDE"

and also: can you open a file 'over' another file

ie if you had appvar 1 open in Y1, can you call GetCalc(Str2,Y1) and have the appvar pointed to in Str2 now open as Y1?
Title: Re: Axe Parser
Post by: FinaleTI on November 07, 2010, 08:58:13 pm
random question: how many bytes is a name string? is the appv token 1 byte? are lower case letters 2 bytes still?

so for example: how large is this name string: "appvAbcDE"

and also: can you open a file 'over' another file

ie if you had appvar 1 open in Y1, can you call GetCalc(Str2,Y1) and have the appvar pointed to in Str2 now open as Y1?
As for your last question, yes, it should work that way. I did that in one of my programs at some point, I just forget which one.
Title: Re: Axe Parser
Post by: Deep Toaster on November 07, 2010, 09:06:07 pm
random question: how many bytes is a name string? is the appv token 1 byte? are lower case letters 2 bytes still?

Name string is however many bytes you make it, just like any other string. The appv char is two bytes: one for the var type (appvar), one for the actual token. And all lowercase letters are one byte unless you convert them individually with T.

so for example: how large is this name string: "appvAbcDE"

So that would be 7 bytes, plus a zero byte to signify the end of a string if you did something like "appvAbcDE"->Str1 for a total of eight bytes.

and also: can you open a file 'over' another file

ie if you had appvar 1 open in Y1, can you call GetCalc(Str2,Y1) and have the appvar pointed to in Str2 now open as Y1?

Yep, FinaleTI answered that one.
Title: Re: Axe Parser
Post by: calc84maniac on November 07, 2010, 09:16:54 pm
random question: how many bytes is a name string? is the appv token 1 byte? are lower case letters 2 bytes still?

Name string is however many bytes you make it, just like any other string. The appv char is two bytes: one for the var type (appvar), one for the actual token. And all lowercase letters are one byte unless you convert them individually with T.
Actually, appvars and programs don't have a token before the name. So appv is actually one byte.
Title: Re: Axe Parser
Post by: Deep Toaster on November 07, 2010, 09:58:38 pm
random question: how many bytes is a name string? is the appv token 1 byte? are lower case letters 2 bytes still?

Name string is however many bytes you make it, just like any other string. The appv char is two bytes: one for the var type (appvar), one for the actual token. And all lowercase letters are one byte unless you convert them individually with T.
Actually, appvars and programs don't have a token before the name. So appv is actually one byte.

Whoops, sorry x.x
Title: Re: Axe Parser
Post by: squidgetx on November 13, 2010, 12:31:45 pm
K so I just found this post, and I was wondering if it is worth it to use the inData method for only 2 or 3 numbers (ie If inData(A,Data(1,2,0)) )
Code: [Select]
.Inefficient
If (A=3 or (A=5) or (A=20) or (A=28) or (A=61))
.Some code
End

.Efficient
If A
  If inData(A,Data(3,5,20,28,61,0))
  .Some code
  End
End
This is probably unnoticeable slower, but its much smaller and the routine is a subroutine so using it more than once in your program will definitely be a large size optimization.
Title: Re: Axe Parser
Post by: Runer112 on November 13, 2010, 05:12:58 pm
The inData() routine is actually a very efficient way to compare a variable with a list of constant byte values. the routine itself is 15 bytes, and each call is 11 bytes plus the size of the data (1 byte per value to check, and 1 byte for a null termination). Even if you're only checking to see if a variable equals either of 2 values, the size of the routine and the call (a total of 29 bytes with 2 values to check) is actually smaller than a compound or statement, like A=3 or (A=5) (31 bytes). If you had already used the inData() routine for something like this and the subroutine already exists in your code, comparing only 1 value with inData() (13 bytes) is actually the same size as a single equality check, like A=3. However, if you're only checking one equality, a better way than either of those is using !If A-3.

Bottom line:
Title: Re: Axe Parser
Post by: squidgetx on November 13, 2010, 05:23:02 pm
Quote
actually smaller than a single equality check
:o

Thanks Runer :)
Title: Re: Axe Parser
Post by: calc84maniac on November 13, 2010, 10:26:36 pm
And don't forget that you have to end your list of data with 0 so the routine knows when the end of the list is reached.
Title: Re: Axe Parser
Post by: Deep Toaster on November 13, 2010, 11:08:18 pm
Bottom line:
  • 1 equality check: !If VAR-CONST
  • 2+ equality checks: If inData(VAR,Data(CONST,CONST,...))

Thanks! Didn't know that.
Title: Re: Axe Parser
Post by: Runer112 on November 14, 2010, 12:11:46 am
And don't forget that you have to end your list of data with 0 so the routine knows when the end of the list is reached.

Wow, completely forgot about that. Fixing that now.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 14, 2010, 12:39:34 am
Reading that 0 being the end of data thing, I assume if we ever need to use those routines in a game for an item menu, for example, that we must make sure that no item ID are equal to 0, right? For example, for an empty item slot it would be 1, potion 2, elixir 3, etc?
Title: Re: Axe Parser
Post by: Runer112 on November 14, 2010, 02:19:54 am
Reading that 0 being the end of data thing, I assume if we ever need to use those routines in a game for an item menu, for example, that we must make sure that no item ID are equal to 0, right? For example, for an empty item slot it would be 1, potion 2, elixir 3, etc?

Solution: inData(A+1,Data(1,2,3,0))
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 14, 2010, 02:35:15 am
I'm lost now. What does A do? ???
Title: Re: Axe Parser
Post by: Runer112 on November 14, 2010, 04:59:27 am
A is just whatever zero-based value you wanted to check. Adding 1 makes it 1-based so the comparison data can be null-terminated.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 14, 2010, 05:02:37 am
So Data(1,2,3,0) would be Data(2,3,4,1), eliminating the zeros in it? What about the actual ending 0, though?
Title: Re: Axe Parser
Post by: Quigibo on November 14, 2010, 05:04:37 am
Don't forget that inData() only works with 8bit numbers (1-255) it won't work with 16-bit numbers.  I could add an inData()r to take care of that but it would be slower.

EDIT: @DJ, he means that if your possibilities were 0,1,2,3 then instead of doing inData(A,Data(0,1,2,3,0)) which wouldn't work, you could do inData(A+1,Data(1,2,3,4,0)) which would work because now you are comparing values that are in the right range.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 14, 2010, 05:10:00 am
Sorry, I'M even more lost now. I'll give up for now. I haven't coded in Axe for 4 months so I think I have missed too many things to understand inData(). :(
Title: Re: Axe Parser
Post by: Runer112 on November 14, 2010, 03:31:17 pm
Here's the description from the commands list:

inData(BYTE,PTR)
Key: inString()
   
Searches for the byte in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

The first argument accepts a byte value. Because Axe variables and math functions return two-byte values, this means that the high byte will be discarded. This argument essentially accepts whatever you enter mod 256.

The second argument accepts a pointer to data. In this data should be a series of byte values which will be stepped through one by one and checked to see if they are equal to the first argument (mod 256). The end of the data is signified by a zero so the search doesn't continue infinitely. For this reason, zero has to be reserved for the terminator and cannot be a value you want to compare.



Breaking down a more specific example, like: If inData(A+1,Data(2,7,17,0))

In the first argument, A represents whatever 0-based number, say an item ID, that you want to check. However, because 0 is reserved for the terminator of the data, we add 1 to it to shift all the item IDs to essentially be 1-based.

The second argument isn't really data itself. The data is defined somewhere in the bottom of the program, and this argument is instead given the value of a pointer to that data. As noted earlier, this data that is pointed to should be a list of nonzero byte values to check if the first argument is equal with, and the data should be terminated with a 0. Because 1 was added to our first argument to account for the fact that 0 is reserved for the terminator, 1 would also be added to the values we want to compare against. In this case, I wanted to compare against the values 1, 6, and 16, which turn into 2, 7, and 17 when 1 is added to them.

Finally, when the routine is run, the data is stepped through byte by byte, checking to see if a byte from the data equals the first argument (mod 256). Let's say we wanted to check if a selected item was a consumable potion, and item IDs 1, 6, and 16 were the potions present in our game. If the selected item ID (A) was 16, this value would be increased by 1, giving 17 for the first argument. This would then be checked to see if it equals 2, 7, or 17, which are the item IDs of the potions all plus 1. It doesn't equal 2 or 7, but it does equal 16. The routine would return the position of the match value, in this case 3, because the third element matched. For our purposes, all we really needed to know is whether or not a match was present, but inData() returning the match position works for this. Any match position returned will be greater than or equal to 1, which will make our IF statement true. If the item ID were 5, it wouldn't match any of the three values in our list. Once the routine hit a zero byte, it would know the searching was done and return a 0 for no match, making our IF statement false.


I hope this helps clarify things a bit :)
Title: Re: Axe Parser
Post by: Deep Toaster on November 14, 2010, 05:08:46 pm
Double-clicked? ;)

Anyway, that's a pretty clear explanation, thanks!
Title: Re: Axe Parser
Post by: Runer112 on November 14, 2010, 05:43:37 pm
Double-clicked? ;)

Anyway, that's a pretty clear explanation, thanks!

Whoops... someone delete the first one lol. I must've done something weird when editing it and instead created a second post instead of just editing the first one.
Title: Re: Axe Parser
Post by: Darl181 on November 14, 2010, 08:05:30 pm
Quick question.  I know what "and" is, I know what "or" is, but what's "xor"?
Title: Re: Axe Parser
Post by: squidgetx on November 14, 2010, 08:06:26 pm
Either or.

As in, if A and B , then  A or B is also true. A xor B is not true
Title: Re: Axe Parser
Post by: Darl181 on November 14, 2010, 08:20:15 pm
Either or.

As in, if A and B , then  A or B is also true. A xor B is not true

So, the whole statement is true only if one (i.e. A) is true and the other (i.e. B) is not?  Or am I completely off?

Also, I was wondering about the !
Is
!If X=2 and C=3
the same as
If X=/=2 and C=/=3
or does the ! only apply to the first term?
Title: Re: Axe Parser
Post by: jnesselr on November 14, 2010, 08:22:33 pm
Either or.

As in, if A and B , then  A or B is also true. A xor B is not true

So, the whole statement is true only if one (i.e. A) is true and the other (i.e. B) is not?  Or am I completely off?

Also, I was wondering about the !
Is
!If X=2 and C=3
the same as
If X=/=2 and C=/=3
or does the ! only apply to the first term?
the !If should apply to the whole statement.

The logic table for xor is:
0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0
Title: Re: Axe Parser
Post by: Darl181 on November 14, 2010, 08:23:48 pm
Okay, I get it now. Thanks!
Title: Re: Axe Parser
Post by: jnesselr on November 14, 2010, 08:24:42 pm
Okay, I get it now. Thanks!
No problem.  Tis what we are here for. ;-)
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 15, 2010, 12:45:45 am
Here's the description from the commands list:

inData(BYTE,PTR)
Key: inString()
   
Searches for the byte in the zero-terminated data. If found, it returns the position it was found in (starting at 1). If not found, 0 is returned.

The first argument accepts a byte value. Because Axe variables and math functions return two-byte values, this means that the high byte will be discarded. This argument essentially accepts whatever you enter mod 256.

The second argument accepts a pointer to data. In this data should be a series of byte values which will be stepped through one by one and checked to see if they are equal to the first argument (mod 256). The end of the data is signified by a zero so the search doesn't continue infinitely. For this reason, zero has to be reserved for the terminator and cannot be a value you want to compare.



Breaking down a more specific example, like: If inData(A+1,Data(2,7,17,0))

In the first argument, A represents whatever 0-based number, say an item ID, that you want to check. However, because 0 is reserved for the terminator of the data, we add 1 to it to shift all the item IDs to essentially be 1-based.

The second argument isn't really data itself. The data is defined somewhere in the bottom of the program, and this argument is instead given the value of a pointer to that data. As noted earlier, this data that is pointed to should be a list of nonzero byte values to check if the first argument is equal with, and the data should be terminated with a 0. Because 1 was added to our first argument to account for the fact that 0 is reserved for the terminator, 1 would also be added to the values we want to compare against. In this case, I wanted to compare against the values 1, 6, and 16, which turn into 2, 7, and 17 when 1 is added to them.

Finally, when the routine is run, the data is stepped through byte by byte, checking to see if a byte from the data equals the first argument (mod 256). Let's say we wanted to check if a selected item was a consumable potion, and item IDs 1, 6, and 16 were the potions present in our game. If the selected item ID (A) was 16, this value would be increased by 1, giving 17 for the first argument. This would then be checked to see if it equals 2, 7, or 17, which are the item IDs of the potions all plus 1. It doesn't equal 2 or 7, but it does equal 16. The routine would return the position of the match value, in this case 3, because the third element matched. For our purposes, all we really needed to know is whether or not a match was present, but inData() returning the match position works for this. Any match position returned will be greater than or equal to 1, which will make our IF statement true. If the item ID were 5, it wouldn't match any of the three values in our list. Once the routine hit a zero byte, it would know the searching was done and return a 0 for no match, making our IF statement false.


I hope this helps clarify things a bit :)
Ah ok, I was mostly confused at the InData(A+1,Data(1,2,3,4,0)) part. So we need to manually offset the Data stuff by 1 except the last 0?
Title: Re: Axe Parser
Post by: Runer112 on November 15, 2010, 01:01:07 am
If you're checking a 0-based value, you need to add 1 to everything (except the null terminator). You could alternatively just use a 1-based value instead and not have to worry about this.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 15, 2010, 03:02:58 am
Yeah, I think if I ever do a RPG, I'll just use 1-based value for empty item slots and stuff. It will solve most problems. I'll just need to fill those slots with 1 instead of 0 when starting a new game.

I think in Illusiat 13, empty item slot is 20 :P. For some reasons, the engine won't support 0.
Title: Re: Axe Parser
Post by: ztrumpet on November 15, 2010, 03:45:13 pm
I think in Illusiat 13, empty item slot is 20 :P. For some reasons, the engine won't support 0.
I believe it was because you did a SortA() on the item list and wanted the blank items to be in the middle. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 15, 2010, 10:17:20 pm
Oh right, I remember now! I wanted empty item slots after useable items and key items at the very bottom of the list.
Title: Re: Axe Parser
Post by: Runer112 on November 15, 2010, 11:21:53 pm
This isn't a bug and doesn't need to be urgently fixed or anything, so I'm posting it here instead of in the Bug Reports thread. But this always bugs the OCD side of me when I see it. The p_Rand function in the Commands.inc is classified under the Input section with p_GetKey and p_DKey. Perhaps move it to Advanced Math or something similar? :P
Title: Re: Axe Parser
Post by: Michael_Lee on November 17, 2010, 03:12:11 pm
Is there a way to switch the buffer and the back-buffer?  It looks like Axe comes with the ability to copy one to the other, not exchange.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 17, 2010, 03:13:27 pm
Does Exch(L3,L6,768) works? L3 is the back-buffer and L6 the main buffer.
Title: Re: Axe Parser
Post by: Michael_Lee on November 17, 2010, 03:15:04 pm
Sweet.  I didn't know that.  It should work, thanks.

Quick question - do I have to add brackets to anything, or will it work just as written?
Title: Re: Axe Parser
Post by: nemo on November 17, 2010, 03:31:22 pm
Sweet.  I didn't know that.  It should work, thanks.

Quick question - do I have to add brackets to anything, or will it work just as written?

for Exch(L3,L6,768)? that'll work as written. don't add brackets around L3 or L6.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 17, 2010, 03:44:49 pm
I wonder if stuff like {L1+5->{L1+6 will work like {L1+5}->{L1+6 and {L1+5}->{L1+6}? I remember some topics about this before, but I totally forgot.
Title: Re: Axe Parser
Post by: nemo on November 17, 2010, 03:48:18 pm
i think {L1+5->{L1+6 would evaluate to {L1+5->{L1+6}} which ultimately put the address of L1+5 into the byte at L1+6, however, because L1+5 is not a value between 0-255, L1+5^256 would be stored in L1+6.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 17, 2010, 03:50:12 pm
Ah ok, thanks for the info. :)

I wonder if this is documented? That might be something to add in tutorials or Axe doc in the future otherwise.
Title: Re: Axe Parser
Post by: Runer112 on November 17, 2010, 05:57:57 pm
If I were Quigibo and I were to add something to the documentation about this, I would add a note stressing that, although leaving off ending parentheses/brackets often works, the practice is best avoided. There are multiple reasons for this:
Title: Re: Axe Parser
Post by: calc84maniac on November 17, 2010, 06:12:53 pm
The main thing to remember is the unlike TI-Basic, the STO symbol does not automatically close all previous parentheses. Instead, the value inside the parentheses is what gets stored.
Title: Re: Axe Parser
Post by: Deep Toaster on November 17, 2010, 06:37:15 pm
Unrelated, but I couldn't find the appropriate topic: Congrats to Quigibo for his Puyo Puyo feature (http://www.ticalc.org/archives/news/articles/14/146/146880.html)!
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 18, 2010, 08:43:28 pm
Yeah true, I think it might be best to have programmers learn to not close parhentesises and brackets when possible. Their code is more readable this way. Only leave them open if you're extremly tight on RAM (if you have a lot of comments, for example).

And yeah congrats for Puyo Puyo feature :D
Title: Re: Axe Parser
Post by: squidgetx on November 19, 2010, 07:25:59 am
If you want a really extreme optimization for or-ing the screen, here it is.  It will be noticeably faster and smaller:

Code: [Select]
.# represents the 16-bit or operation
L₆→A
While -768-L₆
{A}ʳ#{A+L₃-L₆}ʳ→{A}ʳ+1→A
End

This is old, but, what does or-ing two buffers do do each other?
Title: Re: Axe Parser
Post by: calc84maniac on November 19, 2010, 08:13:49 am
It's like TI-Basic Recallpic, where all the black pixels from the second buffer are combined with those in the first buffer.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 19, 2010, 09:39:44 am
That can be useful sometimes, for example if you want to do a transition or animation where the entire grayscale turns black.
Title: Re: Axe Parser
Post by: Michael_Lee on November 25, 2010, 11:11:32 am
Question relating to memory storage and displaying screen:
I want to store, display, and manipulate a 64x64 portion of the screen.
Specifically, I want to take data I have stored in L1, copy it over to the buffer or backbuffer, then use Dispgraph to update the screen, or take data from the buffer and copy to L1.
This part I'm fairly certain I can do, using the code below (which I haven't actually tested yet)
Code: [Select]
For(Z,0,15)
    Copy({Z*24+L6},{Z*16+L1},16)
End
but if anybody sees a problem (or has a better way of doing this), I'd be grateful.

Also, the data in L1, I want to be able to manipulate bit by bit.  So if I were to have this snippet of data:
F32C
I want to be able to treat it like this:
1111
0011
0010
1010
(Just to make sure I have my terminology down, this would be equal to 2 nibbles or 1 byte or 16 bits Edit: 4 nibbles, 2 bytes, 16 bits.)
In this format, I'd like to do things like check around a specific entry to see the total value of the bits 'surrounding' it (if it were treated like a matrix).
However, I don't know how I would do this.

In summary:
1) Request for possible better alternative to my routine
2) Request to take data stored in L1, and manipulated it on the bit level.

Sorry if this isn't making much sense.
Title: Re: Axe Parser
Post by: FinaleTI on November 25, 2010, 11:17:51 am
F32C
I want to be able to treat it like this:
1111
0011
0010
1010
(Just to make sure I have my terminology down, this would be equal to 2 nibbles or 1 byte or 16 bits, yes?)
Well that would actually be 2 bytes (so 4 nibbles and 16 bits). 1 bytes would be 8 bits. Otherwise, you were right.

And I believe there is a bit-reading command in Axe, but I haven't used it so I can't be of much help there.
Title: Re: Axe Parser
Post by: Michael_Lee on November 25, 2010, 11:25:02 am
Ah, thanks, FinaleTI.  I knew I made a mistake somewhere...

Hmm, bit-reading command?
I'm not seeing it... (unless it's all those esoteric commands in the 'Advanced Math' section of the commands list...)
Title: Re: Axe Parser
Post by: squidgetx on November 25, 2010, 11:27:31 am
The bit reading command's syntax is as follows:

EXP1eEXP2 where EXP1 is the pointer (or it could be inline data) and EXP2 is the bit number (0-7) of the pointed to byte. So if you wanted to read the 1st bit of the byte in L1 you would use L1e1

As for writing to bits, this thread (http://ourl.ca/7815) might help

Oh and you don't need the curly brackets in the arguments of your Copy command
Title: Re: Axe Parser
Post by: calcdude84se on November 25, 2010, 11:30:34 am
You work with bytes, not nibbles (A nibble is four bits. There are two nibbles to a byte.)
Also, Copy( works like "Copy(SOURCE,DESTINATION,SIZE)"
So your first code segment is actually this:
Code: [Select]
For(Z,0,63)
  Copy(Z*8+L1,Z*12+L6,8)
End
You have 64 rows, numbered 0-63. 64 bits are 8 bytes, so we multiply Z by 8 then add it to L1. A row on the screen is 96 bits (and therefore 96/8=12 bytes), so we multiply Z by 12 and add L6. The 8 is for the same reason as two sentences ago.

You cannot work directly with bits for the most part. [F32C] is like this, actually:
Code: [Select]
11110011
00101100
To manipulate bits, you need to use e (Euler's e) and e^(
e works like this:
Code: [Select]
b00100000e2which returns 1 because the 2nd bit, from left to right, indexed from 0, is a 1.
e^( works like this:
Code: [Select]
e^(5)which returns b00100000 because the 1 is in the 5th position, from right to left, indexed from 0.

Edit: ninja'd...
Title: Re: Axe Parser
Post by: Darl181 on November 26, 2010, 03:18:09 pm
I'm in the process of writing menus for the Maxwell's Demon port, and I tried to make a sort of optimized, universal menu.  For some reason, it doesn't work.
Thing is, the loop is in a subroutine.
I was wondering if there is a size limit to a subroutine, or are there any commands that won't work in a subroutine.
I'll type out the code, just wanted to get the question out.
Title: Re: Axe Parser
Post by: nemo on November 26, 2010, 03:31:02 pm
i'm pretty sure you could put your whole game into a subroutine and it'd still run correctly. since when a subroutine is called all it does is just change a pointer (well, actually a register)to point at the beginning of the subroutine and start executing the code there until it reaches a Return statement.
Title: Re: Axe Parser
Post by: Darl181 on November 26, 2010, 03:48:55 pm
A and B are used to select the options, C is the # of options.
Code: [Select]
PRGM:AMENUSRC
.AMENU
Lbl MM
ClrHome
Fix 3
Disp " A GENERIC MENU "
.has to be 16 chars
Fix 2
Disp " Play Game",i," Options",i," Quit"
3→C
Sub(SEL)

If A=1
Disp "GAME"

.Game content here

.End of game, go to main menu
Goto MM
End

.Can nest as so
If A=2
Lbl OPT
Fix 3
Disp "Options         "
Fix 2
Disp " Something",i," Something else",i," Get the point"
3→C
Sub(SEL)
.Responses, may contain more sub-menus
Goto MM
End

If A=3
.last option, has to be quit for it to work correctly
Return
End


Lbl SEL
1→A→B
Output(0,A,5►Char
Repeat getKey(54)
ReturnIfgetKey(15)
A+getKey(1)-getKey(4)→B
!If A=B
!IF B:C→B:End
If B=C+1:1→B:End
Output(0,A," "
.that's 1 space
Output(0,B,5►Char
B→A
Pause 475
End
End
ClrHome
.Return
It displays, I just can't get the ► to move up and down.
Title: Re: Axe Parser
Post by: squidgetx on November 26, 2010, 05:08:06 pm
Quote
Code: [Select]
If B=C+1:1→B:End

should be

Code: [Select]
If C+1=B:1→B:End
:P

Don't forget about (the lack of) order of operations :) You're old code added one to whatever the value of B=C was, so that If condition would ALWAYS be true; hence, why you couldn't move the cursor around (because B was getting reset to 1 every iteration)
Title: Re: Axe Parser
Post by: Darl181 on November 26, 2010, 05:45:14 pm
Quote
Code: [Select]
If B=C+1:1→B:End

should be

Code: [Select]
If C+1=B:1→B:End
:P

Don't forget about (the lack of) order of operations :) You're old code added one to whatever the value of B=C was, so that For loop would ALWAYS be true; hence, why you couldn't move the cursor around (because B was getting reset to 1 every iteration)
That might be it...I'll try it.

EDIT.../me doesn't like RAM clears
Normally, it wouldn't be a problem, but the archive screwed up as well :(

Okay, back to normal, just lost the menu thing...which I pretty much have memorized anyway :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 26, 2010, 08:01:21 pm
Sorry to hear, glad you did not lose too much, though.
Title: Re: Axe Parser
Post by: Darl181 on November 27, 2010, 01:24:12 am
Yeah, I have no idea of just how many times omnicalc has saved my rear end...about 1 time out of 30 it doesn't work properly though :(
(And yes, I've used it that much)
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 27, 2010, 02:07:13 pm
Yeah it can be pretty useful if you doN,t have a 84+ with the extra RAM pages. Same for Axe backups and CalcUtil. In some rare occasions they might fail, though, so always have a second backup on the computer or something from time to time.
Title: Re: Axe Parser
Post by: Happybobjr on November 27, 2010, 02:14:04 pm
Yeah, I have no idea of just how many times omnicalc has saved my rear end...about 1 time out of 30 it doesn't work properly though :(
(And yes, I've used it that much)

how has omnicalc saved you?

I could never use it because i have the 2.53MP os.
Title: Re: Axe Parser
Post by: calcdude84se on November 27, 2010, 02:26:54 pm
I think the RAM Restore feature. (He programs in Axe, which can cause RAM clears)
Too bad about 2.53 MP not allowing that. I don't use it because I only have 48KB of RAM. x.x
Title: Re: Axe Parser
Post by: Darl181 on November 27, 2010, 06:14:09 pm
Yes, I use Omnicalc's RAM restore, entries menu, fast apps (10 apps doesn't seem like much to use it, but it makes a notable difference and allows me to hide the finance app :P), and thousands seperators extensively.
I also use Calcutil, so I could use the vars+vars menu and just run stuff archived and from the homescreen, allowing me to have the source in the entries menu as well as the program, get to editing faster.

It's a system that's helped me a lot over the years months.

Hmm...now that I think about it, I know less what to do with a fresh, just-after-mem-clear OS than an OS with omnicalc/calcutil...

btw squidgetx, C+1=B worked ;D
Title: Re: Axe Parser
Post by: squidgetx on November 27, 2010, 06:20:13 pm
^nice.

Since my full mem clear two days ago, the only apps I have on my calc are Axe and a bunch of Ash:Phoenix builds :P
Title: Re: Axe Parser
Post by: Darl181 on November 27, 2010, 06:21:39 pm
Full mem clear?!  Ouch x.x
Looks by that Ash: Phoenix is going well, though :P
Title: Re: Axe Parser
Post by: Deep Toaster on November 27, 2010, 11:28:30 pm
^nice.

Since my full mem clear two days ago, the only apps I have on my calc are Axe and a bunch of Ash:Phoenix builds :P

Ouch, hope those builds were recent...
Title: Re: Axe Parser
Post by: shmibs on November 27, 2010, 11:39:48 pm
oddly enough, the last time i had an accidental RAM clear of any kind was during the summer. that's when my programming activity dropped, though, so i guess it makes sense...
Title: Re: Axe Parser
Post by: Broseph Radson on November 28, 2010, 05:56:47 pm
[On] key combos!!

(http://www.dangerousminds.net/images/uploads/1269385664419_thumb.jpeg)
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 05:57:11 pm
Updates to the Application!
Title: Re: Axe Parser
Post by: shmibs on November 28, 2010, 06:03:37 pm
Quote from: quigibo
Pressing alpha-character jumps to program in compile menu

Manual backup key is now "Alpha"
so does that mean that, in order to use the alpha jump feature, one has to hold alpha while pressing a letter key? or do you mean just pressing a letter key on its own...
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 28, 2010, 06:04:18 pm
I think the RAM Restore feature. (He programs in Axe, which can cause RAM clears)
Too bad about 2.53 MP not allowing that. I don't use it because I only have 48KB of RAM. x.x
DrDnar posted a patch of Omnicalc allowing 2.53 support on UTI a while ago, but I forgot where is it, plus you need to register to download it I think. I wonder if that could solve the issue?

EDIT: Found it! http://www.unitedti.org/forum/index.php?showtopic=9316

Also:
Axe Parser
Delta 0.4.6


No new commands, but a lot of new features.

New Features:
  • Direct key support for the [On] key using getKey(41)
  • Added new Axiom Tokens (but they aren't usable yet)
  • Static data can be stored to variable pointer
  • Pressing alpha-character jumps to program in compile menu
  • Selector wraps around in the compile menu

Changed:
  • Fixed bug that made some invalid syntax become comments
  • Fixed Elseif bug
  • Added new auto-optimizations
  • Automatic backups only after finishing compile with no errors
  • Compiling to apps always attempts a defragmentation
  • App signature improved and resignable on-calc with external program
  • Fixed program menu bug after manual backups
  • Manual backup key is now "Alpha"
  • Fixed sector boundary reading bug when reading large source from archive.
AWESOME! Glad to see the new version out! :)

Hopefully this should fix most people recent problems. Any luck with the Input command by the way?
[On] key combos!!

(http://www.dangerousminds.net/images/uploads/1269385664419_thumb.jpeg)
wut?  ???
Title: Re: Axe Parser
Post by: calcdude84se on November 28, 2010, 06:05:50 pm
"Static data can be stored to variable pointer."
How exactly does this work?
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 06:06:16 pm
Is there an Input command, I heard DJ saying it was something like

Code: [Select]
Z->input
But maybe I misunderstood :S
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 28, 2010, 06:07:22 pm
I don't remember, but I know it was broken on some calc model and OSes. It's best to just build your own routine.
Title: Re: Axe Parser
Post by: Runer112 on November 28, 2010, 06:21:36 pm
"Static data can be stored to variable pointer."
How exactly does this work?

You can now do:
Code: [Select]
"0123456789ABCDEF"→AInstead of having to previously have done something like:
Code: [Select]
"0123456789ABCDEF"→Str1
Str1→A


Is there an Input command, I heard DJ saying it was something like

Code: [Select]
Z->input
But maybe I misunderstood :S

There is an input command, and it returns a pointer to a string of tokens, not a numerical value.
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 06:22:44 pm
You can now do:
Code: [Select]
"0123456789ABCDEF"->AInstead of having to previously have done something like:
Code: [Select]
"0123456789ABCDEF"->Str1
Str1->A

THIS IS AWESOME!

You can now have more than 10 pictures! Also works for strings, right?

But maybe I misunderstood :S

There is an input command, and it returns a pointer to a string of tokens, not a numerical value.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 28, 2010, 06:35:20 pm
Nice Runer112. Also ScoutDavid you might want to fix your Quote. :P

by the way will this new version be uploaded on ticalc.org?
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 06:39:37 pm
1. Quote Fixed;
2. It has not been put TiCalc?;
3. It has not been posted in Cemetech;
4. What are axioms?
Title: Re: Axe Parser
Post by: calcdude84se on November 28, 2010, 06:53:49 pm
Runer, thank you. IMO it would read better as "Inline strings now work for storing to variables" :D
Edit: On a completely unrelated note, I noticed that the manual still says "Not Reasonably" for editing ASM on-calc. Might want to change that ;D
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 07:22:08 pm
Runer, thank you. IMO it would read better as "Inline strings now work for storing to variables" :D
Edit: On a completely unrelated note, I noticed that the manual still says "Not Reasonably" for editing ASM on-calc. Might want to change that ;D


Edit: On a completely unrelated note, I noticed that the manual still says "Not Reasonably" for editing ASM on-calc. Might want to change that

That's not very important, however. Some times, when releasing new versions of a product I add lots of features, and fix major bugs, but forget to fix small bugs, which are sometimes important.
Title: Re: Axe Parser
Post by: calcdude84se on November 28, 2010, 07:26:29 pm
It's not important; it's just something I noticed ;D
Title: Re: Axe Parser
Post by: Munchor on November 28, 2010, 07:27:25 pm
It's not important; it's just something I noticed ;D

Yes, I understood you knew it wasn't important.

It's also cool that letters in program list jump, that's useful for me, who have LOTS of programs and backups :)
Title: Re: Axe Parser
Post by: squidgetx on November 29, 2010, 07:17:33 am
Augh, the dreaded max symbol error :(

Is using the (semi) new inline data feature a valid way to reduce the symbol count?
Code: [Select]
Text(0,,"Hi") instead of
Code: [Select]
"Hi"->Str1:Text(0,,Str1)
Title: Re: Axe Parser
Post by: Quigibo on November 29, 2010, 04:16:07 pm
Yes, that reduces symbol count.  You can also reference things relatively, like Str1+8 for instance instead of making a new static pointer, its the same size in the executable either way since it gets optimized.

By the way, anyone find any bugs yet?  I know for a fact that about 1% of the time when you absorb an OS picture variable from archive as a tilemap, the data can get slightly shifted.  This isn't a new bug, it was in the older versions but no one has reported it yet.  I can fix it but it'll be quite slow to parse when it absorbs tilemaps.  (the noncontiguous rom structure is so evil) I'm going to upload to ticalc soon so I just want to make sure there aren't any obvious bugs.  The things I changed most were things having to do with archive, app compiling, backups, and the compile menu if you're looking for bugs.
Title: Re: Axe Parser
Post by: DJ Omnimaga on November 29, 2010, 04:21:16 pm
I didn't notice the bug yet actually. Does it happens on all OSes/Calcs?

As for ticalc.org upload suggestion I asked since ticalc.org is still at version 0.4.4. Also I forgot to mention Cemetech X.x, that could be another place as well.

I should try to compile my Axe tunnel for 0.4.6 and post an update...
Title: Re: Axe Parser
Post by: ztrumpet on November 29, 2010, 04:45:01 pm
DelVar can be used to help avoid Max Symbol, if I understand right. :)
Title: Re: Axe Parser
Post by: Quigibo on November 29, 2010, 04:47:12 pm
DelVar can be used to help avoid Max Symbol, if I understand right. :)
No, that was gotten rid of several versions ago becasue no one used it.  Now, its used for its more intuitive purpose which is to delete OS variables.
Title: Re: Axe Parser
Post by: Builderboy on November 30, 2010, 11:25:32 pm
Hah yeah i remember thinking that i was never ever going to use Delvar to delete labels and symbols ;D I like its new use better ^^
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 01, 2010, 04:15:26 am
I also like how it can delete archived stuff, too.
Title: Re: Axe Parser
Post by: Deep Toaster on December 01, 2010, 06:32:26 pm
Hah yeah i remember thinking that i was never ever going to use Delvar to delete labels and symbols ;D I like its new use better ^^

Same here. Deleting pointers got a bit confusing after a while, too (two different pieces of data with the same name).
Title: Re: Axe Parser
Post by: JustCause on December 01, 2010, 06:35:48 pm
Axe Parser
Delta 0.4.6

Static data can be stored to variable pointer
Thanks for bringing this to my attention: this helps a lot for MFQT

EDIT: formatting fail
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 05:54:54 pm
just wondering: is it safe to embed random Asm(E5)'s and Asm(E1)'s into an axe program? (I mean other than the obvious problems of the stack not exiting the same as it entered)

I mean, can I push data onto the stack and count on axe to leave it all intact and contiguous? (except when using inside parentheses, I know that)

btw,  E5 and E1 are 'push hl' and 'pop hl', respectively

If not, I'm pulling out Mimas...
Title: Re: Axe Parser
Post by: Builderboy on December 10, 2010, 05:59:57 pm
just wondering: is it safe to embed random Asm(E5)'s and Asm(E1)'s into an axe program? (I mean other than the obvious problems of the stack not exiting the same as it entered)

btw,  E5 and E1 are 'push hl' and 'pop hl', respectively

If not, I'm pulling out Mimas...

its definitely not safe to do it at random, but if you do it in a way that ensures you are not popping HL's to overwrite crucial data (since Axe uses HL as a kind of Ans), and if you ensure that you don't do it across calls (since Axe pushes the address to return too), and if you ensure that the stack is the same size and content as when it started, you should be able to avoid a crash
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 06:05:04 pm
ok I can avoid using it in calls (or just use 'pop de/pop hl/push de' etc), and using it to store/recall the Ans is exactly what I'm using it for.
Also, I'll have a counter so that I know how many items are in the stack at a given time. Also gotta avoid using it in the middle of routines. like no Output(0,0,Asm(E1)>Dec), that'll probably cause an error

EDIT: also, while I'm here, "Str1" is sufficient for a GetCalc( filename, right?
Title: Re: Axe Parser
Post by: nemo on December 10, 2010, 06:29:36 pm
ok I can avoid using it in calls (or just use 'pop de/pop hl/push de' etc), and using it to store/recall the Ans is exactly what I'm using it for.
Also, I'll have a counter so that I know how many items are in the stack at a given time. Also gotta avoid using it in the middle of routines. like no Output(0,0,Asm(E1)>Dec), that'll probably cause an error

EDIT: also, while I'm here, "Str1" is sufficient for a GetCalc( filename, right?

yes, Str1 is free game.
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 07:35:46 pm
how about parsing them tokens? how do I do that? ???
The main problem is the variable token size... and that I need to check for tokens of both sizes.
Title: Re: Axe Parser
Post by: nemo on December 10, 2010, 07:39:00 pm
i'm confused... from what source? a string? a program? and parsing them so you can.. display them? store their integer equivalents into a free ram area?
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 07:44:26 pm
From a string, and so that I can interpret them.

as in:


If A=T+
Goto PL
End
If A=T-
Goto SB
End
...

Except not all of my symbols I need to check are 1 byte tokens.
Title: Re: Axe Parser
Post by: Deep Toaster on December 10, 2010, 07:46:31 pm
ok I can avoid using it in calls (or just use 'pop de/pop hl/push de' etc), and using it to store/recall the Ans is exactly what I'm using it for.

I don't think any routines suddenly ret back from where it's called, so it should be all right if you restore it...
Title: Re: Axe Parser
Post by: nemo on December 10, 2010, 07:51:07 pm
i've probably linked to this page 100 times this week. (http://tibasicdev.wikidot.com/one-byte-tokens) this'll help you decide what tokens are two-byte tokens. store your token into {L1}, and if {L1} is one of the numbers that is indicates a two-byte token, read the next byte into {L1+1} and go through your checks from {L1}r. i'm not 100% sure this will work though, it is on the right track, since i've never done this before.
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 07:53:06 pm
On second thought, I could just check a 1-byte value against all my 1-byte tokens, and then, if i got no hits, load the second byte and check all the two-byte tokens...

But I don't want to have to look all my tokens up in a table... ah well... tibasicdev has a good table.
Title: Re: Axe Parser
Post by: nemo on December 10, 2010, 07:54:24 pm
On second thought, I could just check a 1-byte value against all my 1-byte tokens, and then, if i got no hits, load the second byte and check all the two-byte tokens...

But I don't want to have to look all my tokens up in a table... ah well... tibasicdev has a good table.

you don't have to look up all your tokens in a table, i don't think... use t on a two byte token will work just as well as it will on a one byte.
Title: Re: Axe Parser
Post by: lookitsan00b on December 10, 2010, 08:10:27 pm
I'm not worried about T. I'm worried about the fact that {...} can cut off the end of a two byte token, and {...}r can be one of three things:

 1: two one-byte tokens
 2: a one-byte token followed by the first half of a two-byte
 3: a two byte token.

I also need to know how much to increment my 'PC'... which is a pointer to the next token in the program string.
Title: Re: Axe Parser
Post by: lookitsan00b on December 12, 2010, 11:30:15 pm
hey you know the thing Axe does when you select compile from the menu? How do I do that...
Spoiler For irony:
...in Axe?
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 12, 2010, 11:34:39 pm
Do you mean how the selection bar moves up and down smoothly? I could maybe dig up my xLIB xLIB Revolution menu code later, although it's in BASIC+xLIB. Maybe someone could convert it to Axe. :P
Title: Re: Axe Parser
Post by: lookitsan00b on December 12, 2010, 11:40:48 pm
no no no no no!!!
I thought my hints were clear enough... I meant AFTER you press 2nd/Enter while the cursor is over the 'compile' option.

...and I'm not talking about the transition effect :P (epic fade effect dude, its almost faster than ASM)

Spoiler For if my hints are insufficient:
Ok how do I parse the VAT searching for programs? Or just force open the prgm menu and get the prgm name as output?
Title: Re: Axe Parser
Post by: Builderboy on December 12, 2010, 11:56:07 pm
Ah i see, you're joking.  I assume you are asking how to compile programs in Axe?
Title: Re: Axe Parser
Post by: lookitsan00b on December 13, 2010, 12:04:09 am
lulz edited too late :P
no no no no no!!!
I thought my hints were clear enough... I meant AFTER you press 2nd/Enter while the cursor is over the 'compile' option.

...and I'm not talking about the transition effect :P (epic fade effect dude, its almost faster than ASM)

Spoiler For if my hints are insufficient:
Ok how do I parse the VAT searching for programs? Or just force open the prgm menu and get the prgm name as output?

I think the second option is best... for now at least.
Title: Re: Axe Parser
Post by: Builderboy on December 13, 2010, 12:10:59 am
Ah i see, there is a topic about that here actually

http://ourl.ca/7202

It has some really good info
Title: Re: Axe Parser
Post by: lookitsan00b on December 13, 2010, 12:16:49 am
KTHXBAI




:P
Title: Re: Axe Parser
Post by: AngelFish on December 13, 2010, 12:23:20 am
Do you mean how the selection bar moves up and down smoothly? I could maybe dig up my xLIB xLIB Revolution menu code later, although it's in BASIC+xLIB. Maybe someone could convert it to Axe. :P

It's very easy to do actually, with the RectI( command. I normally just use a subroutine like

Code: [Select]
:For(A,0,9
:RectI(X,Y,width,height
:Y-W->Y
:RectI(X,Y,width,height
:End

You just flip the sign of W to make it move up or down.
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 13, 2010, 01:35:07 am
Ah I see lookitsan00b, it wasn't too clear to me. I just couldn't find anything special to replicate past the title screen sequence. Also what is the transition effect? I never saw any on my 83+ or Nspire O.O
Title: Re: Axe Parser
Post by: lookitsan00b on December 14, 2010, 11:20:43 pm
Ah I see lookitsan00b, it wasn't too clear to me. I just couldn't find anything special to replicate past the title screen sequence. Also what is the transition effect? I never saw any on my 83+ or Nspire O.O

Sorry, a bit of sarcasm there. Scr1 -> Scr2 + Low_quality_LCD = barely perceptible fade effect. :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 15, 2010, 04:18:13 am
Oh I see now. This is normal with that kind of LCD. The fade effect is a good thing, though, for grayscale, else grayscale would be impossible if it faded instantly.
Title: Re: Axe Parser
Post by: feerik on December 20, 2010, 01:01:59 pm
doesnt look that bad
Title: Re: Axe Parser
Post by: Michael_Lee on December 21, 2010, 03:02:34 pm
Quick question: Which is faster:
Code: (Example 1) [Select]
For(C,0,10)
  Code...
  If A
    If B
      Do something...
    End
  End
End

versus

Code: (Example 2) [Select]
For(C,0,10)
  Code...
  If A and B
    Do something...
  End
End

(If it helps, in both examples, the chances of A or B being true are about 1 in 6, but the chances of both of them being true at the same time are about 1 in 36 (well, approximately - probability isn't my strongest point))
Title: Re: Axe Parser
Post by: Builderboy on December 21, 2010, 03:22:38 pm
The first is faster, since 5 out of 6 times the program isn't even *looking* to see what B is.  This is known as short circuit evaluation and can come in very handy :)
Title: Re: Axe Parser
Post by: Michael_Lee on December 21, 2010, 03:24:25 pm
Sweet, thanks!
Title: Re: Axe Parser
Post by: Deep Toaster on December 21, 2010, 08:02:21 pm
And remember to put the least commonly true statement on top to make it eve faster :D
Title: Re: Axe Parser
Post by: Michael_Lee on December 23, 2010, 01:01:05 pm
Follow-up question to this: http://ourl.ca/4050/155915 (http://ourl.ca/4050/155915)

What if both A and B had a high chance of being true at the same time?  Then would
Code: [Select]
If A
  If B
    Do stuff
  End
End
still be the fastest way to evaluate it?
Title: Re: Axe Parser
Post by: calcdude84se on December 23, 2010, 01:05:36 pm
Something to note about using "A and B" is that, for example, if A is 2 and B is one, then "A and B" evaluates to 0. (This is no concern if A and B are never anything other than 1.) You have to use "(A!=0) and (B!=0)", where "!=" is the not equal to sign, to get around this.
Title: Re: Axe Parser
Post by: Michael_Lee on December 23, 2010, 01:09:34 pm
Yeah, I remember that.  That was one of the more inexplicable 'bugs' I had encountered while making my minesweeper game.

But nevertheless:
Code: [Select]
If A
  If B
    Do stuff
  End
End

or...

If A!=0 and (B!=0)
  Do stuff
End

Which is faster, given A and B are usually both true?
Title: Re: Axe Parser
Post by: Runer112 on December 23, 2010, 01:12:00 pm
Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]
If A
  If B
    Do stuff
  End
End

Code: [Select]
If A and B
  Do stuff
End

The second one is only faster if A will be true at least 16/17 of the time.
Title: Re: Axe Parser
Post by: Michael_Lee on December 23, 2010, 01:14:06 pm
Erm, what is a 't-state', and how exactly did you arrive by those numbers?
Title: Re: Axe Parser
Post by: calcdude84se on December 23, 2010, 01:15:24 pm
It has to deal with the underlying machine code that Axe produces.
He looked at the disassembled code :) (There are tables for how many t-states each opcode takes)
Title: Re: Axe Parser
Post by: Happybobjr on December 23, 2010, 01:27:17 pm
where would one find these tables?
Title: Re: Axe Parser
Post by: calcdude84se on December 23, 2010, 01:31:13 pm
There is a plethora of information on the z80 processor in general at z80.info (http://z80.info)
In addition, in the instruction set reference in the 28Days tutorial.
Title: Re: Axe Parser
Post by: Builderboy on December 23, 2010, 02:18:33 pm
Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]
If A
  If B
    Do stuff
  End
End
  • A is false: 34 t-states
  • A is true: 68 t-states

Code: [Select]
If A and B
  Do stuff
End
  • 66 t-states

The second one is only faster if A will be true at least 16/17 of the time.


Thats excellent data!  So what that means is that even if A is true 94% of the time, its still worth it to make the change to two if statements :D  So as a general rule, the best thing to do is to use two different If statements if you are going for absolute speed.  Unless A is only false like once in every 9000th cycle :P
Title: Re: Axe Parser
Post by: lookitsan00b on December 23, 2010, 02:57:46 pm
Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]
If A
  If B
    Do stuff
  End
End
  • A is false: 34 t-states
  • A is true: 68 t-states

Code: [Select]
If A and B
  Do stuff
End
  • 66 t-states

The second one is only faster if A will be true at least 16/17 of the time.


Thats excellent data!  So what that means is that even if A is true 94% of the time, its still worth it to make the change to two if statements :D  So as a general rule, the best thing to do is to use two different If statements if you are going for absolute speed.  Unless A is only false like once in every 9000th cycle :P

And if A is only false once in every 9000th cycle, you could probably do
Code: [Select]
:If B
:  If A
:    do stuff
:  End
:End

of course that requires the order to be interchangeable :P
Title: Re: Axe Parser
Post by: Quigibo on December 23, 2010, 03:38:43 pm
The statistics would be different if you assume that A and B are non-Boolean.  In that case you have extra clock cycles for the not equals zero operations which might actually make it always faster to do the 2 separate statements regardless of probability.  But then again, realistically in programs, there is likely to be a mix of operations so I would include in that calculation.

Code: [Select]
If A__op__
  If B__op__
    Do stuff
  End
End

Code: [Select]
If A__op__ and (B__op__)
  Do stuff
End

In this case, assuming the previous numbers were correct, there is a difference of
    * A is false: 34 t-states + ops
    * A is true: 68 t-states + ops

Against:
    * Always: 87 t-states + ops

So you should always short circuit if you're looking for a speed optimization (assuming non-Boolean), but the second is smaller I think.
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 26, 2010, 01:13:22 am
Nice trick guys :D
Title: Re: Axe Parser
Post by: Quigibo on December 26, 2010, 05:16:53 am
Yup, so the last of the betas is out (hopefully).  Now is the time to catch those bugs so 1.0.0 can be as bug free as possible.  I would also like to get a small group to test pre-releases so that I can be more confident in the stability.   The only requirement is that you have at least one very large file and a variety of programs to test it on.  I am also interested in an assembly programmer who wants to get a head start writing an Axiom so I can have another example to play with in addition to my mode 7 Axiom.  Examples of possible Axiom projects: CalcNet, Raycaster, DCS GUI interface, Fast Math Library, or anything else you can think of.

I'll be gone for a few days, but I'll start picking volunteers when I get back.  There will probably be a bias to more experienced Axe programmers since I only need a few.
Title: Re: Axe Parser
Post by: Builderboy on December 26, 2010, 05:25:36 am
I would love to test Axe 1.0.0 :) I have thousands of bytes of source i am frequently compiling with PortalX, as well as several other small side projects in Axe. 

And the new Axe took 51 bytes of the PortalX main engine! ^^ now to go and do some more optimization :D
Title: Re: Axe Parser
Post by: Fast Crash on December 26, 2010, 05:35:06 am
I would also like to test it  :D

The Icon command is just awesome !
Title: Re: Axe Parser
Post by: Munchor on December 26, 2010, 07:08:43 am
So many updates! Axe 0.4.7 looks wonderful!
Title: Re: Axe Parser
Post by: squidgetx on December 26, 2010, 09:35:19 am
I'll test 1.0.0 too :) A:P's source is around 70k, and I'm constantly compiling lots of other smaller things like its map editor.

Also, awesome new updates :)

edit: wow, new version shaved off 112 bytes off of A:P's main engine O.o
Title: Re: Axe Parser
Post by: FinaleTI on December 26, 2010, 10:04:19 am
I'd love to test 1.0.0 as well.
I know Nostalgia and Pokemon are gonna be getting pretty large fast.
Title: Re: Axe Parser
Post by: Raylin on December 26, 2010, 10:16:45 am
I'd like to test 1.0.0 too.
Title: Re: Axe Parser
Post by: Munchor on December 26, 2010, 10:18:29 am
I am also available to test it :)
Title: Re: Axe Parser
Post by: Fast Crash on December 26, 2010, 10:19:09 am
soon it will be a public beta  :P
Title: Re: Axe Parser
Post by: Michael_Lee on December 26, 2010, 11:21:56 am
If you wish, I am also available for testing services.  I have a bunch of small programs I can test Axe 1.0.0 on, plus several larger projects I'm workimg on, although they aren't probably as large as some of the other projects mentiomed here yet.
Title: Re: Axe Parser
Post by: Deep Toaster on December 26, 2010, 01:24:27 pm
0.4.7 looks really good! I can probably test too. I've got three current projects split into about 36 subprograms, so that should be a sort of stress for the parser :D
Title: Re: Axe Parser
Post by: Runer112 on December 26, 2010, 01:59:17 pm
Unless calc84maniac wants to step in here, I'd be happy to test the axiom capabilities with my raycaster (it's not the Axe one, I wrote a whole new one in pure assembly). I also have a bunch of 32-byte math routines I was just waiting to test!
Title: Re: Axe Parser
Post by: Michael_Lee on December 26, 2010, 02:05:15 pm
Lulz, it seems everybody wants one.

Also, the new line commands are fast.  Kudos for that!
Title: Re: Axe Parser
Post by: Ashbad on December 26, 2010, 02:41:49 pm
Lol my vector tunnel game shot up to 55 FPS with the new routine...
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 26, 2010, 04:04:19 pm
Awesome, lots of nice commands added too. I hope not too many bugs are encountered so you don't have to release too many fixes. I probably will not help on beta-testing, though, because I haven't programmed Axe for several months.

EDIT: WOAH! Line is definitively faster! O.O
Title: Re: Axe Parser
Post by: jnesselr on December 26, 2010, 05:01:31 pm
whoa. That is amazing! It's almost exactly like real ASM now!

EDIT: Yes, I know it produces real asm code. But if you code in pure asm, you know what I mean.
Title: Re: Axe Parser
Post by: Deep Toaster on December 26, 2010, 05:03:19 pm
Awesome, lots of nice commands added too. I hope not too many bugs are encountered so you don't have to release too many fixes. I probably will not help on beta-testing, though, because I haven't programmed Axe for several months.

EDIT: WOAH! Line is definitively faster! O.O

That is fast. Great job on all those optimizations O.O
Title: Re: Axe Parser
Post by: jnesselr on December 26, 2010, 05:56:36 pm
I'm looking forward to 1.0.0 even more now!
Title: Re: Axe Parser
Post by: Michael_Lee on December 30, 2010, 12:33:39 am
Question:
If I have a string, is there a way to get it to display only a set number of characters from that string?
For example, if I have
Code: [Select]
"Hello World Foobar"->Str1
is there a way to display only 6 characters at a time, so I can separately display
Code: [Select]
"Hello "
"World "
"Foobar"
depending on a numerical input I give in?
Title: Re: Axe Parser
Post by: Quigibo on December 30, 2010, 05:29:04 am
Sure:

Code: [Select]
:0->A->{L1+6}
:length(Str1)->L
:While A<L
:Copy(Str1+A,L1,6)
:Disp L1,i
:A+6->A
:End

You just copy the part of the string you want to display to another buffer (and end that buffer with a zero) and then just Disp that buffer.
Title: Re: Axe Parser
Post by: Happybobjr on December 30, 2010, 10:12:56 am
thank you, i needed that too.
Title: Re: Axe Parser
Post by: Munchor on December 30, 2010, 10:13:43 am
Axe Parser won POTY Awards 2010 TI-83+ Series Calculators :D Congratulations Quigibo!
Title: Re: Axe Parser
Post by: yunhua98 on December 30, 2010, 11:13:44 am
*cough*landslide victory*cough*
If Kerm had waited til next year to upload DCS7...
we got 2 POTYs!
Title: Re: Axe Parser
Post by: ztrumpet on December 30, 2010, 11:37:32 am
Congrats Quigibo! ;D
Title: Re: Axe Parser
Post by: Binder News on December 30, 2010, 11:43:19 am
Yay for Quigibo!!!!!!
Title: Re: Axe Parser
Post by: Raylin on December 30, 2010, 12:02:19 pm
*cough*landslide victory*cough*
If Kerm had waited til next year to upload DCS7...
we got 2 POTYs!

It's not so fine and dandy over on Ceme.
Title: Re: Axe Parser
Post by: Quigibo on December 30, 2010, 03:58:52 pm
Wow!  The results are already out?!?  O.O

That is so cool!  I can't believe it was by such a big margin too, I really thought it was going to be close. Thanks everyone for all the support, I couldn't have done it without you guys.  From the beginning I never thought it would take off like this and actually be this popular and especially this early in development since a stable version still isn't out yet.  Also, I've noticed that more than half of the new 83/84 assembly programs being released currently are written in Axe and its not just forum members here either.  So I think the project has been quite successful overall  ;D

Also, its great how each of the top 4 nominees ALL had their own programming language or language extension!
Title: Re: Axe Parser
Post by: Raylin on December 30, 2010, 04:11:13 pm
Congrats, sir. :)
Title: Re: Axe Parser
Post by: jnesselr on December 30, 2010, 05:20:38 pm
Yeah, this has been a good year for programming both the NSpire and the TI-83/84.  I do hope this continues next year. ;-)
Title: Re: Axe Parser
Post by: squidgetx on December 30, 2010, 07:36:31 pm
Woah, someone voted for cuberunner :o

Anyway, gratz Quigibo! Axe is just....amazing (notice how 4 of the featured programs this year were written in Axe ;) )
Title: Re: Axe Parser
Post by: Munchor on December 30, 2010, 07:47:37 pm
Woah, someone voted for cuberunner :o

Anyway, gratz Quigibo! Axe is just....amazing (notice how 4 of the featured programs this year were written in Axe ;) )

Cuberunner is a really good game, the new most popular of my class.
Title: Re: Axe Parser
Post by: Michael_Lee on December 30, 2010, 09:25:55 pm
...since a stable version still isn't out yet.

Eh?  Methinks Axe is quite stable, indeed. 
Congratulations on your win, btw!
Title: Re: Axe Parser
Post by: DJ Omnimaga on December 30, 2010, 11:53:58 pm
*cough*landslide victory*cough*
If Kerm had waited til next year to upload DCS7...
we got 2 POTYs!

It's not so fine and dandy over on Ceme.
Yeah I wish there would have been place for two wins, because DCS7 really deserved one too. I even went close to vote for it (I finally voted for Unity, Axe, Ndless and NewProg) because it's so great too. I thought it would get pretty close to Axe amount of votes. Regardless, congrats QUigibo, but congrats to Kerm as well for having gotten that many votes, still, and more importantly, congrats to EVERYONE who got nominated!
Title: Re: Axe Parser
Post by: Builderboy on December 31, 2010, 01:38:09 am
Congratulations to Axe for winning the POTY!  And congrats to all the other featured programs as well ^^ All of them were exceptional programs ^^
Title: Re: Axe Parser
Post by: Quigibo on January 05, 2011, 05:08:56 pm
Question:

Okay, so I'm almost done with the new Axiom specifications and SDK and am beginning to convert my asm mode 7 engine to an Axiom at the same time as writing the axiom interpreter.  As you might know, there will be several new Token replacements specifically for Axioms.  Originally, I was planning to add 12 tokens to replace the parametric variables X1T-Y6T, but I decided against that now because I am introducing those as 6 entirely new variables to make communication with very large Axioms more convenient.  This is to prevent passing a gajillion arguments every time you need to call an Axiom that requires global variables.

So, I need to figure out a good spot to put these tokens.  I would prefer a single menu where I can use every or almost every single token on that menu.  I was thinking about the [2nd] [DISTR] menu but I could use the window tokens, zoom tokens, or another place instead.  Anyone have a preference?

Also, if you can think of a some generic token names that would be useful to you, but not too specific, feel free to throw them out there.  Also, all new tokens will have a left parenthesis attached, but you can close it like this() to use it as a no-argument token.  Some ideas I am considering so far are:

Start()
Next()
Up()
Down()
Left()
Right()
Render()
DrawL()
DrawR()
DrawS()
Print()


And don't forget, there are still all the TI tokens in addition to these so if you were writing an 8.8 sine routine for instance you could use sin-1() or sinh().
Title: Re: Axe Parser
Post by: AngelFish on January 05, 2011, 05:18:41 pm
How about Run(, to allow for the possibility of Axe based languages?
Title: Re: Axe Parser
Post by: Ashbad on January 05, 2011, 05:19:30 pm
Qwerty, I'm sure your idea is a good one, but I don't understand what you mean by it.  Can you explain?  I'm a bit slow :P
Title: Re: Axe Parser
Post by: AngelFish on January 05, 2011, 05:22:58 pm
Run( would copy pgrmNAME to a location in RAM if archived then return the pointer. If it is in RAM, then it would just return the pointer. That way, you could compile/interpret things with an Axe based Axiom.
/me is confusing himself.
Title: Re: Axe Parser
Post by: calc84maniac on January 05, 2011, 05:25:27 pm
Hmm, that reminds me... can file objects read from variables in RAM, or only from archive?
Title: Re: Axe Parser
Post by: Quigibo on January 05, 2011, 05:57:41 pm
@calc84maniac: I dunno.  I think I tried unsuccessfully before, I'm using the LoadDEIndPaged bcall so I'm not sure if that's able to read from ram.  However, the file pointers are now dereferenceable so you are able to change or lookup the page number and pointer at any time.
Title: Re: Axe Parser
Post by: Binder News on January 05, 2011, 06:20:32 pm
Slightly off topic, but Quigibo, do you know of a sprite xor routine exactly like the one in axe, but that does 4x4 sprites?
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 06, 2011, 02:02:19 am
I can't tell about token names for now since I'm kinda tired but using the ones in an entire menu would be a good idea if it's all for the same thing, otherwise with all the renamed tokens it will get hard to find them in the CATALOG since they're not sorted alphabetically.
Title: Re: Axe Parser
Post by: Quigibo on January 09, 2011, 03:32:04 pm
So the new Axiom SDK is out.  If anyone wants to attempt one, you will definitely get to try it out on 1.0.0 before the official release.  The inc file is not totally finished because I haven't added the new token equates yet, but I'll get to that soon.  Let me know if you have any questions about the Axiom format, some things about it might be confusing.  One thing I'll mention is what the "Stored to" command modifier is.  EXP->DispGraph is a one argument version of this and EXP->float{EXP} is a 2 argument version.
Title: Re: Axe Parser
Post by: ztrumpet on January 09, 2011, 05:35:46 pm
I can't tell about token names for now since I'm kinda tired but using the ones in an entire menu would be a good idea if it's all for the same thing, otherwise with all the renamed tokens it will get hard to find them in the CATALOG since they're not sorted alphabetically.
Yes, that would be great.  Is this possible? ;D
Title: Re: Axe Parser
Post by: FloppusMaximus on January 09, 2011, 06:49:36 pm
I can't tell about token names for now since I'm kinda tired but using the ones in an entire menu would be a good idea if it's all for the same thing, otherwise with all the renamed tokens it will get hard to find them in the CATALOG since they're not sorted alphabetically.
Yes, that would be great.  Is this possible? ;D
Yes, it is, but I'm not sure whether or how well it's been documented.  What you want is the catalog hook(s).  One or the other of them - I think it's the second - is the hook that language localization apps use to reorder the catalog.  It's been years since I looked at that stuff, though.
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 10, 2011, 01:55:14 am
I'm glad to see the fixed version of Axe out. Hopefully no new bug arises from the change.
Title: Re: Axe Parser
Post by: Deep Toaster on January 15, 2011, 12:08:11 pm
So the new Axiom SDK is out.  If anyone wants to attempt one, you will definitely get to try it out on 1.0.0 before the official release.  The inc file is not totally finished because I haven't added the new token equates yet, but I'll get to that soon.  Let me know if you have any questions about the Axiom format, some things about it might be confusing.  One thing I'll mention is what the "Stored to" command modifier is.  EXP->DispGraph is a one argument version of this and EXP->float{EXP} is a 2 argument version.

Oh, we can use the store symbol with Axioms too? That sounds pretty powerful... :D
Title: Re: Axe Parser
Post by: wvstudios on January 17, 2011, 05:54:23 pm
Three words:
Best. App. Ever.  now, if I could only transfer the newest version to my calculator... *sigh*
Title: Re: Axe Parser
Post by: Deep Toaster on January 17, 2011, 08:02:24 pm
Three words:
Best. App. Ever.

Agreed.

now, if I could only transfer the newest version to my calculator... *sigh*

It doesn't transfer? You should post a bug report here (http://ourl.ca/4072).

And welcom to Omni!
Title: Re: Axe Parser
Post by: Binder News on January 17, 2011, 08:30:57 pm
Hi wvstudios. Yes it is the best app ever. What transfer program are you using. If it's TIConnect, I suggest switching to TiLP (google it). Also, you might want to introduce yourself here (http://www.omnimaga.org/index.php?board=10.0).

(Note to self: even though you already have >200 posts, you never introduced yourself)
Title: Re: Axe Parser
Post by: Builderboy on January 18, 2011, 01:12:36 am
Heya wvStudios :D You should make a topic in the Introduce Yourself thread, then we can all welcome you properly :) You should also totally make a page for the Greenfoot game you are developing too ;D
Title: Re: Axe Parser
Post by: Quigibo on January 19, 2011, 07:03:23 pm
So...

I am really busy again with school.  More so than before and I haven't had any free time for the past few days.  But, at the same time, I am very very close to finishing the Axioms and being done with the majority of 1.0.0 changes.  I for sure want to finish it all by Axe's 1-year anniversary from the first alpha version (Feb. 1st) so for sure it will be done by then.  After that, there will be no more syntax changes since the Axioms will provide a framework for that.  However, there will be a small amount of syntax additions and optimizations given that all future versions must be backwards compatible with 1.0.0 since I will declare it stable.
Title: Re: Axe Parser
Post by: Michael_Lee on January 19, 2011, 07:06:42 pm
Sweet.  Good luck!
Title: Re: Axe Parser
Post by: Deep Toaster on January 19, 2011, 08:00:39 pm
Sweet.  Good luck!

And with life, too! I know how they can intersect :P

Also, one year anniversary :o
/me can't wait for the final Axe...
Good luck!
Title: Re: Axe Parser
Post by: squidgetx on January 19, 2011, 08:03:36 pm
finish it all by Axe's 1-year anniversary from the first alpha version (Feb. 1st)
How fitting.
Good luck with all of this (and making sure that future versions can be backwards compatible; that sounds hard :P) What are some of the new changes/features?

edit: woo, 800th post :D
edit2: and 100 respect :O
Title: Re: Axe Parser
Post by: ztrumpet on January 19, 2011, 08:07:16 pm
Awesome!  I can't wait.  Good luck! ;D
Title: Re: Axe Parser
Post by: FinaleTI on January 19, 2011, 08:11:44 pm
That'd be pretty awesome to release it on it's one year anniversary, so good luck.
Title: Re: Axe Parser
Post by: Binder News on January 19, 2011, 08:15:12 pm
Go Quigibo! This is totally epic!

Edit: I just realized I broke 300 posts! Almost half way...
Title: Re: Axe Parser
Post by: Michael_Lee on January 21, 2011, 05:39:02 pm
Is there a way to increase/decrease the size of an appvar without deleting the data contained in the appvar?
Title: Re: Axe Parser
Post by: Binder News on January 21, 2011, 06:48:13 pm
Copy the data to an arbitrary buffer, recreate the appvar with the new size, copy the data back in.
Title: Re: Axe Parser
Post by: Michael_Lee on January 21, 2011, 06:51:13 pm
What if my appvar is larger then any of the buffers, and I might not have enough room to make a second appvar in memory as a temporary storage buffer?
Title: Re: Axe Parser
Post by: calc84maniac on January 21, 2011, 06:55:03 pm
This is why Quigibo needs to make InsertMem and DelMem functions. Seriously.
Title: Re: Axe Parser
Post by: Runer112 on January 21, 2011, 06:55:37 pm
This is why Quigibo needs to make InsertMem and DelMem functions. Seriously.
^++
Title: Re: Axe Parser
Post by: Binder News on January 21, 2011, 07:02:48 pm
Yeah, but isn't that kinda hard, as changing the length of an appvar without going through the system routines would screw with other memory. Right?
Title: Re: Axe Parser
Post by: calc84maniac on January 21, 2011, 07:04:04 pm
Yeah, but isn't that kinda hard, as changing the length of an appvar without going through the system routines would screw with other memory. Right?
That's the thing, these are system routines. Axe just doesn't have any way to access them without inline asm.
Title: Re: Axe Parser
Post by: nemo on January 21, 2011, 07:51:28 pm
Code: [Select]
to insert:
[ADDRESS]   .put the address into HL
Asm(EB)    . ex de, hl
[SIZE]
Asm(EF42F7)

but it doesn't check if there's enough RAM, nor does it update the size of the variable you're updating.. so there are some issues... but it can't be hard to write an axiom for it.

Title: Re: Axe Parser
Post by: DJ Omnimaga on January 21, 2011, 09:35:11 pm
Yeah insert/deletemem would be nice, IMHO.
Title: Re: Axe Parser
Post by: squidgetx on January 21, 2011, 10:12:28 pm
Alternatively you can have the original appvar in archive and copy it to another appvar with a different name, archive it, delete the original, make a new one of the new size and same original name, then copy to it from the one in archive. Although nemos way is probably much easier ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 21, 2011, 10:15:53 pm
Yeah that's what someone said before, but unfortunately this is not convenient if you're running low on RAM.
Title: Re: Axe Parser
Post by: squidgetx on January 21, 2011, 10:19:43 pm
My way is long and inefficient but works as long as you have enough ram to hold the new sized appvar :P (and that's it... So if you have a 12k appvar and you want to make it 14 k all you need is 14k of ram... Which is the same memory requirement as nemos :P
Title: Re: Axe Parser
Post by: Binder News on January 21, 2011, 10:22:40 pm
That's why I suggest using something like L1. It already exists in RAM, and so wouldn't need to be allocated.
Title: Re: Axe Parser
Post by: squidgetx on January 21, 2011, 10:25:51 pm
But unfortunately this is inconvenient if you want to make a new appvar that is larger than 768 bytes...

Also I apologize for any lack of clarity/unintended rudeness... I'm slightly sick :P
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 21, 2011, 10:27:46 pm
Hmm if you delete an archived appvar this large then recreate one, won't that be hard on the flash chip, though?
Title: Re: Axe Parser
Post by: Binder News on January 21, 2011, 10:31:11 pm
@DJ: Yea, I think so.

I hope you feel better soon, squidgetx.
Title: Re: Axe Parser
Post by: Builderboy on January 22, 2011, 02:24:36 am
Maybe what we need is an advanced memory handling Axiom?  It could insert and delete memory, and could also handle advanced things like updating the vat, changing the size counters, and maybe even putting the calculator in program edit mode.
Title: Re: Axe Parser
Post by: Deep Toaster on January 22, 2011, 09:53:36 am
Maybe what we need is an advanced memory handling Axiom?  It could insert and delete memory, and could also handle advanced things like updating the vat, changing the size counters, and maybe even putting the calculator in program edit mode.

I'm already working on that ^^

Insert/DeleteMem, dynamic vars, edit buffers...
Title: Re: Axe Parser
Post by: Binder News on January 22, 2011, 10:01:51 am
Runer already made an Axiom for that. But I would still like to see your version. Who knows, yours may be better.
Title: Re: Axe Parser
Post by: Michael_Lee on January 23, 2011, 03:09:41 pm
Quick question - let's say that I'm using L1 to hold a lot of data, but occasionally I would want to store lots of more data - more then L1 can hold.
Is there a way to 'chain' memory spaces, so that if I were to overflow L1, I would write my data to an appvar or other buffer instead?
Effectively, it would treat L1 and an appvar as one huge block of memory.
Title: Re: Axe Parser
Post by: Ashbad on January 23, 2011, 03:16:16 pm
yeah, to do that you would have already created an appvar witha  pointer to it, and know the size of the buffer you're using (I'll use appbackupscreen for now because I most definately know that offset) At L3 and a pointer to your appvar at P:

EDIT: and btw this is just to read code one byte at a time, with X as your offset:

Code: [Select]
{L3+X+((L3+X>L3+767)*(P-L3+767))} -> Y
Disp Y >Dec
Title: Re: Axe Parser
Post by: ztrumpet on January 23, 2011, 06:32:46 pm
Quigibo, can you have the parser check Axioms first and then check the actual Axe code?  This would allow redefinition of various Axe functions and allow different behavior.  For instance, if you were writing some BrainFck in Axe and had an Axiom for it, you could use + in the way BrainFck requires it to be used in. :)
Title: Re: Axe Parser
Post by: Quigibo on January 25, 2011, 05:08:47 pm
I am pleased to announce that I have finished the Axioms finally.  I will be distributing pre-release versions to a few people later today after I do more testing with them.  They are extremely powerful right now.  New features include: recursive axiom chain calling, distinct commands using identical tokens but based on different arguments, r modifiers, store arrows, and shells; native axe routine calling, relative and absolute referencing for any 2-byte immediate instruction, including calls, jumps, and loads; easily add data tables to aid your axioms, new tokens specifically for axioms, and a lot of other features I'm probably forgetting.

Basically, you have nearly complete control with the new commands.  I'm looking forward to some really great libraries ;D  I'm also going to make a mode7 example program using the new library since I haven't done any example programs for a while.

Quigibo, can you have the parser check Axioms first and then check the actual Axe code?  This would allow redefinition of various Axe functions and allow different behavior.  For instance, if you were writing some BrainFck in Axe and had an Axiom for it, you could use + in the way BrainFck requires it to be used in. :)

I don't want to look through the axioms first or else the parsing will be slower since it will have to scan every single axiom before it starts looking at the regular commands.  Also, I don't have axiom support for operators since they require a lot of special form stuff like auto-optimizations and operation on parenthesis.
Title: Re: Axe Parser
Post by: Happybobjr on January 25, 2011, 05:24:28 pm
Can't wait!
Title: Re: Axe Parser
Post by: Michael_Lee on January 25, 2011, 08:53:00 pm
Fantastic!  I can't wait to see some of these Axioms!
Title: Re: Axe Parser
Post by: Deep Toaster on January 25, 2011, 08:55:07 pm
Wow! Can't wait for this new Axiom stuff to come out!
/me has ideas already :D
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 28, 2011, 10:49:11 pm
That's great Quigibo! I can't wait to see the Mode 7 engine too. I wonder if Runer112 will release his raycaster Axiom soon afterward too. :P
Title: Re: Axe Parser
Post by: Darl181 on January 31, 2011, 08:31:57 pm
Is there a way to store a TIOS picvar, say, Pic1, to a buffer without using dispgraph?
Title: Re: Axe Parser
Post by: ztrumpet on January 31, 2011, 08:33:09 pm
Yes, you can use the Copy() command to take the data from the OS var and place it wherever you like. :)
Title: Re: Axe Parser
Post by: Deep Toaster on January 31, 2011, 11:13:03 pm
Yep, remember that the buffer is just L6 and that the back-buffer is just L6. So Copy(POINTER,L6,768) should work :)
Title: Re: Axe Parser
Post by: Darl181 on February 01, 2011, 02:20:26 am
Would the picvar be required for the executable to run, or just to compile?

Another thing.  You know how {E8447}+24 is the contrast level?  What points to the Ans variable?
Title: Re: Axe Parser
Post by: Deep Toaster on February 01, 2011, 09:13:11 am
Would the picvar be required for the executable to run, or just to compile?

If you're accessing it during runtime, it's required to run.

Another thing.  You know how {E8447}+24 is the contrast level?  What points to the Ans variable?

Ans is just like any other variable: it could be anywhere in user mem. You have to find it with GetCalc() (or store to it/recall it with Axe's built-in routine).
Title: Re: Axe Parser
Post by: Darl181 on February 01, 2011, 10:25:06 am
So, that would be like Getcalc(Ans)?  The goal is to store a token, either two-byte or one-byte, into ans.
Title: Re: Axe Parser
Post by: Deep Toaster on February 01, 2011, 10:29:17 am
So, that would be like Getcalc(Ans)?  The goal is to store a token, either two-byte or one-byte, into ans.

Oh, there's a command in Axe for that: →Ans. So if you want to store the prgm token to Ans, it's just Tprgm→Ans.
Title: Re: Axe Parser
Post by: Darl181 on February 01, 2011, 10:53:11 am
The goal, in the end, is to store a token defined by a number (either 1-byte or two-byte).
Letting A be the token #:  T{A}→Ans
Would that work?
Title: Re: Axe Parser
Post by: Deep Toaster on February 01, 2011, 11:57:11 am
Well, no. If A is the number of the token, just do A→Ans. It's just EXP→Ans, where EXP is the expression (one-byte or two-byte, doesn't matter since it gets extended to two bytes anyway) you want stored.
Title: Re: Axe Parser
Post by: Quigibo on February 02, 2011, 10:18:43 pm
Unfortunately I haven't really had time to add much more to Axe other than the Axioms, and I can't get my mode 7 engine working properly and I might have to rewrite it from scratch.  So I think I will instead release more betas since there are so many more features that need to be worked on before 1.0.0.  Instead I might just release a VAT based Axiom for reading from the VAT efficiently since that's both useful and quick to make.
Title: Re: Axe Parser
Post by: Runer112 on February 02, 2011, 11:23:19 pm
Want these? They were for the InsertMem/DelMem axiom I made a short while ago, so if you're making VAT commands, they could be useful to you. I didn't heavily test them, but they looked pretty good to me.


Code: (InsertMem) [Select]
;---------> InsertMem <---------;
;B_CALL(_InsertMem) with checks to make sure there is enough RAM and the insertion address is okay
;
;INPUTS: Arg1: Pointer to start of variable according to GetCalc()
; Arg2: Offset in variable to insert RAM
; Arg3: Number of bytes to attempt to insert
;
;OUTPUTS: 0 if not enough RAM or Arg2 is out of range
; Nonzero if successful

p_InsertMem:
;REGISTERS: hl=Arg3
;STACK: | Ret | Arg2 | Arg1 | ...
B_CALL(_EnoughMem) ;Check if enough RAM
;REGISTERS: de=Arg3
;STACK: | Ret | Arg2 | Arg1 | ...
pop hl ;Rearrange arguments and stack
pop bc
ex (sp),hl
;REGISTERS: bc=Arg2 de=Arg3 hl=Arg1
;STACK: | Ret | ...
jr c,__InsertMemFail0Args ;Return failure if not enough RAM
dec hl ;Get current variable size
ld a,(hl)
dec hl
push hl
ld l,(hl)
ld h,a
;REGISTERS: bc=Arg2 de=Arg3 hl=current variable size
;STACK: | Arg1-2 | Ret | ...
sbc hl,bc ;Check if offset is outside of variable
jr c,__InsertMemFail1Arg ;Return failure if offset is outside of variable
add hl,bc
;REGISTERS: bc=Arg2 de=Arg3 hl=current variable size
;STACK: | Arg1-2 | Ret | ...
add hl,de ;Calculate final variable size
ex de,hl
ex (sp),hl
;REGISTERS: bc=Arg2 de=final variable size hl=Arg1-2
;STACK: | Arg3 | Ret | ...
ld (hl),e ;Store final variable size
inc hl
ld (hl),d
inc hl
;REGISTERS: bc=Arg2 de=final variable size hl=Arg1
;STACK: | Arg3 | Ret | ...
add hl,bc ;Calculate RAM insertion address
ex de,hl ;Prepare arguments for _InsertMem
pop hl
;REGISTERS: bc=Arg2 de=Arg1+Arg2 (RAM insertion address) hl=Arg3 (bytes to insert)
;STACK: | Ret | ...
B_CALL(_InsertMem) ;Insert memory
;REGISTERS: de=RAM insertion address hl=a lot (negative size of a VAT entry?)
;STACK: | Ret | ...
ret ;Result is always nonzero
__InsertMemFail1Arg:
pop hl
__InsertMemFail0Args:
ld hl,0
ret
__InsertMemEnd:

Code: (DelMem) [Select]
;---------> DelMem <---------;
;B_CALL(_DelMem) with checks to make sure that the deletion address and size are okay
;
;INPUTS: Arg1: Pointer to start of variable according to GetCalc()
; Arg2: Offset in variable to delete RAM
; Arg3: Number of bytes to attempt to delete
;
;OUTPUTS: 0 if Arg2+Arg3 is out of range
; Nonzero if successful

p_DelMem:
;REGISTERS: hl=Arg3
;STACK: | Ret | Arg2 | Arg1 | ...
pop af ;Rearrange arguments and stack
pop bc
pop de
push af
push hl
;REGISTERS: bc=Arg2 de=Arg1 hl=Arg3
;STACK: | Arg3 | Ret | ...
add hl,bc ;Calculate offset of end of deletion
jr c,__DelMemFail ;Return failure if offset+size was so big that it overflowed
ex de,hl
;REGISTERS: bc=Arg2 de=Arg2+Arg3 hl=Arg1
;STACK: | Arg3 | Ret | ...
dec hl ;Get current variable size
ld a,(hl)
dec hl
push hl
ld l,(hl)
ld h,a
;REGISTERS: bc=Arg2 de=Arg2+Arg3 hl=current variable size
;STACK: | Arg1-2 | Arg3 | Ret | ...
sbc hl,de ;Check if end is outside of variable
pop de ;Early pop to avoid having fail condition requiring 2 pops
;REGISTERS: bc=Arg2 de=Arg1-2 hl=current variable size - (Arg2+Arg3)
;STACK: | Arg3 | Ret | ...
jr c,__DelMemFail ;Return failure if end is outside of variable
add hl,bc ;Add back offset to get final variable size
;REGISTERS: bc=Arg2 de=Arg1-2 hl=final variable size
;STACK: | Arg3 | Ret | ...
ex de,hl ;Store final variable size
ld (hl),e
inc hl
ld (hl),d
inc hl
;REGISTERS: bc=Arg2 de=final variable size hl=Arg1
;STACK: | Arg3 | Ret | ...
add hl,bc ;Calculate RAM deletion address
pop de ;Prepare size argument for _DelMem
;REGISTERS: bc=Arg2 de=Arg3 (bytes to delete) hl=Arg1+Arg2 (RAM deletion address)
;STACK: | Ret | ...
B_CALL(_DelMem) ;Delete memory
;REGISTERS: de=Arg3 (bytes to delete) hl=a lot (negative size of a VAT entry?)
;STACK: | Ret | ...
ret ;Result is always nonzero
__DelMemFail:
pop hl
ld hl,0
ret
__DelMemEnd:
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 03, 2011, 10:58:17 pm
Good luck quigibo!
Title: Re: Axe Parser
Post by: Darl181 on February 04, 2011, 02:47:29 pm
[noobish question]What are tilemaps, and how do I use them?[/noobish question]
The ultimate goal is to get a sort of smmothscrolling, specifically for Tio.
Title: Re: Axe Parser
Post by: Michael_Lee on February 04, 2011, 02:54:05 pm
[noobish question]What are tilemaps, and how do I use them?[/noobish question]
The ultimate goal is to get a sort of smmothscrolling, specifically for Tio.

If you've ever played pokemon, you should have noticed how (for example) nearly every patch of grass is the same, the roads are fairly identical looking (at least in the older games), and that one patch of water is fairly identical to another patch of water.

A tilemap basically creates a grid, assigns a number to each square in that grid, and based on that number, displays a certain sprite.  It's just an efficent way to display large amounts of background.  Most RPGs use tilemaps, and I think all calculator RPGs use tilemaps of some sort.

It can also be used for level design -- if you look at the sliding games released recently (Psyche and CuBeS (did I capitalize that right?)) have a grid-like design, and use tilemaps.
Title: Re: Axe Parser
Post by: Darl181 on February 04, 2011, 06:29:50 pm
So, basically what I've been doing (TWHG, lightoff, tio)...I thought they were more complex than that...
For the second part.  Is there sone sort of built-in way to do them, or do I have to do the For( loop myself?  And what is the syntax for using the [Pic#]r thing?
Quote from: two posts up
The ultimate goal is to get a sort of smmothscrolling
Title: Re: Axe Parser
Post by: Michael_Lee on February 04, 2011, 07:17:59 pm
Really no built-in way to do tilemaps (as far as I know).  Basically, you have to create the 'for' loops yourself, and make your own drawing routines.

The [Pic#r]...  Hmm...
By that, do you mean the sort of 'import tilemap' thing?  I've never used it, so I can't really help, but I would think it would take the picture in a picvar, divide it up into 8x8 chunks, and return a pointer to the start of the tiles, which might aid in reusing tiles from hybrid Basic games.  Or something.
I would try something like this:
Code: [Select]
[Pic1r]->Pic000
Pt-On(10,10,Pic000)
Pt-On(18,10,Pic000+8)

For smoothscrolling, there are two ways I know:
1) Create a pixel-based offset for the start of the tilemap, and keep shifting the tilemap and redrawing it every time (this is a bad method, inefficent).
2) Use Horizontal or Vertical to shift the image over, and draw the bare minimum of tiles you need to refresh the screen (either the column or the row that needs to be filled).  Runer's uber tilemapper uses this method, or something similar - you should try looking for the thread elsewhere in this subforum.
Title: Re: Axe Parser
Post by: Darl181 on February 04, 2011, 09:51:02 pm
If you're meaning this one ? it's kind of confusing to learn from, but I get what you mean.
http://ourl.ca/7765/137919 (http://ourl.ca/7765/137919)


EDIT: just realized, axe is over a year old...
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 05, 2011, 11:29:44 pm
Happy birthday Axe.

Not only Axe is 1 years old, it's the project that had the most attention in Omni history with 12000+ posts in its sub-forum. O.O (The second one was Ultima V, I think)
Title: Re: Axe Parser
Post by: Binder News on February 05, 2011, 11:32:53 pm
Happy B-day Axe!!!!!!!!!!!!!!  :hyper: :hyper: :hyper: :hyper: :hyper: :hyper:
Title: Re: Axe Parser
Post by: Deep Toaster on February 05, 2011, 11:50:38 pm
Happy birthday Axe.

Not only Axe is 1 years old, it's the project that had the most attention in Omni history with 12000+ posts in its sub-forum. O.O (The second one was Ultima V, I think)

Epic. That's OVER 9000!!! By a lot O.O
/me loves Axe
Title: Re: Axe Parser
Post by: ztrumpet on February 06, 2011, 12:17:36 am
Thank you Quigibo!  I'm so glad you decided to share it with the community! ;D
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 06, 2011, 12:44:07 am
^This. I remember one year ago I IM'ed him about Pyoro and how I liked the game and he said he would update it, then he brought up Axe. However, back then I was still not confident because I saw so many projects like that failing due to the author's ambitions surpassing their coding skills. I told Quigibo to start with the rudimentary stuff at first that you saw in 0.0.1. Then he signed up here, shortly after joining Revsoft, to post about Pyoro. He asked me what would be the best places to announce Axe. I told him to wait a bit until he has a good enough amount of stuff done, because I was convinced people would not take the project seriously if the first version could only ClrDraw. Then on Feb 1st he announced it with version 0.0.1 and during the first month the Axe board already had 700 posts. Activity skyrocketed even more after sprites support was added.

Nonetheless, Axe came a long way since its creation and I am glad finally a language that answers everyone's wishes had success in creation. Now we have plenty of good ports of popular Flash games and a big upsurge in new releases, especially since the end of the contest.

Thank you a lot, Quigibo!
Title: Re: Axe Parser
Post by: ikemike on February 07, 2011, 06:40:14 pm
I may just not have read the documentation very well, but is it easy to save/display grayscale pictures with Axe Parser? I'm thinking I could probably make a port of "Every Day the Same Dream" using Axe Parser if saving/displaying grayscale pictures was easy enough.

Also, is there an easier way to do non-8x8 sprites?
Title: Re: Axe Parser
Post by: Michael_Lee on February 07, 2011, 07:08:56 pm
By save grayscale, do you mean while playing the game in one go, or between gameplays?  Either way, I can think of 2 methods.
If the scene changes, could first create an appvar, copy over both L6 and L3 to the appvar (L6 is the buffer, L3 is the backbuffer), compress it perhaps, then archive if you want.  You would do the reverse when opening it.
If the scene doesn't change, you could just redraw the screen by reusing the data you used to draw it in the first place.

For non-8x8 sprites - if the dimensions are less then 8x8, then just draw whatever you need to, then use Pt-On or Pt-Mask.  Both leave blank cells transparent.
If it's larger then 8x8, then you might have to end up using the existing sprite routine then making your own.
Title: Re: Axe Parser
Post by: ikemike on February 07, 2011, 08:08:23 pm
Could I save all of it into one appvar? It would require ~15 different scenes.
Title: Re: Axe Parser
Post by: FinaleTI on February 07, 2011, 08:21:27 pm
Yes. You could store both layers for each screen image consecutively.
So, the first scene could be accessed like:
Code: [Select]
GetCalc("appvMOVIE")->P
Copy(P,L6,768)
Copy(P+768,L3,768)
Then you could just call DispGraphrr or DispGraphr in a loop or something to display the scene for a little.
If you wanted to cycle through a few scenes, you could try something like this:
Code: [Select]
GetCalc("appvMOVIE")->Q
For(Z,0,3)
Z*1536+Q->P
Copy(P,L6,768)
Copy(P+768,L3,768)
Repeat getKey(54)
DispGraphr
End
End
For simplicity's sake, this just waits till you press 2nd before moving onto the second scene.

Now, if you're asking how to create the appvar:
Code: [Select]
GetCalc("appvMOVIE",number of frames * 1536)->P
...
Data for frames
Maybe they're in imported pics, or something
...

If you were gonna put the first scene into the appvar, then something like this:

Copy(pointer to front layer of first scene,P,768)
Copy(pointer to back layer of first scene,P+768,768)

Adding other scenes would follow the same pattern, just keep adding 768 to the appvar pointer.
Title: Re: Axe Parser
Post by: ikemike on February 07, 2011, 08:50:06 pm
To even create the data for these grayscale scenes, would I need to use an Axe drawing program to save them in the first place? If so, can I be recommended one?

Edit: ^v^v Thank you.
Title: Re: Axe Parser
Post by: FinaleTI on February 07, 2011, 08:53:02 pm
You can draw the picture in Paint or something on the computer, then run the picture through SourceCoder (http://www.cemetech.net/projects/basicelite/sourcecoder2.php).
Title: Re: Axe Parser
Post by: ikemike on February 08, 2011, 10:32:29 pm
I went ahead and used sourcecoder on a 96*31 picture with 3 monochrome colors. Unfortunately, it gives a "bad number" error on line 15. Can someone please help me with this problem? And is this the right place to continue to ask these questions?
Title: Re: Axe Parser
Post by: Deep Toaster on February 08, 2011, 10:39:21 pm
For image conversion, make sure it's a .bmp/.png/.gif file (one you made with Paint, for example).
Title: Re: Axe Parser
Post by: ikemike on February 08, 2011, 10:56:14 pm
Yes, I used a portable networks graphic. It is the same with a different picture of the same dimensions and color palette— it gives an error on the second line of frame information to have something besides a line of zeroes. Basically,
Code: [Select]
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
00001FF00000000000000000
000010100000000000000000
.It always messes up here^^, the second line where it has no zeroes
Title: Re: Axe Parser
Post by: calc84maniac on February 08, 2011, 10:59:19 pm
Oh, the error is when compiling with Axe? Might be because you need to surround the hex with [] brackets.
Title: Re: Axe Parser
Post by: ikemike on February 08, 2011, 11:27:01 pm
I would very much appreciate it if someone looked into the program I posted a post or two back and looked at it from there. I don't know whether it's good policy to go posting an entire program in a post, is it? In any case, I would appreciate more help.

By the way, is asking for this kind of help on IRC discouraged?
Title: Re: Axe Parser
Post by: ztrumpet on February 08, 2011, 11:49:28 pm
By the way, is asking for this kind of help on IRC discouraged?
Not at all.  That's one of the reasons the chat is there. :)  Good luck. ;D
Title: Re: Axe Parser
Post by: willrandship on February 08, 2011, 11:51:45 pm
quick tip, if you think something is going to take more than a few posts, you should probably start a new topic to avoid it getting buried.
Title: Re: Axe Parser
Post by: Munchor on February 10, 2011, 12:22:26 pm
Quick question:
If
Elif/Else-if
Else


In Axe? Thanks.
Title: Re: Axe Parser
Post by: Michael_Lee on February 10, 2011, 02:42:26 pm
Those already exist ;)
Since 0.4.5, I think, although they were buggy until recently.
Title: Re: Axe Parser
Post by: Munchor on February 10, 2011, 02:43:08 pm
Those already exist ;)
Since 0.4.5, I think, although they were buggy until recently.

I meant how to use them xD
Title: Re: Axe Parser
Post by: Michael_Lee on February 10, 2011, 02:48:25 pm
Oh.

Let's say that I have this:

Code: [Select]
If A=1
    .Do something
End
If A=2
    .Do something
End
...
If A=(some_number)
    .Do something
End

This can be shortened to
Code: [Select]
If A=1
    .Do something
ElseIf A=2
    .Do something
ElseIf ...(etc.)
    .Do something
ElseIf A=(some_number)
    .Do something
End

It can be useful when you have a whole string of If statements -- it makes things easier.

However, if you use ElseIf, once one part becomes true, it skips all the other If statements.

So if I have
Code: [Select]
3->A
If A>1
    Text(10,10,Str1)
End
If A>2
    Text(10,20,Str2)
End
That would display both Str1 and Str2.
But if I have
Code: [Select]
3->A
If A>1
    Text(10,10,Str1)
ElseIf A>2
    Text(10,20,Str2)
End
That would display only Str1 because that was the first conditional to become true.
Title: Re: Axe Parser
Post by: Munchor on February 10, 2011, 02:49:54 pm
All I need was to be told 'ElseIf' but you made a great explanation.

Looks very good, well-explained ;D
Title: Re: Axe Parser
Post by: Michael_Lee on February 10, 2011, 02:51:15 pm
Really?  Guess I went a tad bit overboard <.<
Glad you liked it though.
Title: Re: Axe Parser
Post by: Munchor on February 10, 2011, 03:34:29 pm
Really?  Guess I went a tad bit overboard <.<
Glad you liked it though.

I always like you indent your Axe code, I've seen some code made by you and I always love it.
Title: Re: Axe Parser
Post by: willrandship on February 10, 2011, 05:36:38 pm
ElseIf is Elif

And you cant repeat elses, one else per if.

Wow, old ninja. :P I guess I should have refreshed.
Title: Re: Axe Parser
Post by: NinjaKnight on February 10, 2011, 06:59:03 pm
Are you talking about me? :P
Also, is there a way to compile a program externally?
Title: Re: Axe Parser
Post by: Deep Toaster on February 10, 2011, 08:00:17 pm
Are you talking about me? :P
Also, is there a way to compile a program externally?

Nope, that's been suggested several times, but someone would have to get Quigibo's permission (and the source for Axe) to make an off-calc compiler. You can use Wabbit, though.
Title: Re: Axe Parser
Post by: Builderboy on February 11, 2011, 12:28:22 pm
Nope, that's been suggested several times, but someone would have to get Quigibo's permission (and the source for Axe) to make an off-calc compiler. You can use Wabbit, though.

I think he means compile a program externally, but still on calc.  Like a hook or an entry point.
Title: Re: Axe Parser
Post by: Munchor on February 11, 2011, 12:30:42 pm
I think he means a PC compiler, but if he meant a hook... Has a hook for Axe like Celtic ever been tried?
Title: Re: Axe Parser
Post by: ztrumpet on February 11, 2011, 04:58:13 pm
Nope, that's been suggested several times, but someone would have to get Quigibo's permission (and the source for Axe) to make an off-calc compiler. You can use Wabbit, though.
I think he means compile a program externally, but still on calc.  Like a hook or an entry point.
That's what I thought too. :D
Title: Re: Axe Parser
Post by: Deep Toaster on February 12, 2011, 12:09:52 pm
Ooh, in that case I've wanted it for a while now. Feature request! :D
Title: Re: Axe Parser
Post by: Quigibo on February 12, 2011, 02:58:26 pm
Code: [Select]
If A=1
    .Do something
End
If A=2
    .Do something
End
...
If A=(some_number)
    .Do something
End

This can be shortened to
Code: [Select]
If A=1
    .Do something
ElseIf A=2
    .Do something
ElseIf ...(etc.)
    .Do something
ElseIf A=(some_number)
    .Do something
End

Just to clarify, this would not shorten the code, but actually make it larger since they work in 2 different ways.  The elseif is actually the same as this:
Code: [Select]
If A=1
    .Do something
    Goto E
End
If A=2
    .Do something
    Goto E
End
...
If A=(some_number)
    .Do something
End
Lbl E

So you should ONLY use elseif's if you need to enforce that exactly one of the statements will execute.  In your example, the regular if statements are smaller because you're already guaranteed that A can only hold a single number.  However, its true that the elseif is faster since it only needs to check conditionals until it finds the true one instead of checking all of them.
Title: Re: Axe Parser
Post by: Quigibo on February 12, 2011, 07:54:10 pm
So double post I guess:

The next beta has arrived!  :) In case you were wondering, the new axiom is called "MemKit" can can be found in the "Tools" section of the zip file.   The developer information for developing your own axiom is in the "Developers" section.  Since the Axioms are new I expect bugs, so please report them if you feel that something is not working the way it should.  Haven't found any yet though.

Edit: Actually I did hehehe....
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 12, 2011, 07:55:08 pm
This is nice to hear. This should definitively go into news. I wonder if Runer112 will eventually release his raycaster Axiom?
Title: Re: Axe Parser
Post by: Deep Toaster on February 12, 2011, 08:01:57 pm
The next beta has arrived!  :)

Epsilon :P

But the new features sound awesome! Gonna download soon...

EDIT: Yay, Axioms!
Title: Re: Axe Parser
Post by: calcdude84se on February 14, 2011, 09:20:59 pm
Downloaded, now to send at some point. Post-test loops FTW! ;D
Title: Re: Axe Parser
Post by: shmibs on February 14, 2011, 09:26:12 pm
/\hellz yes! they've already shaved 67 bytes off of blaster master.
Title: Re: Axe Parser
Post by: Darl181 on February 14, 2011, 09:42:28 pm
Couldn't help but lol at the detail in the help section :P
Other than that, it's awesome. :D
Title: Re: Axe Parser
Post by: Munchor on March 27, 2011, 03:55:01 pm
New version, Axe 0.5.1 =D

Have you checked it yet, what do you think?

I'm curious about multiple getkeys.
Title: Re: Axe Parser
Post by: Juju on March 27, 2011, 03:59:36 pm
Same, that feature seems kinda cool.
Title: Re: Axe Parser
Post by: Quigibo on March 27, 2011, 03:59:38 pm
The new getkey is getkeyr.  Its the assmebly bcall _getkeyretoff instead of _getkeyscs.  Unfortunately, since there are so many more key combinations than keys (with 2nd and alpha) the codes are not the same and I don't have any good chart to show them.
Title: Re: Axe Parser
Post by: Juju on March 27, 2011, 04:01:54 pm
Yeah, there must be like over 9000 codes.

Oh well, I'll write a program to output the keycodes and figure them out.

Edit: Might write a chart with all the keycodes. Could be useful.
Title: Re: Axe Parser
Post by: DJ Omnimaga on March 27, 2011, 04:27:45 pm
Ah ok, nice for the update. Does Direct input remain the same if we want to use it normally?

Btw, was requiring 6 MHz mode for DispGraph intentional? Runer112 pointed this out on IRC.
Title: Re: Axe Parser
Post by: Darl181 on March 27, 2011, 06:08:15 pm
So, getKeyr returns the same values as Key Values → Direct Input in Calcsys?  cool
Title: Re: Axe Parser
Post by: ztrumpet on March 27, 2011, 06:36:18 pm
Ah ok, nice for the update. Does Direct input remain the same if we want to use it normally?

Btw, was requiring 6 MHz mode for DispGraph intentional? Runer112 pointed this out on IRC.
Yes, it originally was.
Title: Re: Axe Parser
Post by: Deep Toaster on March 27, 2011, 08:18:12 pm
So, getKeyr returns the same values as Key Values → Direct Input in Calcsys?  cool

Nope, that was getKey(#). It now does the same thing as Key Values > 1. GetKey :)
Title: Re: Axe Parser
Post by: Darl181 on March 27, 2011, 08:36:25 pm
Oh, so BASIC getkey?
Title: Re: Axe Parser
Post by: Deep Toaster on March 27, 2011, 09:07:01 pm
Oh, so BASIC getkey?

Nope. It's more like what the OS uses -- press 2ND, then MATH, and it'll register as TEST (51).
Title: Re: Axe Parser
Post by: Quigibo on May 09, 2011, 11:36:35 pm
I'm planning a major feature addition soon which I am dubbing "Axsembly" (Please excuse my lack of creativity with portmanteaus :P).

Basically, it will allow direct assembly commands to be integrated directly into Axe... but while keeping the syntax looking almost exactly like regular Axe.  I will be using the lowercase letters for the registers and will allow a wide range of arithmetic instructions.  The major difference with Normal Axe syntax is that assignments are done with the equal sign instead of the store arrow (like in most programming languages) and only a limited range of instructions are allowed.  Both of these are to make Parsing on my side possible.  Everything else is basically the same as you're used to already.  There will also be a simple interface to transfer an Axe variable into a register for manipulation and then bring it back up.

For instance, the instruction "a=a+a" or "a=a*2" will both translate to the assembly instruction "add a,a".  However, "a=a*3" does not correspond to a single instruction, and therefore must be made by hand using 3 instructions like "b=a : a=a*2 : a=a+b".  There will also be some new operators like ++ which acts as an "inc" when used in a unary operation or an "add with carry" in a binary operation.  Different kinds of rotation will also be supported.  All these commands can be interwoven with current syntax, but I wouldn't rely on abusing the side effects because they can change from version to version.

This does have one conflict with Axe's current syntax however: The binary number prefix which is currently "b" will have to be changed to something else, but I think that command is used infrequently enough to not anger anyone who would be affected by this change.

I am hoping this will be a great introduction to assembly for new programmers who want to play around with it while staying in Axe's feature-rich environment.  This was a feature I was panning to add at the beginning, but then gave up, but just now thought of a way I could do it efficiently.
Title: Re: Axe Parser
Post by: Michael_Lee on May 09, 2011, 11:42:11 pm
So basically, is this equivalent to inserting hex into the program, except easier to read?
Title: Re: Axe Parser
Post by: Runer112 on May 09, 2011, 11:44:56 pm
This sounds pretty awesome, although I am a little worried that this will make programming in Axe less "authentic," if you know what I mean. Although I do see the merits as well. But is it even necessary to change the b prefix for binary to something else? When parsing, if the b is followed by a 1 or 0, treat it as an indicator of binary data. Otherwise, treat it as the b register.
Title: Re: Axe Parser
Post by: Freyaday on May 09, 2011, 11:45:12 pm
Wait--Axe now has side effects? O.o
Title: Re: Axe Parser
Post by: Quigibo on May 09, 2011, 11:53:39 pm
This sounds pretty awesome, although I am a little worried that this will make programming in Axe less "authentic," if you know what I mean. Although I do see the merits as well. But is it even necessary to change the b prefix for binary to something else? When parsing, if the b is followed by a 1 or 0, treat it as an indicator of binary data. Otherwise, treat it as the b register.
That's true, I guess I could do that.

Axe itself doesn't have side effects, but at the assembly level, the registers change around every time Axe does a native command.  Sometimes you can use these values for optimization.  Like if you knew the b register was always 0 after a Pt-On() for instance, you could use this knowledge to save some bytes.  However, I am simply warning against this because I could change the built-in routines at any time and an optimization like that might not work anymore.
Title: Re: Axe Parser
Post by: Hot_Dog on May 10, 2011, 11:53:30 am
Will Axe create ASM programs even if the programs turn out to exceed 8 KBs? 
Title: Re: Axe Parser
Post by: Builderboy on May 10, 2011, 03:38:05 pm
It will
Title: Re: Axe Parser
Post by: ztrumpet on May 10, 2011, 04:37:21 pm
Axsembly sounds pretty cool.  Good luck getting it to run smoothly. :)
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 11, 2011, 02:43:26 pm
That sounds nice, but then for the contest somebody will have to help me judging entries, because I haven't coded Axe in almost one year and I'll need to scan every entry to make sure only a certain percentage of Asm() and your new ASM feature is used, and sadly I might not make the difference between Axsembly stuff and regular Axe code. ;D
Title: Re: Axe Parser
Post by: ikemike on May 18, 2011, 08:13:54 pm
Can somebody take a look at this code and see why everything up to "rand ^999→Q" repeats itself?
Code: [Select]
.KBYCRACK Crackity Hack!

prgmDEFINE
DiagnosticOff
sub(RCL)
sub(SSP,3,35,Pic1)
sub(SSP,25,30,Pic2)
sub(SSP,47,30,Pic3)
sub(SSP,69,35,Pic4)
sub(SSP,3,48,Pic5)
sub(SSP,25,43,Pic5)
sub(SSP,47,43,Pic8)
sub(SSP,69,48,Pic8)
sub(SET)
Repeat getKey(54)
DispGraph
End
sub(W)
0→T→P
Repeat T=4
40→X
1→A
Repeat getKey(54) or (X=40 and (A=2))
If A=1
Line(2,X/2+2,4,X/2+2)
ElseIf A=2
ref(2,X/2+2,3,1)
rref(2,X/2+2,3,1)
End
DispGraph
If X=0:2→A:End
If A=1:X-1→X:End
If A=2:X+1→X:End
End
If getKey(54)
sub(W)
40-X→X
X*X*X/371+P→P
Else
sub(W)
End
T+1→T
sub(SET)
End
20→X
Repeat getKey(54) or (X=100)
sub(RCL)
sub(FSP,5,30,Pic63)
sub(FSP,5,X/2,Pic6)
X+1→X
DispGraph
End
20-abs(60-X)→X
If X<0:0→X:End
X*X*31/40+P→P
sub(W)
conj(Pic01,L₃,768)
conj(Pic02,L₆,768)
sub(Q)
ClrDraw
sub(Q)
ClrDraw
sub(W)
rand ^999→Q
rand ^999→R
rand ^999→S
If P>999:999→P:End
P→Z
If Q>Z
Q→Z
ElseIf R>Z
R→Z
ElseIf S>Z
S→Z
End
0→X→Y
Fix 5
Repeat Z=X
If P≥X:sub(TSP,4,40,Pic7+Y):End
If Q≥X:sub(TSP,26,40,Pic7+Y):End
If R≥X:sub(TSP,48,40,Pic7+Y):End
If S≥X:sub(TSP,70,40,Pic7+Y):End
If Y=0
32→Y
Else
0→Y
End
Vertical -
Vertical -
Vertical -
ref(0,48,96,10)
rref(0,48,96,10)
If X≤P:Text(4,55,XDec):End
If X≤Q:Text(26,55,XDec):End
If X≤R:Text(48,55,XDec):End
If X≤S:Text(70,55,XDec):End
If X>P:Text(4,55,PDec):End
If X>Q:Text(26,55,QDec):End
If X>R:Text(48,55,RDec):End
If X>S:Text(70,55,SDec):End
If X<(Z-25)
X+10→X
ElseIf X<(Z-10)
X+1→X
Pause 100
Else
X+1→X
Pause 200
End
DispGraph
End
DispGraph
Return


Lbl Q
0→A
Repeat A=8
DispGraph
Horizontal +
Horizontal +
Horizontal +
Horizontal +
Vertical +
Vertical +
Vertical +
Vertical +
DispGraph
Horizontal -
Horizontal -
Horizontal -
Horizontal -
Vertical -
Vertical -
Vertical -
Vertical -
A+1→A
End
Return

Lbl SET
ref(1,1,5,22)
ref(1,1,5,22)
rref(2,2,3,20)
rref(2,2,3,20)
Return

Lbl W
0→A
Repeat A=40
DispGraph
A+1→A
End
Return

Lbl TSP
Plot1(r₁,r₂,r₃)
Plot1(r₁+8,r₂,r₃+16)
Return

Lbl FSP
Plot1(r₁,r₂,r₃)
Plot1(r₁+8,r₂,r₃+16)
Plot1(r₁,r₂+8,r₃+32)
Plot1(r₁+8,r₂+8,r₃+48)
Return

Lbl SSP
Plot1(r₁,r₂,r₃)
Plot1(r₁+8,r₂,r₃+16)
Plot1(r₁+16,r₂,r₃+32)
Plot1(r₁,r₂+8,r₃+48)
Plot1(r₁+8,r₂+8,r₃+64)
Plot1(r₁+16,r₂+8,r₃+80)
Return

Lbl RCL
conj(Pic0,L₃,768)
conj(Pic00,L₆,768)
Return
Title: Re: Axe Parser
Post by: calc84maniac on May 18, 2011, 08:24:25 pm
I don't know about your problem, but I do have an optimization:
Code: [Select]
If X≤P:Text(4,55,XDec):End
If X≤Q:Text(26,55,XDec):End
If X≤R:Text(48,55,XDec):End
If X≤S:Text(70,55,XDec):End
If X>P:Text(4,55,PDec):End
If X>Q:Text(26,55,QDec):End
If X>R:Text(48,55,RDec):End
If X>S:Text(70,55,SDec):End
becomes
Code: [Select]
Text(4,55,min(X,P)Dec)
Text(26,55,min(X,Q)Dec)
Text(48,55,min(X,R)Dec)
Text(70,55,min(X,S)Dec)
Title: Re: Axe Parser
Post by: ralphdspam on May 18, 2011, 10:52:37 pm
That sounds nice, but then for the contest somebody will have to help me judging entries, because I haven't coded Axe in almost one year and I'll need to scan every entry to make sure only a certain percentage of Asm() and your new ASM feature is used, and sadly I might not make the difference between Axsembly stuff and regular Axe code. ;D

So, if there are ASM commands, will they count as an Axe command?  Hehe >:D
Title: Re: Axe Parser
Post by: Deep Toaster on May 19, 2011, 11:09:07 am
2: ASM code must not compose more than 10% of your program code and the only allowed way to use assembly is via the Asm() command. The remaining 90% must be Axe or Axiom code. (See previous rule for Axiom information). Other languages such as TI-BASIC are NOT allowed.

Taken care of already :)
Title: Re: Axe Parser
Post by: Quigibo on May 22, 2011, 11:27:05 pm
Hmm... the problem with the new constants runs deeper than I thought.  The normal static pointers optimize with the assumption they will eventually be replaced by a value within the normal pointer range during the second pass since their actual value is unknown during the first pass.  Constants on the other hand ARE known on the first pass and this replacement model doesn't work in that case since the value is never updated during the next pass.  Therefore, this requires me to modify some very core routines.

So because I'll be rewriting this part anyway, I might finally add a request from a while ago which was to allow static variables to be used before they're defined.  So you can put data at the end of your program instead of only the beginning.  This has some drawbacks however:  First, it will be harder to debug errors.  Since the compiler won't know if a symbol is defined until the end of the source, it would not be able to scroll to the specific place it was used and would instead have to just display "Missing: Str1A" for example, just like labels.  Secondly, it uses up an extra symbol in the symbol table for each use until its finally defined.  As an example of this, here is the symbol count for this program:

Code: [Select]
:.TEST
:Str1       ;1 Symbol
:Str1       ;2 Symbols
:Str1       ;3 Symbols
:"H"->Str1  ;Now defined, so 1 symbol from now on
:Str1       ;1 Symbol
:Str1       ;1 Symbol
:Str1       ;1 Symbol

I'm guessing this will result in a lot of "MAX SYMBOLS" errors if people start using this too much since you only get 153 symbols to use.  What are everyone's thoughts about this?  Is it worth the extra effort?  I feel like most people who would use this would want to use it on large programs in which case they would probably run out of symbols anyway and be forced to move them back on top, which is a very annoying process.
Title: Re: Axe Parser
Post by: Runer112 on May 22, 2011, 11:29:08 pm
I personally vote for another pass. That would solve the problem, wouldn't it? For me, even massive programs still compile in only a few seconds. I think giving up an additional second or two would be acceptable to allow for more free program structure.
Title: Re: Axe Parser
Post by: Binder News on May 22, 2011, 11:33:36 pm
I would love this feature. Great for smaller programs.
Runner, I like your idea even better.
Also, a request: a way to optimize for constants for axioms.
What I mean is, the same token could be used, but instead of having a jump table at the beginning of axiom code, add an extra field in the Axiom header that allows for different variants of the code to be used depending on which constant is specified. The Fix command would be perfect for this.
Title: Re: Axe Parser
Post by: ztrumpet on May 23, 2011, 08:42:08 am
I like Runer's suggestion the best.  I think having a three pass system is the way to go.
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 25, 2011, 04:24:21 am
Another pass would be nice. The only issue that can arise is if someone compiles a massive program like the Hero of Might and Magic game from last year's contest on a regular 83+ (which had like 100 programs and took almost 1 minute to compile)
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2011, 05:04:10 am
On the subject of passes, I could also have a 4th pass to relocate all the data after the builtin subroutines to allow shell compatible programs to break the 8kb executable limit more easily.
Title: Re: Axe Parser
Post by: Runer112 on May 25, 2011, 11:22:27 am
That would be pretty awesome too. I'm always a fan of more features at the cost of being a little slower.
Title: Re: Axe Parser
Post by: Builderboy on May 25, 2011, 11:24:36 am
Perhaps an optional 4th pass for those of us that like to squeeze every bit of speed from everything we encounter?
Title: Re: Axe Parser
Post by: aeTIos on May 25, 2011, 01:13:41 pm
Another suggestion: To cut the size of programs, perhaps use the shell routines? (You can for example always use ion routines when compiling for shell)
Title: Re: Axe Parser
Post by: ztrumpet on May 25, 2011, 03:45:48 pm
Perhaps an optional 4th pass for those of us that like to squeeze every bit of speed from everything we encounter?
I think that's a great idea.  I vote for three passes with an optional 4th.
Title: Re: Axe Parser
Post by: Deep Toaster on May 25, 2011, 11:28:14 pm
If Axe adds more passes, can we also have a hotkey to break compiling at any point? I think that would be useful a lot.
Title: Re: Axe Parser
Post by: Quigibo on May 25, 2011, 11:38:12 pm
It would be too difficult to make passes optional because that stuff is hard coded.  The break key is a great idea though, I think I will make the [On] key break compiling and clean up unfinished files so that if you accidentally compile a huge program for the wrong shell or something, you don't have to wait a minute for it to compile just to delete it and compile again.
Title: Re: Axe Parser
Post by: Runer112 on May 25, 2011, 11:48:29 pm
I don't quite understand why it would be hard to make passes optional. Could you make normal parsing the 4-pass system that moves data to the end? But if this option is turned off, start parsing with a pass outside the normal 4-pass system that acts like the first two passes combined and then resumes with/jumps to the final two passes as usual? This "fifth" pass would probably share a lot of redundant code with the first two passes, but you're not exactly tight on space in the application, are you?
Title: Re: Axe Parser
Post by: leafy on May 25, 2011, 11:58:43 pm
I'm in favor of that fourth pass. For me, size is everything ><
Title: Re: Axe Parser
Post by: DJ Omnimaga on May 26, 2011, 01:23:30 am
That 4th pass idea sounds good to me. :)
Title: Re: Axe Parser
Post by: Michael_Lee on May 26, 2011, 01:30:45 am
I like the 4th pass idea.
An additional second or two (or ten, for that matter) wouldn't really matter to me if it meant that I would get an uber-compressed/speedy program.
Title: Re: Axe Parser
Post by: Freyaday on May 26, 2011, 10:44:24 am
/me likes the idea of smaller Axe programs
Another one for the Fourth pass, then.
Title: Re: Axe Parser
Post by: Builderboy on May 26, 2011, 11:07:09 am
The fourth pass would not actually reduce the size of programs, nor would it make them faster.  The *only* thing it would do is move all the data to the end of the program so you get a little more edge when compiling for Shell, and you are almost at the size limit
Title: Re: Axe Parser
Post by: Freyaday on May 26, 2011, 11:14:16 am
Aww. But would it be possible to have a pass that goes back and optimizes the code?
Title: Re: Axe Parser
Post by: Builderboy on May 26, 2011, 11:19:28 am
Not anymore than it already does i don't think
Title: Re: Axe Parser
Post by: Quigibo on May 26, 2011, 04:20:15 pm
It would also allow me to give a compile error now when you go over the limit.  Currently I can't do that because I don't know how much is data and how much is code.
Title: Re: Axe Parser
Post by: ztrumpet on May 26, 2011, 04:25:19 pm
It would also allow me to give a compile error now when you go over the limit.  Currently I can't do that because I don't know how much is data and how much is code.
Nice!  I really want that. ^-^
Title: Re: Axe Parser
Post by: Deep Toaster on May 27, 2011, 10:05:51 am
The fourth pass would not actually reduce the size of programs, nor would it make them faster.  The *only* thing it would do is move all the data to the end of the program so you get a little more edge when compiling for Shell, and you are almost at the size limit

In that case I do support it :D
Title: Re: Axe Parser
Post by: aeTIos on May 27, 2011, 10:08:44 am
I support the 4th pass.
Title: Re: Axe Parser
Post by: JustCause on May 27, 2011, 10:09:25 am
I support the 4th pass.
^^. I can think of about a hundred ways that would help me.
Title: Re: Axe Parser
Post by: calc84maniac on May 27, 2011, 10:11:39 am
4th pass gogogo!(go)
Title: Re: Axe Parser
Post by: aeTIos on May 27, 2011, 10:11:43 am
Did anyone see my suggestion for using shell routines? If you compile for a shell, you can for example use iputsprite instead of pxl-change and ifastcopy instead of DispGraph, which will cut the size of programs a lot.
Title: Re: Axe Parser
Post by: Runer112 on May 27, 2011, 10:12:48 am
Axe's routines are all custom made and different from shell routines, so it couldn't use them.
Title: Re: Axe Parser
Post by: aeTIos on May 27, 2011, 10:13:16 am
awww. Thats too bad.
Title: Re: Axe Parser
Post by: Compynerd255 on May 27, 2011, 10:25:55 am
I second (or fifth, or whatever) the extra passes. Anything to increase program efficiency. Anyway, in Axe's current form, the second pass is faster than the first.

I know that most of the Axe routines are incompatible with the shell routines, but some of them are not. Because DispGraph is simply Ion's FastCopy, then DispGraph should simple be a CALL iFastCopy when compiling for a shell. I don't know how useful this would be for other commands, however.
Title: Re: Axe Parser
Post by: aeTIos on May 27, 2011, 10:27:18 am
Runer said that Axe's routines are not compatible plus they are better. I conclude that I'm fine with axe's routines as it is now.
Title: Re: Axe Parser
Post by: Runer112 on May 27, 2011, 10:32:16 am
Axe's FastCopy is very different from Ion's FastCopy:


I could give you a similar list for every other command shared between Axe and Ion.
Title: Re: Axe Parser
Post by: Compynerd255 on May 27, 2011, 10:36:27 am
That's really true.
Title: Re: Axe Parser
Post by: Quigibo on May 27, 2011, 02:42:58 pm
Axe actually did use shell routines for at least one version.  The only one I could find to be "compatible enough" was ion's pixel drawing routine.  But it was significantly slower than my own routine so I took it out.  My original vision for Axe was that I would be able to use shell routines to significantly reduce code size and it would be happy and magical.  Unfortunately I never realized how specialized and super optimized Axe's routines are compared to the shell calls so that kind of died out pretty quickly.  Runer's comparison of Axe's fastcopy with Ion's fastcopy is a good example of how many of the shell routines went when I tried to add them.
Title: Re: Axe Parser
Post by: ztrumpet on May 27, 2011, 05:49:06 pm
I remember back when that happened.  Wasn't it back around the introduction of Axioms?
Title: Re: Axe Parser
Post by: Munchor on May 28, 2011, 06:26:45 am
YAY Axe Parser 0.5.3 (http://ourl.ca/4060/213904) is out :D
Title: Re: Axe Parser
Post by: Deep Toaster on May 28, 2011, 11:18:33 am
YAY Axe Parser 0.5.3 (http://ourl.ca/4060/213904) is out :D

Don't use it yet: http://ourl.ca/4072/213957 :(
Title: Re: Axe Parser
Post by: Runer112 on May 28, 2011, 11:21:17 am
As long as you don't use division or flipH(), you should probably be fine. But since I know a lot of people are programming physics platformers that could definitely use either of these, they should probably wait.
Title: Re: Axe Parser
Post by: Munchor on May 28, 2011, 03:23:29 pm
Well, my program which uses a few /256 is fine, but oh wait 16/16 Division, so it's not a problem, most of mine are 8/16. Still bad, I really hope the next version is 1.0.0 bugless :D
Title: Re: Axe Parser
Post by: Freyaday on May 28, 2011, 07:30:51 pm
Has Quigibo fixed those bugs yet?
Title: Re: Axe Parser
Post by: Quigibo on May 28, 2011, 08:01:16 pm
I re-uploaded a fixed version so you won't have to wait until 1.0.0 :)
Title: Re: Axe Parser
Post by: Freyaday on May 28, 2011, 08:30:06 pm
Does signed division work now?
Title: Re: Axe Parser
Post by: Quigibo on June 01, 2011, 06:07:16 am
^ Yes.

Since someone brought up shells recently, it really got me thinking... what if I created another compile option for an "Axe Shell" that calls all the built-in subroutines from the parser itself instead of copying them into the program?  I'd estimate this would save about a kilobyte in an 8kb program, ~12% decrease in size, while having the speed remain the same.  In fact, I could optimize some routines more for speed instead of size since the size wouldn't matter, so some routines like multiplication and division could be significantly faster.  Yes, this would mean you need the Axe application to run the program if you compile for that option, but for people struggling with the 8kb limit or 3D math speed, it could be a life saver.

But then I realized this would basically involve me writing an entire shell or else you wouldn't have a way to actually run the programs.  Either that, or I'd have to have a home screen parser hook like DCS has.  This is possible, but difficult I think since so many other programs use it and I don't want to cause too many conflicts with the hook chaining.

So that gave me another idea.  Since I 'd like to avoid making a shell from scratch, what if I could get these features built into an already existing popular shell?  So I'm thinking of talking to Kerm about it, I'm not sure how much space is left in DCS so I can't say for sure if this is possible, I think all the axe subroutines combined are under 3KB together.  But anyway, is this something you guys thing I should invest time in, regardless of if it ends up in a new Axe Shell or DCS?  It could makes shells more useful than just the extra header.
Title: Re: Axe Parser
Post by: TIfanx1999 on June 01, 2011, 09:55:08 am
I think the Axe Shell is a wonderful idea! =) A standalone Axe shell would be pretty nice IMHO.
Title: Re: Axe Parser
Post by: JosJuice on June 01, 2011, 10:43:54 am
So I'm thinking of talking to Kerm about it, I'm not sure how much space is left in DCS so I can't say for sure if this is possible, I think all the axe subroutines combined are under 3KB together.
There isn't much space. I think he has a few hundred bytes on every page, or less.
But anyway, is this something you guys thing I should invest time in, regardless of if it ends up in a new Axe Shell or DCS?  It could makes shells more useful than just the extra header.
Definitely. It sounds like a great idea. :)
Title: Re: Axe Parser
Post by: Freyaday on June 01, 2011, 04:48:43 pm
Yeah, that would be awesome, especially for when we need the speed instead of size.
Title: Re: Axe Parser
Post by: ztrumpet on June 01, 2011, 04:54:07 pm
That would be awesome!  If you end up doing it, you could talk some to ThePenguin, who has experience with (ab)using Doors's routines without even running the program from Doors itself. :D
Title: Re: Axe Parser
Post by: yoman82 on June 02, 2011, 12:57:05 pm
I would love that. Poll-worthy?
Title: Re: Axe Parser
Post by: Quigibo on June 09, 2011, 06:28:40 pm
I have a little conundrum.  As soon as I allow forward referencing of constants, there is immediately going to be a problem with auto-optimizations.  If the constant value is unknown when it gets to a routine that can auto-optimize (lets say for this example multiplication), it won't know which optimization to do because it doesn't know if its *2, *3, *4, etc.  All it can assume is that its some constant.  I can't just skip over this and come back later when the value is known because each auto-opt is a different size and parsing cannot continue unless the future addresses are correct.  So in this case, it would have to assume the worst case and always use the multiplication subroutine, regardless of the value.

This is avoided simply by declaring a constant BEFORE you use it instead of after, but its noteworthy.  I've already been doing this with pointers but you don't notice because pointers have values like "$9EF0" for instance so those never auto-optimize anyway and you never use them in math other than addition and subtraction.  I'm stumped to think of a way around this though, anyone have any ideas?  I suppose its not too big of a deal either way.
Title: Re: Axe Parser
Post by: Runer112 on June 09, 2011, 07:01:16 pm
You could add a first pass for the sole purpose of finding user-defined constants. Not a terribly elegant solution, but it would work. 
Title: Re: Axe Parser
Post by: lookitsan00b on June 09, 2011, 07:11:29 pm
You could add a first pass for the sole purpose of finding user-defined constants. Not a terribly elegant solution, but it would work.
That'd be the easiest way around it, but at the cost of compiling speed.

However, usually its bad practice using a constant before you define it anyways, so it shouldn't be much of a problem.

So, basically, its either a stricter (but still extremely intuitive) syntax (at a penalty of everything before the define not getting optimized), or a slower (less elegant) compile-time.

I vote for stricter syntax, even though I wouldn't care if it took longer to compile.
Title: Re: Axe Parser
Post by: Quigibo on June 09, 2011, 07:17:11 pm
Yeah, I was thinking about that, but it could take an infinite amount of passes to resolve the constants, like:

oB->oC
oA->oB
5->oA


The first pass can assign A, and B the second pass, but C would not be identified then.  I'm going to have to re-think a lot of this actually and figure out some rules that will make this easy to implement... probably something like the above example would be illegal.  Perhaps I will make a rule like you cannot store to a static unless everything on the left hand side is declared already.
Title: Re: Axe Parser
Post by: ztrumpet on June 09, 2011, 07:45:48 pm
Perhaps I will make a rule like you cannot store to a static unless everything on the left hand side is declared already.
I think that's the way to do it. :)
Title: Re: Axe Parser
Post by: Quigibo on June 09, 2011, 07:55:32 pm
That includes sprites too though.  You can't do:

Pic1+8->Pic2
Pt-On(0,0,Pic2)
[]->Pic1


However, you could do:

Pt-On(0,0,Pic2)
[]->Pic1
Pic1+8->Pic2


And you can always declare the sprite first like Axe has been doing so far:

[]->Pic1
Pic1+8->Pic2
Pt-On(0,0,Pic2)
Title: Re: Axe Parser
Post by: Freyaday on June 10, 2011, 12:07:41 am
I vote for declaring what it is before using it.
Title: Re: Axe Parser
Post by: Compynerd255 on June 10, 2011, 10:49:21 am
I think that you should just define it before you use it. That's the best solution for calc. There isn't a reason why you would extract the defines into a seperate program, except that it wouldn't get backed up.

The reason why they would put the defines at the bottom is because they don't want to scroll through them. So, I think that we need to do one of these two things:
- Allow jumping to a label/define when editing, so you don't have to scroll through the data or preliminary code.
- Create an alternate version of the editor with code folding. In code folding, you look for all of the definite code blocks (If-End, While-End, Lbl-Return, etc) and let people use a key to hide them, replacing them with a little plus thing. They can then press a key again to expand the block again.
Title: Re: Axe Parser
Post by: Quigibo on June 14, 2011, 11:51:29 pm
Just wanted to give everyone a quick update on progress.

This is day 6 of the rewrite.  I can now parse simple programs and have data, labels, variables, and gotos working correctly.  Though I still need to rewrite subs, interrupts, internal subroutines, and axioms.  So currently, I cannot compile any large programs, but I'm almost at the point where I can.  There is at least one extra MAJOR convenience feature that was requested a long time ago that will finally make it to the update, but I won't spoil what it is yet. ;) I still have no idea when it'll be finished because of all the inevitable unexpected issues to come, but hopefully before the end of the month.
Title: Re: Axe Parser
Post by: Deep Toaster on June 14, 2011, 11:57:36 pm
Whoa, this is a huge rewrite... You might as well call it 2.0 O.O
Title: Re: Axe Parser
Post by: Freyaday on June 15, 2011, 01:15:22 am
Whoo, awesomesauce Quigibo!
Does this mean we can use this awesomeness in the contest?
Title: Re: Axe Parser
Post by: TIfanx1999 on June 15, 2011, 11:18:19 am
Just wanted to give everyone a quick update on progress.

This is day 6 of the rewrite.  I can now parse simple programs and have data, labels, variables, and gotos working correctly.  Though I still need to rewrite subs, interrupts, internal subroutines, and axioms.  So currently, I cannot compile any large programs, but I'm almost at the point where I can.  There is at least one extra MAJOR convenience feature that was requested a long time ago that will finally make it to the update, but I won't spoil what it is yet. ;) I still have no idea when it'll be finished because of all the inevitable unexpected issues to come, but hopefully before the end of the month.

That sounds great! Some of you guys really are coding BEASTS =)
Title: Re: Axe Parser
Post by: aeTIos on June 15, 2011, 11:20:10 am
Just wanted to give everyone a quick update on progress.

This is day 6 of the rewrite.  I can now parse simple programs and have data, labels, variables, and gotos working correctly.  Though I still need to rewrite subs, interrupts, internal subroutines, and axioms.  So currently, I cannot compile any large programs, but I'm almost at the point where I can.  There is at least one extra MAJOR convenience feature that was requested a long time ago that will finally make it to the update, but I won't spoil what it is yet. ;) I still have no idea when it'll be finished because of all the inevitable unexpected issues to come, but hopefully before the end of the month.
Wow... You're doing a FULL rewrite?
Also the request... Im curious. you should say it I cant wait waaahh D:
Title: Re: Axe Parser
Post by: Quigibo on June 16, 2011, 06:29:46 am
Yay!  I can finally parse STARSHIP and have it work.  I still need to fix a bunch of miscellaneous things though.

Since I'm rewriting the engine anyway, I figured I might also want to add another feature to the auto-optimizer, something called "Peephole Optimization".  The way it works is basically every time the parser writes an inline instruction, it will scan upwards several bytes and see if the code matches a list of patterns.  If it does, it will replace the code with the more optimized version and then continue writing.  If this works, then its possible Axe programs can get EXTREME :o optimizations approaching that of a moderate z80 coder. It could result in up to a 5-10% decrease in code size plus a small speed boost!

I am going to try to make these open source like I have been doing with the commands so that others can help me with them, hopefully I can find a good system for it.  This is all speculation though, I'm not sure if I'll have time or add it at all if it gets too complex, but I'm hoping it can work.  This could also render a lot of those weird Axe tricks obsolete since they would happen automatically, like 0->A:0->B could automatically optimize to 0->A->B.
Title: Re: Axe Parser
Post by: aeTIos on June 16, 2011, 06:38:46 am
YAAY! Great work. Keep it up! :w00t: :w00t:
Title: Re: Axe Parser
Post by: Freyaday on June 16, 2011, 06:40:51 am
Oh wow, Quigibo, sounds fantastic.
Title: Re: Axe Parser
Post by: aeTIos on June 16, 2011, 06:43:23 am
BTW, would it have a big impact on the speed? (You could make an option to toggle between the new and the old way to parse)
Title: Re: Axe Parser
Post by: Quigibo on June 16, 2011, 06:49:51 am
So far, its the same speed.  However, after the first pass, there is a short but noticeable pause as it writes all the used subroutines to the current end of the program so that data is always after any code during the 2nd pass.  I don't think the peephole ops would cause a significant slowdown either, probably unnoticeable.
Title: Re: Axe Parser
Post by: aeTIos on June 16, 2011, 07:44:57 am
cool. WOW. I just noticed that you expect the next release be 1.0.0 in 2 weeks!? O.O EPIC!
Title: Re: Axe Parser
Post by: yrinfish on June 16, 2011, 08:17:22 am
WOW WOW WOW constants! peephole ops!

Great! I am SOOOO happy!!

Does it still fit?
Title: Re: Axe Parser
Post by: aeTIos on June 16, 2011, 08:18:09 am
? In the app spaces? Yeah, he mentioned that he has plenty of room left in the second page.
Title: Re: Axe Parser
Post by: yrinfish on June 16, 2011, 08:23:20 am
yes, I meant that!! Did it already take up two pages?
Title: Re: Axe Parser
Post by: aeTIos on June 16, 2011, 08:24:40 am
Yes. it was 32768 bytes already. check via 2nd>+>2>Alpha>A.
Title: Re: Axe Parser
Post by: yrinfish on June 16, 2011, 08:29:51 am
Ok, niiice. Thanks!
Title: Re: Axe Parser
Post by: Hot_Dog on June 28, 2011, 02:27:32 pm
So by prerelease, Quigibo, do you mean something like a preview release?
Title: Re: Axe Parser
Post by: Quigibo on June 28, 2011, 03:34:49 pm
I mean I will release it to a few people just to get rid of any obvious bugs I missed and then release it publicly a few days later.  This is only because I want this version super bug free and I still need more time to update the rest of the documentation.  My change-log list for this version is nearly a page now and about 50% of the core routines got rewrites so that makes me nervous to release right away.
Title: Re: Axe Parser
Post by: JustCause on June 29, 2011, 01:33:28 am
I think I speak for everyone when I say I. Want. This. Quigibo, you're just...is there a stronger version of the word "awesome?"
Title: Re: Axe Parser
Post by: Quigibo on July 01, 2011, 07:32:48 pm
I am thinking of making another somewhat major change.

I'd like to change the colon ":" to an inline separator rather than an end of line separator.  That doesn't sound like a big change, but it is if you use the colon and don't close your parenthesis.  For instance, currently "sin(B→C:A" parses as "sin(B→C):A".  But by making the colon an inline operator, it would instead translate to "sin(B→C:A)" which I think is more useful and intuitive.  If you've been closing your parenthesis like you should be, then there won't be any ambiguity so this would only affect those that don't close them regularly.  The reason for this is that currently there is no way to separate expressions within a single line (something you can parenthesize).  Spaces used to work because you could do "(A→C B→A C→B)".  However, this now translates to "(A→CB→AC→B)" since multi-lettered variables are now valid.  Spaces are not supposed to contribute to syntax so I wouldn't want to abuse them like that anyway.

Thoughts or complaints?
Title: Re: Axe Parser
Post by: Runer112 on July 01, 2011, 08:05:03 pm
I rarely use the colon as an inline separator, and when I do, it's usually just to chain basic things like Fix 1:Fix 5. And I always make sure to close my parentheses. So this change would be fine with me.
Title: Re: Axe Parser
Post by: Quigibo on July 01, 2011, 08:12:19 pm
Yeah, I realize its not needed much now, but its going to become VERY necessary for another feature I'm adding:  ;D

Spoiler For Spoiler:
WARNING: Awesomeness may cause explosion of brain.  Do not click further!
Spoiler For Spoiler:
Last chance, you've been warned!
Spoiler For Spoiler:
I'm serious now!
Spoiler For Spoiler:
*.* *.* *.*Lambdas!!!!*.* *.* *.*
Title: Re: Axe Parser
Post by: XVicarious on July 01, 2011, 08:56:00 pm
WHY!? WHY DO YOU PLAY US LIEK THAT!?
Title: Re: Axe Parser
Post by: Ashbad on July 01, 2011, 09:04:41 pm
Awesome, Lambdas!  :D in what syntactical form will they be implemented?  Can I haz example in code?
Title: Re: Axe Parser
Post by: Darl181 on July 01, 2011, 09:50:01 pm
...and what are lambdas? :P
Title: Re: Axe Parser
Post by: calcdude84se on July 02, 2011, 01:02:39 pm
Λ - uppercase lambda
λ - lowercase lambda
:P
More seriously, Ashbad's referring to inline functions, I presume, which probably aren't going to happen.
Title: Re: Axe Parser
Post by: Ashbad on July 02, 2011, 01:07:12 pm
More seriously, Ashbad's referring to inline functions, I presume, which probably aren't going to happen.

Quigibo just said they were gonna happen, so I assume they are :P
Title: Re: Axe Parser
Post by: calcdude84se on July 02, 2011, 01:25:10 pm
Oh, so he did. I couldn't see it in the 1pt font :P My bad.
I'm wondering what their use would be though... It seems to me that it would be more flexible to allow retrieving the address of a label.
Part of the thing with anonymous functions is that you need a syntax to invoke them. Since they would presumably be passed as pointers, does that mean we're finally getting a dynamic call and jump?
Title: Re: Axe Parser
Post by: Quigibo on July 02, 2011, 02:18:38 pm
Let just say that all this speculation is for me to have already implemented and you to find out, but I can assure you its quite sugary syntactically ;) The entire language standards have changed, but its still almost completely reverse compatible.

I'm almost done, I can feel it!  I Only have about 5 items left on my TODO list out of about 40 new features.
Title: Re: Axe Parser
Post by: XVicarious on July 02, 2011, 02:20:28 pm
nice quigibo! can't wait. like i really can't hurry up :P
Title: Re: Axe Parser
Post by: Deep Toaster on July 02, 2011, 06:02:17 pm
I like that idea. It would make this new "scope" stuff easier to deal with.
Title: Re: Axe Parser
Post by: DJ Omnimaga on July 05, 2011, 01:45:06 am
This is amazing to see Axe being finished and so close to it now. It has come a long way. Awesome job Quig.
Title: Re: Axe Parser
Post by: Quigibo on July 05, 2011, 01:50:45 am
I don't think it will ever be "Finished".  Its going to stay alive for a long time, the 1.0.0 will just be the largest, most improved, programming-style changing update to date.  If I ever fear the Parser is starting to die due to real life stuff or boredom of working on the same project for so long, I will definitely pass it on to another programmer to continue, I wouldn't leave you guys hanging. :)
Title: Re: Axe Parser
Post by: Freyaday on July 05, 2011, 04:45:20 am
/me hugs Quigibo
Title: Re: Axe Parser
Post by: samebull (metagross111) on July 05, 2011, 07:43:21 am
Yeah, I realize its not needed much now, but its going to become VERY necessary for another feature I'm adding:  ;D

Spoiler For Spoiler:
WARNING: Awesomeness may cause explosion of brain.  Do not click further!
Spoiler For Spoiler:
Last chance, you've been warned!
Spoiler For Spoiler:
I'm serious now!
Spoiler For Spoiler:
*.* *.* *.*Lambdas!!!!*.* *.* *.*

Thanks. I turned off image blocking just to see that. I thought it was some sweet feature. Real freakin' mature of you. Try a seizure warning instead.
Title: Re: Axe Parser
Post by: TIfanx1999 on July 05, 2011, 08:05:15 am
Actually it is listed there in small font. It said lambdas. Which was also mentioned by other posters on this page of this thread. I'm not even sure why you thought it would be necessary to turn off image blocker anyway, you can click through the spoilers and still read what it says without even messing with image blocker.

*edit*: Ok, it gives alternate text with image blocker on... how strange.
Title: Re: Axe Parser
Post by: samebull (metagross111) on July 05, 2011, 08:22:16 am
Actually it is listed there in small font. It said lambdas. Which was also mentioned by other posters on this page of this thread. I'm not even sure why you thought it would be necessary to turn off image blocker anyway, you can click through the spoilers and still read what it says without even messing with image blocker.

*edit*: Ok, it gives alternate text with image blocker on... how strange.

I had to zoom in my browser a zillion times to see that word. then I reasoned the pics might have been screenshots or something. allow images, add water and BOOM, instant headaches with half that screen flashing. It wouldn't have been an issue if I hadn't just zoomed in a couple dozen times.

I was warned of this too in my intro topic.
Title: Re: Axe Parser
Post by: Deep Toaster on July 05, 2011, 06:12:58 pm
I don't think it will ever be "Finished".  Its going to stay alive for a long time, the 1.0.0 will just be the largest, most improved, programming-style changing update to date.  If I ever fear the Parser is starting to die due to real life stuff or boredom of working on the same project for so long, I will definitely pass it on to another programmer to continue, I wouldn't leave you guys hanging. :)

Perpetual betas are awesome :D Good luck on 1.0.
Title: Re: Axe Parser
Post by: ZippyDee on July 05, 2011, 06:14:48 pm
Actually it is listed there in small font. It said lambdas. Which was also mentioned by other posters on this page of this thread. I'm not even sure why you thought it would be necessary to turn off image blocker anyway, you can click through the spoilers and still read what it says without even messing with image blocker.

*edit*: Ok, it gives alternate text with image blocker on... how strange.

I had to zoom in my browser a zillion times to see that word. then I reasoned the pics might have been screenshots or something. allow images, add water and BOOM, instant headaches with half that screen flashing. It wouldn't have been an issue if I hadn't just zoomed in a couple dozen times.

I was warned of this too in my intro topic.

Maybe madly flashing smileys aren't the best idea! (I don't really like them much myself...)
Title: Re: Axe Parser
Post by: Compynerd255 on July 06, 2011, 08:03:29 pm
Okay, lambdas are freakin' cool! I can't wait to use them in Axe, although I'm trying to think about how I would... I do know that one of my dad's programs uses lambdas to pass drawing routines for different objects into a positioning routine.
Title: Re: Axe Parser
Post by: Darl181 on July 07, 2011, 08:10:34 am
More seriously, Ashbad's referring to inline functions, I presume, which probably aren't going to happen.

Quigibo just said they were gonna happen, so I assume they are :P
Ok, let me rephrase that.

Can someone describe in simple(r) english what lambdas are and how they are used?
Title: Re: Axe Parser
Post by: leafy on July 07, 2011, 11:41:26 am
Lambdas are interesting programming solutions to difficult problems. I've used them in Python before.
Title: Re: Axe Parser
Post by: Deep Toaster on July 07, 2011, 11:43:27 am
I just realized... Lambdas are basically routines you pass around like arguments, right? I actually need that O.O Good luck on it!
Title: Re: Axe Parser
Post by: GreenFreak on July 08, 2011, 07:08:49 am
I don't understand that...  :(
When should I use lambdas?
Title: Re: Axe Parser
Post by: Deep Toaster on July 08, 2011, 01:52:00 pm
If you're making a falldown game, for instance, where every level comes with a special feature (bouncing, antigravity, whatever), you can make each feature a lambda and pass it to the game.
Title: Re: Axe Parser
Post by: Ashbad on July 08, 2011, 02:16:14 pm
Well, as someone who uses them all the time in programming, I can say they are very useful in many situations.  They can help reduce the number of methods needed to evaluate a certain value.  DeepThought gives a decent example with different features per level, such as if you had two different levels of gravity:

Code: [Select]
@gravity = lambda {|cur_level|(cur_level%5==0)?(1):(2)} / air_density
So that every five levels the lambda would return 2 instead of 1.  In that example you could take out the lambda and still be fine, but there are even bigger needs for it when you need to directly pass values as parameters into complex equations with highly varying outputs or when you go to attach them to variables directly so that a variable's state is defined by input parameters.  Which brings me to ask, quigibo: are you thinking of adding full support for lambdas/procs with variable attachments and inlining functions, or just inlining?

EDIT: hmm, so the case here isn't just that many don't know how to use them, but that they also don't know what they are :P understandable.  In a nutshell:

Lambdas are functions that stand in for single values (though in some cases they can return multiple values, but don't worry about that most languages don't even support it).  They can take passed arguments and can contain code that'll evaluate expressions and return values accordingly.  Very, very useful.  For a decent background, here's the wikipedia link Qwerty pointed me to a long time ago that I found very helpful: http://en.wikipedia.org/wiki/Lambda_calculus
Title: Re: Axe Parser
Post by: GreenFreak on July 08, 2011, 02:31:34 pm
ookaaay...
That sounds really useful :)
But I don't understand the code :P
Code: [Select]
@gravity = lambda {|cur_level|(cur_level%5==0)?(1):(2)} / air_density
EDIT: your EDIT helped me to understand it better! thanks ;)
Title: Re: Axe Parser
Post by: Ashbad on July 08, 2011, 02:37:40 pm
Simpler variant:

Code: [Select]
if cur_level%5 == 0
  Thing = 1
else
  Thing = 2
end
Gravity = Thing / air_density
Title: Re: Axe Parser
Post by: Quigibo on July 08, 2011, 02:43:17 pm
Fine!  I'll give an example since people seem to be confused... :)

Map(λ(r12),L1,100)

If you made a function map (which functional programmers should recognize) this would square the first 100 numbers of L1.  You could pass any function there, this example is a function of 1 argument.  But in general, lambda expressions are functions of r1-r6 depending on how many arguments the function is expecting.  Its as if you had made a label in your code "Lbl A:Return r12" and then passed LA (the address of the function) as the argument.  But here you don't need to assign it a label name... sort of like inline data.
Title: Re: Axe Parser
Post by: Ashbad on July 08, 2011, 02:47:49 pm
/me pays off people who didn't understand since they allowed him to finally see Axe's implementation :)

EDIT: hmm.. Your implementation is similar to haskell's or lisp's implementation, as more of a higher order function rather than a general purpose value stand in or an attached proc that directly manipulates a variable's value upon accessing.  Anyways, cool, this would be very useful to me in many circumstances, and I guess you can't really implement the pythonic/Rubonic version in axe anyways :P it'd be a bit impracticable
Title: Re: Axe Parser
Post by: GreenFreak on July 08, 2011, 03:12:03 pm
/me pays off people who didn't understand since they allowed him to finally see Axe's implementation :)

;D

I hope, you'll explain that in the Axe-documentation, Quigibo
Because I'm still confused a bit^^ ;D
Title: Re: Axe Parser
Post by: Freyaday on July 08, 2011, 04:08:16 pm
Umm, does this have something to do with using subroutines as functions?
(Where a function is a thingy that returns a value based off of input)
Title: Re: Axe Parser
Post by: calcdude84se on July 08, 2011, 07:28:57 pm
Map(λ(r12),L1,100)
I have couple remarks on that :)
First of all, since we will presumably be able to make routines such as Map( ourselves, could you show us the syntax for calling a subroutine by address? (Something like sub(r1, ...)r, perhaps? (Where r1 is any expression))
Secondly, will inlining be supported? (In general, not just for Map() That is, if an anonymous subroutine (or lambda, whatever you want to call them) is passed to a routine and that routine has a call for it exactly once, will the compiler replace the call with the routine itself? Otherwise, your example, among other useful invocations, will be much slower than it should be. ;)
Title: Re: Axe Parser
Post by: Darl181 on July 08, 2011, 07:33:22 pm
Well, as someone who uses them all the time in programming, I can say they are very useful in many situations.  They can help reduce the number of methods needed to evaluate a certain value.  DeepThought gives a decent example with different features per level, such as if you had two different levels of gravity:

Code: [Select]
@gravity = lambda {|cur_level|(cur_level%5==0)?(1):(2)} / air_density
So that every five levels the lambda would return 2 instead of 1.  In that example you could take out the lambda and still be fine, but there are even bigger needs for it when you need to directly pass values as parameters into complex equations with highly varying outputs or when you go to attach them to variables directly so that a variable's state is defined by input parameters.  Which brings me to ask, quigibo: are you thinking of adding full support for lambdas/procs with variable attachments and inlining functions, or just inlining?

EDIT: hmm, so the case here isn't just that many don't know how to use them, but that they also don't know what they are :P understandable.  In a nutshell:

Lambdas are functions that stand in for single values (though in some cases they can return multiple values, but don't worry about that most languages don't even support it).  They can take passed arguments and can contain code that'll evaluate expressions and return values accordingly.  Very, very useful.  For a decent background, here's the wikipedia link Qwerty pointed me to a long time ago that I found very helpful: http://en.wikipedia.org/wiki/Lambda_calculus

Ok, so a lambda is basically a subroutine taking a place of a number.  Sounds cool ;)
So I'm guessing something like...
sub(GC)→P
[...]
Lbl GC
GetCalc(Str0L)
Return

...would work?
Title: Re: Axe Parser
Post by: Runer112 on July 08, 2011, 08:18:34 pm
Map(λ(r12),L1,100)
I have couple remarks on that :)
First of all, since we will presumably be able to make routines such as Map( ourselves, could you show us the syntax for calling a subroutine by address? (Something like sub(r1, ...)r, perhaps? (Where r1 is any expression))
Secondly, will inlining be supported? (In general, not just for Map() That is, if an anonymous subroutine (or lambda, whatever you want to call them) is passed to a routine and that routine has a call for it exactly once, will the compiler replace the call with the routine itself? Otherwise, your example, among other useful invocations, will be much slower than it should be. ;)

To answer your first question, you'll probably want to call most functions with a label name, like Map(ARGS). However, you will now be able to call arbitrary addresses as well with (ADDRESS)(ARGS); (ADDRESS) is like a stand-in for the name of the function.

To answer your second question, the point of passing anonymous subroutines to functions as pointers is so you can pass any routine's pointer. The compiler will have no idea if a certain routine of yours is only ever going to be called with a pointer to one external function. If you're only going to pass one external function into your function, then you should just incorporate the first inside of the second.
Title: Re: Axe Parser
Post by: calcdude84se on July 09, 2011, 07:42:06 pm
Ah, thanks for the syntax. As for the second, understood. (But I can't do that for built-ins :P)
Title: Re: Axe Parser
Post by: Quigibo on July 13, 2011, 07:45:09 am
Well its finally here!  Believe it or not, there were still a whole lot of features I wanted to add before releasing it, but the contest deadline is coming up and I've already been delaying too much so I'm going to release it now for better or worse.  Some of the changes are really dramatic, so it will definitely take some time to get used to the paradigm shifts that come with it.

So I was going to write a really long post saying how far the project has come and how much the community has helped me code, test, and popularize Axe Parser.  But then I realized that it would sound like a culmination, and I don't want it to seem at all like I'm done coding or that the parser is finalized.  Also, its 4:30 AM for me right now and I've been staying up this late this whole week trying to get this thing out the door, so I'd rather get some sleep instead.  You guys already know how awesome you are, you don't need me to tell you that  :hyper:

Hopefully there won't be any major bugs since I've been testing it with a few other people and have fixed all the bugs uncovered so far.  So have fun and hopefully everyone in the contest can adapt their code for 1.0.0, there weren't too many incompatibilities for this size of a release and all of them are extremely easy to fix.
Title: Re: Axe Parser
Post by: TIfanx1999 on July 13, 2011, 07:57:27 am
Kudos to you. You said you were going to attempt a release before the contest deadline and you made it. 1.0 is here, and my hat is off to you sir. It must feel great to have 1.0 released, it's been an amazing journey watching this develop. I look forward to seeing it's continued development and improvement as well. Excellent job!
Title: Re: Axe Parser
Post by: Munchor on July 13, 2011, 08:03:29 am
You guys already know how awesome you are, you don't need me to tell you that  :hyper:

I know I'm awesome, but making me lose the game was unnecessary.

But in all seriousness, this seems like an awesome update, Quigibo, you're the awesome one :hyper:
Title: Re: Axe Parser
Post by: apcalc on July 13, 2011, 08:04:56 am
Congratulations on this wonderful release!

Axe has certainly made a massive impact on the entire TI community.  You most certainly deserve a huge rou dof applause for your excellent work! :)
Title: Re: Axe Parser
Post by: Ashbad on July 13, 2011, 10:29:47 am
Unlike what a few Axe Gurus say about this release, I personally find it a step in a wonderful direction.  Beautiful job with the new supported functional aspects, Axe is no longer the FORTRAN II of calculators (by this I mean its main purpose was just to be a compiled language that focused on heavy optimization and few modern aspects).  There are many thing I still would like to see added, but this version is wonderful, great job overall.  I really do like how this version is more of added language features and not trivial optimizations or commands.

TL;DR: :)
Title: Re: Axe Parser
Post by: GreenFreak on July 13, 2011, 10:44:35 am
HELP!
My calc crashed! (because of Axe 1.0.0!)
I'd tried to do little changes:

0->{L1}^r
Fill(L1,58)

It took (my wohle game (compiled) ) 1914 bytes

Then I tried to use the new Fill( comand and compiled the game:

Fill(L1,58,0)

It was ~40 bytes smaller. (Not only because of this change, but also through the new optimizations of Axe.)
Wow, I thought and redid it, to see the old size of the compiled game..

BUT THEN: (after compiling) : "Backing up.."
BAM! Calc turned off. When I tried to turn it back on, It showed the "Backing up.." screen and turn off (after a second) again.

So I took out a battery, but that didn't helped, so I started my with [clear] + [on] : RAM cleared, (and everything else (but not the apps), too.)

 :'(  Is that a major bug? Or a mistake on my part??

I was so happy because of the release of Axe v. 1.0.0  :'(


EDIT: Fortunately I've everything back-up'd on my PC a few days before! ;) I'm sooo happy about that! :D
BUT: Please find the bug, Quigibo!!

EDIT2: I'm not able to redo this...
Title: Re: Axe Parser
Post by: p2 on July 13, 2011, 10:52:38 am
ask runner.
ruunner knows everything.
Title: Re: Axe Parser
Post by: GreenFreak on July 13, 2011, 11:00:39 am
;D I know that ;D
So: Quigibo, or Runer112 :P, tell me, what could went wrong, please!


PS: Oh, ein Deutscher ;D
Title: Re: Axe Parser
Post by: p2 on July 13, 2011, 11:04:13 am
only Runner is on.
send him a PM, if you want to.

But post the answer here.
( want to learn something, too!)   ;)




DU BIST AUCH DEUTSCH / DU VERSTEHST DEUTSCH?  :o
Title: Re: Axe Parser
Post by: GreenFreak on July 13, 2011, 11:07:12 am
Jaaa, kannste mal sehen... (steht über dem Avatar)

bisschen off-topic ;D

Ich denke, dass Runer das von alleine liest...

EDIT: How to join #omnimaga irc?
Title: Re: Axe Parser
Post by: p2 on July 13, 2011, 11:13:47 am
do you mean OmnomIRC?
just write something and press ENTER.
Title: Re: Axe Parser
Post by: ztrumpet on July 13, 2011, 11:22:56 am
EDIT: How to join #omnimaga irc?

Well, there are a few ways.  Here are the easiest two:
1. Use http://www.omnimaga.org/irc/  Be warned, it sometimes crashes.
2. Use mibbit: https://cbe001.chat.mibbit.com/ Make "Connect = EFNet," "Nick = GreanFeak (or something)," and "Channel = #omnimaga"

Good luck! :)
Title: Re: Axe Parser
Post by: GreenFreak on July 13, 2011, 11:25:11 am
Oh, I forgot to enable 3rd party cookies ;D
Title: Re: Axe Parser
Post by: calcdude84se on July 13, 2011, 12:14:23 pm
Nice to finally see 1.0.0! Great job! :D (I'll try it at some point, I know it.)
I'm curious why you've bothered to separate the code and data in the compiled program, though, given recent developments which make this unnecessary.
Title: Re: Axe Parser
Post by: Ashbad on July 13, 2011, 12:20:41 pm
It may be unessicary, but I find it rather more organized and clean :).  Plus, I for one don't trust the whole RAM execution limit breaking idea, I haven't seen enough tests to be sure I would consider using it or wanting people making programs using it.
Title: Re: Axe Parser
Post by: calcdude84se on July 13, 2011, 12:27:28 pm
It may be unessicary, but I find it rather more organized and clean :).
This is in the compiled code. You wouldn't notice. :P
Quote
Plus, I for one don't trust the whole RAM execution limit breaking idea, I haven't seen enough tests to be sure I would consider using it or wanting people making programs using it.
It works perfectly. The only foreseeable problem is getting people to run a program which would make all RAM executable.
Title: Re: Axe Parser
Post by: Runer112 on July 13, 2011, 12:31:44 pm
The reason why code and data are separated is because these recent developments you speak of require either a dedicated program to enforce this setting or an OS/boot code mod. I think most calculator gamers are just students who learned from other students that you can put cool games on your calculator. They probably have no knowledge of these recent developments regarding the execution limit, and will be complaining upon discovering that the game he put on his calculator causes a crash.

EDIT: Oh, I forgot. Or you can add ~50 bytes of code to do this in large programs, which may be completely unnecessary if the code is just moved around a bit.
Title: Re: Axe Parser
Post by: calcdude84se on July 13, 2011, 12:35:57 pm
So the foreseeable problem is rather a large one. :P Makes sense.
Title: Re: Axe Parser
Post by: Ashbad on July 13, 2011, 12:53:51 pm
It may be unessicary, but I find it rather more organized and clean :).
This is in the compiled code. You wouldn't notice. :P
Quote
Plus, I for one don't trust the whole RAM execution limit breaking idea, I haven't seen enough tests to be sure I would consider using it or wanting people making programs using it.
It works perfectly. The only foreseeable problem is getting people to run a program which would make all RAM executable.

Well, it's much much much much cleaner to have two distinct sections, you at least know you can mess with data and only affect data, instead of maybe messing with code.

for the second, ^ what runer said.  Plus, I don't ever want mtoo believe something works "perfectly" until extensive tests are made to be sure -- I'm sure it will turn out to be fine, but until then I'm reframing from associating with it.
Title: Re: Axe Parser
Post by: Quigibo on July 13, 2011, 02:12:27 pm
HELP!
My calc crashed! (because of Axe 1.0.0!)
I'd tried to do little changes:

0->{L1}^r
Fill(L1,58)

It took (my wohle game (compiled) ) 1914 bytes

Then I tried to use the new Fill( comand and compiled the game:

Fill(L1,58,0)

By the way, those are not the same code.  You would have to do Fill(L1,59,0) to be the same as before because now it zeros all 59 bytes of data since before you were manually setting one byte and then copying it to the other 58.

The bug you were talking about where it froze on backing up I had before as well on my real calculator once too.  I think I know what the problem might be, I'll try to fix it.
Title: Re: Axe Parser
Post by: GreenFreak on July 13, 2011, 03:32:54 pm
I'm happy that I have a complete back-up on my PC, so that I haven't lost all my games and programs ;)
So everyone: ALWAYS BACK-UP YOUR FILES!

I hope you can find and fix this bug...

I have another question about the new version:
In the changelog, you wrote:
"Flash is locked after quitting Axe for security reasons."
What does that mean?

Thank you, Quigibo, for your awesome work!
Title: Re: Axe Parser
Post by: defmenge on July 14, 2011, 11:15:09 am
Thank you very much for adding support for single byte variables! This will be extremely useful to my current and probably all my future projects. :)
Keep up the great work! :D
Title: Re: Axe Parser
Post by: JosJuice on July 14, 2011, 03:32:13 pm
I have another question about the new version:
In the changelog, you wrote:
"Flash is locked after quitting Axe for security reasons."
What does that mean?
When a program or app wants to write something to Flash, they can do it in two ways. The first ways is to use BCALLs. It's quite stable, but sometimes there are things that you can't do that way. The other way is to write every byte directly to flash. However, TI has protected flash so that you don't accidentally write to it. Before the program/app writes to flash, it must unlock flash, which can be quite tricky. If Axe doesn't lock flash afterwards, another program might write to flash accidentally (but most programs will normally not even attempt to do it, so it's not dangerous in normal cases).
Title: Re: Axe Parser
Post by: GreenFreak on July 14, 2011, 05:18:07 pm
ah, ok
Title: Re: Axe Parser
Post by: Hot_Dog on July 14, 2011, 10:56:38 pm
Quigbo, I just saw your update allowing variables as single byte values.  This is an excellent addition, and you continue to amaze me!
Title: Re: Axe Parser
Post by: yrinfish on July 15, 2011, 02:03:17 pm
Woooooooow I love it!! I love it!! Why work on Happy if we have THIS, it's AWESOME!
Sleep well!!

I think I love the new function calls the most!!
Title: Re: Axe Parser
Post by: Compynerd255 on July 21, 2011, 12:47:09 am
Okay. My mind is blown with the new Axe.

Blown. Blown. Blown.

I love all the new features! I'm going to download this to my calc tommorow morning and see the awesomeness unfold!
Title: Re: Axe Parser
Post by: Runer112 on July 21, 2011, 12:49:27 am
You might want to hold off for a bit longer until some bugs are fixed. Axe 1.0.0 and 1.0.1 have a nasty ability to sometimes muck up flash. I've heard of effects ranging from losing data in some sectors of flash memory, to having to resend the OS, to having to clear all memory altogether.
Title: Re: Axe Parser
Post by: mrmprog on July 21, 2011, 12:52:17 am
You might want to hold off for a bit longer until some bugs are fixed. Axe 1.0.0 and 1.0.1 have a nasty ability to sometimes muck up flash. I've heard of effects ranging from having to resend Axe, to having to resend the OS, to having to clear all memory.
Gasp!
That is bad, maybe I should hold off then.
Title: Re: Axe Parser
Post by: Darl181 on July 21, 2011, 03:56:13 am
You might want to hold off for a bit longer until some bugs are fixed. Axe 1.0.0 and 1.0.1 have a nasty ability to sometimes muck up flash. I've heard of effects ranging from losing data in some sectors of flash memory, to having to resend the OS, to having to clear all memory altogether.
So that explains it...and I only got the Bad Flash err once x.x
Title: Re: Axe Parser
Post by: Freyaday on July 21, 2011, 08:29:47 am
Yeah. 1.0.0 broke my archive and I spent 5 hours fixing it with massive infusions of thepenguin77
Title: Re: Axe Parser
Post by: annoyingcalc on July 21, 2011, 08:53:37 am
Same here
Title: Re: Axe Parser
Post by: Darl181 on July 21, 2011, 02:08:39 pm
I'm wondering if data lost from axe 1.0.0/1.0.1 is recoverable.  Or was the sector just wiped clean?
Title: Re: Axe Parser
Post by: Binder News on July 21, 2011, 02:11:54 pm
Yeah, I lost my program and Axe itself, but that was it. I think I'll use Wabittemu from now on. For a while at least.
Title: Re: Axe Parser
Post by: GreenFreak on July 22, 2011, 08:51:38 am
You might want to hold off for a bit longer until some bugs are fixed. Axe 1.0.0 and 1.0.1 have a nasty ability to sometimes muck up flash. I've heard of effects ranging from losing data in some sectors of flash memory, to having to resend the OS, to having to clear all memory altogether.

;D I feel adressed^^ Is the Bad Flash error fixed now, Quigibo?
Title: Re: Axe Parser
Post by: Darl181 on July 22, 2011, 04:58:42 pm
Not in 1.0.1.  The safest version to use for now is 0.5.3.

It should be fixed in 1.0.2 tho :)
Title: Re: Axe Parser
Post by: GreenFreak on July 22, 2011, 05:36:43 pm
I hope that all bugs will be fixed in 1.0.2....
Title: Re: Axe Parser
Post by: chattahippie on July 22, 2011, 07:02:24 pm
Thanks for the warning.  Hope its fixed in 1.0.2
Title: Re: Axe Parser
Post by: Anima on July 22, 2011, 07:23:30 pm
Oh bad, I was so happy when Axe Parser 1.0.0 was released, but I didn't know that there is a fatal bug. Please fix it, Quigibo! :O
Title: Re: Axe Parser
Post by: TIfanx1999 on July 23, 2011, 08:07:05 am
Just be patient guys. Quigibo is aware of the bugs, and I'm sure it'll be fixed when the next version is released. ;)
Title: Re: Axe Parser
Post by: mrmprog on July 23, 2011, 08:09:20 am
I am back to 0.5.3 (which works fine :) ) and I noticed that compiling is much, much faster. Were that many new features added to Axe 1?
Title: Re: Axe Parser
Post by: TIfanx1999 on July 23, 2011, 08:16:26 am
Much was re-written or changed entirely, so yea. It was quite a big update.
Title: Re: Axe Parser
Post by: ztrumpet on July 23, 2011, 11:17:44 am
I am back to 0.5.3 (which works fine :) ) and I noticed that compiling is much, much faster. Were that many new features added to Axe 1?
Yes, and tons of new features were added, allowing variable names to be longer, forward referencing, a much, much higher variable limit, and other changes.  This translates to slower parsing, but it's more flexible this way. :D
Title: Re: Axe Parser
Post by: Ashbad on July 23, 2011, 01:59:31 pm
I am back to 0.5.3 (which works fine :) ) and I noticed that compiling is much, much faster. Were that many new features added to Axe 1?
Yes, and tons of new features were added, allowing variable names to be longer, forward referencing, a much, much higher variable limit, and other changes.  This translates to slower parsing, but it's more flexible this way. :D

You forgot the addition of primitive functional aspects ;)
Title: Re: Axe Parser
Post by: Quigibo on July 24, 2011, 02:36:58 am
Actually, the slowdown is entirely due to yet another major feature, the one that required the most core rewriting, which is the peephole optimizations.  The parser now writes commands instruction by instruction instead of byte by byte so it can optimize out any sub-optimal patterns it sees along the way, cutting code size an extra 1-2% and setting it up for future reductions of probably 5% or more.  It should eventually allow you to write code in a more natural way and then automatically convert it to code that is more "Runer Style" as I like to call it ;)
Title: Re: Axe Parser
Post by: mrmprog on July 24, 2011, 04:35:21 am
It should eventually allow you to write code in a more natural way and then automatically convert it to code that is more "Runer Style" as I like to call it ;)
Runer Style? I wonder why you call it that?  <_<
/me can't wait until he can code in a way that humans can read, and have the compiled program hyper-optimized!
Title: Re: Axe Parser
Post by: Munchor on July 24, 2011, 05:28:01 am
I am back to 0.5.3 (which works fine :) ) and I noticed that compiling is much, much faster. Were that many new features added to Axe 1?
Yes, and tons of new features were added, allowing variable names to be longer, forward referencing, a much, much higher variable limit, and other changes.  This translates to slower parsing, but it's more flexible this way. :D

I did not know we could have longer variable names, that's sweet!
Title: Re: Axe Parser
Post by: Runer112 on July 24, 2011, 09:11:00 am
It should eventually allow you to write code in a more natural way and then automatically convert it to code that is more "Runer Style" as I like to call it ;)

And I'll still find ways to optimize it. ;D But cool nonetheless. Although a lot of the optimizations I perform now are somewhat natural to me, it would be nice if Axe could perform a few of them itself. Even my own optimized code confuses me sometimes.


Will this system be able to look over code that wouldn't affect the value in the registers? By that, I mean will it be able to optimize something like:

Code: [Select]
0→A
1→B

Into:

Code: [Select]
ld hl,0
ld (A),hl
ld l,1 ;or even inc l if you can pull it off
ld (B),hl
Title: Re: Axe Parser
Post by: mrmprog on July 24, 2011, 09:20:47 am
/me senses a challenge...
Who can make the most optimized code? Runer with the source, or Quigibo with the parser?  8)


/cue dramatic music
Title: Re: Axe Parser
Post by: Darl181 on July 24, 2011, 11:08:02 pm
..or runer and others helping quigibo with the parser (http://ourl.ca/4175) :P
Title: Re: Axe Parser
Post by: Munchor on July 25, 2011, 07:45:43 am
Quigibo just released Axe 0.0.2, it fixes all the bugs in the 1.0.1 :)
Title: Re: Axe Parser
Post by: Hayleia on July 25, 2011, 07:56:47 am
Quigibo just released Axe 0.0.2 1.0.2, it fixes all the bugs in the 1.0.1 :)
Title: Re: Axe Parser
Post by: Quigibo on July 25, 2011, 07:56:59 am
Even though this isn't a new feature, its new in the fact that it's now optimized enough to be useful.  Calc84maniac gave me the idea over chat:

You can use the ternary operator to short circuit a list of conditions for any statement.  For example, instead of doing:
Code: [Select]
:If A
:If B
:If C
:<code>
:End:End:End
You can now inline the comparisons using the ternary:
Code: [Select]
:If A?B?C,,
:<code>
:End

These both compile to essentially the same code.  To break it down since its not immediately obvious why these 2 are the same, consider the grouping Axe is doing internally:
Code: [Select]
If (A?(B?(C),<b is false>),<a is false>)Basically it checks A, if A is false, there is no code, so it returns the last statement evaluated which is 0 since it was false.  If true, it checks B and again returns false if B is false.  Finally, if B is true, it just returns C's condition which will determine if the entire statement is true or false :)

Its a really nice shorthand! (even though the trailing commas might look ugly)  You can also use it for while and repeat statements which I don't think was possible before.
Title: Re: Axe Parser
Post by: calcdude84se on July 25, 2011, 12:04:49 pm
Yay, short-circuit conditions! :) Is there a way to do something similar with "or" along with "and"?
Title: Re: Axe Parser
Post by: calc84maniac on July 25, 2011, 12:32:11 pm
Yep, instead of If A+B+C, you can do If A?,B?,C
Title: Re: Axe Parser
Post by: calcdude84se on July 25, 2011, 01:17:11 pm
Nice to know. Since all of the most devastating bugs seems to have been fixed, I think I'll send 1.0.2 and try it out a bit. :)
Title: Re: Axe Parser
Post by: Quigibo on July 25, 2011, 02:47:59 pm
Haha! Just realized something... There is no reason for me to require a comma. In the next version, I will make it so that you can do a simple "A?B?C" to 'and' conditionals and "A??B??C" to 'or' them.  That should be more intuitive.  So now there really will be boolean operators!
Title: Re: Axe Parser
Post by: Runer112 on July 25, 2011, 02:53:41 pm
Also, a bug regarding short-circuiting a chain of ORs (or NORs). Omitting parentheses around the inline if statement chain somehow results in the first line inside the If statement being parsed as if it's at the end of the If statement line. For instance, this:

Code: [Select]
If A?,B
Pxl-On(A,B)
0→A
End

Is parsed like this:

Code: [Select]
If A?,BPxl-On(A,B)
0→A
End
Title: Re: Axe Parser
Post by: Quigibo on August 20, 2011, 06:49:22 am
Cool, so I finished the short circuit operators and fixed the bugs involved with them hopefully.  If any of you are familiar with C, these are the "&&" and "||" operators.

Its really easy to use.  Instead of doing:
Code: [Select]
If A=3 and (B=6) and (C=7)
You can do:
Code: [Select]
If A=3 ? B=6 ? C=7
Likewise, "or" would be replaced with "??".  Those spaces I added aren't needed, but you might want to add them if it becomes hard to read.  I'm not sure if this yields a size optimization, it probably depends on the expressions, but it definitely has a speed optimization because it will skip checking the rest of the conditions as soon as one is found that allows the skip to occur (called short circuit evaluation).
Title: Re: Axe Parser
Post by: mrmprog on August 27, 2011, 03:59:07 pm
Have the major bugs in 1.0.X been fixed in 1.0.3?
Title: Re: Axe Parser
Post by: Darl181 on August 27, 2011, 04:33:23 pm
It seems like it.  I've only gotten bad flash maybe once and after running thepenguin's archive fixer haven't had any since ;D
Title: Re: Axe Parser
Post by: Quigibo on August 27, 2011, 10:08:05 pm
Yeah, the serious bugs were fixed in 1.0.2 actually.  The "major" bug in 1.0.2 was just a language thing for pointers, nothing serious.
Title: Re: Axe Parser
Post by: willrandship on August 27, 2011, 10:56:00 pm
So for all intents and purposes 1.0.3 is stable? That's good news, 1.0.1 made me drool. A lot. It was messy. And my friend laughed at me.

But it was worth it! :D
Title: Re: Axe Parser
Post by: GreenFreak on August 28, 2011, 05:06:44 am
willrandship, if I klick on the link in your signature, my avast! antivirus says, that this site wants to install malware on my pc X.x
Title: Re: Axe Parser
Post by: Eiyeron on August 28, 2011, 09:36:54 am
willrandship, if I klick on the link in your signature, my avast! antivirus says, that this site wants to install malware on my pc X.x
Yeah, that happens for a m:oment, then disappear.
Title: Re: Axe Parser
Post by: Ashbad on August 28, 2011, 09:51:38 am
willrandship, if I klick on the link in your signature, my avast! antivirus says, that this site wants to install malware on my pc X.x
Yeah, that happens for a m:oment, then disappear.

\o/ yay totally random off topic stuff

On a side note I didn't get any malware warning
Title: Re: Axe Parser
Post by: Deep Toaster on August 28, 2011, 06:23:14 pm
...so you got the malware? :P

Baaack on topic, yep, from what I can tell from the bug reports (http://ourl.ca/4072.new#new) thread, 1.0.3 is pretty stable. I should upgrade sometime.
Title: Re: Axe Parser
Post by: willrandship on September 01, 2011, 01:34:16 am
There shouldn't be any malware in that link....it's a simple url redirection service.

But yes, as far as I can tell with minimal testing of my own, 1.0.3 is running well, with any crashing being my fault, not axe's :P
Title: Re: Axe Parser
Post by: Compynerd255 on September 01, 2011, 01:06:35 pm
Out of curiosity, about the dereferenced labels: Since (LFOO)() is the same as using FOO(), can you put constant pointers into the first parentheses to call shell and TI-OS subroutines (like (E0000)() to reset your RAM)? Because if so, that will be REALLY cool! :)
Title: Re: Axe Parser
Post by: Ashbad on September 01, 2011, 01:33:25 pm
Out of curiosity, about the dereferenced labels: Since (LFOO)() is the same as using FOO(), can you put constant pointers into the first parentheses to call shell and TI-OS subroutines (like (E0000)() to reset your RAM)? Because if so, that will be REALLY cool! :)

yes.  However, when you load arguments, you aren't loading them the way that the OS routines want them as (they usually want them in registers, you'll be loading them into the stack and/or HL solely) so to load arguments for them you'll have to inline some assembly.  Unless of course the routine doesn't expect any arguments, or just one in HL :P
Title: Re: Axe Parser
Post by: DrDnar on September 01, 2011, 01:37:16 pm
You'd need a way to load parameters into registers before executing the call for shell routines. And I'm all for adding such a syntax into Axe. Axe has filled a void between assembly and basic that's hopefully helping people achieve more. Adding support for external routines would just be a natural way for Axe to integrate more fully into the OS and shells.

Also, a BCALL address isn't actually an address in the linear address; it's an index into an LUT that points to the real address of the routine. Consequently, the normal syntax for calling BCALLs wouldn't be applicable. (They're also typically encoded as a pseudo-instruction using an RST routine, so again, the normal calling syntax wouldn't be applicable.)

EDIT: Ninja'd.
Title: Re: Axe Parser
Post by: Quigibo on September 01, 2011, 01:54:19 pm
There is a subtle difference between (LFoo)() and Foo().  First of all, the second is more optimized, but more importantly, the 2nd one has the last expression in the accumulator whereas the first has LFoo.  If Foo was like this:

Code: [Select]
:Lbl Foo
:+1->B
:Disp B>Dec
:Return

Then calling 5Foo() will print 6, but calling 5(LFoo)() will display the pointer of Foo plus one.  Even when there's arguments, it will still keep the pointer in the accumulator when called that way.

There are only a handful of OS calls in the early address space.  Most of these are either useless to game making or already implemented by Axe.  Anyway, you wouldn't ever want to call them in an ugly way like that.
Title: Re: Axe Parser
Post by: Runer112 on September 01, 2011, 02:04:36 pm
Quigibo, perhaps that could be changed? You could change the arbitrary address calling routine to this:

Code: [Select]
p_CallHL:
.db 6
pop ix
ex (sp),ix
jp (ix)

At the cost of 3 bytes for the entire program and only 12 cycles per use, you could pass arguments directly to arbitrary functions. I pass arguments in hl to functions all the time, so this would actually save bytes. That, combined with the fact that it would result in more uniform code effects, makes me believe that this would be a nice change.
Title: Re: Axe Parser
Post by: Compynerd255 on September 01, 2011, 03:39:21 pm
One thing I do realize about all of this is that if we're going to let people call ASM Shell routines, we need a way to check if the program is being compiled in a shell, so that we don't accidentally compile for the wrong shell when we need one. Maybe a reserved constant combined with #If could do this.
Title: Re: Axe Parser
Post by: Quigibo on September 01, 2011, 05:23:53 pm
That's a good idea Runer, I think I'll make that change.

Shell calls are for the most part useless.  Axe's routines are faster, more optimized and even smaller despite the fact that the actual routines are in the program itself due to the amount of extra register parameter juggling each call to the routine would have to include.  The only time I could see this being useful is for calling code that is shell specific, like the DCS GUI functions.  And even then, its much better to make shell calls Axioms because:

Title: Re: Axe Parser
Post by: Freyaday on September 01, 2011, 05:52:11 pm
Whee no weird hex values!
So, would Runer's idea give us, in essence, another (albeit volatile) variable?
Title: Re: Axe Parser
Post by: calcdude84se on September 01, 2011, 09:57:41 pm
Not exactly. We can already use HL for optimization and other things. (e.g. Pxl-On(0,,Pic0) vs Pxl-On(0,0,Pic0))
His proposed change would keep HL intact across a variable call.
Runer etc.: I take it that this extends also to such as (R*3+LA)()? (call via a jump table)
Title: Re: Axe Parser
Post by: Freyaday on September 02, 2011, 12:25:28 am
Um, so what would that mean? Will simply putting in a var name no longer load that var into HL?
Title: Re: Axe Parser
Post by: ralphdspam on September 02, 2011, 02:19:59 am
No, I think he is saying that hl will remain intact as you return from the subroutine. 
Title: Re: Axe Parser
Post by: calcdude84se on September 02, 2011, 05:51:52 pm
No, I think he is saying that hl will remain intact as you call the subroutine. 
Fixed that for ya ;D
Edit: 2^11th post!
Title: Re: Axe Parser
Post by: Ashbad on September 02, 2011, 05:53:32 pm
No, I think he is saying that hl will remain intact as you return from the subroutine. 

Essentially, it'll push HL before the calling address parenthesis are parsed, and then poped so it can be used within the subroutine with it's initial value.
Title: Re: Axe Parser
Post by: Freyaday on September 02, 2011, 08:34:04 pm
so, I could do

If FOO
sub(FOO)
End
Lbl FOO
->BAR

And BAR would now equal FOO?
Title: Re: Axe Parser
Post by: calcdude84se on September 02, 2011, 08:53:28 pm
We weren't talking about sub( ;)
A(LB)()
Lbl B
Disp >Dec
Return

Currently, this will display the address of Lbl B. The proposed change will make it display A instead, which is much more useful
Title: Re: Axe Parser
Post by: Quigibo on September 25, 2011, 02:20:55 am
I could not replicate the "Bad Flash" bug no matter what I did or how hard I tried, but I did change it to an unknown error which can tell me more useful information about where the error occurred if you can post the error code.

I also could not replicate the random 'r' bug, but I did change around the string reading routine a little bit so that might fix it, although I don't have hope it will.

I suspect that both of these errors are related to other apps you have installed since I am not able to reproduce it on a clean calculator.  DCS, zStart, and Omnicalc in particular create a ton of hooks and are the highest on my possibility list, but please tell me ALL of the apps you have installed when reporting one of these 2 bugs.

By the way, any major or minor bugs found in the next 24 hours I can patch up by Sunday.  But after that, I won't have a lot of time for a while.
Title: Re: Axe Parser
Post by: leafy on September 25, 2011, 03:12:21 am
Bad flash errors usually occur for me after a ram clear, or a particularly glitchy program ran its course.
Title: Re: Axe Parser
Post by: ztrumpet on September 25, 2011, 09:50:17 am
Are Axe Apps automatically signed now?  Do we even have to run them through the signer?
Title: Re: Axe Parser
Post by: alberthrocks on September 25, 2011, 10:54:00 am
I know for sure that a "Bad Flash" error occurs when you overwrite an archived program. That is, if the target program is prgmOUT, and prgmOUT is archived at the time, when I compile prgmOUTSRC it will say "Bad Flash". Hopefully that helps! :) (And the archived prgmOUT for whatever reason disappears, and compilation can occur.)

(This is version 1.0.2, btw)

EDIT: I've confirmed it! :D In an emulator ([wx]Wabbitemu), I emulated a TI-83 ROM, and installed Axe 1.0.4 (latest) on it. Then I tried to make a simple program:
Code: [Select]
.XYZ
Disp "HI"
I compiled it, then archived the compiled program. Then I recompiled... nothing bad happened.
I then sent AXERPG.8Xp (an example program), compiled it, and ran it. Then I exited it, archived the compiled program (RPGDEMO.8Xp), and then compiled again.... and got an error! :D (UNKNOWN ERROR Code: A429992)
Here's a pic: http://dl.dropbox.com/u/1016340/PublicPictures/AxeBadFlashError104.png

Note that this result may be tainted from the previous compile and execution of a compiled program, so I will retest to make sure this is a valid result.
For now, here's the ROM dump (state save):
http://dl.dropbox.com/u/1016340/AxeBadFlash104.sav

EDIT 2: I've confirmed my prediction - it triggers without any other factors. That is:
Load blank ROM -> Turn on calc -> Send Axe.8Xk -> Send AXERPG.8Xp -> Compile AXERPG.8Xp in Axe -> Archive compiled file RPGDEMO.8Xp -> Try recompiling -> ERROR

Could this be also correlated to program size? It didn't fail with the other tiny program (above).

I've provided the ROM of this error, still at the error screen for better debugging.
http://dl.dropbox.com/u/1016340/AxeBadFlash104_CLEAN_INERR.sav
Title: Re: Axe Parser
Post by: Quigibo on September 25, 2011, 04:57:52 pm
Thank you SO much!  I can now narrow down the problem. :)

Axe apps still need to be signed to transfer to another calculator, but at least it won't delete itself.

EDIT: HAHA!  I found it!  Turns out the problem was that TI's "DelVarArc" bcall re-locks flash again whenever it deletes from flash.  My flash unlocking routine was above it, so all I had to do was move it down after that call.  Has anyone gotten the random 'r' error yet with 1.0.4?
Title: Re: Axe Parser
Post by: Eeems on September 25, 2011, 06:16:14 pm
Axe apps still need to be signed to transfer to another calculator, but at least it won't delete itself.
I can't remember if this was asked before, but how long would it take for someone to sign an app on calc, and how much extra space would it take to do so?
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 25, 2011, 06:26:45 pm
Hmm by not deleting themselves, do you mean even if you never sign your app it will still remain on your calc forever, just not be sendable to another?

Also glad to see more updates.
Title: Re: Axe Parser
Post by: alberthrocks on September 25, 2011, 06:48:35 pm
Axe apps still need to be signed to transfer to another calculator, but at least it won't delete itself.
I can't remember if this was asked before, but how long would it take for someone to sign an app on calc, and how much extra space would it take to do so?
From the DuckSign (on calc app signer) documentation:
Quote from: DuckSign Readme
Hashing the application will take about 4 seconds per page on a TI-83
 Plus BE, or about 1 second per page on a TI-83 Plus SE or TI-84 Plus.
 Once this is done, computing a new application signature will take
 about 50 seconds on a TI-83 Plus BE, or about 20 seconds on a TI-83
 Plus SE or TI-84 Plus.

(Yes, you can sign apps on-calc; see http://ourl.ca/7447/149857)
Title: Re: Axe Parser
Post by: DrDnar on September 25, 2011, 08:44:08 pm
Xeda seems to love doing math-y things. You should ask her to learn RSA and write an optimized app signer. How long would on-calc app signing take? It could take over ten minutes if you write a really slow signing algorithm, but my gut feeling is that it can probably be done in under a minute.
Title: Re: Axe Parser
Post by: AngelFish on September 25, 2011, 08:48:09 pm
Axe apps still need to be signed to transfer to another calculator, but at least it won't delete itself.
I can't remember if this was asked before, but how long would it take for someone to sign an app on calc, and how much extra space would it take to do so?
From the DuckSign (on calc app signer) documentation:
Quote from: DuckSign Readme
Hashing the application will take about 4 seconds per page on a TI-83
 Plus BE, or about 1 second per page on a TI-83 Plus SE or TI-84 Plus.
 Once this is done, computing a new application signature will take
 about 50 seconds on a TI-83 Plus BE, or about 20 seconds on a TI-83
 Plus SE or TI-84 Plus.

Is there a particular reason we can't simply get Floppus' permission to distribute ducksign and then bundle it with Axe? For someone who doesn't make apps, I'm not sure I want Axe to use another page if for app signing if that would be necessary.
Title: Re: Axe Parser
Post by: Eeems on September 25, 2011, 08:51:14 pm
I wonder if there is enough space left for Axe to add some sort of signing process that can be enabled ( disabled by default ).
Title: Re: Axe Parser
Post by: Quigibo on September 25, 2011, 09:08:47 pm
There is enough space (I have about 5KB left on the 2nd page) and I think Floppus suggested I could include it at some point.  I just don't think its that high on the priority list right now since how often do you need to send someone an app without a computer?  I'd rather spend the time fixing known bugs and you can always add DuckSign to your calculator separately.
Title: Re: Axe Parser
Post by: Ashbad on September 25, 2011, 09:10:19 pm
Well considering the only way you distribute Axe-compiled Applications is by loading it through your computer first, I don't see why it's so hard to sign it on the computer (faster...) while you're preparing it for download than while you're testing it on-calc.
Title: Re: Axe Parser
Post by: flyingfisch on September 25, 2011, 09:11:58 pm
Ashbad, good to see you again!
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 25, 2011, 09:12:06 pm
The problem is that some people do not have a computer at all (or any suitable access to one). JustCause comes to mind.

However, I personally think it should come as an option, not bundled in Axe. People might not want to wait a long while during compiling everytime they're testing something for bugs and they might not like if Axe takes an extra page if they don't need to sign apps.

On a side note what happened to Floppus? ???
Title: Re: Axe Parser
Post by: Ashbad on September 25, 2011, 09:13:17 pm
Ashbad, good to see you again!

Que

The problem is that some people do not have a computer at all (or any suitable access to one). JustCause comes to mind.

But then he can't distribute it anyways, so no problem there.
Title: Re: Axe Parser
Post by: calcdude84se on September 25, 2011, 09:21:23 pm
Distribution to friends?
But there isn't too much need for integration with the presence of DuckSign.
Title: Re: Axe Parser
Post by: mrmprog on September 25, 2011, 09:24:26 pm
I actually wouldn't mind having that, even if it took extra space. Since I have an 84 se, space isn't really an issue for me. I know that it is for some people though. Perhaps two different AXE versions could be made, one being the normal, and the other having this and other memory hogging features.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 25, 2011, 09:26:43 pm
Yeah my issue is mainly those with lots of programs or who got a regular 83+. If they have Doors CS and Axe, right now they already only have 5 pages left.
Ashbad, good to see you again!

Que

The problem is that some people do not have a computer at all (or any suitable access to one). JustCause comes to mind.

But then he can't distribute it anyways, so no problem there.

Well if he could sign on-calc, he could send the game from calc to calc.
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 26, 2011, 04:59:09 pm
Two Axe releases in two days?? That must be a record!! O.O

Nice update though and I'm glad bugs are slowly getting narrowed down.
Title: Re: Axe Parser
Post by: squidgetx on September 26, 2011, 05:14:49 pm
SO the new feature in 1.0.5...speedy fast less optimized compile..Is this referring to the actual time it takes to compile, or does this mean the executable is larger but faster? If it's the second, that's pretty cool. If it's the first, that's pretty cool too (I was about to ask why is that useful but then I realized for testing small changes in large projects etc.) Nice update...I still have 1.0.3 XP (gotta fix that)
Title: Re: Axe Parser
Post by: Runer112 on September 26, 2011, 05:22:46 pm
The new speedy compile option disables peephole optimizations. This should result in the parsing of average code being about two times faster while producing compiled code that is about 1-5% larger. It's very useful for recompiling large projects after making small changes for testing purposes, but remember to compile the slow way for your project releases!
Title: Re: Axe Parser
Post by: DJ Omnimaga on September 26, 2011, 05:24:32 pm
Hmm interesting, i didn't know this was implemented. It must be helpful when we are debugging and aren't willing to wait 30 seconds everytime XD.
Title: Re: Axe Parser
Post by: Quigibo on September 26, 2011, 05:34:23 pm
Yeah, all the new zoom option does is disable the peephole optimizations, which makes it both slower and larger (but only slightly).  As Runer suggested, its really only for testing purposes in large programs that otherwise take a really long time to compile.

I'm just getting started with the more major peephole optimizations.  Some optimizations, like for instance 2->A:{A+L1}->B now automatically optimize to {2->A+L1}->B , which should help make code more readable.  The fact that finding optimizations like this is getting significantly harder to do in the disassembly means that Axe is inching closer and closer to the ASM limit.
Title: Re: Axe Parser
Post by: Deep Toaster on September 26, 2011, 06:13:19 pm
I'm really looking forward to that speedy compile option :o
Title: Re: Axe Parser
Post by: Quigibo on September 30, 2011, 05:38:25 pm
I've finally figured out how to easily and intuitively allow stack usage for Axe programs that's so easy, even beginners can do it  ;D

Its so simple, I don't know why I didn't think about it before.  The syntax will simply be "keep(EXP1,EXP2)".  All it does is evaluate expression2 and then return expression1.  You might be like "Wait, what?  That seems so pointless, why can't I just do EXP2:EXP1 then?  Isn't that the same thing?"  The answer is no.

Consider this:
Code: [Select]
A->B:B->A
In that example, first, A is stored to B and then B is stored back to A again.  Not useful at all.
But now consider this:
Code: [Select]
keep(B,A->B)->A
What happens now?  You might think that since keep returns the first expression B and then stores it to A that its still the same piece of code. But no!  Keep evaluates B first and then keeps that value until the end of the keep.  So even though B changed value during the 2nd argument, the original B is returned and stored into A.  In other words, this is how you perform an exchange with only 2 variables, and its 4 bytes smaller than using an extra one too!

So where is the original value of B stored then?  That's what the stack is, but you don't need to know that.  All you need to know is that keep is magical and super efficient for this kind of thing.

EDIT: OOOOH, I just realized you can also make recursive function calls with this!  O.O
Code: [Select]
:Lbl FUN
:keep(r1,keep(r2,FUN(r1,r2)->r3)->r2)->r1
:Return r3
Title: Re: Axe Parser
Post by: Freyaday on September 30, 2011, 06:00:03 pm
Well, two birds with one stone.
and Now we can do the perennial exercise of swapping two vars without creating a third var!
Title: Re: Axe Parser
Post by: Runer112 on September 30, 2011, 06:21:06 pm
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here (http://ourl.ca/4057/195758) seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here (http://ourl.ca/4057/195928). Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
Title: Re: Axe Parser
Post by: Deep Toaster on October 01, 2011, 12:38:09 am
That sounds really, really useful. Another update? ;D
Title: Re: Axe Parser
Post by: Binder News on October 01, 2011, 01:04:58 am
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here (http://ourl.ca/4057/195758) seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here (http://ourl.ca/4057/195928). Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.

I second that. I've been wanting more access to the stack for a while now.
Title: Re: Axe Parser
Post by: ztrumpet on October 01, 2011, 11:17:52 pm
Yea!  Awesome idea, Quigibo.  I can't wait for the next update. :D
Title: Re: Axe Parser
Post by: calc84maniac on October 01, 2011, 11:34:47 pm
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here (http://ourl.ca/4057/195758) seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here (http://ourl.ca/4057/195928). Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.
Title: Re: Axe Parser
Post by: Eeems on October 02, 2011, 12:05:35 am
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here (http://ourl.ca/4057/195758) seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here (http://ourl.ca/4057/195928). Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.
Not good if someone wants that to happen though
Title: Re: Axe Parser
Post by: calc84maniac on October 02, 2011, 12:35:30 am
That seems like a pretty good way to safely implement stack usage. But could there also be commands for more experienced coders that simply equate to push hl, pop hl, and ex (sp),hl? Because your idea is great for casual coders, but crazy people like me like to be able to squeeze every last byte out of code. Something like you suggested here (http://ourl.ca/4057/195758) seems to be a good idea for syntax, and calc84maniac suggested a good syntax for ex (sp),hl here (http://ourl.ca/4057/195928). Of course you would want to warn users about the dangers of these commands in the command list, but I don't think it's too dangerous to warrant not adding. There are so many other ways a programmer can crash their calculator with Axe, adding a new one won't really change much.
Directly using pushing/popping can definitely cause problems in the middle of expressions, and in For(const) loops for example. There are too many things subject to change in the implementation of Axe for direct stack access not to be potentially buggy unless you know a lot about the inner workings of Axe. I think Asm() will suffice for crazy hackage.

Edit: Well, I suppose Axe could keep track of all pushes/pops as well as which ones are manual and which ones are internal. It could then error if it tries to internally pop a manual push or manually pop an internal push. That's fairly safe, I guess.
Not good if someone wants that to happen though
If you're at the point where you want to access internal Axe values, you're probably better off using Asm() since that would be Axe-version-specific behavior.
Title: Re: Axe Parser
Post by: GamerMX1248 on October 05, 2011, 11:39:41 am
Any chance we will see 32 bit numbers soon, or will everything just move to floatin point vars towords the end of development?

will an input command for getting numbers instread of arrays of tokens be made soon?
Title: Re: Axe Parser
Post by: DJ Omnimaga on October 05, 2011, 04:05:08 pm
Heya and welcome here! I'm unsure what were the plans for 32 bits numbers, but I think Runer112 posted a routine that allowed combining two numbers into one to make 32 bit ones, sort of. However I'm unsure how reliable it was and where it is on the forums. Native 32 bit support would definitively be cool for those who needs high values such as scores (such as in SMB series where scores easily reach the hundred thousands) or RPGs where damages reach 9999 and where calculating defense/atk/elemental properties causes them to overflow past 65535 or 32767 like in certain SNES RPGs.
Title: Re: Axe Parser
Post by: Quigibo on October 05, 2011, 04:25:23 pm
32 bit numbers and floating point are not planned.  The z80 processor operates in 8 and 16 bit modes and any 32 bit operations have to be done in software.  There is also no hardware support for floating points, so this is even more expensive to do in software.  If you don't mind the slowdown and complexity though, there are routines you can write in pure Axe to treat 2 or more variables as single larger variables.

The alternative to floating point is fixed point notation, which is supported in Axe.  This allows numbers from about -128.00 to 128.00 with a precision of about .004.  I'd say about 90% of games can avoid using fixed point or big numbers all together, but with the recent increase of physics platformers, maybe that statistic is lower.
Title: Re: Axe Parser
Post by: Hayleia on October 06, 2011, 12:08:19 pm
Any chance we will see 32 bit numbers soon ?
I think Runer112 posted a routine that allowed combining two numbers into one to make 32 bit ones, sort of.
Yes. Here it is (http://ourl.ca/4129/155369).
Title: Re: Axe Parser
Post by: squidgetx on October 06, 2011, 03:48:54 pm
lol how did this get unstickied...

fixed. um trying to think of something else constructive to say but i can't. i'll just say that

axe is probably the most amazing thing ever to come to the 83/84 series. it is what made me join omnimaga in the first place after a year when I thought I was done with calcs, and it kept me here long enough for me to be able to join staff. it helped me get my first feature on ticalc.org, and right now all of my calc projects are in axe. it has achieved the near-impossible state of having perfect syntax, a great gui/compiler that produces almost asm quality code, and it is a great way for less experienced users to start understanding more of how the calc works. so kudos to quigibo, runer112, and omni and everyone for making this so fricking amazing.

That said I still need to figure out how all the functional programming stuff works, having trouble wrapping my head around how the compiler deals with all of it :P
Title: Re: Axe Parser
Post by: Quigibo on October 06, 2011, 06:30:20 pm
Thanks ;D

IMPORTANT SYNTAX CHANGE
I am planning to make a non-minor syntax change in the next version.  If anyone is opposed to the following, please let me know now.  This will likely cause incompatibility with a few programs, but its a very easy correction to make to your program.

The change involves the Data() command with 2-byte values.  The current syntax is Data(C1,C2r,C3) to indicate that C1 and C3 are taken to be single byte values whereas C2 is taken to be a 2 byte value.  This works okay for now because C1 and C2 are constants or constant expressions but this syntax does not work with other expressions because you could have an expression that ends with an R, like for instance nib{}r and it would be impossible to tell if you meant nib{} as a 2 byte number, or nib{}r as a 1 byte number.

Now given that, the Data command still only takes constants, but I am adding a new command for sequential data writing that CAN take expressions, and I would like the 2 commands to be consistent.  My current idea is that any expression fully enclosed in extra parenthesis will be taken as a 2 byte number and otherwise a 1 byte number.  In the case of Data, this would look like: Data(C1,(C2),C3)

I personally think this is more readable anyway and easier to type since you don't have to go through any menus.  Any thoughts or other suggestions?
Title: Re: Axe Parser
Post by: Runer112 on October 06, 2011, 06:38:15 pm
How about just using the r modifier still? Old things like Data(C1,C2r,C3) should still be allowed if the entry is a constant, but you would also allow for parentheses like Data(C1,(C2)r,C3), which would work for expressions. This seems like the best idea to me, as it not only provides backwards compatibility, but also still makes it clear that the value is to be parsed as 2 bytes.


EDIT: In case you see this Quigibo, pre-processor conditionals would be super awesome sauce. ;D
Title: Re: Axe Parser
Post by: squidgetx on October 06, 2011, 07:03:24 pm
I could go either way. I don't like the idea of losing the backwards compatibility, but on the other hand I hate typing the r every time =/ On the other hand (again) I don't use it much for large scale data entry anyway which I just do on the computer so maybe it's ok :P
Title: Re: Axe Parser
Post by: Quigibo on October 07, 2011, 03:04:10 am
@Runer:  That makes the syntax deceptively misleading.  If I allow Constr then a user would assume that Varr would work that way as well.  Since Varr is valid syntax it is definitely misleading.
Title: Re: Axe Parser
Post by: Runer112 on October 07, 2011, 11:28:33 am
I wouldn't think it's misleading. If you documented the correct way of doing it as ()r, I think this should solve most problems. New users wouldn't even think about using the old syntax because they wouldn't know it exists. And old users would be familiar with the change and would know that, since Data() used to work only with constants, you can only use the old 2-byte indicator syntax with constants. I would say that using () to specify 2-byte values carries its own problems anyways, since most programmers should know that a plain extra set of parentheses should do nothing to the code.
Title: Re: Axe Parser
Post by: Quigibo on November 01, 2011, 11:56:58 pm
Good news everybody!  I'm almost done with the new Bitmap() command! ;D

I've been working on it for nearly 2 weeks and it now handles all of my test cases and just needs some optimizing.  At just over 200 bytes, its definitely the largest and most complex piece of assembly I have ever written.  It uses no shadow registers or iy so its interrupt safe and compatible with any buffer.

You can draw sprites as small as 1x1 and as large as 224x192 which means you can move larger-than-buffer images across the screen for cut-scenes and stuff like that with ease.  Its not super fast though, its probably only slightly faster than drawing the 8x8 spites individually, but I'll benchmark it once I finish optimizing.
Title: Re: Axe Parser
Post by: Runer112 on November 02, 2011, 12:21:05 am
That sounds awesome! I guess my only question about it is if there will be a way to draw the image with logic other than overwrite, as it might be nice to be able to draw large sprites that combine nicely with the background in games and such.

And don't forget to browse the Axe issue tracker thingy (http://ourl.ca/13278) if you ever want ideas for what to fix/optimize/add. I guess the first two are more important, but the third one is always good to have content added from as well. Especially if there are small, easy things to add that would still be awesome.


EDIT: Oh, and are you completely getting rid of the old command? Because it might still be useful to some due to not requiring a large routine for things that don't really need amazing clipping logic or speed.
Title: Re: Axe Parser
Post by: leafy on November 02, 2011, 01:58:26 am
Awesome! That bitmap command's exactly what I had in mind ^^
Title: Re: Axe Parser
Post by: Quigibo on November 02, 2011, 01:21:22 pm
I think I'm getting rid of the old one... it makes me uncomfortable including a command can cause a crash even though its used in an intuitive way because TI doesn't know how to code right.

And yes, I have my own list as well as the issue tracker.  Since the current version is stable, expect the next version mid-November.  The focus of 1.1 will be "Ease of use" to make coding more basic.  The two largest things I'm tackling are arbitrary-sized sprites and tables.  So other than bug fixes, the rest of the feature suggestions will be on an "If I have time" basis.
Title: Re: Axe Parser
Post by: Freyaday on November 02, 2011, 06:04:51 pm
Boo-yah! This new bitmap will bring awesomeness the likes of which have not yet been seen! (read: more smoothscrolling) Hell, if I do it right, i could draw stuff to this thing and have an animated scrolling bitmap! Whoo!/me hugs Quigibo
Title: Re: Axe Parser
Post by: epic7 on November 02, 2011, 06:37:07 pm
Any expected release date?
Title: Re: Axe Parser
Post by: LincolnB on November 02, 2011, 06:56:13 pm
Awesome! That bitmap command's exactly what I had in mind ^^

/me is expecting greater epicness from Graviter
Title: Re: Axe Parser
Post by: parserp on November 02, 2011, 07:03:08 pm
Yay!!! this release will be epic. ;D
Title: Re: Axe Parser
Post by: mrmprog on November 02, 2011, 08:36:30 pm
/me likes where bitmap is going...
By having a sprite bigger that the screen, does that mean you can show a different part by changing the co'ords?
Title: Re: Axe Parser
Post by: epic7 on November 02, 2011, 09:07:04 pm
Yep
Title: Re: Axe Parser
Post by: mrmprog on November 02, 2011, 09:10:32 pm
 :o SuperAntiSpyware just told me that axe 1.0.5 is a trojan. ???
Title: Re: Axe Parser
Post by: C0deH4cker on November 02, 2011, 10:21:14 pm
LMAO!
Title: Re: Axe Parser
Post by: mrmprog on November 02, 2011, 10:22:24 pm
It also said rabbit sign was one. Apparently, It doesn't like calc stuff :(
Title: Re: Axe Parser
Post by: C0deH4cker on November 02, 2011, 10:25:55 pm
I think it's on crack.
Title: Re: Axe Parser
Post by: Happybobjr on November 02, 2011, 10:43:18 pm
So is Wabbit emulator.  But only the 2nd time you run it??? :P
Ya, if norton says it is a virus, just do one of those online check tools that scans it with about 50 top brand virus scanners.  All say virus free but Norton :P
Title: Re: Axe Parser
Post by: aeTIos on November 04, 2011, 09:03:19 am
So this new bitmap() command does no more use OS routines?
Title: Re: Axe Parser
Post by: Yeong on November 04, 2011, 01:03:29 pm
what is it mean by OS routines? bcalls?
Title: Re: Axe Parser
Post by: aeTIos on November 04, 2011, 02:00:24 pm
yup. Afaik, bitmap() used some bcall.
Title: Re: Axe Parser
Post by: C0deH4cker on November 04, 2011, 04:50:58 pm
I feel pretty stupid because i cant even write a decent tilemapper in axe at the moment, so bitmap() will help. My problem is that i'm starting out too advanced. Im trying to make a tilemap with nibbles instead of bytes. Something always goes wrong.

I use nib{}. what's the division/modulus trick?

Code: [Select]
[A3]->GDB1
{GDB1}/256 == A or 3?
{GDB1}^256 == 3 or A?
Title: Re: Axe Parser
Post by: Builderboy on November 04, 2011, 05:16:53 pm
Try it and see :D
Title: Re: Axe Parser
Post by: Hayleia on November 05, 2011, 02:02:34 am
Code: [Select]
[A3]->GDB1
{GDB1}/256 == A or 3?
{GDB1}^256 == 3 or A?
Wouldn't you want to divide by 16 instead of 256 ??? ?
Personally I never use those but I think it is 16.
Title: Re: Axe Parser
Post by: Builderboy on November 05, 2011, 02:04:23 am
If you want to get high/low nibble, /16 is what you want to do.  If you want to get high/low byte, /256 is what you want to do.
Title: Re: Axe Parser
Post by: aeTIos on November 05, 2011, 09:35:43 am
uh, what does the question mark do?
Title: Re: Axe Parser
Post by: LincolnB on November 05, 2011, 09:59:26 pm
Tilemappers are hard until you've written at least six gazillion of them like i have :P I swear i've had to rewrite a tilemapper for every project i've ever done, even the ones that have died...idk why. I really should reuse more code.
Title: Re: Axe Parser
Post by: C0deH4cker on November 06, 2011, 06:53:50 pm
Thanks for your help!
Title: Re: Axe Parser
Post by: epic7 on November 06, 2011, 08:34:54 pm
Tilemappers are hard until you've written at least six gazillion of them like i have :P I swear i've had to rewrite a tilemapper for every project i've ever done, even the ones that have died...idk why. I really should reuse more code.

I have no idea what that is, but if you have to create a fake number to describe how many times you've used it, it must be important. :P
I think I should learn that
Title: Re: Axe Parser
Post by: LincolnB on November 06, 2011, 08:42:06 pm
lol

A tilemapper is basically a program that lets you edit data in such a way that it makes levels for games really easy to make. I think there's some tilemapping tutorials around...
Title: Re: Axe Parser
Post by: saintrunner on November 06, 2011, 08:45:08 pm
Tilemappers are hard until you've written at least six gazillion of them like i have :P I swear i've had to rewrite a tilemapper for every project i've ever done, even the ones that have died...idk why. I really should reuse more code.

I find myself archiving different bits and pieces of some codes as separate programs. Then I reuse them with RCL later on when needed. :)
Title: Re: Axe Parser
Post by: Yeong on November 07, 2011, 07:21:38 am
I just use 2 for loops for my tilemapper XD
Title: Re: Axe Parser
Post by: C0deH4cker on November 10, 2011, 09:54:21 pm
I just made a working one with a moving character and x256 precision. Working on jumping and collision detecting. Atm, it is a nibble-based tilemapper. 0 is empty space, and 1 is a block. E is entrance and F is finish. Havent implemented any more tiles yet.
Title: Re: Axe Parser
Post by: Quigibo on December 01, 2011, 02:46:39 am
Two things:

First of all, I have been very busy recently so I've had much less time to work on this than in the past.  But the good news is I'm about to have a week off before finals so I'm going to make a promise to release "what I have" by then.  I've fixed almost every bug reported so far and added some new features, both requested, and some I think everyone will find useful.  So expect either 1.1 or 1.0.6 by no later than Dec. 9 depending on how many more things I add.

Second, I've always wanted to include a tilemapper in the language, at least for rendering and collision detection.  Unfortunately, the reason I haven't added this yet is because tilemapping is so specific to games it would be impossible to find one 'universal' solution for everyone's application.  With every extra 'feature' added to a tilemapper, it just makes it larger and slower which you might not want if you just need something simple and fast.

But now I've decided, why not just ask?  What I want to know is how useful some commands for this would be if you had to have just one routine.   Would you actually use it or would you be required to write one yourself because you need something faster or with more features?  So I'm going to compile a list of features in order from smallest/fastest to biggest/slowest.  I want to know what you use in your current games right now, and what you would plan on using in the future.  Let me know the name/names of your Axe games or even assembly game if you happen to be an asm programmer because the same principals apply.

Tiles:
 Byte tiles (256 tiles per set, 1 byte per tile)
 Nibble tiles (16 tiles per set, .5 bytes per tile)
 Compressed tiles (Some type of RLE or something)

Scrolling:
 Static (no scrolling)
 Block (scroll one tile at a time)
 Smooth (scroll one pixel at a time)

Buffer:
 Restrict to buffer (~760 bytes max)
 Any RAM location (~4000 bytes max realistically)
 Any File location (~24000 bytes max)

Color:
 Monochrome (1 buffer)
 3-Color grayscale (2 buffers)
 4-Color grayscale (2 buffers)

Sprite Size:
 8x8 (fixed)
 4x4 (fixed)
 Custom (specifiable)

Obviously I can't just make a compressed 4 color grayscale smooth scrolling tilemapper with custom sized sprites read from archive because it would be very slow, a pain to initialize, huge, and take forever to code.  There are some compromises I can make however, such as Monochrome drawing to a specifiable buffer, meaning you can have 2 tile sets and draw them once to each buffer if you need grayscale, but this is a slightly inconvenient representation for sprites because you have to separate the gray layers into different data sections.  So anyway, lets just say if you had to choose some even distribution of features, what would they be?  And would/could you use this configuration in your current games?

Another thing to keep in mind is that because a majority of the time spent rendering a tilemap is sprite drawing and not the tilemapping itself, any speed increase from this routine will be very tiny compared to if you wrote it in native Axe.  Most of the advantage will come from reduced size of code and simplicity of the programming.

My personal preferences are:
Nibbles, Smooth, RAM, Monochrome, 8x8
Title: Re: Axe Parser
Post by: Freyaday on December 01, 2011, 02:52:28 am
What's a tilemapper again?
Title: Re: Axe Parser
Post by: aeTIos on December 01, 2011, 03:09:10 am
Custom sprite size? Could come in handy for my cemetech contest entry...
EDIT: Owait... I did not read the whole post :P
My preferences are:
Bytes, smooth, RAM, monochrome, 5*5/8*8/16*16 (depends on the type of game)

EDIT2:
But eh, couldn't you also create a routine for accessing arrays? such as size([10][12])->str1 for defining the size then using str1[1][6] to access the array? That would be much less hassle to code.
Title: Re: Axe Parser
Post by: Builderboy on December 01, 2011, 03:20:36 am
Another thing to keep in mind is that because a majority of the time spent rendering a tilemap is sprite drawing and not the tilemapping itself, any speed increase from this routine will be very tiny compared to if you wrote it in native Axe.  Most of the advantage will come from reduced size of code and simplicity of the programming.

Wait is your tilemapper just going to use the built in sprite display routine?  Because displaying tilemaps by looping around a sprite command is going to be just as slow as Axe (which is reallly slow).  There are much more optimized ways to do tilemapping that would be loads faster than the way you can do it in Axe.  I had a discussion with Calc84maniac earlier and he has some really good ideas and methods for making insane fast tilemappers, maybe you can talk to him?

And my preference would be:
Byte: Because limiting a tilemap to only 16 sprites seems like a bit *too* limiting to me
Smooth: Because all other types are easy and fast in Axe
RAM: Because its easy to set up, and tilemaps can span all of RAM if you really needed them to (App with appvar map)
Monochrome: Assuming you can draw to arbitrary buffers, there wouldn't be too much loss of functionality
8x8: Because 4x4 is barely ever used, and arbitrary sprite size would be way too slow.  16x16 might be a better option that 4x4 too, although I think 8x8 is still the best solution.
Title: Re: Axe Parser
Post by: Quigibo on December 01, 2011, 04:41:06 am
Hmm... I guess that's true.  I'm using the exact same type of optimization for the new bitmap command (which technically you can think of as a 1x1 smooth scrolling tile mapper, and it can actually be easily used for this purpose :P).  Its just that although the routine will be insanely fast, maybe up to a 2 times speed up, it will also be insanely large.  Just the subroutine of the bitmap command is already 210 bytes and the tilemapper would end up at least that size I'm sure.

Thinking about this again, I might make this an offical included Axiom like Memkit because then it could include multiple versions, convenient tokens, and use the Axiom variables for optimization...
Title: Re: Axe Parser
Post by: Darl181 on December 01, 2011, 10:34:20 am
I generally end up using:
Byte tiles (Essence is the exception)
Smooth scrolling
Any RAM Location (this would mean pointers would work?)
Monochrome
4*4 tiles (could be just me, but pretty much every single platformer project of mine is 4*4 tiles XD)

Sounding epic, or should I say, "1337"
(137th page :P)
Title: Re: Axe Parser
Post by: ztrumpet on December 01, 2011, 03:16:01 pm
Byte, Free RAM, Monochrome, 8*8 sounds the best to me.

I agree that this should be an Axiom; it's "too higher level" in my opinion to be a regular Axe command.
Title: Re: Axe Parser
Post by: Builderboy on December 01, 2011, 05:16:36 pm
And Axioms could give you higher flexibility too, while still keeping speed up.  For example you could have 2 different Axioms for 4x4 vs 8x8
Title: Re: Axe Parser
Post by: ikemike on December 01, 2011, 07:12:27 pm
EDIT: Answered in chat.
Title: Re: Axe Parser
Post by: aeTIos on December 02, 2011, 01:09:01 pm
Huh?
Maybe you should keep your question and the answer here.
Title: Re: Axe Parser
Post by: Deep Toaster on December 02, 2011, 10:10:54 pm
Tiles: Byte or nibbles compressed with RLE. It really depends on the game.
Scrolling: Smooth. Always smooth-scrolling, but the number of pixels scrolled at a time varies.
Buffer: 768. It's a convenient number even when I'm not dealing with a screen.
Color: Three-color grayscale.
Sprite size: 5x5, 8x8, and 8x12 are my most common sizes.
Title: Re: Axe Parser
Post by: willrandship on December 09, 2011, 12:09:49 am
Hmm, on the smooth scrolling thought: What about having arbitrary-sized (or large but fixed) graphics buffers, which you can draw a portion of which you point to? As in:

DispGraph(X,Y,Buf) would draw a 768-byte section of Buf, starting with X,Y as the top-left. Edge detection would be in-code, or it could even loop. Whichever. That way, you could tilemap or hand draw an entire area, very easily implement smooth scrolling and parallax effects, among various other features.

BBC Basic does it that way, but only has one graphics screen. The actual buffer is somewhere in the 32768x32768 range or higher, I don't really remember.
Title: Re: Axe Parser
Post by: jacobly on December 09, 2011, 12:23:03 am
Actually BBCBasic uses a 768 byte buffer (the manual is a little ambiguous). It is just that coordinates range from -32768 to 32767 (I think). Commands are just scaled and clipped to that buffer according to some settings. Also, a buffer that big would never even fit in ram and rom combined (2^16 * 2^16 / 2^3 = 2^29 bytes > a theoretical maximum of 2^22 bytes (assuming there were actually 256 separate pages, which is not even close to true)).
Edit: Kind of like how TIOS does it, with a ridiculous graphing area, but a small viewing window.
Title: Re: Axe Parser
Post by: willrandship on December 09, 2011, 12:25:11 am
That's too bad :(

Still, I liked the ability to draw as if there were. Also, it was *just* clipping, not scaling. The scaling occurs because the virtual screen res is 320*240 or thereabouts (depends on your MODE setting)
Title: Re: Axe Parser
Post by: jacobly on December 09, 2011, 12:53:34 am
Quote from: BBC BASIC.chm (Topic GBUF)
All drawing operations operate on a 768 byte buffer in memory.
So there *must* be scaling if there are more than one logical unit (coordinate) per physical unit (pixel).
Title: Re: Axe Parser
Post by: Quigibo on December 10, 2011, 08:11:50 am
I know I said I'd release it tonight, but I think it will have to wait until the morning.  I crossed every single thing off the list that needed to be done except for one thing which came up recently, which is the tilemap sprite format bug.  That and updating the doc/commands list.  I won't have time for table stuff until the next release, but everything else should be in this one as well as some other really cool features.  One thing I just added; you can now easily write a tiny program that can print its own source code using a more general var absorption (which used to be limited to just picture vars).  No you can can import Pics, Programs, Appvars, and Strings directly into the executable!

Anyway, its past 5am here now so I have to get to bed.
Title: Re: Axe Parser
Post by: epic7 on December 10, 2011, 08:50:36 am
Release what?/me is expecting something awesome
Title: Re: Axe Parser
Post by: Anima on December 10, 2011, 09:02:27 am
Release what?/me is expecting something awesome
I think he will release a new version of Axe Parser.
Title: Re: Axe Parser
Post by: epic7 on December 10, 2011, 08:43:21 pm
Awesome!! NEW AXE

I was the first person to download the new version :D

Now...
Is absorbing appvars like
[pic1]->pic1
but for appvars?

And what are preprocessor conditionals?

Also, what does single argument for loops can now take any expression as an argument mean?
EDIT: Oh, you mean single argument like "executes the block of code exactly a set number of times."

Also, yet another question, what is
"Now able to use Return in a single argument for loop."
:P

Edit:
Yet another yet another question is:
What does select() do? I don't get what the commands list is saying
:P
Title: Re: Axe Parser
Post by: jacobly on December 10, 2011, 08:58:51 pm
Awesome!! NEW AXE

I was the first person to download the new version :D
And I was the second!

Now...
Is absorbing appvars like
[pic1]->pic1
but for appvars?
I believe so.

And what are preprocessor conditionals?
Instead of commenting out code like this:
...
.Code
...

You can do something like this:
...If condition
.Code
...

And it will only comment out the code if the condition is true (condition must be a constant).

Also, what does Single argument for loops can now take any expression as an argument mean?
For(A) .loop A times
used to not work (because it wasn't implemented)... now it is!

Also, yet another question, what is
"Now able to use Return in a single argument for loop."
:P
This used to be an error (because it wouldn't work):
For(10)
If A+1→A=B
Return
End
End
Now, Quigibo has found some amazing way to make it work, so it is allowed ;D.

btw, most of this info is probably in the command list ;)

Edit:
Edit:
Yet another yet another question is:
What does select() do? I don't get what the commands list is saying
:P
Select(EXP1,EXP2) finds the value of EXP1, stores it into some secret place, then it evaluates EXP2, and lastly, it looks in that secret place and returns the original value of EXP1.
For example:
Select(A,B→A)→B swaps A and B.
A is stored to a secret place, B is stored to A, then the value of that secret place (the original value of A) is stored to B.
Title: Re: Axe Parser
Post by: Quigibo on December 10, 2011, 09:02:37 pm
Here are some cool things you can do with the new version:

Code: [Select]
prgmAA
:.A
:ClrHome
:[prgmAA]->A
:While {A}
:Disp >Tok
:A+1->A
:End
This one prints out its own source code.  Try it :P

And now 3 examples of places the Select() command can be useful.

Code: [Select]
Select(A,B->A)->BSwaps the values of A and B faster and without needing any extra temporaries.

Code: [Select]
Select(A,+1->A)This is the C style "A++" meaning it increments A but returns the value of A before you actually incremented it.
Note: A+1->A-1 is more efficient in this case, but if it was A+8 for instance, the above is better.

Code: [Select]
:Lbl FOO
:Select(r1,Select(r2,MYLBL()->A)->r2)->r1
:Return A
:Lbl MYLBL
:<stuff including more calls to FOO>
You have now created a recursive subroutine that doesn't need to be called in any special format.  Just call FOO(1,2) or whatever.  Something similar to this will eventually replace the current "recursive subroutine" because it has way more advantages:
 - You only need to save values you know are going to change.
 - Optimizes better when used more than one place.
 - Compatible with non sub() form calling.
 - You don't have to remember or get confused that a certain subroutine requires being called a special way.

EDIT:
Quote
This used to be an error (because it wouldn't work):
For(10)
If A+1→A=B
Return
End
End
Now, Quigibo has found some amazing way to make it work, so it is allowed ;D.
That was super easy.  I was already keeping track of how large the stack was.  All I had to do was pop N times for every N nested for loops (the single argument variety) prior to returning.  ;D
Title: Re: Axe Parser
Post by: jacobly on December 10, 2011, 09:59:25 pm
Quick question: do ...'s nest? They obviously can't normally (start and end are indistinguishable) but with preprocessor conditionals they theoretically could.  Not that I need it yet, but it would be a good thing to know.
Title: Re: Axe Parser
Post by: epic7 on December 10, 2011, 10:17:16 pm
Jacobly did
Select(A,B->A)->B
Instead of what Quiggs did,
Select(A,B->A)->A
To swap a and b

Which one works?
If you did
Select(A,B->A)->A
Wouldn't it store B to A, and then restore A's old value back to A, making it do nothing?
Title: Re: Axe Parser
Post by: ztrumpet on December 10, 2011, 10:41:48 pm
Select(A,B->A)->B is the correct one.

Quigibo, is there a "...End"?  (There isn't one on the commands list, though it looks like there should be one.)
Title: Re: Axe Parser
Post by: Runer112 on December 10, 2011, 10:42:46 pm
No need for ...End, because ... already ends the comment block whether or not it's a conditional.
Title: Re: Axe Parser
Post by: epic7 on December 10, 2011, 10:44:21 pm
I believe he said it wouldn't need one.  (ninja'd)

And for the select() part, Thats what I thought. (-Use ->B)
Quigibo, you should fix that post :P
Title: Re: Axe Parser
Post by: calcdude84se on December 10, 2011, 10:48:21 pm
Or have someone else fix it for you! (I just fixed it)
I take it that "constant" means any expression that lacks variables? So I could, say, do "...If °A>L6"?
Title: Re: Axe Parser
Post by: Freyaday on December 17, 2011, 11:03:02 pm
/me saw the new Z-Select command and giggled with glee
Title: Re: Axe Parser
Post by: epic7 on December 17, 2011, 11:04:55 pm
Z-Select, is that the new command? Now that I have the new axe, I'll se what that does.

I love the new awesome progress bar! I compiled multiple times so I could watch it :P

/me was the first downloader for this version, too :P

Wait there's a Z-select, Frey?
I just saw Z-Test.
I don't fully understand, but does this work?
Z-Test(A=1,Lbl 1, Lbl 2)
Does that mean
If A=1
Goto 1
Else
Goto 2
End
Or something like that?
Title: Re: Axe Parser
Post by: Quigibo on December 17, 2011, 11:19:20 pm
So surprise surprise, I added a switch statement last minute, it took me under an hour to have it fully functional.  Its also probably the only new feature this version that needs a tiny bit of explaining.

So basically, Z-Test() is a command to built what's called a "jump-table", or if you prefer, a "goto-table".  It basically creates an array of places to "jump" to and then jumps to the Nth item in that list.  That's about it.  The reason this is useful is that otherwise, you have to do something like:

Code: [Select]
:If A=0:
:<code>
:ElseIf A=1:
:<code>
:ElseIf A=2:
:...and so on...

So when you have a lot of consecutive comparisons, it saves a lot of space in the program.  But the best part is the speed savings.  Normally, you would have to make N comparisons (or log(N) if you're smart :P) in order to figure out which of N pieces of code to execute.  This method however, makes a single comparison!  So no matter how large your jump table is, it always takes the same amount of time to get to the code you want to run.

All of this fun is overhead though, and I will say you should only switch over to a Z-Test() if you have 4 or more cases to check against, otherwise it could be larger and slower.

If you want this to be a call table instead of a jump table, simply put it in a subroutine and call it:

Code: [Select]
:MyTbl(A)
:
:Lbl MyTbl
:  Z-Test(r1,A,B,C,...)
:  <handle errors>

The error handling is for when the number you're testing is outside the range of the table.  This isn't necessarily an error if you're going to use that  to your advantage, but its a good sanity check to have if you're expecting the number to be in the range of your labels.  If you are absolutely positively sure your number is in this range (like you just read a nibble which is always in the 0-15 range and you have 16 labels) then you don't need any code there.

Also as I was typing this, I just realized I forgot to show an error when you try to use this in a For(expr) loop.  DO NOT USE Z-TEST HERE!  You will get a memory leak and eventually a ram clear.
Title: Re: Axe Parser
Post by: epic7 on December 17, 2011, 11:21:33 pm
Cool! I did those repeating else if's 17 times in 2 places for RoboGun O.O

So
Z-Test(A,1,2,3
Would go to Lbl 1 if A=0, Lbl 2 if A=1, and so on?
Title: Re: Axe Parser
Post by: Quigibo on December 17, 2011, 11:26:26 pm
Exactly :)
Title: Re: Axe Parser
Post by: alberthrocks on December 17, 2011, 11:28:32 pm
I think the big thing to note about this feature is that values start from zero.
That is, when A is 0, the first label is jumped to; when A is 1, the second label is jumped to, and so on. :)

I'm still slightly confused myself - is this a Lbl within a Lbl?
Title: Re: Axe Parser
Post by: Quigibo on December 17, 2011, 11:30:41 pm
I don't know what you mean by that...  but its just a command that takes label names for its arguments.  The interrupt command also does this: fnInt(LBL,0) for instance.
Title: Re: Axe Parser
Post by: alberthrocks on December 17, 2011, 11:39:28 pm
I don't know what you mean by that...  but its just a command that takes label names for its arguments.  The interrupt command also does this: fnInt(LBL,0) for instance.
Oh.... silly me :P I didn't read it quite carefully, and parsed it (get it?) as:
Code: [Select]
Lbl FAKE
Z-Test(r1, 1, 2, 3)
Lbl 1
Lbl 2
Lbl 3
Return
Sorry for my mishap! :)

The correct example should be this:
Code: [Select]
.SLCTTEST Select-like cmd test
.Should print "Hi!"
MyLbl(0)
Pause 2000
.Should print "Long time, eh?"
MyLbl(1)
Pause 2000
.Should print "Can't wait to!"
MyLbl(2)
Pause 2000
.Should print "Laugh out loud"
MyLbl(3)
Pause 2000
.Should print "It is now Friday"
MyLbl(4)
Pause 2000
Lbl MyLbl
.Just in case...
ClrHome
Z-Test(r1,HI,LTE,CWT,LOL,TGIF)
Return
Lbl HI
Output(0,0,"Hi!")
Return
Lbl LTE
Output(0,0,"Long time, eh?")
Return
Lbl CWTG
Output(0,0,"Can't wait to!")
Return
Lbl LOL
Output(0,0,"Laugh out loud")
Return
Lbl TGIF
Output(0,0,"It is now Friday")
Return
Title: Re: Axe Parser
Post by: Deep Toaster on December 19, 2011, 01:23:03 pm
That new progress bar is awesome :D And it's great how those really old bugs are now gone all of a sudden.
Title: Re: Axe Parser
Post by: epic7 on December 19, 2011, 03:29:59 pm
Ah, Ive found a place where I can use Z-Test :D
Title: Re: Axe Parser
Post by: Matrefeytontias on January 04, 2012, 12:44:44 pm
I try since a little time to define my own token with an Axiom (as you did with Memkit and new(), load() etc), and someone said me that I must use the hook 9BC8 to modify OS tokens' name. But it seems that Axe, with his own hook, erase the current hook, so I can't change tokens like Axe do. Do you think that we'll can define our own tokens with Axioms in your next version ?
Title: Re: Axe Parser
Post by: kindermoumoute on January 04, 2012, 12:58:31 pm
Yes, It could be very nice to see token replacements for axioms, because currently it's not intuitive to use commands without any meaning. ;)
Title: Re: Axe Parser
Post by: Builderboy on January 04, 2012, 01:33:30 pm
This idea has already been presented and rejected by Quigibo, simply because of speed reasons that would slow down the editing process unfortunately. 
Title: Re: Axe Parser
Post by: Runer112 on January 04, 2012, 01:34:57 pm
I am fairly certain that it can be done with minimal speed loss if token replacements are somehow cached intelligently. In fact, I'm trying it right now. ;)
Title: Re: Axe Parser
Post by: Quigibo on January 04, 2012, 08:46:50 pm
But Axe would also have to parse the original file to find all the axioms each program uses.  And I mean an actual parse due to the newly added conditional comments.  I could instead require axioms to be at the top of the source but then you would again not be able to use conditional comments on them...
Title: Re: Axe Parser
Post by: Runer112 on January 04, 2012, 09:07:01 pm
I think you can safely ignore whether or not the Axiom reference is in a comment. Even if it is, the program probably still uses commands from it somewhere in the source and the token replacement should be used for clarity whether or not it is commented out.

EDIT: And if the programmer is doing crazy stuff like a conditional if-else comment to include only one of two Axioms that replace the same tokens... Well that's a little nuts and I think they can deal with that not being supported. :P
Title: Re: Axe Parser
Post by: Freyaday on January 05, 2012, 03:33:51 am
I think you can safely ignore whether or not the Axiom reference is in a comment. Even if it is, the program probably still uses commands from it somewhere in the source and the token replacement should be used for clarity whether or not it is commented out.

EDIT: And if the programmer is doing crazy stuff like a conditional if-else comment to include only one of two Axioms that replace the same tokens... Well that's a little nuts and I think they can deal with that not being supported. :P
Have you seen optimized Axe code? It is nothing but crazy!
Oh, wait.
( :P )
Title: Re: Axe Parser
Post by: Quigibo on January 05, 2012, 07:02:46 am
Announcement!

I spent several hours today thinking about the logistics, difficulty, and maintainability of creating an "Axe Shell" and then started to code my ideas.  I am pleased to announce that it appears this may become a reality in the next version.  I currently have about half the commands working with more to come.  I will explain some of the logistic problems I faced later.  This will be a beta feature to give me a chance to stabilize potential errors I might have made.  It is not recommended to distribute the executable until it stabilizes.

So first of all, what am I talking about exactly?  Ion, Mirage, and Doors all have a GUI application to act as a shell but Axe does not and I'm not going to add one either.  What I'm referring to, is that instead of copying all the gigantic Axe routines into each program (such as DispGraph, Sprite drawing, Sound, Archive reading, and literally everything non-trivial) the program will use the Axe app itself to find and call the big routines.  This of course loses platform independence in a sense, but so do all the other shells.  This really isn't a shell though, its more of a framework.  Which is why I'm call this the Axe Framework or AXF.  With the bulk gone, this can reduce programs by up to 3000 bytes!  In general, I'm seeing 10-20% reductions in my testing suite. :)

Now for some logistics.  The way it works is that the program gets the standard ion header plus some extra code to locate the Axe app, show the message "Axe Required" if its not found, and do all the necessarily paging.  Its comparable in size to the DCS or App header.  This is both so that I don't have to actually create a shell and its small enough for a header anyway.  But the looming problem is to map the Axe calls to physical addresses in the app.  As I improve and optimize the Axe routines, the addresses will change, causing old executable to need to be recompiled to work.  Normally to fix this, the other shells provide a fixed jump table that then jumps from there to whatever moving code it eventually needs to reach.  But the problem with Axe is that many routines "hijack" other routines to skip parts of code rendering a fixed jump table unusable.  What's worse, the axiom system of replacing absolute and native jumps and calls makes it impossible to execute over it.

To solve both of these, I have a table of subroutine "segments" that have all the code that can be skipped over and then hijack the original routine.  Some routines I do have to make complete or partial copies of, but that's alright.  In those cases, I leave a bit of buffer for future optimizations and changes.  The only other issue I'm worried about is how Axioms will interact with the framework.  Most Axioms should work, but a few really complicated ones could fail if they jump into routines past the entry points.  But that is super hackish anyway.

Some other things on my mind:  I could speed up some routines since the size of the routines no longer matters.  Routines like multiplication are easy to unroll, but others like DispGraph are still limited by the screen driver.  Also, this framework is just as useful to assembly programmers!  I have doubts about how many would actually want to use it though, but nonetheless it is now possible to do that.

Thoughts and suggestions?
Title: Re: Axe Parser
Post by: thydowulays on January 05, 2012, 07:25:33 am
This is amazing! I highly doubt you have to worry about anyone not using your stuff Quigbo, especially if it reduces their programs by 3000 bytes. I don't understand all the way though. It uses the Axe app itself to find and call the big routines? Does that mean people won't really notice any difference programming, but there is a huge one? Or there will be a completely new way to program in Axe? Anyways, I definitely support this, and will be getting the executable as soon as it's stable!
Title: Re: Axe Parser
Post by: TIfanx1999 on January 05, 2012, 08:17:25 am
That's pretty sweet! If you can manage to make it stable I'm sure programmers will love you for the reduced program size. =)
Title: Re: Axe Parser
Post by: MGOS on January 05, 2012, 09:20:00 am
This sounds great so far! I love it when the executeble's size is reduced without having to optimize a lot and make the code unreadable.
But will it be also possible to compile the programs to noshell? Because I like that the executable doesn't need anything else and another app to transfer takes a lot of time. Most of my friends don't understand much about the calculator, they only want to play my games and get confused when they need multiple files ^^ ... Now, it is only one program, they know how to execute it. They don't have watch out to delete accidentally the axe app or so. That was one main reason (beside better speed and graphics) for me to switch from xLib to axe.
Title: Re: Axe Parser
Post by: ztrumpet on January 05, 2012, 09:57:28 am
This sounds great.

How does it work when running programs from a shell, such as Doors or Mirage?  Does it play nice, or does it just RAM Clear?
Title: Re: Axe Parser
Post by: C0deH4cker on January 05, 2012, 10:33:06 am
He said that it has an ion header, so will be executed as an ion program, but there is extra asm code included to access the Axe app's routines, so it should be compatible with all ion-compatible shells.

I assume that this will be another option to compile for, like No shell, Ion, MirageOS, DCS, Axe, App, right?
Furthermore, I believe that with custom token replacements, programmers wouldn't mind going into Axe settings and scrolling through a list of Axioms with custom tokens and doing an "Install custom tokens" process.  As long as it is relatively simple, it wouldnt be much of a hassle.

An extra field could be added to axioms that include custom tokens to designate it as one that has them. Then, when the user goes into the token settings in the axe app, only the axioms with the token replacement field would be shown. The user could select which axioms to use for token replacement with checkboxes.

This would lessen the hardship of coding it to automatically parse the program and look for Axiom() and looking through each axiom included for token replacements.

What do you think about this option? Is it viable?
Title: Re: Axe Parser
Post by: Builderboy on January 05, 2012, 03:35:27 pm
As long as there is still an option to compile programs normally without the Axe dependency I think this is a great idea ^^
Title: Re: Axe Parser
Post by: Deep Toaster on January 05, 2012, 03:56:48 pm
AXF sounds like a great idea, especially how it cuts down so much of a program's size. The biggest problem I can see is the confusion this could cause for users who download games made with Axe. There would essentially be two sets of Axe programs, those that require the Axe shell and those that do not, and people could get confused by that.

My suggestion is that AXF be released under a totally different name, even though the language it uses is called "Axe." I think AXF programs should be categorized separately from ordinary Axe programs (such as on ticalc), and if possible to have Axe and AXF games be considered two completely separate types of programs (such as in program descriptions).
Title: Re: Axe Parser
Post by: ztrumpet on January 05, 2012, 04:07:03 pm
My suggestion is that AXF be released under a totally different name, even though the language it uses is called "Axe." I think AXF programs should be categorized separately from ordinary Axe programs (such as on ticalc), and if possible to have Axe and AXF games be considered two completely separate types of programs (such as in program descriptions).
I agree with Deep here.  The names AXE and AXF are too close to avoid confusion.  The shell itself sounds cool, though.
Title: Re: Axe Parser
Post by: Runer112 on January 05, 2012, 04:54:43 pm
I've been fantasizing about such a system as this for a long time, as it can be used both to conserve executable size and to allow for the use of larger but faster routines. However, your post wasn't very clear to me regarding one important matter: Will the old compilation style remain?

One thing that always turned me off about some programs is their dependency on a shell, especially when they hardly needed any of the routines in it. Although I always have Axe on my calculator, others may not, and they may not want it. And if you're compiling your code as an app and not right up against the size limit, you can afford to have the routines included in your app.

I think it would be best for Axe users to be able to control exactly how Axe compiles their program: with size-optimized included routines, with speed-optimized included routines, or with speed-optimized external routines. I would then advise programmers to follow logic somewhat like this as a guideline to compile and release their work:

Title: Re: Axe Parser
Post by: Quigibo on January 05, 2012, 05:33:26 pm
To clarify, this is simply another option in the shell menu.  The ion header is, I feel, the best option for Axe programs because they are compatible with ALL shells and can still be run from the home screen with Asm().  There is not currently a way to use the external routines from an app, although I could add another option for that later.  Runer, as much as I agree that that would be ideal for advanced users, its quite complicated to implement and would be confusing to new users.  I would like to keep it as simple as possible for the user and have Axe determine these things automatically with common case defaults.

I am actually almost out of space in the Axe app as of now.  The first page (all executable code) is completely full and I have to optimize sections of code just to add more features.  The 2nd page (all data) only has about 3kb of space which is not a lot for future expansion.  I will have to consider paged calls to the 2nd page soon if I can't find more things to optimize.

I have not tested this with Mirage or Doors yet.  I assume they will work, but you might have to disable interrupts at the start of the program (or I might have to add that as part of the header).

Quote
I highly doubt you have to worry about anyone not using your stuff Quigbo, especially if it reduces their programs by 3000 bytes.
I was referring to asm programmers not wanting to use it because usually they have different IO preferences and don't like dependencies.  But I guess people did use the ion routines so maybe it could still be useful to them.

I guess I could change the name then.  I was originally thinking of calling it "Axis" but that has the same issue.  How about "Toolbox"?  Its kinda related physically since it's a 'box' around an 'axe'.  I dunno, does anyone have other ideas for one?
Title: Re: Axe Parser
Post by: ztrumpet on January 05, 2012, 09:27:21 pm
The ion header is, I feel, the best option for Axe programs because they are compatible with ALL shells and can still be run from the home screen with Asm().
I saw the "ALL" in all caps and I felt the need to point out not all shells work; all major, current shells do, but I'm pretty sure shells like CrunchyOS do not.

Edit:  I think it's probably too close, but I just though of the name AxLE - the Axe Language Extender.
Title: Re: Axe Parser
Post by: TIfanx1999 on January 05, 2012, 09:33:51 pm
I think AXF is fine IMHO.
Title: Re: Axe Parser
Post by: Freyaday on January 05, 2012, 10:01:03 pm
Sounds cool! I really like the idea of having options to compile with Speed ops, size ops, or external commands.
Name Ideas:
Tree
Hatchet
Chainsaw
Title: Re: Axe Parser
Post by: parserp on January 05, 2012, 10:04:05 pm
Name Ideas:
Tree
Hatchet
Chainsaw
O.o
maybe it could be called umm, ?
Title: Re: Axe Parser
Post by: Happybobjr on January 06, 2012, 12:14:21 am
anything on improving speed makes me happy :D
Title: Re: Axe Parser
Post by: Deep Toaster on January 06, 2012, 09:38:02 am
anything on improving speed makes me happy :D
I don't think it would make programs any faster, but I may be wrong. It could make them much smaller though.
Title: Re: Axe Parser
Post by: kindermoumoute on January 06, 2012, 10:35:13 am
I don't think I'll use this framework, but it could be nice.
But currently, why not try to use GUI application of DCS7, mirage OS,... when the shell is selected in Axe parser option ?
Title: Re: Axe Parser
Post by: Metallica on January 06, 2012, 12:13:57 pm
I agree with Kindermoumoute. That would be a great idea.
Title: Re: Axe Parser
Post by: chickendude on January 06, 2012, 02:59:37 pm
Another possibility would be to create a smaller Axe shell (or something xLib-style, containing the necessary routines) for people who don't program with Axe or even talk to Kerm about including support for Axe routines in DoorsCS (are there any other shells currently still in development? Ion comes with the source...).
Title: Re: Axe Parser
Post by: DJ Omnimaga on January 06, 2012, 05:17:06 pm
Nope DCS7 is the only one still under active development. MirageOS 1.3 had no news since 2005 or so, Crunchy since 2004 and Ion since 2002 I think.
Title: Re: Axe Parser
Post by: FinaleTI on January 06, 2012, 05:25:23 pm
All I can say is, I love the idea of the Axe Framework. It could make games smaller and faster, and could enhance Axe IDEs *cough*XDE*cough* by allowing them to be tested by compiling with AXF, then finally compiled a different way if desired, among other things.
Title: Re: Axe Parser
Post by: chickendude on January 07, 2012, 08:00:40 am
Nope DCS7 is the only one still under active development. MirageOS 1.3 had no news since 2005 or so, Crunchy since 2004 and Ion since 2002 I think.
And of those, only ion released the source, though it looks like BrandonW (or someone) disassembled MirageOS:
http://brandonw.net/calcstuff/MirageOS.txt
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 12:24:01 am
Well it took countless hours of work to get it working right, but it works!

What works? Take a look at the screenshot. ;D



(If you'd rather just read what it is)
Spoiler For Spoiler:
Custom Axiom tokens! :D
Title: Re: Axe Parser
Post by: ZippyDee on January 09, 2012, 12:49:08 am
That is....pretty damn amazing.
Title: Re: Axe Parser
Post by: kindermoumoute on January 09, 2012, 01:54:05 am
Good job runer 112 ! Thx to work on it. :)
Title: Re: Axe Parser
Post by: LincolnB on January 09, 2012, 09:50:09 am
very cool, my friend.
Title: Re: Axe Parser
Post by: TIfanx1999 on January 09, 2012, 11:37:40 am
Nice work Runer! =)
Title: Re: Axe Parser
Post by: ztrumpet on January 09, 2012, 03:09:18 pm
Wow, that's awesome!  How'd you do it?
Title: Re: Axe Parser
Post by: Matrefeytontias on January 09, 2012, 03:12:40 pm
Yeah, I would like know too  :o
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 03:25:49 pm
Pretty much, I detect whenever the source code open in the program editor has changed to become an Axe program (this mainly applies to the action of opening an Axe program). I then scan the entire program for any AsmComp( tokens (that's #Axiom( in Axe). For each one found, I check that it's in a valid position (e.g. not in the middle of a line, in a string, etc.) and then attempt to locate the appvar. If found, I skip to the end of the Axiom and check for a second header after the standard Axiom footer that signals that the Axiom includes token replacements, and if so, these token replacements are cached in RAM. Then, it's just the simple matter of running the token hook as usual, but checking this area of RAM in addition to Axe's built-in token replacements. :)

Although to be fair, the whole process wasn't a simple matter. :P Every time I wanted to test a change, I had to hex-edit my hook into the Axe application. And I tried to do the whole thing in a very optimized manner, which means trying multiple code possibilities every step of the way. I must've spent over a dozen hours on this thing.


One thing that this upgraded hook does not do is dynamically check for Axioms while the program is being edited. Adding such a feature would be a bit of a pain and probably add at least 50 bytes and slow down the hook, so I figured it's just best to leave it out. If you want to reload Axioms, it's easy enough to do so by closing and reopening the program.
Title: Re: Axe Parser
Post by: Matrefeytontias on January 09, 2012, 03:27:51 pm
Awesome, just awesome :D

EDIT : Maybe I said it 'cos I'm just a beginner  XD
Title: Re: Axe Parser
Post by: kindermoumoute on January 09, 2012, 03:32:19 pm
Wow.. and what happen if :
- An axiom use same token than Axe parser ?
- two axiom have same tokens ?
 ;D
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 03:37:23 pm
Axe gets first priority for token replacements. This is partially for speed reasons, and partially because there's not much sense in overriding an Axe token since you cannot (yet) override the Axe command. After that, Axioms get priority in order of appearance in the source code.
Title: Re: Axe Parser
Post by: Deep Toaster on January 09, 2012, 03:41:10 pm
Awesome ;D Where do you put the replacement token in the Axiom?
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 03:44:43 pm
Currently, I'm putting cached Axiom token replacements in appBackUpScreen, because I know that the OS will not touch this. Except for when you run an app, as the name suggests, but at that point you've exited the program editor. I still need to ask thepenguin77 if zStart wants this area of RAM when editing programs, in which case I should probably find another spot.
Title: Re: Axe Parser
Post by: Deep Toaster on January 09, 2012, 03:47:12 pm
I meant how would you define a replacement token when you're writing an Axiom that should have one?
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 03:57:18 pm
Oh sorry, I misread your post. :)

Basically, your standard Axiom looks like this:


.dw $C0DE
;Axiom commands go here
.dw 0


If you don't want any token replacements, you don't have to change a thing. This keeps backwards compatibility, which is always nice.
If you want token replacements, the layout extends to something like this:


.dw $C0DE
;Axiom commands go here
.dw 0
.dw $C0DE
.dw Tokens_End-Tokens
Tokens:
;For as many token replacements as you want:
.db HookLowByte, HookHighByte, StringLength, "String"
.db HookLowByte, HookHighByte, StringLength, "String"
Tokens_End:


HookLowByte and HookHighByte are different from the usual token values. To figure them out, I use a mix of this (http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:9BC8) in combination with this (http://tibasicdev.wikidot.com/tokens). And StringLength is the length of the replacement ASCII string, which should not include a null terminator.



EDIT: Here's an example, taken from the Axiom I showed in the screenshot. It replaces GridOn with GrayOn, X₃ᴛ with Buf1, and Y₃ᴛ with Buf2.


.dw $C0DE
;Axiom commands go here
.dw 0
.dw $C0DE
.dw Tokens_End-Tokens
Tokens:
.dw 10*2+$0384
.db 6,"GrayOn"
.dw 14*2+$0220
.db 4,"Buf1"
.dw 15*2+$0220
.db 4,"Buf2"
Tokens_End:
Title: Re: Axe Parser
Post by: Matrefeytontias on January 09, 2012, 04:02:52 pm
I'm a little lost ...

If I try it right now, this will not work because I need an additional code which you made, right ?
Title: Re: Axe Parser
Post by: Runer112 on January 09, 2012, 04:09:00 pm
Axe doesn't have this functionality yet, which is why I spent the time to make a prototype version that does. ;) I haven't released it anywhere, since I think Quigibo would rather I give it to him and let him possibly tinker with it a bit and then release it officially. And existing Axioms don't have any token replacement data, so even with this new system, they will act just like they do currently. Only Axioms designed with this new system in mind will have token replacements. However, it is possible to tack on token replacement data to old Axioms if you properly resize the appvar and add in token replacement data.
Title: Re: Axe Parser
Post by: Freyaday on January 09, 2012, 06:36:33 pm
Sounds really, really cool. I hope this gets implemented!
Title: Re: Axe Parser
Post by: Quigibo on January 10, 2012, 03:24:22 am
Very cool!  I'd like to see that code, how you accomplished it.  And I don't mind if you show off the code here, I'm always willing to share code.  The only reason I haven't open-sourced Axe is simply because of standardization.  If other people were to modify and release the parser you could start seeing programs that each need a special version to compile and it can get annoying, these versions wouldn't get official updates either without a very active developer.  By keeping it closed, I can ensure reverse and forward-compatibility in a simple single version.  If you want to know how any chuck of the code looks though, I can always share.

Some things I'm particularly curious about:
- How do you know if the program has just been opened using only the token hook?  Would this process work during an instant scroll as well?  Even in DCS?
- What do you do (or prefer me to do) when there are more replacements than can fit in the buffer?  Especially with long names, it could only hold 80 or so max.
- Are you sure this doesn't slow down the scrolling too much with all these replacements?
- The token numbers are difficult for developers to type in manually, any ideas of how I could generate a list of equates?

Unrelated, but the other thing I realized a while ago is that its too difficult for Applications to use the framework.  All the absolute labels are in the $4000 range, and since an app is running here, I would have to generate an entirely new copy of the pseudo-lookup-table in order to change these addresses to the $8000 range.  And since space is a problem, I doubt I will be able to do that.
Title: Re: Axe Parser
Post by: Runer112 on January 10, 2012, 03:41:19 am
Code vomit:

Code: [Select]
.nolist
#include "ti83plus.inc"
.list

#define p_GetArc $55E7
#define p_ReadArcApp $5658
#define p_CopyArc $568D

#define TokenHook_Temp appBackUpScreen-2
#define AxiomTokens appBackUpScreen

.org $71E0

TokenHook_NotAxe:
ld bc,('A'<<8)+(StrPROGRAM&$FF)
TokenHook_CheckIfChanged:
ld de,textShadow
ld a,(de)
xor b
ret nz
push hl
ld h,StrPROGRAM>>8
ld l,c
B_CALL(_Mov7B)
B_CALL(_saveShadow)
B_CALL(_rstrShadow)
pop hl
xor a
ret

TokenHook:
.db $83
ld a,(cxCurApp)
cp kPrgmEd
ret nz
ld bc,(EditTop)
ld a,(bc)
cp tDecPt
jr nz,TokenHook_NotAxe
TokenHook_MaybeAxe:
inc bc
ld a,(bc)
cp tDecPt
jr z,TokenHook_IsAxe
sub tA
cp tTheta-tA+1
jr nc,TokenHook_NotAxe
TokenHook_IsAxe:
push hl
push de
ld bc,('P'<<8)+(StrAXESRC&$FF)
call TokenHook_CheckIfChanged
call z,TokenHook_AxiomSearch
pop de
ld hl,AxeTokens
ld b,0
jr TokenHook_CompareLoop_Start
TokenHook_CompareLoop:
cp e
inc hl
jr z,TokenHook_LowByteMatch
TokenHook_NoMatch:
inc hl
ld c,(hl)
inc c
add hl,bc
TokenHook_CompareLoop_Start:
ld a,(hl)
or a
jr nz,TokenHook_CompareLoop
TokenHook_DoneNoMatch:
add hl,hl
ld hl,AxiomTokens
jr nc,TokenHook_CompareLoop_Start
pop hl
ret
TokenHook_LowByteMatch:
ld a,(hl)
cp d
jr nz,TokenHook_NoMatch
TokenHook_Match:
ld de,localTokStr
push de
ld c,17
ldir
pop hl
pop bc
ret

TokenHook_AxiomSearch:
ld hl,AxiomTokens
B_CALL(_BufClr)
ld hl,-768
ld (TokenHook_Temp),hl
ld de,(editTop)
push de
ld hl,(editCursor)
push hl
push de
B_CALL(_BufToBtm)
ld hl,(editCursor)
pop de
or a
sbc hl,de
inc hl
ld b,h
ld c,l
ex de,hl
call TokenHook_AxiomSearch_Loop
TokenHook_AxiomSearch_Done:
pop hl
ld (editTop),hl
B_CALL(_BufToTop)
pop hl
ld (editTop),hl
ret

TokenHook_AxiomSearch_CheckHeader:
call ReadArc
inc de
add a,c
ld bc,$C0DE
sbc hl,bc
ld c,a
ret z
pop bc
TokenHook_AxiomSearch_Loop__:
pop bc
TokenHook_AxiomSearch_Loop_:
pop hl
TokenHook_AxiomSearch_Loop:
ld a,tAsmComp
cpir
ret po
push hl
dec hl
dec hl
ld a,(hl)
cp t2ByteTok
jr nz,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_Backtrack:
dec hl
ld a,(hl)
cp tSpace
jr z,TokenHook_AxiomSearch_Backtrack
sub tColon
cp tEnter-tColon+1
jr nc,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_FindAxiom:
pop hl
push hl
push bc
dec hl
rst 20h
ld hl,OP1
ld d,AppVarObj
ld (hl),d
call p_GetArc+1
jr c,TokenHook_AxiomSearch_Loop__
TokenHook_AxiomSearch_FoundAxiom:
ex de,hl
ld c,b
call TokenHook_AxiomSearch_CheckHeader
ld b,32+1
TokenHook_AxiomSearch_ScanAxiom:
call ReadArc
inc de
ld a,h
or l
jr z,TokenHook_AxiomSearch_EndOfAxiom
add hl,de
ld de,5
add hl,de
ex de,hl
djnz TokenHook_AxiomSearch_ScanAxiom
TokenHook_AxiomSearch_EndOfAxiom:
call TokenHook_AxiomSearch_CheckHeader
call ReadArc
inc de
ld a,c
ld b,h
ld c,l
ld hl,(TokenHook_Temp)
add hl,bc
jr c,TokenHook_AxiomSearch_Loop__
ld (TokenHook_Temp),hl
sbc hl,bc
push bc
ld bc,appBackUpScreen+768
add hl,bc
pop bc
ex de,hl
call p_CopyArc+5
jr TokenHook_AxiomSearch_Loop__

ReadArc:
ex de,hl
xor a
cp c
jr z,ReadArc_RAM
push bc
push hl
call p_ReadArcApp+11
pop de
inc de
pop bc
ret
ReadArc_RAM:
ld e,(hl)
inc hl
ld d,(hl)
ex de,hl
ret

AxeTokens:
.db $F4,$03,5,"Copy("
.db $FE,$03,5,"Exch("
.db $0E,$04,5,"Freq("
.db $66,$01,5,"Buff("
.db $62,$01,5,"sign{"
.db $06,$00,5,Lconvert,"Char"
.db $08,$04,4,Lconvert,"Hex"
.db $02,$04,5,"Data("
.db $4E,$01,7,"Bitmap("
.db $02,$00,4,Lconvert,"Tok"
.db $80,$04,7,"#Axiom("
.db $04,$04,5,"Rect("
.db $06,$04,6,"RectI("
.db $58,$02,3,LrecurV,"ar"
.db $5A,$02,4,"app",LrecurV
.db $5C,$02,3,"grp"
.db $F6,$01,4,"port"
.db $52,$01,5,"Text "
.db $D8,$01,8,"Pt-Mask("
.db $DA,$01,7,"pt-Get("
.db $D0,$01,3,"Get"
.db $14,$04,5,"rotC("
.db $16,$04,6,"rotCC("
.db $18,$04,6,"flipV("
.db $1A,$04,6,"flipH("
.db $C8,$03,7,"inData("
.db $B8,$01,5,"input"
.db $74,$01,6,"float{"
.db $72,$01,4,"nib{"
.db $F6,$03,9,"#Realloc("
.db $68,$01,6,"#Icon("
.db $80,$01,2,Llambda,"("
.db $38,$03,5,"Load("
.db $3A,$03,5,"Next("
.db $14,$03,7,"Render("
.db $3C,$03,6,"DrawL("
.db $3E,$03,6,"DrawR("
.db $16,$03,6,"DrawS("
.db $82,$03,6,"Print("
.db $44,$03,3,"Up("
.db $46,$03,5,"Down("
.db $5C,$03,5,"Left("
.db $40,$03,6,"Right("
.db $42,$03,4,"New("
.db $5E,$03,7,"Delete("
.db 0

StrPROGRAM:
.db "PROGRAM"
StrAXESRC:
.db "AXE SRC"
#if (StrPROGRAM>>8) != (StrAXESRC>>8)
.error "StrPROGRAM and StrAXESRC must have the same MSB"
#endif


Answers to your questions:


EDIT: Oh, and if you plan on using this, it's probably a good idea to move TokenHook_Temp and AxiomTokens, since I recently figured out that zStart uses appBackUpScreen, and I know a lot of Axe users use zStart. statVars seems like a good alternative.

EDIT 2: Now that I think about it, I think I realized the much simpler way to determine if the program editor was just opened... If the saved previous value of cxCurApp isn't equal to kPrgmEd, set it to kPrgmEd, scan for Axioms, and then resume the token hook as usual.

EDIT 3: I knew this would happen, as soon as I release my code I think of improvements and bugs. Anyways, I forgot to make this properly find Axioms with names of less than 8 characters. Maybe later I'll just post a new version with all these edits taken into account.
Title: Re: Axe Parser
Post by: Runer112 on January 10, 2012, 08:23:47 pm
Sorry for the double post, but technically, this is a project update!


I fixed everything that I knew was bad about the previous version of the token hook that I posted. The updated hook is now:

Code: [Select]
.nolist
#include "ti83plus.inc"
.list

#define cxPrevApp cxPrev+cxCurApp-cxMain

#define p_GetArc $55E7
#define p_ReadArcApp $5658
#define p_CopyArc $568D

#define TokenHook_Temp appRawKeyHandle
#define AxiomTokens statVars
#define AxiomTokens_End curGStyle

.org $71E0


TokenHook:
.db $83
ld a,(cxCurApp)
cp kPrgmEd
ret nz
ld bc,(EditTop)
ld a,(bc)
cp tDecPt
ret nz
inc bc
ld a,(bc)
cp tDecPt
jr z,TokenHook_IsAxe
sub tA
cp tTheta-tA+1
ret nc
TokenHook_IsAxe:
push hl
ld hl,cxPrevApp
ld a,kPrgmEd
cp (hl)
jr z,TokenHook_SkipAxiomSearch
TokenHook_AxiomSearch:
ld (hl),a
push de
ld hl,AxiomTokens
ld (iy+statFlags),h
B_CALL(_BufClr)
ld hl,AxiomTokens-AxiomTokens_End
ld (TokenHook_Temp),hl
B_CALL(_IsAtTop)
push de
push hl
B_CALL(_BufToBtm)
B_CALL(_IsAtTop)
sbc hl,de
ld b,h
ld c,l
ex de,hl
call TokenHook_AxiomSearch_Loop
pop hl
ld (editTop),hl
B_CALL(_BufToTop)
pop hl
ld (editTop),hl
pop de
TokenHook_SkipAxiomSearch:
ld hl,AxeTokens
ld b,0
jr TokenHook_CompareLoop_Start
TokenHook_CompareLoop:
cp e
inc hl
jr z,TokenHook_LowByteMatch
TokenHook_NoMatch:
inc hl
ld c,(hl)
inc c
add hl,bc
TokenHook_CompareLoop_Start:
ld a,(hl)
or a
jr nz,TokenHook_CompareLoop
TokenHook_DoneNoMatch:
add hl,hl
ld hl,AxiomTokens
jr nc,TokenHook_CompareLoop_Start
pop hl
ret
TokenHook_LowByteMatch:
ld a,(hl)
cp d
jr nz,TokenHook_NoMatch
TokenHook_Match:
ld de,localTokStr
push de
ld c,17
ldir
pop hl
pop bc
ret


TokenHook_AxiomSearch_CheckHeader:
call ReadArc
inc de
add a,c
ld bc,$C0DE
sbc hl,bc
ld c,a
ret z
pop bc
TokenHook_AxiomSearch_Loop__:
pop bc
TokenHook_AxiomSearch_Loop_:
pop hl
TokenHook_AxiomSearch_Loop:
ld a,tAsmComp
cpir
ret po
push hl
dec hl
dec hl
ld a,(hl)
cp t2ByteTok
jr nz,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_Backtrack:
dec hl
ld a,(hl)
cp tSpace
jr z,TokenHook_AxiomSearch_Backtrack
sub tColon
cp tEnter-tColon+1
jr nc,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_FindAxiom:
pop hl
push hl
push bc
dec hl
rst 20h
ld hl,OP1
ld (hl),AppVarObj
ld a,tRParen
ld bc,10
cpir
dec hl
ld (hl),b
ld l,OP1&$FF
call p_GetArc+1
jr c,TokenHook_AxiomSearch_Loop__
TokenHook_AxiomSearch_FoundAxiom:
ex de,hl
ld c,b
call TokenHook_AxiomSearch_CheckHeader
ld b,32+1
TokenHook_AxiomSearch_ScanAxiom:
call ReadArc
inc de
ld a,h
or l
jr z,TokenHook_AxiomSearch_EndOfAxiom
add hl,de
ld de,5
add hl,de
ex de,hl
djnz TokenHook_AxiomSearch_ScanAxiom
TokenHook_AxiomSearch_EndOfAxiom:
call TokenHook_AxiomSearch_CheckHeader
call ReadArc
inc de
ld a,c
ld b,h
ld c,l
ld hl,(TokenHook_Temp)
add hl,bc
jr c,TokenHook_AxiomSearch_Loop__
ld (TokenHook_Temp),hl
sbc hl,bc
push bc
ld bc,curGStyle
add hl,bc
pop bc
ex de,hl
call p_CopyArc+5
jr TokenHook_AxiomSearch_Loop__


ReadArc:
ex de,hl
xor a
cp c
jr z,ReadArc_RAM
push bc
push hl
call p_ReadArcApp+11
pop de
inc de
pop bc
ret
ReadArc_RAM:
ld e,(hl)
inc hl
ld d,(hl)
ex de,hl
ret


AxeTokens:
.db $F4,$03,5,"Copy("
.db $FE,$03,5,"Exch("
.db $0E,$04,5,"Freq("
.db $66,$01,5,"Buff("
.db $62,$01,5,"sign{"
.db $06,$00,5,Lconvert,"Char"
.db $08,$04,4,Lconvert,"Hex"
.db $02,$04,5,"Data("
.db $4E,$01,7,"Bitmap("
.db $02,$00,4,Lconvert,"Tok"
.db $80,$04,7,"#Axiom("
.db $04,$04,5,"Rect("
.db $06,$04,6,"RectI("
.db $58,$02,3,LrecurV,"ar"
.db $5A,$02,4,"app",LrecurV
.db $5C,$02,3,"grp"
.db $F6,$01,4,"port"
.db $52,$01,5,"Text "
.db $D8,$01,8,"Pt-Mask("
.db $DA,$01,7,"pt-Get("
.db $D0,$01,3,"Get"
.db $14,$04,5,"rotC("
.db $16,$04,6,"rotCC("
.db $18,$04,6,"flipV("
.db $1A,$04,6,"flipH("
.db $C8,$03,7,"inData("
.db $B8,$01,5,"input"
.db $74,$01,6,"float{"
.db $72,$01,4,"nib{"
.db $F6,$03,9,"#Realloc("
.db $68,$01,6,"#Icon("
.db $80,$01,2,Llambda,"("
.db $38,$03,5,"Load("
.db $3A,$03,5,"Next("
.db $14,$03,7,"Render("
.db $3C,$03,6,"DrawL("
.db $3E,$03,6,"DrawR("
.db $16,$03,6,"DrawS("
.db $82,$03,6,"Print("
.db $44,$03,3,"Up("
.db $46,$03,5,"Down("
.db $5C,$03,5,"Left("
.db $40,$03,6,"Right("
.db $42,$03,4,"New("
.db $5E,$03,7,"Delete("
.db 0
Title: Re: Axe Parser
Post by: ztrumpet on January 10, 2012, 10:35:53 pm
Wow, Runer, that is incredible.  I'm very impressed with all you did there, and quite glad you made it compatible with everything.  Thank you!
Title: Re: Axe Parser
Post by: Freyaday on January 10, 2012, 11:27:09 pm
/me bows to the glory of the Runer
Title: Re: Axe Parser
Post by: kindermoumoute on January 11, 2012, 01:08:51 pm
* kindermoumoute is amazed by these codes.
Title: Re: Axe Parser
Post by: TIfanx1999 on January 12, 2012, 10:48:28 am
Once again, great work Runer! :thumbsup:
Title: Re: Axe Parser
Post by: Runer112 on January 12, 2012, 03:17:16 pm
I just realized that the token hook has a very minor bug in it. I was relying on the indicator $00 to signal that there are no more tokens to be compared, but I seemed to forget that a couple of tokens actually have $00 as the low byte of the compare value. I suggest fixing this by making $FF signal the end of token comparisons, as this is an odd number and is thus not a valid low byte for the compare value. Fixing the code itself for this change is actually quite easy, and will only cost 1 byte and 4 cycles. Add an inc e before the comparison loop and change or a at the end of the comparison loop to inc a.

EDIT: Let me think this through a bit, this makes my Axiom token replacement cache generator less optimized...
Title: Re: Axe Parser
Post by: Runer112 on January 12, 2012, 06:29:05 pm
Sorry for the double post again!


Well, I found a solution to the issue! The easy way to fix it would've been to simply add 5 or 10 bytes of code to the existing method. But I wanted to minimize as much code bloat as possible in fixing this bug, and I would say I certainly did. Not only did I fix the bug, but the hook is now a byte smaller! ;D

Code: [Select]
.nolist
#include "ti83plus.inc"
.list

#define cxPrevApp cxPrev+cxCurApp-cxMain

#define p_GetArc $55E7
#define p_ReadArcApp $5658
#define p_CopyArc $568D

#define TokenHook_Temp appRawKeyHandle
#define AxiomTokens statVars
#define AxiomTokens_End curGStyle

.org $71E0


TokenHook:
.db $83
ld a,(cxCurApp)
cp kPrgmEd
ret nz
ld bc,(EditTop)
ld a,(bc)
cp tDecPt
ret nz
inc bc
ld a,(bc)
cp tDecPt
jr z,TokenHook_IsAxe
sub tA
cp tTheta-tA+1
ret nc
TokenHook_IsAxe:
push hl
ld hl,cxPrevApp
ld a,kPrgmEd
cp (hl)
jr z,TokenHook_SkipAxiomSearch
TokenHook_AxiomSearch:
ld (hl),a
push de
B_CALL(_IsAtTop)
push de
push hl
B_CALL(_BufToBtm)
B_CALL(_IsAtTop)
sbc hl,de
ld b,h
ld c,l
ex de,hl
ld de,AxiomTokens
call TokenHook_AxiomSearch_Start
pop hl
ld (editTop),hl
B_CALL(_BufToTop)
pop hl
ld (editTop),hl
pop de
TokenHook_SkipAxiomSearch:
inc e
ld hl,AxeTokens
ld b,0
jr TokenHook_CompareLoop_Start
TokenHook_CompareLoop:
cp e
inc hl
jr z,TokenHook_LowByteMatch
TokenHook_NoMatch:
inc hl
ld c,(hl)
inc c
add hl,bc
TokenHook_CompareLoop_Start:
ld a,(hl)
inc a
jr nz,TokenHook_CompareLoop
TokenHook_DoneNoMatch:
add hl,hl
ld hl,AxiomTokens
jr nc,TokenHook_CompareLoop_Start
pop hl
ret
TokenHook_LowByteMatch:
ld a,(hl)
cp d
jr nz,TokenHook_NoMatch
TokenHook_Match:
ld de,localTokStr
push de
ld c,17
ldir
pop hl
pop bc
ret


TokenHook_AxiomSearch_CheckHeader:
call ReadArc
inc de
add a,c
ld bc,$C0DE
sbc hl,bc
ld c,a
ret z
TokenHook_AxiomSearch_Loop___:
pop bc
TokenHook_AxiomSearch_Loop__:
pop bc
TokenHook_AxiomSearch_Loop_:
pop hl
TokenHook_AxiomSearch_Loop:
ld a,tAsmComp
cpir
ret po
push hl
dec hl
dec hl
ld a,(hl)
cp t2ByteTok
jr nz,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_Backtrack:
dec hl
ld a,(hl)
cp tSpace
jr z,TokenHook_AxiomSearch_Backtrack
sub tColon
cp tEnter-tColon+1
jr nc,TokenHook_AxiomSearch_Loop_
TokenHook_AxiomSearch_FindAxiom:
pop hl
push hl
push bc
dec hl
rst 20h
ld hl,OP1
ld (hl),AppVarObj
ld a,tRParen
ld bc,10
cpir
dec hl
ld (hl),b
ld l,OP1&$FF
call p_GetArc+1
jr c,TokenHook_AxiomSearch_Loop__
TokenHook_AxiomSearch_FoundAxiom:
ex de,hl
ld c,b
call TokenHook_AxiomSearch_CheckHeader
ld b,32+1
TokenHook_AxiomSearch_ScanAxiom:
call ReadArc
inc de
ld a,h
or l
jr z,TokenHook_AxiomSearch_EndOfAxiom
add hl,de
ld de,5
add hl,de
ex de,hl
djnz TokenHook_AxiomSearch_ScanAxiom
TokenHook_AxiomSearch_EndOfAxiom:
call TokenHook_AxiomSearch_CheckHeader
call ReadArc
inc de
ld a,c
push hl
ld bc,(TokenHook_Temp)
add hl,bc
ld bc,-AxiomTokens_End
add hl,bc
jr c,TokenHook_AxiomSearch_Loop___
ld hl,(TokenHook_Temp)
ex de,hl
pop bc
call p_CopyArc+5
res statsValid,(iy+statFlags)
pop bc
pop hl
TokenHook_AxiomSearch_Start:
ld (TokenHook_Temp),de
ld a,$FF
ld (de),a
jr TokenHook_AxiomSearch_Loop


ReadArc:
ex de,hl
xor a
cp c
jr z,ReadArc_RAM
push bc
push hl
call p_ReadArcApp+11
pop de
inc de
pop bc
ret
ReadArc_RAM:
ld e,(hl)
inc hl
ld d,(hl)
ex de,hl
ret


AxeTokens:
.db $F4,$03,5,"Copy("
.db $FE,$03,5,"Exch("
.db $0E,$04,5,"Freq("
.db $66,$01,5,"Buff("
.db $62,$01,5,"sign{"
.db $06,$00,5,Lconvert,"Char"
.db $08,$04,4,Lconvert,"Hex"
.db $02,$04,5,"Data("
.db $4E,$01,7,"Bitmap("
.db $02,$00,4,Lconvert,"Tok"
.db $80,$04,7,"#Axiom("
.db $04,$04,5,"Rect("
.db $06,$04,6,"RectI("
.db $58,$02,3,"var"
.db $5A,$02,4,"appv"
.db $5C,$02,3,"grp"
.db $F6,$01,4,"port"
.db $52,$01,5,"Text "
.db $D8,$01,8,"Pt-Mask("
.db $DA,$01,7,"pt-Get("
.db $D0,$01,3,"Get"
.db $14,$04,5,"rotC("
.db $16,$04,6,"rotCC("
.db $18,$04,6,"flipV("
.db $1A,$04,6,"flipH("
.db $C8,$03,7,"inData("
.db $B8,$01,5,"input"
.db $74,$01,6,"float{"
.db $72,$01,4,"nib{"
.db $F6,$03,9,"#Realloc("
.db $68,$01,6,"#Icon("
.db $80,$01,2,Llambda,"("
.db $38,$03,5,"Load("
.db $3A,$03,5,"Next("
.db $14,$03,7,"Render("
.db $3C,$03,6,"DrawL("
.db $3E,$03,6,"DrawR("
.db $16,$03,6,"DrawS("
.db $82,$03,6,"Print("
.db $44,$03,3,"Up("
.db $46,$03,5,"Down("
.db $5C,$03,5,"Left("
.db $40,$03,6,"Right("
.db $42,$03,4,"New("
.db $5E,$03,7,"Delete("
.db $FF

EDIT: This code was changed at 11:15PM EST on 1/12 to fix a critical bug that made all key programming tokens in the PRGM menu inaccessible. Please do not use any copies of the code made before this time! :banghead:

EDIT 2: [10:00PM EST 1/13] Changed the "var" and "appv" token replacements to use the standard lowercase "v" instead of the recursive one. None of the OS tokens, including the recursive equation tokens themselves, actually use the recursive equation characters 02h-04h, so there's no reason why Axe should either.
Title: Re: Axe Parser
Post by: Freyaday on January 12, 2012, 11:05:36 pm
/me falls over
Title: Re: Axe Parser
Post by: Quigibo on January 13, 2012, 02:10:22 am
Cool!  Don't worry, I'm incorporating this feature later after a queue of other features that I need to finish, so you have some time to modify or improve it if you think it needs that :).
Title: Re: Axe Parser
Post by: Runer112 on January 17, 2012, 05:19:29 pm
Some things I'm particularly curious about:
- The token numbers are difficult for developers to type in manually, any ideas of how I could generate a list of equates?

After searching around and not having found any existing list of token hook equates, I figured I should compile one myself, and I did. Feel free to include it in the next release of Axe.

http://www.ticalc.org/archives/files/fileinfo/445/44517.html (http://www.ticalc.org/archives/files/fileinfo/445/44517.html)
Title: Re: Axe Parser
Post by: Quigibo on January 17, 2012, 06:18:51 pm
Wow, that is incredibly helpful!  That will make it much simpler for Axiom developers to include their own token replacements (and myself too).  I will definitely find a place for this in the package :D
Title: Re: Axe Parser
Post by: Quigibo on January 30, 2012, 02:57:48 am
I'm currently in the process of merging the token replacements.  However, one problem I see is that subprograms would not be able to use the replacements because they would each be unaware of which program is the parent (and there could be more than one with different axioms).

To solve this, the #Axiom() command will now be ignored if it's been imported already.  Currently, #Axiom(A):#Axiom(A) either throws an error or puts the axiom on the stack twice (which will quickly fill up the 5 Axiom limit).  This way, you can redefine the relevant Axioms again in each sub-program to see the token replacements in the editor, and the code will compile as expected without error.

Runer, I'm also changing your new suggested syntax of the SDK.  Its basically the same except it doesn't have $C0DE again nor the size.  It knows the size of the Axiom ahead of time and can use that to determine how many token replacements to import.  So it's still reverse compatible and simpler to write because you simply list them after the $0000.
Title: Re: Axe Parser
Post by: Runer112 on January 30, 2012, 03:10:03 am
Those all sound like good ideas. I'm surprised I didn't think of just using the size of the appvar to determine if token replacement data exists, and if so, how much data there is. Smart thinking, and it simplifies things. :)
Title: Re: Axe Parser
Post by: Quigibo on February 02, 2012, 11:24:04 pm
So the main thing I wanted to talk about in the new release is the new "Axe Fusion" compile option.  I was previously calling this "Axe Framework" but fusion is more literal to what is going on, implies that it requires Axe, and sounds cooler.

To reiterate, what this option does is not add ANY built-in Axe routine to your program.  These include things like All DispGraphs, all Sprite commands, all drawing, advanced math, etc.  Instead there is a tiny routine routine added to the start of the program that finds the Axe app and steals the routines from there (like a shell).  The header in Fusion files is literally identical to the Ion header and it should still work in all major shells.  In the end, this reduces code size a lot, usually over 10% sometimes higher than 20%.

Keep in mind that this is a beta feature, meaning it is very unstable right now.  First of all, I would not recommend publishing Axe Fusion programs on sites targeted to end users because those programs may not work with future versions of Axe.  Second of all, I'm not sure if it is working with Axioms right now, I didn't have time to check.

So basically, I added this feature prematurely so that you can all test it out and tell me what you think.  How much is it reducing your code sizes? :)
Title: Re: Axe Parser
Post by: Juju on February 02, 2012, 11:32:13 pm
That sounds pretty interesting. So with this Axe Fusion thing, the Axe app would act like Ion/MirageOS/DoorsCS?
Title: Re: Axe Parser
Post by: Freyaday on February 02, 2012, 11:35:12 pm
How would Fusion work with the program compiled to an app?
Title: Re: Axe Parser
Post by: thydowulays on February 03, 2012, 12:17:24 am
Fusion isn't an Option in the options menu, it's an actual compiling option, so instead of compiling it as an app, you compile it as "Axe Fusion"
Title: Re: Axe Parser
Post by: Freyaday on February 03, 2012, 07:54:16 pm
Oh. That makes sense.
Title: Re: Axe Parser
Post by: Eiyeron on February 12, 2012, 12:54:42 pm
Just axe fusion + zoom compilation gives us real FAST debug build! :p
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 12, 2012, 03:02:29 pm
So the main thing I wanted to talk about in the new release is the new "Axe Fusion" compile option.  I was previously calling this "Axe Framework" but fusion is more literal to what is going on, implies that it requires Axe, and sounds cooler.

To reiterate, what this option does is not add ANY built-in Axe routine to your program.  These include things like All DispGraphs, all Sprite commands, all drawing, advanced math, etc.  Instead there is a tiny routine routine added to the start of the program that finds the Axe app and steals the routines from there (like a shell).  The header in Fusion files is literally identical to the Ion header and it should still work in all major shells.  In the end, this reduces code size a lot, usually over 10% sometimes higher than 20%.

Keep in mind that this is a beta feature, meaning it is very unstable right now.  First of all, I would not recommend publishing Axe Fusion programs on sites targeted to end users because those programs may not work with future versions of Axe.  Second of all, I'm not sure if it is working with Axioms right now, I didn't have time to check.

So basically, I added this feature prematurely so that you can all test it out and tell me what you think.  How much is it reducing your code sizes? :)
This seems interesting, does it means those programs would be dependent on Axe Parser presence on the calc? If so, then I guess a good idea would be for the programmer to publish both versions of his games, so those who have many Axe games can simply keep Axe on their calc and save a lot of space, kinda like how small some Doors CS programs are.
Title: Re: Axe Parser
Post by: Hayleia on March 02, 2012, 07:31:40 am
Now the stupid question:
Could Axe possibly be ported/cloned to the Nspire series, using Ndless ?
Maybe even if it is not on calc ?
Title: Re: Axe Parser
Post by: willrandship on March 03, 2012, 10:44:11 am
It's definitely possible, but also likely to be less efficient, since Axe's routines are designed around the various quirks of the 84+. It would still run faster on the nspire, but probably not as fast as C, def. not as fast as assembly.

Least efficient, but most compatible way would be to have an 83+ emulator :P
Title: Re: Axe Parser
Post by: Hayleia on March 03, 2012, 01:07:23 pm
It's definitely possible, but also likely to be less efficient, since Axe's routines are designed around the various quirks of the 84+. It would still run faster on the nspire, but probably not as fast as C, def. not as fast as assembly.
Ok for "hardware things" but for example, I guess (I said "I guess") that Axe's mathematic operations won't need to be changed to run on the Nspire.

Least efficient, but most compatible way would be to have an 83+ emulator :P
Lol, yeah, but the color ? D:
Title: Re: Axe Parser
Post by: calc84maniac on March 03, 2012, 01:21:20 pm
Ideally we would want the math to be different on a 32-bit processor. :P
Title: Re: Axe Parser
Post by: willrandship on March 06, 2012, 12:37:18 am
Not to mention a RISC processor architecture vs a CISC one. The assembly has some pretty major differences.

An ideal situation would be an axe imitation that is optimized for dealing with ARM, rather than focusing on cross-compatibility. There are a lot of quirks axe deals with on the z80 that become totally unnecessary and less efficient on the nspire, and there are many opportunities a cross-compatible axe would miss.
Title: Re: Axe Parser
Post by: Runer112 on November 23, 2012, 10:42:05 am
So, a new version of Axe has arrived! I think the changelog mostly detailed the new/changed features, but if you have any questions, ask here!

And with all my changes, I'm sure I introduced a fair number of bugs, because I was just blindly fumbling around half the time. x.x If you experience any bugs, please remember to report them in the Bug Reports (http://ourl.ca/4072) thread, and I will try my best to fix them as soon as possible!
Title: Re: Axe Parser
Post by: Eeems on November 23, 2012, 10:58:22 am
You fumble around when it comes to z80 asm? Never :P
I updated my hosted docs on http://axe.eeems.ca last night when I noticed the release.
Title: Re: Axe Parser
Post by: Freyaday on November 23, 2012, 03:54:11 pm
Where were the Axevars moved to and are they in the same order?
Title: Re: Axe Parser
Post by: shmibs on November 26, 2012, 05:04:53 pm
i assume they would have to be in the same order, but would also be very interested to know where they were moved.
Title: Re: Axe Parser
Post by: squidgetx on November 26, 2012, 07:21:02 pm
In the developers folder of the new Axe, you can find Axe.inc which shows you this info (i only know this because runer told me lol)

Quote
axv_A           =$9CFB
axv_B           =$9CFD
axv_C           =$9CFF
axv_D           =$9D01
axv_E           =$9D03
axv_F           =$9D05
axv_G           =$9D07
axv_H           =$9D09
axv_I           =$9D0B
axv_J           =$9D0D
axv_K           =$9D0F
axv_L           =$9D11
axv_M           =$9D13
axv_N           =$9D15
axv_O           =$9D17
axv_P           =$9D19
axv_Q           =$9D1B
axv_R           =$9D1D
axv_S           =$9D1F
axv_T           =$9D21
axv_U           =$9D23
axv_V           =$9D25
axv_W           =$9D27
axv_X           =$9D29
axv_Y           =$9D2B
axv_Z           =$9D2D
axv_Theta       =$9D2F

axv_R1          =$9D31
axv_R2          =$9D33
axv_R3          =$9D35
axv_R4          =$9D37
axv_R5          =$9D39
axv_R6          =$9D3B

axv_Y1          =$9D3D
axv_Y1Page      =$9D3F
axv_Y2          =$9D40
axv_Y2Page      =$9D42
axv_Y3          =$9D43
axv_Y3Page      =$9D45
axv_Y4          =$9D46
axv_Y4Page      =$9D48
axv_Y5          =$9D49
axv_Y5Page      =$9D4B
axv_Y6          =$9D4C
axv_Y6Page      =$9D4E
axv_Y7          =$9D4F
axv_Y7Page      =$9D51
axv_Y8          =$9D52
axv_Y8Page      =$9D54
axv_Y9          =$9D55
axv_Y9Page      =$9D57
axv_Y0          =$9D58
axv_Y0Page      =$9D5A

axv_SpriteBuff  =$9D5B

axv_RandSeed    =$9D63

axv_Y1t         =$84EB
axv_Y2t         =$84ED
axv_X1t         =$84EF
axv_X2t         =$84F1
axv_Y3t         =$84F3
axv_Y4t         =$84F5
axv_X3t         =$84F7
axv_X4t         =$84F9
axv_Y5t         =$84FB
axv_Y6t         =$84FD
axv_X5t         =$84FF
axv_X6t         =$8501
Title: Re: Axe Parser
Post by: Freyaday on November 27, 2012, 07:56:34 pm
wait, Why are axv_Y4Page and axv_Y5Page in the same place?
Title: Re: Axe Parser
Post by: shmibs on November 27, 2012, 08:11:53 pm
they aren't
axv_Y4Page      =$9D48
axv_Y5Page      =$9D4B
Title: Re: Axe Parser
Post by: Freyaday on November 29, 2012, 08:59:39 am
they aren't
axv_Y4Page      =$9D48
axv_Y5Page      =$9D4B
Oh, ok!
Title: Re: Axe Parser
Post by: GinDiamond on November 29, 2012, 05:56:07 pm
Axe 1.2.0 isn't working on WabbitEmu or cemetech's jTIfied. Is this a bug in Axe or a bug with the emulators? Axe works on my calc.

Also, when's the next version of Axe gonna be out? It keeps getting better and better!
Title: Re: Axe Parser
Post by: Eeems on November 29, 2012, 06:16:14 pm
What do you mean it isn't working? Could you give some more information on what happened? Maybe even post in the bug reports topic?
Title: Re: Axe Parser
Post by: stevon8ter on November 29, 2012, 06:18:58 pm
Axe 1.2.0 isn't working on WabbitEmu or cemetech's jTIfied. Is this a bug in Axe or a bug with the emulators? Axe works on my calc.

Also, when's the next version of Axe gonna be out? It keeps getting better and better!

For me it works on wabbitemu
Title: Re: Axe Parser
Post by: Runer112 on December 01, 2012, 02:44:29 am
I would like to improve line drawing, but I need your help! I want to add horizontal and vertical line commands, and then also allow modifiers to all line and other drawing commands to allow white or inverted drawing. The question is, what syntax for these features looks best and/or is easiest to use?

I have added a poll to get your input on this question. Really this is two polls in one:
[1] What should the command for horizontal and vertical lines be?
[2] What should the syntax for white and xor drawing be?

So please look over all the options, and then pick ONE in the [1] category and ONE in the [2] category. Please consider the pros and cons of each; for instance, Horizontal seems like a great choice, but it might cause confusion with the existing Horizontal+ comamnd; and tokens like LinReg(a+bx) can be turned into much better names with the token hook, but without the token hook, they may look confusing.


I would like to note that, for specifying white and xor drawing modes, something like WhiteLine(X1,X2,Y1,Y2) is very much a possibility as well. But then the question is, what tokens should be replaced to be White and Xor? I don't see any obvious choices, but if you have an idea about it, pick the "other" option for [2] and post what your idea is.
Title: Re: Axe Parser
Post by: willrandship on December 01, 2012, 04:45:38 am
I've never been a big fan of overloading functions. It makes code less readable. I also don't see a need to use new tokens, especially since we're getting to the point where those tokens are in more and more obscure sub-menus.

I rather like the W<command> syntax, but I'd also be okay with the !. It's a little misleading, but not too bad. Also, HLine(), etc. is faster to type than LinReg()

If typing on the calc wasn't so slow I'd advocate pure-ASCII compiling. Actually, I would like that anyway, at least as an option.
Title: Re: Axe Parser
Post by: Builderboy on December 01, 2012, 04:55:52 am
I am in favor of preceding the commands with the letter modifiers.  This allows the same syntax to be used for both the horizontal/vertical lines, as well as the different drawing modes for the drawing commands, which would help keep the syntax more consistent.  Additionally, adding more and more extra tokens for new but similar commands can get annoying when they start being spread out over multiple menu's, with the letter modifiers we only ever have to look towards a single token.   
Title: Re: Axe Parser
Post by: Deep Toaster on December 01, 2012, 03:18:36 pm
I thought ! would be great because it means "not" in terms of !If already.

I doubt there'd be more than two of these "prefixes," so W and X out of the entire alphabet feels a bit weird to me. ! and i are characters anyway (so they're more like prefixes), and as I said, ! is already used for something close to that meaning.

Also what would happen if you did something like this?
→XLine(,Y,X+3,Y+3)
Title: Re: Axe Parser
Post by: Freyaday on December 09, 2012, 01:29:20 pm
Also what would happen if you did something like this?
→XLine(,Y,X+3,Y+3)

You'd get a syntax error.
Title: Re: Axe Parser
Post by: leafy on December 09, 2012, 02:29:33 pm
Yeah, but I think what he's trying to get at is loading a value into X, then using that value in HL as the first argument for the Line() command, which should make sense. It's easier to modify values outside of the command block.
Title: Re: Axe Parser
Post by: Matrefeytontias on December 09, 2012, 02:58:55 pm
Then just add a newline between X and Line and it will work.
Title: Re: Axe Parser
Post by: Runer112 on December 17, 2012, 12:18:49 am
So I just released a new version of Axe about 4 hours ago... and I managed to screw up the flagship feature. So I have quickly fixed it and replaced the bad 1.2.1 with 1.2.1a!

If you were one of the five who downloaded Axe 1.2.1 already: go get the fixed version.

For everybody else: what crippling bug? I would never make such a silly mistake, what are you talking about? I don't see it anywhere.
Title: Re: Axe Parser
Post by: Freyaday on December 19, 2012, 12:32:46 am
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually. :P
Does this mean we might be able to have two-page Axe apps in the future?
Title: Re: Axe Parser
Post by: Runer112 on December 19, 2012, 12:33:43 am
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually. :P
Does this mean we might be able to have two-page Axe apps in the future?

Eventually I hope so, yes. But as I've mentioned in previous posts, it's a logistical nightmare so don't expect it any time soon.
Title: Re: Axe Parser
Post by: Freyaday on December 19, 2012, 12:34:09 am
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually. :P
Does this mean we might be able to have two-page Axe apps in the future?

Eventually I hope so, yes. But as I've mentioned in previous posts, it's a logistical nightmare so don't expect it any time soon.
Alrighty, then!
Title: Re: Axe Parser
Post by: Sorunome on December 19, 2012, 08:38:06 pm
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.

And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually. :P
Does this mean we might be able to have two-page Axe apps in the future?

Eventually I hope so, yes. But as I've mentioned in previous posts, it's a logistical nightmare so don't expect it any time soon.
Let's party!
I've been waiting for this feature long :P
But it would still give error memory if there isn't enough ROM
And wouldn't you need to like write page to page and swap a lot between ROM and RAM because the calc doesn't have enough RAM?
Title: Re: Axe Parser
Post by: Matrefeytontias on January 22, 2013, 02:33:44 am
Bump,

At school, I'm in a project that requires the linking abilities of my Ti-83+, and since I'm too lazy to make it in assembly (:P), I wondered : what's the protocol you're using with the Send( command ? My goal is to catch the bits sent with an Arduino in a byte.

Also, since these functionalities had been added to the latest version of Axe, I think you should remove the current poll and make a new one :P
Title: Re: Axe Parser
Post by: Keoni29 on January 22, 2013, 02:59:08 am
I usually write my own link routines. Toggle one pin in the port. This is your clock. Every time want the bit to be 1 you toggle both pins off. Every time you want it to be a 0 only turn the clock pin off. Now for receiving data you send thearduino 8 bits to tell it the calc is in receive mode. Then toggle the clockpin 8 times. On the arduino side you run a bit of hardware interrupt code on the clock pin. Put bits on the data pin.
Title: Re: Axe Parser
Post by: Matrefeytontias on January 22, 2013, 04:32:47 am
In fact it's ok, I've already wrote my routine :P thanks
Title: Re: Axe Parser
Post by: Matrefeytontias on January 29, 2013, 08:40:28 am
Bump,

in fact it's not ok :P , can someone describe the protocol used by the Send() command ?

Also, still not changing the old poll ? ;D
Title: Re: Axe Parser
Post by: Runer112 on January 29, 2013, 01:57:58 pm
Axe's link protocol is a little weird. I detailed it here (http://ourl.ca/14710/285899) about a year ago for someone else wanting to interact with it.

The tabs might have gotten eaten by the code box. You may be able to view it as it was intended by quoting the post, deleting the quote tags, and then previewing it.
Title: Re: Axe Parser
Post by: GamerMX1248 on February 01, 2013, 10:06:10 pm
Is there a way to split several strings without assigning several static variables.
Right now i have to do this:
Code: [Select]
"Easy"->Str11
"Medium"->Str12
"Hard"->Str13
So that when i want to irritate through several strings separated by a '0' using stdDev(, I reference Str11.
But i'd rather do something like
Code: [Select]
"Easy*Medium*Hard"->Str1 Where * is some kind of special character that is replaced by the string termination character.
Is there a way to do this in Axe, or some other easier work around to save on variable declarations and reduce typing time?
I've got a big project that will involve lots of irritating through sets of text, so how I'm currently doing it will take much longer than i'd like to invest in it.

Thanks in advance
Title: Re: Axe Parser
Post by: Runer112 on February 01, 2013, 10:58:02 pm
The string termination character is just a null (zero) byte. When string data is equated to a static pointer or used inline (like after a Disp or otherwise immediately used), this null terminator is automatically added. Otherwise it is not added. However, you can add it manually when you have lots of string data, like this:

Code: [Select]
"Easy"->Str11
"Medium"[00]
"Hard"[00]
Title: Re: Axe Parser
Post by: GamerMX1248 on February 02, 2013, 02:19:14 pm

Thank you. This will make my project so much easier
Title: Re: Axe Parser
Post by: DJ Omnimaga on February 10, 2013, 05:00:25 am
I don't know if voting is over, but I wonder if Horiz and Vert would be confusing with the shift commands that already use Horizontal/Vertical? I was gonna vote using G-T and stuff, but then thought people might confuse Horiz and Horizontal, for example, so I would choose HLine and WLine. That said, source would be slightly larger due to the extra letter prefix. As for the other I guess letter modifiers or an extra argument would work, like xLIB. Disregard this if the update is already done, though.
Title: Re: Axe Parser
Post by: Runer112 on October 29, 2013, 04:25:38 pm
I made a small update to Axe 1.2.2, fixing a bug with the formatting of error dumps. It wasn't at all worth making a new major release for, but I did replace the Axe 1.2.2 download with the updated version.

If you don't plan on dumping any errors, don't even worry about this update. If you do, but a bit of weird formatting isn't a huge issue for you (the dump is still fine I think, it's just formatted oddly), don't worry about this update, either. But if you do want properly formatted error dumps, grab the fixed version in the latest updates thread (http://ourl.ca/4060/364694).
Title: Re: Axe Parser
Post by: Matrefeytontias on October 29, 2013, 04:37:22 pm
And about the app generation bug ? Is it still unresolved ?
Title: Re: Axe Parser
Post by: Runer112 on October 29, 2013, 04:39:33 pm
I'm of the opinion that your archive was just a bit messed up and that it wasn't Axe's fault. :P You should try Axe 1.2.2 again, and if it still doesn't work and you send over Calcsys as well, I can try to help debug it further.
Title: Re: Axe Parser
Post by: tpt1234567890 on October 29, 2013, 05:39:10 pm
I'm of the opinion that your archive was just a bit messed up and that it wasn't Axe's fault. :P You should try Axe 1.2.2 again, and if it still doesn't work and you send over Calcsys as well, I can try to help debug it further.

Thanks for this! My archive messed up right after I read this, and it fixed it!
Title: Re: Axe Parser
Post by: nikitouzz on November 09, 2013, 10:48:56 am
Couldn't you keep the current line routine and add one that clips ? :) please !
Title: Re: Axe Parser
Post by: Runer112 on November 09, 2013, 03:04:07 pm
Clipped lines are tough (to do optimally in assembly, at least) and I've been dreading coding them forever. But I'll bump it up on my priority list and try to force myself to implement them sooner rather than later.
Title: Re: Axe Parser
Post by: Matrefeytontias on November 09, 2013, 03:31:53 pm
I did a pretty fast and optimized line clipping in Axe, maybe I can try to port it in ASM.
Title: Re: Axe Parser
Post by: Streetwalrus on November 11, 2013, 07:08:02 am
An idea would be to add a check whether or not you are on the screen while drawing. Though if you have a huge portion of the line off screen that'd be very slow. :/
Title: Re: Axe Parser
Post by: Matrefeytontias on November 11, 2013, 07:23:56 am
The fastest line clipping code I saw in action actually took 2 coordinates, like a classical line routine, but then performs some mathematics based on cartesian equations to "keep" the points in the drawing window while not altering the "slope" of the line.

Sorry for the poor explanation, English is not my first language :/

This page will explain better than me : http://lodev.org/cgtutor/lineclipping.html .
Title: Re: Axe Parser
Post by: Runer112 on June 18, 2015, 02:42:04 pm
Updated with lots of new stuff on July 1!



Axe 1.3.0 may be coming soon. It doesn't change the language at all, but It adds some new commands, improves some old ones, and improves the Axe application a lot because I rewrote a lot of internals. Primarily, compiling should be significantly (~4x) faster:

Axe 1.2.2
Axe 1.3.0
(http://i.imgur.com/0vKUjh3.gif)(http://i.imgur.com/QlyqDyY.gif)

Because of all the rewriting I did, I fear that I may have introduced bugs. I've squashed all the bugs I found so it shouldn't just be bug city, but I'd still like it to be tested a bit more before an official release. So if you're feeling a bit brave, try the potential Axe 1.3.0 (https://dl.dropboxusercontent.com/u/34812306/Axe.8xk).

Changelog: (https://dl.dropboxusercontent.com/u/34812306/ChangeLog.txt)

Also, to remind people:

In the process of completely recoding the menus, I added an option that I've heard asked for a couple of times: the ability to disable the token hook. But in doing so, I needed to add a second options page, which is currently barren. Give me suggestions for two new options!
Title: Re: Axe Parser
Post by: Sorunome on June 18, 2015, 02:43:36 pm
Wow, that is pretty awesome news, glad you got it to a working state! :D
Title: Re: Axe Parser
Post by: Haobo on June 18, 2015, 03:34:50 pm
Here's a problem that I stated in cemetech about compiling as an app. The only part that actually matters happens later, when the gameplay happens. The nights dont work at all, but the only part of the code that I changed was removing fullrene so that app compiling was possible.


PS. The 1.3.0 made that program take from ~40 secs to ~10 secs compile time.
Title: Re: Axe Parser
Post by: Aspiring on June 19, 2015, 12:12:41 pm
That is awesome!   :thumbsup:  Trying right now.  ;D
Title: Re: Axe Parser
Post by: Hayleia on June 21, 2015, 05:50:39 am
Great work ! :D
I just tried to compile Smash with that and I didn't seem to meet any problem so you probably got rid of the most important bugs :)

  • Comments are now allowed and parsed correctly in a few places that they should have been before.
  • Fixed a bug that resulted in the "APP TOO BIG" error being thrown when compiled code hit 16KB, regardless of target shell.
Lol, I remember complaining about those ones :P
Title: Re: Axe Parser
Post by: Keoni29 on June 25, 2015, 05:08:55 pm
Wow that fast compile time sounds promising! That will save so much time when debugging! Because of the unstable state I will not be using it for development just yet, but I certainly want to try it out.
Title: Re: Axe Parser
Post by: Plokki on July 07, 2015, 10:42:10 am
hello, i tried axe 1.3.0 and the speed is amazing, no bugs, great job ! The only thing is that the auto backup doesn't work (it can be on or off, it doesn't change anything).
I saw that you've done an update on July 1 so I used it to compile my tunnel game but I have something very weird: the programs compiled with axe 1.2.2 or axe 1.3.0 (first version) is 6877 bytes tall but the program compiled with axe 1.3.0 (2nd version) is only 6670 bytes, the source code is the same on each time with 5409 bytes.
And the result is bugged but it doesn't crash.
I don't know at all what happened but I hope you can fix it.
Title: Re: Axe Parser
Post by: Runer112 on July 07, 2015, 11:56:11 am
hello, i tried axe 1.3.0 and the speed is amazing, no bugs, great job !

Thanks for testing it out! Looks like "no bugs" isn't exactly true, though. :P

The only thing is that the auto backup doesn't work (it can be on or off, it doesn't change anything).

I rewrote how backup stuff is handled, so that's certainly a possibility. I should be able to fix that easily enough.

I saw that you've done an update on July 1 so I used it to compile my tunnel game but I have something very weird: the programs compiled with axe 1.2.2 or axe 1.3.0 (first version) is 6877 bytes tall but the program compiled with axe 1.3.0 (2nd version) is only 6670 bytes, the source code is the same on each time with 5409 bytes.
And the result is bugged but it doesn't crash.
I don't know at all what happened but I hope you can fix it.

I'm not sure what could be causing this. Could you provide the source program so I can debug what goes wrong during compilation? If you're not comfortable posting it publicly, you can send it to me using the site's messaging system, or via email to the address on my profile page. The latter may be easier as it would allow attaching the source program directly.
Title: Re: Axe Parser
Post by: Plokki on July 07, 2015, 01:06:46 pm
Thanks for this quick reply :)
I've updated the download link with the last version of my program:http://ti-pla.net/a279466 (http://ti-pla.net/a279466)
The source code is theta_BOOST and i'm using an appvar (AXECOS).
Title: Re: Axe Parser
Post by: Yeong on October 17, 2015, 01:44:05 am
Axe is still actively developing and is still going strong!

Nice to see that :D
Title: Re: Axe Parser
Post by: pimathbrainiac on October 17, 2015, 10:39:07 am
Holy crap a wild @Yeong appeared!

Anyways, I'll download the beta as soon as I can. Great job as always, Runer!
Title: Re: Axe Parser
Post by: TIfanx1999 on October 18, 2015, 11:25:49 am
Hey @Yeong , good to see you? What you been up to?
Title: Re: Axe Parser
Post by: neuronix on November 24, 2015, 11:03:58 am
Waouh, it is really fast and it is very easy  to use  ;)
Title: Re: Axe Parser
Post by: neuronix on November 28, 2015, 09:41:38 am
It is possible to have the source of Axe 1.2.2 because I don't find on this topic. (https://www.omnimaga.org/the-axe-parser-project/latest-updates-%28***do-not-post-here!***%29/)



Sorry for this triple post but I download the Axe 1.3.0 and it bugs  :banghead:
So, I search an other version on the Google and I find this version (https://dl.dropboxusercontent.com/u/34812306/Axe.8xk).

Edit (Eeems): Merged double post.
Title: Re: Axe Parser
Post by: Sorunome on November 28, 2015, 10:34:04 am
Mind editing yor posts instead of double- or tripple-posting, please?

As for the Axe source, it is included in the normal download zip.
Title: Re: Axe Parser
Post by: Runer112 on November 28, 2015, 01:00:49 pm
It is possible to have the source of Axe 1.2.2 because I don't find on this topic. (https://www.omnimaga.org/the-axe-parser-project/latest-updates-%28***do-not-post-here!***%29/)

The source for all of the built-in subroutines is available in each Axe.zip download at Developers\Commands.inc, but the source for the application itself is not available, as it is a closed-source project.

Sorry for this triple post but I download the Axe 1.3.0 and it bugs  :banghead:
So, I search an other version on the Google and I find this version (https://dl.dropboxusercontent.com/u/34812306/Axe.8xk).

Yes, I feared that Axe 1.3.0 would have some bugs, which is why I only released it unofficially as a test release. That link should be Axe 1.3.0 with a few bugfixes applied. If you use that and still encounter bugs, you should report them in the bug reports thread (https://www.omnimaga.org/the-axe-parser-project/bug-reports/). If you do so, please mention the version of Axe you're using.
Title: Re: Axe Parser
Post by: E37 on December 01, 2015, 07:49:03 pm
Is there a way to have both 1.2.2 and 1.3.0 installed at the same time?
I would like to test 1.3 but if there is a problem I would have 1.2.2 to fall back on (also I will have a way to determine if it is me or the compiler messing up).
I haven't had any luck renaming the app.
Thanks!
Title: Re: Axe Parser
Post by: neuronix on December 02, 2015, 11:32:38 am
I search source because I would ported to Ti 83 Premium CE
Title: Re: Axe Parser
Post by: Eeems on December 03, 2015, 08:58:59 pm
I search source because I would ported to Ti 83 Premium CE
Porting to the CE would require a major overhaul. It would take less time to just rewrite it. Especially since we don't have the app signing keys for the CE and we'd have to rewrite it as a group of programs.
Title: Re: Axe Parser
Post by: neuronix on December 04, 2015, 12:02:41 pm
I thought of making it under the shape of a asm program
Title: Re: Axe Parser
Post by: Eeems on December 04, 2015, 03:55:41 pm
I thought of making it under the shape of a asm program
Doing so would basically require a complete rewrite of it. Not to mention most of the routines would have to be completely rewritten since the CE is a eZ80 and not a z80.
Title: Re: Axe Parser
Post by: neuronix on December 12, 2015, 09:57:40 am
I know it but I would like ported to Ti 83 Premieum CE to rewritten the routine  ;)
Title: Re: Axe Parser
Post by: Eeems on December 12, 2015, 05:21:49 pm
I know it but I would like ported to Ti 83 Premieum CE to rewritten the routine  ;)
It wouldn't be rewriting a routine. It would be rewriting the entire thing from scratch. There is little to no point to having the source.
Title: Re: Axe Parser
Post by: neuronix on December 15, 2015, 11:12:56 am
I know it but I would like ported to Ti 83 Premieum CE to rewritten the routine  ;)
It wouldn't be rewriting a routine. It would be rewriting the entire thing from scratch. There is little to no point to having the source.
Thank you for this response but I don't know rewrite completely Axe Parser for Ti 83 Premium CE  :-\ ;)
Title: Re: Axe Parser
Post by: E37 on December 17, 2015, 04:04:20 pm
How is Axe 1.3 coming along?
Title: Re: Axe Parser
Post by: neuronix on December 21, 2015, 08:42:58 am
How is Axe 1.3 coming along?
I don't understand your post. Sorry  :-\

P.S : I am french and I have any difficult to speak english.
Sorry :-\
Title: Re: Axe Parser
Post by: TIfanx1999 on December 21, 2015, 12:55:41 pm
E37 was not talking to you. He was asking Runer112 how the new version of Axe was coming along for the normal TI-84+.
Title: Re: Axe Parser
Post by: E37 on January 11, 2016, 05:06:45 pm
Hey Runner, I know you are busy but how much time do you think it will take to finish Axe 1.3.0?
Title: Re: Axe Parser
Post by: Runer112 on January 11, 2016, 08:27:59 pm
Hey Runner, I know you are busy but how much time do you think it will take to finish Axe 1.3.0?

I'm not sure... there's probably not a ton of work to do, but I have very little free time lately. :-\
Title: Re: Axe Parser
Post by: aeTIos on November 11, 2022, 02:51:34 pm
... And that's it, then.

Nearly seven years of no updates, and understandably so, with the calculator community dwindling. Nevertheless, in my opinion, Axe Parser will always be one of the greatest programs written, and I've recently picked it up again and am again enjoying its quirks and simplicity.
Therefore I think it's a shame that, with the source code closed, no one can ever either learn from this project (it must be a treasure trove of z80 writing) or pick it up again. The chance that either Quigibo or Runer112 are reading this is slim, however, I would want to call upon them to provide a final release with the source code, as a last hurrah for Axe.

Keep rocking your axe, wherever you all may be. Cheers.
Title: Re: Axe Parser
Post by: E37 on November 19, 2022, 11:42:55 am
Therefore I think it's a shame that, with the source code closed, no one can ever either learn from this project (it must be a treasure trove of z80 writing) or pick it up again. The chance that either Quigibo or Runer112 are reading this is slim, however, I would want to call upon them to provide a final release with the source code, as a last hurrah for Axe.

@aeTIos
Runer112 gave me the source for either Axe 1.3.0 or 1.2.2 (I can't remember which and taking a quick peek at it I can't tell) a long time ago. If there is some very compelling evidence that he would be OK with me publishing it, I will.

Having looked at it more carefully, it is 1.2.2.
Title: Re: Axe Parser
Post by: aeTIos on December 01, 2022, 06:51:10 am

@aeTIos
Runer112 gave me the source for either Axe 1.3.0 or 1.2.2 (I can't remember which and taking a quick peek at it I can't tell) a long time ago. If there is some very compelling evidence that he would be OK with me publishing it, I will.

Having looked at it more carefully, it is 1.2.2.

@E37
It is great to hear that at least the source is still around. I had read rumours that the source had been lost! Please hold on to that tightly... make some extra backups. Maybe we can summon @Runer112 somehow.