Omnimaga

Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on February 02, 2010, 04:16:50 am

Title: Features Wishlist
Post by: Quigibo on February 02, 2010, 04:16:50 am
If you have any requests for new commands post your ideas here.  also, it would be helpful if you provide what you think would be a good syntax for that command.  Keep in mind that if you redefine a BASIC command, it should either be useless or there should be a way to still perform the old command in a different way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 02:28:02 pm
True, I think it's essential to not completly ditch certain important commands for others.

As I suggested via yahoo a week ago, something like:

Text(Method,Y,X,string

For method:

-1=big fonts
0=small fonts
1=big inverted fonts
2=small inverted fonts

And obviously, for most drawing commands (maybe even Text(, if not too hard), store what's displayed in the graph buffer, not directly to the LCD, so people can update the display whenever they want (reducing flickering when sprites moves around for example)

EDIT: Not completly ditch pictures as support. Pictures as BASIC coders knew them I mean, else I don't think people will be very happy if their title screen takes 96 sprite slots and have to be displayed sprite by sprite
Title: Re: Features Wishlist
Post by: Silver Shadow on February 02, 2010, 03:25:44 pm
I want sprites. And possibly not only 8x8.
Title: Re: Features Wishlist
Post by: Quigibo on February 02, 2010, 04:28:18 pm
Sprites are absolutely an essential part of this.  I will probably only support 8x8 and 96x64 sprite sizes though.  If you need other sizes, you can write your own subroutines to display them.  For instance, in Pyoro, the bird is a 12x12 sprite, but I draw him using 4 8x8 drawing routines for each corner.  If I do end up supporting other sprite sizes, it will probably be very late into the development.
Title: Re: Features Wishlist
Post by: ztrumpet on February 02, 2010, 04:47:37 pm
This is so awesome!  I really like the different picture sizes.  :D
*ZTrumpet dosn't accually have a wishlist, as the other topic brought out all my suggestions. ;D
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 05:02:18 pm
The only feature i have to request right now is pixel editing and isKeyDown() to check whether or not a key is down :)
Title: Re: Features Wishlist
Post by: Galandros on February 02, 2010, 05:40:45 pm
A keyget command.
Use jim e routine (found in his grayscale lib) or the one in the WikiTI.

I can give a nifty routine to check only the arrows pad with multiple directions.
Title: Re: Features Wishlist
Post by: calc84maniac on February 02, 2010, 06:43:54 pm
With string parsing you should include an "escape character" like in most programming languages, so you can put quotes and sto (or even raw characters inputted as hex) into strings without hassle.
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 02, 2010, 10:23:13 pm
just out of random curiosity would/will there be like flashrom commands or somthing to interface with teh flash rom?


hmm trying to think of what else there could be XD
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 10:30:07 pm
Well for now i think we should just leave Quigibo in peace with what we have suggested so far, lets not let this get out off hand :P
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 02, 2010, 10:34:54 pm
hmm yeah probally a good idea :P 

hmm quigbo how much of the total app space have you used up so far??(out of teh whole thing :))
Title: Re: Features Wishlist
Post by: Quigibo on February 02, 2010, 11:28:09 pm
hmm quigbo how much of the total app space have you used up so far??(out of teh whole thing :))

Only like 4 or 5 kB so far I think.

Feel free to post all your ideas.  I just won't be able to implement them for a while, but its good to have a large collection of ideas for when I do.  I'm almost as the point where the commands and code for each command is completely templated, making adding new features a breeze.  After that point, the functionality will skyrocket.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 11:46:45 pm
Due to the recent increase in forum activity, let's just make sure to read through this thread before posting ideas to prevent reposting the same ideas many times when it gets big x.x, so it won't clutter the topic too much, altough if someone posted a confusing idea I could understand if someone posted the same idea worded differently, thinking it's something totally different
Title: Re: Features Wishlist
Post by: Eeems on February 02, 2010, 11:46:52 pm
A way to make intterupts would be nice. Like somehow registering a bunch and they disabling them at the end.
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 11:48:38 pm
Ooooh nice ^^  Well in that case here i go...

Screen Shifting (couldn't find a good token)
It could either be implemented, or you would use the simple hex codes, i hear its pretty short

Get()/Send()
Used for actual sending of bytes like in Omnicalc

OpenLib()
Import code form other programs (like include?)

DrawInv()
Inverts the screen

randInt(A,B
more support for random values.  From A to B

Func
Function support, like subs with arguments.

Output()
Similar function as in basic.  Makes text menus easier

Fill()
Fill/Outline rectangles

Recall/StoreGDb
Possible appvar storage?

Alright, those were all the ones i could think of.  Al the rest that i had in my head could be built of these pluss the graphics/sprites commands
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2010, 11:50:05 pm
I never got the send commands in Omnicalc. What's the use of sending a byte to another calculator? What does that bit does that is so much special? It was always cryptic to me, even after having read the manual.
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2010, 11:55:33 pm
It was so that you could make multilayer games using the link cables.  You could send a byte (0-255) to the other calculator which would recieve it if it was in get() mode.  You could set up a system where the calculators would be sending bytes back and forth that represent things like keypresses or positions, and have a multiplayer game set up.  I made a couple of games using this as a test, but mostly Basic was just too slow to handle the stress of having to take into account an extra player.  I made a few simple things like two players could move around on a screen and shoot things at eachother, but nothing ever was finished.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 02:10:21 am
yeah but how did you check what's the content of the byte? I mean if you wanted to send a keypress? Did you just put the variable name inside the command or could you just send a number from 0-255 to like the receiving calc ans var?
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 02:56:09 am
Well the send( command took a number as an argument, which could be any real from 0 to 255.  The get() command would return either a value from 0-255 in ans, or -1 if nothing was being sent at the time. 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:04:02 am
aaah ok, so i guess the -1 can be used to detect if the calcs are linked, right?
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 03:16:45 am
Yeah, and there was also a feature to have it wait indefinetaly for an incoming byte.  Once you get the calcs syncted up, it makes things a lot easier :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:42:55 am
Ah that's good. I guess in the future it could maybe be a good feature to add in Axe. I think dealing with linking in ASM is incredibly hard, though. Even ASM coders like Iambian or Calc84maniac have trouble with it.
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 05:05:07 am
Linking is easy.  Syncing is hard.  Really, no matter what routine I write for linking, it is up to the programmer to write code that will properly synchronize the calculators.  Lets say you need to send some critical data from calc A to calc B.  You have to send the byte, but calc B might not be ready to receive a byte, so you have to keep sending until calc B sends a confirmation byte back to calc A. When time is critical, you have to be very cautious about how often the calcs check to see if there are incoming bytes.  It needs to be frequent enough so there aren't long delays between sending, but sparse enough to not slow down the program.
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 10:26:05 am
Yeah, getting the calculators synced, and making them STAY synced with omnicalc was a real real pain.  I had a system that worked with omnicalc, but it made each program twice as slow because it spent half the time waiting for the other calculator x.x
Title: Re: Features Wishlist
Post by: Galandros on February 03, 2010, 12:18:20 pm
Could interrupts be suited to the task?
Implementing interrupts in Axe would be phenomenal.
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 03:14:36 pm
I actualy a command that I would like to see in the next release.  The ability to turn onblocl off.  It's a bit unhappy-making when you accidently get stuck in a loop durring testing and have to pull your bateries
Title: Re: Features Wishlist
Post by: Silver Shadow on February 03, 2010, 03:17:10 pm
Its even more horrible on the NSpire: you can't take out the batteries. The calc auto-shuts down before you have the time to do it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2010, 03:55:11 pm
Oh yeah on block off might be a good idea, back in the days I had a basic program where I used an ASM lib that disabled ON and a bug in a getkey loop caused the game exit functions to not work and I lost everything x.x
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 04:35:31 pm
I assume you all mean that when you press the on button, it breaks the program.  Unfortunately this is nearly impossible since you'd have to break out of an unknown amount of subroutines and the stack would not return the program to the home screen.  Now, I could implement something that saves the stack size and creates an interrupt for exiting when the on button is pressed, but it would take up probably around 200 extra bytes or so and be very complicated.

You will be able to poll the [on] key as a direct key input though, so you can always manually check if it needs to exit.

I have a feeling that if I do implement interrupts, it will be towards the end of the development.
Title: Re: Features Wishlist
Post by: ztrumpet on February 03, 2010, 04:47:16 pm
You will be able to poll the [on] key as a direct key input though, so you can always manually check if it needs to exit.
You're not understanding the Why.  The use of Breaking a program allows the programer to exit the code from anywhere, not just where the code checks for it.  Could you have this in there as an option please?  The reason it helps is because basic programmers test on calc, vs using an emulator.  I think it's possible, as the TiOS does it.  Could you backup the Ram into xRam and then rewrite if the user presses On?  Mabey you could use the token ">Dec"  to serve as "Debug (On breaks) Mode On"?
Mostly people that program On calc want security. :)  In my opinion that is the worst thing about Asm, or any program that Blocks On.  Thanks! :D
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 05:02:09 pm
It is not possible to arbitrarily break a program from asm without using interrupts and special exit code.  BASIC is interpreted so that's why it can break anywhere.

Luckily however, the security is taken care of by Axe Parser itself.  It will give you the option of automatically archiving all the RAM including your source code before testing your program so that if it crashes, you have everything backed up and you don't lose anything.  I will start working on these features in a few weeks probably.
Title: Re: Features Wishlist
Post by: ztrumpet on February 03, 2010, 05:16:13 pm
Thanks!  I think that would work too. :D
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 05:43:49 pm
Oh that's too bad.  Out of curiosity, what happens if you try to break out of the program while within a sub?  Does it just crash then?
Title: Re: Features Wishlist
Post by: calc84maniac on February 03, 2010, 05:54:26 pm
Apparently you can't break at all, so it doesn't matter. But Quigibo, if you save the stack pointer somewhere at the beginning of execution, it should be no problem (this method is used quite a bit in asm programs iirc)
Title: Re: Features Wishlist
Post by: Builderboy on February 03, 2010, 07:03:12 pm
So what would happen if you broke out of the program but didn't restore the stack pointer?
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 07:05:16 pm
Apparently you can't break at all, so it doesn't matter. But Quigibo, if you save the stack pointer somewhere at the beginning of execution, it should be no problem (this method is used quite a bit in asm programs iirc)
Yes I use this too.  But it would still require a special interrupt setup and interrupt routine which might prevent custom interrupts.  Regardless, I think I'll just worry about this later and focus on the more important stuff for now.

Quote
So what would happen if you broke out of the program but didn't restore the stack pointer?
It would return out of the subroutine without finishing it causing unknown consequences.  It would not exit the program either.
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2010, 11:59:59 pm
Sorry to double post, but I've just started to add the "Output()" feature and I'd like to get some feedback on it.

I know that native BASIC uses Output(y,x) but I much prefer the form of Ouput(x,y).  Should I keep it the old way to less confuse people transitioning from BASIC to Axe, or should I change it to (x,y) so that its more consistent with "Text(" "Pt-On(" and the other drawing commands?
Title: Re: Features Wishlist
Post by: calc84maniac on February 04, 2010, 12:02:28 am
Sorry to double post, but I've just started to add the "Output()" feature and I'd like to get some feedback on it.

I know that native BASIC uses Output(y,x) but I much prefer the form of Ouput(x,y).  Should I keep it the old way to less confuse people transitioning from BASIC to Axe, or should I change it to (x,y) so that its more consistent with "Text(" "Pt-On(" and the other drawing commands?
I think you should keep the old way, but start counting at 0 instead of 1.
Title: Re: Features Wishlist
Post by: jsj795 on February 04, 2010, 12:13:30 am
Also, I think Text() is also (y,x) along with pixel-on/off/change/check.
It's only line(), Pt-On/Off that's (x,y)
I'll rather have it (y,x), since I got so used to it
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 12:17:14 am
Haha, i would suggest using x,y and starting at 0 :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 04, 2010, 12:24:39 am
I personally would suggest x,y and starting with 0, to be more consistent with every other functions. I myself easily get confused with the BASIC output cuz I am so used to x being first in graphical functions except Text x.x

It would also help people get more used to standards
Title: Re: Features Wishlist
Post by: Eeems on February 04, 2010, 12:39:53 am
(x,y)
because of aforementioned reasons.
Title: Re: Features Wishlist
Post by: Silver Shadow on February 04, 2010, 07:04:40 am
(x,y) and starting from 0
Title: Re: Features Wishlist
Post by: Galandros on February 04, 2010, 07:06:33 am
Yes I use this too.  But it would still require a special interrupt setup and interrupt routine which might prevent custom interrupts.  Regardless, I think I'll just worry about this later and focus on the more important stuff for now.
Just hook the program interrupt and the break interrupt. Not hard, I think. And yes, essential features first.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:50:20 am
Haha, i would suggest using x,y and starting at 0 :P
I'd have to agree here. =)
Title: Re: Features Wishlist
Post by: Quigibo on February 04, 2010, 03:53:57 pm
Alright, (x,y) at 0 it is!  I've finished that command.  Interestingly enough, "Output(" and "Disp" are nearly identical commands.  The only difference is that output first gets the coordinate position.  Then, after the second comma, the compiler treats whatever follows as if it were a Disp command.  Since my Disp command, unlike BASIC, does not have automatic line returns, they really are equivalent!  That also means that things like Output(x,y,Str1,"Hello",Str3) are valid.

Thanks for the feedback!
Title: Re: Features Wishlist
Post by: ztrumpet on February 04, 2010, 04:23:01 pm
Wow, that's really cool.  So it's like this (in basic and on the graphscreen in my example): Text(-1,8y,6x,Str1,"Hello",Str3

Excellent!
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 05:14:34 pm
Woot!  So when is the next release coming around?  

* Builderboy is eager to start making primitive ASCII games in asm ^^ *
Title: Re: Features Wishlist
Post by: ztrumpet on February 04, 2010, 06:39:46 pm
ACHII
Do you mean ASCII?
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 06:51:19 pm
Haha yeah oops :P
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:40:58 pm
Wow, self aware software is apparently a master of typos. j/k :P
Title: Re: Features Wishlist
Post by: Builderboy on February 04, 2010, 07:42:47 pm
Its an imprecise technology >.>

Mostly the error was due to attempting to interface with such a device such as the iTouch using remotely controlled gerbils.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 04, 2010, 07:48:12 pm
Mostly the error was due to attempting to interface with such a device such as the iTouch using remotely controlled gerbils.
Lesson learned: Never use gerbils for a job better suited to something with opposable thumbs!
I'd also like to second that at some point, linking would be uber cool.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 02:15:31 am
Can't iTouch spellchecker be disabled? I personally would disable it if it was gonna do such typos x.x
Title: Re: Features Wishlist
Post by: Builderboy on February 05, 2010, 02:57:06 am
Yeah I think it can, imma have to see I can find that.
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 04:03:53 am
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

Another option is to store pictures using Hex code.
Code: [Select]
[3C7EDBFFBDC37E3C]->Pic1A
It uses less space in the source, but it would require you to run an external program to convert a pic into Hex code.

A third option is to save the sprites as tiles on one of the picture files.
Code: [Select]
GetCalc(Pic1,8,16)->Pic1A
The biggest problem with this is that the source is dependent on the extra picture files and it is difficult to draw the sprites on-calc (although I guess you can still use an external helper program).

Does anyone have any other ideas for how to define sprites?  Or a better syntax?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 05:27:19 am
If an hex code is done, I think it might be best that someone writes a binary to hex converter or something else it will be hard to add 300+ sprites in a game x.x

Maybe it would be cool if you allowed sprites to be stored in a set of TI-BASIC pictures, for example pic1, 2 and 3, and upon compiling, the user would be asked how many sprites the program will include. Then it would store each 8x8 sprites contained in the pic in separate sprites, scanning the pic from left to right and top to bottom, storing them inside your compiled program
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 08:16:47 am
Whatever method you choose for sprites I would prefer if Axe did not have to rely on a seprate external program to implement sprites. However, if the most efficient way to handle sprites is by the use of an external program then I am all for it. Hmm... perhaps sprites could be stored in a user defined appvar and called from there?

Actually, now that I am thinking more about it, I think an external program would be the best way. It would be used to edit, view, and save sprites.

For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.

Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.

At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Title: Re: Features Wishlist
Post by: Eeems on February 05, 2010, 10:04:15 am
I'd rather do hex for small sprites, but for large ones, what art said is good.
@builderboy:there is an option in settings, but be carefully if you are a fast typed like me, it can actually hurt you to have it turned off.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2010, 11:55:49 am
Actually now that you mention it, maybe the option of storing sprites to an external program might be an idea if the program is archived. That way games with a lot of sprites wouldn't be a big problem to be ran in 24 KB of RAM. The issue, though, is that running stuff from archive would be much slower
Title: Re: Features Wishlist
Post by: ztrumpet on February 05, 2010, 04:21:18 pm
Can you have "input" input at whereever the cursor is at, moved around with output?

------
Pictures:
I think you should have both Hex and external AppVars.  I think it would be easier like that.

If an hex code is done, I think it might be best that someone writes a binary to hex converter or something else it will be hard to add 300+ sprites in a game x.x
DJ, I wrote this a while ago.  It works for both 8*8 and 16*16 sprites.  You select what you want to do, and it will do exactly that.  It may take some trial and error, but I also have a screenie. ;D
Title: Re: Features Wishlist
Post by: Eeems on February 05, 2010, 04:36:43 pm
it could be slower unless at the start of the program it extracts the sprites to somewhere on the excess RAM and then run it from there (excess as in one of the extra pages, of course this could be limiting on newer calcs, who have way less extra ram...)
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 05:58:49 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 06:07:59 pm
To be clear I just meant the Appvar as storage to hold the sprites. When Axe compiles the program the sprite data would be copied from the Appvar to your new program. You'd only need the Appvar if you wanted to "build" the program. That way it wouldn't need to remain on calc after you complete your program. Although, If you release the source with your program, I'm sure you'd want to include the Appvar as well (so it would be buildable)
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 06:13:04 pm
To be clear I just meant the Appvar as storage to hold the sprites. When Axe compiles the program the sprite data would be copied from the Appvar to your new program. You'd only need the Appvar if you wanted to "build" the program. That way it wouldn't need to remain on calc after you complete your program. Although, If you release the source with your program, I'm sure you'd want to include the Appvar as well (so it would be buildable)
Why use an appvar?  Why not just a picture file?  The picture file would be less memory and in addition to that, it is more editable.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 05, 2010, 08:23:55 pm
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

In your original post you mentioned that using Picture files would take up alot of space, so I was trying to find an alternate workable solution. Perhaps I misunderstood and you just meant the picture files themselves were large? If that's the case, I don't mind. Picture files don't take up that much space in my opinion.  Additionally, if someone wanted to make a really large game they wouldn't have to worry about having to use hacked picture files. An Appvar can also be named whatever the user wanted. If using hacked pictures isn't a problem then picture files would be a much better solution.
Title: Re: Features Wishlist
Post by: Geekboy1011 on February 05, 2010, 08:36:51 pm
the only other reason i see y you would do as art said is that also there are only a small amount of pics and if your programming basic games as well at the time it could be hectic with remembering whats what X.x
Title: Re: Features Wishlist
Post by: Quigibo on February 05, 2010, 09:43:34 pm
Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
Code: [Select]
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

In your original post you mentioned that using Picture files would take up alot of space, so I was trying to find an alternate workable solution. Perhaps I misunderstood and you just meant the picture files themselves were large? If that's the case, I don't mind. Picture files don't take up that much space in my opinion.  Additionally, if someone wanted to make a really large game they wouldn't have to worry about having to use hacked picture files. An Appvar can also be named whatever the user wanted. If using hacked pictures isn't a problem then picture files would be a much better solution.

What I was referring to is drawing pictures in the program like you quoted.  "Pic1A" is just a name, not a picture file.  If you literally type out the 1s and 0s (or in this case, hyphens and asterisks) to make a sprite, that takes up about 10x more space than it needs to in the source.  But also, if you only have lets say ten 8x8 sprites in the game, and you store them in Pic1, then you are wasting 90% of that picture since you're not using all of it.  Also, if you include the size of the picture and the size of the source code needed to tell the calculator which part of the picture to use, then it really comes out to about the same memory usage as pure Hex code.

Edit: Actually, I take that back, you can archive the pictures.  But its still not that much more memory efficient than Hex.

BTW, is everyone aware that all the user variables: Labels, Strings, Sprites, Pictures, etc. all have 2 byte names similar to labels?  You are not limited to Str0-Str9, you actually have Str00-Str9Z, which is 370 strings total.  Same with sprites and everything else.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 01:25:15 am
mhmm nice to know ^^
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 06, 2010, 08:05:35 am
Ok, I see what you mean now. I think I'd prefer reading sprites from a Picture file, but hex sprites wouldn't be too bad either.
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 12:48:47 pm
I would like to have the option for both...and what about tokenized hex? That would decrease the size by half. Could you have like an option field so the user can enter where it wants it to grab the sprite from? And for hex, can it be from labels or something? That would be nicer for when you call the sprite more then once to cut down on source code size.
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 01:48:41 pm
This sounds really nice!
I think I'd write best in hex (My Preference). :D
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 02:09:18 pm
Yeah I'd prefer hex (unless I have a large amount of sprites) but with hex I'd rather have support for tokenized hex so I can save room. Tokenizimg hex is as putting the hex into a program doing the asmprog() on it, and then unlocking the program. Either that or justuse Celtic III's hex to bin function.
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2010, 02:24:29 pm
Hmmm, id rather not have tokenised hex, as then you would have to rely on other assembly programs besides Axe, and i think that would kind of defeat the purpose a little.  I personally would like either Pics or Pure Binary as the picture format storage, as they are the easiest to view and edit, a must while working on games.  Pics would be used when you have large ammounts of sprite data, and could be archived if needed.  And Binary would be used when you have a small amount of sprites or just want to play around a but.  And then when compiling the program, the pics/binary would be stored into the program itself so that there is no need for any pics/appvars to run your program.
Title: Re: Features Wishlist
Post by: Galandros on February 06, 2010, 02:44:54 pm
Base64 ftw. Kidding. ^^"

There are many ways to do the sprites storage...
I prefer a Appvar to store the sprites (and other data) in raw data (binary). Appvars can be any size we need, are compact and fast because we will store raw data. (this reminds CelticIII features...)
The only cost is we need some extra coding to edit the sprites and store to appsvars but it is definitely worth it.
Or just put it into the program file in the end after an special token with something like Data...
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 03:25:00 pm
@builderboy: what do you mean you would have to relly on other asm programs?? You would just recall the tokenized string/program into te source and then axe would parse it.
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 03:53:10 pm
@builderboy: what do you mean you would have to relly on other asm programs?? You would just recall the tokenized string/program into te source and then axe would parse it.
You somehow have to unlock the Asm program.  I'd use Oasis... ;D

After thinking about what Builderboy said, I think pure binary would also work nicely.  What do you think Quigibo?
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 04:02:40 pm
Well that's true, but you would usually have a shell or something on your calc. Or Quigibo could include something in axe that would let you do that.
I wouldn't like to use binary, it takes way too much room. But if you could let us have the option of with hex or binary that would work. 
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2010, 04:39:45 pm
As everyone will soon discover, later probably than sooner, all user defined variables are actually pointers.  Str1 and Pic1 will be able to be used anywhere the other can, they just point to where the data is.  So you can define a sprite with a string similar to tokenized hex, or vise versa if you need special characters.

Just to simplify things though, the next release will only support Hex sprites for now.  I'll get to the more complicated sprite formats later.
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 04:45:30 pm
ah ok, well that is good :D
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 05:30:50 pm
Yay Pointers!
Sounds good.  I can't wait for 0.0.4! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 05:42:18 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
Yep, that would be pretty useful. A lot of people use Paint/Photoshop to create their sprite sheets or they do them on calc and store as pics, so an editor like this would make it much easier for them to draw sprites, cuz creating sprites in hex can be quite hectic x.x
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 06, 2010, 07:31:07 pm
For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.

Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.

At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Pics would be used when you have large ammounts of sprite data, and could be archived if needed.  And Binary would be used when you have a small amount of sprites or just want to play around a but.  And then when compiling the program, the pics/binary would be stored into the program itself so that there is no need for any pics/appvars to run your program.
This is what I was saying as well. However change "Appvar" in my original quote to "Picture files".
Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?
Title: Re: Features Wishlist
Post by: ztrumpet on February 06, 2010, 10:18:52 pm
Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?
I like that idea, but I think it would be compiled to the format the calc uses for storing assembly programs. (I think it's internal-binary.  Am I right?)
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 10:26:41 pm
Tokenized. I want that too.
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2010, 10:59:25 pm
So these are the currently wanted formats to store the source data in if i cam correct:

Pics: Easy to edit and easy to view/preview sprites.  Take up a lot of space however and source will not be in one file.  Pics may or may not be archived to save memory, and storage is efficient with 8 pixels per byte)

Binary: Just 1s and 0s in the program, easy to type and edit, and easy to preview, however this is VERY memory inefficient, at 1 byte per pixel.  Cannot be archived either, as it resides in the source program.

Hex: Similar to Binary but every 4 bytes is represented as a char from 0-F.  More memory efficient but harder to see what the sprite is supposed to look like, and harder to edit.  Cannot be archives. 4 pixels per Byte.

Tokenised: Taking Hex a step further, each 2 hex codes is tokenized by a program or the OS and recalled into the program.  Twice as efficient, but even harder to edit/preview.  Cannot be archived.  8 pixels per byte.  Same storage capacity as a pic, but can change size according to how many sprites you need.

Appvar: Data is stored in an appvar by some sort of sprite editing program and can be archived for memory uses.  This is memory efficient but makes for difficult previewing and multiple files for the source.  8 pixels per byte.

I personally am for Pics and Binary, if only because Hex/Tokens/Appvars are difficult to edit quickly and preview without external programs.  Also for making large amounts of sprites, like for huge tilemaps, it would be nice not to have a bunch of hex/tokens in your program, and be able to view the whole sprite map in one pic.  It also helps for sprites that are greater than 8x8, as they will have to combine multiple 8x8 sprites, which might be difficult to do/visualize with hex/tokens.
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2010, 11:23:28 pm
By the way, tokenized sprites will not be able to work properly now that I think about it.  How would you indicate the end of the sprite data since every combination of characters is possible?  I would either have to use escape characters, in which case you might as well use hex, or you would have to predefine the size of the block of data.

Either way, I think this is against the point of the program.  You should not need any tools to actually code which is something I find very annoying about the BASIC language (like trying to get special characters).  The only tools you should need are those that will come built into axe which will include symbol charts, a sprite editor, a help manual, and maybe some other stuff.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2010, 11:44:07 pm
I never heard of tokenized sprite before x.x
Title: Re: Features Wishlist
Post by: Eeems on February 06, 2010, 11:57:53 pm
Well you could define how big it is and it would know. Also, you could provide a simple hex tokenizer for the developers.
Title: Re: Features Wishlist
Post by: Quigibo on February 07, 2010, 12:26:43 am
Don't forget, no matter what method you use to define sprites in the source, the assembled program will be the EXACT SAME SIZE.  And since you can archive your source files, and you can have more than one source file in the same project, efficiency is really a non-issue; they're just for the programmer's convenience.  Editing a sprite on-calc and then doing [rcl] [str1] or something for hex code seems, for me personally, to be the fastest and easiest way other than strait binary.  And also, I've already written code to read hex code used in the Asm() feature.  So only a slight modification will be necessary.  I can also modify my helper program so that 16x16 sprites can also be made easily.

The only advantages I see in using picture vars is that you can edit them on the computer and its easy to change an entire sprite set by just swapping a picture.  But I don't know how useful those features really are for most people.

By the way, I'm going to be very busy the next couple of days so the next update probably won't come until later in the week.

Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 07, 2010, 12:49:54 am
Keep in mind, though, that most of us have little to no asm knowledge, though, so it is hard for us to figure out why something will work and why it won't, and while it can be easy for some people to understand some stuff it can be much harder for others, not to mention there's a lot of info so eventually we forget some stuff. You have to understand that and make sure to not make people feel bad in any way. We don't want to scare away users from the forums (or from contributing to these project topics/ideas) after all. We welcome everyone, regardless of if they understand quickly or not.

That said good luck with your stuff including school and the like, I hope they won,t overload you with too much projects and stuff x.x
Title: Re: Features Wishlist
Post by: ztrumpet on February 07, 2010, 10:32:55 am
I never heard of tokenized sprite before x.x
DJ, this is what the calc stores Asm Programs in as AsmComp( takes them from Hex to Tokenized binary.
It basicly combines two hexadecimal numbers into one token.  Therefore, it's twice as small. :)

Have fun being busy. Good luck! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 07, 2010, 02:20:39 pm
Aaah that, I see. I always thought it was "compiled" or "squished" (the first is because of the Comp part of the AsmComp( command and the later is because some ASM programmers said "squished" ASM programs to define non-hex ASM program format.)
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 06:45:40 pm
I have a suggestion for the parser. You should have a character (I'm thinking "?") that acts as an operation modifier, for things that can possibly have more than one use. For example, "?>" could be used as signed compare, and "? or " would be bit-wise or, while " or " would be boolean or. It could also be used in strings as an escape character, for example ?" would put a quotation mark in the string and ?X41 would put the character 0x41 (or "A")
Title: Re: Features Wishlist
Post by: ztrumpet on February 09, 2010, 07:09:16 pm
Great idea!  I assume you mean strings would look like this: "Part 1"+?41+"Next Part"+Str1  If Str1 was "Hi" then it would result as "Part 1ANext PartHi".  Sounds cool. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 09, 2010, 07:19:46 pm
I'm confused what would it do x.x

I would need concrete examples of it in action to figure out x.x, as I am more visual
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 07:25:56 pm
Great idea!  I assume you mean strings would look like this: "Part 1"+?41+"Next Part"+Str1  If Str1 was "Hi" then it would result as "Part 1ANext PartHi".  Sounds cool. :D
Actually, I was thinking "Part1?X41Next Part"+Str1. The X might not be necessary I guess, but it might simplify parsing. To put a question mark in a string, you would use "??"
Title: Re: Features Wishlist
Post by: Builderboy on February 09, 2010, 07:29:59 pm
Usually what escape characters are for is for getting 'illigal' characters into strings, like -> or ".  Generaly speaking anything after an escape character is ALWAYS considered to be text, no matter what.  so "?->" would be a string containing the -> character.  It could also be used to access characters that are not type-able, like the percent sign or perhaps even the newline character.

Other uses it has is keeping up with the limited tokens that we have to work with.  If we wanted to be able to do both Bitwise OR and Boolean OR, without the escape character (which in this case can modify functions) we would need two different tokens for the two different functions.  With this escape/modifier, we could have individual tokens mean different things.

(And to get the ? character in your string, i guess you would have to do ?? in your string :P)

EDID: Ninja'd by Calc84
Title: Re: Features Wishlist
Post by: Quigibo on February 09, 2010, 08:16:10 pm
The next version has already taken care of getting 'illegal' characters into strings using standard tokens.

Let me just explain signed vs unsigned so it doesn't confuse anyone.  All the numbers are unsigned meaning they represent a number between 0 and 65535.  Negative numbers act just like the regular numbers counted backwards instead of forwards, that is -1 is really 65535, -2 is really 65534, etc.  This allows normal subtraction and addition with negative numbers that everyone is used to.

That's all well and good until you have a statement like -1<1.  That would actually be false since 65535 is not less than 1.  You can get around this by doing a 'signed comparison' which is what calc84maniac is talking about.  The limitations with signed comparison is that your numbers can only be half the size, that is -32768 to 32767.  So you would not be able to use the signed comparison (and get the correct answer) if the number is too large or too small.

This is an good idea to implement, but I think I would want it more intuitive than a question mark.  Maybe something like -1<<1 would be better?  Repeating any operation twice will do the signed version of the operation.  So -4<<2 equals 1 and -2**8 would equal -16.

Oh and by the way, bitwise and Boolean or are identical, there is no reason to separate the 2.
Title: Re: Features Wishlist
Post by: calc84maniac on February 09, 2010, 11:38:20 pm
The next version has already taken care of getting 'illegal' characters into strings using standard tokens.

Let me just explain signed vs unsigned so it doesn't confuse anyone.  All the numbers are unsigned meaning they represent a number between 0 and 65535.  Negative numbers act just like the regular numbers counted backwards instead of forwards, that is -1 is really 65535, -2 is really 65534, etc.  This allows normal subtraction and addition with negative numbers that everyone is used to.

That's all well and good until you have a statement like -1<1.  That would actually be false since 65535 is not less than 1.  You can get around this by doing a 'signed comparison' which is what calc84maniac is talking about.  The limitations with signed comparison is that your numbers can only be half the size, that is -32768 to 32767.  So you would not be able to use the signed comparison (and get the correct answer) if the number is too large or too small.

This is an good idea to implement, but I think I would want it more intuitive than a question mark.  Maybe something like -1<<1 would be better?  Repeating any operation twice will do the signed version of the operation.  So -4<<2 equals 1 and -2**8 would equal -16.

Oh and by the way, bitwise and Boolean or are identical, there is no reason to separate the 2.
But shouldn't << be shift left or something?

Also, bitwise and boolean OR are different.
5 | 2 = 7
5 || 2 = 1 (and the "2" expression isn't evaluated because 5 is non-zero)
Title: Re: Features Wishlist
Post by: Quigibo on February 10, 2010, 12:14:53 am
If you want 5 | 2, then you can do "5 or 2".
If you want 5 || 2, then you can do "5≠0 or 2≠0" since this is basically what a Boolean "or" would do for you anyway.  While I agree it could be made more efficient by a c style Boolean operator where the second argument may be skipped if it does not need to be checked, I don't think its worth it.  You're almost always going to use "or" and "and" when comparing two expressions that already have some type of equality operator.  I think the introduction of 2 different types of "or" will just confuse many programmers and make the coding more complicated since there would have to be some weird way to differentiate the two.

But now that I think about it, maybe I should make the regular "or" "and" "xor" the Boolean versions (like basic) and then add new commands for the bitwise operations.  I'm thinking to use the plot symbols for this.  The little dot will be "and", the little plus sign will be "or" and the little square will be "xor".
Title: Re: Features Wishlist
Post by: ztrumpet on February 10, 2010, 04:27:37 pm
But now that I think about it, maybe I should make the regular "or" "and" "xor" the Boolean versions (like basic) and then add new commands for the bitwise operations.  I'm thinking to use the plot symbols for this.  The little dot will be "and", the little plus sign will be "or" and the little square will be "xor".
I like this way, as I think all the basic programmers would wonder something like why dosn't "A or not(C" work right.  I really like booleans as " and " " or " and " xor ".  Also, are you using not( ?
Title: Re: Features Wishlist
Post by: Quigibo on February 11, 2010, 12:28:58 am
So I've redone a lot of the code.  You won't notice it, but it is much more organized on the inside now making it easier for me to add future features, and there's still a lot more that could be organized further.  Anyway, I've got a to-do list a mile high right now.  I still haven't actually made many of the mentioned corrections yet.  Most of these things are very minor, but very important like parsing order of operations, rewriting some code so that I will be able to handle pointers, the for loop, etc.

Although I could get to doing sprites right away, they're very easy to do, I feel I should finish these corrections first so that everything will just work better.  So either I will release the next version with sprites a little later than I anticipated, or I will release an intermediate version with some of the corrections and then the version after that will finish most of the corrections and include sprite handling.

btw, haven't made use of "not(" yet.  Its on my list.

Oh and I'd like some feedback on this: Should I continue to exclusively use multiblock "If" statements?  Or should I do what BASIC does and allow single or multiblock?  The disadvantage is that then you would have to add the token "Then" after every multiblock statement.  The compiled program will be the same either way, but what is more convenient, never needing the "Then", or sometimes not needing the "End"?
Title: Re: Features Wishlist
Post by: Builderboy on February 11, 2010, 12:32:05 am
Hmmm thats a good question.  I'm tempted to have it be done the way TiBasic has it, if only for readability.  Then again, i do see how usefully it is to not have the burden of a Then after each if (especially since it sometimes takes a whole line x.x)

Soooo i'm on the fence on this one, so I say keep it the way it is :P
Title: Re: Features Wishlist
Post by: Quigibo on February 11, 2010, 12:42:33 am
By the way, I am considering adding the ternary operator (http://en.wikipedia.org/wiki/Ternary_operation) to take the burden off of quick if statements.

The syntax will like this:

statement ?( expression1 , expression2 )

If the statement is true, the expression becomes expression1, if it is false, it becomes expression2.  So for instance:

A<B?(A,B)

Returns the minimum of A and B.  It is equivalent in BASIC like this:

:If A<B
:A
:Else
:B
:End

So quick things like

:If K=15
:A+1->A
:End

can be written like this:

K=15?(A+1->A,)
Title: Re: Features Wishlist
Post by: Eeems on February 11, 2010, 12:53:09 am
I like that!
I like the multiblock if statements, and then this works good for single statements.
Can't wait for more updates!
Title: Re: Features Wishlist
Post by: Builderboy on February 11, 2010, 01:04:17 am
Oh yeah! The Ternary operator! ^^ I remember that from Java and its lots of fun, especialy because its like an if statement that can be used in expressions :D
Title: Re: Features Wishlist
Post by: ztrumpet on February 11, 2010, 04:05:17 pm
Oh and I'd like some feedback on this: Should I continue to exclusively use multiblock "If" statements?  Or should I do what BASIC does and allow single or multiblock?  The disadvantage is that then you would have to add the token "Then" after every multiblock statement.  The compiled program will be the same either way, but what is more convenient, never needing the "Then", or sometimes not needing the "End"?
I'd keep it how it is now.  I don't like using all the ":Then"s that must be used in Ti Basic.

I've never heard of the Ternary operator.  It looks really cool, though. ;D
Side note: This is my 800th post. =)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 12, 2010, 05:03:16 am
Btw in TI-BASIC it's

If <Condition>
Then
<code>
Else
<code>
End

not

If <Condition>
<code>
Else
<code>
End

And you can also do

If <Condition>
Then
<code>
End

However I am lost now. I am a bit confused by that feature request, because it contains a lot of terms I never heard before, programming-wise. Are people implying that the ability to use multiple lines of codes inside If blocks will not be possible in Axe or the opposite?

it would suck to have to do like on the TI-81:

If A=1
<first code to run if condition is true>
If A=1
<2nd code to run if condition is true>
If A=1
<3rd code to run if condition is true>
If A=1
<4th code to run if condition is true>

or the opposite, having to do

If A=1
Then
D->B
End

instead of

If A=1
D->B
Title: Re: Features Wishlist
Post by: Quigibo on February 12, 2010, 06:18:15 am
Single line expressions can be executed by using the ternary.  In your example, you could either do it with blocks like this:

If A=1
D->B
End

or, because its a single expression, do this:

A=1?(D->B)

which is more compact than the regular TI basic.  I don't think I will use the "Then" token at all, maybe I'll re-code it do something else in the future.

Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 12, 2010, 09:07:00 am
aah ok thanks for clarifying.
Title: Re: Features Wishlist
Post by: ztrumpet on February 12, 2010, 04:49:03 pm
Sounds great!  I'm liking the more that I see of the ternary operator. ;D
Title: Re: Features Wishlist
Post by: Builderboy on February 13, 2010, 01:36:27 am
Indeed.   Mmmmm another question, are Boolean expressions going to be evaluated with short circuit evaluation?  For example withe if(A and B) if A is false, the program doesn't event bother to test B, and with if(A or B) if A is true you wouldn't need to evaluate B either.  I know java has this implemented, and was wondering how it is set up now.
Title: Re: Features Wishlist
Post by: Eeems on February 14, 2010, 12:53:14 pm
Hmm, I was wondering, could Celtic III style program control be added? So like, calling another program, getting a list of programs, creating a program, deleting a program, etc.
Also are you planning in adding string operators? Like sub() inString() and such?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 14, 2010, 03:00:27 pm
not sure, I think he only planned most pure-basic commands
Title: Re: Features Wishlist
Post by: Quigibo on February 14, 2010, 03:22:01 pm
Hmm, I was wondering, could Celtic III style program control be added? So like, calling another program, getting a list of programs, creating a program, deleting a program, etc.
Also are you planning in adding string operators? Like sub() inString() and such?

Its too soon to tell.  I'm not sure if I will have commands for program manipulation, but there will definitely be a way to create, save, and load application variables.

String handling is going to be very different since all strings are constant length.  It is very easy to get a substring if it ends at the normal ending, you can just do Disp Str1+A.  For anything else, you can write your own subroutine to copy part of the string to a buffer and then display the buffer instead of the string.  I can probably automate this but I would use a different command instead of sub().  Its still faster than the TI-BASIC sub() command.
Title: Re: Features Wishlist
Post by: Eeems on February 14, 2010, 04:41:06 pm
ah ok, hmm, interesting... Automated would be nice... Of course that isn't a priority right now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 14, 2010, 11:36:14 pm
can strings be used in a way that they can be tilemaps like some people do in TI-BASIC? See Illusiat 13 for an example. Illusiat 13 maps are  128 chars long each, btw, which fills the entire home screen
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 12:22:29 am
Data is data.  String = Picture = List = Hex.  It also equals executable code, but that part is my job  ;)

You can use strings however you like.  You would probably use decimal numbers or hex code for a tile map, but if its more convenient, then yes you can use a string as well.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 15, 2010, 12:37:32 am
Ah ok. What I like with strings is if we use ASCII maps (or dual layer like in Serenity/Elmgon, assuming we use Storepic/Recallpic too), is that each map rows are drawn almost instantly. Maybe with Axe, doing so with sprites won't make much of a speed difference anymore, though, since TI's text display routines are slow by nature compared to a third-party sprite routines :P
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 01:09:30 am
That's right, drawing 8x8 sprites is actually FASTER than drawing text.  Not only because the routine is faster, but also because it is drawn to the buffer instead of directly to the screen.  This is a paradigm you'll just have to get used to.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 15, 2010, 01:14:03 am
This is pretty much why now ASM programmers who make advanced games now make their own font displaying routines I guess
Title: Re: Features Wishlist
Post by: Quigibo on February 15, 2010, 02:37:33 am
I had to do that in Pyoro for the scores.  The main reason was because regular font will not display correctly in the grayscale engine I made, and to make drawing as fast as possible in the least amount of memory, aligned 8x8 sprites are the way to go so I had to make my own number font to fit this size.  It was 7x8 instead of the standard 5x7.
Title: Re: Features Wishlist
Post by: ztrumpet on February 15, 2010, 09:44:23 am
That's pretty cool. (7x8) I had no iea text was so slow comparitivly.  Wow. ;D

By the way,very nice sig, Quigibo! :D
Title: Re: Features Wishlist
Post by: calc84maniac on February 15, 2010, 07:13:17 pm
I think a nice feature would be to expose the graph buffer as an array or pic or what have you. Could be useful for more complicated effects, if people want to write their own routines
Title: Re: Features Wishlist
Post by: Eeems on February 15, 2010, 09:28:17 pm
I was wondering...what about an arguement kind of thing, like with batch files, so you can call another program from it and pass it arguements, and then the arguements are pre defined variables tha can be used by the called program.
Code: [Select]
prgmAA arg1 arg2and then prgmAA could do something like this
Code: [Select]
output(0,0,%1
or we could just make the args the ans variable so that basic programs can pass stuff to it.

Edit: hmm I also had the thought while trying to port hunt to this (it's becoming my standard hello world :p) axe is still missing the basis of a good ai...random numbers within a certain amount...so how hard would it be to add a randInt() command?
Title: Re: Features Wishlist
Post by: Quigibo on February 16, 2010, 01:23:22 pm
randInt will come eventually.  The best way to get random numbers between A and B inclusive is like this: A+rand^(B-A+1) and this will basically be what that function will do.  So if you need a number 1-5, then simply do this: rand^5+1

Passing parameters is unnecessary complexity.  Saving into variables in the main program and then recalling them from the subprogram is about as efficient as it can get and is much simpler to understand for the programmer.  But like I said, I'm not sure if I will allow program modification tools.  You can embed an external program inside the compiled program and call it from there, but you will most likely not be able to call an arbitrary external program from the compiled code.  That would require error handling, something which I will add later, using the "Theta" variable.  0 means no error and all the other values represent different types of errors so you can check if some of the higher level commands executed properly.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 16, 2010, 02:13:39 pm
Just try to not change the syntax from TI-BASIC way too much, though. Just a suggestion, but this is what turned away people from most other BASIC-like languages on calc. They claimed themselves to be as easy as TI-BASIC+xLIB, but finally they weren't even that much easier, so people stuck with TI-BASIC.
Title: Re: Features Wishlist
Post by: Eeems on February 16, 2010, 04:24:07 pm
ah ok, well thanks that beats my method which was rather crude and ineffective.
Title: Re: Features Wishlist
Post by: Eeems on February 17, 2010, 07:28:47 pm
I was wondering if you could add in support for DCS headers and such? icons too?
Title: Re: Features Wishlist
Post by: Builderboy on February 17, 2010, 08:03:42 pm
Mmmm since it is not possible to compile archived programs, do you think you could remove them from the compile menu?  Just a little nag :P
Title: Re: Features Wishlist
Post by: Quigibo on February 18, 2010, 10:11:01 pm
It will be possible in a future version, so it I don't feel like adding something that will just be removed later.

A different idea though, is requiring all Axe programs to have a particular header in order to show up on the list.  That would remove the clutter of BASIC programs, would that be more or less annoying than the clutter?  What does everyone think about that?

Also, I am thinking in the far future to release a developer kit for asm programmers to add Axioms, which is a clever name for importable libraries to add new commands to extend the features even further.
Title: Re: Features Wishlist
Post by: Eeems on February 18, 2010, 10:37:39 pm
Hmm, the headers could work, and the Axioms idea. I had been thinking for a while about having an include statement so you can split your file into smaller more managable chunks for development.
How would these Axiom work? 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 19, 2010, 02:17:38 pm
I would like an header, it would make the list much less cluttered, especially that it's not in alphabetical order. In future versions I hope you also planned to let us choose the compiled program name :P
Title: Re: Features Wishlist
Post by: Quigibo on February 19, 2010, 02:31:02 pm
The include statement will just be inserting "prgmNAME" into the code somewhere.  I'm not sure how the Axioms will work, but they definitely won't be available on any time soon.

Just to give everyone a heads up, I am making a major change in the next version.  I ran into a problem.  When you display stuff, how does the compiler know in what format to display it?  How does it know if you want to display a string, a number (and if so, in what base?), or a character?  All three of those have a number as an argument, either as a pointer for strings, or a number for the ASCII value of the character and the plain old base 10 representation.  Therefore, I must add some way to tell how you want to display that number.

So in the future, you can display a string by omitting any additinal notation, as you have already been doing, but to tell it that that number is not a pointer to a string, you have to use >Dec at the end to tell the Disp or Output command that you intend to display that number as a base 10 representation.  Similarly, I might use >Frac to display the ASCII value of the number.

Sorry if this makes things a little inconvenient, but it will only reduce the size of the compiled program and add even more flexibility.  Its a very simple thing to fix to make older programs compatible with the next version.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 19, 2010, 02:59:56 pm
shouldn't be too much trouble to get used to I guess, if it can make it easier to compile and reduce size ^^
Title: Re: Features Wishlist
Post by: ztrumpet on February 19, 2010, 10:01:02 pm
Sounds great.  I like the header and Axioms ideas.  I also am fine with the changes to Disp.  Good luck! ;D
Title: Re: Features Wishlist
Post by: calc84maniac on February 22, 2010, 01:54:38 pm
I think we definitely need support for Else. Also, clipped sprites would be nice (I can help optimize if you want)
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 02:48:37 pm
Yeah, the sprites right now are not clipped.  I was thinking of adding that, but I was kind of in a hurry.  That would be great if you can optimize a routine for me!  I need it optimized for size, not speed though.

I'll get working on Else soon.  You can do this in the mean time:

If <statement>
<code to do if true>
Goto 1
End
<code to do if false>
Lbl 1
Delvar 1

The asm code generated from this will be identical to the code generated when using Else.
Title: Re: Features Wishlist
Post by: Galandros on February 22, 2010, 03:02:40 pm
True. But else is more readable.

The trouble coding the Else is worth for a cleaner source.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 03:28:22 pm
Does that cause a mem leak like in Basic?

I can't wait to try 0.0.5! ;D
 *ZTrumpet hurry's over to download...
Title: Re: Features Wishlist
Post by: Galandros on February 22, 2010, 03:47:21 pm
Does that cause a mem leak like in Basic?

I can't wait to try 0.0.5! ;D
 *ZTrumpet hurry's over to download...
No because it is compiled into assembly. There are leaks in assembly, though... But with different nature of the BASIC ones.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 04:17:03 pm
(Thanks Galandros!  ZTrumpet gives Galandros a cookie...)

I had an idea!
Can you make a "screen to buffer command", in which the buffer is updated with the current screen?
Also, where is the buffer? Is it the AppSaveScreen? (That's the only place I can think of now, but I've probably only got a 25% chance of being right...)
Thanks! ;D
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 06:11:06 pm
You can still leak in Axe Parser, but only by calling a subroutine that keeps calling itself in a non-terminating infinite loop.  I mean, you can have subroutines call themselves if you want to have a recursive subroutine, but it has to actually exit somewhere.  All the other commands are leak-proof unlike basic.

The next update will definitely have Else, but I'm not sure if it will have the Ternary operator since I have so many other things to do.

Btw, the buffer is stored in plotSScreen.  What would be the use of copying the screen to the buffer?  All of the drawing commands draw to the buffer anyway.
Title: Re: Features Wishlist
Post by: ztrumpet on February 22, 2010, 06:34:27 pm
You can still leak in Axe Parser, but only by calling a subroutine that keeps calling itself in a non-terminating infinite loop.  I mean, you can have subroutines call themselves if you want to have a recursive subroutine, but it has to actually exit somewhere.  All the other commands are leak-proof unlike basic.
Great! :D
Btw, the buffer is stored in plotSScreen.
Thanks!
What would be the use of copying the screen to the buffer?  All of the drawing commands draw to the buffer anyway.
I was thinking that if you had a basic program that calls an Axe program, then somehow you'd want to be able to put the screen on the buffer.  This is to allow interactions with the screen with an Axe program as a subroutine.  Does this seem like a good idea/reason?  Thanks! ;D
Title: Re: Features Wishlist
Post by: Eeems on February 22, 2010, 06:37:30 pm
I was wondering, how hard would it be to let people name their labels with more then two letters?
hmm, it would be nice to have a secondary buffer that you could store too, but that would be easy to do with pictures...
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 08:52:41 pm
I wish I could name labels and strings and pictures of arbitrary length!  The problem is that the calculator has EXTREMELY limited memory.  Each individual label currently takes up 5 bytes.  That is 2 bytes for the location the label is pointing to, 1 for the type, and 2 for the letters.  I need these to be in a continuous array in ram.  The largest free ram is 768 bytes and so rounded to 750, that's exactly 150 Labels.  If each label was 7 letters, you would only be allowed 75 labels.  Unless I can somehow figure out how to read and write data directly to ROM, there really just isn't enough memory to keep track of long names.
Title: Re: Features Wishlist
Post by: Builderboy on February 22, 2010, 08:56:05 pm
Well I haven't worked with Axe or Assembly very much (not Assembly much at all) but is 150 labels/subs really very necessary?  Maybe its just my BASIC attitude towards labels but it would seem to me that you wouldn't need to use them that much.  
Title: Re: Features Wishlist
Post by: Eeems on February 22, 2010, 08:59:37 pm
Ah ok :/ well I was just thinking...you could set it up so that if it jumps to a label or calls it, instead of having labels stored you can parse the location of the label instead into the goto, kind of like assembly is done.
Title: Re: Features Wishlist
Post by: Quigibo on February 22, 2010, 09:20:26 pm
Well I haven't worked with Axe or Assembly very much (not Assembly much at all) but is 150 labels/subs really very necessary?  Maybe its just my BASIC attitude towards labels but it would seem to me that you wouldn't need to use them that much. 
Its not that labels in particular that worry me, its the naming of strings, sprites, pictures, etc. that you often need to name a decent amount.
Title: Re: Features Wishlist
Post by: Builderboy on February 23, 2010, 10:28:53 am
Ah i see, so the same memory is used for variable names as well?  I can see where the problem might arise.
Title: Re: Features Wishlist
Post by: ztrumpet on February 23, 2010, 09:53:28 pm
I was thinking something along the lines of this.  I whipped it up in about an hour:

(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
This is amazing!  I never realized i was in basic.  When I put it on my calc today, it errored because it is in Basic, and basic is not ran "Asm(prgmAHEX". ;D
Excellent job on this Quigibo! :D
Title: Re: Features Wishlist
Post by: Builderboy on February 23, 2010, 10:01:53 pm
The run indicator tipped me off ;) That is a good job though, good work :)
Title: Re: Features Wishlist
Post by: calc84maniac on February 26, 2010, 03:51:53 pm
The Asm( code parser needs a way to insert pointers to variables, methinks.
Title: Re: Features Wishlist
Post by: Quigibo on February 26, 2010, 04:01:17 pm
Sure.  Lets say you do this:

<asm code 1>
ld hl,(var_A)
<asm code 2>
ld (var_A),hl
<asm code 3>

You can do:
Asm(asm code 1):A
Asm(asm code 2):->A
Asm(asm code 3)

More generally, the variables are stored in saveSScreen in alphabetical order and then the random seed immediately follows.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 26, 2010, 04:56:18 pm
btw I do hope Asm( in axe will not have the slow loading that hinders the BASIC version of it x.x. In BASIC, the lower your RAM, the longer it takes for an ASM program to even startup at all with Asm( and it's even worse with many files on your calc. Again, thought, maybe you won't have this problem since the ASM code would most likely be included inside the Axe program, not as an external program, requiring searching the entire VAT for it (which is what slows down Asm( that much in BASIC, I think). An example of how slow Asm( can be is The Reign Of Legends 3 map loading. Each Asm(prgmCODEX instructions takes about 0.25 seconds to execute. Not too bad for a one-time execution, but it's another story when you are using it in a loop.
Title: Re: Features Wishlist
Post by: Builderboy on February 26, 2010, 07:57:18 pm
I believe the Asm() hex codes are added right into the program so there is no speed loss at all.

BTW: Did you find the weird error problem that was popping up?
Title: Re: Features Wishlist
Post by: Quigibo on February 27, 2010, 03:05:02 am
Unfortunately no, I haven't been able to spot a pattern in the errors yet, but I haven't done a rigorous debugging either.  I'll do that tomorrow probably.
Title: Re: Features Wishlist
Post by: Silver Shadow on February 28, 2010, 01:38:02 am
Could you possibly implement lists and/or matrices? It's the only way I've got to do my game engine for Crystal Defenders...
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 01:44:25 am
That's already been done.  It will be in the next release coming very soon.  You have to manually store data though since I haven't added automated data structure support yet.  I'll explain what I mean by that when I release it, but basically you have to keep track of the size of the array, dimensions of the array, and maximum size of the array yourself.
Title: Re: Features Wishlist
Post by: Raylin on February 28, 2010, 09:50:10 am
If time allows, the greatest feature you could add to Axe:

RICKROLLS MID-PROGRAM!





... Kidding.
I would personally like to see greyscale support and the speed of said function.
Perhaps an entire Pic (96x64) to Hex program...?
It would make those title screens easier on the calc.
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 12:37:55 pm
Yeah, you won't even need a title screen to hex program because when do I add splash screen support, it will just use the calc's pictures and copy the ones you choose into the program.  If you need more than 10 pictures you can always write them in Hex if you're really desperate, but I think there are some Pic-to-AppVar programs out there and I might support AppVars where you normally enter a picture.  Grayscale will take a while but I can't think of a good syntax for it yet...
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2010, 12:44:31 pm
When you say copy, you mean at compilation and not during running right?  It would be a tad bit silly if Asm programs were dependent on Basic Pic variables for execution ;D

I dont pretend to know how greyscale works, so this might be the complete wrong approach, but could it be as simple as using PxlOn(X,Y,V) where V is a value from 0 - 2 representing color?  Would it use automatic interrupts or some sort of manual graph buffer copying?
Title: Re: Features Wishlist
Post by: Quigibo on February 28, 2010, 04:15:16 pm
Copy means copy during compile time of course :)

The way grayscale will work will be that all drawing routines actually draw to both buffers at the same time.  When you use DispGraph in grayscale mode, or maybe it will just be a different command, It displays the first buffer mixed with half of the second buffer.  Then the next time its called, it automatically switches to using the other half of the second buffer.  It will not automatically be gray.  You have to constantly redraw the screen in the main loop.

You can automate that when I add interrupt support, but I'm nowhere near ready for that now.
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2010, 04:42:24 pm
Thats genius!  :O
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 28, 2010, 11:47:43 pm
I am a bit confused, basically does it means it will quickly swaps back and forth between both buffers? I believe this is how TI-86 grayscale works, except on these one of the buffer is displayed for a shorter amount of time since they have 4 levels of gray. I think 3 levels should be enough for Axe (like in Pyoro, F-Zero and Reuben Quest)
Title: Re: Features Wishlist
Post by: calc84maniac on February 28, 2010, 11:56:55 pm
I think a nice feature would be something like the Switch statement in C, for when you have a lot of different values to check against (like colliding with a tilemap or handling various different types of objects). It should generate a jump table, and probably be forced to values from 0 to N (if you want A to A+N, just subtract A from the value you are switching).
Title: Re: Features Wishlist
Post by: Eeems on March 01, 2010, 09:42:56 am
Yeah a switch statement would be nice. Also it probably shouldn't be that hard to make.
Title: Re: Features Wishlist
Post by: Galandros on March 01, 2010, 09:46:29 am
I think a nice feature would be something like the Switch statement in C, for when you have a lot of different values to check against (like colliding with a tilemap or handling various different types of objects). It should generate a jump table, and probably be forced to values from 0 to N (if you want A to A+N, just subtract A from the value you are switching).
A vector table would save bytes if it is large enough. Speed is not substantially different.
Title: Re: Features Wishlist
Post by: ztrumpet on March 01, 2010, 05:39:17 pm
I like your plans for greyscale!  It sounds really cool! :D

Yeah a switch statement would be nice. Also it probably shouldn't be that hard to make.
I think Switch would be very nice indeed! ;D
Title: Re: Features Wishlist
Post by: Eeems on March 01, 2010, 10:35:45 pm
Adding in compoliler commands like .IF .ELSE .END etc that will allow for compiling based on which calc you are on and such.
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:29:27 pm
I'd reeealy like to see signed comparisons and operations.  It would make a lot of things a whole lot easier.  Also, would it be hard to add the 'step' optional argument to the For loop?  Its killing me that i cant go backwards XD
Title: Re: Features Wishlist
Post by: trevmeister66 on March 01, 2010, 11:32:04 pm
I don't know if it's been talked about, but 16x16 sprites possibly?
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:35:44 pm
I think its been mentioned, and its been said that you can just write your own routines to display 16x16 fairly easily in Axe.  And that if he ever does support it, it will be late in development.  For now you will have to settle for 4 8x8's :P
Title: Re: Features Wishlist
Post by: calc84maniac on March 01, 2010, 11:42:59 pm
I think NES and Gameboy display hardware had this limit too. Think retro! :D
Title: Re: Features Wishlist
Post by: Builderboy on March 01, 2010, 11:49:55 pm
:P I know what there are no negative numbers in the calc, and I know of ways to do the correct math.  Its just weird that -(-D*2) is NOT equal to D*2, and it would be nice if it did ;)

Title: Re: Features Wishlist
Post by: trevmeister66 on March 01, 2010, 11:58:32 pm
I think its been mentioned, and its been said that you can just write your own routines to display 16x16 fairly easily in Axe.  And that if he ever does support it, it will be late in development.  For now you will have to settle for 4 8x8's :P
Gotcha. I figured that is what was going to be.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 01, 2010, 11:58:57 pm
Given how incredibly fast many alien ships moves around in the space invader Axe screenshot, I think having to use 4 8x8 sprites will not drain speed too much
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 01:04:13 pm
By the way, I added a 15MHz mode in the next version and its incredible!  Why didn't I know about this when making pyoro?  I could've had 8 level grayscale or something!  But the downside is that if you use this mode, your games will run 3 times slower with an 83+ than with the other calculators so compatibility becomes an issue.

Maybe I should just make all math signed... it would only cut the maximum number limit in half from 65535 to 32767 which is still probably big enough for most applications.  I think it will get confusing to have 2 sets of operators, especially for those not familiar with signed/unsigned math.  It would only affect multiplication, division, modulus, and inequalities I think.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 02, 2010, 02:10:11 pm
15 MHz would be cool, altough yeah it might cause incompatiblities issues. I think for simpler games I would probably stick to 6 MHz. Plus 8 level grayscale must take a lot of memory x.x

As for signed, would it be better to have unsigned integers? 32767 might be a bit small. For high scores, though, the person can simply add more zeros at the end, but if someone decided to make some small RPG, it might become an issue for gold pieces, especially if he's porting an older BASIC RPG to Axe.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 02, 2010, 03:44:57 pm
You absolutely need to add 15 MHz mode!
Compatibility isn't really a problem, if somebody really needs to make it work on the 8 MHz one,he could have 2 versions or a frame skip option...
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 04:26:23 pm
that could work
you could use the compiler commands I suggested for that so that it will compile the correct version on calc :)
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 04:38:29 pm
By the way, I added a 15MHz mode in the next version and its incredible!  Why didn't I know about this when making pyoro?  I could've had 8 level grayscale or something!  But the downside is that if you use this mode, your games will run 3 times slower with an 83+ than with the other calculators so compatibility becomes an issue.
Can we chose to have 6mhz if we want?  This would allow games to run the same, when speed is not an issue.

Could we do something like
.6MHZ
and
.15MHZ
to control the speed at the beginning?
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 04:52:31 pm
I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 04:53:52 pm
I've already added it, this is how it works.  You will use the command "Full" found in the modes page and it stands for full speed mode.  However, the command also returns a value.  It will be false (zero) if the calculator does not support 15MHz and true (non-zero) if it does.  So if you had a game you only wanted to be able to run on 15MHz calcs, you can do this:

:!If Full
:Return
:End

That would quit the game if the Full command failed.  If you don't care about the type of calc, then you just use it normally like this:

:Full

The command "Normal" returns to regular speed and doesn't return a value since it can never fail.
Awesome!
I can't wait for 0.0.7... ;D
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 05:20:14 pm
ah cool
well this does work, but it doesn't allow for what I had in mind. I was thinking something like this:
Code: [Select]
!If full
-code1-
Else
-code2-
End
would compile to -code1- on a 15MHZ calc and -code2- on a 6MHZ calc. This would allow for using different versions of code to allow for speed differences.
Title: Re: Features Wishlist
Post by: Quigibo on March 02, 2010, 05:26:33 pm
I think the above way you just wrote is better.  Having a different program for each type of calculator is more annoying in my opinion than a single, insignificantly larger program that works for every calculator.  I might add a command that returns the exact type of calculator and operating system version, not just 15MHz support.
Title: Re: Features Wishlist
Post by: ztrumpet on March 02, 2010, 06:32:22 pm
I think the above way you just wrote is better.  Having a different program for each type of calculator is more annoying in my opinion than a single, insignificantly larger program that works for every calculator.  I might add a command that returns the exact type of calculator and operating system version, not just 15MHz support.
Cool.  I think there should be compiler directives.  Maybe something like a "CIf" statement:
CIf OS=2.53
code here compiled if OS=2.53
Else
other code here compiled if OS!=2.53
End

Would this work?
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 06:39:37 pm
That's kind of what I had in mind. We could use .If .Else .End and such fir that. How about also adding variables that the compiler uses? Like .VER would return te version of the device that it was compiled on? That would make some more nice little modifications to code possible. Also a Date one would work too so it would tell you what date it was compiled on (of course that would be 15MHZ only). 
Title: Re: Features Wishlist
Post by: Builderboy on March 02, 2010, 07:16:31 pm
Could there be a command to swap the buffers instead of just copying them?  That way one wouldnt have to be destroyed in the process.
Title: Re: Features Wishlist
Post by: Eeems on March 02, 2010, 07:20:04 pm
I was also wondering if you could add a third back-buffer, or have a buffer in the program (so like have a blank splash screen in the program that we can edit/read :D, although you would have to put checks in place so we don't accidentally corrupt the program with overflow from it)
Title: Re: Features Wishlist
Post by: calc84maniac on March 02, 2010, 08:12:48 pm
Hmm yeah, maybe instead of having plotSScreen always be the draw area, add a command to set a different buffer to draw to. You would only need to change immediate loads of plotSScreen to loads from a variable in memory. Heck, maybe you could use Theta for this purpose, and have it be accessible like a normal variable.
Title: Re: Features Wishlist
Post by: Builderboy on March 02, 2010, 10:11:40 pm
That would be very useful as well.  This made me thinking, since the LCD isn't memory mapped (right? D:) swapping buffers would be as simple as changing a pointer in the safeCopy routine right?  Or do I not know what I am talking about? ;D
Title: Re: Features Wishlist
Post by: calc84maniac on March 02, 2010, 10:26:17 pm
That would be very useful as well.  This made me thinking, since the LCD isn't memory mapped (right? D:) swapping buffers would be as simple as changing a pointer in the safeCopy routine right?  Or do I not know what I am talking about? ;D
You are quite correct. And it should only be 6 extra clock cycles per call when using a variable instead of a constant, which is not enough to make a difference.
Title: Re: Features Wishlist
Post by: Quigibo on March 03, 2010, 01:55:38 pm
That's actually a really good idea to use some variables as variable pointers that are looked up by some routines.  Maybe I will use the "u" "v" "w" variables for this since I'll probably need more than 1 of them.  The only problem with this is that the variables have to be initialized before the program starts.  Otherwise, it will just be something random.  The parser could do it automatically, but then its just adding extra bytes in case you decide to change it again to anything but the default.  It would be really annoying to start every program with L6->u to do any drawing and it might not make sense for beginners.

I could always make the variable location part of the self modifying code so it already starts initialized without using extra memory, but then that means it can never compile as an app.  Although I'm still not sure how feasible it is to compile apps on-calc.  Have other programmers been able to do it?

All those precompile headers use variables that have to be set somewhere.  That means I would also need preprossesor variables which would be very difficult to add and I'm already running out of memory.  There is no reason that the same program should compile differently on different calculators since only the executable would be distributed ideally.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 03, 2010, 02:33:44 pm
Well, I've never seen anyone make apps on-calc. That could be tricky...
Try asking Brandon, he's an expert in Flash unlocking.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 03, 2010, 02:57:48 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
Title: Re: Features Wishlist
Post by: ztrumpet on March 03, 2010, 08:43:00 pm
I like the Safe_Copy Pointer idea.  :)
Great idea!

Could you automatically initialize the pointer to the most common value of it, as it would be only be a little bigger and less prone to crashes?
Title: Re: Features Wishlist
Post by: Quigibo on March 03, 2010, 10:26:48 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 03, 2010, 10:37:43 pm
I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?
That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.
Fair enough. Do what you can, and I will gladly wait :)
Title: Re: Features Wishlist
Post by: Raylin on March 04, 2010, 02:32:54 pm
I second the on-calc APP compiling feature.
It is full of win.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2010, 04:13:33 pm
would it be even possible at all, though? I don't even think BrandonW did it and he's like nearly the best assembly programmer out there. It has something to do with app signing I think. Even signing apps on a computer is a major hassle sometimes. Remember the trouble Iambian had with bad signatures, preventing many people from sending Celtic III to their calc
Title: Re: Features Wishlist
Post by: Quigibo on March 04, 2010, 04:39:01 pm
Well, I'll wait on that then.

Anyway, I need to propose some safety features and I'd like some feedback.  Here is the idea.  If you select a "safety mode" in the options, the following will occur: All data in ram is archived and an application variable is created to keep track of what it archived (The appvar is also archived).  A dummy variable is also created and is kept in RAM.  Next, after the program is compiled, it is executed within axe parser itself rather than coming back to the home screen.  Once the program finishes, the ram is automatically cleared on the calculator so any corrupted data gets restored to the default.  Next, the appvar gets unarchived and unarchives the variables on its list.  So when the program quits, everything is back to normal.

Now, if the program crashed, and you need to pull the batteries, then the dummy variable gets deleted.  That means that the next time you run axe, it will notify you that you have recovered from a crash and automatically unarchive the programs from the save list to return the calculator back to normal.

This seems like the perfect system to prevent crashes, but its a little too perfect.  What I mean, is that if you start getting used to this, then if it corrupts the memory when safe mode is off, it will be very hard to find where the error is since the error would never be detectable in safety mode.

You might ask "Isn't it possible for axe to automatically detect when memory is corrupted?"  but the problem is that I would need a copy of the entire original RAM to compare it before and after the program is run and that really isn't going to be possible.  And even if it were possible, many assembly programmers often intentionally change non-safe areas of RAM to set flags, alter external variables, run self modifying code, etc.

I'm still going to add this mode anyway, but does anyone else have any other ideas about how to improve safety?
Title: Re: Features Wishlist
Post by: ztrumpet on March 04, 2010, 05:22:26 pm
It sounds really good!

The only idea I have requires hooks, and it's not even that good of an idea.  :)
Wait, never mind:  You're RAM is cleared; There are no hooks... :D
Title: Re: Features Wishlist
Post by: Raylin on March 04, 2010, 07:13:32 pm
I like the safety mode idea.

OMG.
I can has DEBUG mode!? :D

It would be nice if you could edit programs inside of Axe Parser instead of jumping back to Home and reprogramming and recompiling...
Title: Re: Features Wishlist
Post by: Eeems on March 04, 2010, 07:39:39 pm
well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...
Title: Re: Features Wishlist
Post by: calc84maniac on March 04, 2010, 07:47:15 pm
well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...
Actually, I'd think debugging would be pretty darn hard to pull off. Unless, of course, you might be able to build executables that allow debugging, but have larger code size?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2010, 10:06:25 pm
for safety mode, I hope the plan is gonna be to allow people to compile in unsafe mode, though. I personally would like to provide a version of my stuff that has no error checks so it runs faster. I wouldn't mind slower speed for debugging, though.
Title: Re: Features Wishlist
Post by: Silver Shadow on March 05, 2010, 01:48:12 am
How about a sandbox mode where your RAM will be backed up, but won't be cleared after you run the prog, so that if it corrupts the memory, the user will notice it?
Title: Re: Features Wishlist
Post by: Quigibo on March 05, 2010, 11:25:31 am
Yeah that's essentially what I'm doing.  I have saftey mode, sandbox mode, and normal mode.

"Sandbox" is actually what I called safety before.

"Saftey" now means that all ram is archived, but ram is not cleared.  Programs remain archived after execution and it returns to the homescreen (so you will notice glitches but everything is still archived).  You'll have to manually unarchive everything you want to put back in RAM yourself (not recommended until a ram clear is performed).

"Normal" is obviously what has been done to date.
Title: Re: Features Wishlist
Post by: Galandros on March 05, 2010, 02:08:34 pm
Could you had any arbitrary way to time things? It doesn't need to accurately time seconds or miliseconds.
Just accurate enough to know if it is faster. (even if you need loops)
Title: Re: Features Wishlist
Post by: Quigibo on March 05, 2010, 02:32:15 pm
You can do that with interrupts, but I haven't implemented that yet.  And even with interrupts, a few routines like "DispGraph" disable interrupts for the duration of the command during execution.

In the mean time, you can run the codes you want to test in big for loops so they take a measurable amount of time; maybe enough looping to last 5-10 seconds.  That way if there is any difference, you can actually measure it with a stopwatch or clock.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 05, 2010, 02:38:42 pm
Yeah that's generally what I do with TI-BASIC. I move my character around, for example, or scroll down an entire menu, stop the chronometer, then retry with modified code, then compare. Not too accurate but still does the job.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 08, 2010, 02:06:02 pm
Question:

Do you think you will add the following in the future?

1) SMC or saving to external var/appvar/prog - useful for saving highscores and game progress

2) Letting us choose whatever name we want for the compiled program instead of just "LOL".
Title: Re: Features Wishlist
Post by: ztrumpet on March 08, 2010, 03:51:25 pm
He is planning both of these things.  I'm pretty sure this first will somehow be accomplished with the GetCalc( command. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 08, 2010, 11:14:47 pm
Yeah I was more curious about if it was coming in the few next releases, though, or if it was more near the end.

If it is near the end, I will probably just rely on password systems for saving (like Metroid for the NES and Demon Crest for the SNES), altough that might be a bit hard to make in a way that it's hard to crack
Title: Re: Features Wishlist
Post by: Quigibo on March 09, 2010, 11:56:32 am
VAT manipulation will come when I finish the user interface and safety stuff so I'd say in the middle, not the end.

Program naming I'm working on right now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 09, 2010, 02:19:25 pm
Sounds cool ^^

I assume the safety stuff is the option to compile a program with the developer mode with more error checks during execution, right?
Title: Re: Features Wishlist
Post by: calc84maniac on March 10, 2010, 10:15:08 pm
Another good feature would be a Fill( function, to quickly fill memory with a value. This could be especially useful in graphics where this must be done every frame, like if you want to clear part of the screen (such as after a Vertical command)
Title: Re: Features Wishlist
Post by: Builderboy on March 10, 2010, 10:26:09 pm
Couldn't you easily write that yourself though?  

PS: Yay on the update ^^
Title: Re: Features Wishlist
Post by: calc84maniac on March 10, 2010, 10:31:00 pm
Couldn't you easily write that yourself though? 

PS: Yay on the update ^^
Yes, but it would be way slower and more bloated. It would translate much more easily to a few ASM opcodes.
Title: Re: Features Wishlist
Post by: Eeems on March 11, 2010, 12:00:29 am
Fill() would be nice, and line() soon as well. If only you had uploaded sooner today when I could have sent it to my calc x.x now I'm stuck with the slow version for who knows how long x.x
Title: Re: Features Wishlist
Post by: Builderboy on March 11, 2010, 12:07:49 am
Yes, but it would be way slower and more bloated. It would translate much more easily to a few ASM opcodes.
As i see.  Well in that case get right on it Quigibo! :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 01:46:17 am
I fail at understanding the concept of fill x.x

Do you mean like in Paint when filling an area with a color or just like a rectangle routine?

rectangle routines would be cool
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 08:46:54 am
I fail at understanding the concept of fill x.x

Do you mean like in Paint when filling an area with a color or just like a rectangle routine?

rectangle routines would be cool
I mean like a pure data fill, which would work a lot like the TI-Basic version (except with any data area and any length)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 01:35:46 pm
Aaah ok, so like lists?
Title: Re: Features Wishlist
Post by: Quigibo on March 11, 2010, 03:41:33 pm
That's actually really freaky that you mentioned Fill() because I just so happened to have written that command last night  :o

I have working now the Fill() command to fill up data blocks with a particular byte, plus a copy command to copy a number of bytes from a source to a destination and an exchange command to exchange bytes between two ram locations.  The closest thing I could find to copy() was conj() and exchange is expr().  You'll see those in the next version, it should make data manipulation a lot easier, faster, and smaller, but still not as much as when I get arrays working.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 04:25:33 pm
I'm just gonna throw in my requests:
*Full picture drawing
*Access to user variables (programs and appdata)
*Port access
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 04:34:38 pm
*Port access
That can be done with inline ASM. Most people who would know how (or even need) to use ports will probably know ASM.
Title: Re: Features Wishlist
Post by: Builderboy on March 11, 2010, 05:25:13 pm
What would you want with Port access anyway? O.o Maybe linking?  But that i think is going to be supported in (much) later versions so i don't know.
Title: Re: Features Wishlist
Post by: ztrumpet on March 11, 2010, 06:54:57 pm
I like the conj(, expr(, and Fill( commands!  I know I'll end up using them. ;D

Yay, 0.1.1! ;)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 07:19:43 pm
Linking is something that you should be able to use in-line asm for, I agree.

Oh, and interrupts.  You should be able to stick one of your subroutines onto the interrupt.
Title: Re: Features Wishlist
Post by: Raylin on March 11, 2010, 07:37:35 pm
Did someone cover 'being able to use hexadecimal in normal calculations' using >Rect or something...?
Title: Re: Features Wishlist
Post by: calc84maniac on March 11, 2010, 07:42:59 pm
Did someone cover 'being able to use hexadecimal in normal calculations' using >Rect or something...?
I would really, really like being able to use hex.
Title: Re: Features Wishlist
Post by: Eeems on March 11, 2010, 07:45:55 pm
I would like that too...I would also like a way to store large amounts of data to pointers in none hex, so like a list would.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 11, 2010, 07:46:21 pm
I think I may have figured out a way to draw a whole picture to the screen, and that's just something like this:

'Code goes here to move PC into L6
DispGraph
Lbl PC
[000AFF...] 'Pic data
Title: Re: Features Wishlist
Post by: Quigibo on March 11, 2010, 08:01:57 pm
One way to do that is conj(Pic1,L6,768) in the next version if Pic1 contains the hex code of the picture.  I'm still not 100% sure how regular picture support will work in the future though.

All of the other commands suggested so far I plan to add eventually.  School forces me to work slow.  Syntax changes take the longest to add while new commands take less than an hour usually.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 11, 2010, 11:44:06 pm
That's actually really freaky that you mentioned Fill() because I just so happened to have written that command last night  :o

I have working now the Fill() command to fill up data blocks with a particular byte, plus a copy command to copy a number of bytes from a source to a destination and an exchange command to exchange bytes between two ram locations.  The closest thing I could find to copy() was conj() and exchange is expr().  You'll see those in the next version, it should make data manipulation a lot easier, faster, and smaller, but still not as much as when I get arrays working.
Maybe he lives very close to you and is stalking you in secret? :O

Also make sure to not have too much syntax changes in case it would break old Axe programs. So far, every example I tried seemed to work fine in latest versions, though.

As for entire pics, it would be cool to have that as feature, altough for now, since each sprite just takes 8 byte, I would tolerate using 96 sprites to display a pic, for example, plus then, if my pic is not even full screen (a logo, for example) I don,t need to use that many sprites.
Title: Re: Features Wishlist
Post by: Builderboy on March 12, 2010, 12:18:37 am
These new commands sounds great!  Could allow for some really nice effects and animations <(^.^<)

Mmmm out of curiosity are you planning String manipulation soon?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 01:24:31 am
Someone will have to show me examples using them in action once they are avaliable, because I am sorry but I seriously don't get it, even after explanation x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 09:35:47 pm
Suggestion:

-The ability to store directly to the back buffer, without having to go through storing the lcd to buffer first. It migth be very useful if we want to store to the back buffer but not want to lose our main buffer content
Title: Re: Features Wishlist
Post by: calc84maniac on March 12, 2010, 10:03:55 pm
Another neat feature would be one that draws the main buffer to the LCD and simultaneously copies the back buffer to the main buffer. So basically, Dispgraph and Recallpic at the same time. It would be a great way to use the wasted time waiting for the LCD.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 12, 2010, 10:10:52 pm
I just remembered one more:

The ability to display the graph buffer using different logics other than OVERWRITE, like XOR.

Imagine, for example, you have a game with scrolling, but want to display a HUD. Everytime you scroll, you are forced to redraw the entire HUD, because it scrolls as well. In xLIB xLIB Revolution, the HUD is XORed right before scrolling, then XOR'ed again after scrolling (and other stuff) is done.
Title: Re: Features Wishlist
Post by: ztrumpet on March 12, 2010, 10:36:21 pm
I also think we need the And, Or, Xor, and Over-write commands when dealing with pictures. :)
Title: Re: Features Wishlist
Post by: trevmeister66 on March 12, 2010, 10:38:37 pm
I also think we need the And, Or, Xor, and Over-write commands when dealing with pictures. :)
+1

I do believe he will add that in eventually though.
Title: Re: Features Wishlist
Post by: Radical Pi on March 12, 2010, 10:39:04 pm
I second the last five posts :)
Title: Re: Features Wishlist
Post by: _player1537 on March 13, 2010, 02:26:41 am
I second the last 6 posts :P
Title: Re: Features Wishlist
Post by: Raylin on March 13, 2010, 09:15:38 am
[xLib TextMode Commands]
Inverted Text and the like.

[GRAYSCALE!]
Reiteration of what has already been said.

[Omnicalc Custom Font Support]
Think about it! :D :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 13, 2010, 11:04:06 am
I doN't think he is planning to add features involving support of external ASM lib for BASIC programmers such as Omnicalc, xLIB, Symbolic and Celtic, though, meaning most likely no Omnicalc fonts. Plus since text is much slower in ASM than graphics, partially due to TI's slow txt routines, it would nearly defeat the point of using Axe. Maybe a custom font routine reading from Omnicalc font files could be done, though, using a custom sprite routine.
Title: Re: Features Wishlist
Post by: Galandros on March 14, 2010, 10:47:56 am
Being away brings fresh new ideas!

If you have indirection support why not ports access? This can mean sound, linking, etc.. Just be careful to not mess with protected ports. See WikiTI for details on protected ports.
Title: Re: Features Wishlist
Post by: ztrumpet on March 14, 2010, 11:32:11 am
A ToneOut(length,frequency) command sounds awesome! :D
Title: Re: Features Wishlist
Post by: Raylin on March 14, 2010, 11:40:34 am
I CAN HAS EASTER EGGS? :P
Title: Re: Features Wishlist
Post by: Silver Shadow on March 14, 2010, 01:21:14 pm
Ion header support, maybe?
Title: Re: Features Wishlist
Post by: Radical Pi on March 14, 2010, 02:31:34 pm
I CAN HAS EASTER EGGS? :P
How exactly could easter eggs work for something like this? Pressing some random key sequence in the app lets you play a game of Tetris?
Title: Re: Features Wishlist
Post by: _player1537 on March 14, 2010, 02:41:29 pm
I CAN HAS EASTER EGGS? :P
How exactly could easter eggs work for something like this? Pressing some random key sequence in the app lets you play a game of Tetris?

I like that idea  :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 05:57:39 pm
i dont think space should be wasted by unnecessary features. It would suck if when finished this app became 4 pages large instead of maybe 3 just because an easter egg was added

Also I think he's planning Ion/Mirage support in later versions. I would prefer Mirage, though, because with Ion you are limited in terms of RAM. Remember when installing it you lose like 2 KB of RAM, which doesn't happen in MirageOs
Title: Re: Features Wishlist
Post by: Raylin on March 14, 2010, 06:47:15 pm
So...

Rotate(PIC, angle, velocity, direction).
Title: Re: Features Wishlist
Post by: Quigibo on March 14, 2010, 06:53:42 pm
I am definitely adding 90 degree sprite rotation as well as horizontal and vertical flipping.  I'm still looking for some intuitive commands for this though.  To use it, you will want to copy a sprite to free ram and then flip it and draw it from there, otherwise, you might loose track of what direction it has been flipped so far.
Title: Re: Features Wishlist
Post by: ztrumpet on March 14, 2010, 08:26:29 pm
Also I think he's planning Ion/Mirage support in later versions. I would prefer Mirage, though, because with Ion you are limited in terms of RAM. Remember when installing it you lose like 2 KB of RAM, which doesn't happen in MirageOs
Since Mirage shows Ion programs, you can use a ion header to make programs show up in both Mirage and Ion. :)


Can we have a backbuffer to screen command?  Please? ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 08:28:39 pm
Can Ion programs run fine in Mirage if Ion is not installed? If so, I guess that could work, too, altough I think I recall certain Ion programs crashed in MirageOs or vice-versa x.x
Title: Re: Features Wishlist
Post by: trevmeister66 on March 14, 2010, 08:33:47 pm
Can Ion programs run fine in Mirage if Ion is not installed? If so, I guess that could work, too, altough I think I recall certain Ion programs crashed in MirageOs or vice-versa x.x
Yeah, from what I've seen, they work fine in Mirage. I personally haven't ran across any Ion games crashing, but I'm sure it's possible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 14, 2010, 09:00:13 pm
The Core Of Light is one

Also there are Ion games that will crash in Ion and works fine in Mirage, for some reasons. Final Fantasy v1.198 is one. ARPGCS also tend to crash a lot in Ion, especially any Ion version other than 1.4.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 15, 2010, 11:34:10 pm
Not really a feature suggestion, but I would suggest maybe not make upcoming commands too hard to understand. I mean, I noticed as the project advances, most stuff in your posts are explained in a lower and lower level way that practically requires us to learn ASM to understand how it works. It might be good to provide both very well explained documentation of these new commands (in particular, the ones added in v0.1.2), and not just in text, but also maybe examples with screenshots or 8xp files, even if they are not games and just useless programs, and maybe also explain the commands in TI-BASIC equivalent. And not change too much of the syntax for the old essential commands. I kinda like how Axe currently barely requires modification over pure BASIC programs to be compiled

EDIT:

Feature suggestion:

Switch back to old List(Element) syntax instead of the new {} thing, like L1(2)
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 01:11:08 am
I second the new List handling, as it could make the source a lot more readable, like Basic.  Although I understand that it is still in development and things like readability are in the works right now as features are being added :)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 08:21:34 am
I just had an idea:
For saving and loading games and such, you should try program write-back.  Make it so that you can add a token in your code, and it will enable write-back, saving your labels.
Title: Re: Features Wishlist
Post by: Quigibo on March 16, 2010, 11:19:13 am
I cannot use the BASIC format for list handling.  L1(X) is ambiguous in BASIC since you can't tell if you are multiplying by X or finding the Xth element.  This always bugged me.  Similarly, in Axe, it can't tell if you are starting a new expression or finding the element of a list.

Don't forget, axe interprets a command written like this:

:Disp {A*2+L1}

As this:


:A
:*2
:+L1
:{}
:Disp


Both of these compile exactly the same way byte for byte in the executable.  So you can see why the parenthesis notation would be too ambiguous.

But YES, I am definitely going to add a byte data structure so you can define values in base 10 integers instead of just hex and strings.  It will be the same syntax as BASIC lists, but I think I will need to use something other than the curly brackets.
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 12:38:27 pm
Mmmm thats an interesting insight to the way Axe parser works.  It makes more sense now that you have given those examples :).  It will be nice when we get list addition like normal though :P I think it would work very well, although i am at a loss as to what to put for the replacement of brackets :/
Title: Re: Features Wishlist
Post by: Quigibo on March 16, 2010, 12:44:59 pm
I'm thinking maybe ΔList() right now unless I find something better.
Title: Re: Features Wishlist
Post by: Builderboy on March 16, 2010, 12:51:08 pm
Yeah that sounds good.  Thats one thing thats a bit bothersome, finding good tokens for functions that don't exist on the calculator :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 16, 2010, 02:04:11 pm
mhmm I see now why, I guess we might haev to leave things as they are now. However, I would really like to not have to store my list stuff in hex, because it can be annoying to modify the data or to convert it in the first place.

And I understand about trying to find tokens for non-existing TI-BASIC functions x.x. Multi-Platform Language for Calculators team in 2004-05 got around this by having commands typed in the BASIC editor using individual ALPHA letters, for example, like this:

Quote
#CLRS            - Clears the screen
#TEXT <x> <y> <text> <color>      - Displays text
#LINE <x> <y> <x> <y> <color>   - Draws a line
#PIXL <x> <y> <color>      - Draws a pixel
#PIXT <x> <y> <var>         - Stores in <var> the color at (x,y)
#DRAW            - Updates screen
#SHFT <x> <y> <type>         - Used for scrolling, <type> specifies looping state (-1 = Loop, 1-3 standard colors)
#STOP            - abbr. for Store Picture (saves all color layers)
#RCLP            - abbr. for Recall Picture, shows the last pict saved with #STOP
#RECT <x1> <y1> <x2> <y2> <border> <fill> - Draws a rectangle in either a filled un unfilled state (.5 for no fill)
#DBMP <name> <x> <y>         - Displays a bitmap a (x,y)
#DISP <name>            - Displays a sprite at its stored position

That's quoted from MLC readme for the Casio AFX version (the code was the exact same syntax accross the TI-86, 68K, Casio AFX and 9860G calculators, and was gonna be the same on teh 83+Silver too). But as you can see, EVERY MLC command took 5 bytes! This is why I kinda prefer tokens to type commands, not to mention they're easy to access in prgm menu and CATALOG. Most tokens take one byte, others, two.

I also recall MLC for both the 83+ and the 86 being plaggued with the 8.8 (or was it 8.1?) KB code execution limit thing.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 04:46:32 pm
I made a little program that will convert the graph screen into hex so you can paste it into Axe source.  Thought it might be useful.  What you need to do is run the program with your picture on the graph screen, wait about 5 or 6 minutes, and when it is done it will paste the hex into Ans.
Title: Re: Features Wishlist
Post by: ztrumpet on March 16, 2010, 05:03:51 pm
Looks nice Sircmpwn. :)

Personally, I like lists as they are.  I think once you figure them out, they will be no trouble, and they're vary nice as is.  I'd rather have better access to the hardware with {X*3+8+L1} than L1(X*3+7).  (Remember these are my views, and no one's views are wrong because of them. :) )
Title: Re: Features Wishlist
Post by: SirCmpwn on March 16, 2010, 05:10:51 pm
Looks nice Sircmpwn. :)

Personally, I like lists as they are.  I think once you figure them out, they will be no trouble, and they're vary nice as is.  I'd rather have better access to the hardware with {X*3+8+L1} than L1(X*3+7).  (Remember these are my views, and no one's views are wrong because of them. :) )

A) Thank you
B) Agreed, it should stay that way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 16, 2010, 11:06:44 pm
Nice program,. it might be useful for those who dont want to use the computer (BMP to z80 for instance) to convert pics.

@ztrumpet, yeah I guess it might be better this way, as long as we don't have to define lists with hex data. I would rather be able to define them like in basic or close. Having to convert everything to hex before storing it to list would suck imho x.x
Title: Re: Features Wishlist
Post by: calc84maniac on March 16, 2010, 11:55:36 pm
I think getKey(0) should tell whether any keys at all are pressed. Here is an example of how you could do it (feel free to write your own though):
xor a
out (1),a
ld h,a
ld l,a
in a,(1)
inc a
ret nz
inc l
ret


Edit: I modified it so the output would make more sense considering how the rest of the getKey() operations work. Now it returns 1 if no keys are pressed, 0 if keys are pressed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:46:15 am
That reminds me, how many keypresses at once can we use in an Axe game? I noticed some games detects like 3 at once, like the shooter example. I could move diagonally and shoot at the sane time. In BASIC only one is possible at once and in xLIB two (only arrows, others = 1 keypress) and Celtic III a bit more than arrows
Title: Re: Features Wishlist
Post by: calc84maniac on March 17, 2010, 07:36:46 am
That reminds me, how many keypresses at once can we use in an Axe game? I noticed some games detects like 3 at once, like the shooter example. I could move diagonally and shoot at the sane time. In BASIC only one is possible at once and in xLIB two (only arrows, others = 1 keypress) and Celtic III a bit more than arrows
The limit is the same as in ASM, which is the limit of the keyboard itself. Just remember that if you press 3 keys that are the corners of a rectangle, the 4th corner of the rectangle will be detected pressed as well.
Title: Re: Features Wishlist
Post by: Quigibo on March 17, 2010, 01:36:06 pm
I'm almost positive that you can detect as many keys at one as you need.  I don't think there are actually any limits by the nature of the commands.

What is the effect of this though?
xor a
out (1),a
I've never seen this used.  I thought it only works when a in binary is a combination of all ones and a single zero.

getkey(0) is a good idea, but isn't getkey=/=0 basically the same thing?  I was actually planning on making getkey(0) detect the [on] button.

EDIT: wait nevermind, you were requesting an indefinite return.  Regular getkey only is true once and then gets reset back to zero.  I'll have to add that command.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:42:45 pm
Mhmm interesting

Also can both getkey commands detect multiple keypresses? And when multiple ones are pressed, what does one getkey command returns as number?
Title: Re: Features Wishlist
Post by: Quigibo on March 17, 2010, 01:49:35 pm
No, "getkey" tells you the last key pressed once and then gets reset back to zero.  Its essentially identical to the basic getkey but with different numbers.

"getkey(KEY)" tells you if that particular key is held down right now.  So you can chain these together like "getkey(1) and getkey(2)" notice I don't need the parenthesis on the and operation since they're boolean.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 17, 2010, 01:52:05 pm
ooh ok I thought one single getkey command checked for all keypresses. In BASIC, if you do

If getkey=25
A-1->A
If getkey=24
B-1->B

good luck moving diagonally.

At least that's a good plus that Axe allows multiple keypresses ^^
Title: Re: Features Wishlist
Post by: ztrumpet on March 17, 2010, 04:34:52 pm
I was actually planning on making getkey(0) detect the [on] button.
Could you make the On button have a number?  That would be useful at times! :D
I don't know what number to use, but there are plenty to choose from. ;D
Title: Re: Features Wishlist
Post by: calc84maniac on March 17, 2010, 09:38:49 pm
I'm almost positive that you can detect as many keys at one as you need.  I don't think there are actually any limits by the nature of the commands.

What is the effect of this though?
xor a
out (1),a
I've never seen this used.  I thought it only works when a in binary is a combination of all ones and a single zero.

getkey(0) is a good idea, but isn't getkey=/=0 basically the same thing?  I was actually planning on making getkey(0) detect the [on] button.

EDIT: wait nevermind, you were requesting an indefinite return.  Regular getkey only is true once and then gets reset back to zero.  I'll have to add that command.
If you set more than one bit to 0, you can select more than one key group. All the pressed keys in the groups are ANDed together. Thus, you can test for the "any key" quite easily this way.
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 11:43:01 am
Mmmm i think i'd like support to compile the program with ON breaking enabled for debugging (since you said it takes up a +300 bytes to handle the interrupts) but it would be a huge plus for those not working with interrupts and not wanting to deal with them, especially for those who don't understand them.  It can be a huge lifesaver during debugging though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 01:39:04 pm
personally I like the idea of letting the user choose when compiling. Example:

Choose if you want ON to be enabled
CHoose if you want error checking ON
Choose for what shell to compile for
Choose to store the compiled program in RAM or Archive

I don't know if I forgot any

EDIT:

The ability to draw the back-buffer directly to the LCD
The ability to store the LCD content straight to the back-buffer
Title: Re: Features Wishlist
Post by: SirCmpwn on March 21, 2010, 07:15:48 pm
The ability to draw the back-buffer directly to the LCD
The ability to store the LCD content straight to the back-buffer

A) conj(L3, L6, 768) \ DispGraph      ; Backbuffer to LCD
B) conj(L6, L3, 768)                      ; LCD to backbuffer
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 07:24:27 pm
You would probably have to change them to this to preserve the actual LCD buffer.

A) expr(L3,L6,768):DispGraph:expr(L3,L6,768)

And do this, since he was asking to store from the LCD, not the buffer.

B) expr(L3,L6,768):StoreGDB:expr(L3,L6,768)

However, it could be nice to have some built in commands for this.  Perhaps StoreGDB # with different numbers meaning different  buffers?
Title: Re: Features Wishlist
Post by: ACagliano on March 21, 2010, 07:33:58 pm
I tend to prefer the TI Basic way of calling lists, though I believe it was said that that is not possible. And, my request is for various linking commands. One set of send/receive that waits for a response or times out, and a single send command that just fires away, but doesn't wait for a response (if this is possible).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 09:30:20 pm
You would probably have to change them to this to preserve the actual LCD buffer.

A) expr(L3,L6,768):DispGraph:expr(L3,L6,768)

And do this, since he was asking to store from the LCD, not the buffer.

B) expr(L3,L6,768):StoreGDB:expr(L3,L6,768)

However, it could be nice to have some built in commands for this.  Perhaps StoreGDB # with different numbers meaning different  buffers?
Is it still safe, though? I guess it might be since:

Quote
L3 = 768 bytes (appBackUpScreen) Volatility: MED (Saving to back-buffer will corrupt)
L6 = 768 bytes (plotSScreen) Volatility: HIGH (Any buffer drawing will corrupt)

But I want to make sure that before using your suggestion (or SirCmpwn's), I won't run in any further problems, later, doing some stuff with these pointers
Title: Re: Features Wishlist
Post by: _player1537 on March 21, 2010, 09:58:28 pm
on the next version, I think it would be helpful if the compiler told you what line was wrong, it wouldn't have to let you fix it right there just to tell what the line is.  Just my 2 cents  (great job so far :P)
Title: Re: Features Wishlist
Post by: Builderboy on March 21, 2010, 11:23:57 pm
But I want to make sure that before using your suggestion (or SirCmpwn's), I won't run in any further problems, later, doing some stuff with these pointers

Well since L3 and L6 are the backbuffer and the main buffer, i should think so, but you'd have to check with Quigibo o.O Using built in routines would indeed be safer :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 21, 2010, 11:43:13 pm
Yeah I guessed it might be safe, since they're buffer-related. I was just a lil bit unsure. I try to not take too many chances sometimes you know XD (you know what happened to Illusiat 2002)
Title: Re: Features Wishlist
Post by: Eeems on March 22, 2010, 12:38:10 am
I would really like some sort of fps counter or something, so you can see how your code handles differing amounts of objects and such.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 12:42:36 am
wouldn't that be 84+-only, tho? (clock)
Title: Re: Features Wishlist
Post by: Eeems on March 22, 2010, 01:22:49 am
True, though if there was some way to do that on 83+'s that would be nice, even an approximation.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 12:22:12 pm
Yeah, sure.
But is it true that there is no way to get vars from the calc like the Pic1-Pic0 vars and the real variables?
If (that's true), I would like to have the function GetCalc([var name]) manage that.
Else I would like to have an example for how to do it.

I also would like the ability to use ElseIf:

If EXP1
[code1]
ElseIf EXP2
[code2]
Else
[codeX]
End
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 12:26:42 pm
I also would like the ability to use ElseIf:

++ ElseIf
Also, speaking of ++, I would like to see ++ and -- implemented, and possibly +=, -=, *=, /=.

I've been meaning to write another routine for accessing user variables.  I'll post it when I get around to it.
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 01:52:01 pm
The ++ and -- are already supported.  You just write them as +1 and -1.  The compiler automatically optimizes them to the increment.  ElseIf is a possibility, I forgot about that.  A FPS counter is something you could do with interrupts.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 01:55:31 pm
The ++ and -- are already supported.  You just write them as +1 and -1.  The compiler automatically optimizes them to the increment.  ElseIf is a possibility, I forgot about that.  A FPS counter is something you could do with interrupts.

Okay on the +1 and -1, thanks.  Also, FPS requires you to know when a second (the S in FPS) has passed.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 01:57:07 pm
I also would like the ability to use ElseIf:

++ ElseIf
Also, speaking of ++, I would like to see ++ and -- implemented, and possibly +=, -=, *=, /=.

I've been meaning to write another routine for accessing user variables.  I'll post it when I get around to it.

OK, Nice!

*LC hopes to hear from you soon*
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 02:11:27 pm
Hi and welcome here ^^

A routine to access users variables (or even appvars) would be cool, altough I assume this feature will be built-in Axe pretty soon.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 02:32:54 pm
Hi and welcome here ^^
Thanks!
I would like to know why you assume that "the feature will be built-in Axe pretty soon."
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 02:46:19 pm
I think I mentioned I was was going to add it in a few threads before.  It will probably be in the next version.  I'm not sure how much of the calc will be accessible in that release, but we'll see what happens. :)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 22, 2010, 02:55:59 pm
For which reasons do you assume that? Well, of course i hope so too, but it's always nice to have a ground for (some || every)thing
A) DJ Omnimaga is an admin
B) You have 3 posts.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 05:57:11 pm
yes, I'am sorry, I've chosen the wrong words. :-[
I just only meant to say that I would like to know why he assumes that "the feature will be built-in Axe pretty soon."
I think I mentioned I was was going to add it in a few threads before.
I'm also very sorry I haven't read the entire topic before posting this question, but it seemed to me to take lots of time to do that :) (yes I'm a little lazy ;D)

I've another question: is the command Input going to do the same thing as in BASIC, or will there be an other layout, or perhaps the possibility to draw the input-text in small font?
Title: Re: Features Wishlist
Post by: Quigibo on March 22, 2010, 06:08:42 pm
Numerical and character input might be a possibility in the far future, but I doubt it will be anything like basic.  However, it may be possible to embed actual BASIC code into axe itself, kind of like how you can embed assembly.  Not sure if it will work, but I'm reading up on it.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 22, 2010, 06:34:04 pm
OK, right now I'm coding an input (with Axe), and I am going to use that code as a subroutine in my other programs, but I need to read some user variables to read the settings for the input. But right now I will do just the basic coding, and later on the more user-friendly usable thing.

I think BASIC in Axe is not a very bad idea, but isn't it too difficult to implement?
Perhaps it could be just executing a BASIC program.
Title: Re: Features Wishlist
Post by: _player1537 on March 22, 2010, 07:03:58 pm
I've written one if you don't feel like writing it, or if you feel like optimizing.  Just thought I'd point out (sorry if it sounded rude at all) http://ourl.ca/4129/80803 (http://ourl.ca/4129/80803)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 22, 2010, 10:51:32 pm
yes, I'am sorry, I've chosen the wrong words. :-[
I just only meant to say that I would like to know why he assumes that "the feature will be built-in Axe pretty soon."
I think I mentioned I was was going to add it in a few threads before.
I'm also very sorry I haven't read the entire topic before posting this question, but it seemed to me to take lots of time to do that :) (yes I'm a little lazy ;D)

I've another question: is the command Input going to do the same thing as in BASIC, or will there be an other layout, or perhaps the possibility to draw the input-text in small font?
i said that since I effectively seen Quigibo posts saying it will be eventually done. Also, in some occasions, I chat with him real time, altough not as frequently as I used to (since nowadays I am generally only on IRC), so I can discover some more progress.

Also I think so far he is doing a good job at Axe. The goal is to make a language that is similar to TI-BASIC but not necessarly 100% similar and mostly game-oriented. It might be difficult to implement everything but at the rate this is progressing, I am confident he'll succeed in implementing a lot more.

That said let's try to remain polite and respectful towards other people, though. That goes for both regular users and new people, but in case of new people, if they are rude or overly negative on their first few forum posts and did not even contribute anything else in the TI community so far, it is easier for their image to be tarnished.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 02:48:02 am
Also I think so far he is doing a good job at Axe. The goal is to make a language that is similar to TI-BASIC but not necessarly 100% similar and mostly game-oriented. It might be difficult to implement everything but at the rate this is progressing, I am confident he'll succeed in implementing a lot more.
I agree completely with you. Axe is realy a great 'invention.'
That said let's try to remain polite and respectful towards other people, though. That goes for both regular users and new people, but in case of new people, if they are rude or overly negative on their first few forum posts and did not even contribute anything else in the TI community so far, it is easier for their image to be tarnished.
Yes, I know, but when I typed my third post, I did not intend to be rude or someting, but it sounded rude because my english is not that good you know...:-[
Please forgive me? :'(
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 23, 2010, 02:51:24 am
Ooh sorry didn't know that x.x, actually English is not my native language either ^^, don't worry too much about it. I was just unsure since sometimes through text it can also be hard to interpret stuff. We eventually get used to each person's way of writing so everything is all good afterward. :)
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 11:58:30 am
OK. thanks for the encouragement ^^
Title: Re: Features Wishlist
Post by: Raylin on March 23, 2010, 04:40:34 pm
Linking capabilities must be implemented ASAP.
:D

This would be immensely helpful.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 23, 2010, 05:13:52 pm
I almost completely agree with you, except that accessing user variables is perhaps a little more helpful :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 23, 2010, 08:14:26 pm
It would be good if we could save/load from other types of variable, though, like Appvars, because if reading directly from lists, for example, it's easy to hack game save files, like setting LV 99, 9999 HP and 65535 gold, plus the person could cause a game crash x.x
Title: Re: Features Wishlist
Post by: Raylin on March 23, 2010, 08:15:27 pm
++
Agreed and seconded.
Title: Re: Features Wishlist
Post by: LordConiupiter on March 24, 2010, 02:45:57 am
yes, that's true.
but if you want to use ur asm prog within a BASIC prog, than it's easy to store some settings in a list, or in Ans.
BTW, In BASCI you cán edit the AppVars, when you convert them to a program (just one or two bytes different). But I assume that will not happen very often. And perhaps u sometimes just want to be able to check your game loading system, so then it is just usefull that lists or whatever can be accessed, i think...

My opinion: AppVars are usefull for game saves, and lists/Ans are/is usefull for settings to use in tour asm prog.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 24, 2010, 03:04:41 am
Oh yeah true about that, altough if the data saved is produced by Axe in ASM format, it will most likely be harder to dechiper for less experienced users, like hex. Plus if it's squished, the user may not even be able to dechiper anything, because try for example to unlock the program files for Ztris, Galaxian or Desolate in MirageOs and look at the junk that will show up in the BASIC editor.

But yeah I guess you have a good point.
Title: Re: Features Wishlist
Post by: Raylin on March 24, 2010, 01:47:24 pm
So.
Program Writeback to AppVars.
It must be done.
Title: Re: Features Wishlist
Post by: Quigibo on March 28, 2010, 11:14:14 pm
If you check the first post on this thread, I will be editing it constantly to give everyone an idea for the time frame in which I plan to add features.  It also keeps track of ideas already suggested.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 28, 2010, 11:31:19 pm
nice, good idea, it should actually guide people in what project (or parts of projects) to work on and which one to wait before starting working on so they wait for upcoming Axe releases to make their task easier. That's of course for less patient people, though, so these people will probably use or modify the premade ressources like those by SirCmpwn to get these features early :P

I really like the if counter idea, because it will make it much easier to create animations and the like
Title: Re: Features Wishlist
Post by: _player1537 on March 28, 2010, 11:33:40 pm
could there be another section that shows only completed routines and how they work, its sometimes hard to find a particular routine through all the pages
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 28, 2010, 11:35:31 pm
well they are included in html format with each Axe downloads. Check the documentation.html file.
Title: Re: Features Wishlist
Post by: _player1537 on March 29, 2010, 12:42:57 am
do you mean user made routines?
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 01:01:22 am
The user made routines I do not officially endorse because many of them will be added as built-in features in future versions.
Title: Re: Features Wishlist
Post by: _player1537 on March 29, 2010, 01:02:23 am
what about the development tools like sprite makers or pic2hex programs?
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 01:13:26 am
Probably those will come packaged with the parser when its completed either as a separate app or a submenu in the parser.  But right now, if anyone authors a useful helper program to make axe programming easier, feel free to submit it to me and I'll include it in future versions.  Its also a plus if you can write a short readme to go with the program.  Include proper credits to yourself as well.

EDIT: This includes help manuals and tutorials too!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 01:49:57 am
I think SirCmpwn was planning to rewrite stuff like pic2hex and tile2hex in Axe later (once Axe supports saving), in ASM or both, but I could be wrong
Title: Re: Features Wishlist
Post by: LordConiupiter on March 29, 2010, 09:07:23 am
can someone please explain how a counter statement will work?
perhaps I'll understand it when i see an example, but right now i don't know what it exactly will be.
Something like a for loop with multiple vars ???
Title: Re: Features Wishlist
Post by: Galandros on March 29, 2010, 10:26:21 am
I have one idea but is an important add in Axe Parser:

Use letters a-b (note the lowercase) to serve has 8-bit variables. You could most operations you can with the default 16-bit A-Z.
And be able to use the a-z numbers in the A-Z operations.

This would need a major rewrite in Axe Parser functions, I think, but could make it even faster.

I still would like the port access and indirection to places other than the equated in L1 to L6.
Title: Re: Features Wishlist
Post by: Raylin on March 29, 2010, 10:32:21 am
Wait.
What?

I read your post, Galandros.
I was like... .D.

Explain please.
Title: Re: Features Wishlist
Post by: Galandros on March 29, 2010, 10:42:04 am
Basically that you could handle numbers from 0 to 255 or -128 to 127 with lowercase letters.
You gain 26 fast variables for numbers.
Operations with them would be much faster (and maybe smaller, depending on the overhead to all functions needed) when translated to assembly.

An example usage of this:
1->a
If a<8
a+1->a
Disp a>Dec
Title: Re: Features Wishlist
Post by: trevmeister66 on March 29, 2010, 11:41:00 am
I think its a good idea, but how would it be smaller or faster?
Title: Re: Features Wishlist
Post by: calc84maniac on March 29, 2010, 11:46:28 am
I think its a good idea, but how would it be smaller or faster?
Because the z80 is an 8-bit processor, and by nature doing 16-bit operations is slower and produces larger code.
Title: Re: Features Wishlist
Post by: trevmeister66 on March 29, 2010, 11:49:49 am
Ah ok I understand now.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 01:53:49 pm
can someone please explain how a counter statement will work?
perhaps I'll understand it when i see an example, but right now i don't know what it exactly will be.
Something like a for loop with multiple vars ???
Quoted from Quigibo on a chat a few days ago, in BASIC you would do this:
Code: [Select]
A+1->A
If A=20
0->A
<do stuff>
End
In Axe you would be able to this equivalent:

Code: [Select]
IS>(A,20)
<do stuff>
End

Useful for animated tiles where the animation is not updated every frame
Title: Re: Features Wishlist
Post by: Quigibo on March 29, 2010, 02:01:41 pm
Right.  It increments a variable (like a for loop) and then checks to see if it has reached a maximum.  If the maximum is reached, the code gets executed and the variable resets back to zero so that the process can start over again.  So if you put it in your loop like this:

0->A
While 1
  <Render Frame>
  IS>(A,20)
    SinReg 150,5000
  End
End

This would make a beep every 20th frame.

DS<(A,20) would do the same thing but counts downwards and reset to 20 when it gets to zero.

And the lowercase operations might actually be not too much overhaul since they can just use the low order bytes of the standard variables.  However, they would be totally incompatible with regular variables.  You couldn't mix the two very easily without using some weird conversions.  Also, I would need to add some type of modifier so the parser knows if constants are 8 bit or 16 bit.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 29, 2010, 02:06:10 pm
I wonder if that could also help for example in an action game where the character has a sword and slash it to kill enemies, but still be allowed to move while slashing his sword? Without that it would be much harder to not make your character stop completly during the entire sword animation

Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 05:40:17 pm
Another feature idea, after Quigibo mentionned me might compress his title screen:  Compressed sprites routine

When compiling, you could have sprites be compressed and use a different sprite display routine to show them. It would prbly be slower but people could choose whether if they want to use compressed sprites or regular ones. I wonder if it would be hard to implement, though...
Title: Re: Features Wishlist
Post by: ztrumpet on March 30, 2010, 06:09:17 pm
Another feature idea, after Quigibo mentionned me might compress his title screen:  Compressed sprites routine

When compiling, you could have sprites be compressed and use a different sprite display routine to show them. It would prbly be slower but people could choose whether if they want to use compressed sprites or regular ones. I wonder if it would be hard to implement, though...
Sprites are already compressed at an 8:1 compression ratio (double the Hex, as they are stored in token-ized binary), so I doubt if they could get smaller.  However, if they could it's a really cool idea! :D

I really like Galandros' idea!  How much faster would that be, and how would it affect the code (bigger/smaller) if you end up doing it? ;D

The IS and DS commands look really cool!   Awesome idea! :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 06:17:05 pm
oh I suggested it cuz Quigibo comment about the Axe Parser title screen (which would be 768 bytes, in binary), left some indications that it could be compressed even more. What I thought about is for images with several lines of white pixels in a row as well as black. Instead of

00000011
11110000
00011110
00000000
01100000
00000111
00000000
11111000

it could maybe become stuff like 00000011
1x4 0x7 1x4 0x10 1x2 0x10 1x3 0x8 1x5 0x3

Idk what would be the format, though. Also with complex sprites, they may end up larger, actually x.x
Title: Re: Features Wishlist
Post by: ztrumpet on March 30, 2010, 06:20:57 pm
That's a really good idea! :D Could some type of RLE (Run Length Encoding) be used mabey? :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 06:34:48 pm
i wonder how does RLE works... i should maybe check out.
Title: Re: Features Wishlist
Post by: Builderboy on March 30, 2010, 08:19:14 pm
Heh, Dj what you just did is RLE :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 30, 2010, 09:19:44 pm
really? lol ok :P

I still should read further into it to see how it's applied in code form, though :P
Title: Re: Features Wishlist
Post by: Quigibo on March 31, 2010, 04:40:50 am
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Title: Re: Features Wishlist
Post by: Raylin on March 31, 2010, 11:41:31 am
I'm liking where this is going. :D

So, will Axe have a complied compression mode for data?
Title: Re: Features Wishlist
Post by: _player1537 on March 31, 2010, 11:57:56 am
there could also be a way to compress it like this...um I can't seem to find the program, but what it did was take each letter and strip it down to 6 bits, then packaged each of those 6 bit letters into a couple of bytes and every 4 letters saved you one byte.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 31, 2010, 02:47:27 pm
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Wouldn't there be a way to make Axe do the compression/decompression for us?

I would like text compression, tho, it would be nice for games with loads of it
Title: Re: Features Wishlist
Post by: ztrumpet on March 31, 2010, 04:52:30 pm
Heh, Dj what you just did is RLE :)
Yeah I was about to say that lol.  That's a good idea.  It would be quite easy to add too, but maybe a little advanced for most users and it would absolutely require a helper tool or a sketch on paper.  Its not just sprites you can compress.  Level data, text and even entire programs can potentially be compressed if they're sparse enough.
Wouldn't there be a way to make Axe do the compression/decompression for us?

I would like text compression, tho, it would be nice for games with loads of it
I agree here.  I think a longer compiling time would be better than having to compress things by hand.
Text compression sounds awesome too! ;D
Title: Re: Features Wishlist
Post by: Raylin on March 31, 2010, 05:16:54 pm
I agree with said statement.

However, it must be an OPTION.
I would hate to only have 'compressed compiling' available and not 'quick compiling'.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 31, 2010, 10:54:34 pm
what Raylin said. If auto compression/decompression was possible, I would still like to be able to use uncompressed sprites for stuff that need speed
Title: Re: Features Wishlist
Post by: Builderboy on April 01, 2010, 01:01:00 am
Yeah compression would be a great thing to add into axe, but i wonder...  different algorithms work best on different sets of data, i wonder how/if axe would chose different algorithms?  Then again it could always be up to the user to decide on one, or to write there own.  Hmmm its an interesting subject, i will have to think more on it...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 01, 2010, 01:35:25 am
you could maybe do one in axe but I want Portal X finished too D:
Title: Re: Features Wishlist
Post by: Builderboy on April 01, 2010, 01:42:25 am
Oh well i wasn't suggesting that i was going to write one, just that the option is open.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 01, 2010, 01:44:12 am
oooh ok lol :P
Title: Re: Features Wishlist
Post by: Raylin on April 01, 2010, 11:18:59 am
On that note, Portal X must be finished before Portal 2 comes out.
My soul will be ripped in two otherwise. D:
Title: Re: Features Wishlist
Post by: ztrumpet on April 01, 2010, 03:31:00 pm
On that note, Portal X must be finished before Portal 2 comes out.
My soul will be ripped in two otherwise. D:
On that note, Portal Gold, X, and 2 should all be worked on! ;D

I think using different commands for compressed data (vs uncompressed, normal data) would work. :D
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 10:48:37 pm
Find Value

inString(PTR, VALUE) || Searches the application variable the name points to for the designated value. Returns 1 if the value exists; returns 0 if the value doesn't exist.
Title: Re: Features Wishlist
Post by: calc84maniac on April 05, 2010, 10:49:49 pm
Find Value

inString(PTR, VALUE, MODE) || Searches the application variable the name points to for the designated value. Mode can be changed to decimal (1) or hexadecimal (2). Returns 1 if the value exists; returns 0 if the value doesn't exist.
Why are there different modes?

Edit:
I think maybe a better way to do this would be:
inString(PTR, VALUE, SIZE), which would return a pointer to the first value found, else 0 if not found.
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 10:54:38 pm
Oh yeah.
Brain relapse.

Edited.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:08:49 pm
would value be a specific byte in the appvar?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:30:23 pm
No.
It would be a value and Axe would search the AppVar for that value.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:43:01 pm
Mhmm...

Could you provide an usage example of what it would do, including Input and Outputted results as examples?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:47:25 pm
Code: [Select]
:"MYVAR->Str1
:"Saved.->Str2
:Select(Str1)
:GetCalc(50)->A
:45->{A+24}
:If inString(Str1,45)
:Disp Str2,i
:End

Something like that.

In this example, we put in two things. We told Axe to look in MYVAR (Str1) for the value 45.
It returned a 1 and as a result, it threw back a "Saved." message.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:47:51 pm
including Input and Outputted results as examples?
Title: Re: Features Wishlist
Post by: Raylin on April 05, 2010, 11:51:22 pm
EDITED.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 05, 2010, 11:57:22 pm
i still don't get it x.x sorry

Nevermind, then. It may just be way too low-level for me.

I think I will just stick to the functions from Axe 0.0.5 and a few of the 1.x ones and that's about it because the last time I checked the doc I forgot half of the commands :/
Title: Re: Features Wishlist
Post by: Silver Shadow on April 06, 2010, 03:11:15 am
That's why should always have a copy of the doc at hand when programming. I too find it difficult to remember all of the commands and their syntax. But the more you program, the more chances you have of remembering them.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 03:14:22 am
Well, I have it on my PC all the time and an older copy, but I stopped looking at it for a week and forgot a lot of commands. I had to ask Quigibo (via chat) to remind me what some do in more details x.x

I guess I'll really need to get coding again
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:08:31 am
I was planning to add an instr() command, but a little more general than what you are referring to.  It would be like this:

instr(START,BYTE<,SIZE>)

The last option is optional.  You give it a pointer, and it searches for the byte until it finds it and then returns the pointer to that byte, or it returns zero if not found.  That way, its not just limited to application variables, you can use it anywhere.

Its pretty easy to add, but I haven't yet because honestly, it really isn't as useful as it sounds.  There is a regular assembly instruction that does exactly this called "cpir" but I've never used it or needed to use it ever for anything.  I've almost never seen it used in other programs either.  It would only be needed for very specific applications, and even then its easy to write a subroutine yourself with existing commands.  But yes, I will support it eventually, but its in the back of my list.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:11:02 am
Just focus on the more essential commands for now I think ^^ (and bug fixes if any)

In such command, though, how would you specify (in this syntax) if you want to point to a byte in an appvar instead of inside the program?
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:15:00 am
In such command, though, how would you specify (in this syntax) if you want to point to a byte in an appvar instead of inside the program?

Select(Str1)
getCalc()->A
instr(A,'Z',100)

This would search for the character 'Z' in the first 100 bytes of the appvar.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:19:24 am
About getcalc() it returns what was selected with Select(Str1), right, then store it into A, then search from memory location A through the next 100 bytes, then return 1 if "Z" is found?
Title: Re: Features Wishlist
Post by: Quigibo on April 06, 2010, 04:25:24 am
Yes, but just like the calc's instr(), it doesn't just return 1, it returns the location of the found byte if it is found (a pointer) because this is much more useful.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 04:39:37 am
oh ok, that's better then. Thanks for explaining

I will most likely have to code more soon to not forget half of Axe commands again in a month x.x

Btw you might want to update the first topic post with the recent changes in features
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 05:16:42 am
perhaps it could be usefull to be able to call the register values from the processor? like hl?

the following code would return the value of ans:
Code: [Select]
PwrReg HLor
Code: [Select]
ref(HL)or
Code: [Select]
Get(HL)
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 07:15:26 am
perhaps it could be usefull to be able to call the register values from the processor? like hl?

the following code would return the value of ans:
Code: [Select]
PwrReg HLor
Code: [Select]
ref(HL)or
Code: [Select]
Get(HL)
But HL is already, by default, "Ans". The other registers hold nothing useful, unless you use them with inline Asm (in which case you would just use the inline Asm to access the registers anyway)
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 09:00:33 am
U're (partially) right. On second thought this idea is pretty unusefull, but I thought that Axe perhaps could get the functionality of ASM on ur calc. Just like in C: u can use built in functions, but u can also use more 'native' commands.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 01:54:59 pm
It's better to not make Axe look too complicated by adding low level commands like this, though, or at least list those commands in a special area stating you need ASM knowledge to use them, not with the other commands, else people will look at the first commands in the doc and get the impression the language is not much easier than ASM as soon as they run into such command in the list.
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 01:56:59 pm
It's not really as complex as it looks.
It's just inString in essence.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 02:28:56 pm
Aaah ok, just making sure. Cuz Axe in the first place is meant to be kinda easy to learn and look user-friendly at first glance
Title: Re: Features Wishlist
Post by: LordConiupiter on April 06, 2010, 02:34:39 pm
OK, perhaps reading registers is not one of my best ideas x.x
The more experienced programmers just should use inline ASM, thats a much better idea then I guess
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:37:31 pm
I dunno if I said it already but...

Pt-On(X,Y,PIC,<dimension1>,<dimension2>)

If <dimension1> and <dimension2> aren't found, automatically display the sprite in 8x8.

Also,

DS<(TYPE, X1, Y1, X2, Y2)

Begin drawing a shape of a certain TYPE (xLib commands 0-10) at (X1,Y1) and stop at (X2,Y2).
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 10:39:38 pm
I dunno if I said it already but...

Pt-On(X,Y,PIC,<dimension1>,<dimension2>)

If <dimension1> and <dimension2> aren't found, automatically display the sprite in 8x8.

Also,

Pen(TYPE, X1, Y1, X2, Y2)

Begin drawing a shape of a certain TYPE (xLib commands 0-10) at (X1,Y1) and stop at (X2,Y2).
The Pen token is unusable in programs, FYI
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:42:17 pm
Oh.
Oops.

I need to get more sleep.
EDITED.
Title: Re: Features Wishlist
Post by: Will_W on April 06, 2010, 10:42:47 pm
It's not a token at all.
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 10:45:40 pm
Changed the command to DS<().

It works, too.
:D

Draw Shape! :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 10:49:43 pm
Remember for sprite width, they would need to be multiples of 8, though.
Title: Re: Features Wishlist
Post by: calc84maniac on April 06, 2010, 10:59:34 pm
I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" value
Title: Re: Features Wishlist
Post by: Raylin on April 06, 2010, 11:04:36 pm
What about imag()?

Could that work?
Title: Re: Features Wishlist
Post by: SirCmpwn on April 06, 2010, 11:07:53 pm
^ I like that idea.
Also, you could easily do something similar to Celtic III for file access.  (I just realized Iambian is on this thread right now, lol)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 06, 2010, 11:09:34 pm
I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" value
The If counter commands, IIRC. He explained it in a post somewhere but I don't remember in which thread. (Darn this sub-forum is getting big)

Also try to not use too many two byte tokens for commonly used Axe commands, such as ANOVA(
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 12:39:30 am
For sprites larger than 8x8, you can just use a subroutine:

:[your 16x16 sprite here]->Pic1
:0->X->Y
:Pic1sub(DS)
:DispGraph
:Return

:Lbl DS
:->A
:Pt-On(X,Y,A)
:Pt-On(X+8,Y,A+8)
:Pt-On(X,Y+8,A+16)
:Pt-On(X+8,Y+8,A+24)
:Return

This will draw sprites with any size from 9 to 16 pixels.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 12:57:21 am
Would LordConiupiter routine work as well too? He posted some weird sprite routines that apparently displays 16x16 sprites, using some r commands. Which one would be faster and which one would be smaller (in ASM form)?

http://ourl.ca/4129/83923
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 01:08:46 am
That's is basically a Pt-Off() routine, but it only works when the sprite is aligned to the 8x8 grid.  BUT, if you only need the sprite aligned anyway and are always using Pt-Off(), it sure does work.  Keep in mind though that the axe sprite commands are usually smaller and faster.  I haven't compared this one though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 01:43:17 am
Ah ok thanks for the info. To me, such routine would most likely be for both tiles and sprites, so having to align it might be an issue if I wanted smooth movement x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 02:56:08 am
Just updated the list fyi.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:10:54 am
Ok good ^^


Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.

Also, when Axe final version (or the one where old commands will have almost no more chances of changing) is out, do you think it may be best to split Axe routines into their own sub-forum and put them in a new sub-forum between TI-BASIC routines and ASM routines? As for now, they are getting harder and harder to find through the 1400+ posts in this sub-forum, even if a topic dedicated to them was made, but for now I would wait a bit to do such thing, though, since you said Axe syntax for some commands may change (unless this is not the case anymore?)
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 07:19:59 am
Regarding features, there's something I wonder... would support for 4 bits integers be something very hard to implement? In the cases where people use one byte for two tiles in a tilemap data, for example, maybe it would make it easier for people to work with the data, as they wouldn't need to remember how to write routines to split it.

If you have a byte A with two 4-bit numbers packed in it, you can extract them with A/16 and A^16

Edit:
If you want greater speed, use A*16/256 instead of A/16 so it doesn't have to do any real division
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:12:37 am
Thanks I guess that works too and I didn't knew about the later x.x, I guess it might be a good thing to add to Optimizing Tips.txt.

As for A^16, I assume afterward it may be best to redivide it with A*16/256 (or A/16) afterward, right? I worry about having to use more If/then conditions for sprite/tiles displaying then x.x (since that sprite number would be multiplied by 16 unlike the one initially extracted with

Btw I would also find half bytes much easier to read than full bytes in map data since each tile would be one single character instead of two and as you know I am so used to work with text for sprites, so if I need to do a quick edit without wanting to dig up a tile/map editor, I can simply just edit the data directly easier.
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:17:33 am
Mmmm it would be nice for Axe to optimize division by any number multiple of 2 into a chain of bitshifts.  I was at first surprised how slow /64 was compared to /2 :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:18:47 am
yeah that might be a good idea too, even if it means slower compiling :P
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:21:14 am
Hah, at this point i dont think we even have to worry about compiling speed.  It might be the difference between 1 second and 1.1 seconds ^^ Gosh i love the Axe compiling speed, especially after having worked with the slow version for so long ;)
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:23:22 am
Yeah, Axe compiles super fast.  I love it.
Also, I would like to be able to retrieve the pointers to a label for normal math.  This could be useful in the Half Life game engine.  For instance:
Code: [Select]
AB->A
Disp A>Dec   ; Display the address of AB
Return
Lbl AB
Disp "Hello World"
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:41:38 am
Yeah true I guess. I think as long as it won't take 10 seconds to compile 5000 bytes of source we're fine. Plus those who used TASM to compile ASM on old computers are used to much slower compiling speed anyway. On my Pentium II 350 MHz, it took 4 seconds just to compile Hello World. I'm not sure how much faster it is on newer PCs, though.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 11:31:34 am
Hey, using OTBP Assembler, it takes about 30 seconds to compile Hello World.  Mosaic does the same program in less than one.  I'm excited to finish it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 12:17:33 pm
Lol, funny how a 6 or 15 Mhz calc can compile an ASM program faster than a computer. Plus you don't need to go through the process of loading the file on Wabbitemu all the time, meaning saving even more time and the only thing to worry about is making sure your data is safe on calc (CalcUtil I guess) in  case your program contains errors.
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 02:02:40 pm
Bit shifts are not the best way to go for division since it takes 4 bytes each shift.  That's why I didn't optimize higher divisions of 2.  But now that I think about it, multiplication as a method of dividing is small enough to optimize.  I'll add that next time.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:00:39 pm
Which kind of division is called bit shift? Do you mean the one going like A/2/2/2/2?
Title: Re: Features Wishlist
Post by: Silver Shadow on April 07, 2010, 03:09:31 pm
Hey, using OTBP Assembler, it takes about 30 seconds to compile Hello World.  Mosaic does the same program in less than one.  I'm excited to finish it.
"Mosaic"?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 03:10:45 pm
http://ourl.ca/4332
Title: Re: Features Wishlist
Post by: Silver Shadow on April 07, 2010, 03:20:55 pm
That's strange. I have no idea how I managed not to notice it...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 04:19:45 pm
Well on some days projects get posted in a lot and if one gets no updates for a few days, it drops in the list pretty fast. Half of the first project topics page has posts from 2010.

This is why the new double posting rule that was added in march on Omnimaga is 1 hour between posts for authors projects rather than 6

EDIT:

I have a suggestion for one of the future update, that is not for Axe app itself, but either the doc or another help file: a list of all compiling error codes possible, their descriptions and possible causes and possible solutions for most common cases.
Title: Re: Features Wishlist
Post by: Quigibo on April 07, 2010, 08:34:04 pm
Definitely will add that doc when finished.  Currently, I have VERY non-descriptive errors like TI-Basic.  There are only about 15 possible errors right now, but I plan to have about 50-100 when finished to be really specific about the exact part of the code that has the problem.
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 08:38:22 pm
O_O

If you were to put a line number in that...

ERROR: BAD SYMBOL - LINE 6

OMG.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 08:40:27 pm
well, the issue, though, with line number, is that for massive programs it's hard to count until that line if the error is at like line 500 x.x
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 08:51:41 pm
What if it displayed the line in question on the screen?
Like in small text...?

ERROR: BAD SYMBOL - LINE 6
:"This is a test->Str1-><theta>
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 09:09:12 pm
that could work too
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:10:06 pm
I don't belive you can store to <theta> with Axe.  At least, I couldn't do it in version 0.1.2.
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 09:13:22 pm
I don't belive you can store to <theta> with Axe.  At least, I couldn't do it in version 0.1.2.

LOL. SirCmpwn, the point of that entire post was that <theta> was a bad symbol. It was just an example. :P

250th post. :D
FINALLY!
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:14:09 pm
...
I made a fail... where are the paper towels?
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 09:17:43 pm
LOL. In the bathroom. :P

[ontopic]I would like it if linking could be available through Axe soon. Get() and Send() are mocking me.[/ontopic]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 09:54:21 pm
However, wouldn't that be hard to implement? I heard something about how getting a calc variable/memory area while the calc is busy was rather hectic and that for it to be successful, the receiving calc had to receive at the exact picosecond the sending calc is sending. That,s how Omnicalc get/send commands works, IIRC.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 09:57:02 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 10:03:54 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Well, there are two link lines, but only one bit can be sent at once. The sending calculator pulls either line A or line B low, depending on the value of the bit being sent. The receiving calculator acknowledges by pulling the other line low. Then the sending calc lets its line up, and the receiving calc lets its line up.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:05:50 pm
^oh, i see.  Does the hardware ack or the software ack?
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:14:56 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 10:17:20 pm
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.
Although, I'm not a guru on linking.  I know that the ports on each calc mimic each other, so it might be a good idea to assign a random bit, high or low, to each calculator, in which case you can only send one bit at a time.
Well, there are two link lines, but only one bit can be sent at once. The sending calculator pulls either line A or line B low, depending on the value of the bit being sent. The receiving calculator acknowledges by pulling the other line low. Then the sending calc lets its line up, and the receiving calc lets its line up.
just one bit, not even byte? Darn, now to send an entire byte...
Title: Re: Features Wishlist
Post by: Raylin on April 07, 2010, 10:17:40 pm
Whatever allows for real-time multiplayer games is good with me. :)
Title: Re: Features Wishlist
Post by: Builderboy on April 07, 2010, 10:18:30 pm
Heh, yeaah once we write a bit sending routine, we use it to write a byte sending routine XD Haha the joys of asm ^^
Title: Re: Features Wishlist
Post by: SirCmpwn on April 07, 2010, 10:18:31 pm
DJ, to send an entire byte require at 4 loops per byte, if I am correct.
Title: Re: Features Wishlist
Post by: calc84maniac on April 07, 2010, 11:06:42 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
The problem here is that bits may be skipped. Not good D:
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 07, 2010, 11:09:31 pm
I was reading about linking, and would it be faster to have one line be a clock, and then the other line be the bit to be sent?  When the receiving calc detects a change in the clock line, it inputs the bit line into memory.  Seems like it would be faster?  I'm just theorizing tho :P
The problem here is that bits may be skipped. Not good D:
that was my worry about linking stuff.

I wonder how does Ztris and Ztetris do their linking, though, to work so successfully. I never had issue with their linking failing unless both calc models were different.
Title: Re: Features Wishlist
Post by: Quigibo on April 08, 2010, 12:13:01 am
Linking is very easy.  I could add that feature literally in about 10 minutes.  I already made the routines when I made puyo puyo.  Actually coding it well with Axe Basic to get the link synchronized is going to be tricky on the programming side though.  I have spring break coming up next week.  I'll definitely finish the beta sometime around then and I'll have most of these commands working.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 08, 2010, 12:56:48 am
really? I guess it might need some small tutorials with example, though, I guess

I can't wait ^^
Title: Re: Features Wishlist
Post by: Raylin on April 08, 2010, 07:32:25 am
That is AWESOME, Quigibo!

:D

FORGE FORWARD!
(Also, I offer my writing skills for the tutorials.)
Title: Re: Features Wishlist
Post by: Quigibo on April 09, 2010, 04:14:40 am
Just want to take a little poll:

Should For() loops be signed or unsigned?  If they are unsigned, you can make loops as large as 65536 but you can not increment from a negative number to a positive one.  With signed For loops, you can do things like this:  For(A,-8,8) however it limits the maximum size to half of the unsigned max.  Also, the signed routine would probably be about 3-4 bytes larger each For loop and consequently slightly slower each iteration (usually negligible).  I could have an option to do either one, but I don't want it to get too confusing and I have no idea what type of syntax modifier I would use.  Maybe I can make the 'R' power thing the universal modifier where when you put it at the end of a command, it does the non-default version.
Title: Re: Features Wishlist
Post by: mapar007 on April 09, 2010, 05:52:38 am
Mmmh... A hard choice. I think having it as an option is the best. (do you have support for optional arguments in statements? It might be the fifth argument of a For() instruction)
Title: Re: Features Wishlist
Post by: Raylin on April 09, 2010, 08:12:19 am
^++
Agreed and seconded.
Optional unsigned For( loops.
Title: Re: Features Wishlist
Post by: mapar007 on April 09, 2010, 08:17:13 am
Yup, unsignedness should be the optional setting. You rarely need to go over 32K in a loop.
Title: Re: Features Wishlist
Post by: SirCmpwn on April 09, 2010, 08:39:33 am
I like the idea of making R the universal modifier.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 09, 2010, 09:22:50 am
Maybe optional, altough I personally may not mind if unsigned is not supported. For which thing in particular would you need numbers higher than 32767 in For loops ?
Title: Re: Features Wishlist
Post by: Builderboy on April 09, 2010, 10:29:02 am
And if you really really needed to go higher than 32767 you could just do

For(F,-32767,32767

And you would get the full range there :)
Title: Re: Features Wishlist
Post by: Quigibo on April 09, 2010, 04:14:29 pm
The range is the least of my concerns.  The increase in file size is what I'm worried about because It will make all programs bigger that use for loops.  I think I will use a modifier to make it optional, probably the R again.  From now on, the R will stand for "Revised" and be a slight modification of the original command.

For instance, adding it to the end of any drawing command makes it do grayscale drawing instead of regular.  I'm sure I will find more uses for it soon as well.

Another thing I wanted to mention is that for signed math, I think I will make the default unsigned instead of my original idea of making it signed by default.  I have chosen this way for the following reasons


But the first of these reasons is the most important.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 09, 2010, 04:18:15 pm
I would go with what is smaller in size, or if adding the option to use alternatives won't increase the compiled program size, add options too.

I didn't knew unsigned was faster and smaller. I guess you should probably make them all default. You should also mention in the doc that signed will make the program larger so people are aware of that.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:45:46 am
Feature suggestion and question:

1) It would be nice if there was a command to return 0 if the calc it's ran on is a regular 83+, 1 if it's a 83+SE, 2 if it's a 84+ and 3 if it's a 84+SE.

2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot x.x
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:49:18 am
2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot x.x
It is meant to replace a bunch of If/Else statements with A=0, A=1, A=2, A=3, etc, replaced with a faster and smaller solution (or something like that)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:50:54 am
mhmm ok, would this make the compiled code smaller?
Title: Re: Features Wishlist
Post by: Builderboy on April 11, 2010, 12:52:01 am
The switch statement is this:  Sometimes you have data you want to be loaded, or specific things to do under specific circumstances.  Usualy you have to do this with a list of If statements like this:

Code: [Select]
If A=1
Blah
End
If A=2
Blalala
End
If A=3
Bluhuh
End
If A=4
Wooo
End
If A=5
Rickroll
End
If A=6
Grrrr
End

but with a switch statement you could do something like this

Code: [Select]
Switch(A)
1:Bla
2:Woooo
3:Grrrr
4:Rickroll
5:Chocolate rain
6:Lobser
End

Which is a lot easier on the eyes :) Although it probably would have zero affect on compiled size or speed.  Normaly it is just a feature to make things look nice
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:56:48 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 12:58:22 am
OOooh! ok I see! It would be MUCH handier this way! Much easier to read and to code.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 02:10:47 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Right, its much more efficient in an assembly program to do switch statements than a bunch of if statements.

Unfortunately, it would be way too hard to automate this into the parser since its not just simple templated code.  It would have to check all the conditions in the beginning (non-linear parsing) and then create a jump table to each of the switch labels.  It's just way too complex to code and it would need a lot of extra memory.  I mean I could just do it as something that just makes it "easy on the eyes" but I don't feel like its worth the extra effort.  ElseIf statements should take care of this for the most part anyway.
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 02:14:34 am
In cases like this though, it could make the compiled size smaller if you are using enough options, because it can use a table of jumps instead of a bunch of, well, if statements
Right, its much more efficient in an assembly program to do switch statements than a bunch of if statements.

Unfortunately, it would be way too hard to automate this into the parser since its not just simple templated code.  It would have to check all the conditions in the beginning (non-linear parsing) and then create a jump table to each of the switch labels.  It's just way too complex to code and it would need a lot of extra memory.  I mean I could just do it as something that just makes it "easy on the eyes" but I don't feel like its worth the extra effort.  ElseIf statements should take care of this for the most part anyway.
My idea was that it would be required to be from 0 to some number N, and the values must be typed in increasing order. Any missing numbers would jump to the "default" tag
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 02:41:50 am
hmm... If they are forced to be in order from 0 to N that would greatly simplify the statement.  But since the parser doesn't know how many labels are in the switch statement, I would have to dynamically expand the table in the end of program location.  And I think I would still need nonlinear parsing.

What I could do is have the switch statement require labels in the program which would take the burden off of the parser and into the programmer's hands.  Something like this:

Switch(A,J0,J1,J2,J3)

Lbl J0
...

Lbl J1
...

etc.

Here, if A is 0, it jumps to label J0, if A is 1, it jumps to label J1, etc.  You can choose any labels you want (including identical labels) and the variable you are comparing can be any expression.

Would this be useful to anyone though?  It does kind of limit the usage a little bit.
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 10:57:17 am
Hmm...

I can't really see the purpose of this command...

What are the benefits of having this over saying If A=0:End, etc... ?
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:28:43 pm
Hmm...

I can't really see the purpose of this command...

What are the benefits of having this over saying If A=0:End, etc... ?
It would produce faster and smaller z80 code.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 12:31:53 pm
Does the parser support conditional form:

While (A=0)(B=0)(C=12)

cuz i use that alot now.
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 12:35:21 pm
Does the parser support conditional form:

While (A=0)(B=0)(C=12)

cuz i use that alot now.

You will need to put an "and" between each of those statements (there is no implied multiplication in Axe, and you will want to avoid multiplication for speed reasons anyway)
Title: Re: Features Wishlist
Post by: _player1537 on April 11, 2010, 12:35:58 pm
well, you would have to put a '*' symbol in between those, but yes that would be valid (I'm pretty sure at least)

Edit: Yeah, what calc said would be better
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 12:56:38 pm
Yeah, multiplication can really destroy the speed of a program.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 11, 2010, 01:35:05 pm
I assume this excludes multiplication by 2, right?
Title: Re: Features Wishlist
Post by: Raylin on April 11, 2010, 01:40:52 pm
Of course.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 04:08:24 pm
also excludes multiplication of 3,4,5,6,7,8,9,10,12,16,32,256 and more in the future. (see optimization tips)  Also, the multiplication is only optimized if the constant is on the right!  So 2*A is just as slow as regular multiplication.  You need to do A*2 to get the speed and size benefits.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 06:17:43 pm
So, wait. I can't even multiply this type of a function for attack power:

1.5*L [store] B

Where L is your level and B is your attack booster.


And can variables in Axe hold fractions (as in 1.34) as a value.
Title: Re: Features Wishlist
Post by: Builderboy on April 11, 2010, 06:27:56 pm
Nope, Axe does not have decimal support, so you can only have whole numbers.  You can kind of multiply by 1.5 by doing

L*3/2->B

But you wont get the precision of using floating point numbers, it will drop the decimal places.
Title: Re: Features Wishlist
Post by: ACagliano on April 11, 2010, 06:31:32 pm
Bah humbug.

It's ok, though. I'll figure it out. Axe still rocks.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2010, 08:03:16 pm
Actually, you can do decimals (for the most part).  Since variables are 2 bytes, the low byte can be the decimal part and the high byte can be the integer part.  It requires some knowledge of hexadecimal though and the math might be a little confusing at first, but its almost the same as regular math.
Title: Re: Features Wishlist
Post by: Will_W on April 11, 2010, 08:09:30 pm
That's called 8.8 fixed point by the way if anyone wants to know more about it, and I have a (poorly coded) include file that does some stuff with it in z80 over at revsoft.
Adding two 8.8s is the same as adding two 16 bit numbers.  Multiplying two 8.8s results in a 16.16 which needs to be truncated differently (Keep the middle bytes) than if you had multiplied two 16 bit numbers(Keep the low bytes).
Title: Re: Features Wishlist
Post by: calc84maniac on April 11, 2010, 11:42:14 pm
Quigibo, I think you should have an operator to multiply by an 8.8 fixed point value (because this type of value is what sin and cos return, right?)
Title: Re: Features Wishlist
Post by: Will_W on April 11, 2010, 11:53:51 pm
8.8 multiplication would be niffty.  I can't think of it right now, but I'm pretty sure division is different too.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 01:27:25 am
Quigibo, I think you should have an operator to multiply by an 8.8 fixed point value (because this type of value is what sin and cos return, right?)
Kind of.  Since the range is 127 to -127 its really half of the actual sine value.  By the way, thanks for the sin routine!  I modified it a little to get it in the right range, but it's a pretty cool optimization.  I don't know if you were aware I used it.  Someone gave it to me in IRC and said you made it.

I don't know if 8.8 multiplication is really that essential.  There's already a way to multiply by fractions (a multiplication then a division like Builderboy's example) and I've never actually needed to use 8.8 it in any of my asm programs before.

A little off topic:  I'm trying to think of a way to make shell support and I'm not sure how to do the menu because I think it'll be too complicated to have that information built into the source.  There's a lot of information in descriptions and thumbnails, both of which are hard to input.  So unless I make it real simple: Description is the first comment in the program and the thumbnail is an Axe logo, I'm not sure how to go about this and still be easy to use.  I think I'll just go with the simple way for now and do the more complicated way later.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 01:35:08 am
Remember that Ion doesn't support thumbnails, tho, even when its programs are ran in Mirage. Maybe for now have the compiled program name as first line, description, and for now Axe logo for thumbnail if compiled for MirageOs. Later, maybe add support for custom logos?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:02:45 am
Remember that Ion doesn't support thumbnails, tho, even when its programs are ran in Mirage. Maybe for now have the compiled program name as first line, description, and for now Axe logo for thumbnail if compiled for MirageOs. Later, maybe add support for custom logos?
That's essentially exactly what I just said ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:07:01 am
I know, I was just stating it as what I think that should be the best idea...

Well this was my final Axe Parser suggestion/opinion statment. I'm going to let other people provide theirs and wait for the final version.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:12:55 am
You ended it with a question mark so I thought you were asking me if that was what I was going to do.  Sorry if I misunderstood...
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:15:34 am
Take a look at the DCS BASIC header:
::DCS6
:"64-char_hex_icon
:Program code
I can't think of a way to use sine values without 8.8 multiplication, since they are always between [0,1]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:19:13 am
You ended it with a question mark so I thought you were asking me if that was what I was going to do.  Sorry if I misunderstood...
Oh sorry for the confusion x.x

I sometimes tend to end my suggestions (especially short ones) with a question mark, especially when the person asks for some. x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:29:56 am
Its simple:


;A holds the value to be multiplied in the range 0 to 255
;B holds angle

sin(B)*A/256    ;You can do this right now, but its unsigned
sin(B)*A//256    ;You can do this in the future as signed


Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:36:03 am
is dividing by powers of two optimized so it uses shifting instead of division?
Or better yet, Shifting and rotation commands?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:41:52 am
Well, /2 is optimized and so is /256.  /4 is not since its 8 bytes.  A load and call to the subroutine is only 6.  If you want a speed optimized command instead of a size one, you can just do /2/2 and chain them for higher powers of 2.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:45:37 am
Very nice, multiplication too?  And rotation commands?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 03:28:18 am
Well, /2 is optimized and so is /256.  /4 is not since its 8 bytes.  A load and call to the subroutine is only 6.  If you want a speed optimized command instead of a size one, you can just do /2/2 and chain them for higher powers of 2.
So /2, /16, /256, *2, *16 and *256 are optimized, right?

I personally optimize for speed most of the time. Most BASIC programmers badmouthed me for large filesize in the past due to that, but I did not want Reuben Quest to run at like 1 fps on a SE for example. If size is really a concern, I would most likely go for the slower method, though.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 03:53:29 am
The full list is included in the zip file in the optimizations file.  I know its easy to miss, so here is a copy of it:

Code: [Select]
================================================
List of expressions with automatic optimizations
================================================
Expression______Bytes___________
+VAR            5
+CONST          4
+1              1
+2              2
+3              3
+256            1
-VAR            7
-CONST          4
-1              1
-2              2
-3              3
-256            1
*VAR            7 + sub
*CONST          6 + sub
*2              1
*3              4
*4              2
*5              5
*6              5
*7              6
*8              3
*9              6
*10             6
*12             6
*16             4
*32             5
*64             6
*256            3
/VAR            7 + sub
/CONST          6 + sub
/2              4
/128            5
/256            3
^VAR            7 + sub
^CONST          6 + sub
^2              5
^4              6
^8              6
^16             6
^32             6
^64             6
^128            4
^256            2
=VAR            12
=CONST          11
=SHORT          10
=0              8
=1              8
=/=VAR          12
=/=CONST        11
=/=SHORT        10
=/=0            7
=/=1            8

SHORT means less than 256 bytes
CONST means any size
=/= is a "not equal sign"

I'm aware there's more I can add, I'm just focusing on other more important things at the moment.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 04:01:50 am
Oh I didn't knew this is what it was about x.x. The second column confuses me. Is it the amount of memory each of those takes, or is it the amount of memory saved by using them over something else?

EDIT: nvm, looking at the multiplications, I think I get it, now. Some of those seems to take a lot of memory o.o does this means A/2 would take 4 bytes total or 4 bytes for the /2 plus the amount of bytes for the A part of the code?
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 04:11:39 am
Yeah it doesn't account for the variable loading.  Its 3 bytes to load variables or constants before you actually do the operation.

Also Axe is much much much faster than BASIC.  Remember that it requires a whole new mindset.  The only time you ever have to worry about speed is with very intensive drawing and computation.  For instance more than 20 sprites with collision detection, event handling, and maybe some AI code.  And even then, the speed increase is usually a very small fraction of the total cycles.  Most cycles go into displaying sprites usually.  That's why I always optimize for size.

And of course I say "usually".  You can always optimize these things yourself even though its not automatic.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 04:17:19 am
Yeah speed wise I really meant games with a lot of stuff moving around like your space shooter. I guess the best way would be to try out and if I find the speed gain to not be signifiant enough (especially if I have to slow the game down) I will just go with size.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 11:46:05 am
Does Axe have rotation and bit logic?
Title: Re: Features Wishlist
Post by: Raylin on April 12, 2010, 01:18:13 pm
It needs to.
:D
:D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:03:51 pm
What would be bit logic?
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:08:44 pm
It means the "and", "or", and "xor" commands that work bit-by-bit (which is the default in Axe). I also assume he means bit shifting (which are *2 and /2 in Axe). There is no bit rotation command, though (but seriously, even C doesn't have that)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:10:12 pm
aaaah ok. Wouldn't that be complicated to use, though? x.x
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:11:12 pm
Oh?  I didn't know C didn't have that.  Guess there's no real need of it in Axe then.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:13:42 pm
What would be an example (maybe some sort of Axe pseudo code) of it in action and example of what it would do?
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:17:00 pm
Take the byte 11010100 and rotate it to the right one through carry, and you get 01101010. 
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:19:52 pm
Probably the most useful application is when working with bitfields. Say you wanted to have a variable that holds various flag bits, that are 0 or 1. You can use bitwise logic to change individual bits of the value.
A or 4->A would set bit 2 to 1, for example. A and 4 would be used to check whether bit 2 is 0 or 1. It's really a pretty low-level thing, but it can be useful (I sure wish TI-Basic had this)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:31:57 pm
mhmm ok so if for example

A=0 all 8 bits would be 0,
If A=1 the 8th one would be 1,
If A=2 the 7th one would be 1,
If A=3 both 7th and 8th one would be 1
If A=4 the 6th one would be 1,
If A=5 the 6th and 8th one would be 1

And so on?

I'm a bit confused, still. I don't know if I understadn what you mean.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:33:28 pm
mhmm ok so if for example

A=0 all 8 bits would be 0,
If A=1 the 8th one would be 1,
If A=2 the 7th one would be 1,
If A=3 both 7th and 8th one would be 1
If A=4 the 6th one would be 1,
If A=5 the 6th and 8th one would be 1

And so on?

I'm a bit confused, still. I don't know if I understadn what you mean.
Yeah, you've got it right (except we refer to the rightmost bit as bit 0, and the leftmost as bit 7)

Edit:
Example, setting pixel (0,0) of the graph buffer manually:
{L6} or 128->{L6}
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:36:05 pm
oh ok. My worry, though: wouldn,t it be very hard to do If conditions checking if certain bits are = to 1? Maybe it would need a special command to check each indidivual bit

I would love this feature, though, because it would make storing switches/treasure chests/items acquired flags much easier and smaller.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:38:20 pm
oh ok. My worry, though: wouldn,t it be very hard to do If conditions checking if certain bits are = to 1? Maybe it would need a special command to check each indidivual bit

I would love this feature, though, because it would make storing switches/treasure chests/items acquired flags much easier and smaller.
Hmm, this is true. Maybe there should be a command to return powers of 2 for quick bitwise operations.
Title: Re: Features Wishlist
Post by: Will_W on April 12, 2010, 02:40:27 pm
To check a bit, you can mask it with And.
Title: Re: Features Wishlist
Post by: calc84maniac on April 12, 2010, 02:43:04 pm
To check a bit, you can mask it with And.
Yeah, but the issue is with having to write each case of "and 1", "and 2", "and 4", etc. Having something that will check a given bit from 0 to 7 (or 15, since we are using 16-bit values) would be pretty useful to get rid of repetitive code.
Title: Re: Features Wishlist
Post by: Quigibo on April 12, 2010, 02:44:41 pm
Yeah, but its much more size and speed efficient to use bit checks.  I'll add auto-ops for "and" and "or" operations with powers of 2 sometime in the future so they can be used.  Maybe even a binary prefix, becasue that would really help with this.

EDIT: ninja'd!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 12, 2010, 02:44:58 pm
Yeah this is what I meant (calc84 reply). Else we may end up with like if A=0 or A=2 or A=4 or A=6 or A=8 or A=10 or A=12 x.x

Or smaller stuff but still complicated x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 11:09:52 am
Something I've been curious about all of a suddent is: if Axe Parser had Line( support, could it be somewhat fast enough for someone with 3D experience to write a raycasting engine?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 01:51:11 pm
*gasp* :O

The possibilities are endless.
Title: Re: Features Wishlist
Post by: Quigibo on April 13, 2010, 03:22:51 pm
Raycasting wouldn't use the Line() command unless all the walls are pitch black, and then you can't see anything.  The actual algorithm is very complicated and although it could be made with Axe, it would either be too slow or very minimal.  However, by using Line() Axe is definitely fast enough for some realtime 3D wireframe renderings.

I won't promise anything, but it could be a possibility that I might add automated ray casting and mode 9 support in a very far future version.  I have no idea how it would work though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 04:33:49 pm
Aaah ok I see. I was not sure if raycasting used multiple sets of Line(-alike commands. For wireframe 3D I think it could be fast indeed, unless the models had an extreme amount of polygons. Maybe something like Space Dementia 1 for 68K calcs?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 07:46:56 pm
OH MY GOD...

AUTOMATIC RAYCASTING?
MODE 9 SUPPORT?

:D
:D
:D

GOD, I LOVE YOU, QUIGIBO.

nohomo
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 07:57:41 pm
Uhm, I missed the Mode 9 part. What would it be? I know about Mode 7 but not 9

I assume it would make both Axe parser and the compiled programs considerably larger, right, tho (if raycasting or the like were added)?
Title: Re: Features Wishlist
Post by: Raylin on April 13, 2010, 08:00:40 pm
Yes, I'm sure. If the options were activated.
But, if the compressed-run mode feature is put in...

:D
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:13:51 pm
raycasting isn't used for polygons
ray casting is where you have a grid, and every cell on the grid either has a wall, or lacks a wall (it can be extended to give different heights to the walls).  Now, take a line with 96 evenly spaced segments (1 for each pixel the lcd is wide), and a point behind the line (the eye).  Draw a line from the eye, through the center of each of the 96 segments, and see where the closest intersection of that line and a cell that contains a wall is.  Now, from that distance, you calculate how tall the wall should look, and draw that in the vertical center of the screen.  Checking the ray for collisions is complicated, since you can't just test every time the line travels one unit (you could miss walls that way if the unit mark happens to not be in that cell), so you have to use DDA (digital differential analysis), where you check for a hit every time the x or y position of the line is a whole number.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:17:04 pm
Oh I didn't meant it was used for polygons, I was confirming that Line would be very useful to do actual polygon 3D routines.

For raycasting, if the map is stored in some sort of array/matrix/list/tilemap, can't you use some sort of tile-based collision detection instead?
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:18:33 pm
like what?  that's basically what DAA is.  Maybe if I ever feel like learning Axe I could port my 3D engine.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:19:30 pm
really? For some reasons, I gathered something totally different from your explanation, simply because you called it DDA instead of "tile-based collision detection" x.x. I am so used to hearing the later.
Title: Re: Features Wishlist
Post by: Will_W on April 13, 2010, 08:22:09 pm
http://www.student.kuleuven.be/~m0216922/CG/raycasting.html
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 13, 2010, 08:24:47 pm
I kinda wish they would use similar game making vocabulary for every type of game. We would get less confused about what is what from a game to another and not mistake one thing in particular as two different things.
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 07:20:49 pm
I updated my to-do list.  I've pretty much finished everything I thought would be "essential" for the beta release, so I think I might just halt the new commands for a little bit and just focus on writing the user's guide.  Sunday I plan to release the next version: 0.2.0 but this time, it won't just be on omnimaga.  I'll be releasing it on ticalc.org as well as several other calculator forums to expand interest in the project.  So this will be a very big release.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 07:40:56 pm
Unless you are alerady doing so in reply to my other post asking so in the other thread, could you clarify how the pic absorbing feature would operate? Would it let us split 8x8 pics into individual tiles, sorted from left to right and top to bottom, compiled inside the program as data? That would be nice.
Title: Re: Features Wishlist
Post by: Raylin on April 15, 2010, 07:49:21 pm
That on top of the different dimensions for sprites and the DrawShape command.

(I'm going to keep bugging you about that.)
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 07:53:13 pm
It will work like this:

[Pic1]->Pic00 Will read the pic from RAM and copy it into the program.  Stores the pointer to the start of the data into "Pic00"

You can even chain it with regular hex:

[01AF3BPic1B10000]

The pics are NOT stored as a bunch of 8x8 sprites.  Its an array of 12x63 bytes.
Title: Re: Features Wishlist
Post by: Raylin on April 15, 2010, 07:55:05 pm
What's the command?
Or will it be something the Parser itself picks up?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 08:41:28 pm
It will work like this:

[Pic1]->Pic00 Will read the pic from RAM and copy it into the program.  Stores the pointer to the start of the data into "Pic00"

You can even chain it with regular hex:

[01AF3BPic1B10000]

The pics are NOT stored as a bunch of 8x8 sprites.  Its an array of 12x63 bytes.
Aaah ok.

In future versions, will there be a command to store the pics as bunches of 8x8 sprites? It might come handy since it would be considerably faster than any other way
Title: Re: Features Wishlist
Post by: Quigibo on April 15, 2010, 09:42:23 pm
Actually, that would be kind of useful.  So most likely, yes. I guess that's what r is for :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 15, 2010, 10:04:48 pm
YAY! Because personally it would be much faster doing so.

Plus, as several people here are used to Omnicalc, xLIB, CODEX and Celtic, we're also used to displaying sprites stored in pics, one after each others. It's so much easier to edit
Title: Re: Features Wishlist
Post by: _player1537 on April 16, 2010, 06:54:51 am
I'm not sure if this has been asked, but what about a line( routine, will we have that soon?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 16, 2010, 09:58:40 am
Yeah it's coming soon it seems. There will also be circles and rectangles, according to the updated first post
Title: Re: Features Wishlist
Post by: _player1537 on April 16, 2010, 04:34:11 pm
woops, forgot about the first post being updated
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 16, 2010, 06:32:16 pm
no problem :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 05:51:56 pm
Question:

How would somebody go about copying the entire content from an archived appvar/program into another, or parts of it? If for example, someone has a game with a lot of map data and it is spread between 3 appvars of about 7 KB each, currently, he has to use the Unarchive and Archive commands. However, in some cases, there would be a lot of archiving going on and loads of archiving means loads of defragmenting needed, wearing out both the player's set of batteries very fast and their Flash ROM as well (which happened to people, before, such as our last year TI-BASIC contest winner, Drummist).

If it is impossible, I wonder if it would be possible to implement a command that allows you to read bytes from an appvar stored in archive, or at least, something that can copy an entire program from archive into RAM?

For the later, you could ask Iambian if you could use XCOPY source for it if you need someone's routine. It may be useful in the future for people who wants to make slightly larger games (in terms of data, not executable code), but don't want to hinder the user with endless amounts of GarbageCollect messages (and risks of causing the game to crash/exit in improper ways due to him accidentally choosing No). Some of my old BASIC games got some bad reviews because of those.

Quote from: http://web.archive.org/web/20061012201308/www.ticalc.org/archives/files/fileinfo/338/33829.html
[...] Also, since the BASIC game engine is too big to fit in ram, this means that there is quite a lot of archiving going on as you play... so be prepared for garbage collects every six minutes or so.

[...]

Overall: 12/40.
Perhaps on a Silver calculator, this game would be playable, but on an original edition it's just too frustrating to complete, unless you're the kind of person who enjoys spending money on batteries to see them drained by endless garbage collects. If it wasn't for this one point, this game would probably rate “Reign of Legends: at least a 30/40.


There is an ASM RPG called Final Fantasy v1.198 that won't fit in RAM and is split in multiple archived files. It copies the needed data in temporary RAM rather than unarchiving it. I think Desolate requires the data to be in RAM all the time, though.
Title: Re: Features Wishlist
Post by: Raylin on April 23, 2010, 06:10:08 pm
Perhaps that should be a new feature. :D
Title: Re: Features Wishlist
Post by: Quigibo on April 23, 2010, 10:24:50 pm
Reading from archive isn't really that tricky, but it would certainly make the code a lot bigger and require new commands.  You can't just use a pointer; you have to switch pages, store data from that page to a register (temporary variable), switch pages back to the normal RAM, and then save the register into the RAM page at the desired location.  You have to do this for EACH byte or two byte combination you read which means its a lot slower than reading directly from ram.

I think it would really complicate things a lot and it would be about the same speed to unarchive it anyway as it would be to read all of the bytes from archive, although it would definitely be faster for individual bytes.  Putting the calculator in 15MHz mode during archive/unarchives is generally fast enough.  Reading a 6000 byte map by unarchiving would take less than a second to unarchive and especially for RPGs, a little loading bar once in a while isn't that big of a deal since it would never be in the middle of game play.  Just keep the data in ram until its no longer needed.

By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 10:37:55 pm
Well, my biggest issue about unarchiving the map data is that we have to re-archive it after usage. If in the RPG two areas that are linked together are in different files (for example a large dungeon where floor 1 through 4 would be in DARKDNG1.8xk and floor 5 through 7 in DARKDNG2.8xk), then when going back and forth through these areas, there will be a lot of archiving, unarchiving, archiving, unarchiving, archiving, etc, going on, and the player will be annoyed with Garbage Collect messages every 6 minutes or so (especially on a regular 83+ that only has 164 KB of archive). I don't mind archiving speed. Just one little appvar being archived will not even take a second on a 83+. The real issue is the constant Garbage Collecting messages that can take over one minute each.

Here's another scenario:

Player decides that once map finished loading, he needs to go in the menu. He starts holding down ENTER

GarbageCollect?
1: No
2: Yes

What does happen then?

Anyway just a feature suggestions, it's really up to you. Now that I look at your first paragraph, it seems like it may be more trouble than anything else x.x

I could maybe just have a warning during loading saying
"LOADING MAP
 PLEASE DO NOT HOLD ENTER!
 IF A GARBAGE COLLECT
 MESSAGE OCCURS, CHOOSE YES!
 ELSE THE GAME MAY CRASH!"

Or put it in readme altough people may miss it
Quote
By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.
Thanks for the trick. Question, though: when it comes time to exiting, do we need to run special commands to delete temporary data before unarchiving the program again? (so there's enough user RAM to unarchive it)
Title: Re: Features Wishlist
Post by: Quigibo on April 23, 2010, 10:42:56 pm
I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 23, 2010, 10:56:33 pm
I am pretty sure if you archive stuff and there's not enough big enough free sectors available in archive that the GC message will pop up (providing you use the TI-OS routines/ROMcalls to archive/unarchive). The TI-83 Plus guidebook actually explains a bit about sectors. I am pretty sure BrandonW could maybe confirm this but he seems inactive lately
Title: Re: Features Wishlist
Post by: mapar007 on April 24, 2010, 04:49:37 am
I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.

I think you can trigger them in a call to _Arc_unarc, but I'm not sure. Anyway, I don't think the OS does 'sneaky' GC without warnings.
Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 09:30:05 pm
I'd like to ask about library files now.

First of all, I think they will be handled slightly differently than regular source files.  Their header will be in lowercase to distinguish them, and they won't show up on the compiling list to reduce clutter since they're never compiled standalone anyway.  The libraries will basically just be a big list of subroutines that can be called from the main program.

Next thing is how to reduce naming conflicts since the labels are only 2 letters.  Although I plan to eventually allow labels up to 8 letters, right now there is a high chance for duplicate labels, especially if there are multiple library files included in the main program.  To avoid this, I am thinking of having a prefix for the subroutines like this: sub(prgmMYLIB,DW) will call the subroutine "DW" from the "prgmMYLIB" library.

The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.  That means if a library has 25 different routines, but you're only using 5 of them, only the 5 that you use get put into the program.  There is going to have to be some slight restrictions to the subroutines however, mostly, they cannot allocate data or use regular goto's and sub's, only library subs (including itself).

I haven't written any of this yet, I want to get an opinion first.  Does anyone have any other ideas?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 24, 2010, 09:50:48 pm
mhmm, I'm a bit confused x.x I am not sure if I understand the concept well. What would be the benefit of libraries only including the sub routines you use in your compiled code when compiling a program normally alerady do this?

For example, if I have prgmA and it only contains .B in the code, the compiled version will be 13 bytes large (no-stub). In other words, stuff that is not used is not included, right?

I'm not sure if I get the concept x.x
Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 09:58:09 pm
I am also a bit confused about what you're asking about.  A library is just a list of subroutines.  Like if somebody makes a tile mapper or physics engine or something, then you can call those routines from your main program.  Like if your program was prgmA and you said sub(prgmTM,D) this would call subroutine D (lets say that's a drawing command for the tile mapper) from the tile mapper library.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 24, 2010, 10:10:39 pm
mhmm. Yeah I think I get it about the libraries. I guess they're like subroutines, but external?

I got stuck on the part saying this, though:

Quote
The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.

Since in the case of internal sub-routines, if there's a routine I don't need I just have to delete it altogether (and back it up elsewhere for later use), so there wouldn't be any advantage between using external and internal ones.

If it is unclear, I will probably move on for now, though, because it looks like there's something there that is way beyond my capacities of learning (of the moment) that I may be best waiting later to try to understand (at this point it will most likely be lost among 3 or 4 new pages of posts x.x)

Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2010, 11:46:05 pm
Exactly.  But if someone writes a library, odds are you aren't going to use every single command in that library.  And its a huge hassle to keep track of which ones you use and which ones you don't need.  And what if you delete one but it turns out you need it later on?  In addition, its more organized to have the programs and subroutines in separate files.  Also, it would be a real annoyance to have to do a [Rcl] with someone's code into your main program.  And yet another thing!  You might have several source files that use the same libraries so it could potentially save space and make source files even smaller.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 25, 2010, 01:18:53 am
oh right I guess in terms of code management it might be better to have them external then.
Title: Re: Features Wishlist
Post by: Builderboy on April 25, 2010, 02:39:39 am
Hmmmm Using the program name might be good, although it would be cool to have some sort of Method overwriting like in higher languages :D that way if you are just using external subs to make cleaner code it wont be adding all this extra memory into the source

oh and what about the little E for accessing bits?  Like:

AE2 would access the 2nd bit of A, and you could store the same way?  It makes a bit of sense, since E is powers of 10 in Basic, and Powers of 2 in Axe ;D
Title: Re: Features Wishlist
Post by: calc84maniac on April 25, 2010, 03:41:59 pm
I really don't see why the "get/reset/set bit" commands should only be for constants, because that functionality is already available with the "and", "or", and "xor" commands. It would be incredibly useful to allow getting the Xth bit from the number with optimized ASM rather than having to use a For loop every time. Of course, using constants should still be auto-optimized like you were planning.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 01:19:05 am
Question, in the future, will there be a command to draw white lines?

(I guess an alternative for games where the entire gameplay screen is black could be to XOR the graph buffer, draw the lines then XOR it again, though :P)
Title: Re: Features Wishlist
Post by: Builderboy on April 26, 2010, 01:45:13 am
Lol, that would be an interesting workaround ;D I think there should be an alternitive 5th argument like in Basic that allows you to draw different 'Colors'

0:White
1:Black
2:Invert

and maybe others depending how greyscale is planning to be implemented.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 01:51:11 am
mhmm invert might be cool too, actually
Title: Re: Features Wishlist
Post by: Quigibo on April 26, 2010, 02:01:35 am
Yeah, that's actually exactly what I'm planning.  That's how the MOS routine works, so that would make the routines compatible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 02:22:20 am
Cool ^^

And good thing I just checked the first post, I was gonna ask if circles/squares were for next release (or close) x.x

One question, though:  what do you mean by binary support? Do you mean individual bit manipulation?

I'm also glad you're adding tilemap absorbing support. It will make it MUCH easier to insert tiles in a game.
Title: Re: Features Wishlist
Post by: Builderboy on April 26, 2010, 10:58:55 pm
Seeding the random number generator! ;D Simple but potentially useful

Seed->Rand
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 26, 2010, 11:38:49 pm
lol. Well we could do this in BASIC, kinda :P

Title: Re: Features Wishlist
Post by: Quigibo on April 26, 2010, 11:47:37 pm
Binary support means all of the above.  Individual bit operations as well as a new number representation.

The only problem with tile mapping though is that you have to add the entire picture even if you only add a couple tiles.  Also what do I do about the last row of tiles?  Since pic vars are only 96x63, do I just assume the bottom bits are all zeros or do I ignore that whole row of sprites?

Random seed generation is not possible like basic becasue the random numbers have a real randomness factor to them that prevents any predictability with a given seed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 27, 2010, 12:32:32 am
I would just totally disregard the last row of tiles. It's gonna cause more problems than anything else anyway since so few ppl will use xLIB to store pics (which allows the usage of the 64th row). When trying to display a sprite from last row using a pic that only has 63 rows stored results in garbage at the bottom of it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 04:43:57 am
Question: In future versions of Axe Parser, will it be possible to import archived pics/tilepics?
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 08:01:50 am
I have a suggestion: could Horizontal be extended to allow scrolling 1 byte at a time instead of just 1 bit? I would think such code would be more optimized than 8 single-scrolls.
Title: Re: Features Wishlist
Post by: calc84maniac on May 04, 2010, 08:14:04 am
I have a suggestion: could Horizontal be extended to allow scrolling 1 byte at a time instead of just 1 bit? I would think such code would be more optimized than 8 single-scrolls.
I think that can be done with tricky use of the conj( operator.

conj(L6+1,L6,767 should scroll the screen left one byte, I think.

Quigibo, when I tried optimizations like this before, I noticed that there is no way to generate a LDDR to copy from a lower to a higher overlapping area.

Edit: Oops, changed to L6
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 11:30:37 am
I didn't know Horizontal scrolled only 1 bit at a time? o.o

In Axe Tunnel, it always seemed to scroll 1 pixel every frame for me

EDIT: Confirmed that Horizontal and Vertical both scrolls pixel by pixel.
Title: Re: Features Wishlist
Post by: Quigibo on May 04, 2010, 12:21:14 pm
Hmmm... that might be useful calc84, I think I will add conj()r to copy data from one place to another backwards where the bytes at the end get copied first and bytes at the beginning get copied last.

Not sure if I will add 8 pixel scrolling.  You can do it with other commands like calc84 mentioned, and usually when you have 8x8 tiles without smooth scrolling, you redraw them on the screen every frame anyway.

Scroll right by 8:
conj(L6+1,L6,767)
Scroll left by 8:
conj(L6+766,L6+767,767)r (not in 0.2.2)
Scroll up by 8:
conj(L6+96,L6,672)
Scroll down by 8:
conj(L6+672,L6+767,672)r (not in 0.2.2)

Not 100% sure if these are correct, but this is the strategy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 12:25:26 pm
Oh wait I forgot one bit for horizontal is an entire pixel... disregard my comment, then x.x

Do you think importing tilemaps/pictures from archive will be available in the future?
Title: Re: Features Wishlist
Post by: Quigibo on May 04, 2010, 12:30:20 pm
Yes, definitely.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 02:03:46 pm
Are you running down the Features list in order?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 02:17:42 pm
Glad to hear ^^

Oh and I also forgot, for Text(, will it eventually be possible to do something like

Text(X,Y,"HELLO"

(as for now this gives a ERR:BAD SYMBOL)

? Because it seems like a major PITA to have to store everything in memory to be able to display menu choices and if I decide to store all the text at one pointer, I still can't figure out how to display only parts of a string. ???
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 02:20:42 pm
^++
Agreed and seconded.
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 05:26:56 pm
Could the Pxl and Point commands be extended for drawing to the back-buffer? Could be useful for grey-scale.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:29:52 pm
mhmm sounds like a good idea actually. Maybe Pxl-On(X,Y)r[/sub] ?

That said I think he's planning to implement automated GS in the future, but your idea might be useful when we want to update individual parts of the screen like when a door is opened.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 05:47:17 pm
Pt-On(X,Y,PIC)r
Pxl-On(X,Y)r

AWESOMENESS!

The function of said commands can vary but I like the drawing to the back buffer idea.
Perhaps for greyscale?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:49:06 pm
yeah grayscale is what I thought

Used with Dispgraphr

Btw dispgraphr can also be used for sprite animation (you need to use DS<())
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 05:51:45 pm
Yeah.
That sounds awesome.

Also, I was looking in the PRGM menu for once.
Did you know there was a OpenLib() command and an ExecLib command?

Perhaps these could be used for the supposed Axe libraries?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 05:53:12 pm
these are 84+ only. Using them will cause the program to no longer be compatible with the calc most people use: the 83+
Title: Re: Features Wishlist
Post by: SirCmpwn on May 04, 2010, 06:11:08 pm
DJ is right.  The only library I know of that uses them right now is USB8X, which only works on models with a USB port anyway.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 06:17:52 pm
I understand.

Ah well.
Back to waiting for that geometry drawing.
Title: Re: Features Wishlist
Post by: calcdude84se on May 04, 2010, 06:21:48 pm
Yeah, nobody ever really made use of that feature.
Title: Re: Features Wishlist
Post by: Raylin on May 04, 2010, 06:22:26 pm
What is it used for anyway?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 04, 2010, 07:34:31 pm
This page seems to have some stuff related to those commands: http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:9B80

Title: Re: Features Wishlist
Post by: calcdude84se on May 05, 2010, 07:43:26 am
Actually, extension of all drawing functions to the back-buffer would be nice...
Title: Re: Features Wishlist
Post by: Quigibo on May 05, 2010, 02:06:07 pm
Yeah, I'm definitely going to be working on the grayscale commands this version.  What that means, is that every drawing command will eventually be able to draw to either buffer.  So if you want to draw a grayscale sprite, you first draw the black part to the first buffer and then the gray part to the second buffer.  Like this:

:Pt-On(X,Y,Pic1)
:Pt-On(X,Y,Pic2)r

However, just to save space, I am going to have the grayscale drawing and the regular drawing use the same routine, but just jump into the code with a different buffer.  This will unfortunately make the current drawing routines about 5 bytes larger even when you don't use grayscale, but it makes it much smaller when you do need it.  BUT, I might also share all the different sprite drawing routines with each other so that might actually reduce the size if you use different drawing methods in the same program.  I'm not 100% sure what is going to happen, but I will try to make them take the least amount of space possible.

I am also going to test a very limited and special case of look-ahead parsing for pointers.  I am estimating it will reduce executable size by about 2-5% in programs that use pointers frequently.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 05, 2010, 02:07:31 pm
would these new grayscale commands me kinda automated?

Also I think there may be a problem with tile importing. I'll try posting the code later if I can't seems to figure out if I did something wrong. I am fairly certain I did everything right. (tile data appears to be off completly) - EDIT: nvm there was a typo in the code x.x
Title: Re: Features Wishlist
Post by: Runer112 on May 05, 2010, 10:01:42 pm
I noticed you added conversion from binary to integer with 0.2.2, which is getting closer to bit manipulation, but are you planning to release more direct bit manipulation commands? Such as commands that get or set the nth bit of a byte? If not just say so, so I'll know to just make commands for that myself.
Title: Re: Features Wishlist
Post by: Quigibo on May 06, 2010, 03:22:23 am
I'll be adding it soon, I'm still looking for a good token for it...

DJ, I was at first thinking of making the revised drawing commands draw to both buffers, but I think it will be more flexible to do it separately.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 06, 2010, 08:17:17 pm
Mhmm I see, I guess it might be best maybe, and more flexible for the programmer, too. It's good to give him freedom, otherwise the command may not be used very much.
Title: Re: Features Wishlist
Post by: ztrumpet on May 06, 2010, 08:18:32 pm
I'm glad you're adding in both Asm-related and Basic-related commands.  Axe is going to be the best of both worlds! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 10, 2010, 02:42:42 pm
Not much of a feature addition request, more of a feature preservation request:

At the moment, Axe Parser compiled programs will run on both 6 and 15 MHz calcs at once. Even if you use the Full command, your program will still run on a 6 MHz calc fine. It will just run at different speed between each calc speeds.

I would like this cross-compatibility to not be removed in future versions of Axe, else it will suck to be forced to update two versions of your programs all the time because one crashes on 15 MHz calcs and the other crashes on 6 MHz calcs.

Same goes for TI-Nspire and the 48KB RAM TI-84+ calcs, altough I think compatibility with those was planned to be kept.
Title: Re: Features Wishlist
Post by: Raylin on May 10, 2010, 03:21:48 pm
The only thing I would want is the ability to have different sprite sizes.
Title: Re: Features Wishlist
Post by: Galandros on May 13, 2010, 05:11:36 pm
Flags support in Axe Parser could bring advantages in any circumstance? In assembly the use of iy is expensive, so I doubt it is advantageous.

I wish we had a small font TI-BASIC editor on calculator...

Axe Parser syntax takes some time to get used too because of using the TI-BASIC tokens and tokens are not always very descriptive. I imagine it is getting harder to choose the tokens.
Title: Re: Features Wishlist
Post by: calcdude84se on May 13, 2010, 05:17:29 pm
I wish we had a small font TI-BASIC editor on calculator...
I'm not alone, then. It would especially useful for things like ASM on-calc (beside Axe), since lines can get a bit long.
Edit: Sorry for the off-topic post. Here's a feature wish: it would be nice to be able to copy data from Archive to RAM, since Unarchiving and Archiving again puts wear and tear on the RAM.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:18:40 pm
I imagine it is getting harder to choose the tokens.
It is, when I suggest him new features via chat, he often comes up with "I would like to add this, but I would need to figure out a good token to use :P"
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 05:20:14 pm
Can we have a sign command that would return the sign of a number.  Like this:
sign -9 = -1
sign 9 = 1
sign -9001 = -1
sign 9001 = 1
sign 0 = 0
You could use the [2nd] [sin] button.

Is it possible to easily do this in Asm, or would it be the same as ( # > 0 ) - ( # < 0 ) ?
Title: Re: Features Wishlist
Post by: calcdude84se on May 13, 2010, 05:22:33 pm
just read the high bit, which carries the sign, and then differentiate between positive and zero.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:33:18 pm
I can't wait until Axe Parser supports reading/writing to individual bits
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 05:37:52 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 13, 2010, 05:53:00 pm
Yeah I know, I checked WikiTI for most of the addresses. Not sure how it would help for binary stuff, tho :P
Title: Re: Features Wishlist
Post by: Builderboy on May 13, 2010, 08:54:07 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)

Bits not bytes ;) Yeah I cant wait for this either :) It will make a few things quite usefull.
Title: Re: Features Wishlist
Post by: ztrumpet on May 13, 2010, 09:00:57 pm
DJ, you can substitute your own addresses instead of L1 - L6 if you want.  L1 - L6 are just numbers after all. :)

Bits not bytes ;) Yeah I cant wait for this either :) It will make a few things quite usefull.
Gah, my bad. :)  Now that I've read 'bits', I really want this to happen too.  It'll be fun to manipulate stuff in binary! ;D

Technically, you could use calculations to do this with the 'pixel' commands, but it would be a lot of useless calculations. ;D
Title: Re: Features Wishlist
Post by: Builderboy on May 13, 2010, 09:07:00 pm
You can also do it with some loops or lookuptables coupled with AND and OR commands, but its a hassle :P
Title: Re: Features Wishlist
Post by: _player1537 on May 13, 2010, 09:45:43 pm
I use 'and 1' or any other number to do this atm.  iirc there is an asm command like 'set 4,(1337)' or something like that.
Title: Re: Features Wishlist
Post by: Quigibo on May 14, 2010, 12:49:09 am
Just curious, would it be useful to set and get exact bits in the 2 byte number?  Like "get the 11th bit" and "set the 2nd bit" or is it more useful to have the Nth bit with N being variable?  Unfortunately, these routines with variable bits are kinda big.  Big enough where they wouldn't be inline like the constant bit checking and I would make it a subroutine to save space.

I might be able to do both, but I'll have to come up with some clever syntax.

By the way, I just coined a new term: "Axe Hax" for clever exploits of Axe commands. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 14, 2010, 01:07:58 am
mhmm not sure what you mean x.x sorry :(
Title: Re: Features Wishlist
Post by: calc84maniac on May 14, 2010, 01:44:10 am
You could optimize the AND/OR that will reset/set a single bit to a simple 2-byte RES/SET opcode. That way you won't even need extra tokens for constant bit commands.
Title: Re: Features Wishlist
Post by: _player1537 on May 14, 2010, 04:56:12 pm
hmm, could this even be remotly possible:
having a way to change the macro ourselves, ie I like using the "And/Or/Xor" commands bitwise.  I personally always use them this way and use them a lot like this.  If you compiled the new phoenix/raven game I'm making with the new version it would completly fail when running it. 
Title: Re: Features Wishlist
Post by: Quigibo on May 14, 2010, 07:44:45 pm
Those commands are still there, but they've just changed syntax.  It makes the code more readable too because now you're using and/or/xor as single character operators just like addition, subtraction, multiplication, and the others.
Title: Re: Features Wishlist
Post by: _player1537 on May 14, 2010, 10:25:50 pm
sorry, but what do you mean by single character operators?  and the main reason I'd want to change the syntax is because otherwise I'd have to change a ton of source for my program, and its harder to get to the new and/or/xor characters
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 12:16:59 am
By the way, the standard and/or/xor still work as bitwise functions as long as the numbers you're dealing with are both single bytes.  Only the double byte numbers require the new syntax.

What I meant by single characters is that it is more readable to write: "A*B" than it is to do "A times B"
Similarly, "A&B" is easier to read than "A and B" (the ampersand is not the actual symbol, I'm just demonstrating)
Title: Re: Features Wishlist
Post by: Raylin on May 15, 2010, 10:18:19 pm
Just a thought:

IIRC, Axe compiles all the code and skips all the data on the first pass. Then, on the second pass, it appends all the data to the end of the compiled program, creating space as it sees fit. What if these commands were made:

FnOn -  Activate BASIC command mode.
FnOff - Deactivate BASIC command mode.

Here's where my idea comes in.
What if Axe made three passes? The first pass would check to see if there are any FnOn or FnOff commands in the program, skipping everything else. The second and third passes would be the normal Axe compilation.

For example:

First Pass:
Check for any FnOn and FnOff commands. If so, save that line and skip over all code until the end of the program is reached or the FnOff command is reached.

Second Pass:
Compile programs.

Third Pass:
Append data.

So, penultimately, the program code is the ASM version of this.

Code: [Select]
:Asm(prgmAXE1
:<TI-BASIC code>
:Asm(prgmAXE2
 

tl;dr: Axe should compile subroutines and insert them into a large ASM program if BASIC commands are possible.

Of course, all of this is useless if Quigibo figures out a way to reuse commands for different purposes.
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 10:43:08 pm
I doubt I'm going to have a "Basic Mode".  Its more likely that BASIC programs will be token data just like strings are text data and sprites are hex data and then there will be a command to execute that data.

fnOn and fnOff are the enable and disable interrupts commands since there is also the fnInt command and they just go together so perfectly for this.
Title: Re: Features Wishlist
Post by: Raylin on May 15, 2010, 10:48:10 pm
Interesting.
How will hybrid programs be handled?
Title: Re: Features Wishlist
Post by: Quigibo on May 15, 2010, 10:49:31 pm
I don't even know if its possible yet, so we'll see what happens when I get to that.
Title: Re: Features Wishlist
Post by: Raylin on May 16, 2010, 10:27:23 pm
Also...

The idea of custom fonts was brought up. [Personally, I think it would be very memory-intensive.]

This as well as the idea of sprite rotation by any angle. [I think that was brought up before...]

Also, SortA(), SortA()r, SortD(), SortD()r.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 18, 2010, 08:06:34 pm
Sort command would be nice

Something like

SortA(Pointer,Bytes

For example, if you did SortA(L1,27), it would sort the first 27 bytes of pointer L1 from lowest to highest number.
Title: Re: Features Wishlist
Post by: Quigibo on May 19, 2010, 12:00:19 am
Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 19, 2010, 12:06:57 am
Wow that's quite fast. The TI-BASIC Sort( commands takes two seconds to sort 100 elements on a regular 83+ and one second on a 83+SE/84+

And glad to see you're planning on adding Ans support. It will be very useful for people who make Axe games divided into multiple programs or libs for BASIC programmers.

Keep up the good work!

Btw next version will be 2 pages, right? I noticed the previous version was getting pretty close
Title: Re: Features Wishlist
Post by: Quigibo on May 19, 2010, 12:19:02 am
Don't know yet, but I haven't started optimizing the parser itself, so I think I can make it small enough to fit on one page, at least for the next couple updates.  Probably 0.3 will be the time when I switch to a 2 page app.  However, the parser will not be larger than 2 pages at any point.  If I want to add a suite of helper programs, I will add it as a separate optional app.
Title: Re: Features Wishlist
Post by: Raylin on May 19, 2010, 06:13:41 am
Strings?
You plan on putting restrictions of the static pointers?
Or are you making entirely new variables?
Title: Re: Features Wishlist
Post by: calcdude84se on May 19, 2010, 07:24:02 am
The TI-Basic variables, if I understand it correctly
Title: Re: Features Wishlist
Post by: Raylin on May 19, 2010, 07:34:50 am
Yeah, but the static pointers already take up the namespace for the variables.
How will he implement them?
Title: Re: Features Wishlist
Post by: calcdude84se on May 19, 2010, 07:42:22 am
Probably the same way appvars are: with storage into strings.
You'll have to ask quigibo for how he actually plans to do it, but it seems you'd have something like:
"Str8"->Str1
If GetCalc(Str1)->X
{X-2}r->S
X+S-1->E
For(A,X,E
Disp {A}->Frac
End
End
Disp i
Which would display Str8's contents on the homescreen, or nothing if non-existent/archived.
Title: Re: Features Wishlist
Post by: ztrumpet on May 19, 2010, 07:20:13 pm
Yeah, I've got that working already now, except there's a really weird bug I'm trying to fix.  The actual sort routine is very small and fast, its only 21 bytes and sorts a 256 element list in about 1/4 of a second in 6MHz mode.  I'll probably make it larger though to handle sizes greater than 256.  I'm using insertion sort.

By the way, the main focus of the next version will be on variables.  I already have Ans saving and loading working, I expect to have strings, real variables, Picture files, and other things like that all readable and writable.  And I'm also going to add the ability to create programs.  It's possible some existing syntax might change but that seems unlikely at the moment.
Awesome!  I'm going to like these new commands. ;D

calcdude: Excellent visual. :D
Title: Re: Features Wishlist
Post by: Raylin on May 23, 2010, 11:15:15 am
-Linking
-SortA(),SortD()
-Geometry drawing (circles, squares, etc.)
-Interrupts
-xLib DRAWSHAPE
-Application Compiling
-Sprite sizes larger than 8x8
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 07:58:47 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.
Title: Re: Features Wishlist
Post by: ztrumpet on May 25, 2010, 08:02:09 pm
How will interrupts be handled in Axe?  It seems they would be very complex...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 08:04:58 pm
Interrupts would be nice for automated stuff, such as moving enemies, but I wonder if it wouldn't be a bit hard to work with and easy to mess things up?
Title: Re: Features Wishlist
Post by: Raylin on May 25, 2010, 08:19:39 pm
Actually, it could be really easy.

im 2 sets the calculator in a mode to accept a different interrupt routine.
Since Axe can already edit and use programs themselves, couldn't Quigibo just make a command to look for and run a custom program? From there, the compiler can absorb that custom routine as part of the entire program.

I think...
Title: Re: Features Wishlist
Post by: Quigibo on May 25, 2010, 11:09:38 pm
Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 25, 2010, 11:23:50 pm
Mhmm, doesn't sound like a good deal x.x

Personally I don't use L1 that much but I imagine I will when I work on stuff with arrays and the like
Title: Re: Features Wishlist
Post by: Eeems on May 26, 2010, 12:13:38 am
D: well...i guess i could give up part of L1 for interupts...ill just have to learn how to compress my data.
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 12:21:52 am
It will only be taken up when you turn interrupts on though right?  So those who dont use them wont have to give up or mem :3
Title: Re: Features Wishlist
Post by: calcdude84se on May 26, 2010, 07:22:30 am
A custom interrupt sounds nice. That's obviously in im 2. Will the choices for interrupts in a program be either im 1 or im 2, or will you be able to disable them entirely or chain the standard interrupt to the end of the custom one?
Or, to put it more simply, how many choices do you get?
Title: Re: Features Wishlist
Post by: ztrumpet on May 26, 2010, 07:56:10 am
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Title: Re: Features Wishlist
Post by: TIfanx1999 on May 26, 2010, 10:20:54 am
Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.
That sounds really cool actually! =D That'll be fun to play with once you get around to implementing it. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 12:22:03 pm
If interrupts are implemented, I think the command index should be updated well before with enough explanation about what to do and what to not do, in details and maybe an example of what it could be used for, since it seems a bit complicated to use and might cause many people to accidentally cause a RAM clear more.

Also, I heard somewhere that interrupt speed varies when batteries are lower. Is it true?
Title: Re: Features Wishlist
Post by: Galandros on May 26, 2010, 01:38:35 pm
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Not that easy because the vector table has to be aligned in memory like every byte between $9900 and $99FF. And I think it is 257 bytes for some strange reason.
Title: Re: Features Wishlist
Post by: ztrumpet on May 26, 2010, 05:16:13 pm
That sounds neat!  Could you just append 256 bytes to the end of the program and use those as the vector table?  I like how it sounds so far. ;D
Not that easy because the vector table has to be aligned in memory like every byte between $9900 and $99FF. And I think it is 257 bytes for some strange reason.
Ah, okay. :)  How does this work, because wouldn't part of the program normally be there?
Thanks! :D
Title: Re: Features Wishlist
Post by: calcdude84se on May 26, 2010, 05:51:04 pm
yeah, it could be, but it would have to 256-byte aligned, like Galandros said. You're looking at a 257-513 byte increase in program size. The table would be where he said or between $9A00 and $9B00, $9B00 and $9C00, or so on.
It's 257 bytes because the i register, or the interrupt vector, serves as the high byte of an address where the lower byte is essentially random. (It has some structure, documented in AsmIn28, but I can't remember it). Because the read address could be anywhere between $xx00 and $xxFF, you need another byte to complete the two bytes it reads in case it reads from $xxFF.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 06:39:20 pm
Interrupts + SinReg() = BGM music?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 08:19:32 pm
is there a way to control the speed at which an interrupt is executed compared to the rest of the program? Otherwise I think sound might slow the game down way too much
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 09:25:07 pm
I would think not...
I don't know for sure.

In Axe, the interrupt's speed may or may not be affected by the Full command.

[ontopic]Geometry drawing (read: xLIB DRAWSHAPE)[/ontopic]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 09:28:50 pm
Mhmm Raylin you suggested this command about 4 times already. I think it is becoming clear it is not in his priorities since all you need to do is use Line() (altough I think this is larger). By now it is in his planned features I am certain
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 09:52:38 pm
I am only pestering because of the lack of inverted rectangles (which I use extensively).
I need inverted rectangles.

They are like drugs to me.
I NEED THEM.

Perhaps a Line()r for inverse? Or is that reserved for the back-buffer?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 10:26:02 pm
I think this will be for the back-buffer.

For inverted rectangles, do you mean white outline with filled black?
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 10:31:19 pm
I mean, real(12,8).

That means draw a rectangle and invert all the pixels inside.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 10:44:13 pm
I think that could be possible to do through a routine like I posted in the other thread, but I would need to think about a way to make sure it's fast enough
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 10:45:27 pm
well for using filled rectangles, you could always have a subroutine that does a lot of pixelChanging in 2 For loops.  I think that might be a bit slower than an alternative however...  Let me see if i can come up with a quicker version.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 10:47:02 pm
Woot. Many thanks, Builderboy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 11:11:07 pm
Yeah pixel changing is what I thought about. However, thiswould be slow. If your rectangles were multiples of 8, you could just use a bunch of 8x8 sprites
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:12:01 pm
Alright here is a super fast filled inverting recangle thingy.  It does use a fair number or variables though, if thats a problem you can always use memory locations instead.  So here is the code (its rather long)

Code: [Select]
Lbl RC
A^8->O
255->M
While O
M/2->M
O-1->O
End
C^8->O
255->N
While O
N/2->N
O-1->O
End
A/2/2/2->A
C/2/2/2->C
For(F,B,D-1
F*12+L6->J
{J+A} xor M->{J+A}
{J+C} xor N->{J+C}
For(G,A+1,C
{J+G} xor 255->{J+G}
End
End
Return

Its very fast, but if you want something smaller, you can use this:

Code: [Select]
Lbl RC
For(F,A,C-1
For(G,B,D-1
Pxl-Change(F,G
End
End
Return

For both, the input is A,B for top left corner and C,D for bottom right corner.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 26, 2010, 11:15:45 pm
Oh right forgot about L6 x.x

I guess that could work, as long as Raylin isn't running low on memory, because that looks like it will compile pretty large
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:19:27 pm
It compiles to about 350 bytes on my calc, so not too bad.  But like i said, if memory is absolutely a problem, you can go with the pixel change option, which is only 170 bytes.
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:21:04 pm
By memory locations, you mean something like {L1+X} or...?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:26:04 pm
Right, you would replace all the F variables with {L5+1} for example (although i dont think you can use them in for loops D:) and then choose a different location for each variable
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:44:06 pm
Timings?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:47:02 pm
What are you asking?
Title: Re: Features Wishlist
Post by: Raylin on May 26, 2010, 11:55:13 pm
How long do the routines take?
Title: Re: Features Wishlist
Post by: Builderboy on May 26, 2010, 11:59:31 pm
no idea, and i dont have any accurate way to time them since axe doesnt have any timer support.  You would try them out and see though.  For the loop method (the second) it takes about a full second to invert the screen though, while the first one does it almost instantly.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 02:29:20 am
Feature wishlist (unless already planned:)

-A new Axe Parser APP option to get rid of the scrolling when an error is found and you press PRGM to see where is the error located. In other words, an "instant Goto" feature. (like in DoorCS)

That might come handy for large programs. Otherwise having to wait one minute until the scrolling is done everytime there is an error can get extremly annoying when debugging
Title: Re: Features Wishlist
Post by: Raylin on May 27, 2010, 07:14:00 am
^++
Agreed and seconded.

Instant Goto debugging feature FTW.
Title: Re: Features Wishlist
Post by: Galandros on May 27, 2010, 07:19:11 am
is there a way to control the speed at which an interrupt is executed compared to the rest of the program? Otherwise I think sound might slow the game down way too much
You can set the frequency at which the interrupt code is called. The slowest is 110 Hz (executed 110 times per second) , I think. But you can for example, increase a counter, save it and if is odd, exit the interrupt and goes back to normal code.
Title: Re: Features Wishlist
Post by: ztrumpet on May 27, 2010, 07:54:17 am
-A new Axe Parser APP option to get rid of the scrolling when an error is found and you press PRGM to see where is the error located. In other words, an "instant Goto" feature. (like in DoorCS)
I think this would be a great option as well. :D

Builderboy, that's an awesome routine! :)
Title: Re: Features Wishlist
Post by: calcdude84se on May 27, 2010, 07:58:59 am
I agree that instant goto should be added. Axe just keeps getting better...
Title: Re: Features Wishlist
Post by: SirCmpwn on May 27, 2010, 09:54:46 am
I want to request a feature...
How about jumping to the address in a variable?  Such as Goto {A}, for instance, would jump to A.
And you could have something like [LB]->A to store the address of Lbl LB to A.  This would be useful for jump tables, which is something I really want :)

Also, user access to the stack would be nice as well.  I would really like to be able to push a variable onto the stack, then pop it off later.
Title: Re: Features Wishlist
Post by: ztrumpet on May 27, 2010, 10:26:17 am
I like both of those ideas!  Can you add these in Quigibo? :D
Title: Re: Features Wishlist
Post by: Quigibo on May 27, 2010, 01:22:20 pm
I want to request a feature...
How about jumping to the address in a variable?  Such as Goto {A}, for instance, would jump to A.
And you could have something like [LB]->A to store the address of Lbl LB to A.  This would be useful for jump tables, which is something I really want :)

Also, user access to the stack would be nice as well.  I would really like to be able to push a variable onto the stack, then pop it off later.

Both of these things are features I am purposely not adding.  The variable goto isn't really used that much in regular assembly and has very limited application.  Its also very easy to screw things up by accidentally jumping to the wrong place and completely messing up the calculator.  I am trying to make it as safe to use as possible, and this is really just an unnecessary danger.  You can do this with a 2 byte assembly code if you really need it.

Pushing and popping into the stack has the same problem.  If you push a variable in a subroutine for instance, then the subroutine cannot return and the program crashes becasue it jumps to the wrong location.  Also, forgetting to pop can lead to stack overflows which are also not good.


The instant goto I'd like to add, but I don't even have the regular goto error working yet so I don't even know how it would be done.  I can do a similar "faking it" sort of thing where it just displays the error instead of going into the editor I guess.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 01:28:16 pm
If you don't use the editor, would that require you completly code an entire BASIC code (well... Axe) viewer like Builderboy did? If so, then I guess it might be best to disregard the instant goto feature or wait completly at the end of development before attempting at adding it (to make sure you have enough space left, assuming such thing would take a considerable amount of memory in the APP)
Title: Re: Features Wishlist
Post by: calcdude84se on May 27, 2010, 05:28:57 pm
I managed to come up with a feature request. The sprite routines seem somewhat incomplete, only including OR, XOR, and full clear followed by OR (Pt-On, Pt-Change, and Pt-Off, respectively).
My two suggestions are:
add something corresponding to AND, or add a command to use two layers specifying what is cleared followed by what is OR'd
The second, though somewhat less useful one is: Allow sprite commands (except for Pt-Change) to have an extra argument (not required) that would save what's about to be written over. Basically creates a back-copy for later restoration, presumably when the other sprite moves.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 27, 2010, 11:15:53 pm
AND would be nice for sprite masking.


For the second one, do you mean so we don't have to redraw the entire screen (or everything surrounding moving sprites) when stuff moves and instead we just redisplay what was behind the sprite? It sounds like it could be a nice feature.
Title: Re: Features Wishlist
Post by: Quigibo on May 27, 2010, 11:55:00 pm
That's what backbuffers are for so you don't have to save it every time you draw the sprite.

The AND thing I guess I can see how it would be used... but then you have to use AND followed by an OR to actually get masking.  That's the same amount of steps as doing an OR followed by an XOR (another way of doing masking) so it doesn't really add anything new, just more convenience.  Also, I'm all out of tokens for that.

Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.

Title: Re: Features Wishlist
Post by: TIfanx1999 on May 27, 2010, 11:58:50 pm
Sounds great! Go for it! =D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 28, 2010, 12:09:46 am
That's what backbuffers are for so you don't have to save it every time you draw the sprite.
My concern was more about grayscale. Where on the backbuffer and buffer do you store the area your sprite is gonna walk on to redraw it later after the sprite moved, since both buffer and back buffer are entirely used for the grayscale?

That said it is not a big hurry, though. Seeing how fast

Quote
Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.
Sounds like a good deal. I think it's better to improve the parsing and stuff before adding too many other features, so that makes less features code to change later once you optimize. Also, this would make it less overhelming for people who will participate in the programming contest. Since the contest will most likely only last 3 and half a month (or 4), not having to change our code syntax everytime an Axe update comes out will be very appreciated. (people could just use an old Axe version if they don't want to update their code, but that slows down their development considerably)

Also seeing how much you worked on this despite school and stuff, I think if you want to take a break at one point, you deserve it a lot. :)
Title: Re: Features Wishlist
Post by: _player1537 on May 28, 2010, 12:04:45 pm
yay, this sounds nice I can't wait for app compiling and on-breaks (which I hope will include interupts in general)

666th post in this thread >:D
Title: Re: Features Wishlist
Post by: calcdude84se on May 31, 2010, 09:16:51 pm
true, though it's more troublesome for greyscale, as DJ said. OR followed by XOR? Hmm... never realized that. Will use.
Yeah, the command freeze is a good idea. And as always, keep up the good work!
Title: Re: Features Wishlist
Post by: nemo on June 03, 2010, 04:01:23 pm
will there ever be a way to invert all 64 pixels of a sprite? like if i had a white 8x8 sprite with a black border, and i wanted to change it into a black sprite with a white border, will that be implemented? i know i can use two for( loops to do it with pxl-change(, but i'm wondering if it may be implemented in the future
Title: Re: Features Wishlist
Post by: _player1537 on June 03, 2010, 04:07:56 pm
you can also do "pt-change(x,y,pic22)" with pic22 being [FFFFFFFFFFFFFFFF]  You don't have to use pic22, just an example.  I believe our dear friend made a routine that does this with out using another sprite, but it goes along the same lines of two for( loops...only different
Title: Re: Features Wishlist
Post by: Builderboy on June 03, 2010, 05:58:44 pm
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.
Title: Re: Features Wishlist
Post by: calc84maniac on June 03, 2010, 06:01:01 pm
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.
Just remember that will only work as expected for no-stub programs. If it's for a shell, the sprite will be inverted every other time you run the program, and for an App the sprite wouldn't invert at all.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 03, 2010, 06:45:00 pm
wow didn't knew we could use this. x.x
Title: Re: Features Wishlist
Post by: Runer112 on June 07, 2010, 12:41:30 am
The following is a list of all screen/buffer commands, with the size of the routine indicated in parentheses:

The following is a list of the screen/buffer commands that do not utilize subroutines and the increase therefore in program size if the command is called 1, 2, 3, or n times compared to if it was called using subroutines:

Perhaps you could add an optimization feature that counts the number of references to commands such as these? This would either include the routine inline or in a subroutine that is called multiple times depending upon which method is more size efficient based on the number of times the routine is called.
Title: Re: Features Wishlist
Post by: Quigibo on June 07, 2010, 12:47:03 am
That's actually much more tricky than it sounds.  First of all, I would have to make another pass through the program at the beginning and its not just a matter of counting the tokens.  I have to make sure I'm not including strings, token values, and other uses that don't actually count as code.  I will optimize this eventually once I get long name labels.  The two are kind of related even though they sound like different features.

However, in the mean time, you are free to put them in subroutines yourself if you're trying to save space.

Lbl SP
StorePic
Return
Title: Re: Features Wishlist
Post by: Runer112 on June 07, 2010, 12:48:46 am
Yeah, I've been putting them in subroutines. But it just seemed like the kind of optimization that would be quite helpful to not have to manually do for every program.
Title: Re: Features Wishlist
Post by: Quigibo on June 07, 2010, 12:53:05 am
Well its a balance I try to maintain.  Generally, if its under 10 bytes, I don't make it a subroutine, but if its around 9-12 bytes, then it depends on how rare I expect the command to be.  Any more than that, I always use subroutines.  As I said before, eventually this will be optimized automatically.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 07, 2010, 01:08:15 am
I didn't knew DispGraph was this large o.o

But again I only really used it 3 times per program at most
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2010, 07:25:25 pm
If you ever get around to that optimization based on the number of times something shows up, make sure to hit equivalences or unequivalences too. I just went through and manually replaced things like _=16 (which seems to show up a lot) with _sub(16) which checks =16. Saved like 100 bytes.
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2010, 07:37:39 pm
Well, I don't want to do too many of those.  Even though it reduces the size, it also slows down the program a little each time it has to call a subroutine.  Normally, you don't notice this, but sometimes when you're doing very heavy math (like checking if any objects on one list collide with objects on another list) you can actually notice it.

That's an interesting optimization though.  It would be very difficult to figure out what to group though.  Like if you did _*2+1/8+L1 a bunch of times for instance, its convenient to group that whole operation into a single subroutine.  But unlike a computer compiler, Axe doesn't have large memory or fast speed, unless I use the extra ram pages maybe but it would still be super slow for larger programs, so its really not practical to keep track of all that.  Its going to have to be up to the programmer to do a majority of these optimizations.  There's always the computer compiler idea though...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 08, 2010, 07:59:35 pm
It might be good to leave optimizations where the smallest slows down the program up to the programmer IMHO. Just make sure to keep those possible optimizations as documented as possible.
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2010, 08:03:46 pm
Yeah, at the moment I'm making as many optimizations by putting mathematical or logical expressions used more than once (as long as it's size efficient to do so) into subroutines, because my program is at about 7.5k and I don't mind sacrificing some speed for space (it's a sprite editor after all, no need for speed)
Title: Re: Features Wishlist
Post by: ztrumpet on June 10, 2010, 05:58:00 pm
Can we have a command to store the current contrast to a variable?  For example:
ShadeF(->A
Would put the current contrast into A. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 10, 2010, 06:14:59 pm
Not sure if that was suggested before (I might even have suggested them myself XD):

Horizontal +r
Horizontal -r
Vertical +r
Vertical -r
ANOVA(666)r
Line(X1,Y1,X2,Y2)r

I couldn,t find those in the command list. It would let you scroll the back buffer, ANOVA(666)r would delete the entire calc OS certificate+OS the next time you recall the back buffer and you could display lines on the back buffer. White lines would also be nice, but I'M not sure if it's necessary. I simply do DrawInv, display my line then DrawInv again.
Title: Re: Features Wishlist
Post by: ztrumpet on June 10, 2010, 06:20:32 pm
White lines would also be nice, but I'M not sure if it's necessary. I simply do DrawInv, display my line then DrawInv again.
But white lines would be a lot faster.  I think Quigibo should add both while and inverted lines. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 10, 2010, 07:37:36 pm
yeah maybe. I was just saying in case he never adds them that they could be done that way too.
Title: Re: Features Wishlist
Post by: calcdude84se on June 11, 2010, 12:40:47 pm
zTrumpet: The current contrast is stored at $8447 and is in the range from 0 to 39 (decimal)
Title: Re: Features Wishlist
Post by: ztrumpet on June 11, 2010, 12:49:05 pm
Thanks!  So I'd do {E8447}->A to store the current contrast into A, right?
Title: Re: Features Wishlist
Post by: calcdude84se on June 11, 2010, 01:15:25 pm
yes, exactly. If you want the contrast level from 0 to 9, like when you press 2nd+up/down, a simple division by 4 seems like it would work (I may be wrong, but I think that's right)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 06:18:51 pm
Note that you cannot actually update the screen itself with the new contrast value, though. You need a bit of ASM code for that.
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 09:35:05 pm
I thought Quigibo added the Shade( command for that?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:10:51 pm
I don't think it was tied to the contrast level set in RAM, though. It just directly updated the screen. I could be wrong, though.
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 10:27:59 pm
you cannot actually update the screen itself with the new contrast value
It just directly updated the screen

Sorry, I don't understand what you were trying to say here. Though, if you want to update the OS contrast value so it doesn't "jump" when changing it after the program exits, you can store the new value to {E8447}.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:33:40 pm
In the first quote, I was talking about when you store 00h-27h to 8447h, it doesn't actually change the LCD contrast.

In the second one, I was talking about the Shade command. I thought it actually did the later without doing the former?
Title: Re: Features Wishlist
Post by: calc84maniac on June 11, 2010, 10:35:31 pm
Ah, yeah. Well, I was answering to your comment that you needed ASM code to update the screen.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 11, 2010, 10:52:43 pm
aaah ok that's what I guessed. You needed to update a port or something I forgot (I should check the page on WikiTI again later)
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 09:32:53 am
Yeah, port 10h, with values C0-FF (or, rather, D8-FF, if the values are between 00 and 27 in (contrast))
Title: Re: Features Wishlist
Post by: guy6020665 on June 12, 2010, 12:42:20 pm
I don't know if someone has already requested this but i would really like the "randint(" command because it is beginning to get a bit annoying to put

Code: [Select]
While (A>100) or (A<10)
rand/1000->A
End
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2010, 01:06:14 pm
If you want a random integer between 10 and 100, you should do

Code: [Select]
rand^91+10
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 01:47:42 pm
It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 01:59:13 pm
It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot

To produce a random integer between start and end:
rand^(end-start+1)+start

For example, 1 to 10:
Code: [Select]
rand^(10-1+1)+1
rand^10+1

333 to 666:
Code: [Select]
rand^(666-333+1)+333
rand^334+333
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 02:02:26 pm
is it the smallest syntax, though? I really meant some sort of basic to axe rand converter, even if it means the start/end range is different in the Axe version. Just asking for size reasons
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 02:04:14 pm
What do you mean by "is it the smallest syntax?"

EDIT: If you mean is that the most size-efficient way to produce a random integer in that range, yes.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 02:05:42 pm
I am not sure how to explain it further. Sorry. Could anybody else explain to him for him?
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 02:23:32 pm
Like this?

EDIT: Wait hold on, fixing a bug.

EDIT 2: Attached.
Title: Re: Features Wishlist
Post by: Raylin on June 12, 2010, 02:51:58 pm
Good sir, I don't believe all of those commands in above program work.
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 03:25:07 pm
I didn't look at the program, but those commands listed above have a problem that might annoy some: not all numbers are generated with equal frequency. (Actually, they are if high-low+1 is an integer power of 2, but that isn't often the case)
Why? Let's use 4-bit random numbers, and generate a number between 0 and 2, with something like rand^3 (the Axe is rand^16^3, but whatever)
0: 0, 1: 1, 2: 2, 3: 0,
4: 1, 5: 2, 6: 0, 7: 1,
8: 2, 9: 0, A: 1, B: 2,
C: 0, D: 1, E: 2, F: 0
chances: 0: 6/16, 1: 5/16, 2: 5/16
Note that the maximum effect is at most one more occurrence, though that might be important to you. (If it isn't then the code others gave will work)
Besides trying multiple times (like an optimized version of what DJ had at first), I'm not sure of a way to keep it even... So I hope it isn't too big a bother (it is only slight) Anyone know of a good way to even the probabilities?
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2010, 03:30:06 pm
Well, for 16-bit, you would have:
chances: 0: 21846/65536, 1: 21845/65536, 2: 21845/65536.

There is not enough of a difference to matter, and there isn't really a way to do it better (except by increasing the number of bits, and even then it wouldn't be perfect), because the processor is working in binary.
Title: Re: Features Wishlist
Post by: calcdude84se on June 12, 2010, 03:32:49 pm
Yeah, it shouldn't bother anybody, but just in case :P
Actually, now that I think about it, there really isn't a "perfect" way to do it with a binary computer... Silly me...
Title: Re: Features Wishlist
Post by: Runer112 on June 12, 2010, 03:51:01 pm
Good sir, I don't believe all of those commands in above program work.

See:

It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 12, 2010, 11:29:36 pm
mhmm thanks for that converter program This is what I mean earlier ^^

Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 01:25:53 pm
By the way, are horizontal and vertical lines a feature that will come out in the next version or upcoming ones?

http://ourl.ca/4161/94886

I wonder what syntax it would use
Title: Re: Features Wishlist
Post by: Builderboy on June 13, 2010, 02:55:20 pm
Lol being that Horizontal and Vertical have already been taken.... Seems we have run into a predicament :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 02:59:52 pm
Yeah. Also In the future I assume he'll use Line()r for drawing lines on the backbuffer.

Maybe he could make the parser detect when X coordinates and/or Y coordinates are always identical (for example Line(A,15,A,85)) during parsing), or use Hline( or Vline (H and V being alpha letters of course)
Title: Re: Features Wishlist
Post by: Builderboy on June 13, 2010, 03:02:52 pm
Yeah both of those would be great i think.  Although im not sure how well the HLine() VLine() would work in his current parser, it might be completely token based right now, and hard to change o.O
Title: Re: Features Wishlist
Post by: calcdude84se on June 13, 2010, 03:40:27 pm
Why couldn't Horizontal and Vertical have multiple uses? With a '+' or a '-', they'd rotate scroll the screen (as they currently do). If they have a number/variable/expression after them, they draw the corresponding horizontal/vertical line. Or, as you said, would that not be possible in a token-based system?
Edit: They scroll the screen, not rotate it. My bad.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 13, 2010, 11:00:58 pm
Mhmm actually they don't rotate the screen, they scroll it. We could do Horizontal (X1,X2,Y) and Vertical (X,Y1,Y2). My only worry is that it could eventually get confusing if a token is used for multiple purposes.
Title: Re: Features Wishlist
Post by: calcdude84se on June 14, 2010, 01:54:01 pm
Oops, yeah, I meant scroll... I'll edit that.
True, overloading a token with multiple commands can and will make things more difficult if overdone. A little wouldn't though, right? :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 14, 2010, 02:02:47 pm
Nope, but let's not overload them, else it will get confusing for sure. As for now, none of the commands are used for multiple things, I think. There is getkey but both usages are for similar purposes. THis is why I thought using Line( with a slightly different syntax might be best
Title: Re: Features Wishlist
Post by: ztrumpet on June 14, 2010, 05:44:38 pm
I think that all lines should use the same syntax, but Quigibo would detect in the the parser which routine is best to use and put that in the program. :D
Title: Re: Features Wishlist
Post by: calc84maniac on June 14, 2010, 06:33:30 pm
Suggestion:
Use Line(X1,Y,X2,) for horizontal and Line(X,Y1,,Y2) for vertical.

The empty arguments would tell the parser to use the optimized routines.
Title: Re: Features Wishlist
Post by: Quigibo on June 14, 2010, 10:18:55 pm
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
Title: Re: Features Wishlist
Post by: SirCmpwn on June 14, 2010, 11:02:30 pm
I agree with Quigibo.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 15, 2010, 12:53:32 am
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
You mean Horizontal X1,X2,Y1 or something like that, right?
/me hopes Quigibo was planning to actually let the user choose where to draw the line x.x
Title: Re: Features Wishlist
Post by: Raylin on June 15, 2010, 09:48:57 am
In the far future, I would be nice to have the ability to have automated BGM.
Using the interrupts, perhaps?
Title: Re: Features Wishlist
Post by: SirCmpwn on June 15, 2010, 10:33:24 am
Two feature requests:
In the menu for program selection, I would like to press Alpha+[Letter] to scroll to that letter
I would like to define the shell in the header.
Title: Re: Features Wishlist
Post by: ztrumpet on June 15, 2010, 01:17:51 pm
I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.
You mean Horizontal X1,X2,Y1 or something like that, right?
/me hopes Quigibo was planning to actually let the user choose where to draw the line x.x
I hope so too, otherwise it would be kind of like a BSOD/LCD Test Mode without the overload of electricity. O.o
Title: Re: Features Wishlist
Post by: mapar007 on June 15, 2010, 01:19:12 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.

@Raylin: lemme just explain why: the calc processor is too weak to handle all the cryptographic computations involving the signing of the app. (they still have to be signed, even when you already have them on your calc)
Title: Re: Features Wishlist
Post by: calc84maniac on June 15, 2010, 01:31:53 pm
Keep in mind App compiling will take over 10 minutes on-calc, though.

@Raylin: lemme just explain why: the calc processor is too weak to handle all the cryptographic computations involving the signing of the app. (they still have to be signed, even when you already have them on your calc)
I thought they only had to be signed when transferring them to other calcs.
Title: Re: Features Wishlist
Post by: Quigibo on June 15, 2010, 02:01:11 pm
They don't have to be signed on-calc at all, you can sign them on the computer instantly.  I'll probably still add the on-calc signing though, but much later since I doubt anyone would really want to use it.  You'd have to be completely isolated from a computer and slightly crazy to want to do that.  Don't forget, the game will run fine without signing.  This is only for transferring the file to another calculator.

@SirCmpwn
The alpha scroll thing I can do.  The shell type in the header I don't think it necessary.  The app already saves the current shell to use every time you change it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 15, 2010, 03:40:02 pm
I will most likely sign them on the computer, personally. Much faster. That's providing it is even possible to send an unsigned APP from the calc to the computer, though. COuld anyone verify this? Also doesn't it require the app in .HEX format?
Title: Re: Features Wishlist
Post by: jnesselr on June 16, 2010, 10:27:33 pm
Hmm... Why not store the data as an archived appvar or something.  It shouldn't be hard to whip up a java app to convert it.  Can someone explain this signing thing better?  I know about RSA, but is it done on every byte, or the whole app?  I presume that if it was byte by byte, this would be a simple look up table problem, so I'm guessing that's not it.  If it's RSA, and the actual signing process was explained slightly better, I'm sure the app could sign it as well.  I wouldn't mind waiting ten minutes as long as it had a progress bar.  I really dislike the applications that do a process for 5 minutes with nothing to show for it but a blank screen.

Anyway... We could split it up into 4 appvars, each with 4096 bytes.  I bet you could do that in axe, too.  When is the app exporting version expected?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 16, 2010, 10:51:12 pm
I really dislike the applications that do a process for 5 minutes with nothing to show for it but a blank screen.
Yeah I remember that about MirageOs sorting in version 1.1 x.x with 100 programs it took 40 minutes and I thought my calc froze x.x. IN 1.2 it's not as bad.

I don't know much about app signing, but the 10-15 minutes signing process thing came from BrandonW mouth so I guess he knows how that stuff works pretty welland there might not be other ways. As for archived appvars, do you mean to reduce the signing time (since the app wouldn't be multiple pages anymore)? Also I am not sure if Quigibo was planning to implement reading data from archive except if stored in an APP. We would probably still need to unarchive, read data, archive when RAM is running low, unarchive another appvar if needed, load other data, etc. SOmething that would cause a lot of loading times (and wearing off the Flash chip with garbage collections, probably)
Title: Re: Features Wishlist
Post by: SirCmpwn on June 17, 2010, 12:31:03 am
@SirCmpwn
The alpha scroll thing I can do.  The shell type in the header I don't think it necessary.  The app already saves the current shell to use every time you change it.
That is fair, but I have several programs that I develop at the same time, and some use a shell and some I don't actually want to use a shell, so I don't like having to change it all the time.  Sometimes I even forget, and this gets quite frustrating.  For example, I have a prgmKEYS that displays the keycode when you press it, and I accidentally compiled it under MOS and deleted the source.  I'm too lazy to rewrite it, so it has bugged me ever since.  It would have been much easier to define it as nostub in the header.
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:13:50 am
DJ suggested a really cool idea.  I think If I use my hooks correctly, I can have the Axe Tokens automatically enabled whenever the basic editor detects the program it is editing is an Axe source file and then revert back to normal when you quit so that the tokens never get mixed up or confused when you're dealing with regular BASIC.

I'm just worried if I eventually want to switch to Axe Tokens as the default tokens, then computer coding might get more complicated since programs like SourceCoder only use the original tokens.
Title: Re: Features Wishlist
Post by: calc84maniac on June 17, 2010, 02:17:12 am
DJ suggested a really cool idea.  I think If I use my hooks correctly, I can have the Axe Tokens automatically enabled whenever the basic editor detects the program it is editing is an Axe source file and then revert back to normal when you quit so that the tokens never get mixed up or confused when you're dealing with regular BASIC.

I'm just worried if I eventually want to switch to Axe Tokens as the default tokens, then computer coding might get more complicated since programs like SourceCoder only use the original tokens.
You could always ask Kerm to add Axe support to Sourcecoder :)
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:21:23 am
While that is true, and he probably would, what about things like TI-GraphLink?  I don't know if anyone still uses that but that's what I used to use a lot for basic editing.  But I suppose as long as there is at least one computer editor that supports it, then it at least gives you the option.  Does anyone here code on the computer in something other than SourceCoder and would be uncomfortable switching?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 17, 2010, 02:23:48 am
Why not just keep things as they were? Sure, Conj() sounds weird, but think about new members who are gonna ask for help. They're gonna get told to copy bytes they need Conj. Experienced users all ggot used to Conj. I feel like you are forcing this on people and despite what I said regarding that stuff you did not care.

So for now I am sticking to Axe 0.2.6 and am no longer going to provide new feature suggestions.
Title: Re: Features Wishlist
Post by: Raylin on June 17, 2010, 02:30:02 am
Easy, DJ, easy.
Be cool.

Quigibo's obviously wants to evolve Axe into an independent language and if he's doing that, I say let him.
Besides, you can toggle the changes. They aren't really forced... :\
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 17, 2010, 02:32:09 am
True but he's planning to quit documenting the old commands...
Title: Re: Features Wishlist
Post by: Quigibo on June 17, 2010, 02:33:49 am
I'm not planning anything yet.  This is just an experiment.  I'm going to see if people like it or not.  I've clearly got 1 vote for not.
Title: Re: Features Wishlist
Post by: meishe91 on June 17, 2010, 02:42:59 am
I like the idea of just being able to toggle them off and on when you want. That way both sides are happy. What you could do on like the command list to show what both names are is just have one column that says "TI Token" and then the other "Axe Token" and then just state in documentation or something which is which. Just a thought :)
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 04:46:49 pm
I have seen in disassembled code:
 ld ($8000),hl
 ld hl,($8000) ; $8000 is an example

Will that be optimized? Or is the user not optimized code that leads to that?

Also some push and pop of hl could optimize sometimes. Dunno how hard it could be.

When Axe Parser reaches final releases, I will like to see the compiled code for curiosity. :P
Title: Re: Features Wishlist
Post by: Quigibo on June 18, 2010, 04:54:31 pm
That would only be from unoptimized code by the programmer.  Like this:

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

In the above example you first increment the value of A and then save it.  Immediately after, the next instruction is to load A again to display it.  Since you have just saved it and now are immediately loading it, that is obviously an inefficiency.  You can optimize it like this:

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

So that way, it doesn't need to load the value of A a second time.  I might be able to have this be done automatically, I don't know how hard that would be though becasue that type of optimization is not dependent on the source, rather, it would need to make checks on  the assembly code written.  I haven't tried that yet, but it might be possible in the future.
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 05:04:53 pm
I see. I am still getting into Axe Parser details. :P
Since that only comes from user not optimized code, we can leave to the end or just forget it and instead document how to code optimized.

In the future would an Axe Parser optimizator be a viable project? Like a program that takes compiled code and tries to replace code by smaller or faster code.
Btw, programs (and appsvars) can be shrink directly and safely by changing its size word (it is the first 2 bytes that the VAT points to the program memory) to a lesser value?
Title: Re: Features Wishlist
Post by: Quigibo on June 18, 2010, 05:12:14 pm
I doubt you can shrink it that way because I think then the OS is unaware of the change and it will say you have less RAM available on your calculator than you really do and it will not correct itself until the next ram clear.

I hope to have the Parser itself optimize as much as possible.  The reason you don't really see C or Java optimizers is that its really really hard to optimize code at the higher levels, even for a medium level like Axe.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 18, 2010, 05:15:43 pm
Code: [Select]
Disp A+1->A>Dec
Gotta love how we can do that ;D . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)
Title: Re: Features Wishlist
Post by: Galandros on June 18, 2010, 05:34:13 pm
Code: [Select]
Disp A+1->A>Dec
Gotta love how we can do that ;D . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)
Yes, I also like the syntax after understanding the implications.
It is bit like the Ans (some differences) but even faster. :D
I also wish in TI-BASIC we could do some expressions that did not change Ans for faster code. :D Like lines started with colons instead of enter did not change Ans. I see lots of optimization coming from this.

Even more important would be TI-BASIC be faster interpreting. I will experiment a simple interpreter that looks like TI-BASIC but adds some BBC BASIC, Axe Parser and some of my ideas to it. The floating point operations could be easily added later with bcalls to the TIOS routines. Until that I would use integers for numbers, lists, etc..
The main advantage of a interpreter against Axe Parser is stability and source code is also the code. It would be slower anyway, but I believe is possible to come with a bit faster than BBC Basic.
Also 1000th post. ^^
Title: Re: Features Wishlist
Post by: souvik1997 on June 20, 2010, 08:04:13 pm
Something that would be really cool would be the addition of matrices.
Title: Re: Features Wishlist
Post by: calcdude84se on June 20, 2010, 09:00:52 pm
You can do matrices already, albeit indirectly. For a matrix with X columns and Y rows, for example, you can access (A,B) (with A being the column and B the row, indexed from 0) with {B*X+A+GDB1} (assuming the data is ordered a row at a time, beginning at GDB1)
As for a direct method, it might cause too much overhead, though, even if it didn't (I can already think of an implementation where everything that can be figured out is at compile time), I'm not sure it would be added. That would be up to Quigibo.
So, rather, you would like a direct, simple-looking way to use matrices. (Actually, these are really just two-dimensional arrays, but w/e. You're not getting matrix multiplication in Axe except by your own subroutine :P)
Title: Re: Features Wishlist
Post by: Raylin on June 20, 2010, 11:08:45 pm
Perfect character spacing when displaying text one character at a time.
That is the feature I want.
Title: Re: Features Wishlist
Post by: Builderboy on June 21, 2010, 01:15:33 am
How would you propose this works though?  Since you are displaying it yourself one character at a time, you are specifying the arguments.  Maybe a table of constants that tell you the width of each individual character?
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 01:20:04 am
^ I'll get to that character thing  soon.

I'm thinking of allowing a new alternative syntax to make coding a little easier.  Just like you can do {L1+5} I am thinking of also allowing L1(5) like how BASIC does it.  You would also be allowed to do this with variables.  That is, A(2) becomes {A+2}.  The only downside to this would be that implied multiplication can never be implemented then becasue using parenthesis will ALWAYS imply pointing and never multiplication in order to make this unambiguous.  Not that I was planning to add implied multiplication, but thought I'd mention that.  Similarly, I would also like to be able to do the same with matrices.

What I was thinking is that you can store to a matrix at the beginning at some point.  So L1->[A](5,10) tells the compiler that you would like to start a Matrix at the position L1 and make it 5x10.  This would be completely a compiler command and would not contribute anything to the code.  The next step would be to use [A].  With the new syntax, you could say something like [A](2,4) and it will compile as {L1+2*5+4} since now the compiler knows where to store the matrix and how big it needs to be.

I'm still not sure how possible this will be to do since I still need to have it optimized automatically, but it would certainly be pretty cool.  It might allow me to implement some other commands like row and column swapping as well as well as filling with a single value, copying one matrix to another, etc.  All handled at compile time by the parser to translate into the current way of doing things so that its just as efficient.

I'm not planning to ever replace the old syntax, I'm just giving a new alternative to those who like the BASIC way of doing it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 02:00:48 am
I like the new syntax idea. It would become pretty handy for people who are switching from BASIC. I got an hard time getting used to {} syntax x.x

It would probably also make it easier to port some BASIC programs to Axe
Title: Re: Features Wishlist
Post by: Builderboy on June 21, 2010, 02:06:38 am
Wow that actualy sounds amazingly epic!  Automatic Matrices and Auto lists and all sorts of other magnificent things :D I wonder... if matrices could be 'initialized' to half byte in order to take the hassle out of using half byte code :O
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 09:48:55 am
Feature request: True logical and,or commands. (Not sure about xor, that might not work).
These would act similarly to Python (and maybe other languages too).

"A and B" would compile as:
Code: [Select]
ld hl,(var_a)
ld a,h
or l
jp z,_
ld hl,(var_b)
_

"A or B" would compile as:
Code: [Select]
ld hl,(var_a)
ld a,h
or l
jp nz,_
ld hl,(var_b)
_

So basically, "A and B" is the same as "If A:B:End", and "A or B" is the same as "!If A:B:End"
Title: Re: Features Wishlist
Post by: Magic Banana on June 21, 2010, 09:59:45 am
^ I second that request.
Title: Re: Features Wishlist
Post by: _player1537 on June 21, 2010, 10:06:53 am
sorry for being slow...but what will that allow us to do that the current code won't?
Title: Re: Features Wishlist
Post by: Ikkerens on June 21, 2010, 10:13:48 am
sorry for being slow...but what will that allow us to do that the current code won't?

It will allow us to change other if's.
Code: [Select]
:56→V
:If V
:Disp "V is not zero"
:End

Currently that would cause the parser to think, oh, its not a 1, so skip the block
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 10:16:21 am
Well, "5 and 2" will return 2 instead of 0, which is a non-zero value as expected. Of course, if you just use logical (0,1) values, it works as expected as well.
Title: Re: Features Wishlist
Post by: ztrumpet on June 21, 2010, 10:48:45 am
I think it needs real Booleans.  :)

I also like the matrix/list idea. :D
Title: Re: Features Wishlist
Post by: calc84maniac on June 21, 2010, 10:52:48 am
Here is another cool thing about this method: Short-circuit evaluation (http://en.wikipedia.org/wiki/Short-circuit_evaluation)

And I think this method would be more efficient than real booleans, because we don't need to waste the extra space making sure all logical operations end up as 0 or 1. Zero and non-zero are all we really care about.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 12:23:11 pm
I think it would be nice indeed if it worked like TI-BASIC. I always had trouble with If conditions otherwise x.x
Title: Re: Features Wishlist
Post by: ztrumpet on June 21, 2010, 12:26:32 pm
I think it would be nice indeed if it worked like TI-BASIC. I always had trouble with If conditions otherwise x.x
Me too. :)
Title: Re: Features Wishlist
Post by: FinaleTI on June 21, 2010, 02:03:39 pm
It would be nice if there was a way to delete appvars from within your Axe program.
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 02:46:23 pm
I'm confused why that code is any different than the current code:

Code: [Select]
"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a

It returns 0 if its false and non-zero if its true as well, and its the same size.  Unless your optimization is a speed optimization?

And Ikkerens, that code has always worked.
Title: Re: Features Wishlist
Post by: Ikkerens on June 21, 2010, 02:49:02 pm
Not on my calc, if I "If X" it will skip the containing code.
Only accepts a 1.
Title: Re: Features Wishlist
Post by: Quigibo on June 21, 2010, 02:53:49 pm
That's not how "If" works.  X must have been 0 if it skipped the code.  This isn't something I've ever changed, its always been that true means non-zero and false means zero.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 21, 2010, 10:55:00 pm
I noticed in the past that If X sometimes skipped the code if it was something else than 1, but I don't remember when exactly. It was a few versions ago and I forgot which. IN other words, is If with anything that is non-zero supposed to execute the code or will it just do it if it's equal 1?
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 02:45:28 pm
I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 02:50:37 pm
I'm confused why that code is any different than the current code:

Code: [Select]
"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a

It returns 0 if its false and non-zero if its true as well, and its the same size.  Unless your optimization is a speed optimization?

And Ikkerens, that code has always worked.
It is partly a speed optimization, yes. Also, I believe it could be smaller when using expressions, like
A=1 and B=2
wouldn't have to save/restore the result of "A=0".

Not to mention, If X and Y will not work as expected in some cases when using bitwise and.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 22, 2010, 02:52:44 pm
I just noticed that 'Sprites larger than 8x8' is still in this features list. Are the Bitmaps currently added not the thing you meant with this?
I believe they were added now. He probably just need to update the list. Keep in mind those bitmaps are slower than 8x8 sprites, though, since he uses a TI routine for them. If you need speed instead of size, I recommend using multiple 8x8 sprites instead
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 03:52:44 pm
OK, so sprites will perhaps be optimized in the future. Is it really that slow? How many time does Bitmap cost more than multiple 8x8 sprites?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 22, 2010, 04:03:21 pm
It's not incredibly slow. It's just a bit slower than regular ones. Bitmap uses a routine included in the TI OS, which means the code needed for it is not included in your Axe program, which is why your executable ends up slower. It's a BCall, I believe.
Title: Re: Features Wishlist
Post by: LordConiupiter on June 22, 2010, 04:07:30 pm
there's a fairly big chance that it is a ROM call I think, but I don't understand why it can't be used in BASIC then?
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 04:09:06 pm
there's a fairly big chance that it is a ROM call I think, but I don't understand why it can't be used in BASIC then?
It's because there's no TI-Basic command for it. It's a routine intended for use in FlashApps and ASM programs.
Title: Re: Features Wishlist
Post by: Ikkerens on June 22, 2010, 05:19:41 pm
1 more thing to the wishlist:
15Mhz GrayScale
Title: Re: Features Wishlist
Post by: Magic Banana on June 22, 2010, 07:59:18 pm
I've got a feature request.

Would it be possible to make 'checkpoints' in the program editor and be able to jump between them using something like 2nd+Right/Left? Just wondering because my code is getting really long and it takes a while to scroll all the way to the bottom just to change 1 or 2 things before compiling again.

Also, for the Error scrolling, wouldn't it be better to scroll to 7 lines before the line with the error, so that it is at the bottom instead of the top? That's how the TIOS does it. I always have to scroll up to see what I wrote to cause the error.
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:02:20 pm
1 more thing to the wishlist:
15Mhz GrayScale
Actually this isn't a  bad idea, as it *would* result in smaller compiled code and because we don't have the Full and Normals to make it slightly faster. :)  Can we please have this Quigibo? ;D
Title: Re: Features Wishlist
Post by: calc84maniac on June 22, 2010, 08:04:55 pm
1 more thing to the wishlist:
15Mhz GrayScale
Actually this isn't a  bad idea, as it *would* result in smaller compiled code and because we don't have the Full and Normals to make it slightly faster. :)  Can we please have this Quigibo? ;D
The thing is, inside the display routines it would have to set 6MHz, run the code, and restore the previous clock speed. You really aren't saving space after all (especially if your code never sets Full in the first place).
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:07:14 pm
Couldn't you use a different length delay for the LCD?  Or would that not work right? =/
Title: Re: Features Wishlist
Post by: Quigibo on June 22, 2010, 08:26:05 pm
I've got a feature request.

Would it be possible to make 'checkpoints' in the program editor and be able to jump between them using something like 2nd+Right/Left? Just wondering because my code is getting really long and it takes a while to scroll all the way to the bottom just to change 1 or 2 things before compiling again.

Also, for the Error scrolling, wouldn't it be better to scroll to 7 lines before the line with the error, so that it is at the bottom instead of the top? That's how the TIOS does it. I always have to scroll up to see what I wrote to cause the error.

That's another direction I might be headed eventually.  I might just make full fledged editor improvements to the TI Program editor during Axe Edit sessions like "sprite previews" of hex code, "bookmarks" in the code (which is what you're talking about), maybe a "Condensed View" in which labels have little plus signs next to them that expand and hide the code for each subroutine, these are just ideas I'm throwing out there.  They are all possible with the clever use of Key Hooks.  I'm just not sure if I want to go that far until I finish more commands and features, it might be an Axe 2.0.0 thing.

In fact, I would like to turn this thread into a poll, so if any administrators reading this can do that, that would be great.  After each update, I will edit the poll to list several choices of major features to include in the next update so I can get a sense about what people want me to do first.  Also, while you're at it, could you unsticky the token poll since that's already been resolved.  Thanks!  :)
Title: Re: Features Wishlist
Post by: ztrumpet on June 22, 2010, 08:28:11 pm
Also, while you're at it, could you unsticky the token poll since that's already been resolved.  Thanks!  :)
Unstickied. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 01:58:40 am
At the bottom of the topic, you see the REPLY | NEW TOPIC | etc stuff, right? If you click the "ADD POLL" button you can append a poll to this topic. If that button doesn't show up, let me know in this thread about what you want the question to be as well as answers, and I may try to add it (or someone else could)
Title: Re: Features Wishlist
Post by: Quigibo on June 23, 2010, 03:24:26 am
Thank you, I didn't see that!  ;D

So anyway, I decided to pick 3 things that each will take a while and I'll try to include at least one of them in the next version.  I would like to know what people want to see next so I spend my time most efficiently.  I've generally just been doing the easy stuff first, but I realize that a lot of people are getting frustrated with waiting around for certain features and I feel like it would be a good idea if you finally get a say in it.  I mean none of this guarantees I will be able to finish the feature, but at least I'll know what everybody wants.  I'll edit the poll each time I finish one of the features.  I'm still working on other smaller commands on the side too by the way as well as bug fixing and optimizations.

Please Vote!
Title: Re: Features Wishlist
Post by: nemo on June 23, 2010, 07:13:31 am
can you elaborate on which each option really means in terms of axe growing?
Title: Re: Features Wishlist
Post by: Raylin on June 23, 2010, 09:41:58 am
If you make these Axioms things, would we be able to make our own?
Could we make something like geo drawing?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 10:55:06 am
Keep in mind Axioms would be against the contest rules, though (since they would not be Axe native code). Just as an head up for contestants.

Interrupts would be nice
Title: Re: Features Wishlist
Post by: ztrumpet on June 23, 2010, 10:57:17 am
I really want interrupts!  They'll be fun to work with. ;D
Title: Re: Features Wishlist
Post by: Z@VY on June 23, 2010, 10:59:47 am
What are these axioms ??

Oh and interrupts too
Title: Re: Features Wishlist
Post by: SirCmpwn on June 23, 2010, 11:35:46 am
Interrupts will be awesome.  Like no other.
Also, bumping my previous request to press a letter key in the compile menu to jump to that letter, like in the TIOS program selection.
Title: Re: Features Wishlist
Post by: calcdude84se on June 23, 2010, 02:15:50 pm
I voted for interrupts, as they will still be native Axe yet will be very awesome. (Interrupt routines ftw!)
What would also be nice is to be able if the interrupt was caused by the ON key or by something else (the hardware timer, etc.)
Title: Re: Features Wishlist
Post by: LordConiupiter on June 23, 2010, 02:32:32 pm
A small question: do you mean with 'native BASIC commands' that external basic prgm files can be executed, or that inline BASIC can be compiled? The last option is the most difficult one I think, while some tokens got a new 'mask' :)
Title: Re: Features Wishlist
Post by: yoman82 on June 23, 2010, 03:07:46 pm
I think inline BASIC is the most desired feature for me, it would make the transition a lot easier. However, how do you plan to address the homescreen, since it is unusable in regular axe?
Title: Re: Features Wishlist
Post by: calcdude84se on June 23, 2010, 03:17:33 pm
Hmm? The homescreen is usable in Axe. (Disp, ClrHome, Output(, etc.)
Also, bumping another feature request: read, write, and create any variable type. (Also deleting any variable, seeing as there is no deleting yet)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 03:18:18 pm
My guess is that he'll use some sort of code that will go back in TI-OS mode in a RAM area where BASIC code is inserted and execute that using the TI-OS BASIC interpreter, then at the end, it will go back to the Axe program again.
Title: Re: Features Wishlist
Post by: yoman82 on June 23, 2010, 03:18:51 pm
yes, I know, but things like input are not. Sorry if I was a bit confusing.
Title: Re: Features Wishlist
Post by: LordConiupiter on June 23, 2010, 03:48:03 pm
IMHO external variable handling is even more important than interrupts, Axioms and a new syntax for lists and matrices.

but that's just MHO :)
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 04:51:58 pm
Wait, i thought Axioms was just the ability to have some of your axe code in seperate programs?  Like subprograms.  Why is that considered non-native code?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 04:55:46 pm
In the poll it mentions it is ASM libs. If Axioms allow the running of non-Axe code, then such non-Axe libs would be disallowed for the contest.

Quote
Axioms (ASM libraries)
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 04:58:04 pm
Hmmm then i am confused.  What are Axioms Quigibo?
Title: Re: Features Wishlist
Post by: Quigibo on June 23, 2010, 05:46:43 pm
Axioms is an SDK for developers to write their own custom Axe commands in assembly.  They would be able to choose the tokens they want to use and an option to change the spellings if necessary.  Users can import the libraries into their programs using the new Axiom() command.  They aren't just slapped into the code, only the routines you use are put into the code just like native Axe commands.  It will support easy things like just inserting a piece of code into the program or more complicated things like subroutines with multiple arguments.  I think it will accelerate the development of Axe commands becasue once some ASM junkies like calc84maniac :P start writing these routines I can basically copy and paste them into the app to support them naively.  Also they can be written to support specific shells such as DCS or MirageOS.
Title: Re: Features Wishlist
Post by: ztrumpet on June 23, 2010, 05:55:25 pm
That's neat.  Does this count as Axe, DJ?
Title: Re: Features Wishlist
Post by: FinaleTI on June 23, 2010, 05:57:29 pm
That does sound cool.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 06:30:15 pm
That's neat.  Does this count as Axe, DJ?
Sadly, no, because I know this will get abused and people will write Axe games that has like 50% Axioms in them.

If an Axiom is included with Axe Parser download in the future, I'll accept it, though. But I am sure Quigibo would just integrate them in the language (and the APP) anyway.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 06:33:59 pm
Sadly, yes,

I think you mean no?  Ztrumpet was asking if they were Axe code (and therefore usable in the contest).  You said yes, but it sounds like you mean the opposite? o.O
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 06:35:47 pm
Er... my bad... sorry. Edited my post. Nah it wouldn't be considered as Axe code. However, if Quigibo decided to include Axioms with Axe Parser, thos Axioms could be used in the contest. Just not third-party stuff, to prevent abuse.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:00:12 pm
yeah that sounds good to me :) Hmm though... what if you wrote your Axioms in Axe?  Axe compiles to Asm, so i think you could theoretically use Axe Axioms :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:06:20 pm
well, the source code for those Axioms would need to be included, then.
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:16:13 pm
Sounds good to me ^^ I personally voted for Axioms, just because of how much easier it would be to have several different subprograms instead of a single 8000 byte program to edit. 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:16:54 pm
yeah true, especially when working on mutliple projects at once that uses the same routines. Plus it makes the code less long to scroll
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:18:19 pm
Yeah, but it seems that interrupts are going to take the cake this time :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 07:20:35 pm
Well, I personally voted interrupts, since for now I can tolerate scrolling through large code, plus right now my programs are rather small. I guess I might be used a lot to Illusiat 13 :P
Title: Re: Features Wishlist
Post by: Builderboy on June 23, 2010, 07:40:47 pm
Heh i remember when i was programing Portal and i was editing the last sequence.  I had to scroll through over 8000 bytes of Code to get to the buggy part ;D
Title: Re: Features Wishlist
Post by: souvik1997 on June 23, 2010, 08:13:40 pm
Axioms is an SDK for developers to write their own custom Axe commands in assembly.  They would be able to choose the tokens they want to use and an option to change the spellings if necessary.  Users can import the libraries into their programs using the new Axiom() command.  They aren't just slapped into the code, only the routines you use are put into the code just like native Axe commands.  It will support easy things like just inserting a piece of code into the program or more complicated things like subroutines with multiple arguments.  I think it will accelerate the development of Axe commands becasue once some ASM junkies like calc84maniac :P start writing these routines I can basically copy and paste them into the app to support them naively.  Also they can be written to support specific shells such as DCS or MirageOS.
Natively or naively?  :P

I voted for the new list syntax because I am used to the BASIC way of doing things
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 23, 2010, 08:44:32 pm
I think he means natively, according to the context.
Title: Re: Features Wishlist
Post by: ACagliano on June 24, 2010, 12:00:18 pm
I don't know how complicated this would be, but maybe have Axe also serve as an on-calc version of BasicBuilder, compiling selected progs written in Axe into Applications.

I know there's probably a bus-load of problems with this, but its just a whim.
Title: Re: Features Wishlist
Post by: Builderboy on June 24, 2010, 02:24:42 pm
There really is no problem besides the fact that it would take about 15 min to sign the apps, and thats no good :(

(At least you would only have to sign them once however, since you can beta test all you want without signing them)
Title: Re: Features Wishlist
Post by: shmibs on June 24, 2010, 08:58:38 pm
i haven't gone and read through the last 55 posts so im sorry if it has been mentioned already, but reading data one byte at a time from the flash (from appvars and such) instead of unarchiving them in their entirety would be a huge help
Title: Re: Features Wishlist
Post by: calcdude84se on June 24, 2010, 09:00:24 pm
Yeah, doing that or creating a RAM copy of an appvar/program (IMO more useful) has been mentioned. No harm in bumping it, though. :P
That and more variable support are the things on my mind right now (besides interrupts)
Title: Re: Features Wishlist
Post by: Mighty Moose on June 24, 2010, 11:23:27 pm
I'm split between interupts and axioms.  Although I don't use Axe much (yet).  I think interupts would be nice, but I also think axioms would speed up development.

I know this probably has already been mentioned, but have we decided when geometry tools (circles, boxes, etc.) will be added?
Title: Re: Features Wishlist
Post by: Quigibo on June 24, 2010, 11:33:40 pm
They'll be in the next poll Moose.  That one will take particularly long to write though which is why I've been putting it off.  I have to write all those routines from scratch to meet the Axe super-standards.

I've been working on both Axioms and Interrupts and they might both be done by Sunday hopefully.  Just for future reference, I think I will make the interrupt vector table reside in L2 since mirage uses this for its own interrupts but I'm not 100% sure (do any asm programmers know another place to fit the table more tightly?)  Also, writing the Axioms has made me realize the importance of another major optimization that must be done to support the Axioms.  The Parser will have to make a 3rd pass most likely, so that is a 30% in time to compile, but its already pretty fast so I don't think anyone will mind.  The ~20-60 byte decrease to most programs will make it worth it anyway.
Title: Re: Features Wishlist
Post by: Mighty Moose on June 24, 2010, 11:41:40 pm
Oh, ok.  I was just curious.  I would imagine it would be somewhat difficult to draw geometric shapes w/o actual draw tools.

Good luck and happy coding!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 24, 2010, 11:51:25 pm
Good luck Quigibo!

Btw will the usage of L2 mess up MirageOS if we use Interrupts?
Title: Re: Features Wishlist
Post by: Builderboy on June 25, 2010, 01:26:56 am
I hope not D: I dont want MirageOS programs to be deprived of their interrupts :[
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 02:16:29 am
Or not being able to run our games that use interrupts in Mirage. A lot of people still use Mirage as their favorite shell.
Title: Re: Features Wishlist
Post by: Quigibo on June 25, 2010, 04:19:43 am
If you're using your own custom Interrupt, then you're not using Mirage's interrupt.  Therefore there's no conflicts.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 09:20:39 am
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Title: Re: Features Wishlist
Post by: calc84maniac on June 25, 2010, 11:10:58 am
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Well, it would overwrite Mirage's interrupts, but I'm quite sure that these interrupts are only used for those ON+button hacks during games, not in MirageOS itself.
Title: Re: Features Wishlist
Post by: _player1537 on June 25, 2010, 02:21:05 pm
desolate I remember used custom interrupts, and iirc it exited just fine.  Someone might want to double check me on that though
Title: Re: Features Wishlist
Post by: ztrumpet on June 25, 2010, 04:45:03 pm
Awesome!  Thanks Quigibo! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 25, 2010, 06:33:07 pm
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to Mirage
Well, it would overwrite Mirage's interrupts, but I'm quite sure that these interrupts are only used for those ON+button hacks during games, not in MirageOS itself.
Ah, if that's the case, it might be fine, then. Some games disables those.
Title: Re: Features Wishlist
Post by: ztrumpet on June 25, 2010, 10:11:57 pm
I have a request:
Can we have include files.  For example if we had a routine for getting the user's name at "Lbl N" you could add this in your code in two ways:
1: Normally.  Have Lbl N somewhere in your program.
2: With the include.  Close to the top, put the name of the program where the subroutine resides.  When it's compiled it would get compiled with the main program and would run exactly the same.

Is this possible?  I think this would be helpful for better readability. ;D  Thanks! :D
Title: Re: Features Wishlist
Post by: Quigibo on June 26, 2010, 04:23:16 pm
@ztrumpet, I hope so.  I plan to eventually have external Axe libraries which is basically almost exactly what you're talking about, however, it is very difficult.  Much more so than Axioms.

I have reset the poll since I finished interrupts which are really awesome are surprisingly simple to use in Axe.  You're all going to be so spoiled [old man voice] becasue back in my day, we had to are our interrupts in assembly, and the tutorials were wrong and misleading, and I spent weeks before I realized I forgot to save the IX register, and get off my lawn you crazy kids! [/old man voice] :D .  I have replaced it with geometry drawing so please vote once again!
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 06:51:17 pm
will drawing a 8x8 black square be faster or slower than using an 8x8 sprite?
Title: Re: Features Wishlist
Post by: Builderboy on June 26, 2010, 07:18:03 pm
I would hope its faster since your not reading from any sprite data o.O We shall see
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 07:21:30 pm
i hope it is too.. that would come REALLY handy in my contest entry (: i'm waiting to place my vote until i know though.
Title: Re: Features Wishlist
Post by: SirCmpwn on June 26, 2010, 07:23:37 pm
I really want to use custom interrupts and Axioms.  That would be awesome.
Title: Re: Features Wishlist
Post by: Builderboy on June 26, 2010, 07:34:00 pm
I voted for Axioms again ^^
Title: Re: Features Wishlist
Post by: nemo on June 26, 2010, 08:08:14 pm
i'd vote for string output if that was an option.

edit: would it be feasible to have a shortcut to incrementing a byte in RAM?
so rather than doing
Code: [Select]
{O+1*Y+X+L1}+1->{O+1*Y+X+L1}

you could do something like

Code: [Select]
{O+1*Y+X+L1}++

just like in C.
Title: Re: Features Wishlist
Post by: calc84maniac on June 26, 2010, 08:50:20 pm
That would probably be a good idea. In the meantime, you can use a ->var in the first set of brackets and use {var} in the second.
Title: Re: Features Wishlist
Post by: willrandship on June 26, 2010, 09:40:53 pm
I was going to vote asm libs, but voted Geo Drawing since asm libs will probably not be allowed in contests.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 27, 2010, 12:07:24 am
I suspect Raylin will vote for geometry drawing (noticing his signature says his Axe entry is on hold until such feature is added) :P
Title: Re: Features Wishlist
Post by: Raylin on June 27, 2010, 12:09:16 am
Damn right. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 27, 2010, 12:30:05 am
Another thing I wonder:

When you install a language localization APP (like Français, which I used a lot until I started using Omnicalc/xLIB, which screws it up), all the commands in the CATALOG are re-ordered in the new alphabetical order they are in French. Do you think this could be possible for the new Axe tokens? I sometimes have an hard time finding some of them there (except Copy() of course) x.x

You would need to make sure they are ordered properly on 83+/SE calcs, though, since they have fewer commands than the 84+.
Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:02:53 pm
Okay, I've finished Axioms for the most part, I just have a few more things to tweak and more testing to do.  I updated the poll.  I won't go any higher than 4 options otherwise it will spread out the votes too much.  The "Update Documentation" idea would take me a long time to do, but it would involve writing a detailed commands list in the doc itself with examples and tips and stuff like that.  I would still keep the old one though just for reference and to have a "printer friendly" version.

The linking and port I/O would involve automated linking features that basically send and get bytes through the link port as well as raw data for perhaps microphones, IR controllers, sensors, advanced sound, accelerometers, electronic circuits, etc.
Title: Re: Features Wishlist
Post by: nemo on June 29, 2010, 10:07:35 pm
quigibo, i don't recall this being answered. would an 8x8 sprite be faster or slower than geometry drawing an 8x8 black box?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:09:19 pm
I would still keep the old one though just for reference and to have a "printer friendly" version.
or TL;DR version ;D (if for example someone just seek info for one or two command and doN't know the name).

I voted geometry drawing, though, since it might make the creation of HUDs and interfaces faster and circles would be nice. Would this feature also integrate faster horizontal/vertical lines?

Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:09:38 pm
@nemo
Rect() would be faster for sure.  It's possible that it might be about the same speed if its aligned horizontally though.

EDIT:
@DJ
Yes, faster horizontal and vertical lines would be part of geometry drawing.
Title: Re: Features Wishlist
Post by: nemo on June 29, 2010, 10:12:25 pm
that makes my answer. let's go geometry drawing. where's raylin? we know his vote.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:16:40 pm
YAY! What commands will this be, btw?

Also, I wonder: when running Doors CS7 or Français APPs, will the new tokens still work afterward? (in other words, would there be hook conflict or not?)
Title: Re: Features Wishlist
Post by: Quigibo on June 29, 2010, 10:21:55 pm
As far as I am aware, neither of those applications use the Token Hook so there should be no conflicts.  However, I may eventually use the Catalog Hook to rearrange the catalog which would of course conflict with any Language Localization apps.  Its possible I would need to use the App Change Hook as well which could cause other conflicts.  I will see if its worth all the trouble or not and if there is any simpler way to do it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 10:29:29 pm
Aah ok. I am curious what does Français uses, though, as it changes almost every single TI-BASIC token names accross the entire calc (and swaps Int() with iPart()... stupid Texas Instruments...)

For Français, I would wait a bit, though. It's not a big hurry as long as Silver Shadow won't finish translating the doc in English. In long terms it might increase Axe audience because most french people won't even know a single word of English (as it is not one of the official language in France) and I believe most people use the Français APP there (especially the people with the blue 83+, which has the entire keypad in french)

Another thing is that language APPs adds a new option at the top of the CATALOG, above Abs(): Characters. In there you can easily type strings of text including greek and accent characters.
Title: Re: Features Wishlist
Post by: Runer112 on June 29, 2010, 11:15:30 pm
EDIT:
@DJ
Yes, faster horizontal and vertical lines would be part of geometry drawing.

Shit, didn't see that till after I voted for port I/O... :( If it happens to be a tie between geometry drawing and something else, let geometry drawing win? Lol


I made the poll so you can change your vote now

Oh yay
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 29, 2010, 11:16:34 pm
I made the poll so you can change your vote now
Title: Re: Features Wishlist
Post by: TIfanx1999 on June 30, 2010, 12:08:08 am
Mmmmm.... linking. Now that sounds yummy! :D
Title: Re: Features Wishlist
Post by: LordConiupiter on June 30, 2010, 12:25:18 am
yes, I allways have liked connecting anything with anything else :P
Title: Re: Features Wishlist
Post by: ztrumpet on July 01, 2010, 11:54:37 am
GAH!  I really want linking, but I need speed for a HUD.  My vote was for linking, but then I changed it.  Needless to say, I really want both, I just want speed more. ;D
Title: Re: Features Wishlist
Post by: Builderboy on July 01, 2010, 12:09:43 pm
Same here, i was original linking, but i think geometry would be more useful right now.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 12:58:59 pm
quigibo, can i suggest putting storage to BASIC variables as an option in the next poll, since two of the four options currently have 0 votes?
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 02:11:22 pm
could you perhaps change L1 to L6 to something that makes more sense?
like L3 is AppBackUpScreen, in short ABS?
and L6 is plotSScreen, in short PSS?
I would like it, what do you think about it?

Can you also please copy a Pic depending on its size?
I have Pic vars with a size of 779 bytes, from my PC, which have full 64 rows of the screen, and i would like to be able to use all this info.
thanks in advance
Title: Re: Features Wishlist
Post by: Quigibo on July 01, 2010, 04:08:42 pm
Sure, I changed the poll.  You can always change your vote, but I think I will do geometry drawing next anyway since it will be something fun even if it does take a long time.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:11:43 pm
that's fair. i want both geometry drawing and OS pic/var etc. support anyway. guess i'll be a loner and change my vote to OS var support (:
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2010, 04:11:49 pm
Can someone reset the votes and remove geometry drawing from the poll? It looks like Quigibo has selected geometry drawing as the next feature he will work on already.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:12:41 pm
err.. i can't change my vote apparently.
Title: Re: Features Wishlist
Post by: Quigibo on July 01, 2010, 04:18:11 pm
Well, I haven't actually started it yet, but when I finish it I'll reset the poll.  Desires can change over a week like if you get to a point in a game where you realize you really need something or if you start a new project and find yourself inconvenienced.
Title: Re: Features Wishlist
Post by: nemo on July 01, 2010, 04:26:34 pm
quigibo: there's no option for me to remove my vote/change it. can you make this an option?
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 04:59:08 pm
There will be a new poll when he's finished. It doesn't matter whether you change yout vote right now or not. We just have got to wait till he's finished, and there'll be a new poll.

patience is a vitue... :P
Title: Re: Features Wishlist
Post by: ztrumpet on July 01, 2010, 05:20:04 pm
patience is a vitue... :P
No. :P

I changed it so you can change your votes now. ;D

[mini rant]Not fair!  I want all of these options!  Now! :P[/mini rant]
Title: Re: Features Wishlist
Post by: LordConiupiter on July 01, 2010, 06:03:54 pm
haha ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 01, 2010, 07:32:15 pm
geometry drawing remains my vote for now.

Next, I'm sure to vote reading from archive. A must for large games ^^
Title: Re: Features Wishlist
Post by: Builderboy on July 02, 2010, 04:37:34 pm
When compiling to App, since it doesnt tell you program size, could it tell you how much free space is left in the App?  Just a suggestion :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 02, 2010, 04:54:00 pm
That would be nice indeed. On the computer you can get an estimate by taking the app computer file size and divide it by half, but it is not always very accurate
Title: Re: Features Wishlist
Post by: Runer112 on July 03, 2010, 12:52:29 am
That would be nice indeed. On the computer you can get an estimate by taking the app computer file size and divide it by half, but it is not always very accurate

>divide it by half
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 01:44:44 am
as I said, though, it is not 100% accurate. Doing this with Axe Parser APP shows a size of above 16384 bytes
Title: Re: Features Wishlist
Post by: Runer112 on July 03, 2010, 02:13:21 am
I meant to point out the wording, divide (/) it by half (1/2). ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 02:27:40 am
what's wrong with my wording?
Title: Re: Features Wishlist
Post by: Builderboy on July 03, 2010, 02:38:10 am
He's pointing out that dividing by 1/2 is the same as multiplying by 2  (well not really pointing out :P)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 03, 2010, 02:45:53 am
oh ok x.x. Well I kinda dislike when people point out a mistake and do it in a so unclear way x.x. Thanks Builderboy for at least clarifying him
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 04:28:56 pm
I'm not going to read through all 59 pages and make sure this hasn't been posted before. I haven't tried programming in axe yet, but it always seems that everyone is afraid of losing their source.

Why doesn't axe archive/leave archived the source and use a temp program for compiling? This would eliminate the chance of deleting your program.
Title: Re: Features Wishlist
Post by: ztrumpet on July 04, 2010, 04:31:24 pm
Why doesn't axe archive/leave archived the source and use a temp program for compiling? This would eliminate the chance of deleting your program.
That's a really cool idea, but I'm sure people don't want a lot of Garbage Collects.  Personally I think it' an awesome idea.  Could this be an option... ;D
Title: Re: Features Wishlist
Post by: Quigibo on July 04, 2010, 04:33:15 pm
The source is never lost from compiling, the source can only be lost if the user creates a faulty program and runs it when important things are in ram.  I am probably going to add an option to auto-archive the source after the compile but I don't know how many people would use it since it is annoying to have to keep unarchiving the source every time you need to make a change to it.  Another option is to create a backup copy of the source and archive it before compiling, but there might not be enough ram to do that for larger programs.
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 04:39:12 pm
Ok that's good.

I don't know the inner workings of axe, but couldn't you change the last letter of the source name to something random, like B or %, archive it, remake the source program, and copy the source back from archive? That way, the backup would always be there and would not require any extra ram to create.

You could then have an option to restore backup.

Edit:
    Better yet, just change it's type to appVar, no name changing required.
Title: Re: Features Wishlist
Post by: kindermoumoute on July 04, 2010, 05:08:54 pm
This list is promising, I hope soon to have:
Quote
-Read and write to more calc variables (like Pics)
-Elseif
-Geometry drawing (circles, squares, etc.)
-Automated tile-mapping

good luck ;)
Title: Re: Features Wishlist
Post by: Quigibo on July 04, 2010, 06:13:00 pm
I don't know the inner workings of axe, but couldn't you change the last letter of the source name to something random, like B or %, archive it, remake the source program, and copy the source back from archive? That way, the backup would always be there and would not require any extra ram to create.

Yeah, that's what I was thinking.  The only problem with having it as an appvar though is that then if the ram clear does occur, it would be tricky to get the file back as a program.  You would either have to use an external tool or I would have to add some kind of option in Axe.  What I'll probably do is just always save the backup to the same file and call it "ZBackUp%" or something using illegal characters to guarantee that it won't already exist.  The Z so it always shows up at the bottom of the list.  Also I can give it a backup header instead of a regular one so that it can be restored to its original name.

Also, I'm not sure you can rename a file that's in archive without unarchiving it first.  The symbol table can be renamed, but a copy of the name is also in the archive which could lead to complications becasue during a ram clear when the symbol table gets wiped, it will be regenerated with the incorrect name.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 04, 2010, 06:33:33 pm
auto archiving would be cool. I am sure I would use it if I was on a SE calc and was messing around with stuff that can potentially crash the calc. In some occasions, I tend to forget to backup (normally I do)
Title: Re: Features Wishlist
Post by: thepenguin77 on July 04, 2010, 06:35:57 pm
I was just assuming that the program was in ram. If it's in ram, you can do all you want to its name. By directly modifying the name, the program never has two instances in ram and is only archived once.

You also don't want to use % in a program name as it becomes invisible. I thought that making it an appVar would be the simplest because it wouldn't even require changing the file because the name is preserved as is.

The easiest way I see to back up programs in ram is:
change to appVar
archive
recreate original program
copy from archive

It would of course be different for archived programs.

On recovery, just unarchive, and change the type back to program.
Title: Re: Features Wishlist
Post by: Runer112 on July 04, 2010, 07:04:21 pm
Protip

At the start of the program:
Code: [Select]
"prgmPROGSRC"→Str0
Archive Str0

At the end of the program:
Code: [Select]
UnArchive Str0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 04, 2010, 07:05:47 pm
oh wait I forgot about that :D

Thanks for the tip :D
Title: Re: Features Wishlist
Post by: LordConiupiter on July 05, 2010, 10:59:47 am
a feature request: I would like to be able to execute external ASM/Axe programs or code snippets in AppVars, like external sub()'s. Perhaps u could use the command Func() for this, with the following syntax:
Func(PTR, arguments (r1 to r6))
The pointer has to be a label, and arguments are just only useable in Axe Funcs I think.
Title: Re: Features Wishlist
Post by: Builderboy on July 07, 2010, 02:46:32 am
I would like to be able to shift the backbuffer, currently there is no fast way to do it :(
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 02:56:50 am
yeah I suggested that some drawing commands be extended to back buffer usage too before. I think he said it might be hard for some, though. I hope for scrolling it is possible
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 04:18:13 pm
Question: Will the new geometry drawing additions also include the addition of faster horizontal/vertical line routine?
Title: Re: Features Wishlist
Post by: Quigibo on July 07, 2010, 07:02:55 pm
I'm still debating that.  Using the rectangle command to draw lines would be about the same speed anyway so I might just leave it at that to draw a rectangle with width 1.

The Rect() command is using the ref() token since that puts it in the catalog alphabetically.  Its easy to use and it takes as arguments the X,Y of the upper left corner followed by the width and height of the rectangle respectively.  Making the width or height 1 allows you to draw fast vertical or horizontal lines.

I'll try to extend more of the current drawing commands to the backbuffer as part of this geometry overhaul.
EDIT: I'll reset the poll now since I'm well into the geometry stuff.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 07, 2010, 08:24:25 pm
Oh really? Nvm then :P altough it might pose problems if someone wanted to make a racing game like the one included with Axe due to lack of clipping (unless the person used min/max for clipping purpose)

I think the Rect token is fine. I do not remember if Ref was used much anyway and the name is pretty similar so it shouldn,t be too hard to find in the CATALOG.

Suggestion, you should rewrite your racing game using those :D

EDIT: Voted reading from archive.
Title: Re: Features Wishlist
Post by: Magic Banana on July 08, 2010, 01:16:53 pm
Hmm, tough choice between Read From Archive and OS Var Support, but I'm gonna go for the OS Var support so that I can use Axe programs along with Basic Programs.

Also, Saftey Features should be "Safety Features".
Title: Re: Features Wishlist
Post by: ztrumpet on July 08, 2010, 01:31:57 pm
Also, Saftey Features should be "Safety Features".
Good catch.  I got it fixed. :)
Title: Re: Features Wishlist
Post by: Builderboy on July 08, 2010, 02:33:01 pm
Lol looks like a pretty close race so far!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 08, 2010, 02:53:27 pm
Wow indeed o.o

Yesterday reading from archive was leading by far (and I was happy ;D)
Title: Re: Features Wishlist
Post by: ztrumpet on July 08, 2010, 02:56:49 pm
Wow. O.o  This is extremely close! ;D
Title: Re: Features Wishlist
Post by: calcdude84se on July 08, 2010, 03:05:00 pm
Nobody wants safety features :P
And until I voted, it was tied 4-4-4 (safety features not included).
Title: Re: Features Wishlist
Post by: LordConiupiter on July 08, 2010, 04:47:07 pm
I don't know why safety features would be wanted, cuz everybody just should learn to code safely, and safety slows down a lot, while it won't be used so much.
Until I voted, it was tied 5-5-5 :P
Title: Re: Features Wishlist
Post by: nemo on July 08, 2010, 05:48:05 pm
i'm hoping desperately that OS var/pic support wins. quigibo, in the event of a tie, what happens?
Title: Re: Features Wishlist
Post by: Quigibo on July 08, 2010, 06:11:26 pm
Even in the event of a win, that doesn't mean that's the feature I'm going to work on.  This just gives me a sense of what people want.  Unless there is a mass majority, I'm just going to do what I feel is most essential, or in some cases, whatevers easiest :P
Title: Re: Features Wishlist
Post by: nemo on July 08, 2010, 06:12:35 pm
makes sense. could you rank the 4 options from easiest -> hardest for some comparison?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 01:09:01 am
that said, I hope reading from archive is done at some point in the near future, it would come very handy if I ever made some sort of sequel to Supersonic Ball, since it would mostly not just include levels that are randomly generated and the game would be considerably larger.
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 01:38:40 pm
Indeed, DJ. Even if reading directly from archive isn't supported, it would be nice to be able to create RAM copies of variables.
Well, I guess I'll wait and see what feature is added next. Keep up the good work, Quigibo! :D
Title: Re: Features Wishlist
Post by: LordConiupiter on July 09, 2010, 01:55:25 pm
I don't understand why so many people think that OS Var/Pic/Strc etc. is so very important? for the contest it isn't even allowed to use them i thought, or am I wrong at this point?
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 02:09:18 pm
I don't remember about not being able to use them... Unless you mean to store data, which would be pretty pointless anyway. (So much faster just to have it in the program or in an appvar)
That wasn't my vote, at any rate, so I can't tell you why :P
Title: Re: Features Wishlist
Post by: LordConiupiter on July 09, 2010, 03:24:54 pm
OK, I see.
... Unless you mean to store data, which would be pretty pointless anyway. (So much faster just to have it in the program or in an appvar) ...
OS Pics would perhaps be handy, but I thought conversation with external non-Axe programs was forbidden, and OS things are just only handy for that OMHO.
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 03:31:30 pm
I agree w/you there, and yes, pure Axe only.
Pics and strings would be the two useful OS vars, IMO (Mainly for things like sprite/picture editors)
Title: Re: Features Wishlist
Post by: Quigibo on July 09, 2010, 04:04:07 pm
You're allowed to use OS variables and its even encouraged.  How else are you going to save your games?  Appvars are OS variables, but if you wanted, you can use pics, strings, or other things to save data but I don't know why you would want to.

But I have a feeling most people who voted did not vote because of the contest, but because they want to make some useful editors for sprites, tilemaps, music, and programs which are significantly more useful with more OS var support.
Title: Re: Features Wishlist
Post by: Magic Banana on July 09, 2010, 04:05:49 pm
Is there an efficient way to 'swap' the buffer and back buffer? If not, I'd be nice to have that.

Also, is there a better way to store an OS pic to the buffer besides
Code: [Select]
:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
Title: Re: Features Wishlist
Post by: calcdude84se on July 09, 2010, 04:08:51 pm
Just use expr( (well, now it's Exch(, but you get the point) like expr(L3,L6,768
Yeah, you can do it with conj(/Copy( like this:
Code: [Select]
:[Pic1]->Pic1
:Zeros(12
:.You need to fill in the last row
:Copy(Pic1,L6,768
Edit: some letter cases were incorrect
Title: Re: Features Wishlist
Post by: calc84maniac on July 09, 2010, 04:10:42 pm
Is there an efficient way to 'swap' the buffer and back buffer? If not, I'd be nice to have that.

Also, is there a better way to store an OS pic to the buffer besides
Code: [Select]
:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
I believe you are talking about the Copy() and Exch() commands.

To swap the main buffer and the back buffer, do:
Exch(L6,L3,768)

To copy picture data to the buffer, do:
Copy(Pic1,L6,768)
Title: Re: Features Wishlist
Post by: Magic Banana on July 09, 2010, 04:13:11 pm
Thanks guys. I've never really used the Exch() and Copy() commands before, but I guess they are really helpful. I should probably look into how they work.  :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 08:27:39 pm
I don't understand why so many people think that OS Var/Pic/Strc etc. is so very important? for the contest it isn't even allowed to use them i thought, or am I wrong at this point?
If any BASIC stuff is used by your contest entry, it has to be generated by Axe language (and executed with it). In other words, there wouldn't be much point in doing that for the contest since storing your save data in an APPVAR would be much smaller.
Title: Re: Features Wishlist
Post by: jnesselr on July 09, 2010, 09:09:11 pm
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string.
Title: Re: Features Wishlist
Post by: nemo on July 09, 2010, 10:25:05 pm
Quote from: graphmastur
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string.

Case in point. (http://ourl.ca/6241)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 10:32:04 pm
Keep in mind the BASIC data has to be created by the Axe entry during when we will test them, though. When the entry is submitted, external BASIC vars will be deleted.
Title: Re: Features Wishlist
Post by: nemo on July 09, 2010, 10:36:39 pm
another advantage of OS variable support would be if you were developing a basic program and had a routine that just managed/sorted data but took a long time because it's written in BASIC, you could write a quick axe program to do the same thing with the data in the basic variable, compile the program and then run the compiled axe program in the middle of your basic program to do its job in a quick way.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 09, 2010, 10:46:58 pm
True. Also, for people who want to stick with TI-BASIC because writing an Axe game is a bit too hard for them or they are more comfortable with BASIC, they can use OS variable support in Axe to write some small Axe routines that will perform stuff for their BASIC program much faster.

In the past, to do this, you either had to learn ASM or wait until someone does it for you. Now with Axe it's easier so it's much easier to write hybrid BASIC games.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 13, 2010, 05:26:53 am
Keep in mind the BASIC data has to be created by the Axe entry during when we will test them, though. When the entry is submitted, external BASIC vars will be deleted.
Is it allowed then to create a setup program to create all data? Or do we have to create a single program?

And Quigibo: could you add a fourth param to the for statement? for the step size? like:
Code: (Axe) [Select]
For(A,8,3,-1
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 05:58:35 am
Yeah I'm not sure what DJ is talking about.  Especially for large games, it will become impossible to keep all the data in a single program and it would be silly to have to package data in other axe programs just so they can be extracted.  Unless he is referring specifically to the BASIC language and not to the BASIC variables themselves which I think is what he is referring to but I'm not sure what the rules are about external data and if there are limits or not so please correct me if I'm wrong.  Its possible that external data might be forbidden, that is, entries must be a single program.

EDIT: Actually, after re-reading the rules, I think its pretty clear that you are allowed to use them as long as they're not being executed or interpreted by the OS.  So I think DJ just misspoke.

I might be able to do the increments in the for loops.  I will see if I can get them optimized enough.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 07:34:48 am
What I mean is if somebody's entry for the contest uses BASIC data that was created by a BASIC program prior the execution of his Axe entry.

External data is only allowed if it was created using Axe language.

That said, it would totally be pointless to use BASIC data in an Axe program anyway, because it would take a considerable amount of memory compared to its BASIC counterpart. I doubt someone would do this, but we never know, if for example, somebody decided to use map data in his Axe program that he previously used in a BASIC RPG, for instance, and did not feel like converting it to HEX.
Title: Re: Features Wishlist
Post by: yoman82 on July 13, 2010, 11:02:25 am
I'd say it would be my #1 concern for inline basic in axe. It'd really make the transition far easier.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 02:57:58 pm
In my opinion, we should not do anything with basic programming, because this is a new language, and it isn't a good idea to cling to the old language. The transition would be easier if you were to just learn how to use pointers. Besides, axe is a compiled language. Interpretted basic statements would not work.
Title: Re: Features Wishlist
Post by: Builderboy on July 13, 2010, 03:08:46 pm
When a program is compiled, could the compiler show how much of the program Memory and How much is Code?  This would help programers because they would know when they were reaching the executable limit, and it would help App builders to know how close they are to filling the App
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 03:19:48 pm
I can see it helping app members more.  That is not a bad idea.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 04:22:23 pm
It would still be cool to be able to use BASIC vars in Axe, though. Imagine if someone wants to create an image editor or a sprite editor that creates xLIB tilemaps, for instance, or an ASCII map editor for games like Illusiat 13. Some people may want to stick with BASIC but it would be nice if Axe utilities for BASIC programmers could be done to help them.
Title: Re: Features Wishlist
Post by: squidgetx on July 13, 2010, 04:29:40 pm
mrmrmmmrmrmm not really relevant to the current conversation, but I would like circle()r and line()r for drawing on the back buffer..:)
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 05:43:11 pm
DJ, I'm confused.  How would you be able to tell if a BASIC variable was created in Axe or not?  For instance, my music generator creates a BASIC program that can be imported into Axe but suppose someone ran out of room so just left that program in memory and read it from the main program to play the music.  That would be non-Axe generated file but definitely Axe compatible.  Or what if you typed your data file in the TI-BASIC editor and it had a similar format to TI-BASIC for whatever reason?  That would have to be allowed since its data.

The main problem with this is that Axe can generate ANY file with ANY combination of characters inside so technically all files are "Axe Created" and everyone will claim that they are.  It is extremely easy since you can just fill the Data() command with all the tokens you need and then Copy() them into the program.  I think what you're worried about most is that people will find a way to make a BASIC hybrid program somehow.  But let me reassure you this is impossible due to rule #1 since Axe will not support any commands to run BASIC programs or Assembly programs during the duration of the contest (other than the Asm() command which is forbidden).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 05:59:53 pm
If someone's data program looks like this for example:

PRGM:A
[[0,0,0,0,0,0][0,1,1,1,1,1][0,1,1,1,1,1][0,1,1,1,1,0]]

This is how you store a matrix in Ans, in BASIC. Axe data looks much different than that.

I guess you might be right that it shouldn't be a big problem, though. I just get worried because in the past, people tried to figure out loopholes in  my rules (in that case, to run ASM code without using Asm()) to use hybrid code, and I don't want something similar to happen again. I also try to take precautions in advance so when the contest ends, I don't have to disqualify full of entries because people thought they were allowed to do something.

Anyway, I noticed lately that I am getting harder and harder to be understood (including on IRC). I am not too sure why, but I am starting to question myself about my ability to communicate. I wonder if it wouldn't be best that I leave Axe help/features-related topics alone from now on?
Title: Re: Features Wishlist
Post by: Magic Banana on July 13, 2010, 06:12:22 pm
I've got a feature request: Sprite Transformations. Not the complex things like warping or skewing, but flipping and rotating tiles. I'm working on some maps, and I would like to save space by flipping tiles rather than create a whole new tile just for it. There doesn't seem to be any easy way to go about doing these things, so yeah. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 06:21:01 pm
Another feature request would be the ability to use Copy the following way, for example:

Conj(L1,L3+300)r

Instead of being forced to use pointers without any offset (like the +300), if you get what I mean.

Just an example.

The code above gives a BAD SYMBOL error, btw.
EDIT nvm, I forgot to define the size x.x, my bad
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 06:21:22 pm
The only problem with that, would be that it would most likely increase the length of the sprite routine.  I would just do another sprite.  It gives you more options that way.

[EDIT] @DJ What exactly would that do?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 06:27:36 pm
Nvm my post above, I forgot to define the size, which is why I got an error. my bad x.x
Title: Re: Features Wishlist
Post by: _player1537 on July 13, 2010, 08:16:27 pm
I seem to recall something on cemetech doing this...  I'll check real quick (in asm)

Edit: http://www.cemetech.net/forum/viewtopic.php?t=4264&sid=0d23df6917b27ead9b7f1052003327a1
Wasn't exactly what I thought it was (reverses HL, not just L) ... but meh
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:11:16 pm
@DJ, no you are being clear, I think it is me who is not being clear.  In the example you posted, if someone wants to format their data like that then that's their decision (although kind of a stupid one given you can get much higher efficiencies with your own formats).  My point was that you can't ban certain data layouts just because they resemble BASIC.

Sprite rotation is actually much trickier than flipping, those are both on the wishlist already.

Something I was wondering though, would anyone be interested in specialty sprite routines?  Sprite routines which are designed for very specific applications.  Some ideas I had were:


Would anyone be interested in any of these?  I would probably use the Plot1() - Plot3() tokens.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:13:53 pm
Can you explain the first one a little better?  I don't quite understand it.
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:25:21 pm
Here is the fruit sprite in Pyoro.

Layer 1 is 0 and Layer 2 is 0: Transparent, these pixels will be ignored when the sprite is drawn.
Layer 1 is 0 and Layer 2 is 1: A white pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 0: A gray pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 1: A black pixel will be drawn here.

Layer 1:
01110000
10001110
11100001
00010101
00111011
01101000
01111000
00110000
Layer 2:
01110000
11111110
11111111
00011111
00111011
01111000
01111000
00110000
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:28:40 pm
So would you still need to use the buffer and back-buffer?  If so, I thought this was already implemented.
Title: Re: Features Wishlist
Post by: Quigibo on July 13, 2010, 09:30:54 pm
No, currently a 3 level grayscale sprite is drawn like this:
00 = White
01 = Gray
10 = Black
11 = Black

and there is no way to do transparency without adding an extra sprite layer.
Title: Re: Features Wishlist
Post by: jnesselr on July 13, 2010, 09:37:06 pm
So no buffer/back buffer, and transparancy.  Oh yes, please implement that!  I don't know about aligned 16x16 sprites, but unaligned would work.  I really don't think unclipped sprites is a good idea, because I will probably be the first one to corrupt something.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 13, 2010, 10:06:51 pm
@DJ, no you are being clear, I think it is me who is not being clear.
Aaah ok, well I wondered because in the recent few weeks, there were often people being confused at stuff I said on IRC, so I wondered if something wrong was going on with me or something x.x. Maybe I am just a bit tired and not double-checking my stuff well enough.


3 level gs compact masking seems cool, btw. Idk about the others, though, because I expect to mostly use unaligned stuff most of the time, like in Supersonic Ball
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 01:36:13 am
All of those sprite features sound amazing! The 16x16 would definitely help for the bigger sprites, and the unclipped sprites sounds awesome for getting that extra speed. The clipping would also help and save space for making grayscale masking. Man, all of those sound great.  :D
Title: Re: Features Wishlist
Post by: squidgetx on July 14, 2010, 10:57:57 am
Unaligned sprites i think would be nice as long as they use a different command so then ppl who need to draw stuff offscreen don't get messed up w/ it.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 14, 2010, 11:10:24 am
I prefer the first, and the others I won't use very often I guess, but when it doesn't take too much time, they could also be very helpfull in certain circumstances, like you said.

BTW, how are you going to implement linking? Are you giving us the possibility to write to the linking ports like they where memory? Or will we get only the option of sending a variable item and then waiting while it is being send?

I was thinking by myself of using Send() for just writing data to the linkport, which would be usefull for music or selfmade things,
and Get() for requesting data from an other calculator, which should be in some Pause-mode or something with the command Rect(), which could be changed to React()
Title: Re: Features Wishlist
Post by: FinaleTI on July 14, 2010, 11:15:01 am
The special sprite routines sound awesome! I would love to see them implemented.
Title: Re: Features Wishlist
Post by: Quigibo on July 14, 2010, 01:14:08 pm
Ok, I think I'll just stick to the compact masking routine and not the others.  The second one is easy to make with the Axe language itself and the third is probably unnecessary.  But I did think of ANOTHER Dispgraph routine I might add.  I have too many r modifiers so it might be an o modifier but it would use the extra clock cycles, which are normally wasted, to clear the buffer at the same time as drawing to the screen so you never need a ClrDraw.  It would speed up programs using that a lot probably because ClrDraw is a slow OS routine.

Linking can work 2 ways.  You can either do manual linking; setting the individual lines high and low and writing the link routine yourself, or automatic linking; using my own assembly routines.  So I assume you are asking about my built in routine.  The way it works is that it is mostly controlled by the sender.  It is up to the receiver to check the linkport constantly to see if a byte is trying to be sent, if no byte is being sent, the linker proceeds as normal and does not wait.  The sender however will wait for the receiver to confirm that it got the message that it needs to receive the byte.  You will specify a timeout for the Send() routine so that the calculator doesn't freeze if you disconnect the other calculator.  The sending command will return a 1 or 0 depending on whether it was able to send the byte.  The receiver will return a -1 if no bytes were sent or the byte itself if one was.  I will explain it better when I actually have the commands added.
Title: Re: Features Wishlist
Post by: Builderboy on July 14, 2010, 02:19:32 pm
ClrDraw is slow?  Isnt it just a matter of 0->{L6}:Fill(L6,768)?

And automatic linking sounds like an excellent idea :) Kind of like a 1-up of Omnicalcs Linking features.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 14, 2010, 04:33:20 pm
Could u please change the Line() command to behave the same as the BASIC Line() command? I am namely converting my BASIC data to the Axe format, and I use the Line() command with it.

with 'behave', I mean which pixel is turned on when u draw Line(0,1,2,0) for example; pixel (1,0) or (1,1)
In BASIC this is just a little bit different, and therefore some of my converted graphics look ugly.

in BASIC the pixel which is nearest to the left top of the screen is set, so in my example BASIC would choose for (1,0), but Axe chooses (1,1) :(
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 05:37:54 pm
For the inverted Line, it' s a little tedious, but you can do:
Code: [Select]
DrawInv
Line(X1,Y1,X2,Y2
DrawInv
Or you can just do DrawInv once, draw all of your white lines, then use DrawInv again.
Title: Re: Features Wishlist
Post by: nemo on July 14, 2010, 08:13:51 pm
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.
Title: Re: Features Wishlist
Post by: Magic Banana on July 14, 2010, 08:56:06 pm
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.
Eh, Pxl-Change?  ???
Title: Re: Features Wishlist
Post by: nemo on July 14, 2010, 09:04:13 pm
it already has a use, so it may be a bit confusing to use. i'm not sure what token would be used, just thought it seemed like a relatively simple operation. i imagine you could do this with the exch() command and some very tricky modular arithmetic in the free RAM area L6, if anyone wants to try... i'll probably attempt later.
Title: Re: Features Wishlist
Post by: Quigibo on July 14, 2010, 09:07:14 pm
Not inverting, swapping separate locations.  Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way.  I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.
Title: Re: Features Wishlist
Post by: LordConiupiter on July 15, 2010, 01:36:48 am
Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:
Code: (Axe) [Select]
Exch(L3,L6,768)
Line(0,0,96,64)
Exch(L3,L6,768)
I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.
Title: Re: Features Wishlist
Post by: squidgetx on July 17, 2010, 08:32:19 pm
Not inverting, swapping separate locations.  Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way.  I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.

Damn.
Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:
Code: (Axe) [Select]
Exch(L3,L6,768)
Line(0,0,96,64)
Exch(L3,L6,768)
I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.

ummmm i guess...(a little sleepy right now)
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 02:19:11 am
I've always wondered, why does grayscale work on 6mhz, but not 15? It would seem like it would be so much better running on 15mhz, probably flickerless, but it just doesn't. Can anyone explain how that works? Since I'm here I guess I can request 15mhz grayscale if possible.
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 02:52:57 am
Nope, the LCD is so slow that if you try to write that data any faster than its slow speed, it causes weird graphical glitches.  Its more efficient to have the routines in 6MHz because then I don't need to add as much extra pausing code.  Even the 4 level grayscale that calc84maniac wrote was too fast for even 6MHz so I still need pauses, just not nearly as many as I would in 15MHz mode, so you end up with a routine that takes less memory.
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 03:04:11 am
Oh, that explains it. That's too bad, I could really enjoy the speed of 15mhz with grayscale graphics, but I guess I have to settle with monochrome for speed. While on the subject of grayscale, how much slower does adding extra shades of gray make drawing? Like going from 3 -> 4 or even other numbers such as 4 -> 5 and 5 -> 6?
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 03:25:02 am
All the routines are almost exactly the same speed since they are limited by the LCD speed rather than the CPU speed.  Even if I were to write an 8 level grayscale routine, odds are, it would be just as fast as the 4 level or the 3 level or the monochrome.  The only speed you would be gaining from monochrome is that you don't have to update the LCD as often.
Title: Re: Features Wishlist
Post by: Magic Banana on July 18, 2010, 03:44:00 am
Really? Interesting, I always that that it took more to draw out grayscale, with the buffers and all. So, if I were to run a program at 15Mhz, but clock it to 6Mhz when drawing, would there be a significant change in speed, or is it the drawing itself that slows the programs down so much?
Title: Re: Features Wishlist
Post by: Quigibo on July 18, 2010, 03:50:24 am
Yeah, its the drawing itself since you're drawing twice as many sprites, each one to 2 buffers.
Title: Re: Features Wishlist
Post by: Darl181 on July 19, 2010, 04:16:31 pm
New request.
When ReturnIf is called, it would be nice if the Fix tokens were taken care of automatically.
Say the person called Fix 3.
ReturnIf could do the Fix 2 on its own.
Title: Re: Features Wishlist
Post by: nemo on July 19, 2010, 04:16:35 pm
Darl181 has a neat idea in the Your Projects Post and Critique thread. (http://ourl.ca/4161/103124) his idea is to have the statement ReturnIf (and presumably Return!If) automatically set Fix # statements to their defaults. So if in a program you had Fix 1 at the beginning, if you had a ReturnIf statement, the program would automatically set Fix 1 (large sized fonts) back to Fix 0 (small sized fonts). this way you wouldn't need to use If (EXP):Fix 0:Return:End.

ninja'd by himself.
Title: Re: Features Wishlist
Post by: calcdude84se on July 19, 2010, 04:18:23 pm
That might not work, since you wouldn't want those flags reset every time you returned from a subroutine. Better is to do as I suggested (in the same thread), or possibly have a token that adds the equivalent of this code automatically.
Automatic cleanup would be nice in any form, though.
Title: Re: Features Wishlist
Post by: Darl181 on July 19, 2010, 04:25:24 pm
Beat you to it ;)
Four seconds!? wow

The return descriptions confused me for a bit.
I think I'll print out that part of the thread and put it in my binder with my commands list.
Title: Re: Features Wishlist
Post by: Magic Banana on July 19, 2010, 06:44:35 pm
Hmm, I guess what they would be looking for would be a 'reset to default settings' kind of action, which would actually be really interesting actually. Maybe have a number (not sure if all of them are taken already) which resets all of those text and drawing commands to the TIOS default so that instead of remembering what you changed and then putting a bunch of Fix # and hoping you got them all so instead of putting a combination of Fix 0 Fix 2 Fix 4 Fix 6 Fix 8, you could just have Fix 10 (or something) to make sure that all of them are default.

I guess you can always make it part of ClrHome as well, seeing as the only reason you call it is when you are closing the program.
Title: Re: Features Wishlist
Post by: Quigibo on July 19, 2010, 06:45:23 pm
@Darl That would be a huge inefficiency, but you did remind me of the fix extender idea that I forgot about.  You can reset all the fix modes at once by chaining them together like "Fix 0246" for instance to set modes 0,2,4, and 6 in a single line of code for convenience.  I might have time to add that next release.

Also another feature I will be adding is "Temporary Pointers" which are similar to static pointers.  For times when you only need to use some data exactly once, you will be allowed to do things like Pt-On(X,Y,[0123456789ABCDEF]) to both create the data in memory and return the pointer to that data in a single line.  Its just as efficient as regular static pointers but has the advantage of not taking up any extra pointer names so you are less limited by the 150 name limit.  This also will apply to Strings, Data(), and the Zeros() commands which can also be used to return temporary pointers.
Title: Re: Features Wishlist
Post by: calcdude84se on July 19, 2010, 07:15:47 pm
Cool. We can already use it with strings for Disp, but a more general application will be nice. Fix extender could be useful too, even though it only saves source code space.
As for automatically resetting flags on exit, my idea was to have the program start with
Code: [Select]
sub(M
Fix 0
Fix 2
Fix 4
Fix 6
Return
Lbl M
which would automatically reset them on exit. (Or create a dedicated token for this)
Title: Re: Features Wishlist
Post by: Tribal on July 19, 2010, 09:54:38 pm
Would it be possible to specify multiple arguments for 'Fix' say using a comma to separate each one?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 19, 2010, 10:40:41 pm
@Darl That would be a huge inefficiency, but you did remind me of the fix extender idea that I forgot about.  You can reset all the fix modes at once by chaining them together like "Fix 0246" for instance to set modes 0,2,4, and 6 in a single line of code for convenience.  I might have time to add that next release.

Also another feature I will be adding is "Temporary Pointers" which are similar to static pointers.  For times when you only need to use some data exactly once, you will be allowed to do things like Pt-On(X,Y,[0123456789ABCDEF]) to both create the data in memory and return the pointer to that data in a single line.  Its just as efficient as regular static pointers but has the advantage of not taking up any extra pointer names so you are less limited by the 150 name limit.  This also will apply to Strings, Data(), and the Zeros() commands which can also be used to return temporary pointers.
Nice ideas, especially the pointers one. I always wished I could do stuff like Text(0,0,"HI PEOPLE", because otherwise it can be a bit annoying to have to store text to pointers just to use it in the title screen options, for example.
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 10:57:06 am
Tribal: Above, Quigibo mentioned that he plans (or will consider planning) to allow chaining them like Fix 0246, which is even better than using commas. :)
Title: Re: Features Wishlist
Post by: Darl181 on July 20, 2010, 02:36:23 pm
Maybe have a number (not sure if all of them are taken already)

Aren't there some tokens left in the VARS menu?
The Window ones, for example.

I may be really behind on the poll thing ↑↑↑, but it would be nice if you could also write to OS vars.  That way, a sprite editor could store the hex code in an OS string or a picture editor save to an OS picture.
Just a thought.

Oh, and I remembered this morning about the increase in sound quality, recompiled my old sound program, and inadvertently put the headphone in my ear.  And got blasted by the volume.
Might a volume control be possible?
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 03:08:32 pm
The poll option is OS Var support, not just reading. If you're talking about "reading from archive", then no. There are very few programs that write directly to archive.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 20, 2010, 04:03:34 pm
Darl181 was the sound really that loud? Was it from a real calc? Because if I remember correctly, even with really good headphones, sound coming out of the calc link port was usually very low. You had to use loud speakers to get decent volume.
Title: Re: Features Wishlist
Post by: Quigibo on July 20, 2010, 10:25:47 pm
I've finished the popular option "OS var support".  You are now able to Create, Read, Modify, or Delete pretty much any OS variable you can think of, even obscure ones like GDBs.  The only complication right now is that it is very difficult to read or write to any structure that uses floating points like Reals, Lists, and Matrices.  I will probably have to add floating point conversion commands to simplify this, hopefully it will be in the next version, I'm not sure yet.  But for now, strings, pictures, programs, and appvars are extremely useful as external variables.  The best part is, there is no new syntax, you use the same commands you're already used to and plus the addition of DelVar which is intuitive to use.

I am also half way done with linking and I'm just about to start working on reading from archive, just have to think of the simplest possible way to approach it so its easy to use and not very confusing.  It will probably consist of a CopyToRam command and a ReadByte command for the actual reading.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 20, 2010, 10:30:56 pm
Oooh nice to hear :D. Good luck with real/list/matrices. I think for now just string and Ans support would be very good, though, for making some libraries. I hope you can figure out something easy for the other features.
Title: Re: Features Wishlist
Post by: calcdude84se on July 20, 2010, 10:49:37 pm
I'll bump this, as it relates to reading directly from archive.
Can we have a command to create a temporary RAM copy of a variable in RAM?
Maybe something like token("string"), where the command takes a string that is the name of the variable and returns a pointer to the data of the temp var, or 0 if failed (not enough RAM, variable doesn't exist, etc.)
Title: Re: Features Wishlist
Post by: calcdude84se on July 21, 2010, 06:51:00 pm
This is more like a feature retainment request than a feature request, but you could you keep the single-argument Output(?
Even if 2-argument with constants is automatically optimized, it could still be useful with certain expressions involving variables.
While I can't think of a good example off the top of my head, I'm sure one exists :P
Title: Re: Features Wishlist
Post by: calcdude84se on July 22, 2010, 09:41:42 am
And, bumping another feature request. Can there be versions of sin( and cos( that support 8.8 FP?
Title: Re: Features Wishlist
Post by: ztrumpet on July 22, 2010, 11:18:12 am
This is more like a feature retainment request than a feature request, but you could you keep the single-argument Output(?
Even if 2-argument with constants is automatically optimized, it could still be useful with certain expressions involving variables.
While I can't think of a good example off the top of my head, I'm sure one exists :P
I'd like to see the one argument Output( as well.  I use it a lot, and it should be easy to keep.  Thanks! :)
  • 3 level grayscale compact masking for 8x8 sprites.  I used this in Pyoro, it basically allows you to use the unused bit combination as an extra transparency layer so you can have automatic grayscale masking without needing an extra mask layer. 00=transparent 01=white 10=gray 11=black
  • 16x16 aligned sprite drawing.  Its a super fast and small way to draw 16x16 sprites when they're aligned horizontally and also using a more convenient array for the sprite data than trying to make 4 8x8 sprites.
  • Unclipped unsafe 8x8 sprite drawing.  Speeds up sprite drawing significantly for sprites that are always drawn completely on-screen for applications where speed really matters.  But it would crash/corrupt data for sprites drawn partly or fully off-screen
Would anyone be interested in any of these?  I would probably use the Plot1() - Plot3() tokens.
I would like all three of these.  They all sound useful, and I really want the first one. :)
Title: Re: Features Wishlist
Post by: nemo on July 22, 2010, 09:28:52 pm
i second ztrumpet. the 3 sprite features he quoted would help so much. mainly the last one, but those would definitely be something to look forward to.
Title: Re: Features Wishlist
Post by: Quigibo on July 22, 2010, 10:56:56 pm
Well the first one for sure I will add since it can be used for monochrome masking as well, but I'm still not so sure about the other ones since the 2nd one can be written in Axe and the 3rd one seems like a bad idea.  They won't be a priority right now or in a near release.

I guess I'll keep the single line coordinate method for Output() and Text() just in case.  Also, there is no reason to have a separate 8.8 routine for sin because you can do basically the same thing with this: sin(A/256)*2 The only advantage of a separate routine is to use a little bit of the decimal part to get slightly higher accuracy, but its not going to be that much better.

In other news, I've got archive reading completed and I'm rewriting the tutorial about it because there is a lot of new information to learn about, but lucky no new commands.
Title: Re: Features Wishlist
Post by: calcdude84se on July 22, 2010, 11:06:39 pm
Can't wait till Saturday! ;D
Operator overloading seems fun...
And okay for not having extended sin( and cos(, I see what you mean
Keep up the good work! :D
Title: Re: Features Wishlist
Post by: ztrumpet on July 23, 2010, 10:38:58 am
Well the first one for sure I will add...
I guess I'll keep the single line coordinate method for Output() and Text()...
I've got archive reading completed...
Yay! ;D

I wish I was here tomorrow, but it looks like I have to wait an extra week... :(

3rd one seems like a bad idea.
I think the third one is an awesome idea, just make sure to offer plenty of warnings in the readme. :D
Title: Re: Features Wishlist
Post by: Raylin on July 23, 2010, 11:45:17 pm
Was sprite rotation coming in 0.4.0?
Title: Re: Features Wishlist
Post by: Builderboy on July 24, 2010, 01:16:49 am
Sprite rotation would be extra useful.  Rotating by angles other than multiples of 90 might be extremely difficult and slow, but 90 degree rotations, and flipping as well i think would be very useful, and hopefully not to difficult to implement.
Title: Re: Features Wishlist
Post by: SirCmpwn on July 25, 2010, 03:12:15 pm
Writing to new kinds of variables would be tedious, but is already possible if you know the right way to tickle the VAT.
Also, I have a couple feature requests that would be *very* nice for a project of mine, and would probably be quite easy:
Call/Jump to addresses defined at runtime, like sub(E9D95
Access to label values, like:
Lbl A
LA->A
Where A would end up containing 9D95.
Title: Re: Features Wishlist
Post by: Builderboy on July 25, 2010, 03:23:16 pm
That should be very easy to implement, since it has a direct assembly counterpart.  Also the Label thing might also be really nice.  Whaat say you Quigibo?
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 04:17:12 pm
Forming vector tables is a very useful application of this. Even if it's a more advanced use, I'd like to see it too :)
Title: Re: Features Wishlist
Post by: Quigibo on July 25, 2010, 05:51:24 pm
I still don't feel comfortable with arbitrary jumping because its generally dangerous and isn't really useful to the average programmer.  You would have to know a lot of assembly to be able to use it and that's not the goal of the project.  You can already do that anyway with Asm(C3<Label in little endian>).

I'll eventually have a switch statement though which will be a small vector jump table to jump to a list of possible labels based on a value, but its only for labels defined in the program itself.  For instance, Switch(A,L0,L1,L2,L3) will jump to L0 if A is 0, L1 if A is 1, L2, if A is 2, and L3 in all other cases (the default).
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 05:57:48 pm
Well, for using inserted opcodes, you assume we already know the label address, which we don't :P
Switch sounds interesting, but you might want to allow an alternate format that allows choosing the values as well.
But I can understand what you're saying, and switch seems like it will be sufficient.
Keep up the good work :)
Title: Re: Features Wishlist
Post by: Quigibo on July 25, 2010, 06:13:44 pm
That is true and I was thinking about that.  Maybe I can have special opcodes in the Asm() command (kind of like how you can use pic vars in the [] command to insert pictures) but in this case to directly insert labels.  For instance, some syntax similar to this: Asm(C3"AB") would be exactly the same as Goto AB.  I mean, the only time you would even need the labels as numbers anyway is in asm code and it would be super convenient to be able to insert labels directly into the code at multiple locations and its way more customizable.  I could have insertions for other things too like the Axe variables, buffers, and maybe even axe subroutines.
Title: Re: Features Wishlist
Post by: calcdude84se on July 25, 2010, 06:44:13 pm
That sounds nice. I'd like that. :)
Title: Re: Features Wishlist
Post by: _player1537 on July 25, 2010, 10:47:27 pm
ooh, not sure if anyone else would use this, but what about installing a hook that interprets when you press ON-something, and have the something be like one or likewise.  Then when you press that key combo, compile a specific program.  Maybe ON-Sto since they are right next to each other.
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:02:21 pm
On-demand compiling?

Wouldn't that be memory-clogging?
Title: Re: Features Wishlist
Post by: Runer112 on July 25, 2010, 11:04:10 pm
Drawing sprites to an arbitrary buffer would be nice. I'm working on a game that will require at least 2 extra buffers, and I'm sure that writing my own sprite routine in Axe would be nowhere near as compact/fast as your built-in sprite drawing routine.
Title: Re: Features Wishlist
Post by: _player1537 on July 25, 2010, 11:04:52 pm
I'm sorry, what do you mean?  Basically all the feature would do is skip through the process of opening axe and going through the menu to get to your program to compile

Edit: that was @raylin, not runer
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:08:58 pm
@Runer: What you just said is an action in Axe. Look through the documentation again. You'll see it.
If not, the command is EXP->DispGraph.

@_player: Oh. Okay. You want Axe to have a hook so that you can compile quickly. I like.
Title: Re: Features Wishlist
Post by: Runer112 on July 25, 2010, 11:26:13 pm
@Runer: What you just said is an action in Axe. Look through the documentation again. You'll see it.
If not, the command is EXP->DispGraph.

@_player: Oh. Okay. You want Axe to have a hook so that you can compile quickly. I like.

Drawing sprites to an arbitrary buffer, not drawing an arbitrary buffer to the screen.
Title: Re: Features Wishlist
Post by: Raylin on July 25, 2010, 11:36:02 pm
Ah. My mistake.

*Raylin cocks a shotgun and puts his temporary dyslexia in check.
Title: Re: Features Wishlist
Post by: calcdude84se on July 26, 2010, 10:51:00 am
Could we have more pointer-specific operations, especially since a "file" is just a page-address pair?
For example, could we have an "address-of" operator that could be used on A-Z and theta (an perhaps r1 to r6 and Y0 to Y9)? (The only real application I see here is that it would make token-drawing on the graph screen easier)
And perhaps with that we could also have other means to use the "files" as generic pointers to flash?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 26, 2010, 11:50:09 am
I'm a bit confused about how to read from the Archive.  Let's assume that I want to read data from AppVar MyAppV, which is archived.  How would I do this?  And could I exploit this, possibly with some dummy entries in the VAT, to force a page swap?
Title: Re: Features Wishlist
Post by: calcdude84se on July 26, 2010, 11:55:01 am
Code: [Select]
GetCalc("appvMyAppV",Y1
{Y1-2}r-1->S
For(X,0,S
Disp {Y1+S}>Char
End
Also, as far as I can tell, the actual reading is done with a bcall (that should probably be changed), which means the page would be switched back. It could be possible, but, as above, I'd like official support for page-address pointer pairs.
Title: Re: Features Wishlist
Post by: Runer112 on July 27, 2010, 03:39:10 am
By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines.  For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer.  This isn't possible with the circle or line since the buffer is defined in the middle.  I would have to write entirely separate routines since they can't share and it would inflate the code.

Ah ha! I found it! I knew you posted something like this a while ago. It sounds like drawing sprites to an arbitrary buffer would be a pretty quick feature to implement  ;)
Title: Re: Features Wishlist
Post by: Quigibo on July 27, 2010, 03:58:16 am
Alright!  Alright!  I'll include it in 0.4.1 since you're helping me debug that other problem and since I need things to add and this is extremely easy.  The syntax will be Pt-On(X,Y,Pic1)→BUFF.  I can also use a similar technique with ClrDraw and DrawInv, but I'm not sure if I'll have time for that right now.
Title: Re: Features Wishlist
Post by: Runer112 on July 27, 2010, 05:19:50 am
Yay! :D I wouldn't worry too much about ClrDraw or DrawInv, as those can be done pretty easily and quickly anyways.
Title: Re: Features Wishlist
Post by: jnesselr on July 27, 2010, 10:51:25 am
yeah, clearing can be done by setting the buffer to 0, and inverting can be done by xor'ing all the bytes with 0xFF.  I don't really see the point, but I guess it could be useful.  So I'm guessing buff->DispGraph is for displaying?
Title: Re: Features Wishlist
Post by: qazz42 on July 27, 2010, 10:53:00 am
Safty features, I hate how if I make a disp A with no dec at the end, I am screwed with the eternal text displaying
Title: Re: Features Wishlist
Post by: SirCmpwn on July 27, 2010, 11:30:32 am
I still don't feel comfortable with arbitrary jumping because its generally dangerous and isn't really useful to the average programmer.

This is all fine, if you only want Axe to be used by the average programmer.  If you never want Axe to be used for advanced purposes, this is perfectly fine.  But getting label values with L and calling arbitrary subroutines would be quite useful for a myriad of purposes, and it would be useful for tons of competition purposes, too.  If you are concerned with people screwing it up, put it in an "Advanced Commands" section or something.  This kind of thing would open Axe up to serious programmers, for serious purposes.
Title: Re: Features Wishlist
Post by: Raylin on July 27, 2010, 01:28:39 pm
Shaky ground you treadin' on, SirCmpwn. Mind that post's sharpness.

In any case, I would suggest _player's idea of keyhooking the COMPILE command in Axe.
Title: Re: Features Wishlist
Post by: Eeems on July 27, 2010, 01:47:42 pm
That was a little sharp SirCmpwn, try to remember to remain polite. I do agree though I would like that feature.
I would also like the keyhook for compiling. :D
Title: Re: Features Wishlist
Post by: calcdude84se on July 27, 2010, 03:59:43 pm
Qazz, it only messes up what's displayed, it doesn't crash. Putting such features could be difficult because Disp A could actually be useful. Not much can be done there ;D
As for using labels literally, yeah, it probably should be reserved as an "advanced use."
The suggestions I've given (definitely "address-of" and less likely advanced operations for "files" (or what I'm calling extended pointers)) probably don't need to be given any "advanced" label, though.
I agree a keyhook to compile would be nice. :)
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 05:24:48 pm
This is all fine, if you only want Axe to be used by the average programmer.  If you never want Axe to be used for advanced purposes, this is perfectly fine. This kind of thing would open Axe up to serious programmers, for serious purposes.

Calm down SirCmpwn, this is Quigibo's program and he's going to support the features he deems necessary.  He is keeping in mind all of his users, and if he doesn't support a feature you want, dont get angry.  It really has very little practical support and could cause more trouble than its worth.  If you really need it super badly you can always write some Asm code to do it for you, Axe is as advanced as you make it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 27, 2010, 06:06:27 pm
I think if advanced commands are added, there should be an advanced section and a warning that those commands are only for experts. Maybe in a different readme file or something. Axe is meant for people who want an easy language like TI-BASIC, so hard commands should probably have a special section. That said, those commands are not a priority at the moment, I think, since Quigibo is focusing on the ease-fullness. I personally find fixed points hard enough x.x so I stayed away from them.

After the new token thing, I learned that it would be best to let Quigibo add features in order he decides to add them or that he wants the majority to add them (poll). I think it is already pretty good, else it would never have been featured on ticalc.org and it would not have 6000 posts. It's not a good idea to badmouth him for not wanting to add a feature, not that it would make the feature get added necessarly, anyway.
Title: Re: Features Wishlist
Post by: Quigibo on July 27, 2010, 06:17:36 pm
Well I didn't find it that rude, and its nice to see some criticism for a change, I was getting worried  ;)

There are a few technical considerations because its not as simple as a number substitution since the labels aren't actually well defined until the end of the first pass, so its a little more difficult.  That also means the "label values" start using up the available space for label names (there is a 150 name limit for labels).  Secondly, just getting the value of the label is not very useful unless you can actually jump or call to that address.  I'd like to see you propose an intuitive syntax for that since I can't think of a good one off the top of my head.  Lastly, it allows for arbitrary execution of assembly code which is against the rules of the contest if that's what you were planning to use it for.

EDIT: Also, I reset the poll since it was getting old and moldy.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 27, 2010, 06:22:21 pm
Yeah it would be against the rules. There are actually other ways to run ASM, too, apparently, as player mentionned to me once, but that would still be against the rules, too (same for every potential exploits people find)

As for features, you should add 64 level grayscale, pixel shading/ambient light 3D textures and 150 MHz Nspire 84+ emulation mode to the poll.
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 27, 2010, 07:20:12 pm
I'm still waiting for mutliplayer linking, so I voted that way again. I expect that more people will want sprite rotation though. =)
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 07:24:41 pm
I chose sprite flipping :]
Title: Re: Features Wishlist
Post by: nemo on July 27, 2010, 09:16:53 pm
same with me, builderboy. two more features i can add to my tilemapping program (:
Title: Re: Features Wishlist
Post by: Builderboy on July 27, 2010, 09:44:36 pm
I have another feature request.  Could it be possible to support every single character token in the String conversion routine? It would be handy to not have some of the characters change themselves while in Axe :]
Title: Re: Features Wishlist
Post by: jnesselr on July 27, 2010, 10:08:24 pm
What about USB support.  I know it would be difficult, but could you do it?
Title: Re: Features Wishlist
Post by: nemo on July 27, 2010, 10:18:25 pm
not sure if this is a relatively simple command, but could we have a Prompt/Input function? just like in BASIC, you have the user enter a number and it's stored to a program-specified variable.
Title: Re: Features Wishlist
Post by: alberthrocks on July 27, 2010, 10:20:28 pm
@graphmastur: Pretty sneaky. ;) Did you get any ideas for the calc side of things (assuming you know Z80 asm)?

@Quigbo: Oh yes, that's definitely a must. (nemo's idea)
That shouldn't be too hard to implement. ;)
Title: Re: Features Wishlist
Post by: Raylin on July 28, 2010, 12:06:32 am
Sprite flipping will be the $h!t.
On top of that, multiplayer linking will be so awesome...
:D

Now, if all of those features were in the next version (0.4.1)...

:D
:D
:D
Title: Re: Features Wishlist
Post by: SirCmpwn on July 28, 2010, 10:40:27 am
Well I didn't find it that rude, and its nice to see some criticism for a change, I was getting worried  ;)

There are a few technical considerations because its not as simple as a number substitution since the labels aren't actually well defined until the end of the first pass, so its a little more difficult.  That also means the "label values" start using up the available space for label names (there is a 150 name limit for labels).  Secondly, just getting the value of the label is not very useful unless you can actually jump or call to that address.  I'd like to see you propose an intuitive syntax for that since I can't think of a good one off the top of my head.  Lastly, it allows for arbitrary execution of assembly code which is against the rules of the contest if that's what you were planning to use it for.

I was just trying to make my opinion clear, not offend anyone.  Of course it is Quigibo's project, I just thought it would be cool and would open the doors to more advanced things.  This would be useful for a GUI engine, a physics engine, lots of different engines ;), and I can think of a practical application being using the Hatchet routines loaded in L1 (the code in L1 is pure Axe, by the way).  Hatchet could also use the label values to actually load the code.  It might be useful to programs to use my tilemapping routines and input routines, and all the other routines Hatchet would provide and still be valid for the contest.
As for a possible syntax, how about accessing label values with LLABELNAME (sort of like EHEX) and doing arbitrary calls with sub()r?

not sure if this is a relatively simple command, but could we have a Prompt/Input function? just like in BASIC, you have the user enter a number and it's stored to a program-specified variable.

There are a few routines that do this already, I can scrounge one up for you later today.
Title: Re: Features Wishlist
Post by: calcdude84se on July 28, 2010, 07:56:36 pm
For USB, even we ASM programmers don't completely know how it works. :P It's also significantly more complicated than the link port. (I wish Quigibo good luck if he undertakes it ;D)
With relation to an input routine, they are, well, whole routines. Since SirCmpwn said he'd make one for you, I'll leave it at that.
Title: Re: Features Wishlist
Post by: Quigibo on July 28, 2010, 11:27:41 pm
I just want to be clear about how sprite rotation and flipping will work because I don't want people thinking its something that its not.  The commands take 1 argument; the pointer to the 8x8 sprite and the return argument is a pointer to an 8 byte buffer in an unused safe ram area outside of L1-L6.  This area holds a copy of the "new" sprite after the transformation.

Code: [Select]
Pt-On(X,Y,FlipH(Pic1))
I was originally thinking of having a second argument allowing you to specify what area of ram to use as the temporary buffer, but then I realized that it would be easier to use, smaller faster code, and take up no extra visible memory with the single argument instead.  The only problem though is that you cannot  nest these routines together, maybe with an exception of the flip horizontal.  Like for instance RotCC(FlipV(Str1)) will fail because the input and output buffer are the same.  Therefore, I might still have the second argument, but it would be optional.

Also, the subroutines themselves that do the flipping are around 2 sprites in size and it costs an extra 3 bytes each time you call them and is obviously slower than just using a regular pointer so you'd have to be really desperate for space with massive amounts of sprites to even consider using this.
Title: Re: Features Wishlist
Post by: nemo on July 28, 2010, 11:31:58 pm
is the following code valid?
Code: [Select]
Copy(FlipH(L1),L1,8)
Title: Re: Features Wishlist
Post by: Quigibo on July 28, 2010, 11:36:17 pm
is the following code valid?
Code: [Select]
Copy(FlipH(L1),L1,8)

Yes, absolutely.  Although this is theoretical syntax.  I haven't even chosen tokens or names or even finished most of the routines.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 29, 2010, 04:00:35 am
I voted Sprite rotating, flipping. This might come handy when we have several sprites that can be flipped. Smaller file size (although executable code size might increase slightly if the routine is large)
Title: Re: Features Wishlist
Post by: program4 on July 29, 2010, 10:20:08 am
I voted sprite rotation/flipping, because most other people chose that ;). Also, it might come in handy when you make a game that requires rotating of an object (like a ship).

Besides, multiplayer linking is only useful when you have two people, so it can wait until a later version release.
Title: Re: Features Wishlist
Post by: imPersonator on July 29, 2010, 10:20:46 am
What kind of rotation will it be?  Will it be possible to rotate 1 degree?
Title: Re: Features Wishlist
Post by: program4 on July 29, 2010, 10:27:18 am
It would be impossible to rotate an 8x8 sprite by 1 degree, because the sprite is simply not big enough. Maybe a 1 degree rotation would work for a much larger sprite, but it wouldn't look that great.
Title: Re: Features Wishlist
Post by: nemo on July 29, 2010, 04:36:27 pm
i think the rotations will be by 90°. though i would like to see 45° if possible.
Title: Re: Features Wishlist
Post by: jnesselr on July 29, 2010, 04:37:20 pm
90 degrees would probably be the easiest.  How could you do 45?
Title: Re: Features Wishlist
Post by: calc84maniac on July 29, 2010, 04:38:41 pm
It's definitely 90 degrees, considering that the inputs and outputs are 8x8 sprites.
Title: Re: Features Wishlist
Post by: nemo on July 29, 2010, 04:48:17 pm
i'm not sure how you would do it, i'm just saying that if it's possible it'd be cool to be able to rotate 8x8 sprites 45°
Title: Re: Features Wishlist
Post by: Quigibo on July 29, 2010, 09:02:33 pm
Yeah they're just by 90 degrees.  I've finished all the routines, I just need to implement the commands now.  The output sprite needs to be at least sqrt(2) times larger else there will be clipping during the rotation.
Title: Re: Features Wishlist
Post by: Quigibo on July 31, 2010, 03:22:23 am
I decided to stop the poll since I will probably have time for all 3 of those features next version.  Instead, I've decided to ask a more interesting one for a feature I don't plan on adding anytime soon if at all, but I'm very interested in what everyone will think of this.  If you're not sure what each option is referring to, all examples are the Super Nintendo versions of the game, you can see some videos of the games on YouTube to clarify.
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 31, 2010, 07:46:41 am
I personally think mode 7 would be awesome to see. I am curious though, wouldn't polygons be a bit slow?
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 10:44:39 am
Any/all of these would be amazing, but I think the one that would work the fastest and therefore have more uses is Mode 7.
Title: Re: Features Wishlist
Post by: Raylin on July 31, 2010, 10:45:36 am
^ This.

Also, I'm looking forward to some Mode 7.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 31, 2010, 10:52:01 am
Mode 7 sounds like a cool idea. Voted for it. It would be nice to see more racing games for the 83+ and maybe RPG world maps like Final Fantasy VI or Secret Of Mana/Evermore:
 

If you add Mode 7, though, I would recommend allowing the user to specify the height and Y offset of the Mode 7 display too.
Title: Re: Features Wishlist
Post by: jnesselr on July 31, 2010, 11:14:25 am
raycasting or mode 7 would be the best.  But how would you set up routines to handle it?
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 11:25:49 am
This site is aimed at the GBA, but it still wonderfully explains/demonstrates Mode 7 and provides, albeit customized for C programming and the GBA, the math behind it:

http://www.coranac.com/tonc/text/mode7.htm (http://www.coranac.com/tonc/text/mode7.htm)
http://www.coranac.com/tonc/text/mode7ex.htm (http://www.coranac.com/tonc/text/mode7ex.htm)

For Mode 7, you'd probably need something like the following:

Or you could just have the routine require all these inputted as arguments, but that would require the programmer to either give up a lot of the existing variables for this or designate annoying extra variables like {711+L1}r, {709+L1}r, etc.
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 11:53:56 am
I'm for polygons and mesh.  This, folks, is the same kind of 3D you get on a computer!  I would vote there, too, if I were you.
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 12:14:36 pm
I'm for polygons and mesh.  This, folks, is the same kind of 3D you get on a computer!  I would vote there, too, if I were you.

The question is, could you get a polygon engine to run quickly?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 12:15:15 pm
Probably not.
But it would be *sick.*
Title: Re: Features Wishlist
Post by: Runer112 on July 31, 2010, 12:20:44 pm
Admittedly, it would be sick. But unfortunately its uses would be limited due to its inability to be used in realtime games. That's why I voted for Mode 7, it's probably the most reasonable option in terms of realtime usage.
Title: Re: Features Wishlist
Post by: nemo on July 31, 2010, 12:22:34 pm
can quigibo or a mod give us the option to change our vote?
Title: Re: Features Wishlist
Post by: SirCmpwn on July 31, 2010, 12:50:35 pm
Done
Title: Re: Features Wishlist
Post by: Quigibo on July 31, 2010, 02:47:10 pm
Polygons wouldn't be that slow as long as there was a small count.  I'd imagine that you could get a decent real time game with 50 onscreen edges  with more off-screen.

By the way, I was working on a mode 7 engine myself in the actual Axe Language.  At first it was really slow, less than 1fps, but i kept doing more and more optimizations and now I can get the entire lower half of the screen in mode 7 grayscale at about 8-10 fps which definitely has game potential.  However, I don't have rotation, just translation, incline, and FOV.

If I implement any of the 3D modes, the routines are going to be gigantic (probably combined 500-1000 bytes) since I won't care about size, just speed.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on July 31, 2010, 05:09:10 pm
I think it should be fine. Such thing needs to be fast enough so I think the space it takes is worth it.

Btw, are you gonna use Calc84maniac mode 7 engine or are you making your own? His ran at like 20-30 fps I think, if not more. I think it was on SE, though.
Title: Re: Features Wishlist
Post by: Builderboy on August 01, 2010, 05:45:14 pm
3D i like the idea of Mesh and filled things, just because :P

On a separate note, i would like a request for 2 things, Libraries pleeeeeeeases :( and maybe a way to jump to certian lables from inside programs?  Like if you had a comment that was .Goto LB and you put your cursor on that line and pressed On+[anykey] it would jump to that label?  Im not sure if thats possible, just throwing that out there as a possibility.
Title: Re: Features Wishlist
Post by: matthias1992 on August 01, 2010, 06:10:31 pm
As far as 3D stuff goes, I at first voted mode7 but then revoted for polygons. I think polygons can be done if you don't have too many at the same time. I think it is just awesome if we could work with them! I can already imagine a on-calc model creator-viewer that stores models into appvars. I guess using the OP registers for the vertices would be the fastest?

mode7 has my second vote if there is such a thing. In terms of speed I still do recon it faster then poly's but it is 'less 3D' then the poly's.

Now here I am just gonna suggest something that is maybe out of bounds but I'll say it anyway. How about a combined mode7 and poly's? can you imagine a character (poly) walking around in a mode7 world? All the structures and trees would be poly's but the basic ground texture could easily be a mode7 'texture"

I am really looking forward to this!

On a side note I personally would like different tokens for Axe then for basic, but that is just me having hard times switching between the two.
Title: Re: Features Wishlist
Post by: Quigibo on August 01, 2010, 06:28:21 pm
Libraries might be possible very soon, I just need to make my code sightly more modular so I can read from multiple places at once.  I realized a while ago how complicated it would be to implement library files, so it will instead be pretty much identical to the C #include feature that directly inserts the code at whatever position you put it.  You can even put each subroutine in its own separate program.  The include files will not need Axe headers and in fact should not have them so then it doesn't crowd your compiling list.  If its not included in 0.4.2, it will definitely be in 0.4.3

The jumping idea is something I'm planning to add later.  Much later.  I'm planning on using hooks to add tons of new features to the BASIC editor (only for programs with an Axe header) like label jumping, sprite previews, calculator window without exiting, hex - binary - decimal converters, etc.  Really cool stuff, but its something I'd probably write after 1.0.0 comes out.
Title: Re: Features Wishlist
Post by: SirCmpwn on August 01, 2010, 08:21:05 pm
If you are planning those, I've always wanted to use recall like the homescreen.
For instance, pushing [2nd]+Recall should open the same text dialog, but should let you type in more than one token and execute it, and recall the answer.  I've wanted to do [2nd]+Recall length(Str1 but have never been able to.
Title: Re: Features Wishlist
Post by: Builderboy on August 01, 2010, 09:09:56 pm
The include files will not need Axe headers and in fact should not have them so then it doesn't crowd your compiling list.  If its not included in 0.4.2, it will definitely be in 0.4.3

That sounds really sweet :) I've been waiting for libraries for a long time now.  Right now i have a different system in place to go through code quickly :D I have a set of Pointers that i initialize at the beginning of m,y program, one for each subroutine.  Each subroutine its pointer at the very beginning.  By commenting out the initialization of the pointer, i can scroll to the sub instantly, which is much more useful than scrolling for a min to get to the bottom. 
 
Plus using libraries means that you can upgrade sections of code while still keeping a backup of that particular subroutine.  It all makes me very excited :)
Title: Re: Features Wishlist
Post by: Quigibo on August 02, 2010, 06:41:49 am
I just thought of something really useful that I can't believe I didn't think of before.  Its the fact that 2563 = 644.  The reason that's so important is that the labels, subroutines, and pointer names were all being stored as 3 byte entries.  Once byte for the type and 2 for the characters of the name itself.  But since I'm only using a few possibilities; letters, numbers, and theta, I can get away with storing that data in only 6 bits per entry instead of the full 8 bits of a byte.  So now the 3 bytes I was using in memory can suddenly hold 4 entries!  That means that all labels and pointers can now be up to 3 letters long instead of 2.  That one extra character actually allows you to spell comprehensible pseudo-words like sub(BUF) or Lbl MOV.  This wasn't a feature I was planning to add, but I just couldn't stop myself once I realized how easy it would be to do.

I don't think I will ever have enough RAM for the 7 character label names like I was planning unless I use the extra ram pages so this will have to do for now, at least its an improvement.

Also, I changed my mind about the Axe include files.  They will need a special header beginning with 2 periods instead of 1.  That way, you still have the Axe Tokens and eventually the Axe Editor to use when writing the subroutines.  But the extra dot will conveniently make them invisible from the compile list.
Title: Re: Features Wishlist
Post by: SirCmpwn on August 02, 2010, 08:29:39 am
I would be devastated if you started using the extra pages, which I do not have :(
Title: Re: Features Wishlist
Post by: _player1537 on August 02, 2010, 08:31:40 am
Didn't I read a while back that you might support filenames with more letters if some of them were lowercase?  Like LoseTheGame could also be called by sub(LTG)
Title: Re: Features Wishlist
Post by: souvik1997 on August 05, 2010, 02:01:01 am
Didn't I read a while back that you might support filenames with more letters if some of them were lowercase?  Like LoseTheGame could also be called by sub(LTG)

No, I don't think so.
Title: Re: Features Wishlist
Post by: Raylin on August 05, 2010, 05:39:40 pm
Custom keyhooks. Nuff said.
Title: Re: Features Wishlist
Post by: Builderboy on August 10, 2010, 12:23:50 am
When you get an Error Lable, could it tell you which Lable its missing?  The jump to Error doesn't help because it just jumps to the end of the program.
Title: Re: Features Wishlist
Post by: Runer112 on August 10, 2010, 12:35:51 am
When you get an Error Lable, could it tell you which Lable its missing?  The jump to Error doesn't help because it just jumps to the end of the program.

Looks like you're having the same problem as me, label missing errors being thrown with no missing labels to be found.
Title: Re: Features Wishlist
Post by: Builderboy on August 10, 2010, 12:48:34 am
no it was a missing label actually, and it took me ages to search through every single label individually to find the one that was missing.
Title: Re: Features Wishlist
Post by: Runer112 on August 10, 2010, 12:52:51 am
Oh, at least you could find it and fix it.
Title: Re: Features Wishlist
Post by: LordConiupiter on August 13, 2010, 04:17:02 am
someting I would like to have: when you have "prgmA01" in your code, and when you hover that with your cursor, and then press [Enter], that then the program A01 is opened. Is this possible?
Title: Re: Features Wishlist
Post by: Builderboy on August 16, 2010, 12:38:25 am
Might it also be useful when an error is produced in an included program which is archived, to say which included program the error occurred in? Otherwise it might be difficult to track down which included program is misbehaving.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 16, 2010, 01:27:28 am
As for Mode 7, I think it should probably use Calc84maniac Mode 7 engine, assuming he's willing to give the source for it. Were you planning to have 3D stuff as axioms, btw?

EDIT: MWAHAHAHAHAHA! 55555th post on the forums :P
Title: Re: Features Wishlist
Post by: Quigibo on August 16, 2010, 01:39:42 am
Not sure yet.  Most likely 'yes' as a way to promote my updated Axiom engine (which isn't near finished yet).  Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.  Luckily I found a simpler source for a different mode 7 engine and after some major optimizations, you don't notice much speed difference between this and the F-zero engine.  I found enough optimization to offset the SMC removal with even more extra speed and the Axe routines seem to suffice for the multiplication with very little speed loss.  This will of course be a "15MHz recommended" command because I can't see it playable at a decent framerate without it.

@Builderboy its possible... I'll see what I can do.
Title: Re: Features Wishlist
Post by: calc84maniac on August 16, 2010, 07:52:34 am
I think some good features to add would be the "break" and "continue" control statements (for those who don't know, "break" will exit a For, While, Repeat loop immediately and "continue" will go immediately to the next iteration of a loop)
Title: Re: Features Wishlist
Post by: calcdude84se on August 16, 2010, 08:54:38 am
Break and continue can both be done with Goto's, though official support that allows us not to use Lbl's would be nice.
Basically, seconded :)
Title: Re: Features Wishlist
Post by: ztrumpet on August 16, 2010, 09:56:59 am
Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.
I thought F-Zero was an App...  So it isn't, or is there a way to make SMC work with an App?

I agree with the break and continue statements as well. :)
Title: Re: Features Wishlist
Post by: calcdude84se on August 16, 2010, 10:20:50 am
If it is an app (I don't know), he probably copied code to RAM and executed it from there.
Title: Re: Features Wishlist
Post by: TIfanx1999 on August 16, 2010, 05:55:56 pm
Calc84maniac's is great, but it relies on too much self modifying code and unrolled loops.
I thought F-Zero was an App...  So it isn't, or is there a way to make SMC work with an App?

I agree with the break and continue statements as well. :)
It is an app, and it does. There was some discussion about this on IRC. Apparently F-Zero itself wouldn't be adaptable simply because of how it was written.
Title: Re: Features Wishlist
Post by: Quigibo on August 17, 2010, 01:40:35 am
Well the demo that I downloaded was a program.  Its still available to download on his website I think.

I've been really busy this week so far and I'm leaving for school soon so I'll try to get a new version up soon, but not much new stuff will be added.  The one thing I have had time for though is a complete example game which I'm about halfway though, it will be the final example program and downloadable individually as well.  It's based on another game from Warioware that no one's heard of and its coming along very nicely.

Initially, I though I would have the final release nearly complete around this time, but I've decided instead to continue working on this a little more instead of compromising features.  Updates will be more sparse though since college is starting again but I plan to finish around the time of the contest deadline or shortly after.  There will still be updates after that, but I want a very stable, safe, and bug-free version out by then which will be 1.0.0
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 07:38:25 am
How about linking support for sending 2-byte numbers.
Title: Re: Features Wishlist
Post by: Builderboy on August 17, 2010, 03:52:48 pm
That could be easily written in Axe itself i would think, just send the 2 bytes of the 2 byte number.  However, it would be nice to automate the process :)
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 07:44:55 pm
Oh, so if I did

Send({L1},1000)
Send({L1+1},1000)

that would send the 2 byte number?

Would Send({L1}^r,1000) work?
Title: Re: Features Wishlist
Post by: SirCmpwn on August 17, 2010, 07:48:06 pm
The second one, I don't think would work.  Actually, I don't think the first one would, either.  I haven't played with this yet, but you can only muck around with the two available bits, if I remember correctly.
Title: Re: Features Wishlist
Post by: calcdude84se on August 17, 2010, 08:06:34 pm
Send( is a linking routine to send one byte :)
The first one is fine, and the second calc will have to do something like Get*256+Get to get the result, though the Send('s will need to be in the reverse order (high byte first)
Title: Re: Features Wishlist
Post by: ACagliano on August 17, 2010, 08:18:53 pm
ok. No, what happens if I run send on sender but don't do Get on reciever. Will reciever still recieve data?

Note to Quigbo: Can we try for a command to send 2 byte data?

Also can someone give me the HEX for an asm subroutine that emulates Basic's Input command? And tell me where it saves the input so that I can access it using Axe coding?
Title: Re: Features Wishlist
Post by: nemo on August 18, 2010, 12:55:11 am
Cagliano, what sort of input are you looking for? there's a topic under the axe parser subforum i made that has some code that accepts numbers 0-65535, unless you need string and list support.

also, i'm still begging for a pxl-swap() command. i know it can be implemented easily, but i think some pretty neat effects could be achieved with it.
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 01:58:57 am
I forgot to address the break and continue idea.  Those are both definitely possible, it could even be used in If and Switch statements which would be cool.  Finding a token in a convenient menu might be a challenge though.

Sending multiple bytes is simple, I tested a program that sent the entire graph buffer from one calculator to the other and it took less than half a second.  In fact, it is easier and more reliable to send a section of ram than to send individual values so I would recommend that you store all your sending values in consecutive ram addresses to make it easier.

Pixel swap might be nice, but I don't have a good token for that.  Maybe I can put it in the same place as Pt-Mask.
Title: Re: Features Wishlist
Post by: Runer112 on August 18, 2010, 04:15:13 am
Goto r and Endr?
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 04:41:32 am
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
Title: Re: Features Wishlist
Post by: Runer112 on August 18, 2010, 05:12:27 am
The main reason I'm suggesting that is because, although custom Axe tokens are nice, it's always a pain in the ass to try to write Axe programs on a computer. Some tokens are completely unrelated to what they do. Like the Port command, I can't even remember it now despite having used it multiple times. I always have to look it up every time I want to use it.
Title: Re: Features Wishlist
Post by: ACagliano on August 18, 2010, 12:00:03 pm
Cagliano, what sort of input are you looking for? there's a topic under the axe parser subforum i made that has some code that accepts numbers 0-65535, unless you need string and list support.

I'm looking for string input actually. I want a user input string which i can then use in Axe's GetCalc( command.
Title: Re: Features Wishlist
Post by: ztrumpet on August 18, 2010, 01:13:52 pm
By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
I think this is a great idea.  I'll green light it. :)

Can we have Break, Continue, and, since you brought it up, can we please have Switch?  I'd love making Switch structures in Axe!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 18, 2010, 02:21:09 pm
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.
That would be fine as long as those changes aren't too drastic. Example: no massive command changes making it even harder to search for commands in the CATALOG (like Rect() and RectI())
Title: Re: Features Wishlist
Post by: calc84maniac on August 18, 2010, 02:24:12 pm
I forgot to address the break and continue idea.  Those are both definitely possible, it could even be used in If and Switch statements which would be cool.  Finding a token in a convenient menu might be a challenge though.
I would say don't make Break exit just the If statement, but instead make it exit the loop outside. Otherwise you couldn't conditionally Break :P

Break should probably be required after each case of a switch statement of course, unless you want to the code to keep running into the next case (which might be useful actually).

Basically just do it like C, lol :P
Title: Re: Features Wishlist
Post by: Quigibo on August 18, 2010, 02:40:14 pm
Well I was thinking of instead of having just "Break" and "Continue", I also have "BreakIf" and "ContinueIf" as well as their conjugates since then they can be used in conditionals because I think that feature would be nice and this way the assembly is more optimized anyway than having a separate conditional.  Also, I'm not even sure how I could make it break out of multiple levels of nested statements anyway with the way I currently handle nested blocks.

My switch command is going to be really different as well.  I need it to be optimized enough where it is much more favorable to use so I think there will be no switch statement, only case statements.  For instance:

Code: [Select]
:
:A*12+(B/8)         .The last expression used becomes the switch statement automatically
:Case 0
:  .Function1
:Case 83
:  .Function2
:Case -1
:  .Function3
:End
:

The look-ahead parsing to pregenerate a jump table would be messy and memory hungry so I'd have to see how feasible it is.  So that means I am still unsure if automatic breaks would need to be implemented or not.  I'm also unsure if I want to make this command a single byte only command since it could lead to a huge optimization
Title: Re: Features Wishlist
Post by: ztrumpet on August 18, 2010, 03:23:38 pm
I think doing switch, continue, and break like that are all good ideas.  My only request is to allow a "Default" case in the switch structure as well. :)
Title: Re: Features Wishlist
Post by: LordConiupiter on August 18, 2010, 03:37:34 pm
The "Default" could be written like "Case ?" or perhaps "Else"?
Title: Re: Features Wishlist
Post by: ACagliano on August 20, 2010, 07:25:18 am
See the TI-Basic code below:

Code: [Select]
"HELLO"->Str1
Str1+" WORLD"->Str1

Can this be done in Axe? How?


And, as for the Bitmap( command, it says the structure pointed to should be width x height x rows of img. What does this mean exactly? Let's say I wanted a blank sprite that is 7x7 pixels. How should my arguments for Bitmap look (The X and Y can be an arbitrary X and Y)?
Title: Re: Features Wishlist
Post by: calc84maniac on August 20, 2010, 08:25:50 am
See the TI-Basic code below:

Code: [Select]
"HELLO"->Str1
Str1+" WORLD"->Str1

Can this be done in Axe? How?


And, as for the Bitmap( command, it says the structure pointed to should be width x height x rows of img. What does this mean exactly? Let's say I wanted a blank sprite that is 7x7 pixels. How should my arguments for Bitmap look (The X and Y can be an arbitrary X and Y)?
Here's a way to do what you said, I think. Note that extra data bytes are inserted after Str1 is defined. This is important! Otherwise the new data at Str1 would overflow into other data.

Code: [Select]
.Data initialization
"HELLO"->Str1
Zeros(6)
" WORLD"->Str2

.Code to append Str2 to Str1
.Copies length(Str2)+1 bytes to include null terminator
Copy(Str2,length(Str1)+Str1,length(Str2)+1)

Edit:
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 09:42:32 am
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
O.o

I'd like them too, but only if they are used wisely.  I'll like the extra RAM. :)
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 12:03:26 pm
Here's a way to do what you said, I think. Note that extra data bytes are inserted after Str1 is defined. This is important! Otherwise the new data at Str1 would overflow into other data.

Code: [Select]
.Data initialization
"HELLO"->Str1
Zeros(6)
" WORLD"->Str2

.Code to append Str2 to Str1
.Copies length(Str2)+1 bytes to include null terminator
Copy(Str2,length(Str1)+Str1,length(Str2)+1)

So, that takes Str1 and adds it to Str2? Writing it into my calculator with a Disp Str2 doesn't return "Hello World"
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 12:07:22 pm
So, that takes Str1 and adds it to Str2? Writing it into my calculator with a Disp Str2 doesn't return "Hello World"
You need to do Disp Str1. :)

Before that the memory looks like this:
"HELLO",0,0,0,0,0,0,0," WORLD",0
After that, the memory looks like this:
"HELLO WORLD",0," WORLD",0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 20, 2010, 12:15:50 pm
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)
To insert stuff at a memory address and offsetting some of the stuff below, right?
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 12:50:04 pm
You need to do Disp Str1. :)

Before that the memory looks like this:
"HELLO",0,0,0,0,0,0,0," WORLD",0
After that, the memory looks like this:
"HELLO WORLD",0," WORLD",0

I suspect something might be wrong with my calculator, then. The code I put in was

Code: [Select]
.AB
"Hello"->Str1
Zeros(6)
" World"->Str2
Copy(str2,length(Str1)+Str1,length(Str2)+1)
Disp Str1
While getkey=/=9
End

What I get back out is a blank line where Str1 should be displayed.
Title: Re: Features Wishlist
Post by: Quigibo on August 20, 2010, 01:35:59 pm
That code should work.  Are you sure you recompiled it after making changes to the source?

The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.

By the way, I happened to stumble upon an undocumented bcall on brandonw's website that is nearly identical to BASIC's "Input" function, and so I've added that functionality now.  The way it works is that it stores the input to a temporary string in ram and returns the pointer to it just like you would read any other external string.  The only difficulty is that similar to strings, its token based instead of character based so anything that's not a number or uppercase letter has to be converted.
Title: Re: Features Wishlist
Post by: AngelFish on August 20, 2010, 01:43:28 pm
Yep, it was recompiled. Looks like I'll have to just hope other calculators can understand if I ever use that in a program.
Title: Re: Features Wishlist
Post by: ztrumpet on August 20, 2010, 01:58:18 pm
The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.
Yes but working at a fixed address would be faster, and I'm all for more speed. ;D
Title: Re: Features Wishlist
Post by: Runer112 on August 20, 2010, 02:40:28 pm
I'd really like InsertMem and DelMem. I'm currently working on a project that stores data in an appvar that can get very large and change size, and there may not be enough RAM to make a whole other appvar of the new size to coy the data into.
Title: Re: Features Wishlist
Post by: Builderboy on August 20, 2010, 05:18:13 pm
Break and Switch are great ideas in my mind.  I also was visualizing some sort of breakpoint command?  Where you could pause execution, view the variables, and do other sorts of things.  Its highly conceptual right now though, what do you guys think?
Title: Re: Features Wishlist
Post by: Deep Toaster on August 20, 2010, 05:36:10 pm
Switch would be a great addition, but don't know about break. We could always just Goto our way out of the loop.
Title: Re: Features Wishlist
Post by: calcdude84se on August 21, 2010, 11:29:00 am
That, however, requires extra labels, and remember, Goto is bad :P
Edit: It's less that Goto is bad than we have to come up with extra label names for somewhere we shouldn't need to :)
Title: Re: Features Wishlist
Post by: LordConiupiter on August 21, 2010, 02:11:53 pm
Could you perhaps impelement "Goto End" as Break? on this code it would jump to the next End that is read. Is that a good idea?
Title: Re: Features Wishlist
Post by: calcdude84se on August 21, 2010, 03:43:14 pm
That sounds like it could work. Though it wouldn't necessarily be the next End, since If's don't count, not being looping constructs.
Also, it would be nice to be able to specify how far out to go, possibly like "Goto End(3)" to break out of three loops. (This is constant, of course. "Goto End(X)" won't compile, just like "getKey(X)" won't.)
What token would work after Goto for a continue, though, since there's more than one looping construct?
Title: Re: Features Wishlist
Post by: calc84maniac on August 21, 2010, 05:02:59 pm
The InsertMen and DeleteMem commands I was considering to add at one time, but then I realized that you can do basically the exact same thing by creating an appvar, string, program, etc. in ram and then delete it when you're done to get a quick temporary variable without any extra syntax.
But this doesn't allow me to, for example, create a program and write a variable amount of data into it. I would have to create a whole new program every time, copy over the old data, and delete the original. I'd rather just like to be able to insert or delete memory as I need to.
Title: Re: Features Wishlist
Post by: LordConiupiter on August 23, 2010, 09:15:55 am
That sounds like it could work. Though it wouldn't necessarily be the next End, since If's don't count, not being looping constructs.
Also, it would be nice to be able to specify how far out to go, possibly like "Goto End(3)" to break out of three loops. (This is constant, of course. "Goto End(X)" won't compile, just like "getKey(X)" won't.)
What token would work after Goto for a continue, though, since there's more than one looping construct?
Can't "Goto End(EXP)" also be used for If's? that would perhaps be more convenient for the compiler, but of course I don't know how the compiler exactly is handling End commands...

perhaps the token "Connected" could be used for continue? and otherwise "IS>("? that would be handy because of it's location (prgm -> A)
Title: Re: Features Wishlist
Post by: calcdude84se on August 23, 2010, 09:48:04 am
An indexed Connected would be nice, and the name could be changed. As for "Goto End" taking If's into account, I guess that would be okay if it makes things easier for the compiler. I don't know how it works internally either ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on August 25, 2010, 02:01:12 pm
An indexed Connected would be nice, and the name could be changed. As for "Goto End" taking If's into account, I guess that would be okay if it makes things easier for the compiler. I don't know how it works internally either ;D

But then there's the problem of nested loops having the same expression. Stuff like
Code: (Axe BASIC) [Select]
...
:While U>4
:U-1→U
:While U>4
...

Obviously, this probably isn't the best example :P but there are times when someone'd need two loops with the same condition. It'd be a lot easier to just put an extra label at the end and Goto it when we need to for a break, or do it at the beginning of the loop for a continue. Labels don't add to the executable size, anyway, and I don't think there are any problems with Goto'ing out of a loop...
Title: Re: Features Wishlist
Post by: calcdude84se on August 25, 2010, 09:58:52 pm
I'm not sure how that would prevent it :)
As for just using Goto, yes, it's the same size, but it's more convenient to have break and continue :)
Title: Re: Features Wishlist
Post by: andrepd on August 26, 2010, 12:12:51 pm
Tilemapping is a must. Even though with good optimization it is possible in axe, programming it natively in Asm and implementing a command for it is, of course, easier and *much* faster...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 26, 2010, 12:49:54 pm
I think it depends, though. I recall some functions weren't much faster and smaller when done automatically rather than manually, simply because they were the exact same thing. However, writing a tilemapper can be hard, especially with half-byte compression, some people struggle at it and I feel that since Axe is game-oriented, it would be a very nice feature to add to 1.0.0 or 1.0.1
Title: Re: Features Wishlist
Post by: kindermoumoute on September 04, 2010, 06:39:24 pm
I wonder if we could manipulate variables Pic of the calculator, because it did not seem to have been added (from the documentation).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 06:43:47 pm
I am curious if this could be added as well. Right now it's possible to just use DispGraph then run a BASIC program to store to a pic var, but that won't let us store to hacked pics... not to mention it would be nice to do in pure Axe, too.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 07:20:45 pm
Yeah, storing hacked pics would be amazingly useful, especially if we could get them to store the 64th row. That would make Pokemon TI's tile data a heck of a lot smaller.
Title: Re: Features Wishlist
Post by: Quigibo on September 04, 2010, 09:44:25 pm
I'm not quite sure what you mean, you've been able to read/write/create/delete/modify pictures of any size for a long time now...

If you want to create a picture Pic1 that is 64 rows long, you can do this:
Code: [Select]
If GetCalc("Pic1",768)->A
  .Modify the picture here
End

You can even make the pictures ridiculous sizes and it should still work.
Title: Re: Features Wishlist
Post by: nemo on September 04, 2010, 09:46:22 pm
quigibo, we can even access others besides pic0 - pic9? also, can we make pictures that are 3072 bytes, or four screens large?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 09:47:08 pm
I think what he wants is to store actual 8xi files using Axe Parser. In BASIC you would do Storepic 0 through 9. He wants to be able to do the same in Axe. He didn't meant Pic1 as an Axe pointer, but rather the actual TI-BASIC files.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 09:53:46 pm
By hacked pictures I meant pictures number 11-255. They show up with random tokens as their names in the memory menu.
For example, Pic11 would be GDB1. You can use hacked pics with xLib and Celtic III, but currently they can only be stored without the 64th row. If Axe supported the ability to write to (or read) hacked pics, you can then use the full pic to store tiles and sprites, which would be extremely useful.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 09:54:47 pm
An example of game using them is Reuben Quest The Lost Mirror and Zelda Dark Link Quest. Only difference is that both games use Zpic to call them, as xLIB APP didn't exist back when they were made.
Title: Re: Features Wishlist
Post by: Quigibo on September 04, 2010, 10:08:46 pm
@FinaleTI
Oh I see.  Yes, you can read and write to hacked Pictures as well, but you have to use the hex codes since you can't type it in.

Code: [Select]
GetCalc([0760]Data(#,0))->A

To return a pointer to the hacked pic # (in decimal)

@DJ
I'm not talking about a static pointer either, that's the actual OS picture.
Title: Re: Features Wishlist
Post by: FinaleTI on September 04, 2010, 10:22:26 pm
OK. Thanks.
This should be a big help with saving space with the tiles for Pokemon TI. ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 10:23:40 pm
Oh ok, sorry if I was confused. I haven't used Axe in a while x.x
Title: Re: Features Wishlist
Post by: Builderboy on September 04, 2010, 10:42:11 pm
Hey thats good to hear that Axe can support arbitrary sized hacked pictures :)
Title: Re: Features Wishlist
Post by: Deep Toaster on September 04, 2010, 11:16:51 pm
Hacked pictures! Are they allowed for the contest, seeing as we need to type pure hex?
Title: Re: Features Wishlist
Post by: Jonius7 on September 04, 2010, 11:24:26 pm
hacked pictures, that doesn't sound right for the contest, doesn't that bypass the hard work of typing code?
(now i have 20 posts! yay!!! now i can chat at the top of the page!)
Title: Re: Features Wishlist
Post by: calc84maniac on September 04, 2010, 11:25:16 pm
Hacked pictures! Are they allowed for the contest, seeing as we need to type pure hex?
Should be allowed, because the hex is not asm code.
Title: Re: Features Wishlist
Post by: nemo on September 04, 2010, 11:28:00 pm
Pitures just contain data... It wouldn't matter if it was allowed in the contest since they're just an alternative to using data() or [hex]
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 04, 2010, 11:38:48 pm
Yeah they are allowed, just as long as you aren't using any form of data to execute ASM code
Title: Re: Features Wishlist
Post by: nemo on September 06, 2010, 01:58:30 am
would it be unreasonable for an operator to get the half-byte of a location? maybe {PTR}#^r where # is 1-4, which half-byte you're trying to access?
Title: Re: Features Wishlist
Post by: calcdude84se on September 06, 2010, 02:45:48 pm
That could be made more generic :)
Perhaps something like EXPR!#, where EXPR is any expression, ! is the factorial symbol, and # is a constant or variable between 0 and 3 indicating what nibble.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 06, 2010, 02:54:13 pm
or perhaps EXPR[ # ], like arrays? EXPR would be the pointer to the data, and # could be any number/variable with any value. and when that's unrealizable, just constant 0 - 3.

a feature request: when I currently want to draw an Inverted Rectangle, I have to do:
Code: [Select]
Rect(X,Y,W,H
RectI(X,Y,W,H
could you change invT( in the 2nd DISTR menu to Inv, so that we can type InvRect(X,Y,W,H)? or would this be too much work?

another thing I suddenly thought of: could DelVar perhaps be changed to DelCalc(, since it is a member of the Calc var handling system? IMO it would be nice to have GetCalc( and DelCalc( look similar, because of the same Syntax and use.

and the PTR in the documentation used in the External Variables part for GetCalc(PTR) is not the same PTR as for float{PTR}, or am I wrong at this point? Else it would perhaps be more consistent to use EXPR in stead of PTR.

one last note: in the documentation it says: Sub(, but in the editor it is sub( with a lower case S.
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 12:39:56 am
It would be nice to be able to initialize a program whether Axe or BASIC without having the compiler put the code for the secondary program into the compiled code. For example, this would allow end users to install only the levels for a game that they have the memory to run. It would also open up the possibility of creating a base program to which one can add modules for different functions.

It's clearly possible in Assembly since BASIC is simply interpreted Assembly, but I don't know if it could be implemented efficiently in Axe.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 07, 2010, 01:41:16 am
ninja'd? or double post? ;) was the site acting weird, or is this message that important to you, so you posted it twice?
Title: Re: Features Wishlist
Post by: Builderboy on September 07, 2010, 01:45:24 am
That is an interesting double post o.O not sure what the site policies are about that XD
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 04:09:52 am
I think he might have hit Post twice. I think the site is a bit slower when sending posts, tho, nowadays, so people may click again when nothing happens.

Fixed
Title: Re: Features Wishlist
Post by: Ikkerens on September 07, 2010, 10:40:26 am
It would be nice to be able to initialize a program whether Axe or BASIC without having the compiler put the code for the secondary program into the compiled code. For example, this would allow end users to install only the levels for a game that they have the memory to run. It would also open up the possibility of creating a base program to which one can add modules for different functions.

It's clearly possible in Assembly since BASIC is simply interpreted Assembly, but I don't know if it could be implemented efficiently in Axe.

Seconded, running out of space on my app.
Title: Re: Features Wishlist
Post by: Raylin on September 07, 2010, 12:04:10 pm
Quintuple post?! o.o
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 12:16:05 pm
Fixed. Qwerty.55, when the forum doesn't respond when you reply, do not click submit again. Copy your post in your clipboard or in another application, then after 30 seconds, hit refresh in your browser. If your post won't show up on the last topic page, then paste your post and try submitting again.
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 03:08:19 pm
I'd try that advice if I hadn't already tried it. The last multiple post was the result of one submission. I pressed the button and didn't touch my phone until it had sent it. I mean that literally. I set the phone down on my desk and watched it. I think I'll just stick with a computer from now on.

PS: I tried to delete all of the extra posts I had made. Apparently I missed a few.

Sorry.


Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:09:45 pm
Weird, might be a bug or something with the phone app x.x

Don,t worry though, as some of us deleted the extra posts
Title: Re: Features Wishlist
Post by: AngelFish on September 07, 2010, 03:23:37 pm
Wouldn't surprise me. My luck with software as of late has been less than desirable to say the least.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:24:28 pm
That happens x.x

In my case it's when I code site-related stuff or update. Usually it turns out to be a major failure x.x
Title: Re: Features Wishlist
Post by: Ikkerens on September 07, 2010, 03:37:27 pm
That happens x.x

In my case it's when I code site-related stuff or update. Usually it turns out to be a major failure x.x

Lol, thought you were quite capable of doing things (looking at what you've achieved already)
If you ever need help with PHP/HTML/CSS/JS, just say the word
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 03:45:14 pm
Oh I know how to code BASIC and some Axe, but site design is not my cup of tea. I don't like it much. I sometimes have an urge to do some artwork, hence the new forum theme, but it took me over 2 weeks to design the style sheet x.x

That reminds me, would triple buffering, at the cost of the 27 real variables, be easy to implement? (It would use L1, L3 and L6) Useful for 8 level grayscale
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 07:00:55 pm
That could be made more generic :)
Perhaps something like EXPR!#, where EXPR is any expression, ! is the factorial symbol, and # is a constant or variable between 0 and 3 indicating what nibble.

You could always use ^ and / ;)

But it might be a good idea to make things clearer. Maybe [PTR].[NUM], since periods aren't really used right now? It would make sense, anyway, since it kinda means a part of the number.
Title: Re: Features Wishlist
Post by: Builderboy on September 07, 2010, 07:13:25 pm
I think it would be useful only if it was the variable part?  Since if it was constant, using / or ^ would be a bit easier.  Using it as a variable could be useful for half byte tilemapping
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 07:26:59 pm
And even if it were a variable, / and ^ are pretty easy to use. For the high nibble, it's [EXP]^16, and for the low one, it's [EXP]/16. I think the original idea, though, was to make one that would be easier for two-byte numbers, since to get the low nibble of the high byte of A, it would be A^256/16 now. The only reason I can see of adding such a command would be to make things easier to figure out :P
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 08:19:33 pm
I think it would be useful only if it was the variable part?  Since if it was constant, using / or ^ would be a bit easier.  Using it as a variable could be useful for half byte tilemapping
Exactly. You can't really have something that returns the upper nibble if X is 0 and the lower if X is 1 inline in an expression, can you? ;D
Title: Re: Features Wishlist
Post by: Quigibo on September 07, 2010, 08:48:29 pm
What about an alternative half byte referencing command?  I imagine that's what it would generally be used for anyway, so just take out the middle man.

Say I call this command nib{} which uses angle brackets like int{} since it's a referencing command.

[C0FFEE123456]->Str1
nib{Str1*2}   .returns C (12 in decimal)
nib{Str1*2+1} .returns 0
nib{Str1*2+2} .returns F (15 in decimal)
nib{Str1*2+N} .returns the Nth nibble in memory


The only strange thing you might notice about this is that the pointer has to be multiplied by 2.  That's because wherever it points to is in bytes so if the pointer is at the 100th byte, it is actually at the 200th nibble.  That's done during compile time in this case so its not going to increase program size or anything.  But now there are 131,072 (2^17) possible addresses, and so that means you can only use this command for half of the memory.  Ram is in $8000-$FFFF which is exactly the range needed.  However that would suck for apps because they need the other half from $0000-$7FFF.  To remedy this, there would be 2 commands, one for programs/ram/archive and one for apps.  So nib{} and nib{}r would work.

Would this be suitable?

EDIT: Oh, there could also be a store-to version for ram, like 5->nib{Str1*2+2} for instance.
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 09:14:00 pm
That sounds like it'd work nicely :)
I say go do it! :D
Title: Re: Features Wishlist
Post by: Deep Toaster on September 07, 2010, 10:08:49 pm
Yep, that'd be great. What token will this replace?
Title: Re: Features Wishlist
Post by: Runer112 on September 07, 2010, 10:10:23 pm
Any chance of grayscale routines that play nicely with interrupts? I don't really mind if they're slower. Slower but more regular is better as far as I'm concerned.

Edit: Perhaps this could be implemented with a toggle in the Axe options menu? There must be grayscale routines out there that don't kill interrupts, right? Maybe just grab one that looks decent, tweak it a little bit for Axe, and (hopefully) not have to work too much on it.
Title: Re: Features Wishlist
Post by: calcdude84se on September 07, 2010, 10:10:44 pm
What about iPart(? It's in the math menu near float{ and whatnot.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 07, 2010, 10:15:28 pm
A nibble command would be nice. It would make it much easier to deal with half-byte tilemappers, especially those who have an harder time being experienced with Axe.
Title: Re: Features Wishlist
Post by: Quigibo on September 08, 2010, 12:34:33 am
@Runner, yes, I fixed that now.  I decided to keep the grayscale routine unchanged since that is most critical and just change the interrupt routine to push and pop the af register pair instead of saving it to a shadow register.  Its exactly the same size as before now and unnoticeably slower.

Just an fyi to all you asm programmers, I was able to save one byte from each call to Copy(), Fill() and Exch() using an optimization I hadn't considered before.
Code: [Select]
this:
  ld   b,h
  ld   c,l
  pop  hl

can become:
  ex   (sp),hl
  pop  bc

Its slightly slower, but its one byte less.

Oh, and I finally took care of another request: dereferencing.  The routine actually already existed so I only had to add about 6 lines of code.  The new syntax for that is the degree sign followed by the variable and it will return the variable's address.  For those familiar with C, its identical to the &.

A        Returns the variable A
{A}r     Returns what A points to
oA       Returns the address of A
{oA}r    Identical to the first example

So I don't want to see anymore of that {L1-52} nonsense and no one has any excuse for being mad if I change where the variables are in the future.  This works with all variable types including files and the subroutine variables.  Also, don't forget that any dereferenced variable is a constant address just like the L1-L6 addresses so any math you do to it is done during compile time for extra optimization.
Title: Re: Features Wishlist
Post by: calcdude84se on September 08, 2010, 12:39:50 am
Nice to see address-of! Very handy, I've been wanting that for a while.
The size optimizations are nice too.
Keep up the good work! :D
Title: Re: Features Wishlist
Post by: Builderboy on September 08, 2010, 12:58:55 am
I am perfectly happy with the dereferencing :) as long as they stay in the same order ;D and awesome on the optimization!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 08, 2010, 01:03:41 am
It should be fine with me too. I only use those variables the regular way personally (1->A for example).

Also I like the address command and optimizings. Nice job as always Quigibo.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 08, 2010, 08:00:15 pm
Addresses! That'll be useful. No more subtracting from L1 :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 08, 2010, 08:58:20 pm
ANother trick would have been to simply store directly to the memory address the variables are located to, but then the issue is if this location changes from an OS to another, you risk messing up people calc if they use a different OS.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 03:28:27 am
iPart( would be a nice token for nib{ I think. could you also add a bit{ command? min( could be replaced by it. the following syntax could be used:
Code: [Select]
.bit{byteaddress, bitnumber}:

[0B->GDB1            .00001011
If bit{GDB1,1}=1    .true
Disp "last bit on!"
End
If bit{GDB1,8}       .false
Disp "First bit on"
End
Title: Re: Features Wishlist
Post by: Raylin on September 09, 2010, 04:00:41 am
Can't you do that with the Euler's constant 'e'?
Title: Re: Features Wishlist
Post by: ACagliano on September 09, 2010, 08:01:10 am
How about support for DCS icons in Axe executables?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 11:04:52 am
Can't you do that with the Euler's constant 'e'?
ow yes, youre right! thanks!

could a command be added for changing the screen intensity? perhaps lcm( could be renamed to lcd(EXPR) with expr a value from 0 to 24 or something?
Title: Re: Features Wishlist
Post by: Raylin on September 09, 2010, 11:12:32 am
That can be done with Shade(EXP).
Title: Re: Features Wishlist
Post by: LordConiupiter on September 09, 2010, 11:47:09 am
ow! how stupid am I today! perhaps I'm working too much for the contest, and sleeping too little :(

could you also add port reading in the future? I do not mean the I/O port etc, but ports like these: All ports by Address (http://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address)

EDIT:
another feature for the next Axe version after 1.0.0:
the Function command, for labels to be used as commands like subs. I'll explain what I mean with an example:
normally, when you want to use a subroutine, you do:
Code: (Axe) [Select]
sub(SUB,1,2,"HELLOL"
Return

Lbl SUB
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
but the idea of Function is that this could be done:
Code: (Axe++) [Select]
Text(1,2,"HELLOL")r
Return

Function Text(3)r
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
this is some kind of Axiom thing, but than in Axe itself, right?
could this be added in Axe++?
Title: Re: Features Wishlist
Post by: Builderboy on September 11, 2010, 06:51:43 pm
LordConiupiter, what would the advantage of using the Text() token be over using the regular sub() syntax?


Also, i just wanted to ask what the feasibility would be for Apps that have a second page for data?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 11, 2010, 07:02:39 pm
well, it is not just only for the Text token, it could be used for any token. it is just an example, which draws text to the buffer, using the r modifier. perhaps this was not the best example I could give, but it was meant to give the ability to write Axioms in Axe.
Title: Re: Features Wishlist
Post by: Quigibo on September 11, 2010, 07:29:25 pm
Probability of having a 2nd page of data is about 80% right now.  It's more difficult to find some allocated space for 2 pages and I also have several ideas of how I could implement it that I need to decide on.  Its also on the dangerous side, so I need to make sure I do a lot of debugging before I actually release it.  I think with all the things I still want to add, there might actually be more versions before 1.0 or several versions after 1.0 for followup.
Title: Re: Features Wishlist
Post by: Happybobjr on September 11, 2010, 07:31:38 pm
 me want nOOOw.... :P
:):D
Title: Re: Features Wishlist
Post by: calc84maniac on September 11, 2010, 07:33:15 pm
Probability of having a 2nd page of data is about 80% right now.  It's more difficult to find some allocated space for 2 pages and I also have several ideas of how I could implement it that I need to decide on.  Its also on the dangerous side, so I need to make sure I do a lot of debugging before I actually release it.  I think with all the things I still want to add, there might actually be more versions before 1.0 or several versions after 1.0 for followup.
For extra pages of data, you can just save directly to the flash. The data won't ever change after its definition. This way we can have apps as big as we want.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 11, 2010, 11:22:11 pm
I agree it will need a lot of debugging, in case it messes up people flash rom x.x. I assume it will be another closed beta testing run?

It would be awesome to have 2 flash pages, tho, because some people use APPs to get around the 8 KB code limit, but then have to split most of their data in appvars due to the 16 KB limit including data too x.x

Good luck Quigibo!
Title: Re: Features Wishlist
Post by: Builderboy on September 12, 2010, 02:32:14 pm
2 Page Apps sound awesome :D I cant wait for them to be implemented!! ^^ and if what calc84 says is true (and i think i have reason to believe so :P) then could this be a soon to come feature? 
Title: Re: Features Wishlist
Post by: kindermoumoute on September 13, 2010, 03:23:32 pm
I think it would be useful to more programs for example, because there was not much for last update and I found it very useful (at least there is no need to spend lot of time on the translator while someone (or record of commands) explains the function in English).

What do you think?

PS: and then I would have read all the forum omnimaga to know where to find the best such programs, but my English makes me go on google translation ^^.
Title: Re: Features Wishlist
Post by: ztrumpet on September 13, 2010, 04:00:49 pm
I can't wait for Multi-Page Apps (even if all pages != 0 are data).  RPGs can exist in Axe! ;D
Title: Re: Features Wishlist
Post by: LordConiupiter on September 13, 2010, 04:10:51 pm
well, I already have all my data stored to appvars, but now I'm running out of space :(
so I would realy like to see multipage apps with more than one page of code :)

another question I suddenly thought of: How is it going with WAVE support?
Title: Re: Features Wishlist
Post by: Quigibo on September 13, 2010, 04:32:20 pm
I will definitely have a new example program in the next version.  And it will be an entire game, not just a demo like the other ones.

Oh yeah, that WAVE support... I did try, but the quality was unacceptably low in 6MHz with any kind of compression.  It was something I wanted to add at one time, but after playing around with it, it doesn't seem practical.  Someone can always write an Axiom for it eventually but I don't think it will be supported natively.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 13, 2010, 04:59:58 pm
An axiom for it (15 MHz mode) would be cool. Not a big hurry, though. Can't wait to see what you have in store :)

Starcraft Axe Remake, by Quigibo
Title: Re: Features Wishlist
Post by: Builderboy on September 13, 2010, 05:16:01 pm
so I would realy like to see multipage apps with more than one page of code :)

I believe as some asmers have mentioned in the past that this is extremely difficult to pull off, and even seasoned asm experts can have trouble getting it to work.  Having an automated option might be out of the question, but you'd have to ask Quigibo
Title: Re: Features Wishlist
Post by: Raylin on September 16, 2010, 11:29:00 pm
I would like to see masked bitmaps in the next version of Axe. With greyscale support if possible.
Title: Re: Features Wishlist
Post by: Builderboy on September 17, 2010, 02:04:11 am
Bitmaps are an Os command so im not sure of the possibility of that option D:
Title: Re: Features Wishlist
Post by: calc84maniac on September 17, 2010, 03:08:54 am
I'd like the option of turning the homescreen cursor on/off. It would greatly help with making custom text input that doesn't use the "input" command (which ends up creating a temporary string each time it is run, and also uses tokens).
Title: Re: Features Wishlist
Post by: Builderboy on September 17, 2010, 03:19:32 am
well couldn't you just display the character 224?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 17, 2010, 03:22:17 am
well, the cursor is just a token, which you can use with the Output command. I thought it was 224>Char for the normal, 225 for the sencond cursor (with the up arrow), 226 for the alpha cursor (with the small A),  227 for the alpha cursor (with the small a), 228 for the insert cursor ( _ ), etc.

you could use this image to output aany char you want:
Spoiler For Spoiler:
(http://zastava.student.utwente.nl/linkguide/ti83/graphics/chars6x8.gif)

EDIT: ninja'd :P
Title: Re: Features Wishlist
Post by: calc84maniac on September 17, 2010, 08:56:12 am
But still, turning the real homescreen cursor on is only a 3-byte OS command, and the OS handles all of the cursor blinking itself in the interrupts. It's much more convenient :)
Title: Re: Features Wishlist
Post by: Deep Toaster on September 17, 2010, 07:18:15 pm
Maybe it could be a Fix function, if that's not filled already.
Title: Re: Features Wishlist
Post by: Quigibo on September 17, 2010, 08:32:46 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 17, 2010, 09:22:25 pm
Also is 3D still planned for Axe? If not, it might be a good idea to remove the poll maybe :P
Title: Re: Features Wishlist
Post by: ztrumpet on September 17, 2010, 09:44:06 pm
It may be helpful to look into some of ThePenguin's code that deals with this.  It's in most of his games. :)
Title: Re: Features Wishlist
Post by: Quigibo on September 17, 2010, 09:46:44 pm
3D is planned as an Axiom, not as part of the language itself.  I want to remove the poll, but it doesn't let me unless I start a new poll, which I don't really have any ideas for.  I guess I'll start a new one then.
Title: Re: Features Wishlist
Post by: nemo on September 17, 2010, 09:53:16 pm
Quigibo, could you post the source code to the mode7 engine in axe you made awhile back?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 17, 2010, 10:04:45 pm
3D is planned as an Axiom, not as part of the language itself.  I want to remove the poll, but it doesn't let me unless I start a new poll, which I don't really have any ideas for.  I guess I'll start a new one then.
Oh ok. I might have messed up the board settings x.x

I guess I'll wait then.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 17, 2010, 11:40:18 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.

Isn't it a b_call?
Title: Re: Features Wishlist
Post by: calc84maniac on September 19, 2010, 08:43:13 pm
I'm not familiar with how enabling the cursor works, I'll have to look into it.

Isn't it a b_call?

bcall(_CursorOn)
bcall(_CursorOff)
Title: Re: Features Wishlist
Post by: aeTIos on September 21, 2010, 03:03:19 pm
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?
Title: Re: Features Wishlist
Post by: SirCmpwn on September 21, 2010, 04:48:30 pm
Also, bumping my request for Alpha+Letter in the compile menu.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 21, 2010, 07:43:07 pm
Also, bumping my request for Alpha+Letter in the compile menu.

And numbering like in the TI-OS prgm list, if possible.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:08:14 pm
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?

If this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs
Title: Re: Features Wishlist
Post by: Builderboy on September 21, 2010, 11:10:34 pm
Maybe a good idea for an Axe program used as a library?
Title: Re: Features Wishlist
Post by: _player1537 on September 21, 2010, 11:12:54 pm
Also, bumping my request for Alpha+Letter in the compile menu.

This^^^^
I´d like to have a built-in "Menu(" feature
would be very useful I think...
what do you think about that?

If this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs

Possibly the DCSB sum(13 command, except ... with ASM calling it... idk, it would require a 3 page app to use the program then.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:15:27 pm
Yeah, but I think the person meant the TI-OS-like menus. Does the sum(13 command looks like TI-BASIC menus? Also yeah some people may not be willing to make their prog require the 3 pages app. :(
Title: Re: Features Wishlist
Post by: Quigibo on September 21, 2010, 11:28:05 pm
Ok, I'm trying to decide if it's better to list the programs with either instant shortcuts like the BASIC menu (but not just 1-9, it would continue onto A-Z) or I could just use letters to go to the first program starting with that letter.  Since I haven't updated the poll for a while, I decided to change it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 21, 2010, 11:39:03 pm
1-9 then A-Z seems cool to me. It might make it faster to compile stuff sometimes when you remember where are located each source files :)
Title: Re: Features Wishlist
Post by: calc84maniac on September 21, 2010, 11:53:43 pm
It might confuse your muscle memory if you make a new source file though :O

Especially since Axe doesn't say which program was actually compiled (perhaps you could add this, Quigibo?)
Title: Re: Features Wishlist
Post by: _player1537 on September 21, 2010, 11:57:47 pm
I also vote (if there was an option) to be able to compile from the homescreen with a similar method, maybe On-Number or similar, and you could set what those were inside Axe :)
Title: Re: Features Wishlist
Post by: SirCmpwn on September 21, 2010, 11:59:46 pm
With the sheer amount of programs I have, combined with how often I make new ones to mess up the list, I voted for the first option.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 12:59:31 am
Ditto as the good Sir
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 02:08:32 am
I was just reminded about the ability to make custom icons for MOS and DCS instead of the default Axe logo.  I've been thinking about it but I'm having a hard time thinking of a good format for this that is easy to use and unambiguous.  I challenge anyone to think of a good format for this.  It should be:

1. Near or at the top of the header.  Must come before program and data.
2. Parsed as a comment or something that is ignored when its not needed.
3. Similar to existing commands/conventions.
4. Relatively simple to implement.
5. No new tokens.
6. Not simply a commented out sprite since many people comment sprites at the start of their code.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 02:12:29 am
Why not just add the sprite on the first line after the title and the alternative description?
Title: Re: Features Wishlist
Post by: meishe91 on September 22, 2010, 02:41:02 am
Ya, I like Builder's idea. Just have it detect the "[" or what ever in the first line after the title (with or without the description). The only other idea I had was to have it on the next line with a ".[" signifying it.
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 04:00:53 am
But what if the description needs a bracket in it?  The problem with just the .[ is that it's likely a commented out sprite rather than the actual header.  Maybe .( .< ..[ or .[[ might work.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 04:06:17 am
if the description just happens to be an open bracket followed by 16 characters of hex followed by a closing bracket and nothing else then i guess they are out of luck :P
Title: Re: Features Wishlist
Post by: _player1537 on September 22, 2010, 07:17:50 am
I like the .[[ idea, I was actually about to suggest it :)
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 10:04:00 am
I think that you should extend headers more, actually.  Perhaps you could use psuedo-xml, which couldn't possibly be mistaken for commented out code, and could be more extendable.  I was thinking:
Code: [Select]
.PRGMNAME
.<SPRITE>HEX</SPRITE>
.<TARGET>APP/MOS/DCS6/ION/NOSTUB</TARGET>
Of course, only PRGMNAME would be required.  Sprite would default to the axe one, and target would override the settings if present.
Title: Re: Features Wishlist
Post by: Raylin on September 22, 2010, 11:06:50 am
Oooor.

Code: [Select]
.PRGMNAME SPRITE TARGET DESCRIPTION
You could recognize each space before DESCRIPTION as something else. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:13:38 am
Oooor.

Code: [Select]
.PRGMNAME SPRITE TARGET DESCRIPTION
You could recognize each space before DESCRIPTION as something else. :D
The problem with that is that in Ion/Mirage, this is supposed to be the file description. Example: .ROL3 The Reign Of Legends 3 would show The Reign Of Legends 3 in MirageOS. Maybe we should use some sort of XML-style header, as Sir suggested. I like the icon idea personally. I think the default Axe icon should be used by default when not using any, though.
Title: Re: Features Wishlist
Post by: Builderboy on September 22, 2010, 11:20:07 am
I'm still for the .ProgramName Description SpriteData idea :P it just makes sense that all the information should be in the first line, since that's where it all has been up to this point.  Also I don't think target is needed?  Since the target is defined in axe, not in the program.
Title: Re: Features Wishlist
Post by: calc84maniac on September 22, 2010, 11:29:51 am
Also I don't think target is needed?  Since the target is defined in axe, not in the program.
It would actually be better if specified in the program imo.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:43:45 am
I'm still for the .ProgramName Description SpriteData idea :P it just makes sense that all the information should be in the first line, since that's where it all has been up to this point.  Also I don't think target is needed?  Since the target is defined in axe, not in the program.
What if the description is multiple words, though? Would it be like .ProgramName "Description" SpriteData instead?
Title: Re: Features Wishlist
Post by: LordConiupiter on September 22, 2010, 01:43:59 pm
or to keep the Axe syntax: .prgmName "Description" [spritedata]. then you could also do .prgmName [spritedata] when you don't want a description for some reasons...
Title: Re: Features Wishlist
Post by: calc84maniac on September 22, 2010, 01:45:21 pm
Well, all MirageOS/Ion programs have a description of some sort, even if it is empty. So perhaps in that case you would do: .prgmName "" [spritedata]
Title: Re: Features Wishlist
Post by: LordConiupiter on September 22, 2010, 04:58:45 pm
well, it just that I would like to see one syntax in Axe, and not some xml-style thing on the calc, because of it doesn't fit on the screen very well. <prgmname> would fill one complete line, which has to be scrolled through when you want to edit your code.

now suddenly another idea occurs to me: coul the header info be in an external prgm? like this:
Code: (Axe) [Select]
Program:TESTSRC
.prgmHEADER
DiagnosticsOff
.and the rest of the code...

Program:HEADER
TEST "A little test prog" [8142241818244281]
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 06:18:41 pm
Oh, I like that idea!
But we need to make sure that it keeps compatibility with old programs.
Title: Re: Features Wishlist
Post by: Quigibo on September 22, 2010, 06:31:14 pm
What about UNIX style headers?  For instance:

Code: (prgmTESTSRC) [Select]
:.TEST -T MOS -I [123...DEF] -D This is a description

Which can also be defined as:
Code: (prgmTESTSRC) [Select]
:.TEST -D This is a description -I [123...DEF] -T MOS

So the programmer can choose the arguments in any order they like.  And to keep reverse compatibility, if you don't specify a tag, then it defaults to a description.  Also, that escape character would most likely be the negative sign instead of the minus sign because dashes might be used in the description.  This allows for future expansions available for the header as well.
Title: Re: Features Wishlist
Post by: SirCmpwn on September 22, 2010, 06:33:34 pm
I like that!
I also really want to define the type in the header.  I've compiled too many apps x.x
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 22, 2010, 11:48:23 pm
Unix style syntax seems good, as long as it is well documented in the command list or documentation.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 23, 2010, 07:13:16 am
I prefer to have as less extra tokens to be used as possible. And IMO it's more clear to use sybols instead of letters, like in the UNIX style you use a minus symbol and a letter and an extra space, while in the syntax I suggested it's more clear because of the use of tokens to indicate the type of header data.

for compatibility reasons this is my edited plan:
Code: [Select]
Program:TESTSRC
.HEADER prgm
DiagnosticsOff
.and the rest of the code...

Program:HEADER
TEST "A little test prog" [8142241818244281]
Title: Re: Features Wishlist
Post by: ztrumpet on September 24, 2010, 09:51:59 pm
Sounds great! ;D
What does that mean for the Compile for in the Axe menu itself?  Will it just default to that if you don't specify?
Title: Re: Features Wishlist
Post by: Aichi on September 25, 2010, 12:06:53 pm
It will be nice if you create a Framerate feature, what makes possible, that you can choose a  FPS value for every loop.
The prog waits at the end of the loop until the value is reached.
It will be helpful for loops, which have differently fast frames, for example by a space shooter, that would have lags by to much active objects.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 12:46:10 pm
I'm not sure how feasible that would be, though it could be helpful.
In the meantime, http://ourl.ca/7043 (http://ourl.ca/7043) is a topic where someone was trying to do a similar thing ;)
I just bumped it, so eventually there should be a response.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:02:30 pm
I wonder if it would be feasible... it would be cool indeed, though. Personally I just:

 1: add some artificial delay that depends on the amount of objects on the screen
or
 2: simply display those objects on the screen even when unused, like a blank sprite using the OR logic.

In both cases, for tilemaps that only use one wall tile and one floor tile, never do like I did in the BASIC game Illusiat and not display any sprite for floor, because then when walking through areas with few walls, it moves many times faster than when there are many walls.
Title: Re: Features Wishlist
Post by: nemo on September 25, 2010, 02:16:34 pm
is there any chance that bitshift operators will be implemented?
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:27:48 pm
It might be ready tonight, because as another last minute decision, I decided to add support for expression valued label jumping!  The main reason is I thought it would be cool to add function pointers (which point to routines instead of data) because then you can do A LOT of crazy stuff with that.  For instance, lets say you write a subroutine that takes every element in a list and does an operation to it.  You can call that with a subroutine that takes as arguments: a list and a function pointer.  The routine then would call that function on each member of the list.  Like a function that squares the number, doubles the number, adds 1 to the number, or something really complicated.  Plus, a lot of asm programmers have been bugging me to add it for their other diabolical uses :P.


By the way, the new syntax for recursive subroutines is now this: sub(LBLr,1,2,3)

Its becasue it makes it easier for the compiler to know what type of routine it is before evaluating the arguments.  Surprisingly though, you rarely need it. Tail calls don't need them so you can actually write a lot of recursive subroutines already without this new feature.  Like for instance, this:

Code: [Select]
:.RECFACT
:
:.Find 6 factorial
:Disp sub(F,6)>Dec
:Return
:
:.FACTORIAL
:Lbl F
:!If r1
:  1
:  Return
:End
:r1*sub(F,r1-1)
:Return

EDIT: @Nemo
Yeah, *2 is shift left and /2 is shift right.  They automatically optimize to the bit-shift instead of the multiplication.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:33:18 pm
Sounds cool! :)
What'll the syntax for getting the value of a function pointer be?
Can't wait, keep up the good work!
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:35:03 pm
EDIT: @Nemo
Yeah, *2 is shift left and /2 is shift right.  They automatically optimize to the bit-shift instead of the multiplication.
What about arbitrary shifts? That should be as simple as "ld b,shiftamount \ call shift_right", etc.
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:41:28 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds

EDIT: @calc84
That's actually exactly what the multiplications do with multiples of 2 so left shifting is already optimized this way.  Right shifting however I am not currently doing this becasue it takes 8 bytes whereas it only takes 6 to call the division with an argument.  Do you thinking that I should optimize this for speed instead of size?
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:42:42 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds
Does this work with sub() too?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:44:09 pm
Mhmm could you explain expression valued label jumping? In your code example I see no "Lbl". Could you post a more visual way explaining it? (maybe a screenshot of it in action or something) because I really don't get what you mean despite the explanation :/
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:49:02 pm
It will be a set of extra parenthesis:

Goto A       Jumps to label A
Goto (A)     Jumps to the address that the Variable A holds
My main question was "If I have a label A, how do I get its address?" ;D
Also, couldn't it be {A} to be more consistent? (Also, will, say, (using brackets, not parentheses) {L1} jump to the beginning of the L1 saferam area, and will {{L1}} jump to the address at {L1}?)
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:51:23 pm
Also, couldn't it be {A} to be more consistent?
That implies a memory read from the pointer stored in A, which is not consistent. The official z80 syntax makes this mistake too, naming an instruction jp (hl) instead of jp hl
Title: Re: Features Wishlist
Post by: Quigibo on September 25, 2010, 02:53:54 pm
It should work with sub(), but I'm not sure if it will work with the recursive sub().  By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?

I haven't started adding this feature yet so I can't really give any screenshots or visualizations, but I will provide an example when its released.  Its a fairly complicated and rarely used feature so don't worry too much about it.
Title: Re: Features Wishlist
Post by: calc84maniac on September 25, 2010, 02:54:44 pm
By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?
You are correct.
Title: Re: Features Wishlist
Post by: calcdude84se on September 25, 2010, 02:57:33 pm
Also, couldn't it be {A} to be more consistent?
That implies a memory read from the pointer stored in A, which is not consistent. The official z80 syntax makes this mistake too, naming an instruction jp (hl) instead of jp hl
Ah, right, my bad. My questions about {L1} and {{L1}} become about (L1) and ({L1}), then :)
Quigibo, that seems about the best way to do it short of SMC.
Edit: Ninja'd with respect to Quigibo's question.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 02:59:39 pm
It should work with sub(), but I'm not sure if it will work with the recursive sub().  By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?

I haven't started adding this feature yet so I can't really give any screenshots or visualizations, but I will provide an example when its released.  Its a fairly complicated and rarely used feature so don't worry too much about it.
Oh ok.

I think in the final doc there should be some examples of most functions that are more complicated like in the TI-83 Plus manual. It might help a lot.
Title: Re: Features Wishlist
Post by: AngelFish on September 25, 2010, 04:44:22 pm
Is there a way to use the NOT() function in Axe? I've come across situations a few times where I want to test for a non zero value and a zero value in a conditional.

For example:

Code: [Select]
:If A and Not(B)
:Conditional code
:End

I can't figure out how I would do it in Axe, so I end up using
Code: [Select]
:If A
:!If B
:Conditional code
:End
:End
which would appear to be less efficient.

Basically, if there isn't a NOT() function for expressions in Axe already, it'd be nice to have one. Even if the function isn't more efficient, sometimes the End statements get a bit messy and it'd be nice to eliminate as many as possible.
Title: Re: Features Wishlist
Post by: Raylin on September 25, 2010, 05:05:09 pm
This is the wrong topic for that but you'd just:
Code: [Select]
:If A and (B<>EXP2)
Title: Re: Features Wishlist
Post by: AngelFish on September 25, 2010, 05:08:19 pm
Sorry about the topic , but wouldn't B<>EXP2 be false for all B≠EXP2. I see how that would work.
Title: Re: Features Wishlist
Post by: Builderboy on September 25, 2010, 05:19:11 pm
Wow the conditional routine jumping sounds really cool :D it does sound very confusing though, might have to take a while before its completely understood.  Does this mean that we are finally able to use labels as addresses?
Title: Re: Features Wishlist
Post by: ztrumpet on September 25, 2010, 10:44:28 pm
Wow, sounds awesome!  I can't wait for the new release! ;D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 25, 2010, 10:46:19 pm
I changed my vote because after seeing LordConiputer entry and having many others at once on my calc, and having used the CATALOG for a while, I feel that it might be better to have the list so when you type a letter, it goes to the first program that has that letter.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 09:40:28 pm
After compiling, I still think it would be nice, when compiling in program form, if Axe let us know how large is our executable code after compiling, so it give us a guide if we want to know if we are nearing the 8812 bytes limit and are trying to stay under it.
Title: Re: Features Wishlist
Post by: Quigibo on September 27, 2010, 09:59:38 pm
The main problem with that is the compiler doesn't know how big the output file is until it finishes compiling.  It would have to pause when its done somehow to allow the user to see the number which I think would annoy a lot of people who want speedy fast compiling, especially for smaller programs.
Title: Re: Features Wishlist
Post by: Michael_Lee on September 27, 2010, 10:01:32 pm
Maybe add an option that'll let you enable that?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 10:38:00 pm
Ah ok I see x.x

How are you gonna add a warning that the code exceeds 8812 bytes, though? If it is possible to do, then why at the end of the compiling wouldn't it be possible to tell a size other than 8812?
Title: Re: Features Wishlist
Post by: Quigibo on September 27, 2010, 11:41:10 pm
I'm not saying its impossible, I just mean that it would be annoying to happen every time you compile a program.  You definitely need to know when you're over the limit because that's a safety issue (potential crashes), but for smaller programs its not important since you cn check in the [2nd][Mem] menu anyway.

I like the idea of an option for it though.  I could display other statistics too like the number Axe subroutines used, percent data, tip of the day, etc.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 27, 2010, 11:50:08 pm
would it absolutely slow down compiling, though? I thought it would simply be a matter of scanning through the file until the point where is located the data, then display the size, like when you compile an APP (although that displays the size including data).

If it's really inconvenient for smaller programs, I guess maybe it could be at least added as option, though.
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 12:21:38 am
It would be best to make a separate option [in OPTIONS] called 'Generate Report' that CALLS the compiler routine and but doesn't show the compile percentages. (The first pass and second pass thing.) Instead, it would say "Generating report..." and then display:

*Name of program:
*Bytes when compiled and warning if necessary
*Number of subroutines
*Composition percentile (how much is data, etc.)
*Tip of the day / "Did you know"

That's just my idea.
Title: Re: Features Wishlist
Post by: LordConiupiter on September 28, 2010, 11:19:01 am
I like that idea! and I would name the option Compile in the OPTIONS menu, which could be set to report or percentage, and perhaps also both?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 11:40:32 am
It would be best to make a separate option [in OPTIONS] called 'Generate Report' that CALLS the compiler routine and but doesn't show the compile percentages. (The first pass and second pass thing.) Instead, it would say "Generating report..." and then display:

*Name of program:
*Bytes when compiled and warning if necessary
*Number of subroutines
*Composition percentile (how much is data, etc.)
*Tip of the day / "Did you know"

That's just my idea.
that could work too
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 11:42:08 am
I'd make it a separate option entirely. Compile seems too ambiguous.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 11:57:32 am
Yeah, and maybe I guess it is better if compiling is not too slow either. I tried contest entries and I know that some took quite a while to compile, and I was on a 15 MHz calc. NOw imagine on a regular 83+.
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 11:59:14 am
DJ, you run on a 15MHz? Which one?
And, I agree. Compiling needs to be fast.

Still voting for the compile keyhook inside of a program.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 12:03:24 pm
I usually run on my 83+. However, I slowly moved to my TI-Nspire because APP compiling doesn't work on my TI-83 Plus (hardware issue, I think).
Title: Re: Features Wishlist
Post by: Raylin on September 28, 2010, 12:08:33 pm
Awh... That sucks... :c
Isn't the Nspire slow and suckish for ASM? Or was that BASIC...?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 28, 2010, 12:33:22 pm
Under OS 2.54 MP, everything runs at the exact same speed as on a regular 83+. In 15 MHz mode, the speed increase is much lower than it is on a real 84+, though.

Older Nspire OSes got incredibly slow speeds at times with ASM stuff.
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 09:56:56 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 10:06:53 am
that would be really easy to write in Axe! just send the info of the program first using the Send Command, while the other Calc is in Get()-mode.

I would do it this way:
1. give the sign: "I'm ready to send a program" with a certain command,
2. then send the length of the name,
3. then the name itself char by char,
4. and then perhaps the type of the data (prgm, locked prgm, appvar,pic etc),
5. and last but not least the data of the program itself.

I am willing to write this routine this evening, but not jet (it's just 16:00 o'clock over here)
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 10:07:15 am
Quigibo, this BCALL (http://wikiti.brandonw.net/index.php?title=83Plus:BCALLs:4E7C) may prove useful. I've never tried it though, so I don't know exactly how it works.
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 10:22:27 am
@ calc84maniac: Nice

@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:27:11 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.

If you want to call another Axe program, unless you desperately need them to be two separate compiled programs, this can already be achieved with included programs. Just call it as a subroutine in your main program without a Return, like this:

Code: (Your main program) [Select]
.PROGRAM

ClrHome
Disp "Hello "
sub(A)
Disp i
Return

Lbl A
prgmINCLUDE
       
Code: (prgmINCLUDE) [Select]
..

Disp "world!"
Return
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 10:32:22 am
@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
did you mean that! sorry, I misinterpreted your Post, for U suggested to use the Get command, and that's already used for data transfer between 2 calcs.

@Runer: how did you do that! those two code block next to each other?
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:53:31 am
@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.
did you mean that! sorry, I misinterpreted your Post, for U suggested to use the Get command, and that's already used for data transfer between 2 calcs.

@Runer: how did you do that! those two code block next to each other?

A table:
Code: [Select]
[table][tr][td]Put one code block in here[/td][td]        [/td][td]Put another code block in here[/td][/tr][/table]
Title: Re: Features Wishlist
Post by: ACagliano on October 05, 2010, 10:54:59 am
Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.

If you want to call another Axe program, unless you desperately need them to be two separate compiled programs, this can already be achieved with included programs. Just call it as a subroutine in your main program without a Return, like this:

Code: (Your main program) [Select]
.PROGRAM

ClrHome
Disp "Hello "
sub(A)
Disp i
Return

Lbl A
prgmINCLUDE
       
Code: (prgmINCLUDE) [Select]
..

Disp "world!"
Return

@Runner: That method includes the CODE making up the included program and still compiles as one program. Think of what happens in the TI-Basic code

Code: [Select]
Disp "Hello"
prgmZCLRHOME
Disp "Goodbye"

I'm suggesting Axe have a way to do that. Like what calcmaniac said, using B_CALL ExecProg
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 12:15:37 pm
And I think ExecLib would be a nice token for it, which could be renamed to Exec, or ExecProg, with the following syntax:
Code: (Axe) [Select]
ExecprgmTEST
or
Code: (Axe) [Select]
ExecProg("prgmTEST"
.or
"prgmTEST"->Str1
ExecProg(Str1
just what would be easier for the compiler, and what fits the best to the other Axe commands. I personally prefer the second one, and perhaps even ExecCalc(, for there is the GetCalc command, and I like to see similar named commands is the language. I also like to see DelVar changed to DelCalc(, or GetCalc( to GetVar(
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 12:34:19 pm
Execlib only exists on 84+ OS, and only starting at a certain version I think. Not a good choice, I'd say.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 01:05:23 pm
ok, I didn't know that. perhaps e^( then? that's [2nd][LN]. or ExpReg, which can be found in the [STAT]->[CALC] menu as option [ 0 ].

but I still aim for syntax similarity for Calc files handling:
DelVar -> DelVar(
Archive -> ArchVar(
UnArchive -> UnArchVar(
GetCalc( -> GetVar(

and I wonder why input an float are in the external variables section, since float would fit better in the data/storage part, and input in the Text part.
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 01:55:24 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:

Title: Re: Features Wishlist
Post by: Ikkerens on October 05, 2010, 02:24:03 pm
Quote
Pt-Command()→BUFF   Performs any of the Pt-On(), Pt-Off(), or Pt-change() routines to an arbitrary buffer of your choice.

I would love the ability to use this with pxl-Test(
I have this pointer that points to a picture in the ram.
And I need to check wether a pxl is on or not within that picture.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 02:40:43 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:



But how would TIOS do it then? subprograms can be called in BASIC, or do BASIC programs not have to be copied to 959C?
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 02:44:40 pm
Basic programs dont have to be copied, thats the trick.  Since they are not assembled, they are interpreted, the TiOS can just read each line right out of the regular RAM where the program is located and parse it.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 05, 2010, 02:48:14 pm
right! well, then it will become really very tricky I see...
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 05:14:35 pm
Dang, I just realized that Quigibo disabled Axioms with the last update... I'm guessing he's reworking them. But anyways, when they've been reworked and are enabled again, could someone (maybe even Quigibo as an example Axiom) make a fast sprite display routine? When I say "fast" I mean as fast as a sprite routine can possibly get: no aligning, no clipping, and with whichever display method/logic works fastest (it would be nice to be able to specify an arbitrary target buffer, though). The main reason I'm asking is because I've been working on something that uses an aligned tilemap system, but the tiles are animated, and updating the tiles constantly brings the program to a crawl.
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2010, 06:10:37 pm
Why would animated tiles be any slower than regular tiles?  Don't you have to display them every frame anyway?
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 06:45:53 pm
Why would animated tiles be any slower than regular tiles?  Don't you have to display them every frame anyway?

Why would you need to display static tiles every frame? You can just draw them once and repeatedly display that rendered image. Whereas you'll need to render animated tiles over and over.
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 07:16:20 pm
I think this is very difficult to accomplish.  In order to run a program, it must be copied into 959C.  Unfortunately that is where the current program already is, so you would need a 3rd piece of code that would copy the original program back into its original RAM space, copy the second program into 959C, PUSH a piece of its own code onto the stack so that when the program exits, it is able to copy the original program back onto 959C

D:


I think this is handled completely by the BCALL. A copy of the program is inserted at 9D95, and then it is run. When the program returns, the copy is deleted and the program running beforehand should be exactly where it used to be, so the BCALL will return properly.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 05, 2010, 07:19:03 pm
Where is the original program stored while the sub runs?
Title: Re: Features Wishlist
Post by: calc84maniac on October 05, 2010, 07:20:26 pm
It should be located directly after the newly executing program in memory (since the memory insertion shifts it over)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 05, 2010, 07:22:11 pm
Oh, I get it.
Title: Re: Features Wishlist
Post by: Quigibo on October 05, 2010, 09:30:56 pm
I'll definitely check out that bcall.

@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly.  I'm pretty sure I've seen someone do that before but I can't recall the thread...  For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite.  Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().
Title: Re: Features Wishlist
Post by: Runer112 on October 05, 2010, 10:49:04 pm
I'll definitely check out that bcall.

@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly.  I'm pretty sure I've seen someone do that before but I can't recall the thread...  For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite.  Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().

Yeah, I realize the speed increase wouldn't be terribly much, but I could use all the speed I can get. For what I'm trying to achieve, I need to draw about 2,000 sprites per second. I might try my own hand at the routine, but I get the feeling I'd end up writing it in such an unoptimized way that it would even be slower then a full-featured routine. :-\

Is there just a basic, unaligned 8x8 sprite routine without clipping floating around somewhere that I could steal? :P

By the way, what happened to Axioms?
Title: Re: Features Wishlist
Post by: ztrumpet on October 05, 2010, 11:34:49 pm
How about an 8*n sprite display routine that would be just like the regular ones but with an extra argument (default is at 8)?

Ex:
Pt-Off(0,0,Pic1,12) would display the 8*12 sprite pointed to at Pic1 at (0,0).

Quote
<From IRC Logs, calc84 talking about the Gameboy's sprite routines...>
<@calc84> all sprites are 8x8
<@calc84> well
<@calc84> unless you select 8x16 mode
<@calc84> in which case two tiles are used per sprite
<@ztrumpet> Why isn't there an 8*16 mode in Axe?
<@calc84> lol
<@ztrumpet> I'm serious
<@ztrumpet> I've wanted that for a while and keep forgetting
<@calc84> I don't know why there isn't an 8xN sprite display in axe
<@ztrumpet> yeah
<@calc84> it's pretty much the standard for asm
<@calc84> and quigibo can make a default height=8
<@calc84> so existing code doesn't have to change
<@calc84> just add an extra height argument to the end
<@calc84> he would only really need to slightly change the clipping code
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 05, 2010, 11:37:37 pm
I assume this would be for example for characters and some enemies, right? I think that might be a good idea, IMHO. That way we don't need to use two sprites instead of one for stuff that moves around. For smaller sprites it might also save some space.
Title: Re: Features Wishlist
Post by: aeTIos on October 06, 2010, 06:55:04 am
a feature that I would like is to use the "goto" command as this:
224->X
goto{X}
end

this is much faster as
if X=224
goto 224
end

what does the omnimaga community think about this???
Title: Re: Features Wishlist
Post by: calc84maniac on October 06, 2010, 08:09:12 am
That seems more like a job for switch/case.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 06, 2010, 08:15:30 am
what is this command to do exactly? go to the label which has the name of the value stored in X? I think you should just write a handy subroutine for this, which could do the actions you would have placed in the label called [value of X]. like this:
Code: [Select]
244->X
Sub(LX,X

Lbl LX
If r1=224
.actions for label 224, or even:
Goto 224
ElseIf r1=225
.similar actions
ElseIf etc.
.and even more code, if you need it.
End

The switch-statement would be very handy for this in the future, but isn't implemented jet...

EDIT: kinda ninja'd, but not really IMO ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 06, 2010, 01:55:57 pm
Switch statements would be handy, but I don't know if Quigibo was still planning to add them in the future.
Title: Re: Features Wishlist
Post by: aeTIos on October 06, 2010, 02:53:15 pm
what is this command to do exactly? go to the label which has the name of the value stored in X? I think you should just write a handy subroutine for this, which could do the actions you would have placed in the label called [value of X].

The switch-statement would be very handy for this in the future, but isn't implemented yet...

yes, go to the value stored in X
uh, that code would be very long in my program, because there will be 111 if...goto routines.
Title: Re: Features Wishlist
Post by: Quigibo on October 06, 2010, 04:51:57 pm
The labels are just names, they don't actually exist in the executable so there would be no way to tell where you actually need to jump.  ASM jumps function differently than BASIC gotos becasue the ASM uses the actual address in memory which varies wildly as your code grows and changes.  I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.

The reason I don't have 8xY sprite drawing is because it will either make the existing routine larger and slightly slower or i would have to add a whole other sprite routine.  It gets complicated due to the clipping.

Title: Re: Features Wishlist
Post by: ztrumpet on October 06, 2010, 04:57:42 pm
or i would have to add a whole other sprite routine.  It gets complicated due to the clipping.
I vote for this option.  Personally, I don't think it would be a bad thing and it would make programs faster and smaller as an end result. :)
Title: Re: Features Wishlist
Post by: calc84maniac on October 06, 2010, 05:18:59 pm
I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.
You could possibly make Return break out of the switch statement (which could possibly be the smallest solution -- just 4 bytes to push the return location onto the stack and 1 byte per return, as opposed to no overhead and 3 bytes per break)
Title: Re: Features Wishlist
Post by: ztrumpet on October 06, 2010, 05:19:50 pm
I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.
You could possibly make Return break out of the switch statement (which could possibly be the smallest solution -- just 4 bytes to push the return location onto the stack and 1 byte per return, as opposed to no overhead and 3 bytes per break)
That's a really good idea!  I vote for this. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 06, 2010, 11:26:27 pm
Such sprite routine might be good, unless it really signifiantly make your program grow much larger (like 70-100 bytes larger).
Title: Re: Features Wishlist
Post by: Builderboy on October 06, 2010, 11:43:54 pm
But note that it will only make your program larger if you want to use it, and if you dont want the size increase, you can stick with the normal routine and just use two or more 8x8 :)
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 01:02:19 am
calc84maniac, I was thinking about that, and it's a great idea!

I also thought of an interesting new block type which is basically an anti-subroutine.  Instead of calling a routine and then returning from where you called it, you tell it the place you want to return to and then do the routine.  I'm wondering if that would be useful because I do that a lot in the actual parser code.  In Axe and assembly, it's basically this:

Code: (Axe) [Select]
SetRet(LBL)
...
Return
...
Lbl LBL

Code: (Assembly) [Select]
  ld de,LBL
  push de
...
  ret
...
LBL:

The switch statement itself would use something similar.  And since the return point is set to the end of the switch statement, I wouldn't need to add a new break command, you could just use "Return".  The main problem though is that this would actually create memory leaks if you tried to do a goto out of the switch statement from within the switch statement.  I think a common use of switch statements is branching to a bunch of labels though so I'd have to figure out another way to do that...
Title: Re: Features Wishlist
Post by: Ikkerens on October 07, 2010, 01:10:42 am
Hm... Quigibo, could you look into my suggestion on page 86 as well?
It seems to be totally forgotten, and its a feature I (and most likely alot of others) need.
http://ourl.ca/4057/124762
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 01:12:00 am
Yeah, I've already added that :)
Title: Re: Features Wishlist
Post by: Ikkerens on October 07, 2010, 01:13:06 am
Oh cool!
Thx :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 02:46:02 am
But note that it will only make your program larger if you want to use it, and if you dont want the size increase, you can stick with the normal routine and just use two or more 8x8 :)
One concern I got, though, is if you use both 8x8 and the others, wouldn't both routines be added? That might waste a bit of space x.x
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:38:50 am
I have many ideas for projects atm, but I lose the most possibilities by the memory which is avaible for a game.
How possible would it be to let Axe compile a code into an 32/65KB app?
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 11:48:12 am
You mean 64, not 65, right? s:
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:52:46 am
16384 B; 32768 B; 65536 B, or not?
Maybe youre right, I never saw an app with this size
Edit: I made KB to B.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 11:54:21 am
One MB is 1024 KB, not 1000 KB. 65536 KB is exactly 64 MB.
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 11:56:13 am
Damn, i mean Byte, not KB. x.x
Ok, that confused me. =D
Apps can have a size of 65KB.
What I wrote in the first post should be right.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 12:04:57 pm
Wait what. I think I confused myself there too. sS:

But I'm pretty sure the app is 64 and not 65, no matter if it's MB or KB.
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 12:10:53 pm
You should input
16384
Ans*2
into the homescreen.
Press ENTER by 2 times, then the TI outputs
16384
32768
65536.
That must be the avaible size (In Bytes) of apps.
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 12:11:01 pm
It's 65.5KB, or 64KiB
Title: Re: Features Wishlist
Post by: Aichi on October 07, 2010, 12:22:58 pm
What Runer posted is correct.

@ JosJuice
I think you meant kibibyte.
Title: Re: Features Wishlist
Post by: JosJuice on October 07, 2010, 12:26:13 pm
Yes, I probably did. I'm very used to using KB/MB when talking about the unit that is 1024.
Title: Re: Features Wishlist
Post by: ztrumpet on October 07, 2010, 07:29:52 pm
Quigibo, are you thinking of adding the new sprite routines or not? :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 07:33:43 pm
And another UI request: When it scrolls to the prgm, could it scroll into the included program if the error occurred there?
Title: Re: Features Wishlist
Post by: shmibs on October 07, 2010, 07:34:03 pm
/\yeah, 8*16 sprites would be absolutely invaluable in the things im working on right now

EDIT: ninja'd? that was referring to ztrumpet
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 07:35:49 pm
/\yeah, 8*16 sprites would be absolutely invaluable in the things im working on right now

EDIT: ninja'd? that was referring to ztrumpet

They'd just be two 8x8s, wouldn't they?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 08:05:50 pm
For games larger than 16 KB, the only solution right now is to split your code in multiple Axe executables that are under 8811 bytes of executable code and use a TI-BASIC program assisted by an ASM lib to launch them separately (kinda like Illusiat 13, but instead of launching BASIC programs you would launch Axe ones), but then it isn't pure-Axe programming anymore. It would be nice later to have multiple pages app support so the entire first page can be used for code. Alternatively there are appvars.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 08:20:00 pm
Or maybe you could hack it using GetCalc( to find the second prgm...
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 09:19:29 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:



EDIT: Wow, how did I miss this: the Line() command working on back/arbitrary buffers. The routine's already there, it's gotta only take like 10 seconds to modify it for this. I hear you already did it for the pixel commands, which is good.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 09:52:10 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:

  • InsertMem and DelMem bcalls. They would be invaluable for editing variables with a large amount of data in them. (If anything, this is the feature I would want the most, and it seems fairly easy to implement)
  • Case statements.
  • Reading from/storing to the Ans variable for things other than integers (namely strings).
  • Dialog (menu) bcalls.
  • General bcall support.

All b_calls can be accessed with Asm(EFXXXX).

I support using Ans for strings! It'd be really helpful, and I have no idea how to do it myself.
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:01:10 pm
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation:

  • InsertMem and DelMem bcalls. They would be invaluable for editing variables with a large amount of data in them. (If anything, this is the feature I would want the most, and it seems fairly easy to implement)
  • Case statements.
  • Reading from/storing to the Ans variable for things other than integers (namely strings).
  • Dialog (menu) bcalls.
  • General bcall support.

All b_calls can be accessed with Asm(EFXXXX).

I support using Ans for strings! It'd be really helpful, and I have no idea how to do it myself.

how might we use this? for example, i see insertmem is 42F7h. so Asm(EF42F7) would run the bcall, but how do you write to the registers? since HL is the amount to add, and DE is the address at which to add? also, what if there's something important in HL or DE?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:02:47 pm
HL is always Axe's form of "answer", so
Code: [Select]
:X+1
would leave the value of X+1 in HL. For the others I guess you'd need Asm( as well...
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 10:05:55 pm
In Axe you can only set hl, which contains the current value in the calculation. de is used sometimes in two-argument instructions, but that can't be done with Asm(.
Also, due to endianness, it would be Asm(EFF742), not Asm(EF42F7) ;)
Edit: semi-ninja'd
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:07:00 pm
In Axe you can only set hl, which contains the current value in the calculation. de is used sometimes in two-argument instructions, but that can't be done with Asm(.

Can't you load something to DE with Asm(, though?
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:09:51 pm
i'd assume anything you can do in asm you can do with asm().... also, would i need to then push every register onto the stack and pop them accordingly after the bcall, since insertmem destroys all registers? yeah... i would like insertmem+deletemem support.
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 10:11:27 pm
In the Asm( hex, yes. However, outside of Asm(, there is no way AFAIK to set de before invoking an Asm( command.
Sorry if I was confusing. :(
Edit: semi-ninja'd again
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 10:12:23 pm
i'd assume anything you can do in asm you can do with asm().... also, would i need to then push every register onto the stack and pop them accordingly after the bcall, since insertmem destroys all registers? yeah... i would like insertmem+deletemem support.

I guess they would make nice features, but should be highlighted in the docu as very advanced features.
Title: Re: Features Wishlist
Post by: nemo on October 07, 2010, 10:16:17 pm
calcdude, would you be willing to write the hex string that would insert memory (as specified by HL) into an address specified by the axe pointer V?
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 11:29:42 pm
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.

bcalls aren't useful to implement becasue of the reasons you're discussing now.  bcalls require very specific register input and very specific register output.  There wouldn't be an easy way to translate that directly to Axe syntax.

InsertMem, DelMem, and EnoughMem are possible, I will look into some good tokens for them.

There is no bcall for making menus as far as I am aware.

EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I may support 8xY sprites, but I'm not sure yet.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:35:36 pm
Don't Bcalls location changes from an OS to another too?
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:36:35 pm
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.

GetCalc("Ans") returns 0 for me whether I use the Ans token or spell it out. Also, I believe storing strings to Ans involves a more complex method in which you need to create a temporary string variable in which to store the string, and then store that variable's name in Ans.

There is no bcall for making menus as far as I am aware.

Is this (http://wikiti.brandonw.net/index.php?title=83Plus:OS:Dialog_context) not it?
Title: Re: Features Wishlist
Post by: calcdude84se on October 07, 2010, 11:38:15 pm
Don't Bcalls location changes from an OS to another too?
DJ, not really. Normally they are only added.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:38:53 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 07, 2010, 11:42:04 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:44:24 pm
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:45:29 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2010, 11:50:50 pm
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.

Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).

EDIT: The poll seems nearly unanimous now ;)
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.

The garbage collect routine very well may have moved. But seeing as there isn't actually a garbage collect bcall and garbage collecting is handled entirely by the OS, unless you have a hacked OS with different parts from different versions, garbage collecting should work fine.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 07, 2010, 11:52:14 pm
Ah ok. Well, in the GC talk with him, what we were discussing mostly are custom garbage collect messages and forcing a gc. GC'ing by itself seemed easy, but as long as you used the default one.
Title: Re: Features Wishlist
Post by: Quigibo on October 07, 2010, 11:59:17 pm
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers.  Same thing with the circle command.

I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.

Usually for a UI you only need strait lines in which you should use rectangles with singular width or height.  Those can be drawn to the backbuffer.  The menu context is interesting, I hadn't seen that before (since its undocumented) but I will certainly check it out.  From the looks of it though, it seems really large and complicated if its implemented similar to the way BASIC does it.  I don't know how I'd be able to take any amount of arguments either.
Title: Re: Features Wishlist
Post by: alberthrocks on October 08, 2010, 12:05:16 am
Some features I'd love to see implemented:
1) Math specific functions - int( is something I'd love to see. :D Float math is also requested too...
2) input problem.. but I assume that is being fixed atm.
3) Mini input, either on screen, buffer, or backbuffer. Perhaps something like this?
Code: [Select]
minput(startx, starty, endx, endy)->Str1
Example:
minput(10,20,86,28)-> Str1
 (above: 8 units alloted for y, since 6 is height of tiny text, plus 2 for padding.)
Multiline: (If you decide to do so)
minput(startx, starty, endx, endy, multiline BOOL)->Str1
(Multiline is just multiple lines, within the rande of (startx, starty) and (endx, endy).)
Different buffers:
Buffer:
minput(startx, starty, endx, endy, multiline BOOL)ʳ->Str1
Backbuffer:
minput(startx, starty, endx, endy, multiline BOOL)ʳʳ->Str1

Just a thought. :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 08, 2010, 01:42:38 pm
Maybe Mirage-style input?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 08, 2010, 05:49:01 pm
As long as it lets you cancel, unlike in Mirage 1.1 x.x

Maybe Kerm could provide some routines from his Doors CS one? :D
Title: Re: Features Wishlist
Post by: Runer112 on October 09, 2010, 02:53:54 pm
It sounds like you're trying to implement switch statements, but perhaps vector/jump tables could also/alternatively be implemented? They would probably be simpler to code, as the user would end up writing the table for you, and could be activated with only one line. Another nice thing about a vector/jump table is that you can jump to pre-existing routines instead of having to do something like Case 0 / sub(A) with switch statements. Perhaps something like this to store it:

Code: [Select]
[[A,B,C,D,E,F,SUB,etc.]]→GDB0
And something like this to jump to an entry:

Code: [Select]
Goto GDB0,X
.or
sub(GDB0,X)

(The difference between the two being that Goto uses JP and sub() uses CALL.)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 09, 2010, 06:29:05 pm
Not that important, but a length()r would come in handy for me.
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 12:35:53 pm
Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 01:17:18 pm
I think an on-calc documentation of all the commands would be most excellent.
Title: Re: Features Wishlist
Post by: JosJuice on October 10, 2010, 01:18:39 pm
I think an on-calc documentation of all the commands would be most excellent.
That would take a lot of space... D:
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 01:19:38 pm
That's very true...

well, maybe it could be a separate file included for users who want to have it on hand.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 10, 2010, 02:43:47 pm
I think he planned a summary of documentation due to the Help option in the menu, but if I remember, it would more be like CtlgHelp, listing the syntax for each functions. Otherwise it would be very large. Included or not, I think it should be a separate file, though.
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:34:32 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:37:52 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D

Ah, an idea...

* Deep Blue adds that on his own features list

It's a nice idea for Axe as well. Maybe it could replace that Help option? It doesn't even do anything now anyway, so maybe it could be converted into an option to turn syntax help on/off?
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:39:06 pm
yeah, I'd be fine with a small yet complete doc on calc
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:40:11 pm
yeah, I'd be fine with a small yet complete doc on calc

That's not what ztrumpet suggested (I think), but it is what Quigibo will eventually add in place of that Help option in the main menu (again, I think).
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:41:21 pm
Like I said, anything would be fine for me.
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:44:37 pm
For me, i think an upgrade to the Fill() command is in order.  Usualy when people fill elements in RAM, they want to fill it with specific values.  But currently they have to put the value in the first element for fill to work, and this means you have to calculate the Address twice.  Wouldn't it make a lot more intuitive and useful sense (not to mention probably smaller) to do something like Fill(Address,Length,Number) ? that could even be an alternative syntax if you wanted backwards compatibility.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:46:00 pm
That sounds like a good idea...

How does the calc do it, though?
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:46:38 pm
That's a good thing too.  Plus, whenever you create an appvar, it is filled with random data from the start.  maybe in a new version you can clear variable's values at initiation?

Otherwise I have to set the fist element to 0 and do a fill()
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:47:54 pm
That's a good thing too.  Plus, whenever you create an appvar, it is filled with random data from the start.  maybe in a new version you can clear variable's values at initiation?
I do not support this idea, as it takes more code and is, therefore unoptimized in certain situations. :)  I think it should remain as is. :)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:48:05 pm
Maybe if the calc needs to fill from a value that's already there, Fill(location, value, size) could put the value at the starting place and fill it from there? Again, I'm not sure how it works myself...

EDIT: Yeah, I agree, GetCalc( should not clear it for us. Programs often need to initiate it to something else, anyway.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:49:16 pm
yeah, that sounds better.  then you can zeroize it much easier if you want to.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:50:30 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:51:06 pm
The way the calc does it is with a Copy() command i believe.  It copies the 1st element onto the 2nd element.  The 2nd onto the 3rd.  Ect... and it works like a fill command.  There is a built in command for this, and its quite fast.

EDIT: And i believe it *does* take more code actualy.  Since at the very least you are loading the address of the location to be filled *twice* instead of once by combining both steps into one command.

EDIT2: Unless you were talking about the file clearing and not the Fill() command?

EDIT3: Ninjas ninjas everywhere!

EDIT4: Can i ever escape???

EDIT5: Help meeeeee :(

EDIT6: Finally, the light!
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:51:54 pm
EDIT5: no you're screwed my friend :D
EDIT6: by the ninja's that is
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:53:04 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
That's not how CtlgHelp works; if you're in a menu then you can press + on a command and see it's information. :)
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:54:02 pm
yeah, ztrumpet is right.  I think :?

but yeah, one of those would be great!
Title: Re: Features Wishlist
Post by: Builderboy on October 10, 2010, 03:54:27 pm
Lol anyways i think we need Quigibo's input on the Fill() idea, and if it would take less code overall when using both setting and filling.

EDIT: And catalogue help would be cool :D But tricky o.O but i think its the best option.

EDIT2: Yeah Ztrumpet is right
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:55:05 pm
As I've always said, I want a CtlgHelp style system.  The minus button could even be used instead of the plus. ;D
Not really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
That's not how CtlgHelp works; if you're in a menu then you can press + on a command and see it's information. :)

No, it's in the catalog :)
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:55:41 pm
Well, on the + key is the quotation mark, so no problems there. I'm just wondering '-' how it would work well...
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:55:45 pm
yeah.  I'm guessing it's like in Omnicalc, where in the extra prgm commands you press + and it displays the parameters.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:56:41 pm
yeah.  I'm guessing it's like in Omnicalc, where in the extra prgm commands you press + and it displays the parameters.

Yeah, that sounds like a better alternative to CtlgHelp's style.

EDIT3: Ninjas ninjas everywhere!

EDIT4: Can i ever escape???

EDIT5: Help meeeeee :(

/me calls Steve Jobs
Title: Re: Features Wishlist
Post by: ztrumpet on October 10, 2010, 03:57:07 pm
* ZTrumpet eats everyone... :P
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 03:57:55 pm
yeah, I mean, all you really need is the parameters, those usually speak for themselves.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 03:58:46 pm
I was aware of that; I was just wondering how it '-' could work well in the catalog with 'W' on it...
Edit: Directed at ztrumpet's post.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 03:59:44 pm
* ZTrumpet eats everyone... :P

Yeah, that's what I meant, it's in the catalog, not in the actual menus. I must have misunderstood what you said, sorry...

EDIT: Personally I think it'd be a better idea to use Omnicalc's syntax help, which is in the menu itself, instead of in the catalog, because a lot of catalog functions aren't used by Axe anyway.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 04:01:55 pm
Only about 20 of them are used by axe :P
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:02:40 pm
Only about 20 of them are used by axe :P

Exactly. So it would be far less confusing if the syntax help were in the menus.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 10, 2010, 04:04:02 pm
I can't wait for this to be in a somewhat finished stage (yeah, I'm getting off topic now :P)

I won't have to carry around 5 sheets of paper to refer to the multiple commands :D
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:23:33 pm
The fill command needs only to look up the address once when using a variable pointer:

Fill(0->{A},10) will fill all the bytes from A+0 to A+10 with zeros.  This is becasue when storing to a variable pointer, it returns the address instead of what was stored there.  You usually have this situation when dealing with appvars.

As far as static addresses... it could be optimized if it were pure assembly, but the problem is that unless I could guarantee that all the arguments were constants (using look-ahead parsing), I would have to push and pop the extra argument and it would not be any more efficient that using the static address twice.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:27:04 pm
Oh, yeah, I guess Fill(0->{A},10) isn't that much more code than Fill(A,0,10)...

By the way, Quigibo, would 1->{E86EC}r be exactly the same (e.g. speed, size, etc.) as 1->A?
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:30:51 pm
Don't use that!  If I decide to move where the variables are located, that code will no longer work and be outdated.  Use 1->{oA}r instead as this will guarantee that you have the right address even if I move them.  And yes, it will be the exact same in the executable as 1->A byte-for-byte.
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 04:31:38 pm
If you mean E86EC, and $86EC is the address of A, then yes. Note that you should be saying 1->{oA}r, though, to be future-compatible ;)
Edit: ninja'd
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:33:49 pm
So if I wanted to use SaveSScreen as a buffer, I should access it from {E86EC} onward, right?
Title: Re: Features Wishlist
Post by: calcdude84se on October 10, 2010, 04:38:09 pm
Maybe... I'm not sure, and if Quigibo changes anything...
Title: Re: Features Wishlist
Post by: Quigibo on October 10, 2010, 04:40:15 pm
I suppose you could... but you would not be allowed to use the variables A-Theta in your program then.  You would have to use the r1-r6 variables and store the rest directly to another buffer which could be very confusing given that you have to write down what variable each address represents.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 10, 2010, 04:43:50 pm
I suppose you could... but you would not be allowed to use the variables A-Theta in your program then.  You would have to use the r1-r6 variables and store the rest directly to another buffer which could be very confusing given that you have to write down what variable each address represents.

I've already moved all of my vars in-prgm. Bit more mem, but some of it's initiated, anyway. (That's why I asked the question, btw.)

What are r1-r6?

And another question: I noticed the GetCalc([NAME], [FILE]) syntax. Where are "files" stored?

And yet another question :D: Why is L1 SaveSScreen+56? A-Z and theta are only 54 bytes... I heard that the last one's used for random numbers, though. How is it updated?
Title: Re: Features Wishlist
Post by: Runer112 on October 10, 2010, 05:39:10 pm
Holy crap that was a huge storm of sudden posts :o Just to make sure you didn't miss it Quigibo, did you see my feature request (http://ourl.ca/4057/126388) for vector/jump tables?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 10, 2010, 11:53:23 pm
For me, i think an upgrade to the Fill() command is in order.  Usualy when people fill elements in RAM, they want to fill it with specific values.  But currently they have to put the value in the first element for fill to work, and this means you have to calculate the Address twice.  Wouldn't it make a lot more intuitive and useful sense (not to mention probably smaller) to do something like Fill(Address,Length,Number) ? that could even be an alternative syntax if you wanted backwards compatibility.
Yeah I think it should work like in BASIC. That's unless it is much larger of course.



Holy crap that was a huge storm of sudden posts :o Just to make sure you didn't miss it Quigibo, did you see my feature request (http://ourl.ca/4057/126388) for vector/jump tables?
I deleted it ;D

J/k, but the ironic thing is that there was a huge storm of posts, then now tonight, there's a huge storm of 500 Internal Server Errors, even thought almost nobody was posting x.x
Title: Re: Features Wishlist
Post by: LordConiupiter on October 11, 2010, 09:46:57 am
that's not so nice :O...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 11, 2010, 04:17:47 pm
Lol as said in my post I was kidding, unless you mean the 500 server errors?
Title: Re: Features Wishlist
Post by: LordConiupiter on October 12, 2010, 11:39:18 am
yes, that was what I meant :). i get them pretty often, well, let's say once a week. but when I reload, the error seems to be already solved :D
Title: Re: Features Wishlist
Post by: Darl181 on October 12, 2010, 07:56:49 pm
New request (I think):
Line(X1,Y1,X2,Y2,)r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)
Title: Re: Features Wishlist
Post by: ztrumpet on October 12, 2010, 08:43:57 pm
There is no way to have a third buffer just "added".  However, here are your options:
1) Do not use the variables A-Z or Theta or rand and use L1-56 as a third buffer.
2) Create an AppVar and use it as your third buffer.
3) Persuade Quigibo to add the Insert_Mem() and Delete_Mem() bcalls. :P

I hope you can use one of these.  Good luck and I can't wait to see what it ends up looking like. ;D

Edit: * ZTrumpet eats Runer... :P
Title: Re: Features Wishlist
Post by: Runer112 on October 12, 2010, 08:45:24 pm
New request (I think):
Line(X1,Y1,X2,Y2,)r.  Lines draw directly to the back-buffer.

Also I'm not sure how hard it would be but might there be a third buffer sometime in the future?  Not for grayscale, but pxl-test to it?  Something like this would really help me optimize the game I'm working on (In the sig it says I'm done, but I'm trying to make a more memory-friendly version for the 83PBE)

Ive already asked Quigibo for a line routine for the back buffer :P but maybe your second request for it will help better convince him to add it.

As for a third buffer, Quigibo is limited by the safe RAM areas that exist on the calculator and are big enough to hold 768 bytes, of which there are only three. L6 and L3 are two of them, and the third is at L1-56. The first 56 bytes of this screen storage area are used by the random number generator and the 27 variables. If you wanted to use this area, you would have to avoid the use of the rand function and allocate some other place in RAM for variables (and any other data you might have had in L1), possibly a different safe RAM area or an appvar. However, this is a bit of a pain, so what I would suggest is creating a 768-byte appvar for the third buffer when your program starts and delete it when exiting.


EDIT: How did I know I would get ninja'd on this one...
Title: Re: Features Wishlist
Post by: Builderboy on October 12, 2010, 10:04:12 pm
I have an interesting request.  I request that the user variables are moved into L2 so that L1 can be opened up into a 3rd full screen buffer, or a larger span of memory.  L2 *is* the location for some interrupt data for MirageOS and Axe alike, but MirageOS does not seem to use the last 56 bytes of L2 and i believe Axe could be restructured in itself.  What do you think?  Is this possible?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 12, 2010, 10:38:07 pm
1) Do not use the variables A-Z or Theta or rand and use L1-56 as a third buffer.
I thought those vars were moved elsewhere to allow the usage of both the 768 bytes there and the variables?
Title: Re: Features Wishlist
Post by: Builderboy on October 12, 2010, 10:51:21 pm
I just checked and they are still at L1-56 as of version 0.4.5.  Moving them is what i was suggesting :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 12, 2010, 11:20:14 pm
Ah ok. I thought Quigibo said he might move them before.
Title: Re: Features Wishlist
Post by: Darl181 on October 13, 2010, 01:50:19 am
I was able to work around it.  A bit of a slowdown, but oh well.
The line request still stands though ;)
Title: Re: Features Wishlist
Post by: Runer112 on October 13, 2010, 05:41:22 am
I have an interesting request.  I request that the user variables are moved into L2 so that L1 can be opened up into a 3rd full screen buffer, or a larger span of memory.  L2 *is* the location for some interrupt data for MirageOS and Axe alike, but MirageOS does not seem to use the last 56 bytes of L2 and i believe Axe could be restructured in itself.  What do you think?  Is this possible?

I second this.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:43:54 am
I agree with moving the variables to L2.
I also second the backbuffer line drawing request, but I want to extend it to allow lines to be safely drawn off screen.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 13, 2010, 10:03:03 am
I don't really care where the vars are located. I was using their locations to edit them in some old code, but I replaced that code with new code, so for me this is not a problem at all. I could become very handy in cases when you need to store the current screen to an extra buffer, though you could use an Appvar for that. But when L1 would become 768 bytes, then it will be faster to use that, but the difference in duration would be unnoticably small, I think.
Title: Re: Features Wishlist
Post by: Darl181 on October 13, 2010, 10:37:56 am
The reason three buffers would help--1st buffer:2nd and 3rd buffer write to and use for dispgraph--2nd buffer:use for static (not moving) map--3rd buffer:enemies
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 11:20:28 am
I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.
Title: Re: Features Wishlist
Post by: Runer112 on October 13, 2010, 12:49:32 pm
I'm not sure how _InsertMem and _DeleteMem work, but couldn't they mess up data pointers in the VAT? I thought they were used only in edit buffers.

Seeing that there's a bcall called InsertMemNoUpdateVAT, I would have to assume that InsertMem (and DelMem) automatically update the VAT.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 01:48:26 pm
Oh, I see.

And yes, I second (or whatever this is) the request to move the vars to L2.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 13, 2010, 03:24:53 pm
I agree with moving the variables to L2.
I also second the backbuffer line drawing request, but I want to extend it to allow lines to be safely drawn off screen.
Would it cause problem with Mirage, though?
/me hopes Doors CS doesn't have those issues with L2...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 03:50:48 pm
Builderboy mentioned earlier that Mirage doesn't use at least the last 56 bytes of L2, so it should work. I don't think DCS has any built-in interrupts at all, so you can toy with L2 all you want.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 13, 2010, 03:56:50 pm
Ah ok, sounds good if it's the case.
Title: Re: Features Wishlist
Post by: kindermoumoute on October 13, 2010, 04:47:54 pm
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 04:51:11 pm
It has been asked, but apparently no one's taking that up yet. For now, just use Wabbit and export it (but wait until BuckeyeDude fixes the export function).
Title: Re: Features Wishlist
Post by: calc84maniac on October 13, 2010, 04:53:32 pm
I think he's talking about programs for the original TI-83 (no plus). I don't think that would be an easy task, though (one reason because TI-83 doesn't have the same saferam areas that we use for L1-L6)
Title: Re: Features Wishlist
Post by: ztrumpet on October 13, 2010, 04:55:38 pm
I agree with Builderboy on moving the Vars.  This would be immensly helpful to a program that I'm writing now.  Please do it! ;D
Title: Re: Features Wishlist
Post by: Builderboy on October 13, 2010, 05:22:46 pm
Yeah MirageOS uses only parts of the begining for its own variables and interrupts, but the last 56 bytes are safe.  As for Doors, it doesn't use any RAM space while a program is running, as it uses its own AppVar for storage, so it seems like the move to L2 would be fully safe :) Axe just needs to make sure that its own interupt routine doesn't use the last 56 bytes as well
Title: Re: Features Wishlist
Post by: calcdude84se on October 13, 2010, 05:37:33 pm
I must agree; the lack of another full buffer has been annoying me for a while ;D
So, seconded (or whatever number we're on... :P)
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 06:14:32 pm
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:29:16 pm
I think he's talking about programs for the original TI-83 (no plus). I don't think that would be an easy task, though (one reason because TI-83 doesn't have the same saferam areas that we use for L1-L6)

Misread, sorry :-\ Should be possible for the most part.

I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.

Ah, great! If you do it, may I suggest an option to compile to a program that can be run from the homescreen like with BASIC?
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:33:15 pm
What, like include a seperate TI-Basic launcher program?
Title: Re: Features Wishlist
Post by: calcdude84se on October 13, 2010, 08:35:37 pm
Forward references. I don't know how to add more to this... ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:38:52 pm
SirCmpwn: Here (http://ourl.ca/6481/105951).

If anyone includes that code as the header of any TI-83 ASM program, it can run from the homescreen, no launcher/Send(9 needed.

Of course, that's in theory (since I don't have an 83 to check).

Actually, if you wait a bit, I'll test it in Wabbit.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:44:41 pm
Does this work on an 83+?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 08:54:09 pm
Nope, because of $BB, $6D.
Title: Re: Features Wishlist
Post by: SirCmpwn on October 13, 2010, 08:55:19 pm
Thought so.  Then I probably can't do that...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 13, 2010, 09:26:47 pm
Do what? It could work with the plain 83.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 14, 2010, 01:28:22 am
I do not know if it's already been asked, but it would be nice to compile a program Axe Parser in ASM/Ion TI-83 (from the calculator or computer).
Is it possible?
I've been thinking of writing a program to do this, I'll get back to you on it later.
That might be cool, as there are still 82 STATS/83 users (both the same calc) around in Europe.
Title: Re: Features Wishlist
Post by: Darl181 on October 14, 2010, 06:46:54 pm
New thing.  ERR: UNKNOWN ERR  Error code: 4535555  has to do with garbage collecting.  Maybe in 1.0 it could know what the code is and garbage collect.
On second thought, it seemed to miss it or something... I had tried it ~20 times and had given up on it.  I tried again just now and it asked.  Maybe have it garbage collect on that error.
Title: Re: Features Wishlist
Post by: nemo on October 23, 2010, 09:38:13 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on October 23, 2010, 09:39:14 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.

I'd say maybe putting it in parens so that it won't be confused for key number values.
Title: Re: Features Wishlist
Post by: Runer112 on October 23, 2010, 10:15:06 pm
is there a way you could let getKey() take a variable as an argument? so getKey(A) would be valid. it'd help if you wanted to let the user configure his controls.

I guess such a routine could exist, but because of how the keyboard hardware works, it would be fairly bulky and slow. It's probably better to just stick with preassigned keys.



EDIT: So as not to double post, I'll add the following as an edit. It is, however, entirely unrelated.

I guess this request is sort of a form of look-ahead parsing, which is generally difficult to implement, but I believe this is a very basic form that has already been similarly implemented with pre-calculation involving constants. I was wondering if statements such as A+{L1+4}r, which is currently parsed as:
Code: [Select]
ld hl,(A)
push hl
ld hl,(L?+4)
pop de
add hl,de
Could be optimized to be like normal variable addition:
Code: [Select]
ld hl,(A)
ld de,(L?+4)
add hl,de
The same goes for things like subtraction and any other things I may be forgetting that could be optimized this way.


EDIT 2: Oh, by the way, you misspelled "routines" in the fourth line of the Commands.inc file :P



EDIT 3: Man, this post is getting really big! But I promise this next feature request will be simple, I'll even give you the code for it!

Code: (Hexadecimal display (?Rect or ?Polar seems like the best choice)) [Select]
p_DispHex:
.db __DispHexEnd-$-1
ld c,h
call __DispHexByte
ld c,l
__DispHexByte:
ld a,c
rra
rra
rra
rra
call __DispHexNib
ld a,c
__DispHexNib:
or F0h
daa
add a,A0h
adc a,40h
B_CALL(_PutC)
ret
__DispHexEnd:

p_TextHex:
.db __TextHexEnd-$-1
ld c,h
call __TextHexByte
ld c,l
__TextHexByte:
ld a,c
rra
rra
rra
rra
call __TextHexNib
ld a,c
__TextHexNib:
or F0h
daa
add a,A0h
adc a,40h
B_CALL(_VPutMap)
ret
__TextHexEnd:



EDIT 4: Oh, and you haven't forgotten about this (http://ourl.ca/4057/126388), have you? Haha sorry for swamping you. ;)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 24, 2010, 09:42:51 am
Hex display, definitely :D Either ▸Rect or ▸Polar would work.

And this:

Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)
Title: Re: Features Wishlist
Post by: BlackRabbit on October 24, 2010, 12:01:08 pm
Mabe you could make it so you can insert program icons. (Like in Doors or Mirage.)

Code: [Select]
.PROGRAM Description
.[16*16 hex icon]
[i]program code[/i]
Title: Re: Features Wishlist
Post by: Runer112 on October 24, 2010, 12:13:23 pm
Hex display, definitely :D Either ▸Rect or ▸Polar would work.

And this:

Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer?  I think that could be useful. :)

If you urgently need a routine for that, you could do it with the following assembly:
Code: [Select]
Asm(AF474FEDB921FFFFED42)Just put the pointer value right before that.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 24, 2010, 04:27:13 pm
If you urgently need a routine for that, you could do it with the following assembly:
Code: [Select]
Asm(AF474FEDB921FFFFED42)Just put the pointer value right before that.

That's actually exactly what I'm doing right now (even the hex string, I'm pretty sure). I just thought it might be a feature that someone might need in the future, and length( doesn't take an r yet anyway.
Title: Re: Features Wishlist
Post by: BlackRabbit on October 24, 2010, 09:36:25 pm
Thanks for the help.  :)
Title: Re: Features Wishlist
Post by: JustCause on October 25, 2010, 10:08:25 am
Setting the rand seed (think K->rand in BASIC).

(Also, on another rand note, when I use the included Guess the Number program from Mirage, the number is always either 4 or 6. Another reason for this command.)
Title: Re: Features Wishlist
Post by: calcdude84se on October 25, 2010, 10:20:50 am
AFAIK the Axe rand seed is two bytes somewhere in RAM. Maybe using °rand could get us that address? at which point you could use something like S->{°rand}r.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 10:35:10 am
I think it's {L1-2}r, the two bytes after A-Z and theta vars.
Title: Re: Features Wishlist
Post by: calcdude84se on October 25, 2010, 10:48:31 am
Nice to know :)
However, just in case he'll decide to change where it is ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 05:15:05 pm
Mhmm interesting. Personally for a game I would kinda be relunctant about setting the seed, though, because then people can memorize random number patterns and abuse luck manipulation in games :P
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 07:41:07 pm
Axe uses a random number generation method that uses more than just a seed if i remember correctly, so its impossible to set the seed, since the random number actually has an aspect of randomness to it

On a related note, i just came across something that i think is very broken.  In a program that uses a lot of included files for easier coding, if one of the sub programs has a missing End, it brings you to the very end of the top program instead of into the program that caused the error.  So if i had ProgramA

Code: [Select]
.Axe
prgmSUB

and program SUB

Code: [Select]
..SUB
While 1
Output(0,0,"Ahhhh

and tried to compile, i would get an error block in program A :( This just killed some progress on the Zedd library since i have a bunch of subprograms and i'm getting an error but i literally have no idea where it is, not even the program, so now i have to go searching through 6000 bytes of source code   :'(

EDIT: Woo i'll use sourcecoder! ^^
EDIT2: Awww it doesn't do Axe syntax :(
EDIT3: Ahk part of my source got corrupted D: well at least now i know where the error came from...
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 07:49:19 pm
And I've once gotten an ERR:BLOCK that was fixed simply by removing the Else between an If statement and an End, even though the block made perfect sense. I can't seem to recreate the bug, though :P
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 07:50:16 pm
Ooh yeah i got that too, seems that the elseIf still isnt working 100% D:

EDIT: Ok this is weird, i just got my source corrupted again O.O but it cant be the backup feature since its in a subprogram thats getting corrupted, and i even cleared my RAM from just before :(
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 07:52:35 pm
EDIT: Ok this is weird, i just got my source corrupted again O.O but it cant be the backup feature since its in a subprogram thats getting corrupted, and i even cleared my RAM from just before :(

Subprograms don't get backed up? Didn't know that...
Title: Re: Features Wishlist
Post by: Builderboy on October 25, 2010, 08:04:17 pm
Nope, another thing that might be good as an option.

Oh also, it would be nice if Axe saved whether or not you like lowercase turned on, currently it just lets you swap between what you currently have and the other option.  If i turn on Lowercase letters, clear RAM, and then go to Axe the option has changed back to uppercase.  I think it would be nice if it just automatically saved your option and applied it when you start Axe.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 25, 2010, 08:11:46 pm
Oh also, it would be nice if Axe saved whether or not you like lowercase turned on, currently it just lets you swap between what you currently have and the other option.  If i turn on Lowercase letters, clear RAM, and then go to Axe the option has changed back to uppercase.  I think it would be nice if it just automatically saved your option and applied it when you start Axe.

^ Agreed. Right now we have to go under Options > Alpha every time we RAM clear, which for me would be about 12 times a day.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 08:18:42 pm
Yeah backing up sub-programs would be good. I hope you didn't lose progress Builderboy, btw X.x.
Title: Re: Features Wishlist
Post by: Quigibo on October 25, 2010, 09:26:17 pm
As for the subprograms, they are not actual "sub" programs put part of the original code itself.  Thus you can make block abstractions within your code:

Code: [Select]
.MainProg
prgmFOREACH
.Do Stuff to element
prgmENDEACH

Code: [Select]
..ForEach
.Initialization
For(A,0,N)
.Setup

Code: [Select]
..EndFor
.Clean Up
End
.Destructor

I could check to make sure that the block level count before and after reading a subprogram is the same but then you wouldn't be able to use these abstractions.

Backing up subprograms would be a little awkward to compile.  It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume.  The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram.  But I will see if it is possible to have this as an option.  I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile.

Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe :P)
Title: Re: Features Wishlist
Post by: Runer112 on October 25, 2010, 09:46:21 pm
Ahh, Quigibo! Did you read my epic (http://ourl.ca/4057/131942) on the last page? ;)

Also, a new request for TI Program Editor users like me (although I'm probably the only one lol). When saving 8xp files, if a lowercase letter represents something special (u, v, w are equation variables and a, b, c, d, e, n, p, r, s, t, z are statistics variables), TI Program Editor parses these as these special tokens and not lowercase letters. Due to this, they turn into garbage when parsed inside strings by Axe. Could you make these tokens be parsed as the lowercase letters they actually represent?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 25, 2010, 09:55:01 pm
Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe :P)
That might be a better idea. It would save some time when we get errors
Title: Re: Features Wishlist
Post by: jnesselr on October 25, 2010, 11:41:00 pm
I don't know if this has been requested, but 32 bit math would be awesome.
Title: Re: Features Wishlist
Post by: Runer112 on October 25, 2010, 11:47:48 pm
I don't know if this has been requested, but 32 bit math would be awesome.

It would. It would also require Quigibo to completely rewrite every math routine and auto-optimization for a 32-bit mode, as well as needing to create ways to interweave it with the normal 16-bit mode, both on the compiled program side and the parser side. It would be a long and difficult undertaking, and although it would be awesome, I think its sheer difficulty makes it a low priority.

An 8-bit mode has been requested too, and even though that would undoubtedly be a good deal simpler and easier to code, that's still the kind of thing Quigibo doesn't imagine implementing until the far future, like Axe 2.0.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 26, 2010, 02:48:28 am
Yeah if I remember it was gonna remain 1 and 2 bytes for a while. For RPGs you will probably need to have to use lower range of HP/EXP/Gold for now.
Title: Re: Features Wishlist
Post by: Builderboy on October 26, 2010, 02:51:19 am
Also it probably wouldn't be too bad to write a small 32 bit library for Axe, since we have all the multiplication routines we need, it could even be an axiom! :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 26, 2010, 02:59:20 am
True. I recall people tried to do this before but I don't remember if anyone succeeded. In score cases, one thing you can do is add a few artificial zeroes at the end of the number, like 6553500, on the screen. In that case the score would need to increase by 100 everytime, though.
Title: Re: Features Wishlist
Post by: Yeong on October 27, 2010, 04:01:58 pm
I hope that axe supports 4-layer(?) sound like quadplayer.(Or is it possible already and I just don't know how?)
Title: Re: Features Wishlist
Post by: Binder News on October 27, 2010, 08:02:11 pm
Here is a link to my idea. http://ourl.ca/7202/132891 (http://ourl.ca/7202/132891)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 27, 2010, 11:28:51 pm
I hope that axe supports 4-layer(?) sound like quadplayer.(Or is it possible already and I just don't know how?)
I'm not sure if this would be possible, but if it is, I have some doubts games could run fast enough while such complex sound is played.
Title: Re: Features Wishlist
Post by: Binder News on October 28, 2010, 09:29:26 am
If the calc had dual-processors maybe, but it obviously doesn't.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 28, 2010, 06:31:25 pm
Right now, the only way I can see it possible is if the sound plays for an incredibly short period of time every centisecond or something, letting an instruction be executed between every sound. However, that might sound really crappy.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 30, 2010, 06:50:56 pm
well, just don't try it. I'll just only get you disappointed, I think...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 31, 2010, 03:02:02 am
well, just don't try it. I'll just only get you disappointed, I think...
Well if we don't bother trying anything just because it may not work, we would never have seen Axe Parser, TI-Boy SE, Ndless and Geometry Wars for the calculators. This attitude was common in the community back in 2001-07 and nothing was getting done. Even if the end result is a failure, it doesn't hurt to try in the first place.
Title: Re: Features Wishlist
Post by: Quigibo on October 31, 2010, 05:55:17 pm
You actually can have multi-channeled sound right now using the "Port" command to get similar quality to quadplayer.  There is no way you'd be able to have much of a game going on in the background though, but if you're just doing this for the audio itself, it sure is possible, just a little tricky.
Title: Re: Features Wishlist
Post by: LordConiupiter on October 31, 2010, 06:27:34 pm
well, just don't try it. I'll just only get you disappointed, I think...
Well if we don't bother trying anything just because it may not work, we would never have seen Axe Parser, TI-Boy SE, Ndless and Geometry Wars for the calculators. This attitude was common in the community back in 2001-07 and nothing was getting done. Even if the end result is a failure, it doesn't hurt to try in the first place.
yep, that's right. perhaps I've even gotta try it myself ;) I like tricky things, and this case is sounding particularly intresting!
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 06:59:05 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:00:24 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:01:29 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D

That's what we're talking about, though. Sound on calcs with Axe. There already are a lot of programs with sound on calcs, but you just need to find earphones to match.
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:02:11 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

Calculators can't have sound, so guitar hero wouldn't be as cool.

HOWEVER, I'd like a game which interface it's just like Guitar Hero :D

That's what we're talking about, though. Sound on calcs with Axe. There already are a lot of programs with sound on calcs, but you just need to find earphones to match.

WHAAAAAAAAAAAAAAAAAAAAATTTTTTTTTTTTT THEEEEEEEEEEEEEEEEEEEEEEEEEEEE FFFFFFFFFF*******************************************************************************????????


SOOOOUUUUUNNNNDDDD???????
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 07:02:29 pm
Calculators can't have sound, so guitar hero wouldn't be as cool.
Yes they can?
Title: Re: Features Wishlist
Post by: Munchor on October 31, 2010, 07:02:54 pm
Calculators can't have sound, so guitar hero wouldn't be as cool.
Yes they can?
OOOOH MYY GOOOD, I WANT HEADPHONES, WHAT TYPE?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:05:12 pm
Yeah, sound's been on calcs for quite a while. You need a 2.5 mm headphone, but you gotta find the right one. I don't know where to find ones that will work, though.
Title: Re: Features Wishlist
Post by: Runer112 on October 31, 2010, 07:30:34 pm
Yeah, sound's been on calcs for quite a while. You need a 2.5 mm headphone, but you gotta find the right one. I don't know where to find ones that will work, though.

The easiest thing to do is use normal headphones with a 2.5mm male to 3.5mm female converter. The converter should only be a few dollars, and you can probably find one at a Radio Shack (that's where I got mine) or a similar store. You can buy one online too.

A warning though: make sure it will actually fit into your calculator! The one I got just barely fits into the link port of my TI-84 Plus SE. If it were any larger I'm sure it would not have fit.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 07:49:10 pm
Hmm, isn't the iPod headphone 2.5 mm? Does anyone know if that'll work? I need to find it, though...
Title: Re: Features Wishlist
Post by: Happybobjr on October 31, 2010, 08:15:36 pm
if it 2.5 then it will work
Title: Re: Features Wishlist
Post by: calc84maniac on October 31, 2010, 08:17:12 pm
If you want to make sure you get an adapter that fits, you can get a 2.5mm-female to 3.5mm-female and connect it to a TI link cable. That's what I did (more or less)
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:18:50 pm
Mkay, I dug up an old 2.5 mm jack out of the attic, and it worked perfectly - better quality sound then I would have thought!  :)
However, my calculator becomes incredibly sluggish when it's plugged in, but works fine when I play the sample Axe sound program, so I have to run the program, then plug in, then remove the jack after I'm done.  Anybody know why this is?
Title: Re: Features Wishlist
Post by: Deep Toaster on October 31, 2010, 08:19:50 pm
The OS is probably checking constantly for link activity.

By the way, could you send me the source for that program? I lost it.

EDIT: Oh, wait, never mind. It's in the Axe .zip :D
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:20:27 pm
Oh.  How do I make it stop?
Title: Re: Features Wishlist
Post by: calc84maniac on October 31, 2010, 08:21:34 pm
You can just unplug it until you start running a program.
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 08:27:42 pm
Well, in theory you could install a hook to disable silent linking completely (or to try to auto-detect whether you have headphones plugged in) but it would still be draining the calculator's batteries.  I'd say just unplug the headphones when you're not using them.
Title: Re: Features Wishlist
Post by: Michael_Lee on October 31, 2010, 08:31:26 pm
Aw.  Okay, I guess it's really not too much of a hassle.
Does anybody know of a good song or song player thing that I can add so I can show this off at school?
Title: Re: Features Wishlist
Post by: FloppusMaximus on October 31, 2010, 08:37:08 pm
Jim e wrote a program called "Real Sound" that packs a sound file into a Flash app.  The app will, of course, be huge for a song of any length, but it does work pretty well.

(I think it's one of those programs that relies on the extra RAM, so it won't work on recently-manufactured 84+es.)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 03:46:03 am
You actually can have multi-channeled sound right now using the "Port" command to get similar quality to quadplayer.  There is no way you'd be able to have much of a game going on in the background though, but if you're just doing this for the audio itself, it sure is possible, just a little tricky.
Hmm thanks for pointing that out. One more thing I need to try when I start experimenting with sound :)
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)
Yeah, the sound quality was really low, but it still demonstrates that sounds in-game is still possible :)

We can sacrify some frames per second for sound, I am sure. I don't think we really need 60 FPS, because it looks blurry on those LCDs, anyway. I think 12-20 FPS is just enough.

Jim e wrote a program called "Real Sound" that packs a sound file into a Flash app.  The app will, of course, be huge for a song of any length, but it does work pretty well.

(I think it's one of those programs that relies on the extra RAM, so it won't work on recently-manufactured 84+es.)
If I remember, one minute of sound is about 1.3 MB on calc. I had a rickroll APP on United-TI before they switched servers. I think such stuff isn't really practical in-game, though. The sound needs to be lower quality, because I don't think many people will want to play a 500 KB tunnel clone just because it plays through a 30 second segment of "Initial D - Feel The Power" until you die in-game or from the music (not that that song is bad, though).
Title: Re: Features Wishlist
Post by: LordConiupiter on November 01, 2010, 04:01:57 am
well, perhaps could Quigibo add some intruments? just like midi on-PC works: not just only the basic peep tone, but also tones of instruments! that would be really very cool! You could use following syntax of the renamed PwrReg command:
Code: (Axe) [Select]
Midi([INSTRUMENT NO],[FREQUENCY])
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 04:03:46 am
That might be hard to get such complex sound files to play with others at once, though. And music with only one instrument playing at once would be a bit simple I think.

Also I just noticed this topic got 100 pages! O.O
Title: Re: Features Wishlist
Post by: JustCause on November 01, 2010, 10:37:30 am
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)
Title: Re: Features Wishlist
Post by: LordConiupiter on November 01, 2010, 11:31:18 am
I would like to be able to use Apps as Libs, like we have ExecLib and OpenLib in BASIC!
(for use with USB8x)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 12:10:23 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)
What does happens with it? Does it just changes Symbolic tokens or does it simply overwrite its hooks? That seems like something Quigibo might want to check, but again, Symbolic is so old that it might be best to not bother, not to mention both apps have no relation to each others (one is math-oriented while the other is programming-oriented).

I would like to be able to use Apps as Libs, like we have ExecLib and OpenLib in BASIC!
(for use with USB8x)
That might be nice, but those games would not run on the TI-83+ and TI-83+SE :(

Also how do we use OpenLib/ExecLib anyway?
Title: Re: Features Wishlist
Post by: JosJuice on November 01, 2010, 12:32:01 pm
Also how do we use OpenLib/ExecLib anyway?
There's some information about it in the USB8x documentation (that program is pretty much the only one that uses these functions...)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 12:38:36 pm
Ah ok. Not even one TI app does? O.o
Title: Re: Features Wishlist
Post by: AngelFish on November 01, 2010, 12:52:36 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)

What exactly do you mean? I haven't noticed anything and I use both Symbolic and Axe quite frequently.

EDIT: I've mentioned this before, but a Not( function would be nice. There are times when you simply have multiple conditions for a conditional and one of them happens to be negated. It'd probably save a byte to have a token implement the function versus typing in "0=" and in any case, the TI-OS token is already there for the taking.

A way to execute the BASIC-interpreter (to allow external subprograms) would be nice too, although that might be a bit unrealistic since the interpreter is probably scattered around the OS.
Title: Re: Features Wishlist
Post by: ASHBAD_ALVIN on November 01, 2010, 02:04:21 pm
I wish that axe could run ASM programs that are already compiled.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 04:28:06 pm
Hookless mode!

Basically, I just discovered that Axe steps all over Symbolic, and I'm in Accelerated Calculus (which means I need Symbolic). Would it be marginally possible to have a version of Axe that doesn't screw with tokens? (honestly, it's slightly unnerving anyway XD)

What exactly do you mean? I haven't noticed anything and I use both Symbolic and Axe quite frequently.

EDIT: I've mentioned this before, but a Not( function would be nice. There are times when you simply have multiple conditions for a conditional and one of them happens to be negated. It'd probably save a byte to have a token implement the function versus typing in "0=" and in any case, the TI-OS token is already there for the taking.

A way to execute the BASIC-interpreter (to allow external subprograms) would be nice too, although that might be a bit unrealistic since the interpreter is probably scattered around the OS.
Strange, maybe it's an OS/calc-specific issue?
Title: Re: Features Wishlist
Post by: ztrumpet on November 01, 2010, 04:37:10 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.
http://ourl.ca/3610

Does anybody know of a good song or song player thing that I can add so I can show this off at school?
http://ourl.ca/6456
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 06:10:53 pm
There's also Mobiletunes over Cemetech, but I think you need to convert the songs to z80 then compile them to ASM files, so the process is a bit more complicated.
Title: Re: Features Wishlist
Post by: FloppusMaximus on November 01, 2010, 10:32:50 pm
Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.
http://ourl.ca/3610
Yeah, that's the one I was thinking of.  The UTI thread is now at http://www.unitedti.org/forum/index.php?showtopic=8917 .
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 01, 2010, 10:38:05 pm
Ah right, 8 KHz quality. On my headphones, there was a big acute hiss. I wonder if that can be removed from such calc sound? I know the old Playwav from TCPA team and RealSound from Revsoft did that too
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 07:55:43 pm
A couple of feature requests:


Also, automatically converting While 1 and Repeat 0 into endless loops would be nice, if that's not added already.
Title: Re: Features Wishlist
Post by: squidgetx on November 04, 2010, 07:56:40 pm
A couple of feature requests:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

YES

Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 08:02:16 pm
Oh, and

Title: Re: Features Wishlist
Post by: calc84maniac on November 04, 2010, 08:07:24 pm
Oh, and

  • Allowing jumping to an arbitrary place in memory
That can be done using a simple Asm(E9), which will jump to the address of the last result
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 08:13:33 pm
Wow, I didn't think of that. Thanks!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2010, 11:21:35 pm
I like the For( idea.

Could you explain examples of usage of jumping to an arbitrary place into memory? I'm not too sure what it does exactly...
Title: Re: Features Wishlist
Post by: Deep Toaster on November 04, 2010, 11:50:24 pm
I like the For( idea.

Could you explain examples of usage of jumping to an arbitrary place into memory? I'm not too sure what it does exactly...

Well, I'm working on a game where each level adds some new feature, and to save space, I'd like to store all the code for those features in the form of data, move it to L2 before the level starts, and just run the code from there. That way, it doesn't check for the level in a huge If -ElseIf -End statement each pass.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2010, 11:53:02 pm
Ah sounds cool, thanks for the info :)

By the way I'll create the sub-forum for it now so you can post :)
Title: Re: Features Wishlist
Post by: calc84maniac on November 04, 2010, 11:53:57 pm
This is why we need a switch statement.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 05, 2010, 10:40:51 am
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?

Ah sounds cool, thanks for the info :)

By the way I'll create the sub-forum for it now so you can post :)

The feature request was actually for a different (much smaller) game I'm working on. But thanks for the subforum :D
Title: Re: Features Wishlist
Post by: calc84maniac on November 05, 2010, 01:13:02 pm
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?
Nope, switch statement is supposed to do exactly what you were saying, jump to one of a bunch of routines using a table of addresses. It should take the same amount of time for any of the different cases. My plan to make it simpler for Axe to handle was to only allow switching of values 0,1,2,3,...,N, and a default case if the value is greater than N. So what if you wanted to switch and check for A=3,4,5,6? Well, just switch(A-3) and use cases of 0,1,2,3. I don't know if Quigibo will decide to do it this way, though.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 07, 2010, 12:28:55 pm
This is why we need a switch statement.

Doesn't that still take a lot of time to go through, though (when it's run)?
Nope, switch statement is supposed to do exactly what you were saying, jump to one of a bunch of routines using a table of addresses. It should take the same amount of time for any of the different cases. My plan to make it simpler for Axe to handle was to only allow switching of values 0,1,2,3,...,N, and a default case if the value is greater than N. So what if you wanted to switch and check for A=3,4,5,6? Well, just switch(A-3) and use cases of 0,1,2,3. I don't know if Quigibo will decide to do it this way, though.

Oh, sounds like a good idea, then.

A couple of feature requests:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

YES



Or an alternative: allowing programs to define where the vars point.
Title: Re: Features Wishlist
Post by: calcdude84se on November 10, 2010, 05:06:45 pm
Or an alternative: allowing programs to define where the vars point.
Hm. I could see this being useful, but I'm not sure how you would define it, and I'm not sure how well the compiler could handle it...
Also, perhaps For( could just be redefined to take an address instead of a variable? (Use For( °A,S,E) instead of For(A,S,E). This would also make for a more consistent For(L1,S,E) instead of having to use {})
Edit: And you'd have to maintain backwards compatibility, as I just realized.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 10, 2010, 07:43:06 pm
I think something like E89F0→°A would be great. It should be a quick addition to Axe, and Quigibo could still keep the current values as default values and maintain backwards compatibility :)

And as for using addresses in For( loops, I don't think that's a good idea. It's not backwards compatible, as you mentioned, and it'll confuse TI-BASIC programmers who are used to having a var in For(.
Title: Re: Features Wishlist
Post by: nemo on November 10, 2010, 07:47:06 pm
I think something like E89F0→°A would be great. It should be a quick addition to Axe, and Quigibo could still keep the current values as default values and maintain backwards compatibility :)

And as for using addresses in For( loops, I don't think that's a good idea. It's not backwards compatible, as you mentioned, and it'll confuse TI-BASIC programmers who are used to having a var in For(.

For(ADDRESS,start,end)r

problems solved? that is, if quigibo feels like implementing it
Title: Re: Features Wishlist
Post by: Deep Toaster on November 10, 2010, 08:01:23 pm
I'd rather see that as a For( loop that counts backwards, kinda like how Copy( and Fill( work. Besides, it's only one less keystroke than For({ADDRESS},START,END) ;)

Whatever Quigibo decides, though. It's his language :)
Title: Re: Features Wishlist
Post by: Runer112 on November 11, 2010, 12:03:52 am
EDIT: Whoops. Ignore this lol.
Title: Re: Features Wishlist
Post by: Darl181 on November 11, 2010, 12:09:31 am
I've mentioned lines to back-buffer already, I'm pretty sure, but I just ran into a problem with a possible menu.
So, I was thinking...whatever you can do with a sprite (on, off, change) you could do with a line, to both buffers.
Something like this would help with filling a large, outline block-style font with grayscale and changing it back again (i.e. the flash TWHG's menu, grayscale-ified for the calc)

EDIT: it looks kind of like the poll's decided :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 11, 2010, 04:01:18 pm
Would it be possible/easy to change all the commands that can't be used in axe to "..." or something similar?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:03:33 pm
That would be very, very impractical, unfortunately. The token hook that allows Axe to replace the TI-OS tokens with Axe tokens literally checks to see if the token is in a table, then replaces it with the matching Axe token. If we were to change the 200 or so unused tokens to anything else, imagine how slow editing would be :P
Title: Re: Features Wishlist
Post by: Builderboy on November 11, 2010, 04:04:21 pm
Possible i imagine, although also it would probably take up an extremely large amount of space and/or make editing very slow D: but i don't pretend to be an expert in these token hooks so don't ask me ;D

EDIT: Ninja :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 11, 2010, 04:11:08 pm
:(

oh well, it was worth asking.
Title: Re: Features Wishlist
Post by: calc84maniac on November 11, 2010, 04:12:54 pm
Actually, if they were all changed to the same string "...", it wouldn't take much more effort. Instead of just returning if an Axe token is not found, pass that string instead.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:14:14 pm
Actually, if they were all changed to the same string "...", it wouldn't take much more effort. Instead of just returning if an Axe token is not found, pass that string instead.

Whoops :-[

Sounds like a good idea, then ;D Unless it gets too slow.
Title: Re: Features Wishlist
Post by: Builderboy on November 11, 2010, 04:14:26 pm
Would that work within a reasonable speed?
Title: Re: Features Wishlist
Post by: Munchor on November 11, 2010, 04:16:22 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:20:17 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*

What do you mean? Replacing Str1 with a new value? You can do that by

Code: (Axe) [Select]
:"Up"→Str1 .Original value
:[0000] .Two extra zeroes for padding because "Down" is two bytes longer
:"Down"→Str2 .Temporary pointer
:Copy(Str2,Str1,4)

The problem with doing it directly with "Down"→Str1 is that since Str1 is just a piece of memory in the program, you'd overwrite whatever came after it if you replace it with a longer string.
Title: Re: Features Wishlist
Post by: Munchor on November 11, 2010, 04:31:52 pm
So, I can do that with Pictures too?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 11, 2010, 04:35:19 pm
Yeah, Str's, Pic's, and GDB's aren't really vars. They're just pointers to data inside the program, so they're completely interchangeable.

Except when you're accessing the actual variables with GetCalc(, but that's completely different.

EDIT: A feature request: Goto LBLIf CONDITION/Goto LBL!If CONDITION syntax.
Title: Re: Features Wishlist
Post by: calcdude84se on November 12, 2010, 09:38:52 pm
I second the request for "Goto LBLIf CONDITION" and Goto LBL!If CONDITION"
Makes things much more compact, and something tells me the assembly code might be more efficient.
Code: (Before) [Select]
;Using If CONDITION:Goto LBL:End
;Check for condition puts results in, say, z
jr nz,condition_false
jp label
condition_false:
;label is elsewhere
Code: (After) [Select]
;Using Goto LBLIf CONDITION
;Check for condition puts results in, say, z
jp z,label
;label is elsewhere
A vast oversimplification, probably, but I'm thinking it could make things more efficient. :)
Title: Re: Features Wishlist
Post by: Munchor on November 14, 2010, 03:45:36 pm
I'd like a few updates, however, not in the language itself:

In the Application:

You have four options, Compile, Options,Help and Quit.

*Maybe make that when you press up in Compile it goes to quit and the opposite.
*Make the same thing happen with the Compile list.
*Make the Help button give something lol.
*Make that AFTER YOU COMPILE, it goes back to the compile list, because sometimes I wanna compile +1 program, especially when I do RAM delete.


These should not be hard to make and I expect them in next version, so.

The first one is not really needed, it's just that it looks well.

Thanks!
Title: Re: Features Wishlist
Post by: Runer112 on November 14, 2010, 03:59:25 pm
These should not be hard to make and I expect them in next version, so.

Quigibo has been very busy with things in life besides Axe, and has just been trying to get out the next version of Axe as it is, without adding everybody's feature requests. There have been many feature requests, and there's no reasonable way he could get to all of them, especially with how busy he has been lately. I've made a few feature requests myself. For one of them I even gave him the exactly assembly code he would need for it. And I still don't expect that Quigibo has to include it in the next version, or any version for that matter. He will add features as he deems that they should be added, and when he has the time to add them. It's not any one of our calls but his to say that the features we want should be in the next version. Announcing that you expect features to be in the next version puts Quigibo in the unfair position of feeling that he needs to include these features in the next version or he will disappoint you.
Title: Re: Features Wishlist
Post by: Munchor on November 14, 2010, 04:27:53 pm
These should not be hard to make and I expect them in next version, so.

Quigibo has been very busy with things in life besides Axe, and has just been trying to get out the next version of Axe as it is, without adding everybody's feature requests. There have been many feature requests, and there's no reasonable way he could get to all of them, especially with how busy he has been lately. I've made a few feature requests myself. For one of them I even gave him the exactly assembly code he would need for it. And I still don't expect that Quigibo has to include it in the next version, or any version for that matter. He will add features as he deems that they should be added, and when he has the time to add them. It's not any one of our calls but his to say that the features we want should be in the next version. Announcing that you expect features to be in the next version puts Quigibo in the unfair position of feeling that he needs to include these features in the next version or he will disappoint you.

I know of course, it may look like an order now that I read it, sorry.

What I mean is that those are really easy to make since thei're not the language itself, just that.

The other day he said he had college tests a lot and the version 0.5 would take a long time to come, but I'm not worried, I totally understand him :D
Title: Re: Features Wishlist
Post by: squidgetx on November 14, 2010, 08:44:09 pm
Personally I like how it instant exits after compiling; saves a lot of time for debugging. More people will be compiling one program at a time than those who want to compile more than 1 program at once :P
Title: Re: Features Wishlist
Post by: Darl181 on November 14, 2010, 09:35:28 pm
I really want this to be possible:

Code: [Select]
"Up"->Str1
"Down"->Str1

I'd love to see that *.*
"ERR:DUPLICATE"
And help doing something would help be useful...;D
Also, this was already mentioned I believe, but I second whoever asked for the size of the program* to be displayed on the "Compiling..." screen.
*like it does for apps, maybe?

"help working would help"...wow/me facepalms
Title: Re: Features Wishlist
Post by: calcdude84se on November 14, 2010, 09:49:11 pm
Ztrumpet mentioned something like this:
Code: [Select]
"Up"->Str1
"Down"->Str2
If CONDITION
Str1->A
Else
Str2->A
End
So A is your variable pointer :)
Title: Re: Features Wishlist
Post by: calc84maniac on November 14, 2010, 09:52:09 pm
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)
Title: Re: Features Wishlist
Post by: calcdude84se on November 14, 2010, 10:02:48 pm
Ah, right, forgot about inlining of data definitions x.x
Essentially the same thing, though.
Title: Re: Features Wishlist
Post by: calc84maniac on November 14, 2010, 10:05:14 pm
If you are going to use a string more than once, it is a good idea to give it a name, though. If you inline the string each time, the data will be added again and again. (Well, unless Quigibo made it check for duplicates, but I think that would be a waste of processing time)
Title: Re: Features Wishlist
Post by: lookitsan00b on November 14, 2010, 10:21:07 pm
If you are going to use a string more than once, it is a good idea to give it a name, though. If you inline the string each time, the data will be added again and again. (Well, unless Quigibo made it check for duplicates, but I think that would be a waste of processing time)

actually, it probably compiles to something like:

Code: [Select]
;getkey stuff here
 cp 4
 jq nz,lb1
 ld de,P_Address
 ld hl,str1
 ld (de), hl
lb1:
...
data_section:
str1:
 db "Up", 0
Title: Re: Features Wishlist
Post by: Runer112 on November 14, 2010, 10:33:16 pm
This is what disassembly is for :P

Code: [Select]
;getKey stuff here
ld hl,($8700) ;$8700 = K
ld a,l ;K=4 check
sub 4
or h
ld hl,$01
jr z,$+3
dec l
ld a,h ;Standard If statement code
or l
jp z,EndIf
ld hl,string ;If statement contents
ld ($870A),hl ;$870A = P
EndIf:
;Other stuff


string:
.db "Up", 0
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 15, 2010, 02:49:38 am
I would like the option to return on the compile list after compiling a program or the menu. It would be best if we could also choose to exit, though. Some people may be working on multiple programs at once, but a lot of people will most likely only compile one program at a time. That said, it is not really a hurry, though.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 15, 2010, 02:25:08 pm
Quote from: calc84maniac
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)

Thanks, didn't know that. I don't understand how the parentheses work, though...
Title: Re: Features Wishlist
Post by: Builderboy on November 15, 2010, 02:28:15 pm
Wait calc84 is that an explanation or a request?
Title: Re: Features Wishlist
Post by: ztrumpet on November 15, 2010, 03:37:42 pm
Explanation ;)
Title: Re: Features Wishlist
Post by: Builderboy on November 15, 2010, 04:22:43 pm
Ah i understand it now, thats really useful!
Title: Re: Features Wishlist
Post by: calc84maniac on November 15, 2010, 05:22:13 pm
Quote from: calc84maniac
You can always use a variable as a pointer to a string, and change that variable. For example, P is used as a pointer in the following program:
Code: [Select]
Repeat getKey->K
End

If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End

Disp P

("String") tells Axe to insert the string data at the end of the program and return a pointer to it. The parentheses are important because it tells Axe that it is an expression and needs to return the pointer, instead of it being a simple data definition (in which case no code is generated)

Thanks, didn't know that. I don't understand how the parentheses work, though...

Well, try "Up"->P. Axe will give an error, because when a line starts with a double quote Axe is expecting it to be stored to a static pointer (like Str1A), or else just inserted at the end. Starting with parentheses tells Axe that you are actually evaluating an expression here, and thanks to the inline data support Quigibo added recently, a pointer is returned to the inserted string.
Title: Re: Features Wishlist
Post by: Quigibo on November 16, 2010, 05:40:25 pm
Actually, storing to a variable might be valid syntax in the next version, that is "Hello"->P will be parsed the same as ("Hello")->P
Title: Re: Features Wishlist
Post by: Deep Toaster on November 16, 2010, 07:09:06 pm
Actually, storing to a variable might be valid syntax in the next version, that is "Hello"->P will be parsed the same as ("Hello")->P

Would that be necessary, though? It might make people think P is the string, and "Hello"→Str1:Str1→P doesn't add any extra code...

EDIT: Actually, wait, never mind. It's a great idea!
Title: Re: Features Wishlist
Post by: Darl181 on November 17, 2010, 08:02:02 pm
Something like this would be great. (http://ourl.ca/4129/80700)
Title: Re: Features Wishlist
Post by: calc84maniac on November 17, 2010, 09:10:06 pm
Something like this would be great. (http://ourl.ca/4129/80700)
You can already compile for MirageOS. Check out the Options menu :)
Title: Re: Features Wishlist
Post by: FinaleTI on November 17, 2010, 09:14:05 pm
I think he meant built-in icon support, like you can define a description.
It's been requested before, I believe.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 18, 2010, 07:39:30 pm
I think he meant built-in icon support, like you can define a description.
It's been requested before, I believe.

That's a good idea, but I think it should not be added to Axe. Matching icons to each program would be too complicated.
Title: Re: Features Wishlist
Post by: squidgetx on November 18, 2010, 08:25:18 pm
Matching icons to each program would be too complicated.

??? In what way; I don't quite get what you mean. I think he's just looking for a way to just define the 16x16 icon in the header or something in a similar way that Sir's program gives you hex to paste into the first line of the program, but instead of using Sir's program, the new feature would allow you to do
Code: (for example) [Select]
.Program [hex for icon image] or something similar
Title: Re: Features Wishlist
Post by: Deep Toaster on November 18, 2010, 08:26:55 pm
Matching icons to each program would be too complicated.

??? In what way; I don't quite get what you mean. I think he's just looking for a way to just define the 16x16 icon in the header or something in a similar way that Sir's program gives you hex to paste into the first line of the program, but instead of using Sir's program, it would just be
Code: (for example) [Select]
.Program [hex for icon image] or something similar

Oh, like that. That sounds like a good idea. I was thinking that the icon wouldn't actually be in the program, which would make things complicated.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 18, 2010, 09:27:28 pm
Quote
[19:19:29] <nemo> anyone know how to add a DCS description in an Axe program?

Is that possible in Axe? If not, maybe as new feature in one of the upcoming versions?
Title: Re: Features Wishlist
Post by: nemo on November 18, 2010, 09:28:44 pm
Quote
[19:19:29] <nemo> anyone know how to add a DCS description in an Axe program?

Is that possible in Axe? If not, maybe as new feature in one of the upcoming versions?

and an Icon. of course it can probably be done by combining a little inline ASM as instructed here (http://dcs.cemetech.net/index.php?title=ASM_Header).
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 18, 2010, 09:35:21 pm
Yeah true. It would be cool if it was implemented in Axe, though.

At first, I think it was not added because I suggested Quigibo to do some publicity for Axe by having the default icon, to attract more programmers, but I don't think this is needed as much anymore now that most Axe users put his credits in the readme.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 19, 2010, 08:46:02 pm
Not sure about this one, but as a feature request, could sin( and cos( be changed so that they output numbers in the fixed-point format that's used by **? It would be a bit easier to work with.

Also, instead of this:

  • Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.

I have a different suggestion. How about POINTER→°VAR to set our own variables? It would be easier to work with than the one I posted earlier.
Title: Re: Features Wishlist
Post by: ztrumpet on November 20, 2010, 11:05:26 am
I would like a feature that changes the value of the org at that point.  This would be to get around the 8k code limit. :)
Title: Re: Features Wishlist
Post by: Munchor on November 20, 2010, 11:08:45 am
We can't use Pi symbol in Axe, can we?

If so, it would be cool if we could, because of a probable Formulum Axe Version and other programs too of course!
Title: Re: Features Wishlist
Post by: Deep Toaster on November 20, 2010, 11:16:06 am
Nope, no pi. I think Quigibo was thinking of adding it for a different purpose, though (quickly saving as temporary mem).
Title: Re: Features Wishlist
Post by: Munchor on November 20, 2010, 11:17:10 am
Nope, no pi. I think Quigibo was thinking of adding it for a different purpose, though (quickly saving as temporary mem).

We can also define pi like:
Code: [Select]
3.14159265358979323846264338327950288419716939937510->P
Title: Re: Features Wishlist
Post by: Deep Toaster on November 20, 2010, 11:17:59 am
Remember, no decimals in Axe. Periods signify comments, so all Axe sees in that line is the number 3.
Title: Re: Features Wishlist
Post by: Michael_Lee on November 22, 2010, 05:33:28 pm
You could just take your number, inflate it by multiplying it by 128 or something, then divide by 100, multiply by 314, then finally de-inflate by dividing by 128.
N*128*314/199/128->N
Title: Re: Features Wishlist
Post by: Deep Toaster on November 22, 2010, 06:38:12 pm
You could just take your number, inflate it by multiplying it by 128 or something, then divide by 100, multiply by 314, then finally de-inflate by dividing by 128.
N*128*314/199/128->N


For more accuracy, though, you might want to just keep N inflated (by 128 or 256). Then anything you add to or subtract form N would need to be inflated that same amount, and when you actually use N, just deflate it by N/128 or N/256.

And apparently I haven't actually posted this yet, so a feature request: Changing sin( and cos( so that they have a range of -256 to 256 instead of -128 to 128 so that they match the fixed point numbers used by **.
Title: Re: Features Wishlist
Post by: Runer112 on November 22, 2010, 10:42:36 pm
The current sine and cosine routines produce 1-byte outputs, which is why the range is from -127 to 127. It uses a basic approximation that already isn't completely accurate for the output range of -127 to 127, so expanding the output range would just inflate the inaccuracies as well. If you want to inflate the output values, it's probably not that difficult to do with Axe anyways. And if he were to modify the routine to be more accurate and produce 2-byte outputs, it would require a better approximation method and would surely be a much heftier and slower routine.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 23, 2010, 09:39:55 am
The current sine and cosine routines produce 1-byte outputs, which is why the range is from -127 to 127. It uses a basic approximation that already isn't completely accurate for the output range of -127 to 127, so expanding the output range would just inflate the inaccuracies as well. If you want to inflate the output values, it's probably not that difficult to do with Axe anyways. And if he were to modify the routine to be more accurate and produce 2-byte outputs, it would require a better approximation method and would surely be a much heftier and slower routine.

Oh, okay. It's fine the way it is, anyway (just multiply by two for fixed-point math).
Title: Re: Features Wishlist
Post by: Runer112 on November 23, 2010, 10:04:17 am
Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:
Code: (31 bytes) [Select]
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B

When the signed division auto-optimizations are fixed, a better way will be this:
Code: (15 bytes) [Select]
sin(A)*256//256
EDIT: Disregard all of that, the number comes out as fixed point after all.
Title: Re: Features Wishlist
Post by: calc84maniac on November 23, 2010, 10:11:25 am
Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:
Code: (31 bytes) [Select]
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B

When the signed division auto-optimizations are fixed, a better way will be this:
Code: (15 bytes) [Select]
sin(A)*256//256
Um, even though the outputs are in the range -127 to 127, they are still sign extended to 16-bits. All you have to do is multiply by 2 to get the range of about -256 to 256 which is -1 to 1 in 8.8 fixed point.
Title: Re: Features Wishlist
Post by: Runer112 on November 23, 2010, 10:58:57 am
Oh, nevermind then. I just glanced at the routine and didn't see any 16-bit register operations so assumed it was all 8-bit. But now I see the dec h.
Title: Re: Features Wishlist
Post by: Quigibo on November 23, 2010, 03:04:40 pm
The reason Sin and Cos are -128 to 127 instead of -256 to 255 is because that way, you can fit the result in a single byte.  Also its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2010, 03:13:56 pm
its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.

Curious i would think, it takes more memory to go one way than the other way?  I guess some operations don't have an equivalent inverse in asm?
Title: Re: Features Wishlist
Post by: calc84maniac on November 23, 2010, 03:17:23 pm
its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.

Curious i would think, it takes more memory to go one way than the other way?  I guess some operations don't have an equivalent inverse in asm?

Yep, it's add hl,hl vs. sra h \ rr l. If the add hl,hl instruction didn't exist, it would take 4 bytes to multiply by two as well, by using sla l \ rl h.
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2010, 03:19:21 pm
Ah i see, its a small optimization that allows you to double HL :) Gotcha, that makes sense ^^
Title: Re: Features Wishlist
Post by: Michael_Lee on November 25, 2010, 12:11:50 pm
Request:
Command to interact directly with bits, sort of like the nib{ command.
Also, I'm pretty sure this has been requested before, but a way to draw lines and write text to the backbuffer.  Please?
Title: Re: Features Wishlist
Post by: Yeong on November 25, 2010, 12:20:10 pm
Request:
Also, I'm pretty sure this has been requested before, but a way to draw lines and write text to the backbuffer.  Please?
Don't you add r to write at the back buffer?
ex) Line(a,b,c,d)r

My request
including compiled prgm/BASIC prgm in Axe source code
Title: Re: Features Wishlist
Post by: nemo on November 25, 2010, 12:23:33 pm
yeong, no, drawing lines to the backbuffer isn't supported. also, i *think* Asm(prgmCOMPILED) should work. not sure. but implementing BASIC would be far more difficult.

two relatively simple requests: BCalls InsertMem, DelMem, where the variable's size field is automatically updated and it checks to see if there's enough RAM.
Ex.
InsertMem([POSITION],[SIZE]) returns 0 if not enough RAM or 1 if successfully added.
same with DelMem.
Title: Re: Features Wishlist
Post by: Yeong on November 25, 2010, 12:24:41 pm
I thought the Asm( is for raw hex assembly codes only.
Title: Re: Features Wishlist
Post by: nemo on November 25, 2010, 12:26:43 pm
ASM programs are, essentially, hex. though i just realized it won't work because it'll try to read the prgmCOMPILED as source code.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 25, 2010, 09:23:43 pm
If Asm(prgmNAME) is supported, could there be risks of conflicts?
Title: Re: Features Wishlist
Post by: calcdude84se on November 25, 2010, 09:29:32 pm
This is only in Axe source ;)
However, including compiled code is just a bad idea (pre-compiled code won't run correctly), and to include source, we already have prgmPROGRAM.
As for including BASIC programs, I'm curious why you'd need that. Could you elaborate?
Note: This post to me seems it might be bordering on offensive. I do not mean it as such.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 26, 2010, 12:47:56 am
Ah, right. I wasn't sure. As for BASIC the issue is that when executed, it could mess thing up in your program when it goes back to ASM/Axe commands, since TI-BASIC messes with TI-OS data a lot. You may not even be able to use the back buffer and buffer when certain BASIC commands are used.
Title: Re: Features Wishlist
Post by: squidgetx on November 26, 2010, 05:13:06 pm
Ok, I have a feature 'wish':

When the parser runs into certain errors, mainly the Missing Label, Undefined, and Duplicate errors, could there be an option to 'skip' that line of code when compiling? As in, if this option was chosen, the line containing the offending error would be ignored completely by the parser (as if it were prefixed by a period) Error messages would then have a menu accompanying them (sort of like BASIC) with Quit, Goto, and Skip (if applicable)

This sounds kind of hard though, and so it's ok if it's not really realistically possible, but thanks anyway :P
Title: Re: Features Wishlist
Post by: calc84maniac on November 26, 2010, 05:17:44 pm
But ignoring errors would cause a bad program to be produced. I don't think we would want that.
Title: Re: Features Wishlist
Post by: squidgetx on November 26, 2010, 05:53:57 pm
Well, I think that in many situations, the user doesn't care immediately whether a certain piece of data will be included or not. Maybe they were typing quickly while making, for example, a menu, and defined Str1 twice :P But they really just want to test whether the code works and won't care if Str1 is defined incorrectly, and so this might make some debugging a little faster (maybe)

I hope I explained it well enough x.x

Also, I have another request/question: When you use InData(), the data is zero-terminated, but it seems that the 0 is included in the data to be searched: For example, if A=0, and you ran InData(A,Data(1,2,3,0)), it would return 4...Is it supposed to be like this? I think it might be better if the 0 was not included in the data to be searched...
Title: Re: Features Wishlist
Post by: jnesselr on November 26, 2010, 05:58:32 pm
I can understand try and catch, but if they have some syntax error (maybe they have Str1 where it should be Str2) they need to know of it immediately.
Title: Re: Features Wishlist
Post by: Quigibo on November 26, 2010, 06:57:18 pm
Also, I have another request/question: When you use InData(), the data is zero-terminated, but it seems that the 0 is included in the data to be searched: For example, if A=0, and you ran InData(A,Data(1,2,3,0)), it would return 4...Is it supposed to be like this? I think it might be better if the 0 was not included in the data to be searched...

Exactly.  You generally don't want to search for the zero case.  Usually what you do is handle that separately and then when you're sure the byte is non-zero, then use the inData() search.  Although you can search for it if you don't mind it being part of your data since I don't treat zero as a special case.  The reason it's setup this way is because I'm trying to use the smallest code with the fastest speed, and this was most efficient.
Title: Re: Features Wishlist
Post by: tehalynn on November 29, 2010, 12:50:21 am
I have a couple suggestions I think would save a little time when compiling.

1. On the compile screen, sort programs by most recently compiled. The most recently compiled program is at the top.
2. Have a way to automatically run programs after they're compiled. This could be an option, or just a different key to press (instead of enter). I guess this would only work if you're compiling for no shell though.

If both of these suggestions are made, then it should only take 2 keystrokes within Axe to compile and run whichever program you compiled last.

An alternate (or additional) idea is to have a button that compiles and runs the most recently compiled program from the main screen. That would only take 1 keystroke within Axe.
Title: Re: Features Wishlist
Post by: Munchor on November 29, 2010, 08:47:36 am
I have a couple suggestions I think would save a little time when compiling.

1. On the compile screen, sort programs by most recently compiled. The most recently compiled program is at the top.
2. Have a way to automatically run programs after they're compiled. This could be an option, or just a different key to press (instead of enter). I guess this would only work if you're compiling for no shell though.

If both of these suggestions are made, then it should only take 2 keystrokes within Axe to compile and run whichever program you compiled last.

An alternate (or additional) idea is to have a button that compiles and runs the most recently compiled program from the main screen. That would only take 1 keystroke within Axe.

I like those ideas, it'd be very fast to code/compile/test repeatedly.

Also, I don't know if this would ever be possible, but Axe inside Doors? For example, I program in Doors sometimes and I have to change Application to compile :( This is a very weird thing, but maybe you could find a way of getting throught it, Quigibo.

Nevertheless, it's good to see you're hearing to our prays in this long, long topic
Title: Re: Features Wishlist
Post by: Quigibo on November 29, 2010, 04:31:27 pm
I will probably do that; have a pointer in the app that points to a special parsing routine so that external programs like DCS can automatically know where to jump into the app to "externally" use Axe without having to quit the original application.  This is something that Kerm would have to add to DCS, and I'm sure he would if you request it, but I haven't added that functionality to Axe Parser yet.  However, its definitely planned.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 29, 2010, 07:05:11 pm
I will probably do that; have a pointer in the app that points to a special parsing routine so that external programs like DCS can automatically know where to jump into the app to "externally" use Axe without having to quit the original application.  This is something that Kerm would have to add to DCS, and I'm sure he would if you request it, but I haven't added that functionality to Axe Parser yet.  However, its definitely planned.

Would it work with ASM programs? Can't wait for that :D
Title: Re: Features Wishlist
Post by: Yeong on November 29, 2010, 08:31:46 pm
Feature request:being able to sign app more than 16384 bytes.
Title: Re: Features Wishlist
Post by: calcdude84se on November 29, 2010, 08:35:22 pm
I think multi-page apps have been on the list for a while :D
They're rather difficult, so it might be a while before we have them.
Edit: We should probably get a new poll soon :P
Title: Re: Features Wishlist
Post by: Happybobjr on November 29, 2010, 09:00:22 pm
What makes multi-page apps so hard?
Title: Re: Features Wishlist
Post by: calcdude84se on November 29, 2010, 09:02:58 pm
Its not that I'm too busy (although that might be part of it).  Its mainly because the app compiling is VERY dangerous.  The only reason I understand how the code works now is mainly from BrandonW's help.  There are a lot of very tricky bcalls and formalities that TI uses when jumping around the flash pages.  Its already hard enough to allocate a single page for apps, but allocating 2 pages is really tricky because it sometimes involves swapping sectors if I remember correctly.  The point is, I could do it, but I would need a lot of help to make sure there are no rom corrupting bugs (which are really nasty).  Even if I did get it to work, it would still be data-only for the second page unless I create some kind of new syntax for off-page calls.

I do plan to make more of the code open source after the next few releases including the application compiling, error scrolling, and other potentially useful sections.  Tomorrow I will have a new update, I rewrote all of the archive reading code which took me about 4 days.  I'm not sure if there will be any new commands, but I fixed a lot of bugs, safety, optimizations, and looser syntax.
Title: Re: Features Wishlist
Post by: Happybobjr on November 29, 2010, 10:02:51 pm
...?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 29, 2010, 10:03:49 pm
...?

calcdude just posted a quote from Quigibo that answers your question ;)
Title: Re: Features Wishlist
Post by: calcdude84se on November 30, 2010, 06:16:22 pm
Here's the short version: it's dangerous and involves lots of complicated stuff ;D
Title: Re: Features Wishlist
Post by: Happybobjr on November 30, 2010, 07:00:30 pm
I had trouble understanding as i tend to read the users text before the quote. Thus my mind skipped over it...
Title: Re: Features Wishlist
Post by: tehalynn on December 01, 2010, 05:42:50 pm
Has anyone asked for automatic backup of program dependencies?

If I import prgmB into prgmA, then compiling prgmA would backup both prgmA and prgmB.
Title: Re: Features Wishlist
Post by: Deep Toaster on December 01, 2010, 06:22:53 pm
Has anyone asked for automatic backup of program dependencies?

If I import prgmB into prgmA, then compiling prgmA would backup both prgmA and prgmB.

^ Yep, I have, but IIRC Quigibo said that might get messy.

EDIT: Here:

Backing up subprograms would be a little awkward to compile.  It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume.  The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram.  But I will see if it is possible to have this as an option.  I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile.

Actually, since Axe now makes backups after the program is compiled, would this be possible?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 02, 2010, 12:23:24 am
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.
Title: Re: Features Wishlist
Post by: nemo on December 02, 2010, 04:23:00 pm
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
Title: Re: Features Wishlist
Post by: ztrumpet on December 02, 2010, 05:14:16 pm
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
I think this is a really good idea. :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 03, 2010, 12:48:30 am
It may not be convenient since sometimes you may not want to backup every single sub-programs when debugging. For now you have to backup the files manually, one by one.

maybe make it an option to back up subprograms
I think this is a really good idea. :)
Indeed. Just make sure it is not enabled by default, though, since someone may accidentally back them up and it would take ridiculous amount of times (especially if garbage collection is needed)
Title: Re: Features Wishlist
Post by: Quigibo on December 03, 2010, 01:16:58 am
But the problem is that I would need to keep a list of every program to backup while it compiles and I'm already just about out of memory without sipping into the extra pages.  It would either have to be done in the middle of compiling or there would have to be a limit to how many sub programs could be backed up during a "full backup".  I'm pretty sure I'm using the swap saferam area for parsing storage so the second option is more likely if I did decide to implement this.
Title: Re: Features Wishlist
Post by: Munchor on December 04, 2010, 05:04:22 pm
Ok, I have a doubt:

Is Application-making something you want to make in Axe? In 1.0.0, do you think that could be included?
Title: Re: Features Wishlist
Post by: Runer112 on December 04, 2010, 05:19:33 pm
You can already compile Axe programs as applications by selecting "Application" as the shell from the options menu.
Title: Re: Features Wishlist
Post by: Munchor on December 04, 2010, 05:26:49 pm
You can already compile Axe programs as applications by selecting "Application" as the shell from the options menu.

You gotta be kidding. I just found out... Oh my god! No way, this is EPIC!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 04, 2010, 09:27:19 pm
Note that on certain calcs, it may fail, though. It is very rare, but on my 83+ it doesn't work, even if it works fine on everyone else's calc. Someone else had this problem with his 84+, too. Also writing to Flash is dangerous, so always backup both your ARCHIVE and RAM on a flash drive before compiling apps when you have major updates.

Also you need to sign the app on the computer afterward.
Title: Re: Features Wishlist
Post by: AngelFish on December 05, 2010, 06:46:54 pm
I know this has been asked before, but can the variables A-Z and theta be relocated to another place in RAM so that L1 can be used as a buffer storage area?
Title: Re: Features Wishlist
Post by: Runer112 on December 05, 2010, 10:37:30 pm
Here's a sort of odd request: reverse modulus. Instead of returning the remainder of a division, it would return the original number minus the remainder. Perhaps it could use ^^ as its operator? For instance, 16^^7 would return 14 and 9001^^3 would return 9000. I've been trying to wrap my head around how to get a reverse modulus routine to work, but complex math routines aren't my specialty. But I figure the least I could do if you want to implement this feature is save you a few minutes and write the reverse modulus auto-optimizations (really just adjustments to the normal modulus auto-optimizations), which are what I would want the most anyways. I could actually do without a reverse modulus routine.

Code: [Select]
p_RMod2:
.db 2
res 0,l
p_RMod4:
.db 4
ld a,%11111100
and l
ld l,a
p_RMod8:
.db 4
ld a,%11111000
and l
ld l,a
p_RMod16:
.db 4
ld a,%11110000
and l
ld l,a
p_RMod32:
.db 4
ld a,%11100000
and l
ld l,a
p_RMod64:
.db 4
ld a,%11000000
and l
ld l,a
p_RMod128:
.db 4
ld a,%10000000
and l
ld l,a
p_RMod256:
.db 2
ld l,0
p_RMod512:
.db 4
ld l,0
res 0,h
p_RMod1024:
.db 6
ld l,0
ld a,%11111100
and h
ld h,a
p_RMod2048:
.db 6
ld l,0
ld a,%11111000
and h
ld h,a
p_RMod4096:
.db 6
ld l,0
ld a,%11110000
and h
ld h,a
p_RMod8192:
.db 6
ld l,0
ld a,%11100000
and h
ld h,a
p_RMod16384:
.db 6
ld l,0
ld a,%11000000
and h
ld h,a
p_RMod32768:
.db 6
ld l,0
ld a,%10000000
and h
ld h,a
Title: Re: Features Wishlist
Post by: nemo on December 05, 2010, 10:43:00 pm
couldn't reverse modulus be written like 16-(^7)?
Title: Re: Features Wishlist
Post by: Runer112 on December 06, 2010, 12:13:32 am
Indeed it could be. But, especially for the cases where the modulus is a multiple of 2, it would be both faster and smaller to actually have a reverse modulus function. For instance, whereas -(^16) would be 12 bytes, ^^16 would be 6 bytes. As an even more extreme example, whereas -(^2) would be 11 bytes, ^^2 would be 2 bytes.



EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
Title: Re: Features Wishlist
Post by: calc84maniac on December 06, 2010, 12:36:06 am
Couldn't you do and -16 for reverse modulus by 16? (16-bit "and" if applicable.) Bitwise and would supply exactly those optimizations you are requesting (or if not, I would certainly make those optimizations a suggestion to Quigibo)
Title: Re: Features Wishlist
Post by: Runer112 on December 06, 2010, 11:06:18 am
That would work too. It would be smaller than the -(^16) solution; every call with a modulo of 2-256 could use the 8-bit and operator and would be 6 bytes, and a modluo of 512-32768 would be 9 bytes. Reverse modulus optimizations would be, on average, about 60% the size of their and -CONST counterparts. Which I guess isn't too much, but if adding it wouldn't be too hard, why not add it and let people save a few bytes. And I think it would be especially useful for the 2-byte ^^256, which could come in handy in some situations.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 06, 2010, 01:15:11 pm
EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
;D
Title: Re: Features Wishlist
Post by: Builderboy on December 06, 2010, 01:55:45 pm
For reverse modulus 2, wouldn't #+1^2 be smaller and faster?
Title: Re: Features Wishlist
Post by: Deep Toaster on December 06, 2010, 02:23:10 pm
Hmm, how would that work? It would return only 1 or 0.
Title: Re: Features Wishlist
Post by: Builderboy on December 06, 2010, 02:24:13 pm
Oh wait never mind, lol i was reading the explanation of reverse modulus wrong.
Title: Re: Features Wishlist
Post by: LordConiupiter on December 08, 2010, 12:04:27 pm
EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.
;D
o nohs!!! I lost the game :( ;D
Title: Re: Features Wishlist
Post by: Quigibo on December 08, 2010, 03:40:41 pm
Yeah, I'm going to have to add some auto optimizations for "and" "or" and "xor" and their 16-bit counter parts. I totally forgot about those.
Title: Re: Features Wishlist
Post by: Builderboy on December 08, 2010, 07:32:01 pm
Woot ^^ nothing is nicer than uploading a new Axe version onto your calculator and watching the file sizes shrink :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 09, 2010, 12:23:08 am
Cool to hear more optimizations are being added. I will have to compile my Axe TUnnel game with 0.4.6 to see the difference. It has been a while since I last updated it. It was using 0.2.6 I think.
Title: Re: Features Wishlist
Post by: Raylin on December 21, 2010, 09:12:33 pm
Progress?
Title: Re: Features Wishlist
Post by: jnesselr on December 21, 2010, 10:21:35 pm
It still amazes me that this thread is 110 pages long.
Title: Re: Features Wishlist
Post by: Quigibo on December 21, 2010, 10:33:27 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.
Title: Re: Features Wishlist
Post by: Runer112 on December 21, 2010, 10:38:55 pm
Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.

;D
Title: Re: Features Wishlist
Post by: Deep Toaster on December 21, 2010, 10:40:47 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.

Final release :o

Somehow that sounds ominous. But it's awesome!

As a suggestion, though, how about ! being used for not(? Just my opinion, since I'm used to !If  and Else!If  now ;D
Title: Re: Features Wishlist
Post by: Happybobjr on December 21, 2010, 10:40:59 pm
Just saw you changed your progress change to 70%.  Good job.
I wonder how many non-omnimaga users use axe.  I occasionally see something on ti-calc  from a non-omnigamian.

Anyways, great work, i can't wait.

request: what are the chances of two bytes for send( ?
Title: Re: Features Wishlist
Post by: calc84maniac on December 21, 2010, 11:00:23 pm
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.

Final release :o

Somehow that sounds ominous. But it's awesome!

As a suggestion, though, how about ! being used for not(? Just my opinion, since I'm used to !If  and Else!If  now ;D
not() is bitwise complement. If you want logical not like in TI-Basic, you can just use =0.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 22, 2010, 02:57:41 am
Yeah, I've been making a lot of progress.  I fixed all the bugs that were present last version, and added a ton more auto-optimizations.  Most programs are decreasing in size by about 1% which is actually pretty significant for not having to do anything at all to your existing programs.  The new optimizations are mostly with comparisons (both signed and unsigned) and equalities.  Also, I've been working on adding some new commands.  One of which is the not() command which will finally be usable to invert the lower 8 bits and not()r will invert the full 16 bit number.   Right now, I am working on variable reallocation.  There should be a lot of new progress over the next few weeks since I'm on break.  Axe 0.4.7 will be the last of the betas and after that, the final stable release will be complete with full Axiom support.
YAY! And by variable re-allocation, do you mean moving the variables A to Z out of L1 so L1 is 768 bytes?
Title: Re: Features Wishlist
Post by: Quigibo on December 22, 2010, 03:09:03 am
@DJ, yes.  You will be able to move them where-ever you want (including as part of the program itself).  The only limitation is that this can't be decided at run-time, it has to be a constant address.

Another feature I forgot to mention that I'm working on now is getkey(X) with a variable argument.  The routine is a little large (about 20 bytes) but I can see some useful application with this for things like customized keys in games, a piano keyboard, or a trackpad by dragging your fingers along the entire key pad which is something I've done before in BASIC.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 22, 2010, 03:49:28 am
Woah we can even put them where we want? Awesome! I guess it should be useful depending of which memory area the person needs. I personally think sometimes a person may actually need both buffers plus L1 in some cases. Maybe that could open the door for a DispGraphrrr command in the future? (8 level grayscale like in Calc84maniac's chips challenge). Also I like the getkey idea. Will it slow the routine down when using it normally, though (such as Getkey(15))? I think the new one should be pretty useful, though. One thing I'm thinking about are those games allowing the user to choose controls in the options menu. Will it be possible to use them like Getkey({L1+5}), for example?
Title: Re: Features Wishlist
Post by: Quigibo on December 22, 2010, 03:59:25 am
Look-ahead parsing is used when looking at the getkey routine.  So if the number inside the parenthesis is constant like getkey(15) it converts the key code into the correct "DKey code" as it compiles.  On the other hand, if the number is not a constant, like getkey({L1+3}) then it evaluates the inside and performs the conversion at runtime using the slower routine.

By the way, between my last post and this post, I finished the routine and tested it out; it works great! :)

8-level grayscale would be awesome, but I'm skeptical how good it would look on the calculator.  Is that routine available online anywhere?  Also, the programmer would have to fill the buffer with sprites themselves since the normal sprite routines don't use that buffer.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 22, 2010, 04:28:19 am
Ah that's good. If you don't use the new routine at all, it's excluded, right?

And nice to hear the routine works! As for 8 level grayscale, you would have to ask Calc84maniac. On a 83+ it's out of the question, because the screen only allows 6 levels to be seen at once (bad contrast). Calc84maniac said it looks quite nice on a 84+. Flickery, a little bit, but pretty nice considering it's just a z80 calc.

Also is filling the buffers ourselves as fast as using the sprite routines? Someone does the former to use 24x24 sprites so he won't have to use 9 sprites nor the Bitmap routine.
Title: Re: Features Wishlist
Post by: LordConiupiter on December 22, 2010, 12:06:29 pm
Just saw you changed your progress change to 70%.  Good job.
I wonder how many non-omnimaga users use axe.  I occasionally see something on ti-calc  from a non-omnigamian.

Anyways, great work, i can't wait.

request: what are the chances of two bytes for send( ?
somewhere near zero: look at this post (http://ourl.ca/4057/110229)

I really am looking forward to the next release! good luck!
Title: Re: Features Wishlist
Post by: Munchor on December 22, 2010, 12:07:32 pm
I really am seeing forward to the next release! good luck!

I am looking forward to absorving OS's variables :)
Title: Re: Features Wishlist
Post by: LordConiupiter on December 22, 2010, 12:10:43 pm
Me too! but there are so many other things I am looking forward to, I can't mention everything in just one post :P
Title: Re: Features Wishlist
Post by: Munchor on December 22, 2010, 12:11:40 pm
Me too! but there are so many other things I am looking forward to, I can't mention averything in just one post :P

Yes, I just checked the Features Wishlist and other topics better, because I only knew about that update.

Wow! Axe (0.5?) will be really cool!
Title: Re: Features Wishlist
Post by: LordConiupiter on December 22, 2010, 12:14:46 pm
Me too! but there are so many other things I am looking forward to, I can't mention averything in just one post :P

Yes, I just checked the Features Wishlist and other topics better, because I only knew about that update.

Wow! Axe (0.5?) will be really cool!

Axe 0.5 won't ever exist, because after 0.4.7 the next release will be v1.0.0 (like Quigibo said here (http://ourl.ca/4057/156101))
Title: Re: Features Wishlist
Post by: AngelFish on December 22, 2010, 12:16:23 pm
And after Axe 1.0.0 is Axe 9001.0.0, which will include 2 byte color support, 3d graphics, and actual math  :w00t:
/me wishes...
Title: Re: Features Wishlist
Post by: Fast Crash on December 22, 2010, 12:17:08 pm
why not :P
It will be on casio prizm :)
Title: Re: Features Wishlist
Post by: Munchor on December 22, 2010, 12:17:20 pm
Me too! but there are so many other things I am looking forward to, I can't mention averything in just one post :P

Yes, I just checked the Features Wishlist and other topics better, because I only knew about that update.

Wow! Axe (0.5?) will be really cool!

Axe 0.5 won't ever exist, because after 0.4.7 the next release will be v1.0.0 (like Quigibo said here (http://ourl.ca/4057/156101))

:O Nice, then!
Title: Re: Features Wishlist
Post by: Deep Toaster on December 22, 2010, 12:19:34 pm
Wow, lots of (really useful) updates in just a day. not(, reallocation...
/me waits and starts auto-poking Quigibo every five seconds

And after Axe 1.0.0 is Axe 9001.0.0, which will include 2 byte color support, 3d graphics, and actual math  :w00t:
/me wishes...

And objects, or course ;)
Title: Re: Features Wishlist
Post by: LordConiupiter on December 22, 2010, 12:21:52 pm
yeah!!! objects!!
that is going to be implemented for Axe++ I thougt, right?
Title: Re: Features Wishlist
Post by: Happybobjr on December 22, 2010, 06:19:22 pm
Feature Request:  Double buffer.
Code: DisplayGraphrrr
description.  It will display both buffers but as black not as black and gray.
Title: Re: Features Wishlist
Post by: Deep Toaster on December 22, 2010, 06:20:48 pm
Feature Request:  Double buffer.
Code: DisplayGraph rrr
description.  It will display both buffers but as black not as black and gray.

What do you mean? Like DispGraphr, but displaying black instead of gray for a 1 on the back-buffer? That'd be nice and probably pretty small (just OR the two buffers).
Title: Re: Features Wishlist
Post by: Happybobjr on December 22, 2010, 07:01:52 pm
yep that is what i mean.

It would make it nice, in black and white games, to have collision checking between two things this way.  It would have some major speed increases.
Title: Re: Features Wishlist
Post by: Deep Toaster on December 22, 2010, 07:05:11 pm
yep that is what i mean.

It would make it nice, in black and white games, to have collision checking between two things this way.  It would have some major speed increases.

And it'd be nice for two-layer maps :o

Three rs might get weird, though. But it shouldn't be a problem since most programs should only use it once in the entire code.
Title: Re: Features Wishlist
Post by: Runer112 on December 22, 2010, 07:14:22 pm
Feature Request:  Double buffer.
Code: DisplayGraphrrr
description.  It will display both buffers but as black not as black and gray.

What kind of uses would this feature have? I can picture what it would do, but I can't seem to picture how it would be used in a program. Can someone give me some examples?
Title: Re: Features Wishlist
Post by: Deep Toaster on December 22, 2010, 07:16:38 pm
Like looking down on a two-layered map: one on the ground and one somewhere in the air. That way, you can change one of the layers without having to change the other.
Title: Re: Features Wishlist
Post by: Happybobjr on December 22, 2010, 07:34:24 pm
or to do collision checking with sprites and the backround.
Title: Re: Features Wishlist
Post by: Quigibo on December 22, 2010, 10:19:22 pm
I'm rewriting the line drawing routine.  So far, its about the same size as the original, except its at least twice as fast and can be drawn to ANY buffer.
Title: Re: Features Wishlist
Post by: Runer112 on December 22, 2010, 10:21:48 pm
Awesome! While you're at it, any chance for white/inverted lines? I wouldn't mind if it requires a whole new routine for each, it would be worth it.
Title: Re: Features Wishlist
Post by: Quigibo on December 22, 2010, 10:56:09 pm
Maybe, but I would need a new token to change.
Title: Re: Features Wishlist
Post by: Deep Toaster on December 23, 2010, 12:21:38 am
Awesome! While you're at it, any chance for white/inverted lines? I wouldn't mind if it requires a whole new routine for each, it would be worth it.
/me seconds this

Maybe with Line(X1,Y1,X2,Y2,0) like in BASIC? Or would it be too confusing for Axe to parse one token two different ways?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 23, 2010, 01:16:46 am
Feature Request:  Double buffer.
Code: DisplayGraphrrr
description.  It will display both buffers but as black not as black and gray.



What kind of uses would this feature have? I can picture what it would do, but I can't seem to picture how it would be used in a program. Can someone give me some examples?
I thought DispGraphrrr could be more for 8 level grayscale? ??? (L1, L3 and L6)

I'm rewriting the line drawing routine.  So far, its about the same size as the original, except its at least twice as fast and can be drawn to ANY buffer.
Will it run even faster when lines are horizontal/vertical?
Title: Re: Features Wishlist
Post by: Builderboy on December 23, 2010, 01:23:34 am
Hmmmm i wonder if there would be enough speed for 8 level greyscale in an Axe game o.O if i remember correctly calc84 had to do some crazy optimizing to get 8 greyscale to work.  Nevertheless i think 8 greyscale would be more useful than Or'ing the two buffers onto the screen
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 23, 2010, 01:37:34 am
It would be for 15 MHz-only games that's for sure. The 83+ can't even display all 8 levels at once anyway. The contrast is so sparse that at one contrast level, two shades of gray are white and if you increase your contrast by 1, the two darkest shades before black becomes black too.
Title: Re: Features Wishlist
Post by: AngelFish on December 23, 2010, 02:28:48 am

And objects, or course ;)

Hopefully not. I don't like OOP.
Title: Re: Features Wishlist
Post by: Quigibo on December 23, 2010, 04:22:27 pm
New feature added:

DispGraphClrDraw

When used on the same line without a colon or newline in-between, it will function exactly as if you had done DispGraph:ClrDraw but it does them both simultaneously so its just as fast as if you had used the DispGraph by itself.  Its great to squeeze more frame rate out of games where you have to clear the screen after drawing each frame like for instance; ray-casters.  But I'm sure this can be used in may games.  Keep in mind this does add an extra routine to your code so I would still use the regular DispGraph unless you can use the new command exclusively or if you really need more speed.
Title: Re: Features Wishlist
Post by: jnesselr on December 23, 2010, 04:30:57 pm
so, it displays the graph, and then clears the buffer, or clears the screen then displays the buffer?  I think it displays the graph and clears the buffer, though. I just got myself confused.

Also, is there a list of what you still need to add before 1.0 comes out?
Title: Re: Features Wishlist
Post by: Munchor on December 23, 2010, 04:34:32 pm
New feature added:

DispGraphClrDraw

When used on the same line without a colon or newline in-between, it will function exactly as if you had done DispGraph:ClrDraw but it does them both simultaneously so its just as fast as if you had used the DispGraph by itself.  Its great to squeeze more frame rate out of games where you have to clear the screen after drawing each frame like for instance; ray-casters.  But I'm sure this can be used in may games.  Keep in mind this does add an extra routine to your code so I would still use the regular DispGraph unless you can use the new command exclusively or if you really need more speed.

That sounds like a fun command :)
Title: Re: Features Wishlist
Post by: jnesselr on December 23, 2010, 04:35:42 pm

And objects, or course ;)

Hopefully not. I don't like OOP.
I actually love OOP, but it's not for Axe. Maybe another language altogether.
Title: Re: Features Wishlist
Post by: Munchor on December 23, 2010, 04:37:17 pm

And objects, or course ;)

Hopefully not. I don't like OOP.
I actually love OOP, but it's not for Axe. Maybe another language altogether.

There are languages that can be OOP, but not fully OOP, like Python.
Title: Re: Features Wishlist
Post by: Happybobjr on December 23, 2010, 04:41:20 pm
New feature added:

DispGraphClrDraw

When used on the same line without a colon or newline in-between, it will function exactly as if you had done DispGraph:ClrDraw but it does them both simultaneously so its just as fast as if you had used the DispGraph by itself.  Its great to squeeze more frame rate out of games where you have to clear the screen after drawing each frame like for instance; ray-casters.  But I'm sure this can be used in may games.  Keep in mind this does add an extra routine to your code so I would still use the regular DispGraph unless you can use the new command exclusively or if you really need more speed.

love it, that will be great.
Title: Re: Features Wishlist
Post by: Munchor on December 23, 2010, 04:42:11 pm
It's OK, I don't see the point of it that much... Is it thatfaster?
Title: Re: Features Wishlist
Post by: Deep Toaster on December 23, 2010, 04:44:02 pm
According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Seems like a useful command :D I was just about to ask for DispGraphrClrDraw/DispGraphrrClrDraw, but then I realized how pointless it'd be (there'd be no grayscale anyway if you're clearing it every pass).
Title: Re: Features Wishlist
Post by: Munchor on December 23, 2010, 04:45:03 pm
According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Oh I see. Nice then, I refer to: "you're saving all the time it takes to clear the graph buffer.".
Title: Re: Features Wishlist
Post by: Happybobjr on December 23, 2010, 06:21:43 pm
According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Seems like a useful command :D I was just about to ask for DispGraphrClrDraw/DispGraphrrClrDraw, but then I realized how pointless it'd be (there'd be no grayscale anyway if you're clearing it every pass).

why wouldn't there be?
Title: Re: Features Wishlist
Post by: Compynerd255 on December 24, 2010, 12:48:18 am

And objects, or course ;)

Hopefully not. I don't like OOP.
I actually love OOP, but it's not for Axe. Maybe another language altogether.

There are languages that can be OOP, but not fully OOP, like Python.

Not to break the DispGraph:ClrDraw feature discussion all of a sudden. I think it does sound cool.

You know, you could actually do something like OOP very easily in something like Axe. Since I am a C# programmer, I think in objects a lot, and find myself using idioms for multidimensional arrays ({I*3+2+L1} or whatnot) to reference objects. This is my idea of how it could be implemented:

- Somewhere in your code (such as in a library) you write this:
 Class(NME
 Var(X,2)
 Var(Y,2)
 Var(S,8)
 End
This creates a class called NME with a 2-byte X, a 2-byte Y, and an 8-byte S

- Then, somewhere else in your code, you write this:
 Instance(NME, JOE, L1
This will tell Axe that you want an instance of NME named JOE at L1

- Then you can do things with the object:
"JOE(X)" returns the value of JOE's X
"3->JOE(X)" stores the value into JOE's X
"Pt-On(JOE(X),JOE(Y),JOE(S)<degree symbol>)" will draw JOE to the screen.

- You might even want subroutines inside the object itself that omit the JOE( part, so you can simply call JOE's version of the subroutine to have JOE preform operations on himself.

But you can do what you want. I just think that OOP would be really cool.
Title: Re: Features Wishlist
Post by: Quigibo on December 24, 2010, 04:34:57 am
As much as I would like to do OOP, there just simply aren't enough resources on the calculator to handle all the overhead that would take in the parser.

I finally moved the default location of the variables to the end of L1 instead of the beginning and I'm in the process of writing the #Realloc() routine to move them anywhere else.  I decided to make all the compiler instructions have the '#' prefix so they don't get confused with actual commands.  So far, the only other token that has changed is "#Axiom()" but "#Icon()" will be coming soon and I'm pretty sure you can guess what that does :)

Another thing I noticed that I can't believe I didn't see before was to move the random seed away from the variables and into the hidden buffer (the one I'm using for r1-r6, files and other smaller things).  This expands the usable memory in L1 by 2 extra bytes!  It was actually kind of a necessity rather than a choice though because the Rand routine uses a fixed location to get the seed.  If the variables included the seed and then got reallocated, the Rand routine would no longer be looking at the correct location so you could get glitches if you tried to use all of L1 for something.  So it was a win-win to move it.
Title: Re: Features Wishlist
Post by: shmibs on December 24, 2010, 04:47:01 am
YAY FOR CUSTOM ICONS!

oh, and does this mean that variables can be moved, if one chooses, to one of the smaller L's, meaning the L1 area can be used as another buffer?
Title: Re: Features Wishlist
Post by: Quigibo on December 24, 2010, 04:54:25 am
That's exactly the intention.  :)

In fact, you don't need them to be in any of the L1-L6 buffers at all if you're compiling for a shell/noshell.  You can store them directly in your program:

Code: [Select]
:Zeros(54)->Str1V
:#Realloc(Str1V)
Title: Re: Features Wishlist
Post by: squidgetx on December 24, 2010, 08:13:32 am
Damn, all these improvements are sounding really nice. I can see potential uses for all that stuff.

By the way, where's the "hidden buffer"? I want to make sure that while I'm hunting down potential freeram areas that aren't in L1-L6 (like in $8000) that I won't accidentally use that area too XD
Title: Re: Features Wishlist
Post by: Runer112 on December 24, 2010, 04:06:15 pm
The "hidden buffer" is MD5Buffer, a 64-byte section of RAM starting at $83A5. I wonder what immediately follows it in RAM, because if there were only a few more byte of safe to use RAM, you could move all the variables there.
Title: Re: Features Wishlist
Post by: Quigibo on December 24, 2010, 04:10:09 pm
Not really, I'm already using 6*2 = 12 for the r1-r6 variables, 10*3 = 30 for the Y0-Y9 files, 2 for the random seed, and 8 for the sprite buffer. That totals 52 bytes so I really only have 12 bytes left

Edit: Also, I added >Hex finally :)
Title: Re: Features Wishlist
Post by: Runer112 on December 24, 2010, 04:14:21 pm
Oh wow, didn't realize all that other stuff was there too. Nevermind then!

And thanks for adding ►Hex, that should make debugging easier. By the way, can we also use ►Hex outside of text display commands? Perhaps have the hex string be generated to a 5-byte section of MD5Buffer and return a pointer to it? Because then it could also double as a useful and quick hex generator that we can just copy the data out of.
Title: Re: Features Wishlist
Post by: Quigibo on December 25, 2010, 12:10:25 am
Runner, that would make the routines a lot larger and I don't think it would be as used often enough to justify the extra size.

I optimized the 3 level grayscale routine more.  Its 5 bytes smaller and the inner loop is 20 T-states faster.  The inner loop iterates 768 times per frame at 6MHz which results in the overall routine being 2.5 milliseconds faster per frame.  That's about a 4% speedup for a game running at 15fps.  The grayscale is smoother too.

The only thing I'm worried about is that there's only 57 T-states between LCD driver commands at one point (which is not including the 11 T-states of the "out" instruction).  The z80 in 28 days tutorial recommends 60, but the routine works on my 84+ which has the bad LCD.  Anyone willing to test this on hardware?  I attached an example that uses the routine.

Title: Re: Features Wishlist
Post by: Raylin on December 25, 2010, 12:47:31 am
I shall test ASAP.

Dang. Never mind.
Ubuntu says no.
Title: Re: Features Wishlist
Post by: Runer112 on December 25, 2010, 01:27:45 am
Runner, that would make the routines a lot larger and I don't think it would be as used often enough to justify the extra size.

I don't know how small you managed to make the current routine, but mow much larger could this make it? The following routine I whipped up would take input in hl, convert into a null-terminated string of hexadecimal characters starting at vx_Hex, and return a pointer to that string. It's only 29 bytes. To display a string you would just call this and then treat the result like any normal string. But you now have the extra advantage of being able to access the generated hex characters.

Code: [Select]
p_ConvHex:
ex de,hl
ld hl,vx_Hex+4
xor a
ld (hl),a
call __ConvHexByte
ld e,d
__ConvHexByte:
ld a,e
call __ConvHexNib
ld a,e
rra
rra
rra
rra
__ConvHexNib:
or $F0
daa
add a,$A0
adc a,$40
dec hl
ld (hl),a
ret
Title: Re: Features Wishlist
Post by: Builderboy on December 25, 2010, 02:22:35 am
Those new features sound excellent :D and speaking of, i have a new request.  The If A=# changing into !If A-# is such a great optimization (6 bytes and a speed increase).  Maybe it would be worthwhile into looking into auto optimizing that?  I know its got to be used a lot in programs, i went through PortalX and found so many places where it could be optimized, possibly hundreds of bytes saved, and im sure other programs could benefit too :)
Title: Re: Features Wishlist
Post by: Runer112 on December 25, 2010, 03:03:52 am
That's a nice idea Builderboy, but unfortunately users have to choose to optimize their own code in cases like this. This is because, although If A=B and !If A-B would form identical control structures, they would not return the same values. And the programmer may want to use the value returned. For instance, the following code would no longer work as the programmer planned if this auto-optimization existed:

Code: [Select]
If A=5
  →B
  .Do stuff
Else
  .Do stuff
End
Title: Re: Features Wishlist
Post by: Builderboy on December 25, 2010, 03:23:12 am
ah i see what you mean, i guess its just a matter of having to optimize it ourselves then, which works too :)
Title: Re: Features Wishlist
Post by: Quigibo on December 25, 2010, 03:29:59 am
Runner, the one I made is much smaller than the one from WikiTI:

Code: ("ASM") [Select]
p_DispHex:
ld b,4
__DispHexLoop:
xor a
add hl,hl
rla
add hl,hl
rla
add hl,hl
rla
add hl,hl
rla
add a,$90
daa
adc a,$40
daa
B_CALL(_PutC)
djnz __DispHexLoop
ret

It would be about 8 bytes larger to save it to a buffer.  The syntax wouldn't really work well though because axe would throw a fit if you tried to do Disp A►Hex->B for instance since the display routine looks for commas.  You would have to do some hackish code by putting the store on the line after it or using the address of the buffer directly.  But I guess if this is a conversion command rather than a display command this could be allowed... and then I would only need one routine for both display and text.  That might actually work.   I will have to see if I can make that more consistent with the other display format commands because that does sound convenient.

Builderboy.  I really want to but I'm afraid it will break too much compatibility with current Axe programs.  For instance:

Code: ("Axe") [Select]
:A+1->A
:If A=10
:->A
:End

This code increments A and if it goes above 10 rests it back to 1.  Here you are using the fact that the result of the if expression is a one if it ends up going inside the block.  It would be impossible for me to tell if the next expression is going to use the result of the if expression or not.

NINJA'D!
Title: Re: Features Wishlist
Post by: Runer112 on December 25, 2010, 04:04:47 am
Yeah, I think it would be nice to make it secretly be a conversion command, not an actual display command. Although it makes the routine slightly larger, I think it would definitely be worth it.

And by the way, optimization of your code ;)

Code: [Select]
p_DispHex:
ld b,4
__DispHexLoop:
ld a,$1F
__DispHexShiftLoop:
add hl,hl
rla
jr nc,__DispHexShiftLoop
daa
add a,$A0
adc a,$40
B_CALL(_PutC)
djnz __DispHexLoop
ret

And here's what your code modified into a hex conversion routine might look like:

Code: [Select]
p_ConvHex:
ld de,vx_Hex
push de
ld b,4
__ConvHexLoop:
ld a,$1F
__ConvHexShiftLoop:
add hl,hl
rla
jr nc,__ConvHexShiftLoop
daa
add a,$A0
adc a,$40
ld (de),a
inc de
djnz __ConvHexLoop
xor a
ld (de),a
pop hl
ret
Title: Re: Features Wishlist
Post by: Quigibo on December 25, 2010, 06:20:39 am
Thanks Runer!  Its actually kind of freaky how nearly identical it was to my modifications O.O  But I didn't catch that one with the daa since I'm still not entirely sure how that instruction works.

I should be on schedule for an update tomorrow night.  ;D
Title: Re: Features Wishlist
Post by: LordConiupiter on December 25, 2010, 07:22:03 am
Nice! I can't wait, because I already have plenty of ideas how to re-create my constest entry, but I want to do it in Axe 1.0.0 ;)

*LC wishes he could understand all those ASM code snippets, and decides to look for a clear tut somewhere*
Title: Re: Features Wishlist
Post by: jnesselr on December 25, 2010, 10:13:05 pm
Actually, I just thought how awesome it would be if Axe supported usb. Even if it was an axiom or something. But, it's such a pain, that I wouldn't ask for it, but would rather do it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 26, 2010, 02:57:15 am
Awesome updates QUigibo!
Title: Re: Features Wishlist
Post by: Munchor on December 26, 2010, 10:26:00 am
I had an idea:

Code: [Select]
Disp "Hello"
. THIS IS A COMMENT
Disp "This is not a com."
. THIS IS A NEW COMMENT

What if we could have

Code: [Select]
...
This is a comment
This is also a comment
This is the third line of the comment
And this is the last line of a multi-line comment
...
Disp "This is not a com."

Multi-Line comments would be very useful for me, and I hope other people too, because I sometimes want to keep 10 lines of code in a program, but hide it for debugging. I have to put a '.' before all lines and that's very tiring on-calc.

Probably someone already suggested this feature, but this thread is 114 pages long :S
Title: Re: Features Wishlist
Post by: calcdude84se on December 26, 2010, 04:47:56 pm
I haven't seen requests for multi-line comments yet, actually.
That doesn't seem like it would be too difficult to implement, either.
Title: Re: Features Wishlist
Post by: jnesselr on December 26, 2010, 04:48:04 pm
Instead of ..., why not have it have an opening and closing comment character. That way, you don't get confused too.
Title: Re: Features Wishlist
Post by: nemo on December 26, 2010, 04:49:06 pm
/.
comment
./

how about that?

edit: nevermind that's not really accessible on calc..
Title: Re: Features Wishlist
Post by: Munchor on December 26, 2010, 04:49:21 pm
Instead of ..., why not have it have an opening and closing comment character. That way, you don't get confused too.

Yes, '...' was just an idea.

What about

'./


/.'
Title: Re: Features Wishlist
Post by: Deep Toaster on December 26, 2010, 04:50:32 pm
/.
comment
./

how about that?

edit: nevermind that's not really accessible on calc..

That might get complicated for Axe, since / is already used for something. . already means a comment anyway, so I support the ... suggestion. Multi-line comments would be nice :)

EDIT: Just read what graphmastur said. How about .< to open and .> to close, then?
Title: Re: Features Wishlist
Post by: Munchor on December 26, 2010, 05:12:18 pm
.< and .> would be cool.

I'm glad I did some Axe today, otherwise I wouldn't have reminded of this possible new feature ;)
Title: Re: Features Wishlist
Post by: jnesselr on December 26, 2010, 05:50:17 pm
Hey, the poll up above is 40 vs. 2. I think that's decided. Now, for the next poll:

Which Should Quigibo add next:
1) USB Support
2) OS Support (YES)
3) Computer-compiler
4) All of the above.

Actually, I wish we could program an os in Axe.
Title: Re: Features Wishlist
Post by: Builderboy on December 26, 2010, 06:25:55 pm
Um, i think every single one of those is incredibly difficult to do.  USB support isn't well understood, and has very very complicated linking that might bloat code and i dont even know how fast it would be.  OS support, IMHO should not be something Axe is ever allowed to do, because of the new potential for every Axe user to brick their calc.  Not to mention you need complete control over the calculator in order to write an OS, which would require a whole host of new commands to write to flash and swap pages and the like, and it would be a whole project in its own.  Computer compiler has already been discussed an has been worked on by Quigibo, and he stated that it will not be addressed until after 1.0.0 comes out.

I don't want to sound like i am saying those are all bad ideas, i just think that ideas such as those should be completely up to Quigibo, and not to make him feel like he has to enable Axe to write OS's or support advanced features.
Title: Re: Features Wishlist
Post by: Raylin on December 26, 2010, 06:26:34 pm
That would be silly.
How are you going to store two OSes on one calc without custom file formats and a computer and such?

Unless Quigibo was RIDICULOUSLY RIDICULOUS and made an OS emulator inside of another version of Axe.
Or made a VirtualBox application for the calculator.
Title: Re: Features Wishlist
Post by: Runer112 on December 26, 2010, 06:28:19 pm
graphmastur, I think your expectations of Quigibo and Axe are just a little high... Even the most knowledgeable assembly programmers steer clear of the USB port because very few people know how to use it. I think it's a little too much to ask Quigibo to write arbitrary USB protocols for a system that hardly anyone has even been able to hack together any USB functionality. And the same goes for coding operating systems. The first person to design a programming language that allows users to easily write full operating systems deserves a Nobel prize (or whatever the equivalent is for computer science). Anyways, Axe was built to be a programming language to write programs for the TI operating system. It is in many ways inseparable from the TI operating system, and would instantly fail without it.

The computer compiler, on the other hand, Quigibo already plans to work on. That's what Axe 2.0 will be.

EDIT: Damn it, double ninja'd.
Title: Re: Features Wishlist
Post by: jnesselr on December 26, 2010, 06:29:27 pm
lol, you wouldn't store two OSes.  I was kidding when I said that whole thing, but yeah, it would be ridiculous. I would never expect anyone to seriously port axe to an OS.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 27, 2010, 03:07:13 pm
If by OS you mean porting Axe to another OS, I think Sir or someone else was planning to port 1.0 to KOS when it comes out, but do not expect that to happen in short terms.

As for USB, the doc about it is limited. SirCmpwn asked TI for it a few times and TI didn't want to give it to him.
Title: Re: Features Wishlist
Post by: jnesselr on December 27, 2010, 03:37:02 pm
No, TI will never give that out. I know brandonw said that they wouldn't too. If I can even get bulk to send, I'm sure we can experiment with other ports to possibly get tons of information about it, but there are some things that we might never know.
Title: Re: Features Wishlist
Post by: LordConiupiter on December 27, 2010, 04:25:26 pm
.< and .> would be cool.

I'm glad I did some Axe today, otherwise I wouldn't have reminded of this possible new feature ;)
Good idea! It would be very sufficient indeed to have multi line comments.  :w00t:


ow! how stupid am I today! perhaps I'm working too much for the contest, and sleeping too little :(

could you also add port reading in the future? I do not mean the I/O port etc, but ports like these: All ports by Address (http://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address)

EDIT:
another feature for the next Axe version after 1.0.0:
the Function command, for labels to be used as commands like subs. I'll explain what I mean with an example:
normally, when you want to use a subroutine, you do:
Code: (Axe) [Select]
sub(SUB,1,2,"HELLOL"
Return

Lbl SUB
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
but the idea of Function is that this could be done:
Code: (Axe++) [Select]
Text(1,2,"HELLOL")r
Return

Function Text(3)r
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
this is some kind of Axiom thing, but than in Axe itself, right?
could this be added in Axe++?
this feature request has been somehow forgotten, but my wish hasn't changed...
I would really like to see implemented this. Here is a better description of what I tried to say in the above quoted post: access to serveral ports/pins of the processor, so anyeone can write his/her own routine for for example USB linking.
Title: Re: Features Wishlist
Post by: jnesselr on December 27, 2010, 04:42:02 pm
Here is a better description of what I tried to say in the above quoted post: access to serveral ports/pins of the processor, so anyeone can write his/her own routine for for example USB linking.
True, but due to how fast this has to be done, I would think it would be better to have an Axiom or library for this.
Title: Re: Features Wishlist
Post by: Michael_Lee on December 28, 2010, 12:07:26 pm
This has probably been already asked before, but how about a 'break' function?

Also, it would be nice if I could do something like 'BreakIf A' similar to the already existing 'ReturnIf A'
Title: Re: Features Wishlist
Post by: SirCmpwn on December 28, 2010, 01:41:36 pm
Ooo, I like that suggestion.  Continue would be nice as well.
Title: Re: Features Wishlist
Post by: Munchor on December 28, 2010, 01:48:33 pm
Continue() and Break() would be nice (maybe without the parens)
Title: Re: Features Wishlist
Post by: Quigibo on December 28, 2010, 10:25:46 pm
Back from my trip!

Multi-line comments is a good idea, I must have forgotten about it.  I like the original idea of "..." as the start and end since that reminds me of how python does it and you don't have to go into any menus to get the tokens so its easier to type.

Break and Continue are still maybes mostly because I would have to create new tokens for them and they wouldn't be in convenient places next to the other program flow commands.  I'm mostly going to be working on the Axiom support for the next few days since I feel that's most important (After that, anyone can add whatever command you want to the language)
Title: Re: Features Wishlist
Post by: Deep Toaster on December 28, 2010, 11:06:16 pm
This has probably been already asked before, but how about a 'break' function?

Also, it would be nice if I could do something like 'BreakIf A' similar to the already existing 'ReturnIf A'

That and Continue would be nice.

And this is a request that has been posted before: Goto LBLIf CONDITION syntax (which could save us a few bytes :D).
Title: Re: Features Wishlist
Post by: Michael_Lee on December 28, 2010, 11:47:48 pm
@Quigbo -- Perhaps you could use the 'OpenLib' and 'ExecLib' as tokens?

@Everybody else -- I've heard of the 'continue' from my brief forays into Python, but I'm not entirely certain what that could be used for.  Explanation please?
Title: Re: Features Wishlist
Post by: FinaleTI on December 29, 2010, 12:08:26 pm
But OpenLib and ExecLib are 84+ only tokens....
Title: Re: Features Wishlist
Post by: SirCmpwn on December 29, 2010, 01:01:55 pm
Continue skips the rest of the loop and starts another iteration.
Title: Re: Features Wishlist
Post by: Builderboy on December 29, 2010, 01:24:26 pm
That would be pretty easy to implement methinks, its just a jump to the start of the loop again.
Title: Re: Features Wishlist
Post by: Quigibo on December 29, 2010, 02:18:03 pm
For the goto-if and goto-!if I think I will auto-optimize the existing commands instead of creating entirely new syntax.  It would actually be easier I think to read and write and no one would have to change their syntax.  Same thing with sub().
Title: Re: Features Wishlist
Post by: ztrumpet on December 29, 2010, 02:33:58 pm
Multi-Line comments...
Probably someone already suggested this feature, but this thread is 114 pages long :S
I haven't seen requests for multi-line comments yet, actually.
Hmm...
Quoted from page 1 of the Axe Parser topic:
Comments!!!  Yay!  That's great.  Can you have comment blocks?  (Like ' ' to ' ' mabey?)
So, yeah, this has been requested before, in Axe 0.0.1 (when ' was a comment). :P  I'm glad that we can finally have them. :)
Title: Re: Features Wishlist
Post by: Builderboy on December 31, 2010, 01:54:09 am
Lol way back when Axe was a baby ^^ And those auto optimizations sound actually pretty neat :D
Title: Re: Features Wishlist
Post by: Deep Toaster on December 31, 2010, 10:38:59 am
For the goto-if and goto-!if I think I will auto-optimize the existing commands instead of creating entirely new syntax.  It would actually be easier I think to read and write and no one would have to change their syntax.  Same thing with sub().

So
Code: (Axe) [Select]
:If CONDITION
:Goto LBL
:End
will get optimized? That would work, and some programs would suddenly drop in size, too :D Could Axe do the same with Return?
Title: Re: Features Wishlist
Post by: Quigibo on December 31, 2010, 05:19:50 pm
Return already has a ReturnIf and Return!If version.  But I guess I could still optimize it anyway in case someone forgets.
Title: Re: Features Wishlist
Post by: Runer112 on December 31, 2010, 05:20:38 pm
Speaking of optimizing control structures, any chance for Do...While loops?
Title: Re: Features Wishlist
Post by: Munchor on December 31, 2010, 05:22:09 pm
Speaking of optimizing control structures, any chance for Do...While loops?

I'd like Switch cases more than Do...While loops, but I don't really know how the second works.
Title: Re: Features Wishlist
Post by: nemo on December 31, 2010, 05:28:04 pm
Speaking of optimizing control structures, any chance for Do...While loops?

isn't a Do While loop equivalent to a Repeat loop? except that repeat is until the condition is true rather than while it's true..
Title: Re: Features Wishlist
Post by: Runer112 on December 31, 2010, 05:34:04 pm
Speaking of optimizing control structures, any chance for Do...While loops?

I'd like Switch cases more than Do...While loops, but I don't really know how the second works.


Do...While loops are a lot like While...End loops, except that the check to advance to another iteration of the loop is at the end instead of the beginning. This turns out to be more optimized. Whereas a While...End loop has two jumps, one to exit the loop if the condition is false and one to jump back to the beginning, a Do...While combines the two into one jump that jumps back to the beginning if the condition is true.

I don't know how good that explanation was, but perhaps this pseudocode will help clarify it. Numbers in brackets indicate the number of bytes the real code takes:

While...End loop                                                                          Do...While loop                                                                              
Code: [Select]
;While
[x] Loop condition
[2] Check if loop condition is true or false
[3] Exit the loop if false

;Loop contents

;End
[3] Jump back to the beginning of the loop


       
Code: [Select]
;Do
;[0] Start of the loop, takes no actual code



;Loop contents

;While
[x] Loop condition
[2] Check if loop condition is true or false
[3] Jump back to the beginning of the loop if true
Title: Re: Features Wishlist
Post by: Builderboy on January 04, 2011, 01:49:53 am
I've been thinking about this, and how much slower would clipped lines be?
Title: Re: Features Wishlist
Post by: Quigibo on January 04, 2011, 02:11:10 am
@Runner, I was thinking of having "While 1" and "Repeat 0" to auto optimize to no code at all so that would take care of the Do part.  The end condition might work if I add new "EndIf" and "End!If" instructions (which only work on while/repeat loops).  It would be pretty cool too because it would mean you can have pre-check and post-check for the same loop!  Something I haven't seen yet in other languages...

@Builderboy: Very difficult.  The new algorithm has no knowledge of X and Y while drawing the line so it doesn't know when its going off-screen.  If I let it keep drawing, it continues writing to more of the screen ram causing a loop around effect and a possible crash if it goes too far off screen past the end of the L6 buffer.  Likely the next version will just draw nothing if you go off-screen as that would give a size and speed optimization and is more likely what you would want in that case.
Title: Re: Features Wishlist
Post by: Builderboy on January 04, 2011, 02:13:01 am
Ah gotcha, now i need to go about trying to figure out how to write a clipped line routine...
Title: Re: Features Wishlist
Post by: Quigibo on January 04, 2011, 02:24:58 am
You can try this (http://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland).  They even have pseudo code :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 04, 2011, 02:27:56 am
Could there be a 2nd line routine for those who absolutely want clipped ones? Or maybe someone could write an Axiom.
Title: Re: Features Wishlist
Post by: AngelFish on January 07, 2011, 02:22:55 pm
This might have been asked before, but it would be nice to be able to put code inline. That way, if you're only executing the routines once, you can save the 15 byte call.
Title: Re: Features Wishlist
Post by: Runer112 on January 07, 2011, 11:47:05 pm
Could buffer operations be extended to support buffer arguments? I don't think I urgently need it, but I'm sure others would like it. And since all the commands already exist, it would be best not to have to make whole new copies of all the commands with Axioms. Most of the current routines would handle it with no problem. I guess the question is how hard/time-consuming it would be for you to implement it? Variable buffers would play nice with all of the following commands.




EDIT: Completely unrelated, but how did you come up with 1900 and 4700 cycles as arguments to pause for approximately one second? I calculated more like 1800 and 4500 for 6.0MHz and 15.0MHz, or about 1850 and 4600 for 6.15MHz and 15.4MHz (which is about how fast my TI-84+SE runs I believe).
Title: Re: Features Wishlist
Post by: Deep Toaster on January 08, 2011, 12:36:41 am
This might have been asked before, but it would be nice to be able to put code inline. That way, if you're only executing the routines once, you can save the 15 byte call.

What do you mean? Axe 0.4.5 and above support stuff like GetCalc("prgmNAME").
Title: Re: Features Wishlist
Post by: Happybobjr on January 08, 2011, 01:28:57 pm
6.15MHz and 15.4MHz (which is about how fast my TI-84+SE runs I believe).

Is this why my screen is extremely glitchy?
Title: Re: Features Wishlist
Post by: Quigibo on January 08, 2011, 03:45:31 pm
This might have been asked before, but it would be nice to be able to put code inline. That way, if you're only executing the routines once, you can save the 15 byte call.
First of all, the most you can save by making a call inline is 4 bytes.  3 For the call, and 1 for the ret.  But many of the routines are better optimized with conditional returns and so you would often save even less than that if you were able to save anything at all.  It's a little too small of a savings to justify the complexity of another pass I think.

Runer, I have no idea how I got those numbers.  My calculator says 1800 as well.  I think I might have been compensating for interrupts, but compensated the wrong way.  I'll change it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 08, 2011, 09:17:57 pm
Would variable buffer support be slower?
Title: Re: Features Wishlist
Post by: SirCmpwn on January 09, 2011, 12:05:13 am
I'd like to request de-referencing routines, so I could dereference a label, or (even better) dereference something like DispGraph.
Title: Re: Features Wishlist
Post by: Quigibo on January 09, 2011, 12:29:54 am
I'd like to request de-referencing routines, so I could dereference a label, or (even better) dereference something like DispGraph.

This is available for Axioms.  You would have to use inline assembly to call them anyway if it was in pure Axe so this system makes it more convenient as a whole.
Title: Re: Features Wishlist
Post by: squidgetx on January 09, 2011, 02:35:46 pm
Could there be a 2nd line routine for those who absolutely want clipped ones? Or maybe someone could write an Axiom.

Seconded (no pun intended)

new "EndIf" and "End!If" instructions

This would be awesome :D
Title: Re: Features Wishlist
Post by: Deep Toaster on January 09, 2011, 02:54:58 pm
@Runner, I was thinking of having "While 1" and "Repeat 0" to auto optimize to no code at all so that would take care of the Do part.  The end condition might work if I add new "EndIf" and "End!If" instructions (which only work on while/repeat loops).  It would be pretty cool too because it would mean you can have pre-check and post-check for the same loop!  Something I haven't seen yet in other languages...

That would be pretty nice. What about having just While and Repeat be the same as While 1 and Repeat 0?
Title: Re: Features Wishlist
Post by: SirCmpwn on January 09, 2011, 03:34:46 pm
EndIf sounds like Continue to me...
Title: Re: Features Wishlist
Post by: Runer112 on January 09, 2011, 03:38:05 pm
Quigibo, would you go for grayscale routines that are 5 bytes and about 33 cycles larger, but work with interrupts? I may be wrong, but I believe this could be done by changing the start and end of the routines like so:

Code: (Current routine) [Select]
Start:
ld a,i
push af
di

End:
pop af
ret po
ei
ret
   
Code: (Interrupt-friendly routine) [Select]
Start:
ex af,af'
push af
ld a,i
push af
di

End:
pop af
ex af,af'
pop af
ex af,af'
ret po
ei
ret
Title: Re: Features Wishlist
Post by: ztrumpet on January 09, 2011, 05:34:39 pm
How is this interrupt friendly?  Don't interrupts use af', or am I missing something?  Can you explain it to me?  I sense some clever coding. ;D  TIA Runer (or anyone who beats him).
Title: Re: Features Wishlist
Post by: AngelFish on January 09, 2011, 05:42:26 pm
First of all, the most you can save by making a call inline is 4 bytes.  3 For the call, and 1 for the ret.  But many of the routines are better optimized with conditional returns and so you would often save even less than that if you were able to save anything at all.  It's a little too small of a savings to justify the complexity of another pass I think.

Okay.
Title: Re: Features Wishlist
Post by: Runer112 on January 09, 2011, 05:54:37 pm
Before I begin, let me clarify something about shadow registers, because I was a bit confused about this myself for a while. When exchanging registers with shadow registers, the processor doesn't move values from the active registers into the shadow registers and vice versa. There is not one specified set of "active" registers and one specified set of "shadow" registers. Instead, the processor uses a mux to simply flip its definition of which set is the active set and which set is the shadow set. So when an interrupt activates, the processor simply designates the set of registers it wasn't previously using as the set that the interrupt will use.

Anyways, the reason the grayscale routines cause problems is because they require both sets of the af register pair. When not inside an interrupt this is fine, because nothing else was using the second af register pair. But during an interrupt, the af register pair that was being used before the interrupt probably has data in it that we don't want to destroy. However, because the grayscale routine uses both of the af register pairs, this saved value for af will be destroyed. My solution was to back up the saved af register which we don't want destroyed by putting it onto the stack at the start of the routine. At the end of the routine, it is then taken off the stack and put it back into the inactive af register to live to see another day.
Title: Re: Features Wishlist
Post by: Happybobjr on January 09, 2011, 06:05:36 pm
Feature request:  Could you make it so you could delete a label from a program by Delvar"lbl"  ?

I remember this was in earlier versions of axe but it was then removed because of lack of use.
Could this be added again, even if it has different syntax?
It would be extremely helpful in combining games into a gamepack (to save on size and excuse making it an app).
Title: Re: Features Wishlist
Post by: Quigibo on January 09, 2011, 07:57:37 pm
Runer, my custom interrupts don't use the shadow registers for af.  They push and pop af instead specifically for the purpose of making the grayscale routines compatible inside interrupts. :)
Title: Re: Features Wishlist
Post by: Runer112 on January 09, 2011, 08:39:18 pm
Oh lol. Nevermind then! ;) But why is DispGraphrr listed as incompatible with interrupts in the Commands.htm file?
Title: Re: Features Wishlist
Post by: FinaleTI on January 09, 2011, 08:43:47 pm
Mayhaps it wasn't updated?
It only became compatible with interrupts a few versions ago. I think 0.4.5, but I could be wrong.
Title: Re: Features Wishlist
Post by: Quigibo on January 09, 2011, 09:14:08 pm
Oops, you're right, I forgot to update that.  Fixed.
Title: Re: Features Wishlist
Post by: squidgetx on January 10, 2011, 06:25:03 pm
Feature request: Backing up programs from archive?
Title: Re: Features Wishlist
Post by: Broseph Radson on January 11, 2011, 02:25:58 pm
Like i accidentally said in the wrong thread (facepalm). I think something like Parse(srcProg, DestProg) would be cool. It should require that Axe be installed (like xLib) for the command to work. This would allow people to create their own guis for the parser or incorporate the parser into a shell (like axe terminal).
Title: Re: Features Wishlist
Post by: Munchor on January 11, 2011, 04:49:22 pm
I know this has been requested before, but today I really needed it, huh. break and continue functions. This topic is >117 pages long and can't check'em'all, but did Quigibo said anything about implementing them or not?
Title: Re: Features Wishlist
Post by: Quigibo on January 11, 2011, 04:58:03 pm
There is actually a pretty easy way to do break and continue.  You can put your loop in a subroutine and then call it from the program.  Using Return then acts like a break and using a goto to the subroutine acts like a continue.

Code: [Select]
While A
 While B
  If C
   Break
  End
  If D
   Continue
  End
 End
End


.The above can become:

While A
 sub(LOP)
End

Lbl LOP
While B
 ReturnIf C
 If D
  Goto LOP
 End
End
Title: Re: Features Wishlist
Post by: ztrumpet on January 11, 2011, 05:11:30 pm
Before I begin, let me clarify something about shadow registers, because I was a bit confused about this myself for a while. When exchanging registers with shadow registers, the processor doesn't move values from the active registers into the shadow registers and vice versa. There is not one specified set of "active" registers and one specified set of "shadow" registers. Instead, the processor uses a mux to simply flip its definition of which set is the active set and which set is the shadow set. So when an interrupt activates, the processor simply designates the set of registers it wasn't previously using as the set that the interrupt will use.
Thank you so much for this explanation!  Runer  :love:  ;D
Title: Re: Features Wishlist
Post by: Munchor on January 12, 2011, 01:14:36 pm
Hello, I was trying to make a Pause screenie that made Shade (10) for a while. After that it made shade 45.

However, I want it to make Shade the same number as it was when the program ran, so the user's original shade. I don't see how to do this.

If I can, how?
If not, could a GetShade() like command be implemented?
Title: Re: Features Wishlist
Post by: Ikkerens on January 12, 2011, 01:51:58 pm
Hello, I was trying to make a Pause screenie that made Shade (10) for a while. After that it made shade 45.

However, I want it to make Shade the same number as it was when the program ran, so the user's original shade. I don't see how to do this.

If I can, how?
If not, could a GetShade() like command be implemented?

Seconded on this one.
I refuse to update the user's contract without resetting it after use ;)

And, FFth post ;)
Title: Re: Features Wishlist
Post by: Quigibo on January 12, 2011, 02:29:11 pm
Oh yeah, thanks for reminding me!
Title: Re: Features Wishlist
Post by: c.sprinkle on January 12, 2011, 02:30:14 pm
I had thought about that too.
Title: Re: Features Wishlist
Post by: calcdude84se on January 12, 2011, 02:58:49 pm
Shade({E8447}+24 should do the trick :D
Title: Re: Features Wishlist
Post by: Munchor on January 12, 2011, 03:25:34 pm
Shade({E8447}+24

Could you give me an example of how to use it, please? Thanks much.

If that really works then I don't see the need of adding another command.
Title: Re: Features Wishlist
Post by: calcdude84se on January 12, 2011, 03:32:03 pm
You just use it like that :)
It will restore the contrast to what it was at the beginning of the program.
Title: Re: Features Wishlist
Post by: Munchor on January 12, 2011, 03:50:32 pm
You just use it like that :)
It will restore the contrast to what it was at the beginning of the program.

Oh! Then that's perfect! I thought you had to set it to a variable or sth.

EDIT: It worked on uPong, thanks much!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 12, 2011, 06:53:34 pm
That code would've helped so much in Reuben Quest series. I had to force the user to choose his contrast when starting a game because the tool I used used its own contrast level.
Title: Re: Features Wishlist
Post by: Runer112 on January 12, 2011, 09:09:02 pm
calcdude84se reminded me in IRC of _InsertMem and _DelMem. We both seemed to agree that they're quite useful bcalls and would be quite useful. Any chance of them being officially added? If not I might just end up writing an Axiom for it, although I get the feeling that an Axiom wouldn't be nearly as widely useful as a built-in feature. And I realize that they could be dangerous, but there are so many other ways to RAM clear in Axe already. :P
Title: Re: Features Wishlist
Post by: Deep Toaster on January 12, 2011, 10:01:00 pm
calcdude84se reminded me in IRC of _InsertMem and _DelMem. We both seemed to agree that they're quite useful bcalls and would be quite useful. Any chance of them being officially added? If not I might just end up writing an Axiom for it, although I get the feeling that an Axiom wouldn't be nearly as widely useful as a built-in feature. And I realize that they could be dangerous, but there are so many other ways to RAM clear in Axe already. :P

^ Seconded (aagin). It would be really useful to people who want to make a dynamic array or something. Is there a way to prevent it from being used on a safeRAM area, though? Maybe have Axe parse the expression for the locaton to insert/delete and throw an error if it contains any of the L1 to L6 things? Unless its in braces, of coures.

EDIT: When did the new poll go up? It seems to be tied in the grays :D
Title: Re: Features Wishlist
Post by: calcdude84se on January 12, 2011, 10:02:41 pm
Checks would just make it slower, so I'm against them.
Title: Re: Features Wishlist
Post by: Quigibo on January 13, 2011, 02:29:14 am
At this point, I'm not sure how many new features I will have time to add before 1.0.0  I'm just trying to get the Axioms working and its so difficult with so many possibilities and combinations for commands, its almost overwhelming me... but I'm at least halfway done with that luckily.

And I couldn't figure out how to delete the poll... so I just decided to make a goofy question instead :P
Title: Re: Features Wishlist
Post by: Happybobjr on January 13, 2011, 09:10:09 am
Sorry for a probably dumb question but,
Could there be another safty feature: Safe test:On/Off
When compiling it would check the program for getkey(41).
If the program does not contain, It will compile.
In this compiled version, no matter where you are, pressing on will quit the program.

I am not sure if this can be done, although i am sure it would slow things down.  But it would be great for testing code where speed doesn't matter, without the fear of a ram clear.
Title: Re: Features Wishlist
Post by: squidgetx on January 13, 2011, 12:52:51 pm
That would also (probably) have to use interrupts; hence you wouldn't be able to use your own interrupts- the parser would have to check for that too. I think MirageOS already has some kind of feature like this (as long as you don't use your own interrupts: ON+MODE) i think?

Regardless, for non-mirage programs that would be useful as well I suppose. How hard would it be to implement?

I felt tempted to add the option Netham45 is a lobster to the poll but I didn't :P.
Title: Re: Features Wishlist
Post by: Builderboy on January 13, 2011, 12:58:47 pm
well I think you could do it really easily with a certain sized piece of code that would reset the stack and return when the On-Interupt was triggered.  I'm not sure but i *think* that this would work even if your program used interrupts, and so I think is a great option for Axe parser and protecting people against infinite loops and the like :)
Title: Re: Features Wishlist
Post by: Deep Toaster on January 15, 2011, 11:59:34 am
well I think you could do it really easily with a certain sized piece of code that would reset the stack and return when the On-Interupt was triggered.  I'm not sure but i *think* that this would work even if your program used interrupts, and so I think is a great option for Axe parser and protecting people against infinite loops and the like :)

At the beginning of the program:
Code: (Axe) [Select]
:Asm(ED734B8C)

Then, when you want to quit immediately:
Code: (Axe) [Select]
:Asm(ED7B4B8C)
:Return

Haven't actually tried it yet, but that should do it.
Title: Re: Features Wishlist
Post by: calc84maniac on January 23, 2011, 07:47:29 pm
Hey, I'd like to request that the archived file reading method be modified to allow reading from programs in RAM as well. I have an idea as to how this might be accomplished.

Currently, the file byte read routine takes two arguments: an address in HL (any offset is already added in) and a page number in A. If the address is not in the $4000-$7FFF range, it increases the page as much as needed and the pointer is then put into this range.

I'd like to suggest that the routine take three arguments: the start address in HL, the offset in DE, and the page number in A. This takes the load of adding the offset off of the calling code, too. For reads that have no offset, you can make a secondary entry point that loads DE with 0 and runs the routine.

Here's what I suggest for the start of the routine:
Code: [Select]
  bit 7,h
  add hl,de
  jr z,__inROM
  ld a,(hl)
  inc hl
  ld h,(hl)
  ld l,a
  ret
__inROM:
  ;Archived file reading happens here
Title: Re: Features Wishlist
Post by: aeTIos on January 25, 2011, 10:30:30 am
Whats the new poll for ???
Title: Re: Features Wishlist
Post by: Happybobjr on January 25, 2011, 03:45:22 pm
And I couldn't figure out how to delete the poll... so I just decided to make a goofy question instead :P
^.^
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 25, 2011, 03:56:13 pm
There's a remove poll above the quick reply for me, but I'm not sure if non-staff can delete them.
Title: Re: Features Wishlist
Post by: Happybobjr on January 25, 2011, 04:10:32 pm
I don't think we can.
(after 3 accidental topics with polls attached :P )
Title: Re: Features Wishlist
Post by: Ashbad on January 25, 2011, 04:16:13 pm
Quigibo: if possible can axe eventually have a Select/Switch case structure?  Y'know like in C/C++/Java/all that good stuffz

Maybe like:

Code: (POSSIBLE AXE SWITCH FORMAT) [Select]
Switch(X)
Case 1
1->Y
Case 2
3->Z
Case 5
X-Z->Y
Case Else
Sin(Cos(Sin(Cos(X))))->Y
End
Title: Re: Features Wishlist
Post by: Quigibo on January 25, 2011, 04:42:59 pm
Hey, I'd like to request that the archived file reading method be modified to allow reading from programs in RAM as well. I have an idea as to how this might be accomplished.

Currently, the file byte read routine takes two arguments: an address in HL (any offset is already added in) and a page number in A. If the address is not in the $4000-$7FFF range, it increases the page as much as needed and the pointer is then put into this range.

I'd like to suggest that the routine take three arguments: the start address in HL, the offset in DE, and the page number in A. This takes the load of adding the offset off of the calling code, too. For reads that have no offset, you can make a secondary entry point that loads DE with 0 and runs the routine.

Here's what I suggest for the start of the routine:
Code: [Select]
  bit 7,h
  add hl,de
  jr z,__inROM
  ld a,(hl)
  inc hl
  ld h,(hl)
  ld l,a
  ret
__inROM:
  ;Archived file reading happens here

This is an interesting idea.  However, I think this would bring a lot of overhead into each use of Y1.  There would have to be an additional 2 bytes to push and pop the extra argument.  In addition, Y1 would become more of a special form than before and be difficult to parse.  For instance, now there would be a big difference between {Y1+1} and {1+Y1} in terms of how to process this and you wouldn't be able to do things like {Y1*2} either, not that you generally would, but its an additional restriction.  Another point would be that it might also require modifications to the copy routine as well to be consistent.
Title: Re: Features Wishlist
Post by: Deep Toaster on January 28, 2011, 08:33:38 pm
A suggestion for Axioms: referencing labels (or at least modifying the sub( command).
Title: Re: Features Wishlist
Post by: ztrumpet on January 28, 2011, 11:29:29 pm
I think you'll be able to use sub()rr in Axioms. :)
Title: Re: Features Wishlist
Post by: Deep Toaster on January 29, 2011, 10:23:24 am
Great, and it accepts a label as the first argument?
Title: Re: Features Wishlist
Post by: SirCmpwn on January 29, 2011, 02:02:17 pm
Pleeeeeeeeeeaaaaaaaaaaaaaase give us the ability to retrieve the address of our labels.  That would be absurdly useful for a project I've been working on in my spare time.  (Axe Terminal was a demonstration that shells are possible with Axe... this project is the realization of that idea)
How about using the L token?  Like LLB→A to store the address of label LB to A.
I think some features like this can open some doors for more advanced users, while still appealing to the beginner-indermediate crowd.
Title: Re: Features Wishlist
Post by: Deep Toaster on January 29, 2011, 02:03:29 pm
Pleeeeeeeeeeaaaaaaaaaaaaaase give us the ability to retrieve the address of our labels.  That would be absurdly useful for a project I've been working on in my spare time.

^^^ That. I have a routine that finds the address of a label, but it's absurdly complicated.

EDIT: L sounds great! /me seconds the suggestion
Title: Re: Features Wishlist
Post by: ztrumpet on January 29, 2011, 08:08:08 pm
* ZTrumpet thirds it. :)
Title: Re: Features Wishlist
Post by: Xanwell on January 29, 2011, 08:45:28 pm
Yes! That would make so many things so much simpler to do.
Title: Re: Features Wishlist
Post by: calc84maniac on January 29, 2011, 09:07:47 pm
At the same time, you could add a feature to the Asm() command that allow inserting values like in the Data command, except in the code section instead of the data section. It would greatly increase the capabilities of inline assembly, and Axe might even make a good tool for hex programmers who want to easily use absolute labels and data pointers.
Title: Re: Features Wishlist
Post by: Michael_Lee on January 29, 2011, 10:10:54 pm
I fourth (fifth?) SirCmpwn's request.  It would really enhance the power of Axe.
Title: Re: Features Wishlist
Post by: Builderboy on January 29, 2011, 10:17:01 pm
I 6th the request as well, I think we should start a petition :P
Title: Re: Features Wishlist
Post by: Quigibo on January 29, 2011, 10:39:07 pm
Oh yeah, I was planning on adding that functionality.  I'll see if I can get it working.
Title: Re: Features Wishlist
Post by: jnesselr on January 29, 2011, 11:18:40 pm
/me issues a royal decree that Quigibo should do this

I also tried issuing royal decrees that he lose his mind for this community, and add USB support. ;-) But my parliament vetoed me.
Title: Re: Features Wishlist
Post by: Deep Toaster on January 29, 2011, 11:25:19 pm
Oh yeah, I was planning on adding that functionality.  I'll see if I can get it working.

Yay! v1.0.0 is gonna be epic.

But then it's always been epic :D
Title: Re: Features Wishlist
Post by: FloppusMaximus on January 29, 2011, 11:42:20 pm
It seems like there should also be syntax for doing the opposite - using a computed value as the target of a Goto or sub().  Perhaps recycle braces for that?  (e.g., "Goto {LA}" would be equivalent to "Goto A".)  Or would that be too confusing?
Title: Re: Features Wishlist
Post by: calc84maniac on January 29, 2011, 11:54:31 pm
Maybe Goto [LA] might be a better option (or just Goto (LA)), because braces certainly imply a memory read. That would be kind of like the design mistake Zilog made with jp (hl) :P
Title: Re: Features Wishlist
Post by: ztrumpet on January 30, 2011, 12:31:33 pm
How about a command like TI Basic's Stop.  More info here: http://ourl.ca/8403/169341

An "Exit" command. ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on January 30, 2011, 12:32:34 pm
That might confuse people with the way Stop is used, though. And there are always ways to quit immediately from a shell (well, usually).
Title: Re: Features Wishlist
Post by: kindermoumoute on January 30, 2011, 12:35:37 pm
A little feature :
When we go in compilation menu, it could be nice to put the last source compiled at the beginning of the list. What do you think ?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 31, 2011, 12:49:01 am
To quit a program can't we simply Goto a label at the very end of the code? ???
Title: Re: Features Wishlist
Post by: Builderboy on January 31, 2011, 01:04:31 am
That will work only if you are not inside of a subroutine.  If you are inside a sub routine and goto a label at the very end of the program, it will act like a return.  There is currently no way to quit out of an Axe program that will work in 100% of the time.
Title: Re: Features Wishlist
Post by: Quigibo on January 31, 2011, 02:55:31 am
Well just to be fair, if you do ever find yourself with the need to reset the stack you are probably using bad coding practices or doing something too low level that should be taken care of with an Axiom.  This is for the same reason that "Goto" is so frowned upon in languages like C++.  The main reason I still have it in Axe is because it was really easy to add and should help those used to TI-BASIC, because with all the loops, control structures, and subroutines, you should pretty much never need a goto in your Axe code.
Title: Re: Features Wishlist
Post by: Munchor on January 31, 2011, 08:49:35 am
Quote
Axe Parser 1.0.0
[=========-] 90%

1. Quigibo, I'm glad to see your signature;
2. Did anyone ever request a Axe( command?;
3. Are there special getkeys for stuff like 2ND+MODE, or do we have to set a variable when 2ND is pressed?.

Thanks.
Title: Re: Features Wishlist
Post by: Deep Toaster on January 31, 2011, 09:32:34 am
2. Did anyone ever request a Axe( command?;

What would Axe( do? If you mean compiling a source from third-party programs, I suggested being able to do that in ASM :D Doing that for BASIC would require a parser hook, though.

3. Are there special getkeys for stuff like 2ND+MODE, or do we have to set a variable when 2ND is pressed?.

In ASM, there are several ways to get a key. There's low-level key reading, where you're reading the port directly, _GetCSC, where you're reading each key stroke (this is what Axe uses for getKey, so no 2ND+[MODE] combos), and _GetKey, where you're waiting for a key combo. In other words, _GetKey pauses the program until the next keystroke (no loop required), and if it's a 2ND or ALPHA, it sets the 2ND or ALPHA flag and waits for the next key. Kind of like in the TI-OS, basically.

There could be problems with implementing _GetKey in Axe, though. First of all it has problems of its own. If you do a bcall(_GetKey) in your program and the user presses 2ND+[OFF], the calculator turns off, quitting the program and causing you to lose RAM (since you didn't quit correctly). There are ways to get around that, either with more code or with the undocumented instruction.

If you want to try _GetKey for yourself, here's the hex for it: Asm(EF72496F2600)→K

If you want to try _GetKey without the 2ND+[OFF] thing: Asm(EF0B506F2600)→K
Title: Re: Features Wishlist
Post by: Munchor on January 31, 2011, 09:35:04 am
2. Did anyone ever request a Axe( command?;

What would Axe( do? If you mean compiling a source from third-party programs, I suggested being able to do that in ASM :D Doing that for BASIC would require a parser hook, though.

3. Are there special getkeys for stuff like 2ND+MODE, or do we have to set a variable when 2ND is pressed?.

In ASM, there are several ways to get a key. There's low-level key reading, where you're reading the port directly, _GetCSC, where you're reading each key stroke (this is what Axe uses for getKey, so no 2ND+[MODE] combos), and _GetKey, where you're waiting for a key combo. In other words, _GetKey pauses the program until the next keystroke (no loop required), and if it's a 2ND or ALPHA, it sets the 2ND or ALPHA flag and waits for the next key. Kind of like in the TI-OS, basically.

There could be problems with implementing _GetKey in Axe, though. First of all it has problems of its own. If you do a bcall(_GetKey) in your program and the user presses 2ND+[OFF], the calculator turns off, quitting the program and causing you to lose RAM (since you didn't quit correctly). There are ways to get around that, either with more code or with the undocumented instruction.

If you want to try _GetKey for yourself, here's the hex for it: Asm(EF72496F2600)→K

If you want to try _GetKey without the 2ND+[OFF] thing: Asm(EF0B506F2600)→K

Axe( would compile and run (consecutively).

Thanks for the getKeys explanation, I'll probably do sth like that.

Code: [Select]
If getKey(54) and getKey(1)
. CODE
End

Which would require it to be simultaneous (what I want).
Title: Re: Features Wishlist
Post by: Ashbad on January 31, 2011, 09:44:01 am
Quigibo: if possible can axe eventually have a Select/Switch case structure?  Y'know like in C/C++/Java/all that good stuffz

Maybe like:

Code: (POSSIBLE AXE SWITCH FORMAT) [Select]
Switch(X)
Case 1
1->Y
Case 2
3->Z
Case 5
X-Z->Y
Case Else
Sin(Cos(Sin(Cos(X))))->Y
End

So I'm guessing that because my idea was completely ignored it was a really bad one?
Title: Re: Features Wishlist
Post by: Galandros on January 31, 2011, 09:49:20 am
A switch statement for generating optimized assembly using vector tables would be very used, indeed.
Title: Re: Features Wishlist
Post by: SirCmpwn on January 31, 2011, 09:15:11 pm
I would love switch statements.
Title: Re: Features Wishlist
Post by: Builderboy on January 31, 2011, 09:17:42 pm
As would I, there are some things Axioms can't do
Title: Re: Features Wishlist
Post by: ztrumpet on January 31, 2011, 09:46:26 pm
Since forever ago, I still want them too. ;D
Title: Re: Features Wishlist
Post by: Binder News on January 31, 2011, 10:10:27 pm
A switch statement for generating optimized assembly using vector tables would be very used, indeed.
I would love switch statements.
As would I, there are some things Axioms can't do
Since forever ago, I still want them too. ;D
As do I. I LOVE SWITCH STATEMENTS
Title: Re: Features Wishlist
Post by: ztrumpet on January 31, 2011, 10:24:25 pm
We've had this much support for them before, and he hasn't added them.  Let's hope this time, the tide's changed! ^-^
Title: Re: Features Wishlist
Post by: SirCmpwn on January 31, 2011, 10:27:18 pm
We've had this much support for them before, and he hasn't added them.  Let's hope this time, the tide's changed! ^-^
*tiDE ;)
Title: Re: Features Wishlist
Post by: Deep Toaster on January 31, 2011, 11:04:21 pm
We've had this much support for them before, and he hasn't added them.  Let's hope this time, the tide's changed! ^-^
*tiDE ;)

XD

And a last-minute major request: Trinary operators! :D It would work great in Axe since it relies so heavily on HL. Not sure if it's too late to suggest something so big, though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 01, 2011, 12:25:56 am
I would indeed like switch statements. Sometimes it's just easier to write code that way when the program can do many different things depending of the result of a variable, for example. (such as selecting magic that uses different code for each in a game)
Title: Re: Features Wishlist
Post by: squidgetx on February 01, 2011, 05:25:46 pm
Depending on the environment you are in it is currently possible to *sort of* do switch statements...or at least a more optimized form of what we do now (this is something Runer112 taught me by the way).
Code: [Select]
rand^9+1
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
and so forth...
You can replace the Returns with Goto's if you want. The important thing is that you have to get out of the whole code block after you're done otherwise it won't work.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 01, 2011, 05:26:59 pm
You have to use Else!If in that case. Otherwise you could run multiple loops, depending on the returned value.
Title: Re: Features Wishlist
Post by: squidgetx on February 01, 2011, 05:28:22 pm
Not if you're returning or goto'ing somewhere else though :P

Edit for a completely unrelated subject: Can I bring up again a feature request for alternate steps for For() loops, the same way it is in BASIC?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2011, 02:42:13 am
Depending on the environment you are in it is currently possible to *sort of* do switch statements...or at least a more optimized form of what we do now (this is something Runer112 taught me by the way).
Code: [Select]
rand^9+1
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
and so forth...
You can replace the Returns with Goto's if you want. The important thing is that you have to get out of the whole code block after you're done otherwise it won't work.
You mean if QUigibo implements switch statements the source would be easier to read than this but the executable would be less optimized?
Title: Re: Features Wishlist
Post by: Builderboy on February 02, 2011, 03:02:54 am
I think he means its just a bit more optimized than:

Code: [Select]
If A=1
Bla
End
If A=2
Bla
End
...

But a switch command would be a *lot* more optimized than both, and a lot better looking
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 02, 2011, 03:11:37 am
Oh ok, thaT's good to hear then.
Title: Re: Features Wishlist
Post by: ztrumpet on February 02, 2011, 10:29:27 am
Edit for a completely unrelated subject: Can I bring up again a feature request for alternate steps for For() loops, the same way it is in BASIC?
There's actually a pretty easy way to do this: http://ourl.ca/4129/77715
Title: Re: Features Wishlist
Post by: Darl181 on February 02, 2011, 12:10:25 pm
I think I found something that's both an incompatibility issue and a feature request.
Can the instant goto be made compatible with CalcUtil's "save screen" option?
The save screen is when you quit out of the program editor it asks if you want to save changes or not, very useful :) but it causes crashes with axe :P
Title: Re: Features Wishlist
Post by: Munchor on February 02, 2011, 02:39:47 pm
Quigibo, if you are implementing Switch statements, can you include support for Strings?

In computers, no programming language has switchs with strings, and I'd love them ;D
Title: Re: Features Wishlist
Post by: Binder News on February 02, 2011, 03:23:41 pm
^So would I
Title: Re: Features Wishlist
Post by: calc84maniac on February 02, 2011, 03:30:13 pm
Not that Axe has string comparison features in the first place :P
Title: Re: Features Wishlist
Post by: Ashbad on February 02, 2011, 03:35:23 pm
the thing is how easy and optimize switches would be.  You would only have to check the value of the original statement once, and then compare that to all the others similar to a long chain of "Else!If... Else!If..." statements.   I thought it was a good idea, and I think I could help code it, though I doubt it's really that difficult to code.

While we're at it.. I also suggest adding optimized string comparison functions :)
Title: Re: Features Wishlist
Post by: Compynerd255 on February 02, 2011, 03:42:04 pm
Quigibo, if you are implementing Switch statements, can you include support for Strings?

In computers, no programming language has switchs with strings, and I'd love them ;D
C# and related languages actually do have switches for strings (I've used them more than once). However, it would be nice to have any string comparisons at all in Axe, since we want name strings and stuff like that.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 02, 2011, 03:52:56 pm
Quigibo, if you are implementing Switch statements, can you include support for Strings?

In computers, no programming language has switchs with strings, and I'd love them ;D

It might be worse in Axe since string comparison is so inefficient (there's no string comparison test yet anyway).

While we're at it.. I also suggest adding optimized string comparison functions :)

I had a string utility Axiom back when Axe supported them, but I lost it when I lost my thumb drive. I could easily recode it, though :D

But it'd be nice as a built-in function too, if Axe still has space on its data page?
Title: Re: Features Wishlist
Post by: Ashbad on February 02, 2011, 03:54:26 pm
thing is, string comparison isn't hard to make, but hard to optimize, from what I can tell; and putting that in a switch in axe could be painful indeed :(
Title: Re: Features Wishlist
Post by: Munchor on February 02, 2011, 06:52:48 pm
Oh yeah, Axe doesn't even have string comparison.

It's really hard to code like this in stuff like 'Easy', 'Medium' or 'Hard'. There are lot of ways to turn this around of course, but indirect.
Title: Re: Features Wishlist
Post by: kindermoumoute on February 03, 2011, 01:49:14 am
A little feature :
When we go in compilation menu, it could be nice to put the last source compiled at the beginning of the list. What do you think ?

I think it could be very intuitive, and usefull.
Title: Re: Features Wishlist
Post by: JustCause on February 03, 2011, 10:25:37 am
An option to disable the token swaps when editing source. They slow down the program editor a bit, compounded by my recent switch to the DCS7 8-line program editor. I can deal with ref() instead of Rect().
Title: Re: Features Wishlist
Post by: Compynerd255 on February 03, 2011, 10:27:40 am
Oh, I have a feature request: a Symbol Table. In other words, I want to define memory locations other than L1-L6 as alpha-numeric symbols. For example, this:
Code: [Select]
GetCalc(Str1, 768) -> {L1+700}r
...code...
Pt-Off(2,5,Pic1)->{L1+700}r
Copy(L6, {L1+700}r, 768
becomes this:
Code: [Select]
#Define(BUF,L1+700
GetCalc(Str1, 768) -> BUF
...code...
Pt-Off(2,5,Pic1)->BUF
Copy(L6,BUF,768)
ASM programmers can do this, so why can't we?
Title: Re: Features Wishlist
Post by: Quigibo on February 03, 2011, 01:48:14 pm
That would use the symbol table which is already limited by 153 entries for labels and static pointers.  If I add named constants, those would have to share that same space and also be limited to 3 characters long.  It would be nice though, I'll think about it.

By the way, a lot of people mentioned switch statements.  I tried before but I couldn't get much optimization.  But just now I remembered a better method for switch statements that was right under my nose the entire time: the same strategy I use already in the parser!  Each check would only take 4 bytes plus 8 bytes for initialization.  The format would be like this:

A->Switch(0,ZER,1,ONE,10,TEN,1000,THO)

Which checks A.  If A is 0 it jumps to ZER, if its 1, it jumps to ONE, etc.  And if its none of them, it continues.  This allows me to create a vector jump table for super space efficiency.  But, there is quite a lot of overhead, so this would be really only useful if you use it a lot.

Code: [Select]
ld   hl,(axv_A)
 ld   de,JT1
 ld   a,4
call JumpTable

JT1:
.dw 0,ZER
.dw 5,FIV
.dw 10,TEN
.dw 1000,THO

JumpTable:
 ld   b,h
 ld   c,l
 ex   de,hl
loop:
 ld   e,(hl)
 inc  hl
 ld   d,(hl)
 inc  hl
 ex   de,hl
 or   a
 sbc  hl,bc
 ex   de,hl
 ld   e,(hl)
 inc  hl
 ld   d,(hl)
 jr   z,done
 inc  hl
 dec  a
 jr   nz,loop
 ret
done:
 pop  hl
 ex   de,hl
 jp   (hl)
Title: Re: Features Wishlist
Post by: calc84maniac on February 03, 2011, 05:08:22 pm
Sounds like a neat idea :)

I made some optimizations, by the way:
Code: [Select]
ld   hl,(axv_A)
 ld   de,JT1
 ld   b,4
call JumpTable

JT1:
.dw 0,ZER
.dw 5,FIV
.dw 10,TEN
.dw 1000,THO

JumpTable:
loop:
 ld   a,(de)
 cp   l
 inc  de
 jr nz,skip
 ld   a,(de)
 cp   h
skip:
 inc  de
 ld   a,(de)
 inc  de
 jr   z,done
 inc  de
 djnz loop
 ret
done:
 pop  hl
 ld   l,a
 ld   a,(de)
 ld   h,a
 jp   (hl)
Title: Re: Features Wishlist
Post by: ztrumpet on February 03, 2011, 06:27:18 pm
Sounds awesome!  I can't wait for switches. ;D

I second the request for the #define command. :)
Title: Re: Features Wishlist
Post by: Calcaholic on February 03, 2011, 06:56:52 pm
I just want to add two very simple proposals hoping that they aren't mentioned yet.

First that the Axe-specific entries in the catalog are implemented in the alphabetical order, so that tey're more easy to find.
And second a option to compile a progam directly using a menu entry for example in the program menu.


By the way I want to enunciate my very thanks for the Axe Parser. I wish having known it before.
Title: Re: Features Wishlist
Post by: Binder News on February 03, 2011, 07:13:55 pm
First that the Axe-specific entries in the catalog are implemented in the alphabetical order, so that tey're more easy to find.

I don't remember where, but I think someone asked for this before (I think it was somewhere in this thread). Quigibo said that it would actually be kinda hard. But I might be mistaken.

Second, that's actually a cool idea. But I'm not sure how easy that would be with hooks.
/me looks for a list of hooks to see if there is one for when something is selected in a menu
I know there is a parser hook, but I'm not sure what else there is.

Third, welcome to Omnimaga! You should introduce yourself in our introductions place/sub-forum/thing.
Title: Re: Features Wishlist
Post by: squidgetx on February 03, 2011, 07:23:34 pm
He did already lol. And IIRC, changing the catalog would be pretty hard. Also, I second the request to have the last-compile program at the top of the screen :)
Title: Re: Features Wishlist
Post by: Ashbad on February 03, 2011, 07:26:16 pm
maybe a possible Lite-Axe program that compiles very simple programs on the fly O.o

Actually, that would be cool.  Kinda like how Dr. Java is a lite version of the real Java compiler.  Though, maybe someone besides quigibo should make this, he's already busy with normal axe :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 03, 2011, 11:02:33 pm
First that the Axe-specific entries in the catalog are implemented in the alphabetical order, so that tey're more easy to find.

I don't remember where, but I think someone asked for this before (I think it was somewhere in this thread). Quigibo said that it would actually be kinda hard. But I might be mistaken.

Yeah that was me, because it might be hard to find some such as Rect, for example. However he said it would be hard. I don't remember why but I suspect it would require an entire new page that contains the order of every single command, like the language localization apps.
Title: Re: Features Wishlist
Post by: Compynerd255 on February 04, 2011, 10:20:21 am
I think that the switch idea as it shows sounds really cool. If you are concerned about overhead for a lot of these commands, start eating into saveSScreen or appBackupSScreen if you aren't already. You could even create an Appvar buffer if needs be.

Quigibo doesn't have to do this, but I think it would be cool if someone made an app kind of like TI 83 Plus Catalog Help, except with Axe commands instead of TI-Basic. (As a review, this program installs a keyhook to the (+) key that brings up the command syntax for that command highlighted in the Catalog or function menus, and then lets you edit it in the top line and paste it back in the previous location). This would help people code using commands they don't usually use.
Title: Re: Features Wishlist
Post by: Munchor on February 04, 2011, 10:21:40 am
Sounds awesome!  I can't wait for switches. ;D

I second the request for the #define command. :)

What would it do?
Title: Re: Features Wishlist
Post by: jnesselr on February 04, 2011, 10:25:22 am
Sounds awesome!  I can't wait for switches. ;D

I second the request for the #define command. :)

What would it do?
Defines stuff.  No, seriously, it just defines stuff as existing.  It's a strange command, to me.  It has some interesting uses, though.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 04, 2011, 10:30:45 am
Like if you didn't want to remember a number like E848E, you could #define a name for it.
Title: Re: Features Wishlist
Post by: Ashbad on February 04, 2011, 01:46:31 pm
Like if you didn't want to remember a number like E848E, you could #define a name for it.

Like #Define($848E, SAUSAGE), so that SAUSAGE = $848E
Title: Re: Features Wishlist
Post by: Munchor on February 04, 2011, 02:09:36 pm
Like if you didn't want to remember a number like E848E, you could #define a name for it.

Like #Define($848E, SAUSAGE), so that SAUSAGE = $848E

The register $848E..... I see, then we'd have more control over our programs, I like it ;D
Title: Re: Features Wishlist
Post by: Darl181 on February 04, 2011, 02:31:23 pm
I got a random idea this morning--4*4 sprites.  Instead of it always having to be 8*8 and doing, say, [F09090F000000000], something like [F99F] would be just a square, and only a square.
Title: Re: Features Wishlist
Post by: ztrumpet on February 04, 2011, 03:59:59 pm
I still want 8*y sprites that can be any height sometime. ;D  For instance, 8*4...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 05, 2011, 12:06:43 am
Yeah that would be cool, especially for custom fonts. :D
Title: Re: Features Wishlist
Post by: Darl181 on February 05, 2011, 12:15:15 pm
AFAIK this got ignored, and it's the root of many ram clears for me...
I think I found something that's both an incompatibility issue and a feature request.
Can the instant goto be made compatible with CalcUtil's "save screen" option?
The save screen is when you quit out of the program editor it asks if you want to save changes or not, very useful :) but it causes crashes with axe :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 06, 2011, 12:01:12 am
Shouldn't this go in bug reports? ???
Title: Re: Features Wishlist
Post by: Darl181 on February 07, 2011, 06:57:12 pm
Well, It's kind of both :P
I think the Bug reports thread is for unexplained things, but I guess I'll do that anyway.
Title: Re: Features Wishlist
Post by: NinjaKnight on February 07, 2011, 09:52:11 pm
Changing some of the drawing commands so that they work with the back-buffer/arbitrary buffers, like Text() and Circle().
Title: Re: Features Wishlist
Post by: Darl181 on February 07, 2011, 09:59:48 pm
Yes, that would be great ;D
IDK about arbitrary buffers though...
What would also be nice would be sprite-like manipulation of most every buffer-related command, but that's a lot to add :P
Syntax like Pt-Change(Line(5,5,20,5))r or something.
That is pretty complex tho...
Title: Re: Features Wishlist
Post by: Deep Toaster on February 08, 2011, 09:20:04 am
Syntax like Pt-Change(Line(5,5,20,5))r or something.
That is pretty complex tho...

How would Pt-Change( take one argument, though? And doing that would add a few more bytes to every drawing routine to restore HL, which might not be used.
Title: Re: Features Wishlist
Post by: Darl181 on February 08, 2011, 02:40:06 pm
IDK anything about asm, except it's complicated :P
I was thinking, like there's the r modifier and such, that other tokens can be used the same way.
Title: Re: Features Wishlist
Post by: squidgetx on February 08, 2011, 06:18:42 pm
Can I request some sort of sign function that would return the sign (65535, 0, or 1) of a number? Too bad sign{} is already in use though...
Title: Re: Features Wishlist
Post by: calc84maniac on February 08, 2011, 06:41:28 pm
(X>>0)-(X<<0)
Title: Re: Features Wishlist
Post by: squidgetx on February 12, 2011, 08:25:10 pm
Feature request: nibble read/write command option to do the opposite endian-ness of the current nibble routines.
Title: Re: Features Wishlist
Post by: guy6020665 on February 12, 2011, 10:39:29 pm
Umm just wondering. Ive been thinking maybe a Vertical +2 using a number to tell the parser how many pixels to shift?
Title: Re: Features Wishlist
Post by: Deep Toaster on February 12, 2011, 11:14:40 pm
That sounds like a good idea. It would get complicated for Horizontal , though, so maybe just Vertical ?
Title: Re: Features Wishlist
Post by: ztrumpet on February 12, 2011, 11:19:58 pm
Nah, as it's easy enough to implement yourself...
Vertical +2 is Copy(L6+24,L6,744)
Basically, Copy(L6+12(X),L6,768-12(X)) ;D

Edit:  That may be "Vertical -".  I'm not sure which is which anymore. :P
Title: Re: Features Wishlist
Post by: souvik1997 on February 13, 2011, 12:19:38 am
Drawing to an arbitrary buffer would be really useful IMO.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 13, 2011, 12:40:18 am
Edit:  That may be "Vertical -".  I'm not sure which is which anymore. :P

Yeah, it is. And good point, that works really well. Vertical -2 might be easier to calculate/use, though.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 13, 2011, 04:01:43 am
Nah, as it's easy enough to implement yourself...
Vertical +2 is Fill(L6+24,L6,744)
Basically, Fill(L6+12(X),L6,768-12(X)) ;D

Edit:  That may be "Vertical -".  I'm not sure which is which anymore. :P
Yeah that works too. I guess it would be faster, too, right, since the screen wouldn't be shifted twice, but only once. I could be wrong, though.
Title: Re: Features Wishlist
Post by: FinaleTI on February 13, 2011, 08:47:35 am
Drawing to an arbitrary buffer would be really useful IMO.
Pixel testing an arbitrary buffer would also be fantastic.
Title: Re: Features Wishlist
Post by: ztrumpet on February 13, 2011, 10:27:27 am
Note that I had a mistake in my earlier post.  It should have been "Copy()" not "Fill()".  I think I was tired or something. O.O
Title: Re: Features Wishlist
Post by: Deep Toaster on February 13, 2011, 11:32:56 am
Lol, nobody noticed it ;D

At least nobody went ahead and tried it.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 13, 2011, 03:17:04 pm
Drawing to an arbitrary buffer would be really useful IMO.
Pixel testing an arbitrary buffer would also be fantastic.
Yeah I agree. I wonder how hard it would be to implement
Title: Re: Features Wishlist
Post by: Munchor on February 13, 2011, 03:17:49 pm
Drawing to an arbitrary buffer would be really useful IMO.
Pixel testing an arbitrary buffer would also be fantastic.

You mean pxl-test stuff in the back buffers?
Title: Re: Features Wishlist
Post by: Happybobjr on February 13, 2011, 03:18:50 pm
I think he is saying that it could be to any mem location. (as if you made a buffer)
Title: Re: Features Wishlist
Post by: Builderboy on February 13, 2011, 03:24:40 pm
We could probably write one ourselves really easily since we have the getBit function
Title: Re: Features Wishlist
Post by: aeTIos on February 14, 2011, 01:19:52 pm
A Bitmap( command that draws to the buffer, and a Pt-Mask command with custom height and width, for example Pt-Mask(xpos,ypos,hex,height, width)
(cursive is optional argument)
Title: Re: Features Wishlist
Post by: Michael_Lee on February 14, 2011, 02:47:11 pm
You can draw Bitmap( on the buffer, you know...
Just place a Fix 9 at the beginning of your program, and a Fix 8 at the end.
Title: Re: Features Wishlist
Post by: aeTIos on February 14, 2011, 02:48:50 pm
:o i didnt know that :D
so, fix 9 draws bitmaps to the buffer. does it do any more? (always nice to know that)
Title: Re: Features Wishlist
Post by: Michael_Lee on February 14, 2011, 02:59:51 pm
Nope, just that.  But you have to make sure to add the Fix 8 to the end of the program.  It makes the calc draw bitmaps directly to screen, like normal.
Title: Re: Features Wishlist
Post by: ralphdspam on February 15, 2011, 01:39:56 am
I would also like to be able to read/write to bits instead of just bytes and nibbles. 
Title: Re: Features Wishlist
Post by: Builderboy on February 15, 2011, 01:44:04 am
Nope, just that.  But you have to make sure to add the Fix 8 to the end of the program.  It makes the calc draw bitmaps directly to screen, like normal.

Question: At which point does the calc ever actually use the bitmap command I wonder? O.o
Title: Re: Features Wishlist
Post by: Michael_Lee on February 15, 2011, 02:06:48 am
It would also be able to read/write to bits instead of just bytes and nibbles. 

Erm... what?

@Builderboy: I've no idea but it would be interesting to find out.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 15, 2011, 02:23:24 am
I think he meant I would also like to be able. Didn't Axe already support bit reading/writing, though?
Title: Re: Features Wishlist
Post by: Michael_Lee on February 15, 2011, 02:43:51 am
Ah.  That would make sense.
Axe does support it, but I've always thought that it was a bit complicated to do.
Title: Re: Features Wishlist
Post by: FinaleTI on February 15, 2011, 05:55:54 am
Nope, just that.  But you have to make sure to add the Fix 8 to the end of the program.  It makes the calc draw bitmaps directly to screen, like normal.

Question: At which point does the calc ever actually use the bitmap command I wonder? O.o
I believe the cross-like graphscreen cursor is a bitmap.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 15, 2011, 09:21:28 am
It would also be able to read/write to bits instead of just bytes and nibbles. 

You can, with bit-masking. (Use and, or, and xor to mask bytes, then store them back.)

Bit flipping sounds like a useful feature too. Might be slow, though.
Title: Re: Features Wishlist
Post by: NinjaKnight on February 15, 2011, 10:49:45 pm
Bit flipping sounds like a useful feature too. Might be slow, though.

What do you mean by bit flipping? If I understand correctly, couldn't that be done with a simple
A xor b(bits to be flipped) -> A

For example,
A xor 15 -> A
would flip bits 0-4.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 15, 2011, 11:11:10 pm
Whoops, I just noticed I replied to ralphdspam on a different page... :D

Yep, and use or to set and and to reset. Use the plot style tokens for full 16 bit control. There are also ASM instructions to do it on bits directly, which is what I think ralphdspam meant

And now that I think of it, when would you use SET and RES in an Axe program, then? Especially considering the way Axe does math.
Title: Re: Features Wishlist
Post by: ralphdspam on February 15, 2011, 11:42:29 pm
Whoops, I just noticed I replied to ralphdspam on a different page... :D

I actually had Huffman Coding in mind when I requested this feature.  It would save a lot of space in my code if I could just work with individual bits instead of having to test the entire byte for the individual bits.  (if that made any sense  :P)
Title: Re: Features Wishlist
Post by: Compynerd255 on February 16, 2011, 10:25:48 am
And now that I think of it, when would you use SET and RES in an Axe program, then? Especially considering the way Axe does math.
You would use it to store multiple booleans inside one 8-bit number, in order to save space. I personally use bit checking for Eitrix, using individual bits to store the grid. Similar tricks can be used to store 2, 4, and 8 bit numbers inside larger number structures.
Title: Re: Features Wishlist
Post by: Runer112 on February 18, 2011, 11:46:59 pm
Could you give axioms the ability to define their own Fix statements? As far as I can tell, the parser handles Fix statements as special cases anyways, merging two one-byte tokens into one command. I believe it would be invaluable for Axiom programmers to be able to provide settings for their commands with their own Fix statements, whether they are expanded to allow arguments greater than 2 digits like Fix 10, or at least allow any second token to be appended, like Fix A, or even something like Fix  or .


EDIT: Also, any chance of support for Axioms followed by a store token? Like: Pt-On(X,Y,PIC)→BUFF


EDIT 2: Oh yeah, and is the limit of 32 entries per Axiom listed in the documentation a technical limitation? Because if not, any chances that limit could be lifted? I forsee something I'm working on passing 32 entries. A lot of them are just custom variable defines and slightly varying calls (number of arguments, r modifiers) for a few actual routines, but the total number is bound to surpass 32.
Title: Re: Features Wishlist
Post by: Darl181 on February 19, 2011, 12:04:39 am
Something like the multi-digit Fix things would be cool in a normal program as well (something like Fix 0,6,8).
Title: Re: Features Wishlist
Post by: jnesselr on February 19, 2011, 11:02:19 am
Something like the multi-digit Fix things would be cool in a normal program as well (something like Fix 0,6,8).
or Fix 068 could work.  I believe that was asked before somewhere.  I like the idea.  Would it be smaller compiled code?, or the same?
Title: Re: Features Wishlist
Post by: Deep Toaster on February 19, 2011, 11:07:26 am
Something like the multi-digit Fix things would be cool in a normal program as well (something like Fix 0,6,8).
or Fix 068 could work.  I believe that was asked before somewhere.  I like the idea.  Would it be smaller compiled code?, or the same?

Nope, it'd be exactly the same compiled (since each Fix is an individual SET/RES instruction). I like the idea of combining them, though, for easier-to-read code.
Title: Re: Features Wishlist
Post by: ralphdspam on February 20, 2011, 06:01:14 pm
It would also [like to] be able to read/write to bits instead of just bytes and nibbles. 

You can, with bit-masking. (Use and, or, and xor to mask bytes, then store them back.)

Bit flipping sounds like a useful feature too. Might be slow, though.

Yeah, but I would have to do something like this:
Say I want to test 10110011
Code: [Select]
179->A
For(B,0,1)
If nib{A*2+B} and 8
Sub(D)
End
If nib{A*2+B} and 4
Sub(D)
End
If nib{A*2+B} and 2
Sub(D)
End
If nib{A*2+B} and 1
Sub(D)
End
End
Lbl D
.Do Stuff
Return
If there were to be command specifically for bits, I would be able to do this:
Code: [Select]
179->A
For(B,0,7)
If bit{A*8+B}
.Do Stuff
End
End
Title: Re: Features Wishlist
Post by: souvik1997 on February 20, 2011, 06:07:34 pm
That shouldn't be too hard, there is already a bit opcode in ASM.
Title: Re: Features Wishlist
Post by: Runer112 on February 20, 2011, 06:28:12 pm
Code: [Select]
179->A
For(B,0,7)
If bit{A*8+B}
.Do Stuff
End
End

It already is possible to extract single bits from a byte or word with the e command (that's Euler's constant, not just a plain lowercase e). For instance, AeB would retrieve the Bth bit of the low byte of A, with B=0 corresponding to the most significant bit and B=7 corresponding to the least significant bit. The code you posted could be emulated with the following:

Code: [Select]
{POINTER}→A
For(B,0,7)
If AeB
.Do Stuff
End
End
Title: Re: Features Wishlist
Post by: calc84maniac on February 20, 2011, 11:10:54 pm
Yes, and also multiplying an address by 8 loses a LOT of important information. The nibble command gets around multiplying by 2 by having two separate commands, one for flash(apps) and one for ram.
Title: Re: Features Wishlist
Post by: Builderboy on February 21, 2011, 02:05:53 am
What I think should be added is the ability to *set* bits through a method other than ORing or ANDing bit masks, of which not everyone is familiar with
Title: Re: Features Wishlist
Post by: ralphdspam on February 25, 2011, 01:18:50 am
What I think should be added is the ability to *set* bits through a method other than ORing or ANDing bit masks, of which not everyone is familiar with

Especially, the people that come from a BASIC background (like me)

EDIT: Oh, and are there still plans for mode 7 gfx? That would be great.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 28, 2011, 02:07:06 am
I think Mode 7 will be added through an axiom.
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2011, 02:09:00 am
It would also be nice to be able to back up programs even if they are archived :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 28, 2011, 02:19:16 am
We can't? I always thought we could... it would be a nice idea in case before compiling we screwed up our code to the point of requiring a rollback. X.x
Title: Re: Features Wishlist
Post by: Builderboy on February 28, 2011, 02:22:51 am
Yeah for some reason it does nothing when the code is archived o.O maybe because it doesnt auto backup when its archived?
Title: Re: Features Wishlist
Post by: Compynerd255 on February 28, 2011, 10:29:40 am
Yeah for some reason it does nothing when the code is archived o.O maybe because it doesnt auto backup when its archived?
Probably because it's archived. If its archived, the reasoning is that you aren't working on it at the time. There is very little reason to back it up. If you need to, you could back it up manually, or unarchive it.
Title: Re: Features Wishlist
Post by: Deep Toaster on February 28, 2011, 08:53:27 pm
Request: Adding a null byte after input.
Title: Re: Features Wishlist
Post by: Quigibo on March 01, 2011, 03:42:35 am
The problem with backing up things in archive is that there isn't always enough free ram to create the backup (whereas you are guaranteed to have it if it already exists in ram).
Title: Re: Features Wishlist
Post by: Compynerd255 on March 01, 2011, 11:13:23 am
Request: Adding a null byte after input.
You could always add that yourself. In fact, you are probably doing character processing on the string anyway, since input returns a string of tokens.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 01, 2011, 06:40:38 pm
Request: Adding a null byte after input.
You could always add that yourself. In fact, you are probably doing character processing on the string anyway, since input returns a string of tokens.

By then there's no way to know how long the string is, though.
Title: Re: Features Wishlist
Post by: ztrumpet on March 01, 2011, 06:49:53 pm
The problem with backing up things in archive is that there isn't always enough free ram to create the backup (whereas you are guaranteed to have it if it already exists in ram).
This doesn't sound like too much of a problem; can the parser check and then tell the user "Not enough RAM to backup" if it errors?
I think this is a good idea. ;)
Title: Re: Features Wishlist
Post by: Darl181 on March 01, 2011, 08:18:09 pm
Something that would be nice:  run indicator going while it's in the process of "Writing APP..."
Occasionally it seems frozen :P

Also, lowercase letters usable in static pointers GDB, Str, and Pic would really help
Title: Re: Features Wishlist
Post by: calc84maniac on March 01, 2011, 08:21:46 pm
Request: Adding a null byte after input.
You could always add that yourself. In fact, you are probably doing character processing on the string anyway, since input returns a string of tokens.

By then there's no way to know how long the string is, though.
Doesn't the returned string have size bytes just like any other variable? It's just a temporary string variable.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 01, 2011, 08:54:41 pm
I ... didn't know that x.x

I thought it was stored in some safe RAM area. Guess I should have checked XD
Title: Re: Features Wishlist
Post by: squidgetx on March 02, 2011, 08:33:49 pm
Something else; Normally Axe will save changes, but if you get a compile error and scroll to with prgm, it won't save any setting changes. This is sometimes annoying, at least for me, because often I find myself accidentally compiling apps...
Something that would be nice:  run indicator going while it's in the process of "Writing APP..."
Occasionally it seems frozen :P
^^ This. Especially since I have encountered scenarios where it really was frozen (well, I waited 10 minutes before pulling a battery, thankfully archive remained uncorrupted)
Doesn't the returned string have size bytes just like any other variable? It's just a temporary string variable.
Huh, I always thought it just pointed the appropriate location in L5.
Title: Re: Features Wishlist
Post by: Compynerd255 on March 03, 2011, 10:19:52 am
I have another cool feature request - you don't have to do this if you don't want to.

I'd like an auto-updating version number in the standard Major.Minor.Revision format. You would specify a version number to start counting from in the program, then the Revision would automatically update every time the program is compiled. Then, you could use this value in your programs (e.g. to make sure that two calculators playing a link game are playing the same version of the game).
Title: Re: Features Wishlist
Post by: aeTIos on March 03, 2011, 10:29:03 am
Request: fixed input command (it sometimes adds extra bytes)
Title: Re: Features Wishlist
Post by: calc84maniac on March 03, 2011, 10:33:36 am
Request: fixed input command (it sometimes adds extra bytes)
What do you mean, "adds extra bytes"?
Title: Re: Features Wishlist
Post by: Deep Toaster on March 03, 2011, 08:25:42 pm
Request: fixed input command (it sometimes adds extra bytes)

It doesn't add extra bytes. You probably noticed that displaying it has some stuff that comes after it. That's because a string created by input isn't a null-terminated string like you're used to, where the string ends with a byte of [00]. Instead it's continuous with the rest of the data as a length-prefixed string, like with BASIC strings. In other words, instead of ending the string with a 0, the string has its own length stored in the two bytes preceding it. Use

Code: (Axe) [Select]
:input→P
:{P-2}r

to get the length of the string.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2011, 02:46:00 am
I have another cool feature request - you don't have to do this if you don't want to.

I'd like an auto-updating version number in the standard Major.Minor.Revision format. You would specify a version number to start counting from in the program, then the Revision would automatically update every time the program is compiled. Then, you could use this value in your programs (e.g. to make sure that two calculators playing a link game are playing the same version of the game).
The problem, though, is that some people could just cheat by modifying the game with calcsys. The only way to prevent cheating would be to scan the entire program via the link port and compare with your copy, to spot any differences. But again, this isn't very likely to happen since the average calc gamer at school barely even know how to archive/unarchive/turn ON the calc, anyway.
Title: Re: Features Wishlist
Post by: Quigibo on March 04, 2011, 02:57:07 am
I have another cool feature request - you don't have to do this if you don't want to.

I'd like an auto-updating version number in the standard Major.Minor.Revision format. You would specify a version number to start counting from in the program, then the Revision would automatically update every time the program is compiled. Then, you could use this value in your programs (e.g. to make sure that two calculators playing a link game are playing the same version of the game).
The problem, though, is that some people could just cheat by modifying the game with calcsys. The only way to prevent cheating would be to scan the entire program via the link port and compare with your copy, to spot any differences. But again, this isn't very likely to happen since the average calc gamer at school barely even know how to archive/unarchive/turn ON the calc, anyway.

The goal isn't to prevent cheating though, its just to try to make sure the programs are compatible so that linking works 100%.  Like if you changed your linking routine or something between versions.

This isn't really an Axe feature though, its really something the programmer should take care of themselves and its relatively trivial.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 04, 2011, 03:00:50 am
Oh, right, then I guess it could be nice, but I agree it might be best if the programmer handled this.
Title: Re: Features Wishlist
Post by: Runer112 on March 08, 2011, 05:46:47 pm
thepenguin77's perfect grayscale (http://ourl.ca/9538) tutorial brings up a good request: changing the display routines to advance in rows instead of in columns. Although this would possibly slow the routines down a bit, even without perfect crystal timer synchronization, this should make the grayscale look better.
Title: Re: Features Wishlist
Post by: yrinfish on March 12, 2011, 03:38:26 pm
Another request:
An GetCalc() that returns a pointer to the VAT entry of it.
Something like:
Code: [Select]
:"prgrmBLAH"->Str0
:.NORMAL
:GetCalc(Str0)->A
:.POINTER TO VAT
:GetCalc(Str0)r->A
That r is the angle menu r
Title: Re: Features Wishlist
Post by: Ashbad on March 12, 2011, 03:40:23 pm
that would be useful, to find out other attributes of the program stored in the VAT.  however, if I'm not mistaken, there might be a simple way to do this in a few commands already (not sure, thought I saw something like that before.)
Title: Re: Features Wishlist
Post by: yrinfish on March 12, 2011, 03:54:21 pm
That would be nice!!!
I want to use it to store sub-programs as an appvar and change them to a program when it is started.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 12, 2011, 04:40:17 pm
that would be useful, to find out other attributes of the program stored in the VAT.  however, if I'm not mistaken, there might be a simple way to do this in a few commands already (not sure, thought I saw something like that before.)

I think that would be better for an Axiom like MemKit (not sure if it already has this).
Title: Re: Features Wishlist
Post by: yrinfish on March 12, 2011, 04:59:08 pm
Oh, I accidrntally tapped (iPod Touch) on report to moderator, if anything happens, it is my fault, and no, memkit has wonderful functions, except this one.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 12, 2011, 08:10:56 pm
Nested libraries would be nice.
Title: Re: Features Wishlist
Post by: Runer112 on March 14, 2011, 10:19:00 pm
In connection with this (http://ourl.ca/9165/185146), I've always thought it would be nice if the inData() routine returned 0 instead of the position of the terminator when the byte to search for is 0. As in the example I cited, we currently have to navigate around this problem by tagging +1's onto everything. Unless you have a reason for preferring the way the current routine treats 0 inputs, can this be changed?


And if you want to change it, I'll make things even easier. After a bit of playing around I have come up with a routine that should implement this change. It is the same size as the current routine and about the same speed; the amount of overhead cycles isn't vastly different, and it only takes 4 cycles more per iteration. Anyway, here it is:

Code: [Select]
p_InData:
.db __InDataEnd-$-1
ex de,hl
xor a
ld h,a
ld l,a
__InDataLoop:
cp c
ret z
ld a,(de)
inc de
inc hl
or a
jr nz,__InDataLoop
ld h,a
ld l,a
ret
__InDataEnd:




EDIT: Also, because I'm sure I'm not the only one wondering about this, I'll go ahead and ask it:

Nested libraries would be nice.
Nested libraries? ???
Title: Re: Features Wishlist
Post by: Compynerd255 on March 15, 2011, 12:57:08 am
EDIT: Also, because I'm sure I'm not the only one wondering about this, I'll go ahead and ask it:
Nested libraries would be nice.
Nested libraries? ???
He means libraries within libraries. Remember that in Axe, you can use prgmNAME to include the Axe program called NAME as if it were inline. Nested libraries means that we could use this same concept within the referenced program (which we currently can't do).
Title: Re: Features Wishlist
Post by: Deep Toaster on March 15, 2011, 09:21:12 am
I would really like nested subprograms, but having subprograms one level deep already made compiling a lot slower :-\
Title: Re: Features Wishlist
Post by: JustCause on March 15, 2011, 10:02:12 am
ClrDrawrr to clear both buffers.
Title: Re: Features Wishlist
Post by: Runer112 on March 15, 2011, 04:20:45 pm
Couldn't you just do ClrDraw and ClrDrawr?
Title: Re: Features Wishlist
Post by: Compynerd255 on March 15, 2011, 05:35:09 pm
Couldn't you just do ClrDraw and ClrDrawr?
But that would be slower, since its two loops we have to worry about. Its the same as the logic of having a DispGraphClrDraw command. However, this routine could be coded yourself:
Code: [Select]
For(I,0,767
0→{L3+I}→{L6+I}
End
Title: Re: Features Wishlist
Post by: Runer112 on March 15, 2011, 05:49:45 pm
Using an optimized assembly routine, I guess I could make a routine for clearing both buffers at once. ClrDraw \ ClrDrawr would take 34592 cycles by my calculation. The following routine (including the call) would take 25405 cycles, so about 1/3 faster.

Code: [Select]
p_ClearBothBuffers:
ld hl,plotSScreen
ld de,appBackUpScreen
ld bc,768
xor a
__ClearBothBuffersLoop:
ld (hl),a
ldi
jp pe,__ClearBothBuffersLoop
ret
Title: Re: Features Wishlist
Post by: Quigibo on March 16, 2011, 05:54:08 pm
My spring break is next week.  I will finally have time to pick this project up again so expect an update in about a week.  I know there have been a lot of bugs/feature requests recently that I've probably forgot about or missed, I will try to reread most of the features wishlist, bug reports, and optimization threads on Friday so if there are any other important things you feel I should do not already mentioned in those threads, now would be a good time to bring them up there.
Title: Re: Features Wishlist
Post by: Freyaday on March 16, 2011, 10:17:47 pm
A way to merge multiple buffers into one and two-bit color sprites: black,grey,white,transparent or black, dark grey,light grey,white. I don't know if this has been asked before, custom size sprites?
Title: Re: Features Wishlist
Post by: Happybobjr on March 16, 2011, 10:43:54 pm
I would like to be able to have more buffer control.

Such as having "appvarScreen" be able to be displayed on the screen (without messing with L3 or L6)
Have monochrome display where both buffers are drawn. (allows masking and other things)
Possible more lvl's of gray where you could use Dispgraph( A , L3, L6 )  where A is pointing to something in the ram.  Or could that be an axiom?
thepenguin77's perfect grayscale (http://ourl.ca/9538) tutorial brings up a good request: changing the display routines to advance in rows instead of in columns. Although this would possibly slow the routines down a bit, even without perfect crystal timer synchronization, this should make the grayscale look better.
My calculator, and one of my friend's calc (ti-84+ and 84+SE) still cant handle 4 lvl grayscale (and 3 has problems too)  So maybe this could allow all users to have better displaying and slow it down enough to work on some calcs (Types L and M that I have seen)

Thank you for your time.
As a side note, the calc's that I have seen fail with the Gray, also have problems linking together (probably coincidence)
Title: Re: Features Wishlist
Post by: calcdude84se on March 16, 2011, 10:59:57 pm
Such as having "appvarScreen" be able to be displayed on the screen (without messing with L3 or L6)
We have "BUFFER->DispGraph" :) No greyscale, though, for that.
Title: Re: Features Wishlist
Post by: Happybobjr on March 16, 2011, 11:06:26 pm
Such as having "appvarScreen" be able to be displayed on the screen (without messing with L3 or L6)
We have "BUFFER->DispGraph" :) No greyscale, though, for that.
isn't that the same as Buffer->(l3 or L6 not sure) then display graph?
Title: Re: Features Wishlist
Post by: Compynerd255 on March 17, 2011, 10:30:14 am
Such as having "appvarScreen" be able to be displayed on the screen (without messing with L3 or L6)
We have "BUFFER->DispGraph" :) No greyscale, though, for that.
isn't that the same as Buffer->(l3 or L6 not sure) then display graph?
But that destroys L3 and L6. However, as a caveat, you should use an arbitrary buffer as a backup storage, and L3 and L6 as more active drawing space.
Title: Re: Features Wishlist
Post by: Freyaday on March 17, 2011, 01:24:03 pm
No, BUFFER->DispGraph doesn't work anymore. Speaking of which:
BUFFER->DispGraph
Title: Re: Features Wishlist
Post by: Ashbad on March 17, 2011, 01:27:16 pm
I'm not sure if this is done yet, but it would be nice if axioms who take control of unused system tokens can change their names in the editor, kinda like how Axe changes tokens like Plot1( to Pt-Mask(.

That would be useful to me greatly, and many other Axiom developers.
Title: Re: Features Wishlist
Post by: ztrumpet on March 17, 2011, 05:56:42 pm
My calculator, and one of my friend's calc (ti-84+ and 84+SE) still cant handle 4 lvl grayscale (and 3 has problems too)  So maybe this could allow all users to have better displaying and slow it down enough to work on some calcs (Types L and M that I have seen)

Thank you for your time.
As a side note, the calc's that I have seen fail with the Gray, also have problems linking together (probably coincidence)
Mine's an 'M' and it doesn't have the greyscale or linking problems. ;)
Title: Re: Features Wishlist
Post by: Happybobjr on March 20, 2011, 01:52:52 pm
Auto power down in program option?
Title: Re: Features Wishlist
Post by: Runer112 on March 20, 2011, 02:23:09 pm
APD only works in situations when the OS is in control, so you can't just insert APD into an assembly program. If the assembly program calls a bcall that waits though, like _getkey or _GetStringInput, APD can activate during that.
Title: Re: Features Wishlist
Post by: Darl181 on March 20, 2011, 05:17:30 pm
Someone should probably make a list of some sort of all these requests, it's hard to tell what's added and what's not, also some things get kind of buried and not found :P
Title: Re: Features Wishlist
Post by: Deep Toaster on March 20, 2011, 07:09:00 pm
I'm not sure if this is done yet, but it would be nice if axioms who take control of unused system tokens can change their names in the editor, kinda like how Axe changes tokens like Plot1( to Pt-Mask(.

It's been suggested before. I think people said that would slow down the editor too much (it's already scrolling much slower than usual).
Title: Re: Features Wishlist
Post by: Runer112 on March 20, 2011, 07:13:53 pm
I'm not sure if this is done yet, but it would be nice if axioms who take control of unused system tokens can change their names in the editor, kinda like how Axe changes tokens like Plot1( to Pt-Mask(.

It's been suggested before. I think people said that would slow down the editor too much (it's already scrolling much slower than usual).

I think it would hardly slow down the editor any more than Axe already slows it down, if done right. By this, I mean searching the file for Axioms and loading all the token replacements before editing so none of it has to be done on the fly.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 20, 2011, 07:25:40 pm
From the past five pages (in reverse order):


I took out some unrelated parts of each post, so if any of them sound weird, that's why :)
Title: Re: Features Wishlist
Post by: Darl181 on March 20, 2011, 07:49:30 pm
Starting from really far back...
Quigibo: if possible can axe eventually have a Select/Switch case structure?  Y'know like in C/C++/Java/all that good stuffz
Maybe like:
Code: (POSSIBLE AXE SWITCH FORMAT) [Select]
Switch(X)
Case 1
1->Y
Case 2
3->Z
Case 5
X-Z->Y
Case Else
Sin(Cos(Sin(Cos(X))))->Y
End
the ability to retrieve the address of our labels.
How about using the L token?  Like LLB?A to store the address of label LB to A.
How about a command like TI Basic's Stop.  More info here: http://ourl.ca/8403/169341
An "Exit" command. ;D
When we go in compilation menu, it could be nice to put the last source compiled at the beginning of the list. What do you think ?
2. Did anyone ever request a Axe( command?
3. Are there special getkeys for stuff like 2ND+MODE, or do we have to set a variable when 2ND is pressed?.
A switch statement for generating optimized assembly using vector tables would be very used, indeed.
Trinary operators! :D It would work great in Axe since it relies so heavily on HL. Not sure if it's too late to suggest something so big, though.
alternate steps for For() loops, the same way it is in BASIC?
Can the instant goto be made compatible with CalcUtil's "save screen" option?
The save screen is when you quit out of the program editor it asks if you want to save changes or not, very useful :) but it causes crashes with axe :P
Quigibo, if you are implementing Switch statements, can you include support for Strings?
While we're at it.. I also suggest adding optimized string comparison functions :)
An option to disable the token swaps when editing source.
a Symbol Table. In other words, I want to define memory locations other than L1-L6 as alpha-numeric symbols. For example, this:
Code: [Select]
GetCalc(Str1, 768) -> {L1+700}r
...code...
Pt-Off(2,5,Pic1)->{L1+700}r
Copy(L6, {L1+700}r, 768
becomes this:
Code: [Select]
#Define(BUF,L1+700
GetCalc(Str1, 768) -> BUF
...code...
Pt-Off(2,5,Pic1)->BUF
Copy(L6,BUF,768)
ASM programmers can do this, so why can't we?
First that the Axe-specific entries in the catalog are implemented in the alphabetical order, so that tey're more easy to find.
And second a option to compile a progam directly using a menu entry for example in the program menu.
maybe a possible Lite-Axe program that compiles very simple programs on the fly O.o
I think it would be cool if someone made an app kind of like TI 83 Plus Catalog Help, except with Axe commands instead of TI-Basic.
4*4 sprites.  Instead of it always having to be 8*8 and doing, say, [F09090F000000000], something like [F99F] would be just a square, and only a square.
I still want 8*y sprites that can be any height sometime. ;D  For instance, 8*4...
Changing some of the drawing commands so that they work with the back-buffer/arbitrary buffers, like Text() and Circle().
some sort of sign function that would return the sign (65535, 0, or 1) of a number? Too bad sign{} is already in use though...
maybe a Vertical +2 using a number to tell the parser how many pixels to shift?
Drawing to an arbitrary buffer would be really useful IMO.
Pixel testing an arbitrary buffer would also be fantastic.
A Bitmap( command that draws to the buffer, and a Pt-Mask command with custom height and width, for example Pt-Mask(xpos,ypos,hex,height, width)
(cursive is optional argument)
I would also like to be able to read/write to bits instead of just bytes and nibbles. 

Like previous post, edited out some extra stuff in posts
Title: Re: Features Wishlist
Post by: jnesselr on March 20, 2011, 07:52:12 pm
woot, I got quoted!  Nicely done, DeepThought.
Title: Re: Features Wishlist
Post by: ztrumpet on March 20, 2011, 08:07:58 pm
Darl got ninja'd. :(
Thanks, Darl and Deep. :)
Title: Re: Features Wishlist
Post by: Darl181 on March 20, 2011, 08:11:09 pm
I added more stuff to the list, up to before page 126.  Lots of stuff that's not in the last five pages :P
I was looking for when axe 050 was released, but there's stuff before that as well

EDIT: there's a routine index, maybe there could be an index for this?
Title: Re: Features Wishlist
Post by: Camdenmil on March 20, 2011, 09:46:15 pm
I don't know if this has been suggested already, but a way to easily AND sprites to a buffer?
Title: Re: Features Wishlist
Post by: Binder News on March 20, 2011, 10:21:43 pm
@Camdenmil: That's what Pt-Off does.
Title: Re: Features Wishlist
Post by: Builderboy on March 20, 2011, 10:37:12 pm
Pt-Off overwrites the whole screen, it doesn't AND
Title: Re: Features Wishlist
Post by: ztrumpet on March 20, 2011, 10:40:01 pm
Pt-On() should AND the sprite on the buffer. ;)
Title: Re: Features Wishlist
Post by: Builderboy on March 20, 2011, 10:41:20 pm
Methinks that would make a lot of incompatibility :P
Title: Re: Features Wishlist
Post by: ztrumpet on March 20, 2011, 10:44:13 pm
Isn't that what it already does?
Title: Re: Features Wishlist
Post by: Builderboy on March 20, 2011, 10:57:02 pm
Nothing does AND right now, Pt-On does OR ;)
Title: Re: Features Wishlist
Post by: Binder News on March 20, 2011, 11:12:53 pm
Oops, I thought it did AND. Well, you learn something new every day.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 21, 2011, 10:40:00 am
Oops, I thought it did AND. Well, you learn something new every day.

If it did AND, it would erase pixels, not add them.

I added more stuff to the list, up to before page 126.  Lots of stuff that's not in the last five pages :P
I was looking for when axe 050 was released, but there's stuff before that as well

EDIT: there's a routine index, maybe there could be an index for this?

I think we should have a little list in the first post of this thread, kind of like the Bug Reports thread (except that that hasn't been updated in a while). If Quigibo wants I can keep it updated :D

woot, I got quoted!  Nicely done, DeepThought.

Quoted again. Happy?
Title: Re: Features Wishlist
Post by: jnesselr on March 21, 2011, 11:59:28 am
woot, I got quoted!  Nicely done, DeepThought.
Quoted again. Happy?
Very.
Title: Re: Features Wishlist
Post by: ztrumpet on March 21, 2011, 03:57:00 pm
Nothing does AND right now, Pt-On does OR ;)
* ZTrumpet stabs ZTrumpet.   :-[

Whoops.  Thanks for pointing out my mistake.  I really should think more when I'm posting at 10:45 PM. :P



woot, I got quoted!  Nicely done, DeepThought.
Quoted again. Happy?
Very.
Ecstatic?
Title: Re: Features Wishlist
Post by: jnesselr on March 21, 2011, 04:12:54 pm
woot, I got quoted!  Nicely done, DeepThought.
Quoted again. Happy?
Very.
Ecstatic?
Of course, now that Ztrumpet quoted me too.  :thumbsup:
Title: Re: Features Wishlist
Post by: Builderboy on March 22, 2011, 11:33:24 am
Axe puts its own routines after the data, so things still get run at the very end.

Methinks this would be a good thing to change in Axe!  That way we can have larger programs that bypass the limit :)
Title: Re: Features Wishlist
Post by: Deep Toaster on March 22, 2011, 12:35:22 pm
And I just realized something:

Nothing does AND right now, Pt-On does OR ;)

I second (or whatever) this. I really need it now O.O
Title: Re: Features Wishlist
Post by: Builderboy on March 22, 2011, 03:34:32 pm
You can do the equivalent of AND with an OR and an XOR with an inverted sprite mask if you absolutely need it.  Quigibo is out of sprite tokens so I don't know if he is planning on adding it any time soon D:
Title: Re: Features Wishlist
Post by: Happybobjr on March 22, 2011, 03:36:39 pm
when would you need it?
Title: Re: Features Wishlist
Post by: Deep Toaster on March 22, 2011, 03:44:51 pm
when would you need it?

Dark background.
Title: Re: Features Wishlist
Post by: Camdenmil on March 22, 2011, 07:22:57 pm
You can do the equivalent of AND with an OR and an XOR with an inverted sprite mask if you absolutely need it.  Quigibo is out of sprite tokens so I don't know if he is planning on adding it any time soon D:

That's how I'm doing it now, but I'd imagine a Pt-And routine would be faster.
Title: Re: Features Wishlist
Post by: Ashbad on March 22, 2011, 07:31:14 pm
It might be a little faster, but to tell the truth, not by much -- the assembly version would still have to do the AND/OR/XOR/NOT operations anyways, even if they might be a little smaller and faster.  If you need however, I can maybe write a lightweight axiom that would have a modification of the pt-on( command that would do a masking operation -- I actually think it wouldn't be that big of a operation.

I can write that for you tomorrow if you like -- though I'm sure someone like Sir will rush in and write it before I do ;)
Title: Re: Features Wishlist
Post by: calcdude84se on March 22, 2011, 07:50:47 pm
It would actually be decently faster (at least twice as much). You'd only be drawing the sprite once, instead of however many times are needed to use only OR and XOR. ;)
But yeah, we are kinda short on tokens :(
Title: Re: Features Wishlist
Post by: ztrumpet on March 22, 2011, 08:14:57 pm
There's always the Plot tokens. ;)
Title: Re: Features Wishlist
Post by: Ashbad on March 22, 2011, 09:01:36 pm
Plot2 and Plot3 are open.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 22, 2011, 11:14:15 pm
It might be a little faster, but to tell the truth, not by much -- the assembly version would still have to do the AND/OR/XOR/NOT operations anyways, even if they might be a little smaller and faster.  If you need however, I can maybe write a lightweight axiom that would have a modification of the pt-on( command that would do a masking operation -- I actually think it wouldn't be that big of a operation.

It would be exactly twice as fast, since you're doing one AND routine instead of a combination of OR and then XOR.

EDIT: Ninja'd by four hours :P
Title: Re: Features Wishlist
Post by: z80man on March 23, 2011, 03:14:20 am
I just had this one idea. In asm when interfacing with the keyboard you have to set one group of keys to check for input at a time. Now currently on Axe, the Getkey routine scans all of the keyboard groups then reports the input. My idea was to be able to specify only one group (or specific groups) to scan. Such as the arrow key group for example. reason being is that in most games only a limited number of keys are used so it would be an optimization to only scan certain groups.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 23, 2011, 06:26:53 am
getKey actually uses the OS's built-in _GetCSC bcall, so Axe would have to add an entire key scanning routine to make that work.
Title: Re: Features Wishlist
Post by: aeTIos on March 23, 2011, 06:28:25 am
is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)
Title: Re: Features Wishlist
Post by: Freyaday on March 23, 2011, 12:35:12 pm
is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)

Code: [Select]
:If getkey(54) and (getkey(47)
stuff
:End
Also, be aware that if waiting for a keypress with a loop, only getkey(0) will allow for multikeypress detection later on. For whatever reason, just getkey doesn't, even if the keys are being tested later in in the program with their own getkey(whatever). I don't know why.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 23, 2011, 12:43:57 pm
is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)

Code: [Select]
:If getkey(54) and (getkey(47)
stuff
:End

He meant pressing 2nd, then MATH, like you do in the OS. A way to do bcall(_getKey) is

Code: (Axe) [Select]
Asm(EF724926006F)
It involves a whole other key system though.
Title: Re: Features Wishlist
Post by: Darl181 on March 23, 2011, 08:56:01 pm
New request:
[hex goes here]→Pic1
FlipV(Pic1)→Pic2
RotC(Pic2)→Pic3
The ability to do stuff like that.
Title: Re: Features Wishlist
Post by: calc84maniac on March 24, 2011, 04:10:38 am
Copy(FlipV(Pic1),Pic2,8)
Copy(RotC(Pic2),Pic3,8)

Of course, Pic2 and Pic3 have to be defined and 8 bytes large
Title: Re: Features Wishlist
Post by: aeTIos on March 24, 2011, 05:38:32 am
is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)

Code: [Select]
:If getkey(54) and (getkey(47)
stuff
:End

He meant pressing 2nd, then MATH, like you do in the OS. A way to do bcall(_getKey) is

Code: (Axe) [Select]
Asm(EF724926006F)
It involves a whole other key system though.
Yes, I know. I dont know how to read register A with Axe, though...
Title: Re: Features Wishlist
Post by: Compynerd255 on March 24, 2011, 10:26:35 am
Copy(FlipV(Pic1),Pic2,8)
Copy(RotC(Pic2),Pic3,8)

Of course, Pic2 and Pic3 have to be defined and 8 bytes large
When you do this, if your game has an appvar save file, you should have an "Initialized" variable in it or compare it with a version number to make sure the game only does this once (to prevent it from writing back and wearing down your archive).
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 10:47:42 am
For any and all drawing commands, command()rr to perform the command on both buffers. (L3 and L6)

A way to manipulate individual bits.

And Try/Catch
Title: Re: Features Wishlist
Post by: Deep Toaster on March 24, 2011, 10:51:54 am
And Try/Catch

The OS doesn't throw enough errors for that to be useful, though.

And when it does error, it's usually a RAM clear. You can't really stop that, unless you're willing to operate your calc with corrupted system RAM.

is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)

Code: [Select]
:If getkey(54) and (getkey(47)
stuff
:End

He meant pressing 2nd, then MATH, like you do in the OS. A way to do bcall(_getKey) is

Code: (Axe) [Select]
Asm(EF724926006F)
It involves a whole other key system though.
Yes, I know. I dont know how to read register A with Axe, though...

Just use that code I gave you. It loads A into HL so you can use it ;)
Title: Re: Features Wishlist
Post by: SirCmpwn on March 24, 2011, 10:54:01 am
Persistent interrupts would be very cool.  Also, try/catch requires OS level support, which isn't there.  Wait for KnightOS.
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 10:56:07 am
Stateful ComeFrom and multitasking.
Title: Re: Features Wishlist
Post by: Xeda112358 on March 24, 2011, 10:59:09 am
Multitasking would be difficult on a Z80... It can be done, but it would be slow and running two tasks would be slower than running each one separately :D
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 10:59:47 am
It would be that slow? Aww, man!
Title: Re: Features Wishlist
Post by: Deep Toaster on March 24, 2011, 11:00:28 am
comeFrom might actually be possible, but we can't even access the current pointer right now.

So as a bump for a feature request: Getting PC (or at least the pointer to a label).

It would be that slow? Aww, man!

Multitasking is always slower than two tasks independently. You can't just make a processor suddenly divide into two or something.

And as a reminder, make sure feature requests are things you're actually going to use, not just things that sound cool ;)
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 11:03:30 am
I would use a stateful ComeFrom, actually. What the stateful means is that it's actually a conditional, so when the argument becomes true, control flow leaps to the ComeFrom from wherever it was in the program.
Title: Re: Features Wishlist
Post by: Xeda112358 on March 24, 2011, 11:04:43 am
Yeah, the Z80 wasn't designed for multitasking and personally I am glad about that :D The closest you can come to that is using an interrupt. It might be cool to make an interrupt that interprets code like a BASIC language while executing assembly, but the thing is interrupts will slow down your regular code (though it isn't usually noticeable). For example, if your interrupt took 1/220th of a second to run, that would mean that your regular code ran at half of its max speed, I believe.
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 11:06:28 am
Oh. Now if only we had multiple processors....
Title: Re: Features Wishlist
Post by: Deep Toaster on March 24, 2011, 11:13:02 am
Oh. Now if only we had multiple processors....

...which would make assembly and Axe that much more confusing :D
Title: Re: Features Wishlist
Post by: Freyaday on March 24, 2011, 11:59:39 am
But oh so much more fun.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 25, 2011, 03:29:53 am
My spring break is next week.  I will finally have time to pick this project up again so expect an update in about a week.  I know there have been a lot of bugs/feature requests recently that I've probably forgot about or missed, I will try to reread most of the features wishlist, bug reports, and optimization threads on Friday so if there are any other important things you feel I should do not already mentioned in those threads, now would be a good time to bring them up there.
I'm glad to hear. Good luck :D
Title: Re: Features Wishlist
Post by: ZippyDee on March 25, 2011, 03:53:39 am
How about a way to send a byte directly to the LCD?
Title: Re: Features Wishlist
Post by: Happybobjr on March 25, 2011, 08:32:13 am
the lcd updates all at once by reading a section of memory.  To send a byte to the  lcd you would do...
Code: [Select]
:(0-255) -> {L6+(0-767)}
:dispgraph


The parentheses represent number choices.
L6 is the location in the Free Ram in which the lcd reads from.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 25, 2011, 09:35:46 am
That isn't actually the case.  The LCD has its own internal memory, which stores the contents.  DispGraph copies the buffer to the LCDs internal memory.  Bitmap(, for example, can optionally copy straight to the screen.
Title: Re: Features Wishlist
Post by: AngelFish on March 25, 2011, 10:10:12 am
A way to manipulate individual bits.

And Try/Catch

Use the logical functions to manipulate individual bits, since that's essentially the only way to do it at the Assembly level too.

But I'm curious as to what types of exceptions you'd be catching, since there aren't really a whole lot of errors you can recover from on a z80 calc.

You can't just make a processor suddenly divide into two or something.

I think the iPhone has an app for that...
Title: Re: Features Wishlist
Post by: Freyaday on March 25, 2011, 10:42:36 am
A way to manipulate individual bits.

And Try/Catch

Use the logical functions to manipulate individual bits, since that's essentially the only way to do it at the Assembly level too.

But I'm curious as to what types of exceptions you'd be catching, since there aren't really a whole lot of errors you can recover from on a z80 calc.

You can't just make a processor suddenly divide into two or something.

I think the iPhone has an app for that...
I wasn't entirely serious with the try/catch. I just wanted to see if it was possible. But as it stands, the only single bit manipulation tools we have are the pxl- commands, and I can't get those to work on anything but the front/back buffers.
Title: Re: Features Wishlist
Post by: AngelFish on March 25, 2011, 11:09:51 am
That's because you're using the wrong commands  ;)
The pxl commands are basically just specific applications of bitwise operations with some special case handling built in to deal with operating across bytes. Try using the AND, OR, and NOT commands available through 2nd+Math->Logic instead of those.

Bitwise operations (http://en.wikipedia.org/wiki/Bitwise_operation)
Title: Re: Features Wishlist
Post by: Freyaday on March 25, 2011, 11:12:43 am
No, the bits, not the bytes.
Title: Re: Features Wishlist
Post by: AngelFish on March 25, 2011, 11:19:52 am
Freyaday, there is no processor command to manipulate individual bits. You have to do it with logical operations. For example, if you want to change the bit three in the byte 1011 0010 to a one (say this is the value in variable A), then you would do A OR B, where B is 0000 0100. This will change the individual bit. That is how you do these things at the assembly level. There simply is no other [efficient] way to change individual bits in arbitrary memory locations, unless I'm sorely mistaken about microprocessor design.
Title: Re: Features Wishlist
Post by: Freyaday on March 25, 2011, 11:32:34 am
I didn't know! But then isn't that what the pxl-commands do? Could it be possible to rejigger them to accept locations outside of L3 and L6?
Title: Re: Features Wishlist
Post by: Builderboy on March 25, 2011, 11:40:13 am
Freyaday, there is no processor command to manipulate individual bits. You have to do it with logical operations.

There are actually commands built in to set and reset bits. They are aptly names SET (to set bits) and RES (to reset bits) :)
Title: Re: Features Wishlist
Post by: Freyaday on March 25, 2011, 11:43:52 am
So, does this mean single bit manipulation is a possible feature?
Title: Re: Features Wishlist
Post by: Builderboy on March 25, 2011, 11:48:43 am
Yes it does i hope.  And if you are setting a constant bit and not a variable, the bit setting routine can be auto optimized to take up 4 bytes methinks.

Ld HL,adress
SET/RES #,(HL)
Title: Re: Features Wishlist
Post by: Deep Toaster on March 25, 2011, 12:57:29 pm
I didn't know! But then isn't that what the pxl-commands do? Could it be possible to rejigger them to accept locations outside of L3 and L6?

Those actually use bitmasking because it's better to use when the location isn't constant. But as Builderboy said, it is possible to set individual bits, but it's better only in certain conditions.
Title: Re: Features Wishlist
Post by: AngelFish on March 25, 2011, 03:06:32 pm
Yes it does i hope.  And if you are setting a constant bit and not a variable, the bit setting routine can be auto optimized to take up 4 bytes methinks.

Ld HL,adress
SET/RES #,(HL)

O.o
/me feels stupid for forgetting that the z80 is CISC and thinking that it didn't have the ability to explicitly set bits
Title: Re: Features Wishlist
Post by: ZippyDee on March 25, 2011, 05:42:07 pm
That isn't actually the case.  The LCD has its own internal memory, which stores the contents.  DispGraph copies the buffer to the LCDs internal memory.  Bitmap(, for example, can optionally copy straight to the screen.

Yes, dispgraph reads from the buffer, so a way to write directly to the LCD would be nice. Is Bitmap( the only way to do that right now?

EDIT: Another idea is to have a way to jump to program source from the axe compile menu. I have a lot of programs, so would faster to go through the axe menu to open up my axe programs for editing.
Title: Re: Features Wishlist
Post by: Compynerd255 on March 25, 2011, 06:53:40 pm
EDIT: Another idea is to have a way to jump to program source from the axe compile menu. I have a lot of programs, so would faster to go through the axe menu to open up my axe programs for editing.
Maybe, when you click on the source program using [X,T, theta, n], you would be given a list of labels in the program, and you could quickly jump to one of those labels in the source (like we do with error handling).

I also have another request: See all the errors in the program, not just the first one. Basically, what would happen is that when the compiler hit an error, the program would not compile, but would still go through the code as if it were compiling, looking for other errors. Then, when all was said and done, you can choose one of the errors to scroll to. This would be useful because one error might be the cause of several dozen or something like that. If this creates too much overhead, then it would be nice to have the compiler give you a choice of quitting, scrolling to the error, or running through the source to the next error.
Title: Re: Features Wishlist
Post by: calc84maniac on March 25, 2011, 09:18:53 pm
Yes it does i hope.  And if you are setting a constant bit and not a variable, the bit setting routine can be auto optimized to take up 4 bytes methinks.

Ld HL,adress
SET/RES #,(HL)
Actually, that's 5 bytes (set/res are 2-byte instructions). But if this gets implemented, there should be inc/dec as well I think :P
Title: Re: Features Wishlist
Post by: Builderboy on March 26, 2011, 01:51:50 am
Oh i wasn't aware Ld HL, address was 3 bytes D: hah thats why I'm not an asm programmer :P
Title: Re: Features Wishlist
Post by: ZippyDee on March 26, 2011, 05:09:17 am
Yes it does i hope.  And if you are setting a constant bit and not a variable, the bit setting routine can be auto optimized to take up 4 bytes methinks.

Ld HL,adress
SET/RES #,(HL)
Actually, that's 5 bytes (set/res are 2-byte instructions). But if this gets implemented, there should be inc/dec as well I think :P

Both SET/RES and INC/DEC would be incredibly useful. I'm working on a sprite editor, and it certainly is annoying to have to turn all the bits on and off using individual bitmasks.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 26, 2011, 11:12:36 am
Oh i wasn't aware Ld HL, address was 3 bytes D: hah thats why I'm not an asm programmer :P

Addresses are two bytes ;)
Title: Re: Features Wishlist
Post by: Builderboy on March 26, 2011, 11:17:52 am
Yep i forgot :P
Title: Re: Features Wishlist
Post by: squidgetx on March 27, 2011, 03:56:02 pm
Request:

Option to read nibbles the opposite direction (little endian vs big-endian)

And yes I actually need this...I'm still using .4.8 since it got switched in .5.0 :(
Title: Re: Features Wishlist
Post by: Freyaday on March 27, 2011, 04:29:52 pm
Change the way the >Char command works so that Output(0,0,[7C5C2F7C5C2F7C3ECC12]>Char
Prints
|\/|\/|><[
 instead of a dieresis.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 27, 2011, 04:31:52 pm
I like how the shell/no-stub/app is now displayed in the compile menu. Sometimes I accidentally compiled to the wrong shell because I forgot to change it.

Also, smally typo in the help menu: It's axe.omnimaga.org, not www.axe.omnimaga.org. ;)

EDIT: Wow Supersonic Ball code still works in 0.5.1 O.O
Title: Re: Features Wishlist
Post by: Camdenmil on March 27, 2011, 04:52:54 pm
Request:
Invert and/or white line. I've needed to draw white lines before and there's no easy way to do it.
Title: Re: Features Wishlist
Post by: Deep Toaster on March 27, 2011, 08:14:43 pm
Change the way the >Char command works so that Output(0,0,[7C5C2F7C5C2F7C3ECC12]>Char
Prints
|\/|\/|><[
 instead of a dieresis.

Doesn't Output(0,0,[7C5C2F7C5C2F7C3ECC1200]) work?
Title: Re: Features Wishlist
Post by: Yeong on March 27, 2011, 09:26:41 pm
Request: idk if I posted this already, but...
Stereo sound support.
I heard that it's possible with ASM...
Title: Re: Features Wishlist
Post by: Freyaday on March 27, 2011, 11:41:56 pm
Circle()r
And while I'm at it, Circle()rr
Title: Re: Features Wishlist
Post by: SirCmpwn on March 27, 2011, 11:53:03 pm
Some way of specifying the shell in the header would be great.  I often screw up the shell choice because I so quickly switch between different programs targeting different shells.  Perhaps the second line could contain a comment that would specify this, optionally?
Also, I'm again pushing the request through for getting the address of a label.
Title: Re: Features Wishlist
Post by: AngelFish on March 27, 2011, 11:58:25 pm
What about a buffer swap command instead of implementing bunch of <command>r's?
Title: Re: Features Wishlist
Post by: Freyaday on March 27, 2011, 11:59:56 pm
Stateful Goto
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 12:56:37 am
Circle()r
And while I'm at it, Circle()rr
Circlerr? What would that do?
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 01:15:19 am
Following suit to one of my previous wishes, that would draw a circle on both buffers.
Also, flickerless greyscale. And the current dark grey is too dark and light grey is too light.
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 01:18:27 am
If you had Circler you could draw a circle on both buffers...
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 01:29:36 am
Yeah, but Circle()rr would draw on both. At the same time.
Also, four-argument For() loops: var, start, end, increment and negative increments are allowed. Also, recoding RectI() to work with negative lengths, and removing the space after DrawInv.
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 01:30:32 am
yeah clipping for lines/rectangles would be nice.
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 01:36:11 am
Well, for negative lengths, the rectangle should go up/left, depending on which length/s is/are negative. Oh, and a paint bucket.
Title: Re: Features Wishlist
Post by: Builderboy on March 28, 2011, 01:46:35 am
paint bucket.

That sounds like an excellent candidate for an Axiom :) remember, the Axiom system was added specifically so that Quigibo wouldn't have to add every single command himself and keep managing all of the subroutines. 

Also, I second the conditional goto, as well as the shell specification in an optional header, which would override the current setting in the Axe options.
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 02:36:35 am
Actually, I think the term is Argumentative Goto, 'cause it'd take an argument instead of a label. :)
But seriously, if y'all have in mind the same thing I do, the result would be akin to a switch statement, but orders of magnitude more powerful.
Title: Re: Features Wishlist
Post by: Builderboy on March 28, 2011, 03:17:02 am
Hmmm how precisely would it work and how would it be more powerful than a switch statement?
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 03:36:12 am
:Goto Str0
Where it uses whatever the string is at Str0 as the label and
:Goto Str0r
Which would evaluate Str0 as an expression and go to a numerical label (or perhaps to an address...)
Title: Re: Features Wishlist
Post by: Builderboy on March 28, 2011, 03:47:14 am
note that since labels are not stored in the program, that would add 5 bytes for each label that exists in the program at the very least, 3 for the name and 2 for the address, and it would have to search through all the possible names looking for a match, and then jump to that address.
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 05:30:09 am
By "paint bucket" I assume you mean a floodfill of some sort, no? Here's how I think would make the most sense:
Code: [Select]
FloodFill(X,Y)    //X and Y are the coordinates of the pixel to start filling fromOnly two arguments are necessary, because it would always invert the color. Floodfilling the current color on top of itself would do nothing.
Title: Re: Features Wishlist
Post by: SirCmpwn on March 28, 2011, 08:54:18 am
I once wrote a flood fill routine, look around for it on Omnimaga.
Title: Re: Features Wishlist
Post by: Munchor on March 28, 2011, 08:56:03 am
Also, how to make a empty rectangle? We can do it with four lines, but could there be a RectI(0,10,20,30 (rect inverted). Or is there any other way to do it?
Title: Re: Features Wishlist
Post by: Fast Crash on March 28, 2011, 10:08:39 am
Code: [Select]
Rect(X,Y,W,H)
RectI(X+1,Y+1,W-2,H-2)

That's what i use.
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 11:06:21 am
What about a greyscale paint bucket?
Title: Re: Features Wishlist
Post by: squidgetx on March 28, 2011, 03:36:48 pm
SirC's flood-filler would probably be easily modifiable to make grayscale.

IIRC the Circle() routines are coded in such a way that it is very difficult to make it draw on the back buffer.

For For() loops, just use a While loop instead and increment manually, it probably is just as optimized anyway.

As for the flickering on the grayscale, I think Deep Thought already mentioned going across the screen by rows instead of columns as per thepenguin77s grayscale tutorial, so I'll just remention that again ;)

And now I have something I want to say...
People, this has kind of been bugging me. Feature-request-wise, remember that Quigibo is really busy. Complex routines are hard to put in, and most of the time they can easily be written in Axe anyway with a few commands (like the for() and the paint bucket thing). Figure out how to do it yourself; don't just ask for a feature request because you don't want to take the time to code your own routines. Another example: grayscale. Are you really complaining that the shades of gray are too dark/light? It's freaking grayscale on a monochrome screen. Seriously, any asm programmer will tell you that grayscale is a huge pain to program correctly and IMHO we should be grateful that we have it as good as it is. I'm talking to everybody here. I feel like some people are taking Quigibo for granted, and imo something like a paint bucket is in no way really important enough to merit its own command. Something like bit-manipulation, label-addresses or switch-statements or big-endian nibble reads hint hint hint are more appropriate candidates for feature requests. And did someone really ask for multitasking?

I guess what I'm really trying to say, is just try and think about what you are asking for before you post, and whether or not it's practical. Then think about how you could code it; a lot of things are not difficult to code by hand anyway. Some languages don't even have for() loops, for example. And when you do post, try to explain what you are talking about. Not everyone knows what the phrase "stateful goto" or "try/catch" means.

Sorry to rage like this but I felt the need to say it. No offense to anyone intended. :) Also I do not want to start any kind of war or fight so if you have a problem with this, rate it down and pm me. Leave it off the forums, thanks  :)
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 03:48:52 pm
You're right, squidgetx. We need to start thinking realistically here... And for many routines (such as floodfill), writing an Axiom would be the perfect solution. Then it can even have its own command if needed without stressing quigibo
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 04:01:00 pm
My bad. I now resolve to be more explanatory/serious in the future.
Title: Re: Features Wishlist
Post by: ztrumpet on March 28, 2011, 04:20:27 pm
Also, I'm again pushing the request through for getting the address of a label.
I really like this idea too. :)

What about a buffer swap command instead of implementing bunch of <command>r's?
You could just use Exch(L3,L6,768) for this. ;)
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 04:23:09 pm
What about a buffer swap command instead of implementing bunch of <command>r's?
You could just use Exch(L3,L6,768) for this. ;)
I had forgotten about Exch(. This certainly makes my programs smaller.
Title: Re: Features Wishlist
Post by: Ashbad on March 28, 2011, 05:14:55 pm
... And did someone really ask for multitasking?

O.o

That and paint bucket commands... lol.  I can just say lol.

Indeed people -- if you really want these routines fixed to your expectations, get an assembler and write up an axiom!  Squidget is right, some of these requests are a bit... farfetch'd.  However, there are some things which must be included into the actual compiler -- reading label addresses is pretty much impossible in an axiom, but quigibo is probably adding them anyways, once he figures out a nice and optimized way to do so ;)

EDIT: and also, freyaday, if you want better grayscale, you can write an axiom that changes the 11011011b and 00100100b scanlines to 11110011b and 00001100b ones ;)
Title: Re: Features Wishlist
Post by: Quigibo on March 28, 2011, 06:46:09 pm
Speaking of which, I think it is now time to start an "Axiom Request" thread for requests such as the paint bucket, which legitimately would be a lot better as an assembly command, but wouldn't be used enough to justify being part of the standard language.  It would also be a good to keep a list of Axioms created so far so people have access to those.

The highest priority requests to me right now are actual features of the compiler, user interface improvements, and language control features.  Commands are low priority right now unless they are absolutely essential or super easy to implement since this is what Axioms are for.
Title: Re: Features Wishlist
Post by: Freyaday on March 28, 2011, 07:36:02 pm
Oh, Returning the program file to existence before Archiveing the backup, and letting the parser recognize (and perhaps automatically Archive) backups that are in RAM.
Title: Re: Features Wishlist
Post by: ZippyDee on March 28, 2011, 08:05:37 pm
I still think a "jump to label" from the compile menu would be a handy feature. Maybe like pressing PRGM in the compile menu would display a list of the labels in the program and allow you to quickly jump to a label in your program. It would be much faster than going through the actual PRGM menu and having to scroll through and find the section of code you want to look at. I know this wouldn't be an incredibly necessary feature, just a convenience thing...And it certainly shouldn't be a priority over other features that actually improve the Axe language :P
Title: Re: Features Wishlist
Post by: Runer112 on March 29, 2011, 07:38:23 pm
The Axiom system is great. Things like automatic jump and call replacements and manual 16-bit load replacements are great, which even the hard-coded Axe commands cannot do. But there's one thing that internal Axe commands can do whereas Axioms can't that I would love to be able to do. Would it be possible to add a new internal Axiom compiler feature that allows calls to be made with offsets? Perhaps a new macro like ld b,b \ .db BYTE \ .org $-2? Because this would be incredibly useful for calling a command in slightly different ways, like you often use with an optional buffer argument for drawing commands.
Title: Re: Features Wishlist
Post by: Compynerd255 on March 30, 2011, 10:27:38 am
I have a feature request that would significantly reduce the size of Axe programs: automatically calculate constants. For example, L1+4 is a constant, but when Axe encounters it, it loads L1, then adds 4, instead of simply loading the end value. So, when Axe encounters a string of constants in the program, it actually runs through the operations of adding, subtracting, multiplying, and dividing until a variable is encountered. For example,
Code: (Axe) [Select]
{L1+5}→{L3+2}
should parse as:
Code: (ASM) [Select]
ld hl,saveScreen+5
sto hl,appBackupScreen+2
Title: Re: Features Wishlist
Post by: Deep Toaster on March 30, 2011, 12:13:35 pm
Doesn\'t it already do that? It also precalculates things like +L1-8 by adding (L1-8) together.

If it doesn\'t do this in the new version, it\'s a bug.
Title: Re: Features Wishlist
Post by: Ashbad on March 30, 2011, 01:13:24 pm
I still think a "jump to label" from the compile menu would be a handy feature. Maybe like pressing PRGM in the compile menu would display a list of the labels in the program and allow you to quickly jump to a label in your program. It would be much faster than going through the actual PRGM menu and having to scroll through and find the section of code you want to look at. I know this wouldn't be an incredibly necessary feature, just a convenience thing...And it certainly shouldn't be a priority over other features that actually improve the Axe language :P

I second that. :thumbsup:
Title: Re: Features Wishlist
Post by: Compynerd255 on March 30, 2011, 04:06:39 pm
Doesn\'t it already do that? It also precalculates things like +L1-8 by adding (L1-8) together.

If it doesn\'t do this in the new version, it\'s a bug.
I should probably look at dissassembled code before I make guesses of that. But if it doesn't have that in there, that would still be super nice.
Title: Re: Features Wishlist
Post by: Freyaday on March 30, 2011, 04:20:18 pm
DispGraphº to use SafeCopy.
Title: Re: Features Wishlist
Post by: ACagliano on April 01, 2011, 12:02:23 am
Perhaps a command to check a certain block of memory for variable bytes.

Search(PTR to start search,bytes to search for (more than one byte),number of bytes forward to search)

return 0 if not found, or offset of first result.

Ex: to clarify

in the block 013450AE2345FF000F ,

Search(PTR,[AE23],9)  returns 3
Title: Re: Features Wishlist
Post by: calc84maniac on April 01, 2011, 12:10:48 am
Perhaps a command to check a certain block of memory for variable bytes.

Search(PTR to start search,bytes to search for (more than one byte),number of bytes forward to search)

return 0 if not found, or offset of first result.

Ex: to clarify

in the block 013450AE2345FF000F ,

Search(PTR,[AE23],9)  returns 3
That can be done pretty easily in pure Axe by looping over each of the 9 bytes and using inData to check for a match each time (and that is how an assembly version would work anyway)
Title: Re: Features Wishlist
Post by: ACagliano on April 01, 2011, 12:13:39 am
inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.
Title: Re: Features Wishlist
Post by: calc84maniac on April 01, 2011, 12:21:34 am
inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.
Something like
Code: [Select]
Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
(returns -1 if failure)
Title: Re: Features Wishlist
Post by: ACagliano on April 02, 2011, 07:35:06 pm
Another one: for those of us who have assembly programs on calc that do things like invert text, invert the screen, check ram, or what not. Have a command that parses a compiled z80 executable and inserts it into the program.

command(assembly program)   ; only the source requires the program, not the executable.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 02, 2011, 09:42:48 pm
Another one: for those of us who have assembly programs on calc that do things like invert text, invert the screen, check ram, or what not. Have a command that parses a compiled z80 executable and inserts it into the program.

command(assembly program)   ; only the source requires the program, not the executable.

That would be extremely difficult because all the pointers would get thrown off (unless you put it in the very, very beginning of your Axe prgm). Anything using fixed addresses (JP, CALL, etc.) would end up where it doesn't expect it to be, which would be disastrous.

Same reason why you can't just jump straight to a different program while running a program.
Title: Re: Features Wishlist
Post by: Freyaday on April 03, 2011, 01:33:18 am
I think the string equality check command could be used to compare multiple bytes.
Title: Re: Features Wishlist
Post by: ACagliano on April 03, 2011, 12:57:34 pm
inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.
Something like
Code: [Select]
Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
(returns -1 if failure)

Calc, where do the variables here come from? Which is the search string and which is the string to search? I may use this.
Title: Re: Features Wishlist
Post by: Ashbad on April 03, 2011, 01:24:28 pm
I think the string equality check command could be used to compare multiple bytes.

actually yes, that should work -- I haven't looked at this command yet, but strings are composed of characters that have codes from 0-255, like normal data.  No idea how it handles 0's though.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 03, 2011, 01:56:02 pm
inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.
Something like
Code: [Select]
Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
(returns -1 if failure)

Calc, where do the variables here come from? Which is the search string and which is the string to search? I may use this.

r1-r6 are the subroutine arguments. For example, if you called sub(SRC,[POINTER_TO_FIRST_STRING],[POINTER_TO_SECOND_STRING],[LENGTH_OF_STRING_TO_TEST],[START_POSITION]), [POINTER_TO_FIRST_STRING] would be r1, [POINTER_TO_SECOND_STRING] would be r2, etc.
Title: Re: Features Wishlist
Post by: Freyaday on April 06, 2011, 02:27:16 am
Pt-command()º so that it wraps instead of clips.
Title: Re: Features Wishlist
Post by: ZippyDee on April 06, 2011, 02:31:20 am
It's much easier to just draw two sprites in axe than to write a new set of wrapping sprite display routines in ASM.
Title: Re: Features Wishlist
Post by: Freyaday on April 06, 2011, 02:51:23 am
Couldn't the coords just be set to be mod the screen size?
Title: Re: Features Wishlist
Post by: SirCmpwn on April 08, 2011, 05:11:37 pm
SirC's flood-filler would probably be easily modifiable to make grayscale.

IIRC the Circle() routines are coded in such a way that it is very difficult to make it draw on the back buffer.

For For() loops, just use a While loop instead and increment manually, it probably is just as optimized anyway.

As for the flickering on the grayscale, I think Deep Thought already mentioned going across the screen by rows instead of columns as per thepenguin77s grayscale tutorial, so I'll just remention that again ;)

And now I have something I want to say...
People, this has kind of been bugging me. Feature-request-wise, remember that Quigibo is really busy. Complex routines are hard to put in, and most of the time they can easily be written in Axe anyway with a few commands (like the for() and the paint bucket thing). Figure out how to do it yourself; don't just ask for a feature request because you don't want to take the time to code your own routines. Another example: grayscale. Are you really complaining that the shades of gray are too dark/light? It's freaking grayscale on a monochrome screen. Seriously, any asm programmer will tell you that grayscale is a huge pain to program correctly and IMHO we should be grateful that we have it as good as it is. I'm talking to everybody here. I feel like some people are taking Quigibo for granted, and imo something like a paint bucket is in no way really important enough to merit its own command. Something like bit-manipulation, label-addresses or switch-statements or big-endian nibble reads hint hint hint are more appropriate candidates for feature requests. And did someone really ask for multitasking?

I guess what I'm really trying to say, is just try and think about what you are asking for before you post, and whether or not it's practical. Then think about how you could code it; a lot of things are not difficult to code by hand anyway. Some languages don't even have for() loops, for example. And when you do post, try to explain what you are talking about. Not everyone knows what the phrase "stateful goto" or "try/catch" means.

Sorry to rage like this but I felt the need to say it. No offense to anyone intended. :) Also I do not want to start any kind of war or fight so if you have a problem with this, rate it down and pm me. Leave it off the forums, thanks  :)
I only ask for stuff I can't do on my own.  For example, I didn't ask for a routine to swap in an extra page of RAM, I just did it myself.  Label addresses is the only thing I'm pushing for right now, and I'm doing so because of three reasons: (1) While I can do it myself, it is a nuisance on both myself and end users, (2) I already have a significant amount of code written for the project I want this feature for, and (3) I don't think it would be very difficult to implement.

In addition, if you want a new feature, like the paint bucket, that isn't a very good candidate for an actual feature, look it up.  For example: How to make a paint bucket (http://en.wikipedia.org/wiki/Flood_fill)
Title: Re: Features Wishlist
Post by: Ashbad on April 08, 2011, 05:13:30 pm
It's much easier to just draw two sprites in axe than to write a new set of wrapping sprite display routines in ASM.

Actually the wrapping code in assembly is much smaller than the clipping code ;)
Title: Re: Features Wishlist
Post by: Quigibo on April 09, 2011, 05:15:53 am
^ Not really. Pseudo-wrapping in the horizontal direction is smaller, but its not real wrapping because the half sprite on the right side of the screen would be shifted down by one pixel and additional clipping would be needed for the last row so it wouldn't leak into memory after the screen.  This is better suited for an Axiom though since wrapping is rarely needed and can be done easily with 2 sprites.


Anyway, I came up with a new advanced syntax idea!  I was thinking of allowing programmers to take advantage of the stack the z80 offers but I'm concerned about memory leaks this could cause and undesired conflicts when calling routines since Axe uses the same stack behind the scenes.  But then I realized there is a way I could do it that would be both easy to use and be impossible to leak memory.  The solution is to:

1) Only allow the pair if they are in the same scope.  I define scope loosely... it has to fit on one line, but CAN intersect most single argument commands.
2) Require a pop for each push in that scope or else throw a syntax error.
3) Allow automatic integration into the right-hand side of binary operations.

For a non-technical explanation: Think of it as storing a value (maybe the result of a large computation) to a place you want to read later without having to use a temporary variable or do the computation again.  You can nest as many of these as you want without concern about memory.  I decided to use the pi character (π) to implement this.  Storing to it pushes the variable and reading from it pops it.

For example here is code to swap the values of 2 variables using a temporary:
Code: [Select]
A->T B->A T->BHere is the same code using the stack instead.
Code: [Select]
A->π B->A π->BSince each variable read or write is 3 bytes, but each stack read or write is only 1 byte, this code saves 4 bytes and is slightly faster.

Another example:
Code: [Select]
{A*3}->X {A*3+1}->Y {A*3+2}->ZHere is a case where you can nest them together:
Code: [Select]
{A*3->π->π}->X {π+1}->Y {π+2}->ZThis saves a HUGE amount of memory.

When nesting, the most recent store to the stack is the one that gets read when you read from the stack.  Here is a pairing example:

A->π
   B->π
      C->π
      π->D
   π->E
   F->π
   π->G
π->H


I'm hoping this will lead to more possibilities to optimize code.  I know at least one individual will have a field day with this ;) Let me know if anyone, especially asm programmers, have questions or concerns.  It seems to work in my head, but I haven't tried implementing it so there may be some unforeseen problems.
Title: Re: Features Wishlist
Post by: Munchor on April 09, 2011, 05:23:25 am
Quigibo, I didn't read the whole thing, but we can use pi in Axe?
Title: Re: Features Wishlist
Post by: Ashbad on April 09, 2011, 09:16:50 am
No scout ;)

But quigibo, this is awesome.  This really could save a lot of memory and speed for advanced programmers :D. This is like a dream come true... Sorta.
Title: Re: Features Wishlist
Post by: ztrumpet on April 09, 2011, 10:27:57 am
That is wonderful!  Excellent idea, Quigibo, I can't wait to see the code that comes from this. :D
Title: Re: Features Wishlist
Post by: TIfanx1999 on April 09, 2011, 02:31:22 pm
Cool feature addition. =) I seem to remember a couple people asking about this as a possible feature.
Title: Re: Features Wishlist
Post by: Runer112 on April 09, 2011, 02:33:59 pm
Could you add an option to the options menu for expert users that would turn off the scope checking? Because I can definitely think of times when I wanted to be able to push/pop across multiple lines for extreme optimizations.


EDIT: Also Quigibo, do you want to put up that poll that you had proposed earlier about the GetCalc() functions?
Title: Re: Features Wishlist
Post by: ztrumpet on April 09, 2011, 04:04:02 pm
Could you add an option to the options menu for expert users that would turn off the scope checking? Because I can definitely think of times when I wanted to be able to push/pop across multiple lines for extreme optimizations.
I like this idea too, as it could potentially be very useful. ;D
Title: Re: Features Wishlist
Post by: SirCmpwn on April 09, 2011, 04:06:45 pm
^ Not really. Pseudo-wrapping in the horizontal direction is smaller, but its not real wrapping because the half sprite on the right side of the screen would be shifted down by one pixel and additional clipping would be needed for the last row so it wouldn't leak into memory after the screen.  This is better suited for an Axiom though since wrapping is rarely needed and can be done easily with 2 sprites.


Anyway, I came up with a new advanced syntax idea!  I was thinking of allowing programmers to take advantage of the stack the z80 offers but I'm concerned about memory leaks this could cause and undesired conflicts when calling routines since Axe uses the same stack behind the scenes.  But then I realized there is a way I could do it that would be both easy to use and be impossible to leak memory.  The solution is to:

1) Only allow the pair if they are in the same scope.  I define scope loosely... it has to fit on one line, but CAN intersect most single argument commands.
2) Require a pop for each push in that scope or else throw a syntax error.
3) Allow automatic integration into the right-hand side of binary operations.

For a non-technical explanation: Think of it as storing a value (maybe the result of a large computation) to a place you want to read later without having to use a temporary variable or do the computation again.  You can nest as many of these as you want without concern about memory.  I decided to use the pi character (π) to implement this.  Storing to it pushes the variable and reading from it pops it.

For example here is code to swap the values of 2 variables using a temporary:
Code: [Select]
A->T B->A T->BHere is the same code using the stack instead.
Code: [Select]
A->π B->A π->BSince each variable read or write is 3 bytes, but each stack read or write is only 1 byte, this code saves 4 bytes and is slightly faster.

Another example:
Code: [Select]
{A*3}->X {A*3+1}->Y {A*3+2}->ZHere is a case where you can nest them together:
Code: [Select]
{A*3->π->π}->X {π+1}->Y {π+2}->ZThis saves a HUGE amount of memory.

When nesting, the most recent store to the stack is the one that gets read when you read from the stack.  Here is a pairing example:

A->π
   B->π
      C->π
      π->D
   π->E
   F->π
   π->G
π->H


I'm hoping this will lead to more possibilities to optimize code.  I know at least one individual will have a field day with this ;) Let me know if anyone, especially asm programmers, have questions or concerns.  It seems to work in my head, but I haven't tried implementing it so there may be some unforeseen problems.

\o/ that sounds great!  I always love the addition of lower level features.
Which individual do you speak of?
Title: Re: Features Wishlist
Post by: ztrumpet on April 09, 2011, 05:15:43 pm
Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this (http://ourl.ca/10185/195814). :)
Title: Re: Features Wishlist
Post by: Freyaday on April 09, 2011, 06:34:52 pm
I see two problems with pi as it is now:
Too many consecutive pushes without pops will cause an overflow, even if the pops occur later on
And
A->pi->pi puts A once on the stack because, as it is now specified, pi-> is a pop, so pi->pi pops the top value then pushes it back in, doing nothing but waste cycles. Also, could there be a command for reading that top value w/o popping it? And a complementary command for deleting the top value off the stack w/o having to store it anywhere?
Title: Re: Features Wishlist
Post by: ztrumpet on April 09, 2011, 06:39:10 pm
Too many consecutive pushes without pops will cause an overflow, even if the pops occur later on
It normally doesn't cause a problem in Asm, so why would it cause a problem in Axe?
A->pi->pi puts A once on the stack because, as it is now specified, pi-> is a pop, so pi->pi pops the top value then pushes it back in, doing nothing but waste cycles.
No, it doesn't work like that, as it would read "A->pi" and then "->pi". :)
Could there be a command for reading that top value w/o popping it?
Nope, as it's impossible without something like "pi->A->pi".
A complementary command for deleting the top value off the stack w/o having to store it anywhere?
Sure: "pi"
Title: Re: Features Wishlist
Post by: Ashbad on April 09, 2011, 06:41:53 pm
Those are actually brilliant points you brought up -- less advanced users trying to tap into this may accidentally push 2K of data to the stack (which is way past the ~300 byte safe zone and would probably hurt the VAT) in a loop with a push without a pop -- maybe limit this to maybe 50 pushes?  (or ~299 :P)

This would keep it safe for newbies who have no idea what the stack is but think it has something to do with virtual plates ;)
Title: Re: Features Wishlist
Post by: Freyaday on April 09, 2011, 06:59:15 pm
So, am I right or not? I don't know; to be honest, I don't know much about the actual way the calc operates. I am not an ASM programmer.
Title: Re: Features Wishlist
Post by: Ashbad on April 09, 2011, 07:09:16 pm
I'd say one of your concerns was brilliant, the others Ztrumpet rightfully cleared up :)
Title: Re: Features Wishlist
Post by: Freyaday on April 09, 2011, 08:20:26 pm
Which one?
Title: Re: Features Wishlist
Post by: Deep Toaster on April 09, 2011, 08:31:16 pm
Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this (http://ourl.ca/10185/195814). :)

I really like that idea. What about changing Zeros( (det() to something more universal?
Title: Re: Features Wishlist
Post by: Runer112 on April 09, 2011, 08:59:14 pm
Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this (http://ourl.ca/10185/195814). :)

I really like that idea. What about changing Zeros( (det() to something more universal?

I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value. Maybe you could even add a Block()r command for creating a block filled with a specified word while you're at it, although this probably isn't as necessary as a normal byte-filling block command.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 09, 2011, 09:23:25 pm
I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value.

I like that idea. It would make it compatible with previous versions.
Title: Re: Features Wishlist
Post by: Runer112 on April 09, 2011, 09:24:01 pm
I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value.

I like that idea. It would make it compatible with previous versions.

That's the idea. :)
Title: Re: Features Wishlist
Post by: calc84maniac on April 09, 2011, 10:25:19 pm
Maybe it would be cool to expose the ex (sp),hl instruction somehow, which basically pops a value (and returns it) then pushes the previous value. Alternatively, think of it as swapping the previous value with the value on the top of the stack. (Of course, this command should be valid only if something has been pushed to the stack)

Edit:
Maybe ->πr? Which would mean storing to the stack while returning the previous value.

Edit2:
I suppose the right side of binary operations (which you mentioned before) will be optimized? For example, should compile to pop de \ add hl,de.

Edit3:
Hmm, this:
Code: [Select]
{A*3->π->π}->X {π+1}->Y {π+2}->ZCould even be optimized to:
Code: [Select]
{A*3->π}->X {π+1->π}->Y {π+1}->ZBut yeah, you did need an example of nested pushes/pops anyway.
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 01:12:31 pm
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.
Title: Re: Features Wishlist
Post by: Munchor on April 10, 2011, 01:14:15 pm
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.

Code: [Select]
Lbl SR
.CODE
Return

Lbl CP
.CODE
Goto E
Return

.Code
Lbl E
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 01:26:38 pm
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.

There's no real command to do that in ASM either. In fact, you could think of the program itself as a big subroutine that calls smaller subroutines. There's are JForce bcalls in ASM, but they leave an extra copy of the program in RAM, causing a memory leak.

There are workarounds though, but the one Scout suggested will not work. It just returns control to wherever the routine was called at the first Return (at the end of the program).

Also Scout, where are Lbl SR and Lbl CP defined?
Title: Re: Features Wishlist
Post by: Munchor on April 10, 2011, 01:28:17 pm
Deep: Mine will work, I didn't mean sub( but Lbl.
Title: Re: Features Wishlist
Post by: Runer112 on April 10, 2011, 01:30:15 pm
Scout, that would not work. The problem has to do with the state of the stack when hitting a Return. If you're in a subroutine, the return address to actually exit the program, and not just return from the subroutine, is somewhere hidden in the stack. When your program is just starting up, the stack will look something like this:
Code: [Select]
OS return location
Stuff
...

But when you're in a subroutine, the stack will look something like this:
Code: [Select]
Subroutine return location
Possibly more subroutine return locations
...
OS return location
Stuff
...

Because the OS return location is dug into the stack at an unknown depth, you cannot access it. The solution to this is to backup the OS return location at the start of your program when you know that it is the topmost stack entry. I would suggest using code like the following:


Code: [Select]
.MYPROG

Asm(ED73E383)          .Back up the OS return location

.YOUR PROGRAM GOES HERE

Asm(ED7BE383ED56C9)    .Exit program from anywhere, put this wherever you want it




EDIT: Quigibo, perhaps you could add a Returnr function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Returnr is detected in the first pass, set a flag to say so, but otherwise parse the Returnr command and the rest of the pass as normal. Before starting the second pass but after the header has been added, check this flag. If it isn't set, resume as normal. If it is set, add the 4-byte stack pointer backup code to the beginning of the program and then step through every static pointer, increasing them by 4. The rest of the program should then be able to be parsed normally.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 01:31:37 pm
Nope, it won't.

When you call sub(CP), it'll jump to Lbl E, which returns -- back to the place where you did sub(CP), which means it never runs the second Return at the end of Lbl CP.

EDIT: Runer112's routine above is pretty much the only way to do it without problems. Use that.
Title: Re: Features Wishlist
Post by: jnesselr on April 10, 2011, 01:31:54 pm
My best suggestion is to store sp somewhere, and then load sp back when you are done, and then return.  This works because something calls $9D95 or your ASM program, and the address to return to is stored at sp.  So you store sp at the start to some location, and then change it back to sp when you are done, and return.

EDIT: Uber-ninja'd with code.
Title: Re: Features Wishlist
Post by: ztrumpet on April 10, 2011, 01:42:10 pm
I've always wondered: Wouldn't the method Runer described cause a memory leak in the stack because everything wasn't poped off the stack before placing the return address on the stack?
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 01:42:52 pm
What about Basic's Stop? How does that work?
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 01:43:39 pm
I've always wondered: Wouldn't the method Runer described cause a memory leak in the stack because everything wasn't poped off the stack before placing the return address on the stack?

Nope, there'll be junk data where the stack used to extend, but it gets overwritten anyway, so it doesn't really matter.

What about Basic's Stop? How does that work?

The OS itself resets all its own variables to simulate ending a program (since BASIC is interpreted anyway, it's just like putting an end-of-program there).
Title: Re: Features Wishlist
Post by: jnesselr on April 10, 2011, 01:45:25 pm
What about Basic's Stop? How does that work?
Well, I believe mostly the same way.  But considering that BASIC is parsed, I would think that the parser handles all of that for you.
Title: Re: Features Wishlist
Post by: ztrumpet on April 10, 2011, 01:46:37 pm
I've always wondered: Wouldn't the method Runer described cause a memory leak in the stack because everything wasn't poped off the stack before placing the return address on the stack?

Nope, there'll be junk data where the stack used to extend, but it gets overwritten anyway, so it doesn't really matter.
Ah, gotcha.  It makes sense now. :D  Thanks! ;D
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 01:47:01 pm
What about Basic's Stop? How does that work?
Well, I believe mostly the same way.  But considering that BASIC is parsed, I would think that the parser handles all of that for you.

Yeah, the OS just ends the program the same way it ends when the BASIC parser reaches the end of a program -- it resets pointers and flags back to how it was before the program was run.
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 01:51:08 pm
So, is there a B_Call for that?
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 01:57:54 pm
Well, if there is, you won't be able to use it in an Axe program. ASM and BASIC are very different on the calc. Using the BASIC Stop in Axe would be like using Python's sys.exit() in C.
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 02:00:49 pm
That...made no sense to me. I have no experience with PC programming.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 02:35:04 pm
Oh, sorry. Basically I just mean you can't use one language's routines in a different language, especially if they're run in fundamentally different ways (Axe is compiled, BASIC is interpreted).
Title: Re: Features Wishlist
Post by: thepenguin77 on April 10, 2011, 04:15:51 pm
I've decided to try to incorporate Axe into zStart. But since Axe is constantly being changed, I can't statically link to addresses within it.

So my request is a call table that's at a static location that outside programs can call. The only two calls I can see needing though are:
-Compile OP1
-Set Axe Hooks

I want the Compile OP1 so I can make a button that compiles an Axe program. Preferably, have it display everything it normally does when compiling a program, and then just return. With enough hacking, this might even allow for an on-computer compiler.

And the set axe hooks would be so that even after ram clears, you have Axe's token set.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 04:33:56 pm
/me seconds the request for compiling from OP1
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 04:51:20 pm
Eight char var names, And the ability to (ab)use APD.
Title: Re: Features Wishlist
Post by: Quigibo on April 10, 2011, 05:00:54 pm
I've decided to try to incorporate Axe into zStart. But since Axe is constantly being changed, I can't statically link to addresses within it.

So my request is a call table that's at a static location that outside programs can call. The only two calls I can see needing though are:
-Compile OP1
-Set Axe Hooks

I want the Compile OP1 so I can make a button that compiles an Axe program. Preferably, have it display everything it normally does when compiling a program, and then just return. With enough hacking, this might even allow for an on-computer compiler.

And the set axe hooks would be so that even after ram clears, you have Axe's token set.

Yes, I was definitely planning on adding hooks within Axe for external compiling.  Next update would be a good time to add them.

EDIT:  The only problem though is that Axe uses almost all of the free ram locations when compiling so you'd have to be extremely careful if you want your program to resume after the compile.
Title: Re: Features Wishlist
Post by: thepenguin77 on April 10, 2011, 05:11:22 pm
Thanks. And to prevent version conflicts, you might want to add a GetVersion call so that if you start adding a bunch of features, it won't crash if the version on someone's calc is too old.

Also, you should probably have some kind of flag to signify that Axe is at a high enough version to do this. Perhaps $1337 right before the call table?

Edit to your edit:
    I wouldn't be using any. It would be called from a hook, from an app.
Title: Re: Features Wishlist
Post by: DrDnar on April 10, 2011, 06:40:06 pm
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.

There's no real command to do that in ASM either. In fact, you could think of the program itself as a big subroutine that calls smaller subroutines. There's are JForce bcalls in ASM, but they leave an extra copy of the program in RAM, causing a memory leak.
There are several work-arounds. You can, for example, use DeleteMem on 9D93h and then JForce your way out of the program. (The program's size is stored in 89ECh.) The easiest way to exit an assembly program at any time is to start the program with
Code: [Select]
pop hl
ld (returnAddress), hl
and then quit with
Code: [Select]
ld hl, (returnAddress)
jp (hl)
For this, stack level doesn't matter because the OS always wraps assembly code with an error handler; error handlers restore the stack when an error is thrown or you remove the handler. (Hopefully, all shells do something similar, too.) There's a specific memory address (86DEh) in which the OS stores the stack value of the most recent error handler, so you could also read that address, and then subtract the proper offset from it to get the address on the stack where the return address is stored. Of course, just throwing any error is a valid way to quit any assembly program.

EDIT: So, somebody already posted an Asm( string to quit at any time. I meant this more for Quigibo than end-users, as I think there should be an official way to quit at any time.
Title: Re: Features Wishlist
Post by: Ashbad on April 10, 2011, 06:50:50 pm
Well, with new stack commands, wouldn't it be possible to exit from a subroutine like this?

Code: [Select]
Lbl EXT
π -> A
Return

That should pop the address of the call to the routine, and then return like a normal program exit.  Correct me if I am mistaken.

Though this would not work in flash apps.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 10, 2011, 06:52:32 pm
Well, with new stack commands, wouldn't it be possible to exit from a subroutine like this?

Code: [Select]
Lbl EXT
π -> A
Return

That should pop the address of the call to the routine, and then return like a normal program exit.  Correct me if I am mistaken.

Though this would not work in flash apps.

That assumes you're exactly one subroutine deep, so you have to think about the cases where you're calling a subroutine from a subroutine (or you just happened to jump to the subroutine).
Title: Re: Features Wishlist
Post by: calc84maniac on April 10, 2011, 06:57:38 pm
This reminds me, would the new stack commands conflict with operations that implicitly use the stack? For example, A->π B-(π+C) would in theory compile to something like:
Code: [Select]
ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
pop hl
ld de,(axv_C)
add hl,de
pop de
ex de,hl
or a
sbc hl,de

Long story short, the pops would happen in the wrong order. How will this be handled?
Title: Re: Features Wishlist
Post by: Ashbad on April 10, 2011, 06:59:53 pm
Hmm.. Good point.  I guess there would be another way though -- for each subroutine you call, increment a counter somewhere in saferam starting at 0.  Within each subroutine, just increment this.  Then when you go to call the EXT routine, it checks the counter, and pops the amount of times the counter specifies and then just simply calls return.  Requires just a few cycles off of each subroutine (completely unoticeable) and a few bytes (maybe around say, 4 more per subroutine?) and it would make exiting a snap.

Or, if someone knows the address the OS calls to the beginning of the program, you could just push that to the stack and return -- however, that would lead to stack overflow after a while.
Title: Re: Features Wishlist
Post by: Freyaday on April 10, 2011, 07:28:44 pm
Or, if you stick with pi->A, you now have the ability to exit two subroutine layers at once.
Title: Re: Features Wishlist
Post by: Runer112 on April 10, 2011, 07:28:55 pm
I just want to sort of bump up this post from a short while back. A bunch of people have been debating how to get a "hard return" function working and I don't know if they missed this post I made 2 pages ago. It details both how a programmer could manually add this functionality and how the command could be built-in to Axe.


Because the OS return location is dug into the stack at an unknown depth, you cannot access it. The solution to this is to backup the OS return location at the start of your program when you know that it is the topmost stack entry. I would suggest using code like the following:


Code: [Select]
.MYPROG

Asm(ED73E383)          .Back up the OS return location

.YOUR PROGRAM GOES HERE

Asm(ED7BE383ED56C9)    .Exit program from anywhere, put this wherever you want it




EDIT: Quigibo, perhaps you could add a Returnr function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Returnr is detected in the first pass, set a flag to say so, but otherwise parse the Returnr command and the rest of the pass as normal. Before starting the second pass but after the header has been added, check this flag. If it isn't set, resume as normal. If it is set, add the 4-byte stack pointer backup code to the beginning of the program and then step through every static pointer, increasing them by 4. The rest of the program should then be able to be parsed normally.
Title: Re: Features Wishlist
Post by: DrDnar on April 10, 2011, 07:38:39 pm
Here's a slightly easier way that might be less compatible with shells:
Code: [Select]
Asm(2ADE86 2B 2B F9 C9)You don't need to place any special code at the start of the program.

It uses the fact that the OS (and probably all shells) always wraps programs in an error handler when it runs them. So if any shells don't do that, or place any extra pushes on the stack before running the program, it'll crash. But all shells have to use an error handler, or else an error will quit the shell itself.
Spoiler For Actual assembly code:
Code: [Select]
ld hl, (86DEh) ; This address is how the OS always knows how to restore the stack with APP_POP_ERR
dec hl
dec hl
ld sp, hl
ret

Really late edit: That will also have problems if your program installs an error handler of its own, so be sure to pop off any error handlers you have installed before running that. It will also have problems if you modify port 6, so you must restore its value before running that code.
Title: Re: Features Wishlist
Post by: Quigibo on April 11, 2011, 04:05:05 pm
This reminds me, would the new stack commands conflict with operations that implicitly use the stack? For example, A->π B-(π+C) would in theory compile to something like:
Code: [Select]
ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
pop hl
ld de,(axv_C)
add hl,de
pop de
ex de,hl
or a
sbc hl,de

Long story short, the pops would happen in the wrong order. How will this be handled?

Ah, but this is exactly my point about scoping!  Because of those extra parenthesis after the subtraction, those stack calls would not be in the same scope and therefore be illegal.  This is one of the reasons I don't want to support an override for the scope checking because it would be very confusing and incompatible with future versions if any of the underlying stack usages in the background of the program change.

The Returnr is a good idea, but that implementation won't work because pointers actually are being added to the code in the first pass for labels.  The second pass just fills in static storage and built-in subroutines.  I might still try to come up with another way though.
Title: Re: Features Wishlist
Post by: ralphdspam on April 11, 2011, 08:55:15 pm
It would be nice to have left and top clipping for rectangles. :)
Title: Re: Features Wishlist
Post by: Munchor on April 13, 2011, 08:43:16 am
Here's a slightly easier way that might be less compatible with shells:
Code: [Select]
Asm(2ADE86 2B 2B F9 C9)You don't need to place any special code at the start of the program.

It uses the fact that the OS (and probably all shells) always wraps programs in an error handler when it runs them. So if any shells don't do that, or place any extra pushes on the stack before running the program, it'll crash. But all shells have to use an error handler, or else an error will quit the shell itself.
Spoiler For Actual assembly code:
Code: [Select]
ld hl, (86DEh) ; This address is how the OS always knows how to restore the stack with APP_POP_ERR
dec hl
dec hl
ld sp, hl
ret

DrDnar, the seems very good, thank you :)

Also Quigibo, what about including in Axe commands a list of the Asm(HEX commands that may be useful for Axe programmers?
Title: Re: Features Wishlist
Post by: DrDnar on April 14, 2011, 03:29:03 am
Also Quigibo, what about including in Axe commands a list of the Asm(HEX commands that may be useful for Axe programmers?
You (plural) should make Wiki for that. WikiTI might work, if you don't feel like setting up a separate one.

By the way, the code I posted earlier is based on my disassembly of the code that runs programs. It's definitely not something you're likely to come up with just by reading the SDK.
Title: Re: Features Wishlist
Post by: Munchor on April 14, 2011, 05:50:51 am
Also Quigibo, what about including in Axe commands a list of the Asm(HEX commands that may be useful for Axe programmers?
You (plural) should make Wiki for that. WikiTI might work, if you don't feel like setting up a separate one.

By the way, the code I posted earlier is based on my disassembly of the code that runs programs. It's definitely not something you're likely to come up with just by reading the SDK.

You're prob. right, Zeda also has a pdf with hundreds of commands.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 18, 2011, 03:34:49 pm
Yeah an Axe Wiki should be really useful. Do you think there should be one setup on this hosting or something?

Also I edited the top page poll, because it was left without an edit for far too long.
Title: Re: Features Wishlist
Post by: Freyaday on April 18, 2011, 03:59:32 pm
Functions.
Title: Re: Features Wishlist
Post by: Builderboy on April 18, 2011, 04:07:46 pm
Don't we already have those?
Title: Re: Features Wishlist
Post by: Freyaday on April 18, 2011, 04:11:04 pm
I'm talking about, like, expr(X-3^27)->R and wherever R is encountered, the expression X-3^27 is inserted into the ASM instead of the value R.
Title: Re: Features Wishlist
Post by: Builderboy on April 18, 2011, 04:17:09 pm
But you can just do

Code: [Select]
sub(R)

Lbl R
X-3^27
Return

And save on space.
Title: Re: Features Wishlist
Post by: Freyaday on April 18, 2011, 04:18:29 pm
Ok. I was just wondering.
Title: Re: Features Wishlist
Post by: Munchor on April 18, 2011, 04:31:33 pm
Is there any way you can add VAR++?

I'd really like it, cos it makes the code more stylish that VAR+1->VAR and easier to introduce to C++/java/C coders.
Title: Re: Features Wishlist
Post by: ztrumpet on April 18, 2011, 07:02:11 pm
Is there any way you can add VAR++?

I'd really like it, cos it makes the code more stylish that VAR+1->VAR and easier to introduce to C++/java/C coders.
I asked this very early on, and it turned out that Quigibo instituted one of his first optimizations with Var+1->Var turning into inc Var.  So, the optimization is still there, just not the other syntax. :)
Title: Re: Features Wishlist
Post by: Builderboy on April 18, 2011, 07:05:25 pm
I think he is just asking for the A++ syntax for style, just so it looks more like traditional programming languages
Title: Re: Features Wishlist
Post by: ztrumpet on April 18, 2011, 07:09:00 pm
I think he is just asking for the A++ syntax for style, just so it looks more like traditional programming languages
Ah, okay. :)
In that case, I'd like the syntax to be valid as well. :D
Title: Re: Features Wishlist
Post by: Darl181 on April 18, 2011, 07:09:50 pm
I  was wondering if there can be a key for the compile menu that jumps straight to the backups.  XTΘn or something?
Title: Re: Features Wishlist
Post by: Happybobjr on April 18, 2011, 07:10:24 pm
up once?
Title: Re: Features Wishlist
Post by: Deep Toaster on April 18, 2011, 08:16:46 pm
Yeah an Axe Wiki should be really useful. Do you think there should be one setup on this hosting or something?

Ooh, that would be really useful, like the DCS wiki on Cemetech.
Title: Re: Features Wishlist
Post by: Quigibo on April 18, 2011, 09:42:50 pm
Also I edited the top page poll, because it was left without an edit for far too long.

Hehe, I can take a hint :P  Added a meaningful poll.

I was thinking of adding ++ as an operator for single byte variables because it could lead to a huge optimization there (but not to the 16-bit variables).  So A++ would translate to:
Code: [Select]
ld  hl,axv_A
inc (hl)

Which is NOT the same as A+1->A.  This is because here A represents the Axe "A" variable as just a single 8-bit byte and so 1++ becomes 2, but 255++ becomes 0 again.  And similarly, {B+L1}-- becomes:
Code: [Select]
ld  hl,(axv_B)
ld  de,axr_L1
add hl,de
dec (hl)
Title: Re: Features Wishlist
Post by: Freyaday on April 18, 2011, 11:35:20 pm
A^^B to do signed modulus, so that -1 returns B-1 instead of 65535 mod B.
Title: Re: Features Wishlist
Post by: Munchor on April 19, 2011, 06:44:39 am
A++ would be very cool, thanks Quigibo.

What about this (I suck at Assembly):

Code: [Select]
cp 255
call z,VarPlus

VarPlus:
   ld a,(VarA)
   inc a

Actually, this really sucks.
Title: Re: Features Wishlist
Post by: Ashbad on April 19, 2011, 08:17:00 am
Option 2: I chose that because to tell the truth, it really isn't that hard to put Normal:Dispgraph:Full into your program :/ if you can't do that then shame on you ;D
Title: Re: Features Wishlist
Post by: Compynerd255 on April 19, 2011, 08:40:47 pm
But you can just do

Code: [Select]
sub(R)

Lbl R
X-3^27
Return

And save on space.
I think what he means is a replacement routine, where instead of calling the subroutine, the code is inserted inline. I'd like to see that implemented somehow (maybe parsing from the label until a Return is encountered).

Oh, yes, and on the compile menu, I'd also like to be able to hold STAT or something while pressing ENTER to suppress automatic backup creation (like compiling after a RAM clear).
Title: Re: Features Wishlist
Post by: willrandship on April 19, 2011, 08:43:58 pm
I want ++ too! I use it all the time, especially in games without gravity physics, for the coordinates!
Title: Re: Features Wishlist
Post by: Builderboy on April 19, 2011, 09:35:29 pm
I think what he means is a replacement routine, where instead of calling the subroutine, the code is inserted inline. I'd like to see that implemented somehow (maybe parsing from the label until a Return is encountered).
Yeah I know what he meant, I was just pointing out that it would provide no new functionality, nor would it be a size reduction.  Indeed, I can see little application for it, as it also might end up in confusion for new users that end up bloating their memory by writing a modified sprite routine and end up bloating their code by 1000 bytes.
Title: Re: Features Wishlist
Post by: Runer112 on April 19, 2011, 09:58:58 pm
Although a ++ command could definitely be useful to intense optimizers like myself, I don't think the command should be added due to confusion it may cause. These are the two major sources of confusion I would foresee:

Title: Re: Features Wishlist
Post by: Freyaday on April 19, 2011, 10:17:27 pm
Access to the clock.
Title: Re: Features Wishlist
Post by: calc84maniac on April 19, 2011, 10:34:19 pm
Although a ++ command could definitely be useful to intense optimizers like myself, I don't think the command should be added due to confusion it may cause. These are the two major sources of confusion I would foresee:

  • It's only an 8-bit math command, whereas every other math command is 16-bit. And unless the user knows the underlying machine code, I would imagine that they would think something as simple as addition of 1 could easily be performed on a 16-bit value.
  • The result of the addition isn't returned in hl. {B+L1}+1 and {B+L1}++ would return an entirely different value, despite only having one slight difference in the mathematical operator that comes after what would appear to be a value fetch. In my mind, this is by far the stronger reason of the two as to why this operator could cause confusion.
Maybe the ++ and -- operators should work without the memory read brackets, which would simplify parsing and emphasize that the pointer is what is returned.
Title: Re: Features Wishlist
Post by: Happybobjr on April 19, 2011, 10:44:04 pm
Request: 4 line rectangle.  (probably could be an axiom I guess.

It would draw 4 lines, but it would not be restricted to vertical and horizontal points.
I know This can be done through normal code, but The only way I see to do it is very large compared to what it could be.
Title: Re: Features Wishlist
Post by: Freyaday on April 19, 2011, 10:50:19 pm
Bit rotation, and the ability to use multiple vars to create 32- and 64-bit vars.
Title: Re: Features Wishlist
Post by: willrandship on April 19, 2011, 10:53:11 pm
Ability to change mem outside of the buffers, and have horizontal/vertical move those pixels in or out. I thin it was there before (listed as garbage pixels) but it should probably just be a fix/option, to avoid incompatibilities. Also, sprites overlapping the screen should draw to that area correctly.
Title: Re: Features Wishlist
Post by: calc84maniac on April 19, 2011, 11:01:53 pm
Ability to change mem outside of the buffers, and have horizontal/vertical move those pixels in or out. I thin it was there before (listed as garbage pixels) but it should probably just be a fix/option, to avoid incompatibilities. Also, sprites overlapping the screen should draw to that area correctly.
What is "outside the buffer"? Where do all these pixels go?
Title: Re: Features Wishlist
Post by: Freyaday on April 19, 2011, 11:32:08 pm
I think he means a buffer buffer, a border of nondisplaying pixels around the displayable portion of the buffer.
Title: Re: Features Wishlist
Post by: Munchor on April 20, 2011, 07:54:23 am
I have a new feature suggestion!

Multiple fixes in one line:

Code: [Select]
Fix 3
Fix 1
Text(0,0,"HELLO WORLD
Fix 0
Fix 2

Would be :

Code: [Select]
Fix 3,1
Text(0,0,"HELLO WORLD
Fix 0,2

Is it possible?
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 09:40:39 am
That would be awesome!
Title: Re: Features Wishlist
Post by: Munchor on April 20, 2011, 09:42:08 am
That would be awesome!

It would be cool, but not sure if awesome, it's rarely useful.
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 09:43:39 am
It is if, like me, you tend to use a lot of Fix es.
Title: Re: Features Wishlist
Post by: calc84maniac on April 20, 2011, 01:42:14 pm
It is if, like me, you tend to use a lot of Fix es.
I don't think it's really worth it to add that, because it's only a small source-code convenience. It has no effect on the compiled program.
Title: Re: Features Wishlist
Post by: Munchor on April 20, 2011, 04:11:26 pm
It is if, like me, you tend to use a lot of Fix es.
I don't think it's really worth it to add that, because it's only a small source-code convenience. It has no effect on the compiled program.

Yeah you can't optimize res/set bits, it's only a code conenience.
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 04:20:08 pm
It's called syntactic sugar.
For loops, Repeats, and Whiles are all syntactic sugar, too.
Title: Re: Features Wishlist
Post by: Runer112 on April 20, 2011, 04:37:29 pm
By the way, I just want to clarify something about the second poll option because its text is somewhat misleading. Your code would only be smaller if you run your program at 6MHz. If your program runs at 15MHz, your program could actually be bigger by having to manually add the Normal and Full wrapper. Not to mention the added pain of having to add it.
Title: Re: Features Wishlist
Post by: Munchor on April 20, 2011, 04:48:12 pm
It's called syntactic sugar.
For loops, Repeats, and Whiles are all syntactic sugar, too.

Loops are not syntax sugar, they are one of the paradigms of programming. Variables, Loops and Functions are the three paradigms of modern programming, they are definitely not syntax sugar.

@Runer: I totally agree, I don't understand how the first option won.
Title: Re: Features Wishlist
Post by: Builderboy on April 20, 2011, 06:43:06 pm
In Axe they are not syntax sugar, since they use things such as conditional Goto's, and more optimized versions of what could be done with Axe, so they are very necessary.   
Title: Re: Features Wishlist
Post by: Runer112 on April 20, 2011, 06:48:05 pm
@Runer: I totally agree, I don't understand how the first option won.

Actually my post was vouching for the first option. It was explaining that giving the user manual control is in fact worse if their program is intended to run at 15MHz.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 20, 2011, 08:07:54 pm
I have a new feature suggestion!

Multiple fixes in one line:

People have suggested that several times before, and there's a suggestion to put it together without commas (like Fix 135). It would be useful, too. Could it be added?

Maybe the ++ and -- operators should work without the memory read brackets, which would simplify parsing and emphasize that the pointer is what is returned.

I really like that idea. I actually planned to post that exact feature request a few days ago (POINTER++ and POINTER--), but I forgot :P So I guess I second it? :D
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 08:17:00 pm
Syntactic sugar covers any command whose effect can be reproduced by other means. This means that all loops are sugar, as they are just Conditioned Gotos in disguise.
Title: Re: Features Wishlist
Post by: Builderboy on April 20, 2011, 08:22:27 pm
Ah i see now.  In any case, it does provide a non-syntax use in Axe :P Since it *is* faster than using If statements and Goto's
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 08:24:20 pm
Yes, because loops are special Gotos.
16 bit bitwise operations.
Title: Re: Features Wishlist
Post by: Builderboy on April 20, 2011, 09:37:41 pm
16 bit bitwise operations.

Already added, check the documentation :)
Title: Re: Features Wishlist
Post by: calcdude84se on April 20, 2011, 09:49:38 pm
Or, Freyaday, if you are too lazy :P, they are the plot tokens. The dot is "and", the box is "xor", and the cross is "or". (I might've gotten the last two backwards, make sure).
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 09:52:42 pm
I think those are only 8 bit, though.
Title: Re: Features Wishlist
Post by: calcdude84se on April 20, 2011, 09:55:53 pm
That's what " and ", " or ", and " xor " are for ;)
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 10:03:15 pm
Those are logical, not bitwise. They behave the same as they do in BASIC.
Title: Re: Features Wishlist
Post by: calcdude84se on April 20, 2011, 10:24:25 pm
Those are definitely bitwise. For example, "1 and 2" returns 0, though, if it were logical, it would return 1.
This happened to be the source of several bugs in some of my Axe programs, mind you :P
Title: Re: Features Wishlist
Post by: Freyaday on April 20, 2011, 10:26:04 pm
Are you sure? That's never happenned to me.
Title: Re: Features Wishlist
Post by: calcdude84se on April 20, 2011, 10:30:27 pm
Here, screenshot, just because:
Title: Re: Features Wishlist
Post by: Ashbad on April 20, 2011, 10:32:56 pm
Yeah, they are bitwise, which is why you need parenthesis around statements in a logic sentence with more than one logic check, such as:

Code: [Select]
If (X=0 And (Y>5)) Or (Y=16)
Because the equals, not equals, greater than, etc. return 1 or 0 if it is true, and the logic operators handle the bitwise comparisons.  With the sentences out of the way, this is what it looks like otherwise:

Code: [Select]
If ((1) And (0)) Or (1)
I think its 8 bit comparisons, but I'm not sure about that part.  However, it is bitwise, though usually all it does compare is 1's and 0's.
Title: Re: Features Wishlist
Post by: Munchor on April 21, 2011, 11:20:33 am
Yap, every If that uses a and or a or or any other operation like this requires parentheses in all the ones that aren't the first.

Just like Ashbad said and calc84maniac proofed.
Title: Re: Features Wishlist
Post by: calcdude84se on April 22, 2011, 08:31:53 pm
*calcdude/calcdude84se/calcdude84pse
Actually, what I proved is that " and " etc. are bitwise and not logical. ;)
A more realistic example than the "1 and 2" one is in the potential optimization of this code segment:
Code: [Select]
If A=/=0 and (B=/=0You might think "Hey, it's testing =/=0; I can just remove that!" But, if A=1 and B=2, for example, "A and B" will yield a different result. That's part of how I encountered bugs a few times.
Also, Ashbad, your code works just the same as
Code: [Select]
If X=0 and (Y>5) or (Y=16)(You don't need the parentheses around the arguments to " and ")
Note too that just because they are bitwise doesn't mean that you need parentheses. Those rules apply for any infix (taking arguments like "ArgA OPERATION ArgB") operator, and probably others.
What you said is just a direct effect of Axe's utter lack of order of operations ;)

Also, after someone else posts another feature request, if we want to talk about this more could we do it in another thread? Otherwise it makes it a bit hard to see feature requests ;D
Title: Re: Features Wishlist
Post by: Quigibo on April 23, 2011, 06:56:54 pm
An update on my progress today:

Something I thought would be useful, but not requested yet, was to made rand dereferencable.  So now orand returns the pointer to the seed.  One use is to use {orand}r to return the most recent number generated from a rand call.  Another unintended consequence which I was at first about to fix but decided to keep is that you can use rand as the variable in a for loop!  so For(rand,0,10) will actually work and use the seed as the location to store the counter.  This is great for programs that don't use random numbers and want an extra variable.  Just beware that any call to rand will change its value (which would screw your for loop)

Another thing I added was the ability to stack Fix commands.  So "Fix 135" is the same as "Fix 1:Fix 3:Fix 5".  Also, there is now a fixed jump table built into the app so hopefully applications like DoorsCS and zStart can take advantage of using some useful Axe features externally once I release the API.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 23, 2011, 09:15:33 pm
Another thing I added was the ability to stack Fix commands.  So "Fix 135" is the same as "Fix 1:Fix 3:Fix 5".  Also, there is now a fixed jump table built into the app so hopefully applications like DoorsCS and zStart can take advantage of using some useful Axe features externally once I release the API.

Whoa! Those are all features immediately useful to me :w000000000000t:

Thanks Quigibo! Glad you're still actively making Axe better :D
Title: Re: Features Wishlist
Post by: Freyaday on April 23, 2011, 09:18:20 pm
getkey(key1,key2...)
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.
Title: Re: Features Wishlist
Post by: calc84maniac on April 23, 2011, 09:21:19 pm
getkey(key1,key2...)
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.
What if more than one is pressed?
Title: Re: Features Wishlist
Post by: Runer112 on April 23, 2011, 09:21:56 pm
getkey(key1,key2...)
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.

I can't really think of a use for that, it seems to me like plain old getKey would do what you want. Although perhaps I'm not quite understanding your suggestion. Could you give me an example of how it might be used?
Title: Re: Features Wishlist
Post by: Freyaday on April 23, 2011, 09:49:50 pm
calc84manic: It would return the first value in the list
Runer112: Instead of having to check if getkey (not getkey()) is part of a list of accepted values and then do getkey->VAR, you'd do getkey(list) and get the same speed and keyholding abilities of getkey()
Title: Re: Features Wishlist
Post by: Runer112 on April 23, 2011, 09:49:50 pm
I don't feel great about bumping my own suggestion because I don't want to make it seem like I think my suggestion is more important than others. But in reality, it sort of is. I know you (Quigibo) have been leaning away from adding new commands and instead implementing parser and general application improvements, leaving new commands for Axiom programmers. I think this is a great idea, leaving the deep down technical stuff to the person who knows it best and leaving the job of writing commands to the general assembly programming populous. But it would be useful if Axiom programmers had a programming tool that currently only you have. There are commands that I'm literally just waiting for this ability to finally implement.

The Axiom system is great. Things like automatic jump and call replacements and manual 16-bit load replacements are great, which even the hard-coded Axe commands cannot do. But there's one thing that internal Axe commands can do whereas Axioms can't that I would love to be able to do. Would it be possible to add a new internal Axiom compiler feature that allows calls to be made with offsets? Perhaps a new macro like ld b,b \ .db BYTE \ .org $-2? Because this would be incredibly useful for calling a command in slightly different ways, like you often use with an optional buffer argument for drawing commands.


There are a few other command-adding abilities that only you have that would also be useful. For instance custom token replacements would be nice, even if they had limitations such as requiring Axioms to be at the very start of the program or only loading token replacements upon opening the program editor. The closer that Axiom programmers come to your ability to add new commands, the less we would have to bug you about adding commands. ;)
Title: Re: Features Wishlist
Post by: calc84maniac on April 23, 2011, 10:06:40 pm
calc84manic: It would return the first value in the list
Runer112: Instead of having to check if getkey (not getkey()) is part of a list of accepted values and then do getkey->VAR, you'd do getkey(list) and get the same speed and keyholding abilities of getkey()
This should work in theory:
Code: [Select]
Data(key1,key2,key3,...,keyN,0)-1->A
While {A+1->A}->B
EndIf getKey()
.B now holds the resulting key or 0 if none match
Title: Re: Features Wishlist
Post by: Quigibo on April 24, 2011, 04:30:35 am
Runer, how do you suggest I do the token replacement?  The first problem I had was that you have to know ahead of time what Axioms are being used in the program so it knows what to replace.  That can easily be solved with your first suggestion of always requiring the Axioms to come first, but this does remove a possible convenience, however its probably worth it.  The next problem is that for each token the Axioms have to be searched for in the symbol table to find their pointers, which could be costly with a large number of programs.  Then, when finally found, each Axiom would have to be scanned completely to find if the token matches by transversing the offset list (again, for each token).  So if you had 2 Axioms with 25 new commands each, and about 20 tokens on the screen, that's 40 symbol table searches + 1000 checks + the built in checks.  I could definitely see this causing lag in the scrolling.  There might be another way of caching the data in ram somewhere, and maybe setup a binary search, but this would greatly complicate things.  The token hook is only called when tokens are being printed and I don't want to use other hooks so its difficult to have some sort of "pre-parsing".  I am however still open to suggestions of what to name the rest of the custom override tokens.

Your other suggestion, If I'm reading this correctly, is a static offset to optimize doing ld hl,dynamic_ptr; ld de,offset; add hl,de; correct?  This might be an option in the future.  There are other useful features I can think of too, like adding the ability to create Axioms that take a label as their first argument, like how the current interrupt setup command works.
Title: Re: Features Wishlist
Post by: Munchor on April 24, 2011, 07:55:10 am
Quote
Another thing I added was the ability to stack Fix commands.  So "Fix 135" is the same as "Fix 1:Fix 3:Fix 5".  Also, there is now a fixed jump table built into the app so hopefully applications like DoorsCS and zStart can take advantage of using some useful Axe features externally once I release the API.

:D That is great, thanks. Does that optimize the program or just the source size?
Title: Re: Features Wishlist
Post by: Runer112 on April 24, 2011, 10:04:37 am
Runer, how do you suggest I do the token replacement?  The first problem I had was that you have to know ahead of time what Axioms are being used in the program so it knows what to replace.  That can easily be solved with your first suggestion of always requiring the Axioms to come first, but this does remove a possible convenience, however its probably worth it.  The next problem is that for each token the Axioms have to be searched for in the symbol table to find their pointers, which could be costly with a large number of programs.  Then, when finally found, each Axiom would have to be scanned completely to find if the token matches by transversing the offset list (again, for each token).  So if you had 2 Axioms with 25 new commands each, and about 20 tokens on the screen, that's 40 symbol table searches + 1000 checks + the built in checks.  I could definitely see this causing lag in the scrolling.  There might be another way of caching the data in ram somewhere, and maybe setup a binary search, but this would greatly complicate things.  The token hook is only called when tokens are being printed and I don't want to use other hooks so its difficult to have some sort of "pre-parsing".  I am however still open to suggestions of what to name the rest of the custom override tokens.

If there's a way to only parse any #Axiom( tokens immediately when the program editor is opened, that seems like a good route to take. You could get their pointers from the symbol table and cache them at the start, and you'd only need 3 bytes * 5 Axioms of cache storage. If there isn't a specific event that can be triggered upon opening the program editor, you can always fake it by hooking into an event that periodically occurs, but only acting upon it the first time it is triggered.


Your other suggestion, If I'm reading this correctly, is a static offset to optimize doing ld hl,dynamic_ptr; ld de,offset; add hl,de; correct?  This might be an option in the future.  There are other useful features I can think of too, like adding the ability to create Axioms that take a label as their first argument, like how the current interrupt setup command works.

Yeah, something like that. It would be more useful for doing offset calls though, like:
Code: [Select]
OFS_NEXT(7)
call sub_Axiom1
This is the sort of thing you often do with drawing commands so they can work with different buffers.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 24, 2011, 10:28:30 am
:D That is great, thanks. Does that optimize the program or just the source size?

Source only. Each Fix command is just a four-byte SET/RES instruction, and there's no way to combine them and have the result be smaller except in rare cases where you set a bunch of related flags at once.

EDIT: Four, not three. Not sure what I was thinking.
Title: Re: Features Wishlist
Post by: Runer112 on April 25, 2011, 10:05:52 pm
Some more Axiom feature requests: the ability to specify commands that must be followed by a store token, and the ability to specify that the Axiom should be searched before the internal commands.

I understand that you didn't make Axioms parsed first because it would slow down parsing of normal commands, which would probably account for most of the program. But having it as an option would be useful. That way if your Axiom didn't supplement/replace any built-in commands, you wouldn't specify this option and parsing speed would be normal. But if your Axiom was designed to replace internal commands, you could do so by specifying this option.


Also, if you're going to modifying the Axiom system with any feature additions (not necessarily the ones above), it would probably be a good idea to start adding more information to the Axiom header, namely version information. This would signal to the Axe application parsing the Axiom whether or not the application's version is compatible. Adding an expanded header would also allow for the addition of more information, like whether or not to parse with a higher priority than internal commands. Perhaps:
Code: (Axiom header) [Select]
.db $C0,$DE ;Header bytes reversed so old Axe applications won't accept the Axiom
.db Axiom_version
;Possibly additional header data
Title: Re: Features Wishlist
Post by: Compynerd255 on April 26, 2011, 10:29:02 am
Here's a request that shouldn't be hard to implement: adding If conditionals to sub and Goto. Because this can be done in z80 ASM, it shouldn't be hard to optimize this:
Code: (Original code) [Select]
!If A-1
sub(FOO)
End
to this:
Code: (Optimized code) [Select]
sub(FOO)!If A-1

Also, I would like For loops to work with negative numbers (as a seperate option). For example, For(I,-1,1) is a legitimate loop (check the positions to the left, center, and right, for instance) but would end immediately. So, I would like to specify For(I,-1,1)r to show that the indexes are signed. Oh, and I would also like to specify custom steps in For loops, like we can in TI-BASIC.
Title: Re: Features Wishlist
Post by: Freyaday on April 26, 2011, 10:42:15 am
As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)rr
where C>0, would increment by -C if A>B and C if A<B
Title: Re: Features Wishlist
Post by: Runer112 on April 26, 2011, 04:47:07 pm
Here's a request that shouldn't be hard to implement: adding If conditionals to sub and Goto.

I agree, that would be nice. I think Quigibo was contemplating adding this feature not long ago.

Also, I would like For loops to work with negative numbers (as a seperate option). For example, For(I,-1,1) is a legitimate loop (check the positions to the left, center, and right, for instance) but would end immediately. So, I would like to specify For(I,-1,1)r to show that the indexes are signed.

Having For() loops work with negative numbers would be sort of tricky and larger than normal loops, because signed comparisons are harder than unsigned comparisons. To have a loop like For(I,⁻1,1), you could just use a loop like For(I,⁻1+256,1+256) and change every reference of I in the loop to I-256. Alternatively, you can make a custom While loop that would be smaller and faster:
Code: [Select]
⁻1-2
While 1
  +2→I
  ;Your code goes here
End!If I-1

Oh, and I would also like to specify custom steps in For loops, like we can in TI-BASIC.

I've been wondering why Quigibo hasn't added that as well.

As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)rr
where C>0, would increment by -C if A>B and C if A<B

This doesn't seem like a loop structure that would be widely used, especially since modern programming languages don't have loops like this. This is the kind of thing that you would best build a custom loop for.
Title: Re: Features Wishlist
Post by: Freyaday on April 26, 2011, 04:52:19 pm
Oh, and I would also like to specify custom steps in For loops, like we can in TI-BASIC.

I've been wondering why Quigibo hasn't added that as well.
I suggested that awhile ago and got shot down hard. =/
Apparently, it was thought that While loops were an acceptable substitute.
As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)rr
where C>0, would increment by -C if A>B and C if A<B

This doesn't seem like a loop structure that would be widely used, especially since modern programming languages don't have loops like this. This is the kind of thing that you would best build a custom loop for.
Why shouldn't Axe be the first, then?
Title: Re: Features Wishlist
Post by: Runer112 on April 26, 2011, 04:57:01 pm
As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)rr
where C>0, would increment by -C if A>B and C if A<B

This doesn't seem like a loop structure that would be widely used, especially since modern programming languages don't have loops like this. This is the kind of thing that you would best build a custom loop for.
Why shouldn't Axe be the first, then?

Because, in all fairness, that's not a very practical loop structure. Quigibo doesn't want to bog Axe down with commands that will rarely be used or can easily be otherwise produced with the existing features. Technically both For() loop feature addition suggestions qualify as being able to otherwise be produced, but the For() loop with a variable increment is a fairly widely used loop structure in many programming languages and I think would make sense to add.
Title: Re: Features Wishlist
Post by: Deep Toaster on April 26, 2011, 06:16:20 pm
Here's a request that shouldn't be hard to implement: adding If conditionals to sub and Goto.

I agree, that would be nice. I think Quigibo was contemplating adding this feature not long ago.

His post:

For the goto-if and goto-!if I think I will auto-optimize the existing commands instead of creating entirely new syntax.  It would actually be easier I think to read and write and no one would have to change their syntax.  Same thing with sub().

Still not sure: does that mean this (http://ourl.ca/4057/159200) is now optimized? If so, I still want to suggest a Goto LBLIf CONDITION syntax, if only to have it look better. If Quigibo doesn't want to add it he doesn't have to though, if conditional Gotos are already optimized.

EDIT: Doesn't seem to be optimized yet... Goto LBLIf CONDITION, please? :D

EDIT2: Another suggestion: a hotkey to quit from compiling.
Title: Re: Features Wishlist
Post by: Quigibo on April 26, 2011, 11:16:07 pm
Actually I was planning to have for-loops have a step size parameter, but it will most likely have to be a non-negative constant in order to actually optimize.  I really think the syntax for conditional gotos and subs looks a bit ugly which is why I'm planning to auto-optimize it eventually.

Quote from: Runer112
You could get their pointers from the symbol table and cache them at the start, and you'd only need 3 bytes * 5 Axioms of cache storage.
To work reliably, this would require some other kind of hook other than the token hook which I'm trying to avoid.
Title: Re: Features Wishlist
Post by: calc84maniac on April 26, 2011, 11:17:57 pm
Actually I was planning to have for-loops have a step size parameter, but it will most likely have to be a non-negative constant in order to actually optimize.
How about optimizing constants and having a less optimized version for non-constants?
Title: Re: Features Wishlist
Post by: aeTIos on April 28, 2011, 03:32:08 am
My wish is longer labels and user-defined variables, like in assembly "Xpos .equ appbackupscreen" so in Axe that would be like "varXpos ==A" or so. Maybe you could replace the 'grp' token  with it, since its not really much used. (imo ;))
As for labels, try to make them 6 chars or so.
Title: Re: Features Wishlist
Post by: Darl181 on May 02, 2011, 02:43:05 am
Not really a feature per se, but might it be possible to release a version of axe 0.5.1 that has the dispgraph bug fixed?

btw on the poll voted no, it would break compatibility with older programs.  As for easier reading, at least to me it's weird seeing a Pt-On( or For( with closed parenthesis :P
Title: Re: Features Wishlist
Post by: ZippyDee on May 02, 2011, 02:50:11 am
I also voted no on the poll. I feel like even though the size of the compiled program will be the same, I still prefer to have smaller source code if it's possible. Seems like closing all parentheses just for the sake of it is an unnecessary addition that would just add bytes to my source code and take away from my free ram.
Title: Re: Features Wishlist
Post by: Quigibo on May 02, 2011, 02:59:39 am
0.5.2 is coming out this week and I haven't actually gotten to fixing it yet so I think you'll have to wait until then.  Yeah, I forgot to mention that I added a new poll.  This is something big that I was thinking about since the start of the project.  I was avoiding the topic for a while though because I was afraid it was already too late to make a change like that, but I figured I would ask it anyway.  Even though it would break compatibility, it would be fairly easy to fix, and Axe could conceivably add extra closing parenthesis for you automatically as it compiles.

I actually already have been enforcing closed parenthesis on some commands.  I thing getkey(), all the # commands, and a few others currently require them closed right now.

EDIT: And ZippyDee, sig related! :P
Title: Re: Features Wishlist
Post by: Deep Toaster on May 02, 2011, 09:24:34 am
Would it take longer to compile if Axe enforced parentheses? I definitely don't want compiling to take any longer... Otherwise I would vote for enforcing it.
Title: Re: Features Wishlist
Post by: Runer112 on May 02, 2011, 09:55:08 am
I voted yes in the poll. I have seen numerous examples of people having a bug in their program because of unclosed parentheses. However, because they think it's okay to leave parentheses open, rarely do they find their bug. It only turns out that after they post their source code in a help thread, someone else who closes their parentheses discovers the bug. And even then, it's an elusive bug to find for people who do know that closing parentheses is important. In my experience, all it produces is messier code and more errors.
Title: Re: Features Wishlist
Post by: Freyaday on May 02, 2011, 10:39:28 am
Line-test(StartX,StartY,EndX,EndY,Color(1,0),ResultX,ResultY[)r]
Would start at the Start coordinates, follow the pixels indicated by the Line algorithm and return the coordinates of the first pixel found of the color indicated (1=black, 0=white) to the variables indicated by the Result arguments.
Title: Re: Features Wishlist
Post by: Runer112 on May 02, 2011, 10:51:04 am
Freyaday, that is a fairly complex command that seems to be for a very specific purpose. It's not exactly the kind of command that should be implemented into the main Axe language. A command like this should probably either be coded in a custom Axiom or just simply coded straight into your program in Axe.
Title: Re: Features Wishlist
Post by: Freyaday on May 02, 2011, 10:54:12 am
I can't figure out how to make it in Axe.
So I put it in The Axiom section.
Title: Re: Features Wishlist
Post by: collechess on May 02, 2011, 05:09:49 pm
Horizontal+x and Horizontal-x
To shift the graphscreen a certain amount of pixels
Title: Re: Features Wishlist
Post by: Builderboy on May 02, 2011, 05:14:24 pm
The reason I think this has not being added is because it is already possible and easy in Axe, just by using a for loop, and so wouldn't really add any new functionality, nor would it add much speed.
Title: Re: Features Wishlist
Post by: collechess on May 02, 2011, 06:18:04 pm
randInt
Title: Re: Features Wishlist
Post by: squidgetx on May 02, 2011, 06:19:27 pm
just do rand^x+y where y is your lower bound and y+x is your upper bound
Title: Re: Features Wishlist
Post by: Deep Toaster on May 02, 2011, 06:20:14 pm
randInt

rand already returns numbers as integers :)

EDIT: Ninja'd.
Title: Re: Features Wishlist
Post by: Runer112 on May 02, 2011, 06:31:28 pm
Code: [Select]

sub(RND,1,10)    .Example usage to generate a random number from 1-10


.<------- Random Integer ------->
.Input: r₁=lower bound
.       r₂=upper bound
.Output: random integer from r₁-r₂
Lbl RND
Return rand^(r₂-r₁+1)+r₁


Although this is easily achieved with a custom routine, I'm wondering if it should be added as an Axe feature anyway. Getting a random integer from a to b is a feature of just about every programming language.
Title: Re: Features Wishlist
Post by: JustCause on May 04, 2011, 02:28:02 pm
If this has already been brought up, I'm sorry, but drawing text to the back buffer. Without it, you have to Exch() the buffers every time you want to draw black text in 4lv grayscale, and that's slooooooow. Perhaps a new Fix command?
Title: Re: Features Wishlist
Post by: Runer112 on May 04, 2011, 02:30:02 pm
Unfortunately, this isn't an Axe limitation, this is an OS limitation. Axe uses the OS text drawing routines, and the OS is incapable of drawing text to any buffer other than the front buffer.
Title: Re: Features Wishlist
Post by: calc84maniac on May 04, 2011, 02:30:21 pm
If this has already been brought up, I'm sorry, but drawing text to the back buffer. Without it, you have to Exch() the buffers every time you want to draw black text in 4lv grayscale, and that's slooooooow. Perhaps a new Fix command?
Well, the OS routine only supports writing to the main buffer. Of course, you could alternatively make your own sprite-based version which would be super-fast in comparison :)
Title: Re: Features Wishlist
Post by: Runer112 on May 07, 2011, 04:27:57 pm
Here's one that I think would be pretty useful and easy to implement: custom interrupts that call the OS interrupt handler before starting or upon finishing. This would allow programmers to use commands like getKey or getKeyr with custom interrupts enabled, which could be very useful. Perhaps fnInt(LBL,FREQ)r? If they wanted they could actually use this to speed up arrow key repeats as well.
Title: Re: Features Wishlist
Post by: Deep Toaster on May 07, 2011, 04:37:52 pm
That's a great idea :D

And another suggestion: Pt-Zero( or something like that (maybe for Plot2(?) to use AND logic. It would be really useful to me right now <_<
Title: Re: Features Wishlist
Post by: Munchor on May 07, 2011, 04:41:39 pm
I just saw the poll, I think parentheses are very important since all programming languages enforce them (TI-Basic not included). As long as Axe redirects us to the error if we press PRGM.

I'd really really like this implemented :D
Title: Re: Features Wishlist
Post by: Deep Toaster on May 07, 2011, 04:47:55 pm
Would it slow compiling down though?
Title: Re: Features Wishlist
Post by: Quigibo on May 07, 2011, 10:29:13 pm
Wow, this is a really dead-close poll!  Not sure what I'm going to do yet, I usually only make a change this large if there is overwhelming support for it.  And no, it doesn't affect compile time because axe has to figure out where to close the parenthesis (pop the stack) on its own already without them so it would take just as long.  This would only be a programmer convenience and wouldn't change anything at all about the compiling process or generated programs.  If you are extremely for it or against it, please state your lengthy opinions why this is either a terrible idea or an absolute necessity.

Another new feature I am adding is a new style of pointer referencing.  For any variable or static pointer you can now write {__+A} as A(__).  and {__*2+A}r as A(__)r.  Here, the variable A can also be a ram location like L1, a static pointer like Str1, and possibly a file object like Y1 if I can get that to work.  That means things like L1(7) means the same thing as in basic as it does in Axe; the 7th item in L1's memory.  I think this form will make pointers easier for beginners to understand and reduce pointer related errors.

randInt(min,max) for a range of numbers is definitely useful and I'll probably get to that in this release.  I have been working this whole week with little sleep to finish my python compiler project for class so I'm a little "compiled out" right now, but hopefully I'll get this all done soon.  My goal is to finish adding core features so that the next release after that will be 1.0.0 but we'll see what happens...

Title: Re: Features Wishlist
Post by: Deep Toaster on May 07, 2011, 10:32:41 pm
Wow, this is a really dead-close poll!  Not sure what I'm going to do yet, I usually only make a change this large if there is overwhelming support for it.  And no, it doesn't affect compile time because axe has to figure out where to close the parenthesis (pop the stack) on its own already without them so it would take just as long.  This would only be a programmer convenience and wouldn't change anything at all about the compiling process or generated programs.  If you are extremely for it or against it, please state your lengthy opinions why this is either a terrible idea or an absolute necessity.

Good to hear. In that case I support forcing programmers to close brackets (reasons have been posted already by a couple of us).

And how about a hotkey to quit compiling? :D

Another new feature I am adding is a new style of pointer referencing.  For any variable or static pointer you can now write {__+A} as A(__).  and {__*2+A}r as A(__)r.  Here, the variable A can also be a ram location like L1, a static pointer like Str1, and possibly a file object like Y1 if I can get that to work.  That means things like L1(7) means the same thing as in basic as it does in Axe; the 7th item in L1's memory.  I think this form will make pointers easier for beginners to understand and reduce pointer related errors.

That makes sense, and it would make arrays so much easier to understand and use :)
Title: Re: Features Wishlist
Post by: calc84maniac on May 07, 2011, 10:33:22 pm
That means things like L1(7) means the same thing as in basic as it does in Axe; the 7th item in L1's memory.
Well, actually the 8th item (unless you plan on starting with 1 instead of 0 for arrays, which of course wouldn't be a great idea from a low-level programming perspective)
Title: Re: Features Wishlist
Post by: ztrumpet on May 07, 2011, 10:34:27 pm
Here's one that I think would be pretty useful and easy to implement: custom interrupts that call the OS interrupt handler before starting or upon finishing. This would allow programmers to use commands like getKey or getKeyr with custom interrupts enabled, which could be very useful. Perhaps fnInt(LBL,FREQ)r? If they wanted they could actually use this to speed up arrow key repeats as well.
I think this is a great idea as well.

I'm for closing the parenthesis; since some commands already require it, I think it should be universal.

The new syntax sounds neat. ;D
Title: Re: Features Wishlist
Post by: Freyaday on May 07, 2011, 10:36:17 pm
Another new feature I am adding is a new style of pointer referencing.  For any variable or static pointer you can now write {__+A} as A(__).  and {__*2+A}r as A(__)r.  Here, the variable A can also be a ram location like L1, a static pointer like Str1, and possibly a file object like Y1 if I can get that to work.  That means things like L1(7) means the same thing as in basic as it does in Axe; the 7th item in L1's memory.  I think this form will make pointers easier for beginners to understand and reduce pointer related errors.
Sweetness!
Title: Re: Features Wishlist
Post by: Munchor on May 08, 2011, 08:22:29 am
@Quigibo: All that looks cool and here's my text on parentheses:

If we are not forced to use parentheses then we won't use them sometimes (like I used to) and then some stuff goes wrong  (this happened to me) and I had no idea why! since everything made sense. If parentheses are forced, it makes code cleaner and more universal among other languages. I think all commands should require them and even on If's they should exist like :If (X=88):.DO THIS:End.
Title: Re: Features Wishlist
Post by: Deep Toaster on May 08, 2011, 11:40:11 am
Wait, even on Ifs and Disps and things like that? Remember Python doesn't even enforce them for those. The commands with a space with them are meant to have a different interface IMO.

EDIT: Unless you make Axe Tokens get rid of the spaces and replace them with (, but I doubt that's practical.
Title: Re: Features Wishlist
Post by: ztrumpet on May 08, 2011, 11:41:27 am
Wait, even on Ifs and Disps and things like that? Remember Python doesn't even enforce them for those. The commands with a space with them are meant to have a different interface IMO.
Yeah, I think this is the way to do it as well.  I only think it should be only after a '('.
Title: Re: Features Wishlist
Post by: Munchor on May 08, 2011, 04:44:01 pm
Wait, even on Ifs and Disps and things like that? Remember Python doesn't even enforce them for those. The commands with a space with them are meant to have a different interface IMO.

EDIT: Unless you make Axe Tokens get rid of the spaces and replace them with (, but I doubt that's practical.

I didn't say Disps, did I?
Title: Re: Features Wishlist
Post by: Admiral-Bell on May 08, 2011, 05:27:21 pm
Wait, even on Ifs and Disps and things like that? Remember Python doesn't even enforce them for those. The commands with a space with them are meant to have a different interface IMO.

EDIT: Unless you make Axe Tokens get rid of the spaces and replace them with (, but I doubt that's practical.

Yes, python does require parentheses for it's display command. You don't need them for if, but print() is a function and python always requires parentheses for functions. Unless, of course, you are still using python 2.x, but at this point you really should be using 3.x
Title: Re: Features Wishlist
Post by: Deep Toaster on May 09, 2011, 09:37:50 am
Wait, even on Ifs and Disps and things like that? Remember Python doesn't even enforce them for those. The commands with a space with them are meant to have a different interface IMO.

EDIT: Unless you make Axe Tokens get rid of the spaces and replace them with (, but I doubt that's practical.

I didn't say Disps, did I?

If you enforce it on some commands that end in a space but not others, you create a UI disconnect which is always a bit annoying :(
Title: Re: Features Wishlist
Post by: ZippyDee on May 09, 2011, 09:40:34 am
I have to agree with Deep Thought on this one...If you're going to require something, make it a uniform requirement. Also, make sure it's a logical requirement... I personally think If statements are fine the way they are. However, I can understand adding parentheses to other commands that already prompt you for parentheses such as For( and Output(.
Title: Re: Features Wishlist
Post by: aeTIos on May 09, 2011, 09:42:49 am
My wish: Axe does only include routines in included files if they're called. All routines end in return, so it won't be too hard to implement....
Title: Re: Features Wishlist
Post by: Freyaday on May 09, 2011, 09:43:05 am
How about an option to enforce it or not?
The reason I'm against it is because Axe programs need so much space that any savings are precious, and I've saved hundreds of bytes by writing my code to eliminate as many closing parenthesis as possible
Title: Re: Features Wishlist
Post by: ZippyDee on May 09, 2011, 09:49:43 am
My wish: Axe does only include routines in included files if they're called. All routines end in return, so it won't be too hard to implement....
Not true...sometimes people end routines in Goto. It's certainly not as simple as just looking for a return after a label. There's a lot more that has to be taken into account.
Title: Re: Features Wishlist
Post by: aeTIos on May 09, 2011, 09:51:45 am
But real routines are called via sub(. If they end in a goto, you cant call it via sub( or your program cant be closed... (I have experienced this several times when I learned axe xD)
Title: Re: Features Wishlist
Post by: ZippyDee on May 09, 2011, 09:53:07 am
Unless it goes to another routine that has a return...
Title: Re: Features Wishlist
Post by: Freyaday on May 09, 2011, 09:54:49 am
Oh, a way to make the backup create a new backup under a different name, so that when you're trying something new and you're not sure if it'll work or if you'll like it, you can have the old one backed up and in case you do or it does, you have the new one backed up as well.
Title: Re: Features Wishlist
Post by: aeTIos on May 09, 2011, 10:26:51 am
Yeah, thats a good idea!
Title: Re: Features Wishlist
Post by: collechess on May 09, 2011, 07:55:57 pm
Line(-1,x1,y1,x2,y2) or Line(-1,x1,y1,x2,y2)T

Erases a line from (x1,y1) to (x2,y2)
Title: Re: Features Wishlist
Post by: Michael_Lee on May 09, 2011, 08:40:41 pm
A workaround:

Invert the screen, use Line(), then invert the screen again?

Code: [Select]
DrawInv
Line(x1,y1,x2,y2)
DrawInv


Title: Re: Features Wishlist
Post by: Compynerd255 on May 10, 2011, 10:33:18 am
A workaround:
Invert the screen, use Line(), then invert the screen again?
Code: [Select]
DrawInv
Line(x1,y1,x2,y2)
DrawInv
But that's hecka slow. I know that TI-BASIC allows you to draw both white and black lines with the fifth argument: Line(x1, y1, x2, y2, color). But this workaround does work until that update is made.
Title: Re: Features Wishlist
Post by: Freyaday on May 11, 2011, 08:47:43 pm
Some way to get the current position of the Text cursor.
Maybe something like
Text ->X
Would make X the format used by Text(X), And
Text ->X,Y
Would be what is used in Text(X,Y)
Title: Re: Features Wishlist
Post by: ztrumpet on May 11, 2011, 09:07:01 pm
{E86D7}r->X should do Text->X
{E86D7}->X and {E86D8}->Y should do Text->X,Y
Title: Re: Features Wishlist
Post by: Compynerd255 on May 12, 2011, 12:03:13 pm
{E86D7}r->X should do Text->X
{E86D7}->X and {E86D8}->Y should do Text->X,Y
Are those BCALLS, or are they memory locations?

Oh, and I have a feature request that I think we would all love: Defining tokens as constants. Simply put,
Code: [Select]
9000→X
X+9000→X
If X>9000
Disp "Its over 9000!"
End
could be
Code: [Select]
#Define(Xmin, 9000)
Xmin→X
X+Xmin→X
If X>Xmin
Disp "Its over 9000!"
End
Then, symbols could be defined relative to each other, as in ASM, and then we could also do other things with it as well. Symbols could also be undefined, and redefined later in the program.
A way you could code it:
- When a #Define instruction is encountered in the program, it reserves one of the spaces used for 32 Axiom commands to store up to 32 symbol definitions (limiting the user to 4 Axioms).
- Every time the token is encountered, the number is parsed instead.
- When an #Undefine is encountered, simply remove the symbol.
Title: Re: Features Wishlist
Post by: ztrumpet on May 12, 2011, 03:21:52 pm
{E86D7}r->X should do Text->X
{E86D7}->X and {E86D8}->Y should do Text->X,Y
Are those BCALLS, or are they memory locations?
Memory locations.
Oh, and I have a feature request that I think we would all love: Defining tokens as constants. Simply put,
Code: [Select]
9000→X
X+9000→X
If X>9000
Disp "Its over 9000!"
End
could be
Code: [Select]
#Define(Xmin, 9000)
Xmin→X
X+Xmin→X
If X>Xmin
Disp "Its over 9000!"
End
Then, symbols could be defined relative to each other, as in ASM, and then we could also do other things with it as well. Symbols could also be undefined, and redefined later in the program.
A way you could code it:
- When a #Define instruction is encountered in the program, it reserves one of the spaces used for 32 Axiom commands to store up to 32 symbol definitions (limiting the user to 4 Axioms).
- Every time the token is encountered, the number is parsed instead.
- When an #Undefine is encountered, simply remove the symbol.
I second the request.  It's a great idea. :)
Title: Re: Features Wishlist
Post by: yrinfish on May 12, 2011, 03:29:26 pm
I like that idea, but not #Define but #def because that fits better, and maybe other symbols that are shorter...
Title: Re: Features Wishlist
Post by: Compynerd255 on May 12, 2011, 03:57:28 pm
I like that idea, but not #Define but #def because that fits better, and maybe other symbols that are shorter...
Good point. Maybe for the hijacked BASIC tokens we could use nPr and nCr (#Def and #Undef respectively).
Title: Re: Features Wishlist
Post by: ZippyDee on May 12, 2011, 04:06:14 pm
I understand the use for a #def token, but I don't really understand why you'd need #undef...
By being able to reassign a value to a CONSTANT, it's no longer CONSTANT. That makes it function just like any other variable, I'd think... Am I wrong?
Title: Re: Features Wishlist
Post by: Runer112 on May 12, 2011, 04:28:02 pm
The problem with this is the limited RAM space Axe has when compiling, and it already uses pretty much all of it. It would be a great feature, but it would be difficult to be implemented.
Title: Re: Features Wishlist
Post by: Deep Toaster on May 12, 2011, 06:58:50 pm
Another reason for Axe to enforce parentheses:

Quote from: OmnomIRC
[16:47:34] <+Hot_Dog> wow, it's still not working
[16:47:51] <+Hot_Dog> even on hardware
[16:48:40] <+Hot_Dog> I just don't know
[16:48:55] <+Runer112> what does the source code look like
[16:48:59] <+Runer112> for your test program
[16:49:19] <+Hot_Dog> .ABC : AsmComp(AXIOM : 9
[16:49:30] <+Runer112> umm
[16:49:35] <+Runer112> add an ending parenthesis maybe?
[16:49:51] <+Hot_Dog> indeed, forgot that
[16:49:56] <+Hot_Dog> that was the problem all alone
[16:49:59] <+Hot_Dog> *along
[16:50:01] <+Runer112> wait
[16:50:03] <+Runer112> did that fix it?
[16:50:07] <+Hot_Dog> yes it did
[16:50:08] <+Runer112> lol
[16:50:20] * +Hot_Dog bangs head against wall again
[16:50:21] <@DThought> And that is why I think Quigibo should enforce it :/
[16:50:26] <+Runer112> and this is why Axe sorely needs to force parenthesis closing
[16:50:36] <+Runer112> so many bugs caused by open parentheses
[16:50:38] <@DThought> Ninja'd, Runer.

It just adds another thing to remember when debugging sometimes :-\
Title: Re: Features Wishlist
Post by: Hot_Dog on May 12, 2011, 07:07:08 pm
Another reason for Axe to enforce parentheses:

Quote from: OmnomIRC
[16:47:34] <+Hot_Dog> wow, it's still not working
[16:47:51] <+Hot_Dog> even on hardware
[16:48:40] <+Hot_Dog> I just don't know
[16:48:55] <+Runer112> what does the source code look like
[16:48:59] <+Runer112> for your test program
[16:49:19] <+Hot_Dog> .ABC : AsmComp(AXIOM : 9
[16:49:30] <+Runer112> umm
[16:49:35] <+Runer112> add an ending parenthesis maybe?
[16:49:51] <+Hot_Dog> indeed, forgot that
[16:49:56] <+Hot_Dog> that was the problem all alone
[16:49:59] <+Hot_Dog> *along
[16:50:01] <+Runer112> wait
[16:50:03] <+Runer112> did that fix it?
[16:50:07] <+Hot_Dog> yes it did
[16:50:08] <+Runer112> lol
[16:50:20] * +Hot_Dog bangs head against wall again
[16:50:21] <@DThought> And that is why I think Quigibo should enforce it :/
[16:50:26] <+Runer112> and this is why Axe sorely needs to force parenthesis closing
[16:50:36] <+Runer112> so many bugs caused by open parentheses
[16:50:38] <@DThought> Ninja'd, Runer.

It just adds another thing to remember when debugging sometimes :-\

Yeah, I spent 2 days trying to find a bug that turned out to be just one missing parenthesis at the end
Title: Re: Features Wishlist
Post by: Michael_Lee on May 12, 2011, 08:04:25 pm
Question:
What exactly happens if I leave a parenthesis open?  Obviously, it'll start glitching the program up, but in what ways?  What precisely does it do to the code?
Title: Re: Features Wishlist
Post by: Quigibo on May 12, 2011, 08:05:46 pm
Actually, constant definitions would be very easy to do and are already implemented, kind of.  That's exactly what Str1, Pic1, GDB1 are!  They just hold a constant value that happens to be a ram location.  But I could easily allow the programer to specify other values for these constants and the syntax would be very intuitive:

9001->Str1

This would use symbol space though, so its still limited to ~150 static variables including the regular static pointers.  Bun nonetheless, still generally useful since I don't think that many people actually run out of symbol space. 

EDIT:
Question:
What exactly happens if I leave a parenthesis open?  Obviously, it'll start glitching the program up, but in what ways?  What precisely does it do to the code?
Axe will add the parenthesis for you at the end of the line.  So if you had:

sin(A+cos(B->C

It becomes:

sin(A+cos(B->C))

Instead of what you might be trying to do:

sin(A+cos(B))->C
Title: Re: Features Wishlist
Post by: squidgetx on May 12, 2011, 08:18:31 pm
I use all my symbols >8)

Anyway, sounds cool anyway. As for parentheses forcing, I think that it seems like a good idea, but I never close any of my pt-on('s for example....I think it is fine to leave it as it is. Last thing I want is to be hit with >9000 compile errors just because a bunch of Pt-On('s or Text('s were left unclosed :P I don't know, I'm sure it will definitely help some people  though. Maybe have it as an option?
Title: Re: Features Wishlist
Post by: Runer112 on May 12, 2011, 08:24:28 pm
Quigibo, if you add constant definitions to Axe programming, could you perhaps add it to Axiom programming as well? That's something I always thought would be quite useful. Perhaps add a new command type, AXM_CONST, that has a 2-byte value instead of a routine? And something that would be even more awesome is a type like AXM_VAR, that allows you to define custom variables that are fully compatible with variable auto-optimizations and dereferencing. Again, you'd probably want the routine data to be replaced by a 2-byte value, in this case a pointer to the variable.

EDIT: And while I'm talking about Axiom feature requests, I want to bump my request for support for offset calls. :)
Title: Re: Features Wishlist
Post by: Freyaday on May 12, 2011, 09:15:54 pm
I'm trying to figure out what the purpose is behind these constants. Wouldn't it just be the same thing as, say, putting in the number?
Title: Re: Features Wishlist
Post by: ztrumpet on May 12, 2011, 09:29:00 pm
I'm trying to figure out what the purpose is behind these constants. Wouldn't it just be the same thing as, say, putting in the number?
Yes, but it's easier if you change something.  For instance, let's say you have a piece of code that draws a tilemap to the screen that's 8*12 sprites large.  But what if you wanted to add a HUD to the side of the screen and make it 8*10?  Then you'd have to find all of those 12s in your code and change them to 10s.  Or you could have used the (hopefully) soon to be Axe equivalent of a #define() when you wrote the code in the first place, so all you'd have to do is change the line with the #define() in it from a 12 to a 10 to fix all of those lines of code.
Title: Re: Features Wishlist
Post by: Freyaday on May 12, 2011, 09:55:10 pm
Aha.
N^^M to do signed modulus
Title: Re: Features Wishlist
Post by: Michael_Lee on May 12, 2011, 09:56:18 pm
I'm trying to figure out what the purpose is behind these constants. Wouldn't it just be the same thing as, say, putting in the number?
Yes, but it's easier if you change something.  For instance, let's say you have a piece of code that draws a tilemap to the screen that's 8*12 sprites large.  But what if you wanted to add a HUD to the side of the screen and make it 8*10?  Then you'd have to find all of those 12s in your code and change them to 10s.  Or you could have used the (hopefully) soon to be Axe equivalent of a #define() when you wrote the code in the first place, so all you'd have to do is change the line with the #define() in it from a 12 to a 10 to fix all of those lines of code.

Question: Why not just pick a random spot in memory near the end of a buffer or pick a variable, store the number, and resolve never to modify it?
Title: Re: Features Wishlist
Post by: Builderboy on May 12, 2011, 10:02:28 pm
Because then it's read as a variable and not a constant, and will result in larger code :)
Title: Re: Features Wishlist
Post by: Quigibo on May 12, 2011, 11:50:45 pm
By the way, I finished adding the request for constants.  It was only about 10 lines of code extra.  :)
It works really nicely too!  You can even add, subtract, multiply, and divide constants with each other to make new constants, all with nothing added to the executable code!

I've added so many new features and bug fixes, probably the largest update so far, but I don't know if I'll have time for everything I was planning by tomorrow's release.  Of the most complicated new additions that I have yet to make and am not sure about making yet are: stack operators, alternative referencing syntax, and native register operations.
Title: Re: Features Wishlist
Post by: ralphdspam on May 13, 2011, 12:02:45 am
Cool!  I can't wait until the next release. :)
Title: Re: Features Wishlist
Post by: Freyaday on May 13, 2011, 01:55:26 am
Amazing work Quigibo! I can't wait for 0.5.2!
Title: Re: Features Wishlist
Post by: Munchor on May 13, 2011, 10:23:35 am
Quote
ERR: BLOCK Either an “End” is missing you you have too many “End”s.

This is from documentation.pdf. What if there is an ERR for too many "End"s and an error for not enough?
Title: Re: Features Wishlist
Post by: Compynerd255 on May 13, 2011, 10:29:14 am
Quote
ERR: BLOCK Either an “End” is missing you you have too many “End”s.

This is from documentation.pdf. What if there is an ERR for too many "End"s and an error for not enough?
That's actually a good idea. One feature request I have is, when Axe encounters an error, it actually keeps going, looking for all the errors, and then lets you go to any of the error. Then, if all of the errors have the same, underlying cause, you can fix it. (This once happened to me in a C# program. I put a closing bracket in the wrong place, yielding hundreds of errors simply because my code was outside of legal programming space.) Also, this would let you have warnings (nonfatal errors such as unclosed parentheses, incorrect arguments in a subroutine, over 8811 bytes of code, and whatnot).
Title: Re: Features Wishlist
Post by: lookitsan00b on May 13, 2011, 04:45:10 pm
Quote
ERR: BLOCK Either an “End” is missing you you have too many “End”s.

This is from documentation.pdf. What if there is an ERR for too many "End"s and an error for not enough?
Just wondering: could it also be caused by too many (but the correct amount) of ends?
Its the only thing I can think of to cause an err:block in one of my recent situations...
Spoiler For problem area/pseudocode:
Code: [Select]
Repeat
 For
  If
  ElseIf
  ElseIf
  ElseIf
  ElseIf
   If
    For
     If
      If
       If
       ElseIf
       ElseIf
       ElseIf
       ElseIf
       ElseIf
        If
        ElseIf <-- err:block here
        ElseIf
        End
       ElseIf
       End
      End
     End
    End
   End
  ElseIf
  End
 End
End
I may have forgotten a couple :P
I managed to fix it by swapping some elseifs for if's placed end to end... (and changing elseifs to elses) but I wanna add more elseifs!

... and all those elseifs.... are actually "Else!If -1"s. Any chance of a selection structure ??? :D
Title: Re: Features Wishlist
Post by: Runer112 on May 13, 2011, 04:49:47 pm
You can only have a certain number of nested conditionals before the parser no longer has enough RAM to keep track of them and is forced to throw an ERR: BLOCK. You can manually make ElseIf analogs that don't use nested conditionals by doing something like the following. They will result in the same compiled code too, so you don't have to worry about the fix bloating your code.

Code: (Uses nested conditionals) [Select]
If -1
 
 .Stuff
 
ElseIf -1
 
 .Stuff
 
ElseIf -1
 
 .Stuff
 
ElseIf -1
 
 .Stuff
 
End
   
Code: (Doesn't use nested conditionals) [Select]
If -1
 .Stuff
 Goto END
End
If -1
 .Stuff
 Goto END
End
If -1
 .Stuff
 Goto END
End
If -1
 .Stuff
 Goto END
End
Lbl END

Alternatively, if you're using 3 or more ElseIfs in a row, it's optimal to turn the whole chain into a subroutine, like this:

Code: [Select]
sub(IF)

Lbl IF
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
 If -1
  .Stuff
  Return
 End
Return
Title: Re: Features Wishlist
Post by: lookitsan00b on May 13, 2011, 04:58:25 pm
aaww... I figured that was it. I guess I cant add any more types then... or can I use a subroutine to get around it :D ???

But still, only 19 types? thats nowhere near enough... especially since its already causing problems with 7 :P

Still hoping for a selection structure though :D

EDIT: ok thanks, although I was just thinking to move the whole if/elseif block into a subroutine :P
Title: Re: Features Wishlist
Post by: Deep Toaster on May 15, 2011, 08:32:28 pm
If you need more than 19, maybe you could find some way to wrap it in a loop instead? Sort of like a switch statement?
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 04:35:31 pm
A way to check if any key is pressed except a particular key.
I'll use 5 (a nonexistent key) for the following examples
Code: [Select]
not(getkey(5))activates when no key is pressed
Code: [Select]
not(getkey(5)) and (getkey(0)) will not activate when 5 is pressed, even when there are other keys being pressed at the same time
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 04:37:15 pm
doesn't those code examples work anyway? o.O
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 04:40:36 pm
They do not produce the desired behavior, and I also have another request:
The complement of this, a way to check if a specific key, and only that specific key, is pressed.
Any code I can come up with has the same problems as above
Title: Re: Features Wishlist
Post by: Runer112 on May 16, 2011, 04:44:15 pm
The second code example you posted already works. But while checking for individual keys or any key is easy, what you suggest is not nearly as easy. This is a good example of the kind of function that could be useful in an Axiom, but isn't really needed enough (especially for its relative complexity compared to other key commands) to warrant making it a built-in feature.
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 04:50:39 pm
Try If not(getKey(5)) and (getKey(0)!=0) for the first one, it seems to provide the results you are looking for.  The documentation specifies that getKey(0) does not return 0 or 1, merely a nonzero number.  For the second, I can't think of a way to do it in axe, so that might be a worthy addition
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 04:53:13 pm
I have two more Ideas:
An option to show the list of variables a program uses
And a Widow command, think of scrolling around a pic that's bigger than your computer screen, something like Window(Pointer to start of data,Width of pic, Highth of pic, x-coordinate of start, y-coordinate of start
Where start is the coordinate in the too-big pic that will be mapped to 0,0
And also Window()r
And StoreWindow() which would take the same arguments, but put the screen onto the pic instead of the other way around. And, of course, StoreWindow()r
Title: Re: Features Wishlist
Post by: Runer112 on May 16, 2011, 04:57:27 pm
To be fair, I can't think of how these features would be terribly useful. I've never encountered a game or program that tells me to press any key except ENTER, or a game that tells me to press ENTER and not touch any other keys. If you can suggest a good use for it to me, then I will submit that it could be useful as a built-in feature.
Title: Re: Features Wishlist
Post by: Binder News on May 16, 2011, 04:59:11 pm
I would love a switch statement. Just throwing that out there.
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 05:04:13 pm
To be fair, I can't think of how these features would be terribly useful. I've never encountered a game or program that tells me to press any key except ENTER, or a game that tells me to press ENTER and not touch any other keys. If you can suggest a good use for it to me, then I will submit that it could be useful as a built-in feature.
Avoiding the hardware's three-corners bug.
Also, I edited my post.
EDIT: Edited it even further.
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 05:06:08 pm
How would that bypass the 3 corners bug?
Title: Re: Features Wishlist
Post by: Runer112 on May 16, 2011, 05:08:53 pm
You can "avoid" the three-corners bug already by checking the key you want to check and then making sure the 3 corner keys aren't all pressed as well. For instance:
Code: [Select]
getKey(47) and not(getKey(48) and getKey(40) and getKey(39))

Although in reality you're not avoiding the bug, you're just changing how it works. Without the fix, pressing the 3 corner keys but not the key you want will result in a false positive. But on the other side of the coin, with the fix, pressing 2 of the corner keys as well as the key you want will result in a false negative.
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 05:10:03 pm
Yeah, since it is in hardware, there really isn't any way to fix the 3 corners bug :/
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 05:13:36 pm
There are multiple sets of three corners that can set it off, and checking for all of them would be far larger than just checking if only that key is pressed. Also, things get surreal once you start pressing in the top five rows of keys.
In case you're wondering, I made a program for the explicit purpose of investigating this bug
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 05:15:22 pm
There are multiple sets of three corners that can set it off, and checking for all of them would be far larger than just checking if only that key is pressed.

Except thats exactly what the routine would have to do if implemented, check every single key.  Like Runer said, I think this is a pretty specific request, and might be better suited as an axiom because of its size and complexity.
Title: Re: Features Wishlist
Post by: Freyaday on May 16, 2011, 05:18:20 pm
Why must everything be an Axiom?
I also find it interesting that noone's commented on my Window() suggesstion
Title: Re: Features Wishlist
Post by: ztrumpet on May 16, 2011, 05:20:36 pm
There are multiple sets of three corners that can set it off, and checking for all of them would be far larger than just checking if only that key is pressed. Also, things get surreal once you start pressing in the top five rows of keys.
In case you're wondering, I made a program for the explicit purpose of investigating this bug
Like this? http://ourl.ca/7652 :D
Why must everything be an Axiom?
I also find it interesting that noone's commented on my Window() suggesstion
It's because you're requesting specialized stuff that could be built with Axe's built-in routines.  In other words, you're more-so requesting sub-routines and not actual commands. ;) Edit: Or look at the post below for a better explanation.
Title: Re: Features Wishlist
Post by: Builderboy on May 16, 2011, 05:23:28 pm
It's because you're requesting specialized stuff that could be built with Axe's built-in routines.  In other words, you're more-so requesting sub-routines and not actual commands. ;)

His specific command couldn't be written with Axe actually, without some sort of brute forcing of the getKey(A) command.  But we are not saying everything must be an axiom, we are saying things that have very specific uses should be made into Axioms.  Quigibo wanted Axe to have all the general use commands that programmers would use on a regular basis.  He also knew he could never fill all of the requests, and so he created the Axiom system specifically for cases like these, where there is a definite need for a new routine from a programmer, but that routine isn't general enough to be included into the Parser himself. 
Title: Re: Features Wishlist
Post by: DJ Omnimaga on May 16, 2011, 05:31:08 pm
I'M glad to see a new version out Quigibo :D
Title: Re: Features Wishlist
Post by: Deep Toaster on May 21, 2011, 07:11:41 pm
:w00t: Some of these commands are really getting useful.
Title: Re: Features Wishlist
Post by: Darl181 on May 21, 2011, 11:38:27 pm
Maybe a button in the program/compile list which jumps straight to the start of the backup files?  It could be the plus key or something.
Title: Re: Features Wishlist
Post by: Hot_Dog on May 26, 2011, 11:33:44 pm
Did you add ++ and -- for increasing and decreasing like C++?  Those would be nice
Title: Re: Features Wishlist
Post by: Runer112 on May 27, 2011, 08:55:58 am
I believe the reason computer languages introduced the ++ function is because it produced more optimized code. However, on the z80, incrementing a 2-byte value with C+1→C is already the most optimized way to do so. I guess it could be added to produce slightly smaller source code, but it wouldn't be adding any optimization.
Title: Re: Features Wishlist
Post by: calc84maniac on May 27, 2011, 09:23:13 am
It could be useful to make some sort of increase/decrease function for the one-byte pointer references.
Title: Re: Features Wishlist
Post by: Munchor on May 27, 2011, 09:25:52 am
I change variables inside loops quite often. In Axe, I don't know, but I do that a lot in pretty much every language.
Title: Re: Features Wishlist
Post by: Hot_Dog on May 27, 2011, 02:48:34 pm
Even though ++ and -- wouldn't optimize further, it sure speeds up coding time in my case.
Title: Re: Features Wishlist
Post by: Quigibo on May 27, 2011, 06:50:38 pm
It would certainly optimize with expressions though, even with 2 byte variables.  For example:

{A*12+B}r+1->{A*12+B}r

Can definitely be optimized with increment operators.  The r and the end of the brackets can tell the parser whether or not to use a 16-bit increment or an 8-bit one.  Variables are always assumed to be 16-bit, but you can still do the more optimized 8-bit increments via {oA}++  This is definitely a feature you will see soon.
Title: Re: Features Wishlist
Post by: Runer112 on May 27, 2011, 07:14:19 pm
Oh, I assumed ++ would only be an available operator for variables, as other programming languages use it. But I guess it makes sense from an optimization standpoint to allow it for one-byte values and complex pointers.

Now if only Axe supported conditional jumps based on the Z80's flags, we could make super optimized loops...
Title: Re: Features Wishlist
Post by: Deep Toaster on May 27, 2011, 07:19:50 pm
Is that another bump for GotoIf? I wholeheartedly second that :D
Title: Re: Features Wishlist
Post by: Runer112 on May 27, 2011, 07:20:41 pm
Actually it wasn't a bump for conditional Goto, but I still really want that as well. And of course conditional sub() would go hand in hand with it. At least sub() without arguments.
Title: Re: Features Wishlist
Post by: AngelFish on May 27, 2011, 07:24:06 pm
The only reason I ever change the counting variable in a for loop is to adjust the increment, which TI-BASIC allows you to do with the fourth argument (that Axe doesn't seem to support).

EDIT: GotoIf!  :)
Title: Re: Features Wishlist
Post by: Aichi on May 28, 2011, 06:43:17 am
What about an additional Backup option that enables backing up all used subprograms as well?
Title: Re: Features Wishlist
Post by: Munchor on May 28, 2011, 06:47:42 am
What about an additional Backup option that enables backing up all used subprograms as well?

I'd love that.
Title: Re: Features Wishlist
Post by: Hot_Dog on May 28, 2011, 08:09:18 pm
It would certainly optimize with expressions though, even with 2 byte variables.  For example:

{A*12+B}r+1->{A*12+B}r

Can definitely be optimized with increment operators.  The r and the end of the brackets can tell the parser whether or not to use a 16-bit increment or an 8-bit one.  Variables are always assumed to be 16-bit, but you can still do the more optimized 8-bit increments via {oA}++  This is definitely a feature you will see soon.

Quigibo, I see you added that.  Thank you thank you thank you!
Title: Re: Features Wishlist
Post by: Freyaday on May 28, 2011, 08:16:28 pm
Pxl-Command()->buffer
Including Pxl-Test
(Or, perhaps, Pxl-C(X,Y,PTR))
This one was suggested by Runer:
DispGraph(Buf1,Buf2)^r[r]

In fact, what about
DrawingCommand(args[,list of buffers to apply to]
Title: Re: Features Wishlist
Post by: Quigibo on June 01, 2011, 09:54:04 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Title: Re: Features Wishlist
Post by: calc84maniac on June 01, 2011, 10:05:34 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Don't touch the certificate. You'll thank me later. Might as well just have an optional app signer instead.
Title: Re: Features Wishlist
Post by: calcdude84se on June 01, 2011, 10:08:10 pm
In less depressing words, does anybody at all know completely how the certificate works besides BrandonW, who himself might not know everything?
Also, is there some system call you might hook into to validate it? If it exists, it seems safer than modifying the certificate.
Title: Re: Features Wishlist
Post by: Freyaday on June 02, 2011, 02:32:04 am
Some way to evaluate a string as an expression. Writing what amounts to a number menu is not fun.
Title: Re: Features Wishlist
Post by: ZippyDee on June 02, 2011, 02:36:42 am
str->expr evaluations would require huge routines and would end up making programs gigantic.
Title: Re: Features Wishlist
Post by: Freyaday on June 02, 2011, 03:53:57 am
Auto indenting
Title: Re: Features Wishlist
Post by: Compynerd255 on June 02, 2011, 12:44:44 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
Title: Re: Features Wishlist
Post by: Runer112 on June 02, 2011, 12:47:41 pm
Auto indenting

This is the kind of feature you'd want a custom program editor for. It would be incredibly hard if not impossible to achieve automatic indenting with just a hook, and it would probably noticeably slow down the program editor.
Title: Re: Features Wishlist
Post by: TIfanx1999 on June 02, 2011, 01:28:28 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
I got a good chuckle at this. In all seriousness though this is probably going be more trouble than it's worth.

Auto indenting

This is the kind of feature you'd want a custom program editor for. It would be incredibly hard if not impossible to achieve automatic indenting with just a hook, and it would probably noticeably slow down the program editor.

^
Ditto. You'd be modifying how the program editor displays lines on the fly. Also, since there is no scrolling, wouldn't that make things a bit cramped on only a 16 character display?
Title: Re: Features Wishlist
Post by: Builderboy on June 02, 2011, 01:29:24 pm
Not to mention the screen is rather small :P things would get bad looking very quickly.  This is the motivation I had a while back to make my own program editor, but it turned out to be quite a project :P
Title: Re: Features Wishlist
Post by: Hot_Dog on June 02, 2011, 01:45:45 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.


The certificate?  You brave soul.  I absolutely, positively had to unlock flash to get Crabcake to work, and even then, people suggested that I be very hesistant when proceeding.  Let alone touching the certificate
Title: Re: Features Wishlist
Post by: JosJuice on June 02, 2011, 03:16:57 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
You can't properly sign it on-calc if you don't modify the certificate.
Title: Re: Features Wishlist
Post by: calc84maniac on June 02, 2011, 04:30:02 pm
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
You can't properly sign it on-calc if you don't modify the certificate.
Sure you can. There's just a lot of maths involved to sign it properly, and Quigibo is interested in modifying the certificate so unsigned apps won't act weirdly.
Title: Re: Features Wishlist
Post by: Quigibo on June 02, 2011, 05:04:51 pm
Yeah, I tried ducksign recently and it signs apps on-calc in about 20 seconds (with a 15MHz calc) so speed is certainly not an issue and I could integrate a signer into Axe.  But I think setting the expiration count is more useful than actually signing it since the only reason to sign it is to transfer it to another calculator from your own calculator, while the expiration count affects the normal use of the program.  Although I still want an option for that eventually.
Title: Re: Features Wishlist
Post by: JosJuice on June 03, 2011, 02:08:33 am
I have a feature request.

I was thinking it would be cool if I could  O.Omodify the certificate pageO.O to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.
Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
You can't properly sign it on-calc if you don't modify the certificate.
Sure you can. There's just a lot of maths involved to sign it properly, and Quigibo is interested in modifying the certificate so unsigned apps won't act weirdly.
Ah, that's nice. But what's the purpose of modifying the certificate if we can sign apps without using it? Is it because signing an app is trickier/takes more time?
Title: Re: Features Wishlist
Post by: Hayleia on June 03, 2011, 12:02:39 pm
I'd like (if not already made, but I didn't find it, maybe I'm a noob) that the command
Line(X1,Y1,X2,Y2 ,0)
erases the line (draws a white line), as in Basic

I don't know either if it already is, but I thought about
"Automatic Power Down"
Title: Re: Features Wishlist
Post by: Ashbad on June 03, 2011, 01:53:34 pm
I don't believe there is a command to erase lines, and AFAIK I don't think it's going to be added onto the included commands anytime soon -- if would a great part of a line-drawing Axiom.

APD I believe is possible through either an Axiom and/or a small set of inline assembly opcodes.
Title: Re: Features Wishlist
Post by: Runer112 on June 03, 2011, 01:55:30 pm
APD is never turned off. It just is incapable of activating unless the OS has control of the calculator, which you can give to it by using getKeyr.
Title: Re: Features Wishlist
Post by: Freyaday on June 03, 2011, 03:05:45 pm
But wait, that's a bad Idea, because Axe's L1 is SaveSScreen, a set of 768 bytes that the OS dumps the screen into on an APD, and Axe's variables are located at the very end of L1.
Title: Re: Features Wishlist
Post by: Ashbad on June 03, 2011, 04:26:04 pm
But wait, that's a bad Idea, because Axe's L1 is SaveSScreen, a set of 768 bytes that the OS dumps the screen into on an APD, and Axe's variables are located at the very end of L1.

Well, it also depends, if you do #alloc() and you don't even use L1 (I personally never really touch it) then you're fine :)
Title: Re: Features Wishlist
Post by: Hot_Dog on June 05, 2011, 05:12:15 pm
Speaking of For( loops, I don't know if this has already been asked, but why isn't a 4 parameter allowed?  Even if it's just a constant increment or decrement, that would be really helpful
Title: Re: Features Wishlist
Post by: Quigibo on June 05, 2011, 06:19:49 pm
Speaking of For( loops, I don't know if this has already been asked, but why isn't a 4 parameter allowed?  Even if it's just a constant increment or decrement, that would be really helpful

The main reason is that the increment code has already been written by the 2nd argument so it would be hard to make that happen on the 4th argument.  I would have to do some really weird and difficult out of order parsing for that to work, and I don't want to make it the 2nd argument because that would be extremely confusing.

Also, I will probably be adding a new loop structure which unlike "Repeat" is literally a "Repeat".  The syntax is a one argument for loop For(Times):Code:End where it just does the loop however many times without using extra variables and is highly optimized (more so than Runer-style loops).  The only thing blocking me right now is those AWFUL "Goto" statements.  I now see why so many languages ban them, they make it really difficult to optimize since you can't use the stack in any loop that has a goto, otherwise you get memory leaks.  I am therefore banning the Goto instruction inside this new loop structure and possibly for-loops if it leads to an optimization there.  I mean you shouldn't be abusing gotos that way anyway so I'm hoping there won't be any compatibility issues with this.

And just to let developers know, I already added code to allow Axioms to hijack existing routines so they can call or jump into any routine at any entry point.  Beware when using this on native Axe commands though as some of them could change from version to version as new optimizations are found.  Speaking of which I've already found a few major optimizations with all sprite and pixel commands that should shed quite a few bytes off of programs, especially larger ones.
Title: Re: Features Wishlist
Post by: Runer112 on June 05, 2011, 06:24:45 pm
And just to let developers know, I already added code to allow Axioms to hijack existing routines so they can call or jump into any routine at any entry point.

 :w00t: :w00t: :w00t: :w00t:

The other stuff is cool too. Don't ban Goto use altogether though, I actually use it sometimes to produce optimized code. :P
Title: Re: Features Wishlist
Post by: Freyaday on June 05, 2011, 07:04:03 pm
If no Goto, then can we please have EndIf in For loops? And this new thingy, whatever it is?
Title: Re: Features Wishlist
Post by: Quigibo on June 05, 2011, 07:07:23 pm
That's already been around since I first added the EndIf, you can always use them in for loops ;)
Title: Re: Features Wishlist
Post by: Freyaday on June 05, 2011, 07:08:58 pm
That's already been around since I first added the EndIf, you can always use them in for loops ;)
Orly?/me did not know that
I have a super important feature request:
Continued Axe improvement after 1.0.0 is released.
Title: Re: Features Wishlist
Post by: Runer112 on June 05, 2011, 07:10:05 pm
That's already been around since I first added the EndIf, you can always use them in for loops ;)

Actually, you can't. Is this a bug then?

Also, I want to bump an old request for conditional Goto/sub(). :)
Title: Re: Features Wishlist
Post by: Freyaday on June 05, 2011, 07:11:09 pm
Oh, speaking of Subroutines, a way to end the program from within a subroutine.
Title: Re: Features Wishlist
Post by: Deep Toaster on June 05, 2011, 07:45:17 pm
Oh, speaking of Subroutines, a way to end the program from within a subroutine.

That's been suggested, but it's not something you'd usually see in ASM either. There is a way to do it, and I think someone posted code for it, hold on...

EDIT: Seems like you were the one who suggested it, and Runer did suggest a Returnr function: http://ourl.ca/4057/196059;topicseen#msg141935 Could that be added sometime? I can see it being useful, even if I don't use it myself.
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2011, 12:06:35 pm
I have a whole slew of compiler-side feature requests involving static pointers, constants, and labels (which I will henceforth collectively refer to as defines). I figure since Axe is nearing 1.0.0, compiler-side feature additions would be a decent priority. I will order them in what I believe would approximately be increasing difficulty to implement, which also happens to be increasing awesomeness.


EDIT: I just want to mention that I don't really need any of these features, so don't feel like you have to add all or even any of them. Although out of all of them, I would probably most like the third one. :)


First, could the parsing of defines be modified to accept lowercase letters?


Second, could static pointers and constants not require the first token to be a GDB, Pic, or Str token? I see this as being most easily implemented by allowing define references to be prefixed with an easily accessible token like i, which would dictate that what follows is a define and not a variable. Some sample code of old and new static pointers coexisting:
Code: [Select]
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E

!If GetCalc(iAPV,4096)→M
  Disp Str0E
  getKeyʳ
  Return
End


Third, in addition to user-defined constants, could there be user-defined variables? I realize this can sort of be emulated with code like {GDB0}r, but that wouldn't qualify for variable optimizations and would be a pain to type every time you wanted to use it. The easiest way I see this being done is by chaining it with the above suggestion. You would define them as a constant but would reference them with a prefix like var (the u token) or ?. It would even have built-in de-referencing! Some sample code:
Code: [Select]
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E
L₂→iMAP

!If GetCalc(iAPV,4096)→varMAP
  Disp Str0E
  getKeyʳ
  Return
End


Fourth, could unused tokens be turned into defines? When the initialization statement is reached, the token would be checked to confirm that it's not already a command or a define. It would then be added to the list of defines with the first "name" byte being an identifier that it is a token, something like 0. Then, when a reference to the token is reached and it does not match any commands, check the define array. I can also imagine an extension to this that would allow r modifiers to be tagged onto the token, setting flag bits in the first "name" byte. Instead of checking that the first "name" byte is 0 during parsing, you would check that the high six bits are 0.


Finally, this feature request would probably require some overhauling of the parser, but it would be incredible: using an extra RAM page while compiling on calculators that have one. With this, you could lift the static pointer and nested conditional limits to near-unreachable levels. You could even increase the maximum length of static pointers to a much more comfortable length like 8 characters and still have more than 10 times the number of available pointers than there are currently.
Title: Re: Features Wishlist
Post by: ztrumpet on June 08, 2011, 01:33:20 pm
That sounds really awesome, especially all of the extra page stuff.  I think all of Runer's suggestions are good ideas.  I hope they can be implemented. :D
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2011, 04:53:35 pm
Alright, I'll answer all of those :)

1. Yes, that would be be easy.  I remember trying to do this before though and I think there was some problem with it but I don't remember what it was so I'll try it again.  Right now, each symbol is 3 bytes and I'm already using that to store 4 characters via 6-bit compression.  With 26 uppercase, 26 lowercase, 10 digits, theta, and null, that exactly fills up the 64 allowed combinations.  So if there's some other character there I'm forgetting, that may have been the reason, but I guess I could scrap a letter or 2, however confusing that may be...

2. That would be easy, but I'm not sure about that token choice, that would be weird since its currently used in the newline.  I could instead use the pi token since I don't think my previous idea of using it for stack is going to work.

3. Also easy.  I just don't want to encourage them to be used too much though or you'll start to get out of symbols errors.  But I'll definitely implement this if I do the above.

4. I don't think so, there is no single table of all the tokens Axe uses, and when you include multiple Axioms, it would get even trickier.  Also, there's just too many places in the code where a token needs to be instantly recognized as variable, constant, or special character.

5. Love the idea, but I would hate to see someone not be able to compile others' source code just because they don't have an extra ram page.  I guess I can put that up for a poll maybe.  There was point where I was thinking of using extra ROM pages, which both calcs have, since the data is write-once anyway and I already have routines to unlock flash.  I'm pretty sure the 83/84s keep an entire sector open for nothing but temporary swap use, which I could clear and use myself.  That might be better, but I'll have to do more research to make sure its possible.

All these are reverse compatible with the current Axe version though so I could add them any time.  My highest priority right now is fixing things that are not going to be reverse compatible since I want to stop changing those after 1.0.0.
Title: Re: Features Wishlist
Post by: ztrumpet on June 08, 2011, 05:18:06 pm
5. Love the idea, but I would hate to see someone not be able to compile others' source code just because they don't have an extra ram page.  I guess I can put that up for a poll maybe.  There was point where I was thinking of using extra ROM pages, which both calcs have, since the data is write-once anyway and I already have routines to unlock flash.  I'm pretty sure the 83/84s keep an entire sector open for nothing but temporary swap use, which I could clear and use myself.  That might be better, but I'll have to do more research to make sure its possible.
I'm pretty sure the OS calls dibs on part of the extra RAM page, but it can be regenerated with a simple bcall, something like "generate app base page table," but shorter. :)
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2011, 05:45:35 pm
In response to Quigibo's responses:

1. Wait, you use 6-bit compression already? Why can I not make 4-character static pointers or labels then? Also, unless you define them to simply equal other characters, you're forgetting about the 30 GDB, Pic, and Str tokens.

2. Oops, totally forgot about the fact that it's already used for newline. Pi would be good then.

3. Yeah, I realize this could make the max symbols limit creep up quickly (See #5). But it would be a pretty nice feature nonetheless.

4. Okay, this wasn't even my idea and I didn't really care too much about seeing it implemented anyways. ;)

5. I was actually thinking about using the swap sector myself, but for some reason decided against it. But now that I think about it again, it should definitely be possible to use that to store defines because they are, as you said, write-once data and should therefore work perfectly. And I know it's possible to use the swap sector as your own person write-once storage. That's how calc84maniac backs up all the contents of RAM before running TI-Boy, by copying it all to the swap sector. Having 64KB of define storage space would be incredible. You could scrap name compression, increase the character limit to 8, and still fit over 5,000 symbols! Nobody would ever run out! ;D
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2011, 06:16:03 pm
Wait, you use 6-bit compression already? Why can I not make 4-character static pointers or labels then? Also, unless you define them to simply equal other characters, you're forgetting about the 30 GDB, Pic, and Str tokens.

The first character is either a "label", "label later", "GDB", "Pic", or "Str".  Pi will be added to that list when I add that.  The second character is either the first letter/number for labels, or the 0-9 for the Pic/Str/GDB.  Then there are only 2 characters left after that.  I see what you mean though, I could compress it more to get an extra character out of static pointers.  But if I do #5, I won't have that problem.

EDIT:  Also, if I use the swap sector, I could conceivably do the entire thing in one pass (including all those new pass features) O.O
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2011, 06:29:05 pm
EDIT:  Also, if I use the extra page, I could conceivably do the entire thing in one pass  O.O

You mean the extra RAM page? Or the swap sector? Because if you could do it with the swap sector that would be awesome because every calculator could use it. I figure you could use 1 16KB page to hold the defined constants and the remaining 3 pages to hold references waiting to be filled in.
Title: Re: Features Wishlist
Post by: calc84maniac on June 08, 2011, 06:29:30 pm
EDIT:  Also, if I use the swap sector, I could conceivably do the entire thing in one pass (including all those new pass features) O.O
How is that possible? Won't you need to have a 2nd pass to insert any previously unknown values?
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2011, 06:59:34 pm
With that much space, I could just store a list of pointers to places that need replacements later and then replace them all once the values are known at the end of parsing.
Title: Re: Features Wishlist
Post by: Runer112 on June 08, 2011, 07:55:41 pm
Super bonus 1.0.0 feature? ;D
Title: Re: Features Wishlist
Post by: ztrumpet on June 08, 2011, 09:32:41 pm
Super bonus 1.0.0 feature? ;D
Doooo it! ;D
* ZTrumpet is employing peer pressure.  And standing on a ladder whilst doing so. ^-^
Title: Re: Features Wishlist
Post by: Deep Toaster on June 08, 2011, 09:39:02 pm
EDIT:  Also, if I use the swap sector, I could conceivably do the entire thing in one pass (including all those new pass features) O.O

+++++++

That would be awesome. And fast.

EDIT: Which would be awesome.
Title: Re: Features Wishlist
Post by: ztrumpet on June 08, 2011, 09:40:53 pm
That would be awesome. And fast.

EDIT: Which would be awesome.
And fast.

Edit: I actually think it would compile at about the same speed.  Regardless, it'd still be awesome. :D
Title: Re: Features Wishlist
Post by: Quigibo on June 08, 2011, 10:14:18 pm
I guess the only side effect is that you can't run the Axe app when your batteries are low, but that's no big deal.  I'll try to get this done by next release.  Looks like label/variable names will be up to 7 characters long now and will allow ~2000 variables + labels per program (up from 3 characters and 150 of each right now).  This would also allow me to put all data after subroutines and allow forward declaration of ANY static pointer/constant.  It'll be quite an epic release indeed if I get this working.  Not to mention tons of optimizations I've already made that will affect nearly every program.

Get excited.  >:D
Title: Re: Features Wishlist
Post by: Darl181 on June 08, 2011, 10:25:36 pm
Win.
Will it be possible to use lowercase letters?
Title: Re: Features Wishlist
Post by: Deep Toaster on June 09, 2011, 12:03:26 am
I guess the only side effect is that you can't run the Axe app when your batteries are low, but that's no big deal.  I'll try to get this done by next release.  Looks like label/variable names will be up to 7 characters long now and will allow ~2000 variables + labels per program (up from 3 characters and 150 of each right now).  This would also allow me to put all data after subroutines and allow forward declaration of ANY static pointer/constant.  It'll be quite an epic release indeed if I get this working.  Not to mention tons of optimizations I've already made that will affect nearly every program.

Get excited.  >:D

:hyper:

1.0's gonna be a huge leap forward, wow.
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 12:05:11 am
I'm glad I made those suggestions, it sounds like parsing is going to get a major upgrade. ;D
Title: Re: Features Wishlist
Post by: Freyaday on June 09, 2011, 12:08:34 am
I guess the only side effect is that you can't run the Axe app when your batteries are low, but that's no big deal.  I'll try to get this done by next release.  Looks like label/variable names will be up to 7 characters long now and will allow ~2000 variables + labels per program (up from 3 characters and 150 of each right now).  This would also allow me to put all data after subroutines and allow forward declaration of ANY static pointer/constant.  It'll be quite an epic release indeed if I get this working.  Not to mention tons of optimizations I've already made that will affect nearly every program.

Get excited.  >:D
WinWInWInWInWInINWINWINIWNINWINIWNINWINWINIWNIWNINWINWINWINWINWINIWNIWNINWINOInhfzaruiognbvlasgbjlhuihnuiwehn!!!!AAAAAHAHAHAHHAHAHHAHAHAAHAHAHAHHAHAHAHHAHAHAHHAHAHAHHAAAAAQA!/me got too excited
But seriously: All of the drawing commands->buffer
Inverse drawing commands, and perhaps a new syntax:
drawing-command(All the necessary arguments, list of buffers onto which to draw this awesomeness)
^Would be AWESOME
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 12:18:54 am
Inverse/white drawing for commands that currently cannot might be nice. However, I'm not sure how being able to provide a whole list of buffers to apply a command to would be useful. I can't see why you'd want to apply the command to any more than two buffers in the first place, and if so, you can easily do something like:

Code: [Select]
Pt-On(expression→r₁,expression→r₂,expression→r₃)
Pt-On(r₁,r₂,r₃)ʳ

Because of how arguments are loaded and read, it wouldn't even be possible to optimize this much by combining the two into "one" command. Also, this is sort of a weird request in general, because the syntax style of applying a command to a list of buffers is strange.
Title: Re: Features Wishlist
Post by: Freyaday on June 09, 2011, 12:23:15 am
Well, ok then, but I'd like to see all the commands be able to be drawn to any buffer, because only the pt-commands can currently be done so, and It'd be so amazing to have the ability to send the rest of them to any buffer imaginable.
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 12:28:19 am
I voted no on the recent poll, in large part because I don't see any great alternatives, whether they are easily accessible or not. If you're worried about defines that start with lowercase b, you can always just add a rule that defines cannot start with a lowercase b. I doubt anybody would even know that such a rule exists if you did add it, because I think the chances of somebody making a define that starts with a lowercase b are pretty low.

However, if someone can suggest a decent alternative to the lowercase b, I might be willing to change my vote.
Title: Re: Features Wishlist
Post by: Freyaday on June 09, 2011, 12:30:39 am
pi?
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 12:31:52 am
I think pi is going to be used for a feature I suggested, hopefully coming up in 1.0. ;D Anyway pi doesn't seem like a very intuitive binary indicator, at least to me.
Title: Re: Features Wishlist
Post by: Quigibo on June 09, 2011, 12:45:52 am
Well I was thinking of changing an existing token to the percent sign, like assembly.  Probably the "Sci" token in the mode menu [mode]{right}[enter] which is the same amount of clicks away as [alpha][alpha]{B}.
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 12:53:28 am
Eh, it's not a terribly intuitive base token, but I guess there aren't many other available options.
Title: Re: Features Wishlist
Post by: Hot_Dog on June 09, 2011, 10:32:59 am
Pi may not be the most intuitive, but it is certainly easy to access.  Just two clicks away as opposed to looking through menus or even the catalog.
Title: Re: Features Wishlist
Post by: aeTIos on June 09, 2011, 10:36:23 am
also... pinary xD
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 04:48:11 pm
I think Quigibo and I both agree that π would be a good token for the following feature, as it is quickly accessible and will probably be used far more often than binary numbers.

Second, could static pointers and constants not require the first token to be a GDB, Pic, or Str token? I see this as being most easily implemented by allowing define references to be prefixed with an easily accessible token like π, which would dictate that what follows is a define and not a variable. Some sample code of old and new static pointers coexisting:
Code: [Select]
"appvTILEMAP"→πAPV
"Not enough RAM!"→Str0E

!If GetCalc(πAPV,4096)→M
  Disp Str0E
  getKeyʳ
  Return
End
Title: Re: Features Wishlist
Post by: Quigibo on June 09, 2011, 06:05:23 pm
Actually, Runer, pi is free now.  Here is my layout currently for custom variables:

L1+2->oMyVar
9001->MyVar
oMyVar->A
MyVar->A


So I am totally avoiding the "var" and "pi" tokens in favor of a much more intuitive and simple use of existing symbols.  I figure since writing AB doesn't make sense in a program to load the value of A and then the value of B, I might as well use that as a multi-character variable without needing a prefix.  Also the dereferencing token makes a lot of sense here since you are assigning the location of a variable, or the value of a constant.
Title: Re: Features Wishlist
Post by: Runer112 on June 09, 2011, 06:07:30 pm
Ah okay, that's great. I was going to suggest that originally, but figured the variable problem would make it too hard to implement.
Title: Re: Features Wishlist
Post by: calc84maniac on June 09, 2011, 06:20:15 pm
Would it be possible to chain variable declarations, like:
L1->oMyVar1+2->oMyVar2+1->oMyVar3

Would make it a lot easier to change the size of a variable or add/remove variables during development.
Title: Re: Features Wishlist
Post by: Quigibo on June 09, 2011, 06:36:34 pm
Would it be possible to chain variable declarations, like:
L1->oMyVar1+2->oMyVar2+1->oMyVar3

Would make it a lot easier to change the size of a variable or add/remove variables during development.

Ooo!  That's a cool idea.  You can definitely chain them line-to-line but I'll see if I can add it all on the same line.
Title: Re: Features Wishlist
Post by: TIfanx1999 on June 09, 2011, 06:42:44 pm
I guess the only side effect is that you can't run the Axe app when your batteries are low, but that's no big deal.  I'll try to get this done by next release.  Looks like label/variable names will be up to 7 characters long now and will allow ~2000 variables + labels per program (up from 3 characters and 150 of each right now).  This would also allow me to put all data after subroutines and allow forward declaration of ANY static pointer/constant.  It'll be quite an epic release indeed if I get this working.  Not to mention tons of optimizations I've already made that will affect nearly every program.

Get excited.  >:D
Just wanted to ask, but would this be compatible with the TI-83+ as well? Cross compatibility for all models should be a primary concern IMHO. :)
Title: Re: Features Wishlist
Post by: calc84maniac on June 09, 2011, 06:45:14 pm
Would it be possible to chain variable declarations, like:
L1->oMyVar1+2->oMyVar2+1->oMyVar3

Would make it a lot easier to change the size of a variable or add/remove variables during development.

Ooo!  That's a cool idea.  You can definitely chain them line-to-line but I'll see if I can add it all on the same line.
Also, would it be possible to define 1-byte variables, which automatically use the byte load/store operations? Maybe even be able to define as unsigned/signed as well.
Title: Re: Features Wishlist
Post by: Darl181 on June 10, 2011, 08:32:17 pm
Something that could be useful would be the ability to manually backup an archived source.  It gets kind of tiring having to unarchive every time I want to backup (at least, for the on-calc way) :P

EDIT: (quote from zstart thread)
A bug: using the on+enter shortcut to compile disables the auto-backup feature, because
Quote from: thepenguin77 on IRC
[18:27:38] <thepenguin77> [...] when compiling from the API entry point, the option is changed
Afaik, this would need the entry point to be modified to have another input...
Also having to do with the backup feature, a fix for ^ ;)
Title: Re: Features Wishlist
Post by: DrDnar on June 12, 2011, 01:34:00 am
Three suggestions: First, there should be a way to get a pointer to a label, allowing you to make jump tables and callbacks. Second, I am bumping the idea of a general-purpose b_call command mentioned a while back. Third, I am also bumping having an official way to exit a program (http://ourl.ca/4057/196230) at any time.

Edit: Moved some previous contents to routines thread. (http://ourl.ca/4129/218560)
Title: Re: Features Wishlist
Post by: Quigibo on June 12, 2011, 02:36:47 am
Reading labels as values is for sure coming in the next version.  But its mostly for Axioms that require labels as arguments because there really isn't any other use for them since you still can't jump to arbitrary values due to leaks and unsafe code.  I think I might have a way to allow programs to exit anywhere soon, but I already have to rewrite half of the parser from scratch so I doubt I'll have time next version.

For those other assembly commands, most of them are really too specific and low level for any general use.  Runer112 actually made an LCD Axiom LCD Kit (http://ourl.ca/9952) that does most of those already and you could certainly design a port axiom to allow arbitrary port writing, I just don't see the purpose of that for the average game.
Title: Re: Features Wishlist
Post by: DrDnar on June 12, 2011, 02:48:17 am
They could be used for using the crystal timers or clock, or doing something ridiculous like powering USB devices or protecting data with an MD5 hash or writing an undeleter in Axe.
Title: Re: Features Wishlist
Post by: Freyaday on June 12, 2011, 03:24:09 am
The ability to jump code execution to an arbitrary location.
Title: Re: Features Wishlist
Post by: Deep Toaster on June 12, 2011, 09:47:19 am
You can do that with Asm(9E):
Oh, and
  • Allowing jumping to an arbitrary place in memory
That can be done using a simple Asm(E9), which will jump to the address of the last result
In other words, E8000:Asm(9E) jumps to $8000.
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2011, 03:32:11 pm
You can do that with Asm(9E):
Oh, and
  • Allowing jumping to an arbitrary place in memory
That can be done using a simple Asm(E9), which will jump to the address of the last result
In other words, E8000:Asm(9E) jumps to $8000.
Look closer, it's actually E9. 9E is the SBC A,(HL) instruction.
Title: Re: Features Wishlist
Post by: Deep Toaster on June 12, 2011, 03:33:17 pm
Aw bleep, I did it backwards on my table and didn't notice :P
Title: Re: Features Wishlist
Post by: Freyaday on June 12, 2011, 07:33:22 pm
So I'd do GetCalc(code):Asm(9E)?
Title: Re: Features Wishlist
Post by: Deep Toaster on June 12, 2011, 07:37:05 pm
E9, as calc84maniac said.

But it's not that simple to jump straight to a different program. Remember you can't execute code beyond the hex address $C000 (that's why programs are limited to 8811 bytes, since 8811 is the difference between $C000 and $9D95, where programs normally start). Unless you're absolutely certain the program you're looking for isn't beyond $C000 (which is perfectly possible), you have a pretty high chance of getting a RAM clear with that code.
Title: Re: Features Wishlist
Post by: calc84maniac on June 12, 2011, 07:43:50 pm
E9, as calc84maniac said.

But it's not that simple to jump straight to a different program. Remember you can't execute code beyond the hex address $C000 (that's why programs are limited to 8811 bytes, since 8811 is the difference between $C000 and $9D95, where programs normally start). Unless you're absolutely certain the program you're looking for isn't beyond $C000 (which is perfectly possible), you have a pretty high chance of getting a RAM clear with that code.
In addition to that, all programs are assembled to run at $9D95. Run it from anywhere else and all of the absolute pointers (which is almost every pointer in Z80) will be wrong.
Title: Re: Features Wishlist
Post by: Deep Toaster on June 12, 2011, 07:46:05 pm
Aaand there's always the chance that it's in archive :)

EDIT: In other words, don't try it unless you really know what you're doing. I think there's a bcall(_ExecutePrgm) for that purpose.
Title: Re: Features Wishlist
Post by: Freyaday on June 12, 2011, 08:26:35 pm
And what's the asm for that, and can I execute code within an appvar?
Title: Re: Features Wishlist
Post by: Darl181 on June 16, 2011, 07:08:23 pm
I was wondering...the ability to use ! just before a var or whatever to check if it's false.  ie instead of having to do
If getKey(15) and (A=0)
...it would be possible to do something like...
If getKey(15) and (!A)

Or is VAR=0 already an auto-optimized thing?
Title: Re: Features Wishlist
Post by: calc84maniac on June 16, 2011, 07:10:05 pm
I was wondering...the ability to use ! just before a var or whatever to check if it's false.  ie instead of having to do
If getKey(15) and (A=0)
...it would be possible to do something like...
If getKey(15) and (!A)

Or is VAR=0 already an auto-optimized thing?
It's already optimized, but not as much as if you did
If getKey(15)
!If A
...
End
End


because it has to calculate the 0 or 1 boolean in order to perform the AND.
Title: Re: Features Wishlist
Post by: Darl181 on June 16, 2011, 07:45:27 pm
Ok, so just have them as separate statements if possible?  (with the least likely outermost so it runs through less checks)
Coll, I'll just do that ;D

(what I'm working on is adding movable objects to DS and I'm trying to make sure the getKeys and such don't mess with it :P
Title: Re: Features Wishlist
Post by: Deep Toaster on June 16, 2011, 09:14:43 pm
Ok, so just have them as separate statements if possible?  (with the least likely outermost so it runs through less checks)
Even if you don't use !, it's still more optimized to do something like
Code: (Axe) [Select]
:If A
:If B
:...
:Code here
:...
:End
:End
instead of
Code: (Axe) [Select]
:If A and B
:...
:Code here
:...
:End
Title: Re: Features Wishlist
Post by: Ashbad on June 16, 2011, 09:19:24 pm
One thing I would really love is to have some sort of global variable that can be used in an expression to represent the current location the PC is at, so that you could tell exactly where in the program memory you were.  This would mean you could make overlapping functions that HHS inner would do the function, the outer would simply return value of the PC at the beginning of the function.  This would be very, very useful for implementing crude OOP and Proc arrays.
Title: Re: Features Wishlist
Post by: ralphdspam on June 16, 2011, 11:23:59 pm
Can you add a For() loop that counts down?  (Like a 16 bit djnz)  Maybe For()r ?  That would be very useful.  :)
EDIT: I know there is DS<(), but that is a little bit different.
Title: Re: Features Wishlist
Post by: jnesselr on June 18, 2011, 09:16:25 pm
Can you add a For() loop that counts down?  (Like a 16 bit djnz)  Maybe For()r ?  That would be very useful.  :)
EDIT: I know there is DS<(), but that is a little bit different.
In extension to this, would it be possible to add a command that allows you to do something like For()r except it would check the two arguments, and if the first was larger than the second, it would count down instead of up.
Title: Re: Features Wishlist
Post by: Munchor on June 19, 2011, 12:30:19 pm
Can you add a For() loop that counts down?  (Like a 16 bit djnz)  Maybe For()r ?  That would be very useful.  :)
EDIT: I know there is DS<(), but that is a little bit different.
In extension to this, would it be possible to add a command that allows you to do something like For()r except it would check the two arguments, and if the first was larger than the second, it would count down instead of up.

I'm not sure if I'm right, so please correct me if not:

Isn't that the same thing as For(10,2,-1)? Or this can't be done?
Title: Re: Features Wishlist
Post by: jnesselr on June 19, 2011, 09:54:10 pm
Can you add a For() loop that counts down?  (Like a 16 bit djnz)  Maybe For()r ?  That would be very useful.  :)
EDIT: I know there is DS<(), but that is a little bit different.
In extension to this, would it be possible to add a command that allows you to do something like For()r except it would check the two arguments, and if the first was larger than the second, it would count down instead of up.

I'm not sure if I'm right, so please correct me if not:

Isn't that the same thing as For(10,2,-1)? Or this can't be done?
I'm pretty sure that can be done (I know it can in basic, well, assuming you include a variable in there) I was just thinking of having it do it automatically without the negative one.  Like if it was For(A,10,2)r it would count down, but For(A,2,10)r would count up.
Title: Re: Features Wishlist
Post by: alberthrocks on June 21, 2011, 01:31:07 pm
I don't know if this has been suggested yet, but can the Axioms get custom token support?
I don't think people (nor I) would enjoy writing down which token corresponds to which command... :P
It should be definable in the compiled file (obviously), and... accessible via a special menu.
(Omnicalc esque, where a button is pressed twice to access the menu OR some other method)

Also, can subroutines get custom token support too? (Basically, preparse the library file, and then make an accessible menu to access the new tokens)

I propose a format like this:
Code: [Select]
.LIBRARY [special identifier to indicate this program is a library]

.Fade.FadeIn may even make a "Axe Class" possible! But don't worry about that for now - this is just for organization.
#Token(Fade.FadeIn)
Lbl FIN
code here...

#Token(Blah)
Lbl BLA
code here...

Is this possible?
Title: Re: Features Wishlist
Post by: Ashbad on June 21, 2011, 01:52:38 pm
Token Support: already rejected
Those For Loops:  Why not just come up with your own Repeat or While loops?

Code: [Select]
Abs([num_of_Loops+1])
While -1 -> [var]
   .Code
   [var]
End

Which is a simple template that can be easily modded to fit your application-specific restraints.
Title: Re: Features Wishlist
Post by: Runer112 on June 23, 2011, 08:59:18 pm
Remove the scope restrictions on commands? I was just working on a pretty beastly optimization using the value returned by Copy() in the middle of a line, but Axe won't let me. :(

Also, do you think the /10 "optimization" should be removed? It results in smaller code, but also much slower code.
Title: Re: Features Wishlist
Post by: Quigibo on June 23, 2011, 11:57:28 pm
Remove the scope restrictions on commands? I was just working on a pretty beastly optimization using the value returned by Copy() in the middle of a line, but Axe won't let me. :(

Also, do you think the /10 "optimization" should be removed? It results in smaller code, but also much slower code.

The scope restriction I might remove for that command, the main reason I have it is because I don't want it used inline or else that implies that it has a defined return value (which is what you're trying to do) yet its still possible it could change in the future for a better optimization or something.  I don't think the Copy() command could possibly get more optimized though, but I'd at least have to change the documentation about it to describe the return value and also decapitalize the "C".

For division by 10, I figure that if you're dividing by a constant 10 you're most likely not using the division for speed critical math and are probably doing something with digits, which don't need to be fast generally.  If speed was really critical, you should be using one of the other auto-ops for division or just use /(10) instead of /10.
Title: Re: Features Wishlist
Post by: Freyaday on June 24, 2011, 02:13:12 am
Could BASIC's expr( be hijacked into providing a string->number routine?
Title: Re: Features Wishlist
Post by: Runer112 on June 24, 2011, 02:26:54 am
Yeah, the copy and fill commands definitely have calculable, consistent return values. And I don't think the routines could possibly be optimized any more, so these values probably won't change. Although if I could have it my way, I would completely remove scope restrictions. I often find myself seeing how my code could be more optimized with insane stuff like inline If statements.

Speaking of which... feature request: inline If statements? :) Many (most?) computer languages have them, so why not bring them to Axe?


Also, I don't think you need to change the capitalization of Copy() or Fill(). Other commands, like GetCalc() for instance, can be used inline but are capitalized. I think routines used solely for their return value should not be capitalized, but other commands should.
Title: Re: Features Wishlist
Post by: aeTIos on June 24, 2011, 06:42:13 am
What are inline if statements?
Title: Re: Features Wishlist
Post by: Munchor on June 24, 2011, 07:25:44 am
What are inline if statements?

I think it's like:

Code: [Select]
EndIf A>4
Title: Re: Features Wishlist
Post by: defmenge on June 24, 2011, 11:06:22 am
What are inline if statements?
An inline if statement returns one of two values depending on whether a condition is true or not.
Example (pretending it would be implemented in Axe as IIf(Condition,TrueValue,FalseValue):
Code: [Select]
"True"->Str1
"False"->Str2
Disp IIf(A=B,Str1,Str2)
Title: Re: Features Wishlist
Post by: Ashbad on June 24, 2011, 11:22:58 am
You can technically do Iif statements in axe already:

Code: [Select]
"True"->Str1
"False"->Str2
Disp ((A=B)->C*(°Str1)+(not(C)*(°Str2)))
Title: Re: Features Wishlist
Post by: Runer112 on June 24, 2011, 11:25:52 am
Aww, I was writing a big long post about inline if statements but you ninja'd me. :P

But the way you suggested it as a command would be nice. I figure the IS<( token would be perfect for this, as it's currently an unused token easily accessible in the programming menu. It even sort of makes sense without a token replacement if you read it as "is." It would be nice if it had 4 forms, like:

Code: [Select]
.If condition, true, false
iif(A=B,C,D)

.If not(condition), true, false
!iif(A=B,D,C)

.If condition, true
iif(A=B,C)

.If not(condition), true
!iif(A=B,D)

The latter two forms are a bit unconventional, but I could see them being used for optimization purposes. For instance, here is some code I wrote a long time ago. It moves a sprite around the screen according to user key input and draws it, and applies boundaries to the sprite so it does not move offscreen.

As small as I could get it, 345 bytes of executable code. ;)

Code: [Select]
:.SMILE
:[004466000000817E]->Pic1
:DiagnosticOff
:0->X->Y
:Repeat getkey(15)
:ClrDraw
:getKey(3)-getKey(2)+X
:!If +1
:+1
:End
:-1
:Pt-On(min(,88)→X,getKey(1)-getKey(4)+Y+(=⁻1)min(,56)→Y,Pic1)
:DispGraph
:End

The fancy If stuff you see there is an optimized way of making sure the position does not become -1. However, I could only use it for the x coordinate.



EDIT: Ashbad, that would work, yes. But it would be unnecessarily bloated and slow. That would be about 1.5x larger than an inline if statement, and an incredible ~15x slower. It would also require the multiplication routine being added to the program, which may not have previously existed in the program and making the code even larger.
Title: Re: Features Wishlist
Post by: AngelFish on July 01, 2011, 08:40:07 pm
Would it be possible to do special escape sequences in strings, such as "ABC\→"→Str1 to point STR1 at the string "ABC→". The compiler errors on the "→" currently. The only workaround I've found with this is to write the entire string in hex, which is understandably a bit of a pain for non-ASCII characters.
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2011, 08:47:50 pm
I don't think an escape code should be necessary. You could solve this problem without entering the whole string as hex, just enter the one character as hex. In this example, the "" at the end is so Axe knows the data is a string and appends a null terminator. If the hex is in the middle of the string, you don't need to add this null string.

Code: [Select]
"ABC"[1C]""→Str1


EDIT: Also, while looking into this, I discovered that some of Axe's ASCII equates are not correct. and are at least two incorrect ones. All the more reason to use B_CALL(_Get_Tok_Strng) to parse tokens into ASCII.
Title: Re: Features Wishlist
Post by: AngelFish on July 01, 2011, 08:49:04 pm
You can add hex in strings?

That makes everything so much easier.
Title: Re: Features Wishlist
Post by: Deep Toaster on July 03, 2011, 04:30:49 pm
You can add hex in strings?

Not in strings. Runer's code ends the string, tacks a hex byte on, and tacks a null string after that to add in a [00] character. It would be the same as

Code: (Axe) [Select]
"ABC"[1C00]→Str1
Because it's all inline, the pointer to the first string is what gets assigned to Str1.
Title: Re: Features Wishlist
Post by: defmenge on July 13, 2011, 09:07:15 am
Is there any possibility of a nicer syntax for single-byte custom name variables, like "MyVarr" or something similar? Almost every L1+xxx variable I'm currently using is single byte, and just attaching an "r" looks better and makes code less cluttered than {°MyVar}, and would probably be more optimized too (or maybe not, I don't know Axe's inner assembly workings :P).
The reason I can't use 16-bit is that the variables would overlap and collide with each other due to 1-byte offsets and I really need to conserve space by writing numbers

I know 1.0.0 just came out, sorry for bothering with feature requests that early, but custom names don't have that much of a use to me if they can't be made 1-byte easily. :/
Title: Re: Features Wishlist
Post by: p2 on July 13, 2011, 09:48:57 am
It please should support xLib-codes.
They're very useful.
But axe automatically deactivates xLib, Deutsch/German, and every other APPs like them.
That's a little problem for every xLib-user.

And what's about a possibillity to write these special things like @ and all the others (in xLib it's real(13,2,X) X is a value from 1 to 255).
It's not possible to write them in a text. That's annoying, because then you have to drew these funny symbols.
Title: Re: Features Wishlist
Post by: Hayleia on July 13, 2011, 10:11:14 am
you can write this "@" and others, using Output(X,Y,Z►Char) but you have to know the necessary value
Title: Re: Features Wishlist
Post by: p2 on July 13, 2011, 10:15:07 am
but where is the char-command?
I can't find it.

Are the values the same as in xLib?

BUT:
How can I input such a symbol into a text / save into a string?
Title: Re: Features Wishlist
Post by: Hayleia on July 13, 2011, 10:18:08 am
in Math. I don't know the values of  xLib but for Axe, to display a @ it is Output(x,y,64►Char)
Title: Re: Features Wishlist
Post by: p2 on July 13, 2011, 10:27:21 am
So it's
"ABC"+64>Char+"DEF"->Str1
Would that be correct?





And what's about supporting xLib-codes?
(I mean real(  -commands)
Title: Re: Features Wishlist
Post by: Runer112 on July 13, 2011, 10:45:43 am
To make the string "123@456", you would do something like the following. 40 is the hexadecimal character code for @.

Code: [Select]
"123"[40]"456"
Title: Re: Features Wishlist
Post by: p2 on July 13, 2011, 10:50:29 am
Thanx!

Where to find a list of the hexadecimal character codes?
Title: Re: Features Wishlist
Post by: Ashbad on July 13, 2011, 10:55:04 am
Here is one major request I would like to ask for: Data Structures.

I'm talking about structs somewhat like that which can be seen in C, but possibly simpler, where the size of each element within is somewhat constant to only 8 bit or 16 bit ints with possibility of random data to be included as well, such as pre-terminated Strings.

Here is my idea -- struct declaration would be similar to an ALGOL-based block.  Each element inside doesn't have a name, but simply a number, and the expression on each line, depending on it's form, will be added as an element to the struct.  To specify size before the value, simply one would put th size as a number the line before, and just add a colon for prettiness:

Code: [Select]
StructDef Kitty
  1:15 .add element 0 to be 8 bit char with value of $0F
  2:6000 .el. 1 is a 16 bit int with value of 6000
  8:"Hellolol" .el 2 is pointer to a string with an actual value
End

Or even easier, just allow for size to be determined at declaration, and all values upon struct declaration are undefined:

Code: [Select]
StructDef Kitty
  1
  2
  8
End

(I actually would rather the second option)

Creation would be simple, in fact, really simple.  You could use any 16 bit pointer as a pointer to a struct, and simply just do something like:

Code: [Select]
Disp Struct(A,Kitty,2) .disp string stored in element two of structure A
With this in mind, all pointers would have to actually allocate space and fill the space with data by their own means, but the pointer would be treated in accordance with the design of the access struct, Kitty.

This method would be the easiest way to implement this sort of struct data type, and would be very useful to many people, even if it is just syntactic sugar for manual indirection.

If you choose not to implement it into the language standard, I understand, I can find a way to make it in Axiom form :)
Title: Re: Features Wishlist
Post by: defmenge on July 13, 2011, 10:55:29 am
Thanx!

Where to find a list of the hexadecimal character codes?

List of character codes for the monospace font:
http://tibasicdev.wikidot.com/83lgfont

The character codes of the variable width font are slightly different for the additional characters:
http://tibasicdev.wikidot.com/83smfont
Title: Re: Features Wishlist
Post by: ztrumpet on July 13, 2011, 10:56:06 am
Here's a table/list of them: http://tibasicdev.wikidot.com/83lgfont

Edit: Ninja'd.  Twice.  ^-^
Title: Re: Features Wishlist
Post by: Ashbad on July 14, 2011, 10:10:52 am
In addition to structs, another nice feature would be expression continuation over multiple lines.  Take this for example:

Code: [Select]
lambda(Pt-on(r1,r2,r3):Pt-on(r1,r2+8,r3+8)) -> A
It would be nice if when a line ends with a colon, the expression isn't closed at the end of the line, but rather continued on the next one:

Code: [Select]
lambda(Pt-on(r1,r2,r3):
Pt-on(r1,r2+8,r3+8)) ->A

I'm finding myself writing long lambdas ATM for TaN (don't yell at me for making it Axe based again, I only did it because the new functional features make life so much easier considering enemies), some of which take dozens of lines.  This addition would be very helpful :)
Title: Re: Features Wishlist
Post by: SirCmpwn on July 14, 2011, 10:36:05 am
Really well done on the new version!  I haven't upgraded yet, but I'm pretty sure you can't nest includes, which would be a nice feature.
Title: Re: Features Wishlist
Post by: calcdude84se on July 14, 2011, 11:23:33 am
Since we now have single-byte variables, can we get 8-bit math, too? :)
Title: Re: Features Wishlist
Post by: Freyaday on July 14, 2011, 01:58:08 pm
Can we get 32-bit math, please?
Title: Re: Features Wishlist
Post by: calc84maniac on July 14, 2011, 05:30:23 pm
It would be nice if you could optimize the inline-If-Else statement when one of the arguments is empty. If the first argument is empty, turn it into a !If containing the second argument. If the second argument is empty, leave off the Else clause (in other words don't write a JP $+3)

Edit: typo
Title: Re: Features Wishlist
Post by: Runer112 on July 14, 2011, 08:12:37 pm
In addition to structs, another nice feature would be expression continuation over multiple lines.  Take this for example:

Code: [Select]
lambda(Pt-on(r1,r2,r3):Pt-on(r1,r2+8,r3+8)) -> A
It would be nice if when a line ends with a colon, the expression isn't closed at the end of the line, but rather continued on the next one:

Code: [Select]
lambda(Pt-on(r1,r2,r3):
Pt-on(r1,r2+8,r3+8)) ->A

I'm finding myself writing long lambdas ATM for TaN (don't yell at me for making it Axe based again, I only did it because the new functional features make life so much easier considering enemies), some of which take dozens of lines.  This addition would be very helpful :)

You could just write the function as a subroutine and then deference the pointer to the subroutine.
Title: Re: Features Wishlist
Post by: Ashbad on July 14, 2011, 09:26:26 pm
In addition to structs, another nice feature would be expression continuation over multiple lines.  Take this for example:

Code: [Select]
lambda(Pt-on(r1,r2,r3):Pt-on(r1,r2+8,r3+8)) -> A
It would be nice if when a line ends with a colon, the expression isn't closed at the end of the line, but rather continued on the next one:

Code: [Select]
lambda(Pt-on(r1,r2,r3):
Pt-on(r1,r2+8,r3+8)) ->A

I'm finding myself writing long lambdas ATM for TaN (don't yell at me for making it Axe based again, I only did it because the new functional features make life so much easier considering enemies), some of which take dozens of lines.  This addition would be very helpful :)

You could just write the function as a subroutine and then deference the pointer to the subroutine.

Symbols are ugly to keep track of.  Plus, either way, even if I did it that way, I do have lambdas that I'm using that would look better and would be safer from Clear deletion with that implemented; organization is always nice, and that would definitely add that as an option towards keeping things clean.
Title: Re: Features Wishlist
Post by: Quigibo on July 14, 2011, 10:02:24 pm
By the way, I should mention that lambda currently produce 3 extra bytes of code compared to using regular label names.  Label names are also neater and allow more flexibility with code.  Lambdas are meant to be used as expressions, that is, they take in arguments and return a value.  This could maybe optimize better in the future.  Also, using variables as single byte values is less optimized than if you had just used the 2 byte form, at least until I can optimize in some 8-bit math.
Title: Re: Features Wishlist
Post by: Darl181 on July 15, 2011, 01:57:16 pm
Can it be made so when the parser reaches an error and it's inside a subprogram, it displays which subprogram its in?

Not actually changing the errors, but something like...

[insert percent thing here]
ERR:INVALID HEX (or whatever happens)
prgmPHYSCSUB

...would be great.  Once it starts getting something like >5 subprograms it's great fun looking through them one at a time trying to find the error :P
Title: Re: Features Wishlist
Post by: defmenge on July 15, 2011, 02:42:16 pm
If the subprograms are in RAM, you can press PRGM to open the faulty program and it'll scroll to the line the error occured at.
However, if you keep programs in the Archive (like I do), it'll just exit when you press PRGM, so it would indeed be nice if it displayed in which subprogram the error occured.
Title: Re: Features Wishlist
Post by: Darl181 on July 15, 2011, 05:26:36 pm
Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
Title: Re: Features Wishlist
Post by: Ashbad on July 16, 2011, 08:01:23 am
By the way, I should mention that lambda currently produce 3 extra bytes of code compared to using regular label names.  Label names are also neater and allow more flexibility with code.  Lambdas are meant to be used as expressions, that is, they take in arguments and return a value.  This could maybe optimize better in the future.  Also, using variables as single byte values is less optimized than if you had just used the 2 byte form, at least until I can optimize in some 8-bit math.

So, I guess that's a no to the continuation of lines thing?  Even if I just did use them as expressions, expressions can get pretty damn long.  That's why I asked for it.
Title: Re: Features Wishlist
Post by: Freyaday on July 16, 2011, 02:13:57 pm
Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
Title: Re: Features Wishlist
Post by: Michael_Lee on July 16, 2011, 03:40:03 pm
Not really a feature request, but I noticed that the syntax for returning the address of a label is...
Code: [Select]
∟LBL
...whereas the syntax for returning the address of a variable is...
Code: [Select]
°VAR
...which seems kind of inconsistent to me.

I don't really care if this gets changed or not -- just commenting :)
Title: Re: Features Wishlist
Post by: GreenFreak on July 17, 2011, 08:19:57 am
I don't if it was mentioned before, but I would like to use Text( on the backfuffer, too...
Title: Re: Features Wishlist
Post by: Runer112 on July 17, 2011, 12:23:36 pm
Drawing text to the back buffer isn't possible with TI's text routines. Axe programs and just about every sane coder use TI's built-in text routines instead of writing their own to save a large amount of effort and size.

To write text to the back buffer with routines that only draw to the front buffer, you can do something fancy like back up 6 rows of the front buffer, draw the text into those 6 rows, copy those 6 rows into the back buffer, and then restore the rows on the front buffer. But that's a really roundabout way to draw text to the back buffer.

The alternative is to write your own text routine. Whether you do it in Axe or assembly, it will probably take up a lot of space, but if you absolutely must be able to draw text easily to the back buffer, this is the way to go.
Title: Re: Features Wishlist
Post by: GreenFreak on July 17, 2011, 01:00:20 pm
Oh, I didn't know that this is so difficult to do...
Title: Re: Features Wishlist
Post by: Deep Toaster on July 17, 2011, 02:42:18 pm
Not really a feature request, but I noticed that the syntax for returning the address of a label is...
Code: [Select]
∟LBL
...whereas the syntax for returning the address of a variable is...
Code: [Select]
°VAR
...which seems kind of inconsistent to me.

It is annoying, but °LBL looks like (°L)(B)(L) :/
Title: Re: Features Wishlist
Post by: calc84maniac on July 17, 2011, 02:49:04 pm
Not really a feature request, but I noticed that the syntax for returning the address of a label is...
Code: [Select]
∟LBL
...whereas the syntax for returning the address of a variable is...
Code: [Select]
°VAR
...which seems kind of inconsistent to me.

It is annoying, but °LBL looks like (°L)(B)(L) :/
Axe 1.0.0 supports named variables ^^
Title: Re: Features Wishlist
Post by: Runer112 on July 17, 2011, 02:49:16 pm
Actually the problem is that you can have labels and constants with the same name. The following is perfectly valid code:

Code: [Select]
Zeros(128)→°Map
Lbl Map

The address of the 128-byte map would be °Map while the address of the label would be ʟMap.
Title: Re: Features Wishlist
Post by: Darl181 on July 17, 2011, 03:17:33 pm
Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
Never does for me.  Even if there's an existing one in archive it overwrites it with a program in RAM.
Title: Re: Features Wishlist
Post by: ztrumpet on July 17, 2011, 06:23:11 pm
Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
Never does for me.  Even if there's an existing one in archive it overwrites it with a program in RAM.
Yeah, Axe only compiles to RAM.  It can, however, read source from archive.
Title: Re: Features Wishlist
Post by: Deep Toaster on July 18, 2011, 07:56:35 am
Actually the problem is that you can have labels and constants with the same name. The following is perfectly valid code:

Code: [Select]
Zeros(128)→°Map
Lbl Map

The address of the 128-byte map would be °Map while the address of the label would be ʟMap.

An idea: what about combining the two? Might be a bit confusing at first but I think duplicate names between variables and labels shouldn't be allowed. But then we couldn't use one-character lettered/theta labels...
Title: Re: Features Wishlist
Post by: Ashbad on July 18, 2011, 08:18:42 am
I actually think it's fine.  Good naming convention will keep you from this anyways (for data, always start with a S for string, D for hex delimited data; Data( is rarely used so do whatever with that).  You shouldn't be naming them the same things anyways; it's a horrible computer coding practice, why should it be okay for Axe even if it is allowed?  I stick with the original degree symbol and list symbol for doing the same thing but for different applied entities.  Like in Perl, PHP, Ruby, and many others, different sigils apply to different variables based on what type they are (though in Ruby it means scope); I think Axe's 'sigils' for finding address are good for differentiation.
Title: Re: Features Wishlist
Post by: annoyingcalc on July 18, 2011, 09:02:48 am
make Axe compatable with gCn 1.0
Title: Re: Features Wishlist
Post by: Ashbad on July 18, 2011, 09:03:54 am
make Axe compatable with gCn 1.0

That's a job for an axiom.
Title: Re: Features Wishlist
Post by: annoyingcalc on July 18, 2011, 09:05:46 am
make Axe compatable with gCn 1.0

That's a job for an axiom.

how to make Axioms but I use them some like crabcake
Write one then if you can Ib dont know
Title: Re: Features Wishlist
Post by: Runer112 on July 20, 2011, 01:30:41 am
Although it's easy enough to do manually, I (and probably others) would like to see randInt(). It would be especially cool if you could optimize it for constant arguments. :)
Title: Re: Features Wishlist
Post by: Quigibo on July 20, 2011, 02:26:11 am
Yeah, I keep wanting to add it... but its so annoying because I need to special case it for 4 possibilities: (var,var) (const,var) (var,const) and (const,const).  In addition, I also have to incorporate the optimizations for modulus with powers of 2.  Without these optimizations, the command would be pointless because no one would use it knowing they could do the exact same thing faster and smaller with just as much code.
Title: Re: Features Wishlist
Post by: calc84maniac on July 20, 2011, 08:23:05 am
I think the new For(const) command could be nicely extended to For(expression). The expression would be evaluated exactly once, upon entry to the loop, and the HL before the For() would be preserved (just like in the constant version). Here's my suggested asm code generation:
Code: [Select]
 push hl
  ;EVALUATE EXPRESSION HERE
  ex (sp),hl
  pop bc
loop:
  push bc
  ;LOOP BODY HERE
  pop bc
  dec bc
  ld a,b
  or c
  jr nz,loop

Or, if you wanted to employ the nested djnz optimization like in the constant version (which may not be worth it due to size):
Code: [Select]
 push hl
  ;EVALUATE EXPRESSION HERE
  dec hl
  inc l
  inc h
  ld b,l
  ld c,h
  pop hl
loop:
  push bc
  ;LOOP BODY HERE
  pop bc
  djnz loop
  dec c
  jr nz,loop

Edit:
Hmm, this reminds me, what should happen when For() contains a 0? Should the loop be skipped?
Title: Re: Features Wishlist
Post by: Darl181 on July 20, 2011, 02:41:25 pm
What's happened to me was when I do For(A,0,0) or two of the same number, it happens once.
When I do something like For(A,1,0) it doesn't happen (instead of an almost infinite loop like it used to...:) )

If you mean For(0) like in the newer ersions, idk b/c I'm still using 0.5.3 :P
Title: Re: Features Wishlist
Post by: Runer112 on July 20, 2011, 04:32:27 pm
I know a maximum variable name length of 5 works out well for you because that makes each entry 8 bytes large, but in my experience so far 5 just isn't enough. I think 8 or 13 would be nice.


Also, bumping two old feature requests:

Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this (http://ourl.ca/10185/195814). :)

I really like that idea. What about changing Zeros( (det() to something more universal?

I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value. Maybe you could even add a Block()r command for creating a block filled with a specified word while you're at it, although this probably isn't as necessary as a normal byte-filling block command.

Quigibo, perhaps implement B_CALL(_DelRes) somehow? It would probably have to be manually called by the user at their discretion, but it would be useful for people who want to use L2. And for that matter, B_CALL(_DelRes) should probably be a part of the interrupt setup, which it currently is not.
Title: Re: Features Wishlist
Post by: Darl181 on July 20, 2011, 07:09:36 pm
Maybe Data could be changed a bit so something like (Data([ABCD]),2)→GDB1 would store [ABCDABCD]?
Title: Re: Features Wishlist
Post by: Freyaday on July 20, 2011, 08:45:42 pm
Wasn't Fill just changed to do exactly that?
Title: Re: Features Wishlist
Post by: calc84maniac on July 20, 2011, 08:49:06 pm
Wasn't Fill just changed to do exactly that?
It doesn't fill a repeating string of multiple bytes. You can accomplish this with Copy(), but either way he's suggesting a shortcut for the original definition of the data.
Title: Re: Features Wishlist
Post by: mrmprog on July 20, 2011, 11:00:19 pm
I agree with all the features on this page. I was going to quote them, but that would be huge.
Title: Re: Features Wishlist
Post by: Scipi on July 20, 2011, 11:02:09 pm
Something that should probably be implemented is an optional, fourth argument to the For( command

For([Var],[start],[end],([inc])
Title: Re: Features Wishlist
Post by: Kiruahxh on August 02, 2011, 06:28:16 am
Hi!

I am new in the forum :-)
I'd like to have a debug macro (#Debug / #Release) and #Debug(code) would mean the code is only executed in debug mode, or something like this.
I'm am for the 4 args loops too.

There is an error in the commandList :
DispGraphClrDraw(BUF1,BUF2)rr has been replaced by DispGraphClrDraw(BUF1,BUF2)r
Title: Re: Features Wishlist
Post by: squidgetx on August 02, 2011, 10:16:16 am
In response to the poll, I'd rather have the smaller size for file reads. I don't know when anyone would be using time-critical file reads. In any case, it's always easier to copy a tilemap or level into RAM anyway since then it can be modified, etc.

Actually, just kidding. I can think of maybe a couple situations where a fast file read time could be nice. (Tiny Wings lol) Err, would it ever be possible to do both? I'm not very helpful, am I? lol :P

Title: Re: Features Wishlist
Post by: p2 on August 02, 2011, 01:06:31 pm
decimals and negatie numbers should please be possible!!

But that isn't possable to make, or?
Title: Re: Features Wishlist
Post by: calcdude84se on August 02, 2011, 01:48:31 pm
Negative numbers are already there. Look at all the commands specifically for signed numbers, for instance.
If by "decimals" you mean "floating point," the answer to that is "no," mainly because floating point isn't normally necessary for games. Axe does have support for binary fixed-point numbers, though.
Title: Re: Features Wishlist
Post by: zeldaking on August 02, 2011, 01:51:26 pm
maybe a built in picture to hex editor? with custom side lengths.
Title: Re: Features Wishlist
Post by: calcdude84se on August 02, 2011, 01:59:38 pm
A sprite editor is packaged with the Axe download ;)
Edit: it is only 8x8, though, IIRC. Others have created more versatile sprite editors, however.
Title: Re: Features Wishlist
Post by: Deep Toaster on August 02, 2011, 02:05:56 pm
Not sure if I've posted this before, but even if I have it's definitely gotten lost (166 pages?!): A Pt-And( command to take the place of Plot2(. It's really useful in certain situations. I usually use a combination of Pt-On( and Pt-Change( to do the job, but Pt-And( would be twice as fast.
Title: Re: Features Wishlist
Post by: ztrumpet on August 02, 2011, 02:28:33 pm
Not sure if I've posted this before, but even if I have it's definitely gotten lost (166 pages?!): A Pt-And( command to take the place of Plot2(. It's really useful in certain situations. I usually use a combination of Pt-On( and Pt-Change( to do the job, but Pt-And( would be twice as fast.
Yeah, I'm sure you requested it before. :)  And, like last time, I agree; I would find it quite useful. :D
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 02, 2011, 02:35:04 pm
Hi!

I am new in the forum :-)
I'd like to have a debug macro (#Debug / #Release) and #Debug(code) would mean the code is only executed in debug mode, or something like this.
I'm am for the 4 args loops too.

There is an error in the commandList :
DispGraphClrDraw(BUF1,BUF2)rr has been replaced by DispGraphClrDraw(BUF1,BUF2)r
Heya welcome to the forums. I hope you enjoy your stay (and calc programming) :)

On a side note I'M unsure if this is related or not but I wonder if there were future plans for the raycaster Axiom by Runer112?
Title: Re: Features Wishlist
Post by: Quigibo on August 02, 2011, 04:03:56 pm
You can do Pt-And already with the new Pt-Mask()r command.  Its way more versatile anyway because any situation you use an "And" mask with you're probably doing more than one sprite draw anyway.  The new command bit patterns handle all 3 of the original sprite methods plus transparency:

F B
1 1 = Black (Pt-On)
1 0 = Invert (Pt-Xor)
0 1 = White (Pt-And)
0 0 = Transparent
Title: Re: Features Wishlist
Post by: Runer112 on August 02, 2011, 04:55:19 pm
That does work Quigibo, but it's unnecessarily slow and bloated if the only logic they require is AND.


Also, in response to this:
I'd like to have a debug macro (#Debug / #Release) and #Debug(code) would mean the code is only executed in debug mode, or something like this.

I've always wanted a compiler feature like this, but what would be infinitely more useful is #If. It could handle debug stuff and much more, like easily changeable compiling options. For instance, my old raycasting project had to have like 8 different copies of the source for slight rendering variations. #If would allow me to combine them all into one and make working on such projects much more manageable.
Title: Re: Features Wishlist
Post by: ztrumpet on August 02, 2011, 05:09:39 pm
Also, in response to this:
I'd like to have a debug macro (#Debug / #Release) and #Debug(code) would mean the code is only executed in debug mode, or something like this.

I've always wanted a compiler feature like this, but what would be infinitely more useful is #If. It could handle debug stuff and much more, like easily changeable compiling options. For instance, my old raycasting project had to have like 8 different copies of the source for slight rendering variations. #If would allow me to combine them all into one and make working on such projects much more manageable.
#If would be awesome.  I'd love to be able to use it; it'd make so many things so much simpler.
Title: Re: Features Wishlist
Post by: Freyaday on August 02, 2011, 10:44:05 pm
What would #If do?
Title: Re: Features Wishlist
Post by: Runer112 on August 02, 2011, 11:09:16 pm
It's an If statement that is evaluated at compile time, only compiling the code inside the statement if the condition is true. One scenario in which it would be very useful is debugging. You could put something like this in your code to easily enable or disable a bunch of debugging outputs and not have the debug code bloat your program when you're not debugging.

Code: [Select]
.MYPROG
1→°Debug

.Some of your program

#If °Debug
ClrHome
Disp A►Dec,i,B►Dec,i,C►Dec,i,X►Dec,i,Y►Dec
While 1
EndIf getKey(0)
End

.The rest of your program


You could also use for many other things. To name a few:
Title: Re: Features Wishlist
Post by: ZippyDee on August 03, 2011, 03:46:48 am
wouldn't that need to be #End at the end of that?
Title: Re: Features Wishlist
Post by: Runer112 on August 03, 2011, 10:57:15 am
Technically, yes, it should be preceded with an octothorpe. The question is do we want to make a new token for #End, which probably wouldn't be as obvious to find as End and wouldn't make as much sense without token replacements.
Title: Re: Features Wishlist
Post by: calc84maniac on August 03, 2011, 10:59:16 am
It may also be possible to make use of the existing If construct with a constant condition. The compiler could then auto-optimize and get rid of the portion that is never run. Does this sound like a good idea?
Title: Re: Features Wishlist
Post by: p2 on August 03, 2011, 11:00:51 am
wouldn't this be possible:
you write 7/8 and get 1
you write (1/4)+8.95 and get 9

so that it rounds decimals, but doesn't make an Error?
(for calculations in graphical-things)
Title: Re: Features Wishlist
Post by: Runer112 on August 03, 2011, 11:03:19 am
No, I think an actual #If is still necessary. There could be labels or data defined inside the subroutine that other parts of the program need regardless of whether or not the if statement is executed. And regardless of that, I think it's a good idea to continue the pattern of preceding compiler commands with an octothorpe.
Title: Re: Features Wishlist
Post by: Quigibo on August 03, 2011, 01:55:47 pm
The #If and #End would be super easy to code, but what would be good symbols for those to replace?

Also, octothorpe?  Haven't heard that used.  The convention I use when reading code aloud is:
Code: [Select]
# - Hash
! - Bang
* - Splat
/ - Whack

Its pretty old school from my lisp programming, but I love using it!  ;D
Title: Re: Features Wishlist
Post by: Kiruahxh on August 03, 2011, 03:07:23 pm
Another idea, but not to include in the language : is there any computer asm code optimizer for z80 (based on output state and input state)?
I think it could decrease a lot the size of programs...
And there is no 8 bits maths, I mean that it would be cool to declare vars 8 or 16 bits; and for example to have
x = -x equal to x = 256-x when x is 8 bits, instead of 32656-x. This would be faster too I think.
Title: Re: Features Wishlist
Post by: Runer112 on August 03, 2011, 03:26:07 pm
The #If and #End would be super easy to code, but what would be good symbols for those to replace?


I had two ideas for this:

Title: Re: Features Wishlist
Post by: ztrumpet on August 03, 2011, 04:51:33 pm
The #If and #End would be super easy to code, but what would be good symbols for those to replace?


I had two ideas for this:

  • The first and most obvious solution would just be to make 3 unrelated tokens the tokens for #If, #Else, and #End. The tokens under VARS → Table... could be useful for this, as it's a menu containing exactly 3 unused tokens. #ElseIf would probably just be a combination of #Else and the normal If. This method would have the advantage of looking nicer with Axe-tokenized code, but they would look pretty confusing without Axe token replacements like in SourceCoder.

  • My other idea would be to replace IS<( with #If and just use the normal Else and End. This would have the advantage of looking just about as good in something like SourceCoder and being easier to type on both platforms. However, the lack of hash marks preceding Else, ElseIf and End might be undesirable.
I like your first option a lot better; I think Else, ElseIf, and End should have hashes in front of them.
Title: Re: Features Wishlist
Post by: Deep Toaster on August 04, 2011, 12:37:53 am
The #If and #End would be super easy to code, but what would be good symbols for those to replace?
How about Pmt_Bgn and Pmt_End (in the Finance menu)? I can't see them being used anywhere else.
Also, octothorpe?  Haven't heard that used.
Lol I don't think that's the one usually used, especially in coding.
The convention I use when reading code aloud is:
Code: [Select]
# - Hash
! - Bang
* - Splat
/ - Whack
I love those terms :D Oddly appropriate too.
Title: Re: Features Wishlist
Post by: mrmprog on August 04, 2011, 02:41:02 am
I think that the whole #If idea is very good. There, I have shared my two-cents.
Title: Re: Features Wishlist
Post by: Ashbad on August 06, 2011, 11:53:22 am
Quote
Also, octothorpe?  Haven't heard that used.
Lol I don't think that's the one usually used, especially in coding.

No, it's just called "hash".  Someone was trying too hard to sound smart when they used that one :P.  In fact, calling it anything other than "hash" or "crunch" usually makes other programmers look at you funny.

Also, here's my two cents on the new XXX.XXX decimal notation, with a discussion leading up to why I would prefer an XX.XX notation instead: http://ourl.ca/916578
Title: Re: Features Wishlist
Post by: Quigibo on August 07, 2011, 06:50:44 am
Ashbad, I disagree with that view.  You could make the same argument with regular floating point numbers in other programming languages.  When you type 0.7 for a float in Java or C++, it cannot represent 7/10 in binary and must perform rounding.  Does this mean we should instead represent it as some crazy decimal to avoid confusion?  I don't think so, the programer should always be expecting some rounding when doing floating point calculations.
Title: Re: Features Wishlist
Post by: Ashbad on August 07, 2011, 09:09:13 am
But if it was made to help TI-BASIC programmers translate easier, they would wonder why numbers like 255.998 and 255.999 are equal.  And then they have to lear about how floating point notatio. In Axe works with binary terms anyways.  Rather pointless?..

And when you type 7/10 in Java/C, it DOES equal 0.7f/d, not something like 0.66f/d.  You know as well as I do that's not a good comparison; the two forms of floating point notations work entirely differently, using different techniques (and in most languages, the amount of numbers that can be stored is already specified in digits, not in 256 base-units).  I.E: you know that 0.00000000001f and 0.00000000000002f are equal due to the digit length and the fact they'll either be treated as generic infitesmals or simply zero (possibly even throw a warning!); in axe, you don't know if two consecutive small numbers are equal, or even what they really represent.  5.001 is equal to 5.002 which is equal to 5.003, but why are they not equal to 5.004 then?  It's not sane.  It's pointless to have large precision for the hell of it when the user doesn't know what things will truncate to.  I still stick by the XX.XX argument.  The programmer should expect that high precision floating point numbers will retin their value; if there is rounding involved in the thousands place, and things are stored in 8.8 notation for high precision work, something is wrong with the implementation.
Title: Re: Features Wishlist
Post by: calc84maniac on August 07, 2011, 10:02:06 am
It's fairly common knowledge that you shouldn't use equal/not-equal comparison for floating-point numbers, and this applies to fixed-point as well.
Title: Re: Features Wishlist
Post by: Ashbad on August 07, 2011, 10:38:55 am
It's fairly common knowledge that you shouldn't use equal/not-equal comparison for floating-point numbers, and this applies to fixed-point as well.

That's after operations like comparing a calculus function that simulates a sine function to a built in sine function, that could get things off by a few millionths per calculation.  Not by thousandths.  And, the main point is not returned values from operations being slightly off, it's that the programmer doesn't know the storing limit directly of thousandths FP numbers.  That's a large problem.  If there's an option for sot ring things to 3 decimal points, there should be assurance that everything in those 3 digit points will be completely represented, and anything past that won't do much.  XX.XX rules because you know everything will be represented fairly.  With XXX.XXX, that sixth X is really questionable because no one has an idea how it will be represented.
Title: Re: Features Wishlist
Post by: Runer112 on August 07, 2011, 11:10:14 am
And when you type 7/10 in Java/C, it DOES equal 0.7f/d, not something like 0.66f/d.  You know as well as I do that's not a good comparison; the two forms of floating point notations work entirely differently, using different techniques (and in most languages, the amount of numbers that can be stored is already specified in digits, not in 256 base-units).

In Java, C, C++, and most other modern languages, 0.7 DOES NOT equal 0.7. They use binary-encoded floats, not decimal-encoded floats, and 0.7 cannot be perfectly represented in binary. If you don't believe me, check out this IEEE 754 converter (http://www.h-schmidt.net/FloatApplet/IEEE754.html). The number of decimal digits that can be stored in a regular float is 7.22. That's right, it's not an integer. Just like the number of decimal digits that can be stored in an Axe fixed-point number is 2.41. Java, C, and C++ don't throw an error if you enter an 8-digit float, so why should Axe throw an error if you enter a 3-digit decimal?


It's fairly common knowledge that you shouldn't use equal/not-equal comparison for floating-point numbers, and this applies to fixed-point as well.

This is very true. Just like you would never check if a float is exactly 112.453 after some calculation, you wouldn't check if a fixed point number is exactly 112.453.
Title: Re: Features Wishlist
Post by: Ashbad on August 07, 2011, 01:19:03 pm
It's 7.22 because it can get an 8th, though you know that eighth has no usable purpose.  With Axe, if the XXX.XXX must stay, make sure to warn people that the sixth X is crap and never ever to use it.

And of course .7 doesn't equal .7 in binary.  But it doesn't equal .701 either.  You can't do it.. all that matters is the representation and that there is a given standard on how many digits you should go to.  Since Axe is a language used mostly by inexperienced programmers that haven't touched face with computer languages like C++ or Java, the third should be eliminated since the BASIC coders, who wont know anything about represented digits and how they work, will get confused (and the reason it was put in there was to make a nice transition for them?  Yeah, right, that wont confuse them whatsoever).  I'm not an idiot, I know how FP IEEE754 numbers work, and I know how many digits can be stored.  But if this is being added to cut confusingness for lower-experience Axers, then it's 1000% pointless and 50% stupid.  It's not even a good idea for advanced programmers, since it still doesn't represent numbers well enough for high-precision applications, so what's good about it again?  Those extra .41 digits could be used for something much more useful than storing another .41th of a digit, they could be used for flags and other commodities.

C and c++ (with decent compilers) usually have some sort of compilation option to check for over-extended FP numbers and warn at compile-time about them, so, yes they can.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 07, 2011, 02:14:56 pm
Well personally in BASIC I didn't use much decimals. 2 were enough for me, like 99.99. When I made a RPG, often I didn't even need this much precision for damage formulas anyway, especially that in the end I got rid of the decimal part.

Also for precision stuff, well... BASIC is so slow that I doubt a lot of people use more than 2 decimals to move stuff around. Most of the time they move stuff every few pixel.

Ashbad you need to calm down a bit, though. Don't become angry at people because they disagree with you. This leads to nothing good and Quigibo can do whatever he wants with his language anyway. (I didn't want the new token names to be added at first, and they went in anyway)
Title: Re: Features Wishlist
Post by: Runer112 on August 07, 2011, 02:16:41 pm
It's 7.22 because it can get an 8th, though you know that eighth has no usable purpose.  With Axe, if the XXX.XXX must stay, make sure to warn people that the sixth X is crap and never ever to use it.

The 3rd decimal digit of Axe fixed point numbers has a purpose. Try representing 1/256, a very useful number for transformations, without it. Or try representing 1/3. Whereas 0.33 would equal 84/256, 0.333 would equal 85/256, the latter of which is 4x more precise. I, and I believe many others, would not want to forfeit this additional precision. Saying that the 3rd decimal digit doesn't matter is like telling someone to ignore the units digit of a 3-digit integer.

If you limited numbers to 99.XX, people will think 99.99 is the maximum number possible, although it's really 255.997. If you thought they'd be confused when 0.138 equals 0.139 (I'm simply obliging your suggestion here; not once in my programming experience have I seen someone check for exact equality to a number with more than one decimal place), think about the confusion caused when they learn that, in a system that presents itself as a mod 100 system, 50+50 doesn't overflow. And I know you might suggest having BCD math routines for this purpose, but there are multiple problems with this. To list the ones that come to mind:



EDIT: As a note, I just want to mention that I'm not dragging this out for the sake of trying to prove anybody wrong. I just think it's simplest to leave fixed point numbers the way they are.
Title: Re: Features Wishlist
Post by: TIfanx1999 on August 08, 2011, 11:28:18 am
I'll agree with Ashbad that the loss of precision in the third decimal digit will probably confuse some people. Perhaps just a mention of this in the readme would do?
Title: Re: Features Wishlist
Post by: Ashbad on August 08, 2011, 11:33:35 am
I'll agree with Ashbad that the loss of precision in the third decimal digit will probably confuse some people. Perhaps just a mention of this in the readme would do?

^ If it must stay, this is the best option.  How about in the command reference thing?
Title: Re: Features Wishlist
Post by: Freyaday on August 08, 2011, 11:53:46 am
Ok, a few things.
That .22 of 7.22? That means that, beyond those 7 decimal digits, only 22% of numbers result in a unique binary value.
It should also be stated that, to avoid confusion, you can enter it in hex, as EXXXX
Title: Re: Features Wishlist
Post by: p2 on August 09, 2011, 08:21:10 am
Are there any posibillities to calculate with numbers like 3.58264579835 so that it uses the 3.58... but tells you 4 if ypu check the number?

(I need it for games when you are controling a little point and have to run way of a few enemies which are calculating the best path to your position and then walk exactly the streak on 1 or 2 (whatever I choose)



Someone - i thenk it was runner - has helped me with such a program.
I think he has multipled every var with 255 or something.
But I haven't really understood that.


Is there any special command in axe?

or may someone make such a command for the next version of Axe??
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 08:25:56 am
Ok, a few things.
That .22 of 7.22? That means that, beyond those 7 decimal digits, only 22% of numbers result in a unique binary value.

*seven* decimal digits?  22%?  Assuming you mean after that decimal digit, only 22% of numbers are represented, that might be true if you account for the useless 3rd digit that nobody should ever use, but that ".22" is completely represented as a unique value.
Title: Re: Features Wishlist
Post by: Compynerd255 on August 09, 2011, 10:06:24 am
Since Axe is a language used mostly by inexperienced programmers that haven't touched face with computer languages like C++ or Java,
BLASPHEMY! I write in C# and use floating points all the time! And I use Axe!

I do see you guys's point with killing the third decimal point simply because the percision isn't offered. I would propose an XXX.XX way of writing numbers so that it isn't confusing why comparisons aren't working, but you can still go all the way up to 255 (an XX.XX would only allow up to 99). Also, another question: will putting a degree sign before a fixed-point decimal variable return the whole number portion of said variable (like int(x) in BASIC)?
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 10:36:51 am
The degree sign is already used to use the address of a variable. If I could remember how Axe did fixed point, I'd give you a simple workaround for it. :/
As for the 2- or 3-digits issue:
First, note that the underlying format uses base 2, while the numbers are expressed in source as base 10.
8 binary digits (I'm not using 'bits' in hope that what I say will be slightly clearer) have more precision than 2 decimal digits. This can easily be seen by noting that 28 = 256 > 102 = 100.
8 binary digits are also less precise than 3 decimal digits. Once again, 28 = 256 < 103 = 1000.
The reasons behind each preference for a certain length are, as I understand it, as follows:
2 digits: We want the underlying format to be more precise than the input format, so that nobody is confused by the loss of precision resulting from expressing the number in 3 digits.
3 digits: We want the input format to be more precise than the underlying format, so that everybody has full control over the contents of the resulting binary fixed-point number.

I do support 3 digits, though. A note in the README should suffice to alert about the loss of precision.
The main reason is that, if you only want to use 2 digits, then you only use 2, while you can't use 3 if there's only support for 2.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 10:40:19 am
Since Axe is a language used mostly by inexperienced programmers that haven't touched face with computer languages like C++ or Java,
BLASPHEMY! I write in C# and use floating points all the time! And I use Axe!

Welcome to the 1% of programmers who don't fit that description.

Quote
I do see you guys's point with killing the third decimal point simply because the percision isn't offered. I would propose an XXX.XX way of writing numbers so that it isn't confusing why comparisons aren't working, but you can still go all the way up to 255 (an XX.XX would only allow up to 99). Also, another question: will putting a degree sign before a fixed-point decimal variable return the whole number portion of said variable (like int(x) in BASIC)?

XX.XX would work, since the 99 there would actually represent 255.  That way, each representation of "1" would actually mean 2.55 instead.
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 10:44:23 am
Also, people seem to be using different notations. Using "AAA.BBB" to mean AAA + BBB/256 is not how numbers are normally expressed. As far as I was aware, this was going to be straightforward decimal notation, where "AAA.BBB" means AAA + BBB/1000, rounded to the nearest 256th.
Edit: the unconventional notation would also make it more confusing for beginners, by the way.
Title: Re: Features Wishlist
Post by: calc84maniac on August 09, 2011, 02:35:02 pm
Are there any posibillities to calculate with numbers like 3.58264579835 so that it uses the 3.58... but tells you 4 if ypu check the number?
You can round a fixed-point value A to the nearest integer by doing A+128//256. If you want to round down always, do A//256. If you want to round up always, do A+255//256.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 04:26:24 pm
Also, people seem to be using different notations. Using "AAA.BBB" to mean AAA + BBB/256 is not how numbers are normally expressed. As far as I was aware, this was going to be straightforward decimal notation, where "AAA.BBB" means AAA + BBB/1000, rounded to the nearest 256th.
Edit: the unconventional notation would also make it more confusing for beginners, by the way.

Oh, I thought the top XXX was specified from 0-999, not 0-255.  If it is 0-255, then I agree, thats confusing as hell and the system isn't very well thought out.  And to think I was only arguing against something insignificant like the lower XXX...
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 04:30:13 pm
There's absolutely no way you could specify the integer part from 0-999 unless you did 10.6 fixed point instead of 8.8, which is what Axe uses ;)
Also, given that Axe treats all fixed-point numbers as signed, the integer part can only be from -128 to 127, anyway.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 04:49:40 pm
There's absolutely no way you could specify the integer part from 0-999 unless you did 10.6 fixed point instead of 8.8, which is what Axe uses ;)
Also, given that Axe treats all fixed-point numbers as signed, the integer part can only be from -128 to 127, anyway.

Well, 0-999 where each "1" actually represents .30625.
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 05:31:27 pm
Ah, I see. Yeah, that's confusing, though :/
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 05:33:48 pm
Ah, I see. Yeah, that's confusing, though :/

Either way, the 0-255 or 0-999, it's confusing
Title: Re: Features Wishlist
Post by: calc84maniac on August 09, 2011, 06:20:09 pm
0-127 is no more confusing than -32768-32767 or 0-65535.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 06:25:02 pm
0-127 is no more confusing than -32768-32767 or 0-65535.

Good point.  It's also no less confusing to someone who doesn't get the importance of those particular numbers (*ahem* the people this system was made for to make things less confusing, yet makes things more confusing)
Title: Re: Features Wishlist
Post by: calc84maniac on August 09, 2011, 06:26:36 pm
0-127 is no more confusing than -32768-32767 or 0-65535.

Good point.  It's also no less confusing to someone who doesn't get the importance of those particular numbers (*ahem* the people this system was made for to make things less confusing, yet makes things more confusing)
It wasn't to make it less confusing, it was for convenience. It can be really annoying to convert decimal to EXXXX format manually.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 06:30:59 pm
0-127 is no more confusing than -32768-32767 or 0-65535.

Good point.  It's also no less confusing to someone who doesn't get the importance of those particular numbers (*ahem* the people this system was made for to make things less confusing, yet makes things more confusing)
It wasn't to make it less confusing, it was for convenience. It can be really annoying to convert decimal to EXXXX format manually.

Then don't use decimal!  There are usually a million and one ways around using decimal, since with this notation doesn't do anything like convert from hex back to decimal, just a notation for decimal to hex; hence, it really isn't highly useful anyways.

Since it seems as though the drawbacks to the fpart of the XXX.XXX system will be documented in the future, I'm fine with that; though, that ipart looks really, REALLY ugly even in comparison.  I promote a XX.XXX system where 99.000 == 0xFF00.
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 08:07:22 pm
That will screw with all your math. That would make 0.500**1.000>>1.000 true, for instance. And don't suggest changing the ** operator, either, because then all it would make it almost twice as slow because of the necessary extra multiply. ;)
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 08:48:30 pm
That will screw with all your math. That would make 0.500**1.000>>1.000 true, for instance. And don't suggest changing the ** operator, either, because then all it would make it almost twice as slow because of the necessary extra multiply. ;)

I fail to see how changing how the top translates from decimal to true value, rather than just the top staying in true form, changes *anything* of that sort.  99.000 * .500 (proposed translation) ==  255.000 (current translation) would return true.  I fail to see any of your point whatsoever.  How things translate to the same form doesn't affect any math at all.  If 1.000 ** .500 returned true before, it will return true after the change as well.
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 09:46:31 pm
I'm just having problems with the fact that you're trying to convert 99 into 255. Assuming you want this done by multiplying by 255/99, let me restate the point I was trying to make with the evaluation of a statement. (I'm using unsigned fixed point here.)
1.000**1.000=1.000
This looks obviously true.
Let's convert this to hex-represented fixed point by multiplying by 255/95:
E02AF**E02AF=E02AF
E0733=E02AF
So, I see two views to take: 1) Math is completely screwed over for multiplication. 2) Math is now non-intuitive.
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 10:00:43 pm
Or, we go back to my original point of keeping things constant: why is it that it's not something like 255.255 then, or 99.99 (the slower speed is fine by me, floating points are expected to be slower anyways -- life isn't about a dozen or so cycles, it's about ease of use).  The different notations for the different parts is just stupid.  No FP notation should ever do this.  Ever.  Keep it consistent, at the very very very very very least.
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 10:05:00 pm
There's only one notation: decimal notation. Is the part that's throwing you off the fact that the number is bounded between two powers of two and not two powers of ten?
Edit: It doesn't seem very hard to understand a statement such as "The number must meet the condition that -128<=#<128."
Title: Re: Features Wishlist
Post by: Ashbad on August 09, 2011, 10:15:59 pm
There's only one notation: decimal notation. Is the part that's throwing you off the fact that the number is bounded between two powers of two and not two powers of ten?
Edit: It doesn't seem very hard to understand a statement such as "The number must meet the condition that -128<=#<128."

Why do you think I'm an idiot?  Any moron can understand those limits compared to the other ones.  It still doesn't mean they're a good idea.  Much like how expressing the S&P500 as a line graph, and then the DOW Jones as a donut graph wouldn't be a good idea.  Being consistent is key.
Title: Re: Features Wishlist
Post by: AngelFish on August 09, 2011, 10:19:51 pm
Let's keep this civil, people. No need to start a fight over fixed point math, when arbitrary precision is clearly the way to go :P
Title: Re: Features Wishlist
Post by: calcdude84se on August 09, 2011, 10:21:30 pm
Why do you think I'm an idiot?  Any moron can understand those limits compared to the other ones.  It still doesn't mean they're a good idea.  Much like how expressing the S&P500 as a line graph, and then the DOW Jones as a donut graph wouldn't be a good idea.  Being consistent is key.
Ashbad, I do not think that you are an idiot. I'm sorry if I made it seem like that. I just do not see how the notation is inconsistent. ???
Title: Re: Features Wishlist
Post by: calc84maniac on August 22, 2011, 02:12:04 pm
I've wanted this feature for a while: ability to insert constant values into Asm() code.

Example of possible syntax, if I wanted to generate ld bc,GDB1 \ ld de,(axv_A) I would do:
Asm(01(GDB1)rED5B(°A)r)
Title: Re: Features Wishlist
Post by: ztrumpet on August 22, 2011, 02:25:33 pm
I've wanted this feature for a while: ability to insert constant values into Asm() code.

Example of possible syntax, if I wanted to generate ld bc,GDB1 \ ld de,(axv_A) I would do:
Asm(01(GDB1)rED5B(°A)r)
I like this idea.  However, what if { and } were used instead of ( and )?  This would lead to a more standard syntax, even if it breaks up the flow of the Asm code.
Title: Re: Features Wishlist
Post by: calc84maniac on August 22, 2011, 02:54:55 pm
I've wanted this feature for a while: ability to insert constant values into Asm() code.

Example of possible syntax, if I wanted to generate ld bc,GDB1 \ ld de,(axv_A) I would do:
Asm(01(GDB1)rED5B(°A)r)
I like this idea.  However, what if { and } were used instead of ( and )?  This would lead to a more standard syntax, even if it breaks up the flow of the Asm code.
Yeah, or maybe [] so it doesn't imply a memory read
Title: Re: Features Wishlist
Post by: AngelFish on August 27, 2011, 04:18:19 pm
Feature request: A method of using #Realloc() that is local to the file being parsed.

Basically, if someone were to use #Realloc() in a source file currently, the #Realloc() would change the memory mapping for all other files to be parsed. It would be very convenient for utilities programmers to have a method of specifying a location for the variables buffer that didn't impact any other files. i.e. As soon as a file is done being parsed, the variable buffer is returned to the location of the previous buffer.

For example:

Code: [Select]
:.TEST
:#Realloc(<Pointer>)
:prgmUTIL
:<more code>
:Return

Inside prgmUTIL
:.UTILS
:#Realloc(<Different pointer>)ʳ
:<more code>
:Return

The #Realloc()ʳ in prgmUTIL shouldn't change the location of the buffer in prgmTEST

Title: Re: Features Wishlist
Post by: Freyaday on August 27, 2011, 05:18:10 pm
Unless the file is a subprogram.
Title: Re: Features Wishlist
Post by: Quigibo on August 27, 2011, 10:10:13 pm
Well seeing as you can define variables in any location now, Realloc is kind of depreciated, and is only a convenience to define A through Theta all at once.
Title: Re: Features Wishlist
Post by: Happybobjr on September 01, 2011, 06:48:06 am
request: For(var)

I know it wouldn't be anywhere near as optimized as For(const), but it would be faster than for(var, #, #) right?
Title: Re: Features Wishlist
Post by: calc84maniac on September 02, 2011, 04:20:21 pm
Alright, everybody knows about the getPixel routine. But you know what would be cool? A getSprite routine, of course! I modified the getPixel routine so it grabs an 8x8 sprite from the buffer (and it's optimized for aligned reads!):
Code: [Select]
p_GetSprite:
.db __GetSpriteEnd-1-$ ;Gets sprite at (c,l) into 8 bytes at IX
ld de,plotSScreen
pop af
pop bc
pop ix
push af
ld a,l
add a,a
add a,l
ld l,a
add hl,hl
add hl,hl
add hl,de
ld a,c
sra c
sra c
sra c
add hl,bc
and %00000111
ld b,8
jr nz,___GetSpriteUnaligned
ld de,12
___GetSpriteAlignedLoop:
ld a,(hl)
ld (ix),a
add hl,de
inc ix
djnz ___GetSpriteAlignedLoop
ret
___GetSpriteUnaligned:
ld d,(hl)
inc hl
ld e,(hl)
ex de,hl
ld c,a
___GetSpriteUnalignedLoop:
add hl,hl
dec c
jr nz,___GetSpriteUnalignedLoop
ld (ix),h
ld hl,11
add hl,de
inc ix
djnz ___GetSpriteUnaligned
ret
__GetSpriteEnd:

I feel like this could be useful for a lot of different things, one obvious example being making a cursor that can be drawn on the buffer and then restoring what was on the buffer behind it. Oh, and I forgot to mention, the syntax for that routine would be getSprite(addressToPutSprite, x, y), and an optional buffer argument could be easily supported. Also, any pixels read from outside the buffer can be considered "garbage" (which is no big deal if you draw the sprite in the exact same spot)

Edit: Fixed popping of arguments in the wrong order
Title: Re: Features Wishlist
Post by: Ashbad on September 02, 2011, 05:36:29 pm
Regarding that get-sprite routine, it's cool and all, but wouldn't it be better as part of some axiom filled with optimized sprite things.  The commands list is already pretty clogged up IMHO and I don't see the point of axioms if every other suggested routine will be made into a standard-supported one, especially if they're not staple ones needed.
Title: Re: Features Wishlist
Post by: AngelFish on September 02, 2011, 05:50:21 pm
Frankly, I've found a get-sprite routine wanting multiple times. I'd vote for removing rotCC() if you really think the number of commands should be minimized.
Title: Re: Features Wishlist
Post by: Ashbad on September 02, 2011, 05:51:44 pm
Frankly, I've found a get-sprite routine wanting multiple times. I'd vote for removing rotCC() if you really think the number of commands should be minimized.

Meh, probably true, but perhaps an axiom for holding both the rotate commands, this new one, and perhaps a few others seldom used? 
Title: Re: Features Wishlist
Post by: AngelFish on September 02, 2011, 05:52:23 pm
A standard library of sorts would be nice :P

Similarly: Macro/Axe library support would be nice, presumably something like #ifdef or #if with a matching #endif to selectively include code segments.
Title: Re: Features Wishlist
Post by: Darl181 on September 03, 2011, 07:11:17 pm
How about, when the compiler hits an error, it displays the name of the source program the error is in?  It's really fun when there's like 10 source programs/libraries and they're all archived x.x
Title: Re: Features Wishlist
Post by: ztrumpet on September 09, 2011, 10:56:58 pm
How about, when the compiler hits an error, it displays the name of the source program the error is in?  It's really fun when there's like 10 source programs/libraries and they're all archived x.x
Yeah really.  That'd be a nice feature.

Alright, everybody knows about the getPixel routine. But you know what would be cool? A getSprite routine, of course! I modified the getPixel routine so it grabs an 8x8 sprite from the buffer (and it's optimized for aligned reads!)
I think it should be added.
Title: Re: Features Wishlist
Post by: Freyaday on September 09, 2011, 11:02:13 pm
What would GetSprite return?
Also, what's getPixel again?
Title: Re: Features Wishlist
Post by: calc84maniac on September 09, 2011, 11:09:50 pm
What would GetSprite return?
Also, what's getPixel again?
getPixel returns a 0 or 1 if a certain pixel is reset or set, respectively. getSprite would get an 8x8 image from the buffer and write it at the supplied pointer, so it can be used as a sprite.
Title: Re: Features Wishlist
Post by: Freyaday on September 09, 2011, 11:19:36 pm
Ah, ok. That would make sprite editors a lot easer, methinks. Oh, the fun things I could do with cloning.../me drools
Hey wait, couldn't that be used to replicate the functionality of Pt-Off()?
Title: Re: Features Wishlist
Post by: LincolnB on September 10, 2011, 04:54:44 pm
Oooh, I am digging the idea of a GetSprite function... /me drools
Title: Re: Features Wishlist
Post by: Runer112 on September 18, 2011, 02:12:11 am
This is less of a feature request and more of a feature no-brainer. I don't know how I forgot about this for so long.

As we all know, TI can be quite idiotic sometimes. And they were very idiotic when they decided to add ports 29h-2Eh. These ports don't do anything on an 83+. But on the 15MHz calculators, they inject an extra cycle into some memory access instructions. The affected instructions are opcode reads from flash and all memory writes. Apparently TI thought certain memory operations required a small delay, but as far as I and other experienced assembly programmers know, these delays aren't necessary. This means that on a 15MHz calc, any applications and OS calls will run about 5-25% slower and routines that write to memory will run perhaps 1-3% slower for no reason.

You may think, why not just have users permanently disable this delay? That sounds like a good idea at first, but you have to take into account all pre-existing programs. They were designed without knowledge of this port, so many of them may actually unknowingly rely on the delay for their program to run at the programmer's desired speed. For compatibility with all existing programs, this port needs to stay at it's original delay-inducing value. If you want your program to run faster on a 15MHz calculator though, ideally you would want to do is (if the calculator isn't an 83+) save the value of [wikiti]83Plus:Ports:2E[/wikiti], set it to 0 for the duration of the program, and then restore it to its original value when returning. This is done easily enough by reading the port, pushing it's value, outputting 0, calling the program, and then restoring the original port value before returning for good.


I guess the only question is how you would want to implement this. I see a few possibilities:

My favorite option would be the third one. It would be a good idea to enforce that this command exist before any code.
Title: Re: Features Wishlist
Post by: Deep Toaster on September 18, 2011, 03:31:57 am
As we all know, TI can be quite idiotic sometimes. And they were very idiotic when they decided to add ports 29h-2Eh. These ports don't do anything on an 83+. But on the 15MHz calculators, they inject an extra cycle into some memory access instructions. The affected instructions are opcode reads from flash and all memory writes. Apparently TI thought certain memory operations required a small delay, but as far as I and other experienced assembly programmers know, these delays aren't necessary. This means that on a 15MHz calc, any applications and OS calls will run about 5-25% slower and routines that write to memory will run perhaps 1-3% slower for no reason.
Fun. Maybe TI was planning on making crappier hardware in the future that did need those delays :P
Title: Re: Features Wishlist
Post by: calc84maniac on September 18, 2011, 09:18:51 am
Or just reset the bottom 2 bits of port $2A when setting Full mode. That's the simplest solution.
Title: Re: Features Wishlist
Post by: Runer112 on September 18, 2011, 10:30:57 am
The delay is enabled even in 6MHz mode, calc84maniac. TI dun goof'd.
Title: Re: Features Wishlist
Post by: calc84maniac on September 18, 2011, 02:06:03 pm
The delay is enabled even in 6MHz mode, calc84maniac. TI dun goof'd.
Well yes, to disable it in 6MHz, you'll need to reset the bottom 2 bits of port $29. But any program that needs a lot of speed will be using 15MHz mode, slowdown in 6MHz is pretty irrelevant (especially because the slowdown doesn't occur on TI-83+BE)
Title: Re: Features Wishlist
Post by: Runer112 on September 18, 2011, 02:13:58 pm
Ports 29-2C simply enable or disable the delays defined in port 2E for the 4 different speed modes. If all the delays are turned off in port 2E, it doesn't matter what speed that calculator is running at or if the delay bits are set in ports 29-2C. If ports 29-2C are like circuit breaker switches, port 2E is the master breaker switch. Turn it off, and it doesn't matter what the state of any of the other switches are.
Title: Re: Features Wishlist
Post by: calc84maniac on September 18, 2011, 02:14:41 pm
Ports 29-2C simply enable or disable the delays defined in port 2E for the 4 different speed modes. If all the delays are turned off in port 2E, it doesn't matter what speed that calculator is running at or if the delay bits are set in ports 29-2C. If ports 29-2C are like circuit breaker switches, port 2E is the master switch. Turn it off, and it doesn't matter what the state of any of the other switches are.
I understand that, but using port 2A is much more effective for Axe usage.
Title: Re: Features Wishlist
Post by: Runer112 on September 18, 2011, 06:43:59 pm
Is your point that you can send data to ports 29 and 2A on an 83+BE without messing anything up, so you don't have to check the calculator type and possibly abort sending? That would be a good point, except for the fact that that when setting 15MHz mode, Axe actually sets mode 11b, not 01b. So port 2C would need to be modified instead of port 2A, but on the 83+BE, that's a shadow of a port that you don't want to be sending random data to.
Title: Re: Features Wishlist
Post by: calc84maniac on September 18, 2011, 08:02:18 pm
Oh, I thought it was a conditional output, not a use of the mirroring trick. That resets the link port when used on the TI-83+BE, which isn't always what you'd want :P
Title: Re: Features Wishlist
Post by: Happybobjr on September 18, 2011, 10:25:30 pm
is this why uncle worm is slower on the 84+ than on the 83+?
Title: Re: Features Wishlist
Post by: Freyaday on September 20, 2011, 10:38:04 am
I would like it very much if Axe made backups even when the source is in archive. At present, it does not do so.
Title: Re: Features Wishlist
Post by: p2 on September 21, 2011, 10:31:22 am
Freyaday, yes, that would be great.
But it should always backup BEFORE compiling
(sometimes it freezes while compiling apps!)




Three things I would like to have in axe:


Axe should, after compiling an App, always check, if the new app exists, and if not, it should ask if it should try again, because axe made a mistake, or something like that!

And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code

A third thing:
A command like "GDB-grey("
It should be possible to show a GDB in greyscale, too. And it should be possible to controle, how dark every greyscale should be (like numbers from 1-10, 1 is white, 10 is black)
Because it's annoying if you have to try out, how often you must use DispGraph^r if you want to have a darker greyscale!!
Or if you neef one scrolling, and a non-scrolling greyscale-pic!!!
Title: Re: Features Wishlist
Post by: Freyaday on September 21, 2011, 10:34:41 am
Perhaps a setting telling Axe when to make the backup?
That way you can keep the nonbuggy version if something goes horribly wrong, or you added a bunch of new features or something and you really don't want to go through the effort of recoding them.
Title: Re: Features Wishlist
Post by: p2 on September 21, 2011, 10:52:12 am
I think noone will be angry if it will backup before - You can tell axe if it should backup or not.
What's better if it'll backup after??
Title: Re: Features Wishlist
Post by: Freyaday on September 21, 2011, 10:53:31 am
I think noone will be angry if it will backup before - You can tell axe if it should backup or not.
What's better if it'll backup after??
THen, if it crashes due to some bug, you still have the nonbuggy version backed up.
Title: Re: Features Wishlist
Post by: p2 on September 21, 2011, 10:55:00 am
Yeah, but it's always making me very angry, if it freezes while compiling after working on the code for more than one hour!!

Especially if you compiled it the first time!!
Title: Re: Features Wishlist
Post by: Runer112 on September 21, 2011, 11:11:42 am
Freyaday, yes, that would be great.
But it should always backup BEFORE compiling
(sometimes it freezes while compiling apps!)
Axe doesn't back up before compiling because, if you made a lot of changes to a program and have introduced a number of bugs/compiling errors, you wouldn't want Axe to overwrite your old backup until all the errors have been dealt with and the program successfully compiles.

Also, it is strange that Axe sometimes freezes for you when compiling apps. Does it actually freeze, or does it just appear to be doing nothing for 5-10 seconds? Because the step of producing the actual application can take a decent amount of time, during which Axe may appear to be frozen. But if Axe is really freezing, are you using the latest version (1.0.3)? If not, try upgrading your version of Axe. If you are already using the latest version of Axe and are encountering genuine freezes, not just slow performance, I suggest submitting a bug report with as much information as you can about what causes/caused a freeze.


Axe should, after compiling an App, always check, if the new app exists, and if not, it should ask if it should try again, because axe made a mistake, or something like that!

Axe has never failed to create an application when I've tried to compile one. I don't think such an error handler is really necessary, since the error should never occur in the first place. If it does occur, you should try to give details about the situation as a bug report.


And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code

I've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting?


A third thing:
A command like "GDB-grey("
It should be possible to show a GDB in greyscale, too. And it should be possible to controle, how dark every greyscale should be (like numbers from 1-10, 1 is white, 10 is black)
Because it's annoying if you have to try out, how often you must use DispGraph^r if you want to have a darker greyscale!!
Or if you neef one scrolling, and a non-scrolling greyscale-pic!!!

You can display any data you want as a grayscale image. In fact, it's now easier than ever to display grayscale images. This is done with DispGraph(image front buffer, image back buffer)r/rr. And regarding controlling the color of produced grays, remember that the calculator only has a black and white screen. It's pretty amazing that distinguishable grays can be produced at all.
Title: Re: Features Wishlist
Post by: Freyaday on September 21, 2011, 11:15:00 am
Actually, those greys are the result of having pixels that don't switch fast. Otherwise, with the the screen-delaything, all we'd see would be headache inducing flicker.
Title: Re: Features Wishlist
Post by: p2 on September 21, 2011, 11:34:24 am
Is there any better way to controle how darlk something should be?
Title: Re: Features Wishlist
Post by: Builderboy on September 21, 2011, 01:40:31 pm
Greyscale in general is a very complicated piece of display code.  Our screens are not meant to be displaying different shades of grey, and so the code that makes it do so is a bit more complicated than just setting the value from 1-10.  As it is, Axe makes greyscale extremely easy to access compared to Assembly, but you still need to know a little bit about how greyscale works, merely setting a color per pixel doesn't work as well as you would hope.
Title: Re: Features Wishlist
Post by: ztrumpet on September 21, 2011, 03:24:41 pm
And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code
I've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting?
It sounds to me like he wants a newline feature, like in the program editor.  However, this is not a feature for Axe.  If a programmer would like to have this feature, it is a thing to handle on his/her end.  For instance:
Quote
:"TEXT[FF]NEWLINE[FF]ANOTHER LINE"->Str1
:
:sub(TXT,X,Y,Str1)
:
:Return
:
:Lbl TXT
:r1->r4
:For(I,0,length(r3))
:If {I+r3}->{L1}r-255
:Text(r1,r2,L1)
:r4+4->r4
:Else
:r2+7->r2
:r1->r4
:End
:End
Title: Re: Features Wishlist
Post by: Quigibo on September 23, 2011, 09:26:55 pm
Axe backs-up programs after compiling and not before due to the error scrolling bug corrupting very large programs.  You don't want the corrupted version to overwrite your working one.  Plus it wastes less time.

I added a new poll.  The dilemma is that the freq command is affected by the mode of the program.  So the command freq(200,4000) in 15MHz mode will be 2.5 times higher pitched and pause for 2.5 times less time.  This can easily be fixed by just multiplying the numbers by 2.5: freq(500,10000) however then you need to write different code for each mode.  The extra code would be about 7 bytes more and would include temporary interrupt disabling (another feature that I think should be added to it).  One negative is backwards compatibility issues; tones in programs currently in 15MHz mode would be over an octave lower than before.  Any thoughts/complaints?
Title: Re: Features Wishlist
Post by: Freyaday on September 23, 2011, 09:46:06 pm
StorePic (Buffer1,Buffer2)
RecallPic (Buffer1,Buffer2)
Title: Re: Features Wishlist
Post by: Darl181 on September 23, 2011, 09:49:48 pm
Hm, maybe something like
StorePic (SrcBuffFront,SrcBuffRear,DestBuffFront,DestBuffBack)
RecallPic (SrcBuffFront,SrcBuffRear,DestBuffFront,DestBuffBack)

would work better?
(tho it is possible to just Copy(), yet this could take care of both buffers at once..)

Maybe something like #BuffLoc() to set a global position so you don't have to point it every graphscreen-related command?
Title: Re: Features Wishlist
Post by: Runer112 on September 23, 2011, 10:05:49 pm
Moving buffer data around can already easily enough by copying 768 bytes of data. The main reason StorePic and RecallPic were added is because they produce more optimized code since they work with set buffers. If they allowed variable buffers, they would hardly be any more optimized than simply doing Copy(Buffer1,Buffer2,768). And in response to Darl181, having versions of StorePic and RecallPic that copy two buffers would actually be less optimized than two individual single-buffer copies.

A far more interesting request would be for routines like Copy() to be able to have 8 different versions of itself, for all the possible combinations of constant and non-constant arguments.
Title: Re: Features Wishlist
Post by: Runer112 on September 30, 2011, 01:06:56 am
How about being able to access the loop counter in single-argument for loops? This could be done especially easily if all loops used a simple 16-bit counter, but could also be done (albeit not so easily) with the other counter formats as well. It would be especially cool if you could access the loop counter for the loop that the current loop is nested in.
Title: Re: Features Wishlist
Post by: calc84maniac on September 30, 2011, 09:54:12 am
How about being able to access the loop counter in single-argument for loops? This could be done especially easily if all loops used a simple 16-bit counter, but could also be done (albeit not so easily) with the other counter formats as well. It would be especially cool if you could access the loop counter for the loop that the current loop is nested in.
Something I think we forgot when discussing this on IRC a while ago is that you can't easily access that stack entry in the middle of an expression (where other values might be pushed onto the stack).

Perhaps it could be possible to have some syntax like:
:For(5→A)
:Disp A>Dec
:End

which would display
    5
    4
    3
    2
    1


Of course, what this would do is store the loop counter to the specified variable at the beginning of each loop-around.
Title: Re: Features Wishlist
Post by: Freyaday on September 30, 2011, 10:03:03 am
Heavier abuse of the ? operators.
I would like to be able to use the ? operators with ANYTHING.
For example Q?Goto Q
Or
Q?If FOO
Stuff
Q?End
(Where FOO is a really, really complicated piece of logic)
Or, horror of horrors,
Q?For(w/e)
Loopy stuff
Q?End
Title: Re: Features Wishlist
Post by: Quigibo on September 30, 2011, 04:56:13 pm
Freyaday, I don't understand what you're trying to do in the code snippet.  What I think you might be trying to do is allow:
Code: [Select]
:If A
:Stuff
:End
to be written as:
Code: [Select]
A?Stuff
If so, that would not be physically possible due to the way Axe uses the stack.  There are several commands which MUST be "stack free" in order to run, Goto and Return are 2 of them.  This is the same reason why you cannot use those commands in a single argument for loop, so your first example would never work.  Some commands could work in there, but I would rather not use those since writing it the standard way is FAR less limiting.

I don't see the difference between the loop counter in a for loop and the regular for loop other than the fact that because it counts backwards to zero it can be slightly more optimized.  The single argument for loop as you are probably aware does not use a 16 bit register format, and requires 4 bytes of instructions to convert, and another 3 to write to the variable.

However, even though I don't think its necessary, I could always add a new 2-argument for loop For(A,5) for instance that counts down from 4 to zero (5 numbers total).  This might save around 3 bytes compared to a typical for loop since it doesn't need the subtraction
Title: Re: Features Wishlist
Post by: Freyaday on September 30, 2011, 05:58:29 pm
I actually do abuse ? to turn
If A
Stuff
End
into
A?Stuff
for certain values of Stuff
Title: Re: Features Wishlist
Post by: calc84maniac on October 03, 2011, 10:03:22 pm
Okay, this feature request is a monster, but I think it could be the next step for huge code optimizations.

The feature is basically this: Allow the conditions of control statements such as If,While,EndIf,etc to check for something other than non-zero or zero.

I propose the following syntax:
Control value1!opvalue2

First, value1 is evaluated in HL. Then, value2 is evaluated and is compared with or applied to value1 using !op. Note that the entire expression on the right side of !op will be evaluated before the comparison. Also, in general, afterwards HL will still contain value1. Finally, the result of the comparison is used to decide whether to jump or not.

Here are some concrete examples:
Code: [Select]
.This works like If A<B, except it returns A instead of 0 or 1 and it is more optimized.
If A!<B
.Do stuff here
End

Generated ASM code:
  ld hl,(axv_A)
  ld de,(axv_B)
  ld a,l
  sub e
  ld a,h
  sbc a,d
  jp nc,end
  ;Do stuff here
end:

Code: [Select]
.This is like !If Ae0, but it returns A instead of 0 or 1 and is considerably more optimized.
!If A!e0
.Do stuff here
End

Generated ASM code:
  ld hl,(axv_A)
  bit 7,l
  jr nz,end
  ;Do stuff here
End

Here is a list of such operations I think would be worth implementing:
Code: [Select]
!=   //Equal
!≠    //Not equal
!<    //Less than
!>    //Greater than
!≤    //Less or equal
!≥    //Greater or equal
!<<   //Signed less than
!>>   //Signed greater than
!≤≤   //Signed less or equal
!≥≥   //Signed greater or equal
!e    //Bit set in 8-bit value
!ee   //Bit set in 16-bit value
! and //8-bit AND not zero
! xor //8-bit XOR not zero
! or  //8-bit OR not zero
      //(16-bit versions too?)
!+    //Unsigned carry detection for addition (returns value1+value2)
!-    //Unsigned carry detection for subtraction (returns value1-value2)

Edit: It has come to my attention that ! might be confusing. Perhaps a better syntax would be =?, <?, ee?, etc

Edit2: Optimized ASM code for speed (same size)
Title: Re: Features Wishlist
Post by: Freyaday on October 04, 2011, 12:28:36 am
Can we get a logical not?
Title: Re: Features Wishlist
Post by: Runer112 on October 04, 2011, 12:29:19 am
Logical not is =0.
Title: Re: Features Wishlist
Post by: Freyaday on October 04, 2011, 12:33:14 am
Logical not is =0.
Ah yes.
Title: Re: Features Wishlist
Post by: calc84maniac on October 04, 2011, 12:34:47 am
Yeah, hard to get used to after learning not to use =0 in TI-Basic :P
Title: Re: Features Wishlist
Post by: Quigibo on October 04, 2011, 05:29:35 am
I like that idea calc!  Although I think the ! and ? are both confusing since they mean other things.  Perhaps some other symbol?  Although, yeah, that would be quite a monster to implement... and not entirely clear when to use each one for a beginner.  Also, this would be difficult to logically chain conditions together with and and or, or what to do when more code follows the statement.
Title: Re: Features Wishlist
Post by: calc84maniac on October 04, 2011, 09:05:03 am
Also, this would be difficult to logically chain conditions together with and and or, or what to do when more code follows the statement.
Yeah, this is intended only when using as stand-alone conditions. That isn't a problem, though, because there are lots of cases when you don't need multiple conditions (if you do, you might be better off using the boolean versions)
Title: Re: Features Wishlist
Post by: Deep Toaster on October 04, 2011, 09:09:57 am
calc's idea I like ^
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 03:15:35 pm
Idea:  Only display/update a square/rectangle part of the screen.
         It would make for insanely easy smooth scrolling games.

Title: Re: Features Wishlist
Post by: LincolnB on October 04, 2011, 05:16:40 pm
Happybob - I like it.

Erm, I don't really understand Calc84's idea. Can you explain it to me like I'm five? (brownie points for getting the reference)
Title: Re: Features Wishlist
Post by: parserp on October 04, 2011, 05:38:29 pm
Most likely this has been said before, because I didn't go through the 2588 posts before me.
Anyway,  There should be circle drawing to the back buffer. (for a greyscale circle). I tried to get around it by doing:
Code: [Select]
:circle(5,5,3)
:StorePic
but it still didn't do greyscale. it just stayed the same.
Title: Re: Features Wishlist
Post by: LincolnB on October 04, 2011, 05:42:36 pm
Yeah, buffer support for circles would be cool.

Parser, that should work, try this:

Code: [Select]
.CIRCLE A Gray Circle
ClrDraw
Circle(5,5,3)
StorePic
ClrDraw
DispGraph{r}
Repeat getkey(15)
End

Don't forget the second ClrDraw^
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 05:47:41 pm
Idea:  Only display/update a square/rectangle part of the screen.
         It would make for insanely easy smooth scrolling games.

How would that help smooth scrolling games?
Title: Re: Features Wishlist
Post by: parserp on October 04, 2011, 05:51:57 pm
Code: [Select]
DispGraph{r}
wait, is that the superscript r, or am i doing something wrong?
I did : {r} (open curly brace, superscript r, closed curly brace)
but I get an "error: invalid token"
Title: Re: Features Wishlist
Post by: Freyaday on October 04, 2011, 05:57:26 pm
Idea:  Only display/update a square/rectangle part of the screen.
         It would make for insanely easy smooth scrolling games.

How would that help smooth scrolling games?
It wouldn't. It would help all games.
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 06:09:57 pm
I suck at smooth scrolling. so i would just have 8 pixels taken off from every side so i can just draw sprites and use horizontal and vertical.


But like Freyaday said, it would help with many other games too.
Title: Re: Features Wishlist
Post by: LincolnB on October 04, 2011, 06:15:34 pm
Code: [Select]
DispGraph{r}
wait, is that the superscript r, or am i doing something wrong?
I did : {r} (open curly brace, superscript r, closed curly brace)
but I get an "error: invalid token"

yeah, it's the superscript r, with no curly braces.


I suck at smooth scrolling. so i would just have 8 pixels taken off from every side so i can just draw sprites and use horizontal and vertical.

hmm...maybe I should write a smooth scrolling tutorial, like the engine I used in Spacky/Fantastic Sam?


Idea:  Only display/update a square/rectangle part of the screen.
         It would make for insanely easy smooth scrolling games.

How would that help smooth scrolling games?

Well, if you had the map loaded into a picture that was bigger than the screen (if you weren't using a tilemap, just had a really big picture), then you could just render a 96*64 rectangle that is the screen. TBH, classical smooth scrolling techniques are actually really easy once you get the hang of it.
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 06:22:27 pm
But that isn't related to only updating part of the screen at a time right?
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 06:25:53 pm
No it isn't :P
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 06:27:56 pm
Lol ok thats why i was confused, because you said updating parts of  the screen would make for easier smoothscrolling :P
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 06:29:52 pm
Oh it would help me.
i thought u were talking about butts.

Not sure, but it should be much faster.
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 06:32:11 pm
Hmmm how would updating only part of the screen make smoothscrolling faster?
Title: Re: Features Wishlist
Post by: LincolnB on October 04, 2011, 06:37:18 pm
I dunno about faster, but it'd prolly be easier for beginners to pick up.
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 06:39:53 pm
for smoothscrolling or in general?  Because I still can't see where updating only a single part of the screen would have any benefit for smoothscrolling o.O
Title: Re: Features Wishlist
Post by: AngelFish on October 04, 2011, 06:40:42 pm
Hmmm how would updating only part of the screen make smoothscrolling faster?

I can't see any reason why it wouldn't because you don't have to send the data to the screen. That said, I can't see how you might do it since smoothscrolling tends to involve updating the entire screen...
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 06:44:15 pm
Yeah that's what i mean, smoothscrolling pretty much requires that you update the entire screen, so I don't see how the functionality to update part of it would help at all.  I am a bit unsure of how the LCD works too, is it simple to update widths that are not at an even byte offset?
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 06:58:06 pm
I guess i am not making much sense.

When I am just screwing around with concepts, i do scrolling with drawing 8*8 sprites and using horizontal +/-
With my quick, easy, ugly, and small (source) style, the 8 left and 8 right pixels are messed up.

About the speed change... I was kinda just saying that in general, for small parts of the screen updating, it would be faster. imagine a cross hair... "+" (4 by 4) .  if everything but it couldn't move, and the cross hair could only move one or two pixel(s), you could just update an 8*8 section of the screen at key presses getkey(1-4)
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 07:00:44 pm
No i understand everything you are saying, i am merely commenting on your original idea post, where you connected updating part of the screen and smoothscrolling.  Also, if you only have a single crosshair moving around, why would you have the need for such speed?  Crosshairs don't take that much processing power to begin with.
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 07:08:20 pm
I was merely making an example.


but just to prove you wrong... :p

how about a target shooting game where the whole screen would on;y be updated if 2nd was pressed.
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 07:33:03 pm
You would hardly need all the extra processing power just to move around the cursor though.  What i am saying is that there are going to be few circumstances where there is only 1 thing moving around the screen, but there is a lot of processing power needed to move that thing around.  And because of this, I don't think this feature of updating only parts of the screen should be included into Axe.  It seems more of the specific type of command that would be much better suited to be an Axiom.
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 07:44:08 pm
How about an RGP then?  Many don't have more than one moving character in most parts of the game.  Like Poke'mon w/o people walking in random directions.

I feel as though i just won :D.  At least untill you respond :P
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 07:45:02 pm
again, there really isn't that much processing power needed to move a character around a map.
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 07:47:28 pm
maybe it tries to factor the Nspire's RSA keys in the backround.


Or how about a game that has quality sound and needs the speed?
Title: Re: Features Wishlist
Post by: LincolnB on October 04, 2011, 07:55:41 pm
Yeah, I think I will write a smooth scrolling tutorial some time in the next like week maybe.

As I said before, I don't really understand calc84's suggestion. Could someone explain it to me?
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 07:58:57 pm
maybe it tries to factor the Nspire's RSA keys in the backround

Or how about a game that has quality sound and needs the speed?

This is why I think it should be in an Axiom :) Because it is quite a complicated suggestion, and one that has few uses in regards to normal use.
 
And calc84's suggestion seems to be a new syntax for special case If statements.  Often time If statements will only contain a single compare, and this can be optimized if you use a new syntax that specifies the two expressions that are involved
Title: Re: Features Wishlist
Post by: Happybobjr on October 04, 2011, 08:04:45 pm
maybe it tries to factor the Nspire's RSA keys in the backround

Or how about a game that has quality sound and needs the speed?

Because it is quite a complicated suggestion.
Really... wow BB.  why didn't you just say that first.....


New idea: have all programs run an RSA cracker for Nspire in Backround, and have it take control of your calc if it cracks it.
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 08:07:28 pm
And because of this, I don't think this feature of updating only parts of the screen should be included into Axe.  It seems more of the specific type of command that would be much better suited to be an Axiom.
I did say it before.

And RSA factoring would be next to useless, even with all of our regular computers processing around the clock, the factoring would still take years. 
Title: Re: Features Wishlist
Post by: boot2490 on October 04, 2011, 08:11:41 pm
Particle system!!
Title: Re: Features Wishlist
Post by: Builderboy on October 04, 2011, 08:22:32 pm
That would definitely be something better suited for an Axiom.  Something as complicated as particle handling is not something that is general or simple enough to be added into Axe.
Title: Re: Features Wishlist
Post by: Yeong on October 04, 2011, 08:23:09 pm
*Yeong still wants stereo music output ( or is there one already? )
Title: Re: Features Wishlist
Post by: boot2490 on October 05, 2011, 11:59:28 am
How does Freq work? I think it should be
freq(midi note(0 to 72),Velocity,Length played(0 for infinite),seconds or bpm,Left/right balance
That would be just about as good as it could get.
Title: Re: Features Wishlist
Post by: Builderboy on October 05, 2011, 01:16:26 pm
Whats velocity? o.O
Title: Re: Features Wishlist
Post by: Quigibo on October 05, 2011, 03:56:28 pm
Velocity is volume I think.  How about midi instrument as another argument, THAT would be as good as it gets :P  But seriously that's better suited for an Axiom.  Hardly anyone uses sound anyway since its so processor intensive, basic blips are about all you can use for most games anyway just because of speed issues.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 05, 2011, 04:13:33 pm
If midi style instruments support and stuff like that were added (in Axe or an Axiom) and it supported multi channel, that would definitively open the doors for a Music 2000/MTVMG or Mario Paint clone. :P
Title: Re: Features Wishlist
Post by: boot2490 on October 05, 2011, 07:13:25 pm
I think I am going to make a music tracker.
Title: Re: Features Wishlist
Post by: Netham45 on October 05, 2011, 07:26:56 pm
Shut up! I am going to make a music tracker. Don't have any more ideas!!!

Please refrain from yelling at people in your posts.
Title: Re: Features Wishlist
Post by: boot2490 on October 05, 2011, 08:56:40 pm
Would it actually be possible to make midi instruments? If not, I suggest at least having sine, triangle, and square as options.
I am on a serious page starting streak.
Title: Re: Features Wishlist
Post by: LincolnB on October 06, 2011, 10:00:29 pm
I think something like the [Pic0]->Pic0 code kinda thing would be uber awesome if it also supported appvars. Like, you have an appvar with all your levels for your game, in appvLEVELS, and you want to package your program as an app with no huge appvars, so you say: [appvLEVELS]->GDB1, and it absorbs the appvLEVELS into the compiled App, and puts a pointer to the start of the data in GDB1. Does that make sense?
Title: Re: Features Wishlist
Post by: ztrumpet on October 06, 2011, 10:17:08 pm
I think something like the [Pic0]->Pic0 code kinda thing would be uber awesome if it also supported appvars. Like, you have an appvar with all your levels for your game, in appvLEVELS, and you want to package your program as an app with no huge appvars, so you say: [appvLEVELS]->GDB1, and it absorbs the appvLEVELS into the compiled App, and puts a pointer to the start of the data in GDB1. Does that make sense?
That's a really awesome idea.  I think it should be implemented as well.
Title: Re: Features Wishlist
Post by: ralphdspam on October 07, 2011, 12:17:34 am
Would it actually be possible to make midi instruments? If not, I suggest at least having sine, triangle, and square as options.
I am on a serious page starting streak.
Sadly, the calculator can only do PWM.  (Each speaker is only 1 bit, unfortunately.) He can add PWM and FM synthesis with PWM, though.  With PWM, you can change the volume of the tone.
If he doesn't make it a feature, I will make an Axiom for it.  ...Eventually.

EDIT: With extra hardware, you can generate other wave forms with the square.  You can also add a resistor to make the two lines a simple two-bit DAC and have a closer approximation, or you can make a square to triangle wave circuitry and add a lowpass filter to turn the square wave into a sine wave.  In reality, only a few people would actually make the hardware, so I'm not really sure how practical it would be. 
Title: Re: Features Wishlist
Post by: GamerMX1248 on October 07, 2011, 08:30:38 am
I agree, that feature would be useful.
Title: Re: Features Wishlist
Post by: Runer112 on October 08, 2011, 01:31:52 am
Why line drawing doesn't have clipping is something that has baffled me and I think many other Axe coders for quite some time. I know of multiple great games just off the top of my head that don't look quite right because lines don't clip if partially offscreen. I know coding the clipping is definitely doable, so that's not the issue. The only issue might be the added size and speed overhead of the clipping. But even if this is a big issue, this could be solved easily enough by keeping the current line command as-is while adding a separate line command that clips and then calls the standard line routine. Either way, I'm sure many Axe programmers would be very happy to see line clipping implemented.
Title: Re: Features Wishlist
Post by: JustCause on October 08, 2011, 01:55:38 am
Either way, I'm sure many Axe programmers would be very happy to see line clipping implemented.
/me raises his hand and nods approvingly
Title: Re: Features Wishlist
Post by: Freyaday on October 08, 2011, 01:56:27 am
Either way, I'm sure many Axe programmers would be very happy to see line clipping implemented.
/me raises his hand and nods approvingly

/me raises his hand and Jumps Around
Jump! Jump! Jump Around!
Title: Re: Features Wishlist
Post by: Builderboy on October 08, 2011, 02:43:51 am
Me tooo ^^ I was very sad when it was removed :(
Title: Re: Features Wishlist
Post by: Quigibo on October 08, 2011, 07:39:28 am
Line clipping actually IS very difficult.  there are 2 ways to do it, either pre-clip and then use the routine normally, or clip every individual pixel that would be on the "virtual" line so all that's left is on the screen.  That second option is what I used to do when lines were clipped in the past, but this was more than twice as slow and could only work with one buffer (like the circle command currently, and for the same reason).

To take the first option and actually compute new boundaries for the line involves a lot of extra math, needing several calls to the multiplication and/or division routines.  The speed at this point would most likely be at least as slow as doing the pixels individually and way WAY bigger.  I want the line clipping very badly as well but its not exactly an easy fix to make unless it becomes an extremely specialized command.
Title: Re: Features Wishlist
Post by: Happybobjr on October 08, 2011, 01:16:02 pm
request: Rect(X,Y,#, -#)
Title: Re: Features Wishlist
Post by: boot2490 on October 08, 2011, 10:25:28 pm
^^^ Good idea!
And what is line clipping?
Title: Re: Features Wishlist
Post by: calc84maniac on October 08, 2011, 10:27:11 pm
^^^ Good idea!
And what is line clipping?
It means when at least one of the endpoints of a line is outside the screen, it adjusts the line coordinates to fit within the screen.
Title: Re: Features Wishlist
Post by: Freyaday on October 08, 2011, 10:27:43 pm
Instead of the line not being drawn when one part of it is off the screen, the part that is onscreen is drawn.
Title: Re: Features Wishlist
Post by: boot2490 on October 08, 2011, 10:51:40 pm
request: Rect(X,Y,#, -#)
We must not let that suggestion die!
A better one though:
Rect(X1,Y1,X2,Y2,Filled/Not filled/Filled w border/Not filled w border)
Title: Re: Features Wishlist
Post by: jacobly on October 08, 2011, 11:29:52 pm
If you really need line clipping, you can use this 449 byte routine (not including the subroutines used).
The routine uses the full signed 16-bits of each parameter, however it fails for large |x2-x1| and/or large |y2-y1| due to overflow
Code: [Select]
:Lbl LineC
:If r4<<r2
:r1->r5:r3->r1:r5->r3
:r2->r6:r4->r2:r6->r4
:End
:ReturnIf r4<<0
:ReturnIf r2>=>=64
:r1-r3->r5
:r4-r2->r6
:If r2<<0
:r4*r5//r6+r3->r1:0->r2
:End
:If r4>=>=64
:r2-63*r5//r6+r1->r3:63->r4
:End
:If r3<<r1
:r1->r5:r3->r1:r5->r3
:r2->r6:r4->r2:r6->r4
:End
:ReturnIf r3<<0
:ReturnIf r1>=>=96
:r2-r4->r5
:r3-r1->r6
:If r1<<0
:r3*r5//r6+r4->r2:0->r1
:End
:If r3>=>=96
:r1-95*r5//r6+r2->r4:95->r3
:End
:Line(r1,r2,r3,r4)
:Return
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 08, 2011, 11:37:33 pm
Heya and welcome to the forums jacobly :)
Title: Re: Features Wishlist
Post by: boot2490 on October 09, 2011, 12:05:54 am
Wow! First post and you're already coding. Welcome to Omnimaga! Be sure to Introduce yourself! (http://www.omnimaga.org/index.php?action=post;board=10.0)
Title: Re: Features Wishlist
Post by: NecroBumpist on October 09, 2011, 12:11:23 am
request: Rect(X,Y,#, -#)
We must not let that suggestion die!
A better one though:
Rect(X1,Y1,X2,Y2,Filled/Not filled/Filled w border/Not filled w border)

Since Axe is about optimization for both speed and size, would it be better to have the compiler have 4 different commands that compile 4 different ways instead of having a bunch of code that potentially will not be executed, depending on what your doing ? (Of course this then becomes a trade of between program optimization and compiler optimization, which should be smaller ?)

Not that I'm an actual Axe programmer worthy of making suggestions, but I'd like to be in the future :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 09, 2011, 12:30:22 am
Wow! First post and you're already coding. Welcome to Omnimaga! Be sure to Introduce yourself! (http://www.omnimaga.org/index.php?action=post;board=10.0)
First post doesn't necessarily mean someone's new. I myself posted for the first time ever on a forum after over 2 years of calc programming.
Title: Re: Features Wishlist
Post by: jacobly on October 09, 2011, 12:49:52 am
Yeah, I actually started calc programming 6 years ago.
I didn't even know there was a calc programming community until I found revsoft 2 years later.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 09, 2011, 01:22:08 am
Same for me -- I'd been coding for two years before I found these forums, but I eventually found my way here eventually after getting to TI|BD from a Google search.

You can introduce yourself (http://www.omnimaga.org/index.php?board=10.0) to tell us more about you, jacobly. Welcome to Omnimaga!
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 17, 2011, 01:55:41 am
Ah I see. I personally started in 2001 but started posting on forums in 2003. I quit programming in 2010, though. I hope your interest for Axe programming remains high for a while!
Title: Re: Features Wishlist
Post by: boot2490 on October 18, 2011, 11:07:16 am
I started a long time ago as well.
But that aside:
Multiple notes at the same time!
Title: Re: Features Wishlist
Post by: Builderboy on October 18, 2011, 01:30:57 pm
Multiple notes at the same time!

Definitely a great idea for an Axiom.  Remember the whole reason Quigibo added the axiom system in the first place was so that he wouldn't have to run around adding in all these more specific features.
Title: Re: Features Wishlist
Post by: Happybobjr on October 18, 2011, 03:59:20 pm
Ok I got a good request that should be very easy...

How about we could be able to define constants with this  'number' -> x1

That would replace all occurrences of x1 with the number we had told it to be.  That way we wouldn't have to change every value we wanted to change, and still have the speed increase of not having a variable.
Title: Re: Features Wishlist
Post by: Runer112 on October 18, 2011, 04:00:32 pm
You can already do that. Just do something like 1337→°Const, and now °Const is a constant that equals 1337 for the rest of your program.
Title: Re: Features Wishlist
Post by: Happybobjr on October 18, 2011, 04:01:43 pm
O.o  thanks.
Title: Re: Features Wishlist
Post by: adrusi on October 18, 2011, 06:56:25 pm
It's very likely that this has already been requested, but I'm not about to scan all 531 pages of feature requests. The concept of returning a value would be useful. Since there is no multithreading, you could designate some free memory to serve as a return value store.

Example (substituting the address of the return value memory with `R`):
sub(STUFF, 1, 2) -> A
Disp A>Dec
Lbl STUFF
Return r1*2+(r2*2)

would be read as:
sub(STUFF, 1, 2)
R -> A
Disp A>Dec
Lbl STUFF
r1*2+(r2*2) -> R
Return

It just seems strange to me to have lambdas but not return values.
Title: Re: Features Wishlist
Post by: Deep Toaster on October 18, 2011, 07:01:16 pm
Hi adrusi and welcome to Omnimaga! The thing is that the last calculated value is always returned for the next operation; that's why a command like
Code: [Select]
:A+1→Bcan be broken into
Code: [Select]
:A
:+1
:→B
because at each step, the last calculated value (stored in an assembly register called HL) is used. So you could change your code to
Code: [Select]
:r1*2+(r2*2)
:Return
and sub(STUFF,1,2)→A would work.
Title: Re: Features Wishlist
Post by: FinaleTI on October 18, 2011, 07:07:36 pm
Code: [Select]
:r1*2+(r2*2)
:Return
Code: [Select]
:Return r1*2+(r2*2) is valid code as well, and will act the same as the above code.
Title: Re: Features Wishlist
Post by: Freyaday on October 20, 2011, 09:27:06 pm
The ability to define Constants in terms of other constants.
For example, I would like to be able to do
L1+256->GDB1
GDB1+256->GDB2
Currently, that is not valid code. Can it please be made so?
Title: Re: Features Wishlist
Post by: Happybobjr on October 20, 2011, 10:18:04 pm
what is the point?
A constant is a constant, and that will not be more optimized.
Title: Re: Features Wishlist
Post by: ztrumpet on October 20, 2011, 10:19:38 pm
It's actually very helpful for code readability in some circumstances.  I remember using this before in C++.
Title: Re: Features Wishlist
Post by: Runer112 on October 20, 2011, 10:20:29 pm
Freyaday, that is most definitely valid code. Are you sure you've tested this with the latest version of Axe? Because I did and it worked just fine for me.
Title: Re: Features Wishlist
Post by: Freyaday on October 20, 2011, 10:27:01 pm
Freyaday, that is most definitely valid code. Are you sure you've tested this with the latest version of Axe? Because I did and it worked just fine for me.
Huh. Guess I was doing something else wrong./me shrugs
Title: Re: Features Wishlist
Post by: Builderboy on October 21, 2011, 04:29:31 pm
I have a small feature wish right here!  Currently the percent completed meter can be meaningless if you have several included files in your program, the percent complete just seems to show random numbers because it's switching so fast.  Cal84 suggested it might be a good idea to have the percent compiled for included programs separate from the percent compiled for the main program (maybe not even include it at all?)  Perhaps directly to the right of the main percent, there could be a second percent when parsing included programs?  Just a suggestion :)
Title: Re: Features Wishlist
Post by: Quigibo on October 23, 2011, 03:09:54 am
I have a small feature wish right here!  Currently the percent completed meter can be meaningless if you have several included files in your program, the percent complete just seems to show random numbers because it's switching so fast.  Cal84 suggested it might be a good idea to have the percent compiled for included programs separate from the percent compiled for the main program (maybe not even include it at all?)  Perhaps directly to the right of the main percent, there could be a second percent when parsing included programs?  Just a suggestion :)

That's actually impossible because Axe doesn't know how large a program is when you have included programs.  It only knows the number of bytes read from the source as a percent of the total number of bytes.  There is no way I'd be able to calculate the expanded size unless I made a 3rd pass to do nothing but sum up the size of all the source programs recursively.  Alternatively, I could do that in the first pass so that the percent would be accurate during the 2nd pass, but most errors are caught in the first.

What I probably will end up doing is adding the name of the current program being parsed to the progress so the percent means something; the progress within the current file.
Title: Re: Features Wishlist
Post by: Builderboy on October 23, 2011, 05:05:30 am
Since you know the size of the base program, you should be able to calculate the percent complete of the base program right?  That is all I am asking, have the percent of base program size completed.  (Also, since you are only able to nest included programs 1 deep, it wouldn't need to be recursive :P) but yeah, percent compiled of the main program I think would be more helpful.
Title: Re: Features Wishlist
Post by: Happybobjr on October 23, 2011, 09:20:20 am
 how about making an option to display the final size of the program after compilation?
It would require a keypress at the end if the option is on, but it would be much faster than scrolling through all your programs in the memory menu.
Title: Re: Features Wishlist
Post by: Hayleia on October 23, 2011, 12:39:08 pm
how about making an option to display the final size of the program after compilation?
It would require a keypress at the end if the option is on, but it would be much faster than scrolling through all your programs in the memory menu.
Good idea, and I think it is doable as it is done for Apps :)
As long as it is an option that can be disabled, because I often do little useless programs.
Title: Re: Features Wishlist
Post by: Runer112 on October 26, 2011, 01:24:49 pm
Two feature requests:

Title: Re: Features Wishlist
Post by: jacobly on October 26, 2011, 02:43:00 pm
  • The ability to include token strings as data. I thought about a possible syntax for this, and I came up with ["String goes here"]. Perhaps there's a better syntax, but that's just what I came up with.
I was going to make the same exact request, with the same suggestion for syntax. O.O
Ninja'd before I even made the post.
Title: Re: Features Wishlist
Post by: Runer112 on October 26, 2011, 02:51:14 pm
Yeah, I saw your FP math Axiom and I figured that being able to enter token strings would make it about 100x simpler. People could then just enter standard homescreen/TI-BASIC code which could be executed simply with a bit of setup and calling the OS to handle parsing it from there.
Title: Re: Features Wishlist
Post by: Quigibo on October 26, 2011, 07:31:35 pm
Both good ideas.  I was planning to add a token string eventually, but I forgot about it since nobody was really using tokens.
Title: Re: Features Wishlist
Post by: Keoni29 on October 26, 2011, 07:35:49 pm
I am experimenting with video signal generation. It would be nice if there was support XD
Title: Re: Features Wishlist
Post by: Builderboy on October 26, 2011, 07:43:57 pm
Support for video signal generation? o.O I think this is not really something many games would use, and would be much better suited for an Axiom.  What kind of video signal are you even working with?
Title: Re: Features Wishlist
Post by: C0deH4cker on October 27, 2011, 10:50:46 pm
Or 'Token string here'
Title: Re: Features Wishlist
Post by: Freyaday on October 28, 2011, 12:22:31 am
This is an idea that was kicked around on IRC which I cannot take credit for, but felt needed mentioning before it was forgotten [/disclaimer]:
Autostore.
The idea is an extension onto the concept of ++ and --. Basically, you would type in, say, A+=2, and A would increase by 2. Type in A*=2, and it doubles. A-=3 will decrease A by 3, and so on and so forth.
(this is just one possible syntax, but it seemed to have the most support in the discussion)
Title: Re: Features Wishlist
Post by: MGOS on October 28, 2011, 12:24:48 am
Yeah, that would make things a lot easier - same syntax like C++.
Title: Re: Features Wishlist
Post by: Keoni29 on October 30, 2011, 08:50:40 am
Freq(WAVE,OFFSET,TIME
The starting position of the wave.
Normal wave produced by freq:
______         _______
      |       |       |
      |       |       |
      |_______|       |______ etc.

Wave starting at 1/4 wave
__         _______        ___ etc.
  |       |       |      |
  |       |       |      |
  |_______|       |______|

Say the wave is 200 then the wave starts at 50



Value must be within the domain[0,WAVE]

Makes sound blending easier and sound better!
Title: Re: Features Wishlist
Post by: mushmoom on November 02, 2011, 07:08:04 pm
I think Axe needs trig functions because if I had to say: calculate and simulate the trajectory of an object, it would take a lot more memory to program each function and its values.
Title: Re: Features Wishlist
Post by: Happybobjr on November 02, 2011, 07:22:33 pm
It does have sin( and cos(

unfortunately, it would be extremely inefficient to do any other ones.
Title: Re: Features Wishlist
Post by: Builderboy on November 02, 2011, 07:46:29 pm
I think Axe needs trig functions because if I had to say: calculate and simulate the trajectory of an object, it would take a lot more memory to program each function and its values.

You don't need much Trig at all to compute the trajectory of an object, and Axe already has Sin and Cos, which should be more than enough :)
Title: Re: Features Wishlist
Post by: Keoni29 on November 03, 2011, 10:14:49 am
But sin(x) has only 3 possible values: -1, 0 and 1
(or does axe use another method?)
Title: Re: Features Wishlist
Post by: MGOS on November 03, 2011, 10:52:26 am
sin(x) returns a value between -127 and 127, where x is between 0 and 255. So if you want to get the sine of 90°, you type sin(64) and get 127.
It's the same with the cosine function.
If you want to plot the points on a circle with radius 10, you think of a number you have to divide 127 to get 10, which is about 13.
You also have to add the Center coordinates.
Code: [Select]
For(I,0,255)
sin(I)//13+20->Y
cos(I)//13+20->X
Pxl-On(X,Y)
End
Title: Re: Features Wishlist
Post by: Keoni29 on November 03, 2011, 10:55:46 am
But sin(x) is very slow right? Does it use a LUT or an approximation algorithm? When you only need like 16 directions is it better to use a LUT?
Title: Re: Features Wishlist
Post by: MGOS on November 03, 2011, 11:01:09 am
I don't know which kind of routine is used. I once programmed a piston engine-simulation with sin and cos and that was pretty fast.

And if you do always the same calculation with the sin/cos values, I think it is better to use a LUT for only these 16 values.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 03, 2011, 03:46:24 pm
Not sure what algorithm it is, but it's definitely an algorithm (not a lookup table, which would be huge for 256 possible input values). If you don't need it to be too exact, a lookup table would probably be faster.
Title: Re: Features Wishlist
Post by: Quigibo on November 03, 2011, 05:05:24 pm
The sin and cos routines are very fast, about the speed of doing one multiplication (because that's essentially what it does).  It uses the fact that sin(x) when x is in the range [0 to 180 degrees] has a hump that is approximately a parabola.  For the domain and range that I'm using in Axe, sin(x) is approximately: x*(128 - x)/32.  This is then just replicated with alternating sign periodically.

A look-up table is always faster, they are even faster than regular multiplication.  If you have 16 values, then done right it could be slightly faster and about the same size to use a look-up table, but you have to be good at Axe optimization to achieve this.  However, unless you are computing sin and cos more than 1000 times per second, I wouldn't even bother because it won't make a difference.
Title: Re: Features Wishlist
Post by: mushmoom on November 03, 2011, 06:04:16 pm
Thanks
Title: Re: Features Wishlist
Post by: epic7 on November 03, 2011, 08:48:01 pm
It would be cool to have something that was like a mix of ti-basic Input, and Text(


Also, has something like this ever been created for axe?
As I suggested via yahoo a week ago, something like:

Text(Method,Y,X,string

For method:

-1=big fonts
0=small fonts
1=big inverted fonts
2=small inverted fonts
Title: Re: Features Wishlist
Post by: C0deH4cker on November 03, 2011, 09:38:53 pm
You can use the Fix # commands.
Title: Re: Features Wishlist
Post by: parserp on November 03, 2011, 09:50:13 pm
There should be an easy way to input strings
Title: Re: Features Wishlist
Post by: Deep Toaster on November 03, 2011, 11:29:03 pm
Virtually all input routines are done by coders themselves, unless everyone agreed to have identical input routines that did exactly the same things. The only reason the input command exists is because there's a routine provided by the OS to do it, and even then it can be glitchy (such as when you do 2nd+[QUIT]).
Title: Re: Features Wishlist
Post by: Keoni29 on November 04, 2011, 04:00:40 am
Hero core is gonna be quite a heavy game. There are a lot of bullets. (around 10 enemie bullets on the screen and 6 player bullets) Then you have the enemies' movement and some bosses use "ropes" for their neck or tail. A lot of sines need to be calculated :P

Freq(WAVE,OFFSET,TIME
The starting position of the wave.
Normal wave produced by freq:
______         _______
      |       |       |
      |       |       |
      |_______|       |______ etc.

Wave starting at 1/4 wave
__         _______        ___ etc.
  |       |       |      |
  |       |       |      |
  |_______|       |______|

Say the wave is 200 then the wave starts at 50



Value must be within the domain[0,WAVE]

Makes sound blending easier and sound better!
Would this even be possible? Is it easy to implement this in the existing freq( routine?
Title: Re: Features Wishlist
Post by: MGOS on November 04, 2011, 11:23:47 am
I know this is quite difficult, but how about the text and the circle commands for the back-buffer and arbitary buffers?
Title: Re: Features Wishlist
Post by: epic7 on November 04, 2011, 05:31:39 pm
What are the arbitary buffers?
Title: Re: Features Wishlist
Post by: Keoni29 on November 04, 2011, 05:33:08 pm
What are the arbitary buffers?
Custom buffers defined by the programmer
Title: Re: Features Wishlist
Post by: MGOS on November 05, 2011, 04:37:48 am
And this also might be something useful: Auto-Backup not only for the main program, but also for all the other included not-archived sub programs.
Title: Re: Features Wishlist
Post by: aeTIos on November 05, 2011, 09:56:19 am
are bit commands planned? if not I want to request. (since that will give a HUGE size optimization)
Title: Re: Features Wishlist
Post by: Keoni29 on November 05, 2011, 12:19:12 pm
are bit commands planned? if not I want to request. (since that will give a HUGE size optimization)
Such as shifting? I use this code I got from qwerty:
Code: [Select]
Lbl SHIFT
2->r2
If r2
While
r2
Asm(CB15CB14
->r2
End
Else
2->r2
End
For 2 to the power of r1. r2 is return value


But things like binairy tilemaps would come in handy :P
Title: Re: Features Wishlist
Post by: aeTIos on November 05, 2011, 12:20:58 pm
yup. but I'm fine with an axiom too.
Title: Re: Features Wishlist
Post by: Keoni29 on November 05, 2011, 12:50:00 pm
Now I have to do this to convert dec to binairy:
For(r2,0,15
r1^2->{L1+r2}
r1/2->r1
End
But since the memory is already in binairy this shouldn't be neccesary. As well as half nibs (4 times 0-3 instead of 2 times 0-F)
Title: Re: Features Wishlist
Post by: Builderboy on November 05, 2011, 01:48:47 pm
are bit commands planned? if not I want to request. (since that will give a HUGE size optimization)

Wait did you mean bit shifting or setting/resetting/accessing individual bits?  Because shifting can be accomplished by simply multiplying or dividing by 2, and setting/resetting/accessing individual bits has already been implemented.
Title: Re: Features Wishlist
Post by: aeTIos on November 05, 2011, 03:08:41 pm
What are the commands for the bit set/reset/accessing indiviual bits?
also you have 444 respect
Title: Re: Features Wishlist
Post by: Keoni29 on November 05, 2011, 03:15:44 pm
are bit commands planned? if not I want to request. (since that will give a HUGE size optimization)

Wait did you mean bit shifting or setting/resetting/accessing individual bits?  Because shifting can be accomplished by simply multiplying or dividing by 2, and setting/resetting/accessing individual bits has already been implemented.
Since which version?
Title: Re: Features Wishlist
Post by: Hayleia on November 05, 2011, 03:29:50 pm
But to set a bit (let's say the first one for example), don't we just need to or with 10000000 ?
And the same to reset but with xor ?
Title: Re: Features Wishlist
Post by: aeTIos on November 05, 2011, 03:31:16 pm
:o that could indeed be true
and to get a bit and with the wanted one
thx!!
Title: Re: Features Wishlist
Post by: Builderboy on November 05, 2011, 03:53:38 pm
But to set a bit (let's say the first one for example), don't we just need to or with 10000000 ?
And the same to reset but with xor ?

You would use AND to reset bits, XOR is used to toggle a bit
Title: Re: Features Wishlist
Post by: Hayleia on November 05, 2011, 03:55:49 pm
But to set a bit (let's say the first one for example), don't we just need to or with 10000000 ?
And the same to reset but with xor ?

You would use AND to reset bits, XOR is used to toggle a bit
D: epic fail
I posted without thinking a lot but I knew something like that could work ;D

EDIT: I gave you a +1, you no longer have +444 D: Should I remove it ?
Title: Re: Features Wishlist
Post by: Builderboy on November 05, 2011, 04:04:02 pm
Do what you please, it's your own respect you are giving :)
Title: Re: Features Wishlist
Post by: Quigibo on November 05, 2011, 07:35:09 pm
Don't forget the 'e' operator.  It accesses the Nth bit of a number.  Its been around for a long time now...
Title: Re: Features Wishlist
Post by: Keoni29 on November 06, 2011, 04:15:37 am
Don't forget the 'e' operator.  It accesses the Nth bit of a number.  Its been around for a long time now...
Syntax?
Title: Re: Features Wishlist
Post by: Builderboy on November 06, 2011, 04:21:07 am
Don't forget the 'e' operator.  It accesses the Nth bit of a number.  Its been around for a long time now...
Syntax?

It's all in the commands index :) You should check it out, it has all the Axe commands ever, you may find some you never new existed ^^.  AeB accesses the Bth bit of A
Title: Re: Features Wishlist
Post by: Keoni29 on November 06, 2011, 04:25:51 am
Found it. But all variables are 16 bits :( When I have this number:
10101011 00010110
Does AeB return the B-th bit from the 1st or the 2nd nibble from the left?
Title: Re: Features Wishlist
Post by: Builderboy on November 06, 2011, 04:31:48 am
It would use the low byte (which i don't remember which one it is, you should test it out)
Title: Re: Features Wishlist
Post by: Keoni29 on November 06, 2011, 09:08:32 am
I checked the command list. Ae0 gives the highest bit of an 8-bit number. In axe when saving 16bit numbers in an array you have to define the low byte first. So that means that axe uses the low byte first. When a command needs an 8bit number it will simply take the low byte of the variable. Is this theory correct?
Title: Re: Features Wishlist
Post by: Quigibo on November 06, 2011, 02:21:48 pm
Yes.  If you're using 'e' it will ignore the high byte of a 16-bit variable.  However, if you use 'ee' you can pick from the entire 16 bits.
Title: Re: Features Wishlist
Post by: LincolnB on November 06, 2011, 08:31:56 pm
can you set bits with the e operator? Like, can you say, 1->Ae4
Title: Re: Features Wishlist
Post by: Deep Toaster on November 06, 2011, 08:33:51 pm
Nope, use bitmasking (and, or, xor) for that.
Title: Re: Features Wishlist
Post by: Freyaday on November 11, 2011, 11:51:25 pm
White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.
Title: Re: Features Wishlist
Post by: Keoni29 on November 12, 2011, 04:23:30 am
White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.
Use drawinv ... drawinv for that
Title: Re: Features Wishlist
Post by: Hayleia on November 12, 2011, 06:50:21 am
White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.
Use drawinv ... drawinv for that
This will not work for inverted lines, only for white objects ;)
But for a white rectangle, you also can do Rect(...) RectI(...)
Title: Re: Features Wishlist
Post by: Freyaday on November 12, 2011, 10:28:13 am
Those are both much slower than a RectW() would be.
Title: Re: Features Wishlist
Post by: Happybobjr on November 12, 2011, 12:09:18 pm
*     Request:  Rectangles that accept negative values in a reasonable manner :P

For so that the initial point could be the bottom left pixel
Title: Re: Features Wishlist
Post by: LincolnB on November 12, 2011, 04:30:13 pm
the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1
Title: Re: Features Wishlist
Post by: parserp on November 12, 2011, 05:41:20 pm
Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1
ooh that would be an AWESOME thing to have... :D
Title: Re: Features Wishlist
Post by: C0deH4cker on November 12, 2011, 10:36:42 pm
Well, appvars cant be easily edited oncalc, so maybe we could do [prgmNAME]->GDB1.
In this case, the program should not be parsed as axe code. Another possibility is string vars.
[Str1]->Str1
Title: Re: Features Wishlist
Post by: Deep Toaster on November 13, 2011, 11:33:32 am
I don't like the idea of importing programs because program variables generally store, well, program code, and you can import them with the prgm command. As for strings, I think that makes sense, but unfortunately strings in the TI-OS are token strings (http://tibasicdev.wikidot.com/one-byte-tokens), while Axe and ASM strings are character strings (http://tibasicdev.wikidot.com/83lgfont), which are different except for the uppercase letters, digits, and theta.
Title: Re: Features Wishlist
Post by: shmibs on November 13, 2011, 12:11:40 pm
the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

what, exactly, would be the point of that? appvars are supposed to be variables, which can be modified during runtime and used to store data, but that takes effect only during compilation.
Title: Re: Features Wishlist
Post by: Quigibo on November 13, 2011, 07:14:02 pm
I thought I already added this... oh well, I'll add it soon then.  One use of this is computer generated data (For instance music, large pictures, levels, and more).  Those can export to an appvar format and then you don't need to have tons of extra space taken up in your source code in hex form.
Title: Re: Features Wishlist
Post by: parserp on November 13, 2011, 07:18:10 pm
the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

what, exactly, would be the point of that? appvars are supposed to be variables, which can be modified during runtime and used to store data, but that takes effect only during compilation.
he means for levels and stuff that you don't change, they are just there for the picture, therefore all you would need is the executable and not all of the appvars
Title: Re: Features Wishlist
Post by: ztrumpet on November 13, 2011, 07:26:23 pm
I'd love to be able to include AppVars in the source.  That was one of the issues that plagued me in trying to put out the Cube Droid demo fast enough for the contest.
Title: Re: Features Wishlist
Post by: Freyaday on November 14, 2011, 12:12:33 pm
Perhaps the absorbing syntax could be just having appvAPPVAR->constant on a line, similar to how it is with programs.
Title: Re: Features Wishlist
Post by: Yeong on November 14, 2011, 01:12:36 pm
I'm just curious, but does axe already have a function to absorb TI-OS Strings?
Title: Re: Features Wishlist
Post by: Freyaday on November 14, 2011, 05:44:28 pm
I'm just curious, but does axe already have a function to absorb TI-OS Strings?
No.
Title: Re: Features Wishlist
Post by: parserp on November 16, 2011, 05:59:32 pm
as butts noted in the help axe optimize thread, there should be an option for upside down text!!! :D
Title: Re: Features Wishlist
Post by: Builderboy on November 16, 2011, 06:07:44 pm
Upside down text doesn't sound like anything programs would be using most of the time, and therefore a much better candidate for an Axiom.

As an aside, I've been seeing a fair amount of feature requests popping up recently that would be perfect candidates for Axioms.  This is the entire reason Axioms were created in the first place, so Axe wouldn't become a language filled to the brim with dozens of highly specific functions, and also to help ease the burden of coding off of Quigibo.  New feature requests should be restricted to changes to the compiler/syntax that would be impossible to achieve via Axiom, such as Conditional Goto's, or Switch statements.
Title: Re: Features Wishlist
Post by: Yeong on November 16, 2011, 09:10:58 pm
I think there should be an option to turn off peephole optimization.
Title: Re: Features Wishlist
Post by: Builderboy on November 16, 2011, 09:16:14 pm
There is, just press Zoom instead of Enter when you compile
Title: Re: Features Wishlist
Post by: calcdude84se on November 16, 2011, 09:16:42 pm
Press the ZOOM key instead of whatever key you normally press to compile (2nd or Enter) ;)
Edit: ninja'd
Title: Re: Features Wishlist
Post by: Yeong on November 16, 2011, 09:17:51 pm
I meant as a "Permanent off"
Title: Re: Features Wishlist
Post by: calcdude84se on November 16, 2011, 09:22:14 pm
It's not really necessary as you can just press ZOOM every time. It's the same number of keypresses as compiling with the peephole optimizations, and wouldn't require you to fiddle with options.
Title: Re: Features Wishlist
Post by: Yeong on November 16, 2011, 09:30:35 pm
ah. I just had a time when I pressed zoom, it didn't work. D:
Maybe I pressed it at the wrong time or something.
Title: Re: Features Wishlist
Post by: Camdenmil on November 16, 2011, 10:30:58 pm
Don't know if these have been suggested in the last 180 pages, but white lines and/or invert lines. Also, use memory locations in for loops, currently it says invalid token when I try to use a memory location.
Title: Re: Features Wishlist
Post by: Deep Toaster on November 16, 2011, 10:48:51 pm
ah. I just had a time when I pressed zoom, it didn't work. D:
Maybe I pressed it at the wrong time or something.
Or maybe you have a version without ZOOM?
Title: Re: Features Wishlist
Post by: Xeda112358 on November 17, 2011, 12:38:00 pm
I don't like the idea of importing programs because program variables generally store, well, program code, and you can import them with the prgm command. As for strings, I think that makes sense, but unfortunately strings in the TI-OS are token strings (http://tibasicdev.wikidot.com/one-byte-tokens), while Axe and ASM strings are character strings (http://tibasicdev.wikidot.com/83lgfont), which are different except for the uppercase letters, digits, and theta.
Code can easily be created to turn an OS string into a character string. I do that in a few of my projects and I am wondering if Quigibo already has code in Axe to do that (can appvars with lowercase names be created?)...

EDIT:... or accessed?
Title: Re: Features Wishlist
Post by: Yeong on November 17, 2011, 01:14:26 pm
Feature request:enable to type tokens instead of finding them in menu.
Title: Re: Features Wishlist
Post by: aeTIos on November 17, 2011, 01:15:21 pm
Most likely not added since they would most likely interfere with routines. Also would need a huge stack x.x
Title: Re: Features Wishlist
Post by: Yeong on November 17, 2011, 01:16:29 pm
D:
It was too much, I guess XP
well, then... feature request: port it to TI-86
Title: Re: Features Wishlist
Post by: aeTIos on November 17, 2011, 01:18:59 pm
Lol @ the port to 86 :P
I might create axe for writing computer programs (parsed, but faster :P)
Also, I will add colors then. Will post a topic about it when starting the project.
Title: Re: Features Wishlist
Post by: Freyaday on November 20, 2011, 06:42:55 pm
Lol @ the port to 86 :P
I might create axe for writing computer programs (parsed, but faster :P)
Also, I will add colors then. Will post a topic about it when starting the project.
YES PLEASE!
Title: Re: Features Wishlist
Post by: mrmprog on November 20, 2011, 07:47:08 pm
Lol @ the port to 86 :P
I might create axe for writing computer programs (parsed, but faster :P)
Also, I will add colors then. Will post a topic about it when starting the project.
YES PLEASE!
That would be pretty cool. Would it be based towards making simple comp games?
Title: Re: Features Wishlist
Post by: epic7 on November 20, 2011, 09:39:57 pm
Axe for computer?
...
GENIUS
MAKE IT
PLEASE
Title: Re: Features Wishlist
Post by: TIfanx1999 on November 21, 2011, 08:13:09 am
D:
It was too much, I guess XP
well, then... feature request: port it to TI-86
Actually, that would be pretty cool. ;) Not really a feature request so much as an independent project though. :P
Title: Re: Features Wishlist
Post by: Darl181 on November 23, 2011, 11:59:37 am
Would it be possible to do something like #RealLoc() for the buffer? (meaning, instead of always defaulting to L6 you could have it default to, say, a 768-byte appvar)
Title: Re: Features Wishlist
Post by: parserp on November 23, 2011, 12:02:41 pm
Would it be possible to do something like #RealLoc() for the buffer? (meaning, instead of always defaulting to L6 you could have it default to, say, a 768-byte appvar)
:D that would be awesome!!!!
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2011, 01:24:52 pm
Would it be possible to do something like #RealLoc() for the buffer? (meaning, instead of always defaulting to L6 you could have it default to, say, a 768-byte appvar)

We have DispGraph(Buffer) so there really wouldn't be much point of being able to modify the DispGraph command. 
Title: Re: Features Wishlist
Post by: Darl181 on November 23, 2011, 01:51:57 pm
Sorry--I'm not talking about DispGraph, I'm talking about things like Pt-On(), Rect() and the like.
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2011, 01:52:25 pm
You can use those with arbitrary buffers as well
Title: Re: Features Wishlist
Post by: Darl181 on November 23, 2011, 01:54:10 pm
Yes, but if you have something like 20 lines in a row where you're modifying a tertiary buffer, it gets kind of tiring typing in the fourth argument 20 times (esp. if there's lowercase letters) :/
Title: Re: Features Wishlist
Post by: Builderboy on November 23, 2011, 01:55:12 pm
You could always store it to a seperate var to save typing time, but I see what you mean
Title: Re: Features Wishlist
Post by: Quigibo on November 23, 2011, 03:26:59 pm
The drawing commands are hardwired to the main buffer for extra efficiency and size optimization.  You should plan out your buffers so that the one that requires the most drawing to is the main buffer (which is not always the black layer).  Then use the appropriate DispGraph command to display it.
Title: Re: Features Wishlist
Post by: aeTIos on November 23, 2011, 03:28:24 pm
Huh? Can you relocate/change the main buffer then?
Title: Re: Features Wishlist
Post by: Quigibo on November 23, 2011, 03:58:25 pm
No, that's why L6 should be the one you do the most drawing to.
Title: Re: Features Wishlist
Post by: aeTIos on November 23, 2011, 05:18:56 pm
I see :P
Title: Re: Features Wishlist
Post by: Darl181 on November 24, 2011, 11:24:05 am
Hm, well I guess worst-case scenario one could Exch() tho that would add to the size..
Title: Re: Features Wishlist
Post by: dunrite321 on November 26, 2011, 02:16:22 pm
I don't know if anybody's posted this before, but since I don't have time to read through 185 pages of this thread, could you make black text a single command on 4-level grayscale?
Title: Re: Features Wishlist
Post by: Darl181 on November 26, 2011, 02:54:47 pm
That sounds like a good idea...Text(...)rr maybe?
Title: Re: Features Wishlist
Post by: Runer112 on November 26, 2011, 06:06:48 pm
Drawing text to the back buffer has been asked for multiple times, and has been rejected multiple times. Although it's a great idea, Axe uses the OS text drawing routine, which is only capable of drawing text either directly to the screen or to the front buffer.
Title: Re: Features Wishlist
Post by: Freyaday on November 26, 2011, 09:58:47 pm
Perhaps text()rr could print to L6 and then copy the printed portion to L3
Title: Re: Features Wishlist
Post by: Freyaday on November 27, 2011, 05:36:43 pm
8.8 sin() and cos()
Title: Re: Features Wishlist
Post by: Quigibo on November 27, 2011, 11:32:50 pm
Multiply by 2 and it's 8.8 :P
Title: Re: Features Wishlist
Post by: Freyaday on November 28, 2011, 12:16:14 am
Multiply by 2 and it's 8.8 :P
Multiply what by two?
Title: Re: Features Wishlist
Post by: Deep Toaster on November 28, 2011, 10:40:23 am
Perhaps text()rr could print to L6 and then copy the printed portion to L3
That would destroy part of L6, and it would be pretty much the same thing to do it in Axe code. I personally think an Axe subroutine would actually be better for that job since you know how long the text is (but a native Axe routine wouldn't).
Multiply by 2 and it's 8.8 :P
Multiply what by two?
The output of sin and cos are numbers between -128 and 127. Multiply that by two (it takes just one byte to do that) and they're between -256 to 254, which is just -1 to (almost) 1 in 8.8 fixed point.

EDIT: Was there ever even a Text()r command? ???
Title: Re: Features Wishlist
Post by: thepenguin77 on December 02, 2011, 08:44:47 pm
Ztrumpet brought up the point that it would be useful if instead of refusing to jump to an archived program's error, it uses zStart to bring up the editor instead.

The offset to jump to when the error occurs is stored at an OS address correct? If that is the case, then I can add an api entry point to edit a program and you can call it if the error occurred in the archive. Since I end up opening a program editor anyways, the goto function should work like normal.

If you want to do this, I'll also have to know how you are opening the program editor. (I've never looked very far into it)

Edit:
   That was easy
Title: Re: Features Wishlist
Post by: Quigibo on December 02, 2011, 10:17:10 pm
I'd love to add that but my own error scrolling isn't working yet and I feel I should at least fix that before adding a zstart entry call.  Maybe you can help me, I don't know what I'm doing wrong because I'm still not exactly sure how the OS handles edit buffers entirely.  It appears to work when instant-scrolling in small programs, but it RAM clears sometimes when scrolling to a spot greater than 8kb into the code.  Its somewhat random and not completely consistent.  How did you do it in zstart?  Do you see anything wrong?  This is the code I'm using:

Spoiler For Spoiler:

EditorExit:
   ld   a,(v_PrgmStartPage)
   or   a
   jp   nz,SystemExit
   ld   hl,v_InputName+1
   ld   de,progToEdit
   ld   bc,8
   ldir
   xor   a
   ld   (de),a
   ld   a,kPrgmEd
   B_CALL(_NewContext)
   ld   hl,(v_PrgmPtr)
   ld   bc,(v_PrgmStart)
   or   a
   sbc   hl,bc
   ld   b,h
   ld   c,l
   ld   hl,(editTail)
   add   hl,bc
   ld   (editTail),hl
   ld   hl,(editTop)
   add   hl,bc
   ld   (editCursor),hl
   ld   hl,0
   push   hl
EditorLoop:            ;Check if at beginning of program
   ld   de,(editTop)
   or   a
   sbc   hl,de
   jr   z,EditorFound
   B_CALL(_BufLeft)
   ld   hl,(editCursor)
   ld   a,(hl)
   cp   tEnter
   jr   z,EditorFound
   pop   hl
   inc   hl
   push   hl
   jr   EditorLoop
EditorFound:
   B_CALL(_BufRight)
   B_CALL(_DispEOW)
   pop   hl
   ld   a,h
   or   l
   jr   z,EditorMon
EditorScroll:
   dec   hl
   ld   a,h
   or   l
   jr   z,EditorMon
   push   hl
   B_CALL(_CursorRight)
   pop   hl
   jr   EditorScroll
EditorMon:
   res   2,(iy+50)
   res   7,(iy+20)
   res   3,(iy+5)
   B_JUMP(_Mon)
Title: Re: Features Wishlist
Post by: thepenguin77 on December 03, 2011, 03:38:34 pm
A little disassembling and this is what I came up with:

Code: [Select]
ld hl, offsetToError
ld (errOffset), hl

ld hl, op1
ld de, progCurrent-1
ld bc, 9
ldir
ld a, 3
ld (menuCurrent), a
ld a, 1
ld ($85DF), a
ld a, kEnter
bcall(_pullDownChk)
bcall(_clrTR)
bcall(_newContext0)
bcall(_gotoErr)
bcall(_mon)

This method essentially fakes a person going into the program menu and editing a program. You can leave out the bcall(_gotoError) if you aren't going to initialize (errOffset), but then it won't scroll.

I believe this will work from an app, but I've only tested it from a keyhook so far.
Title: Re: Features Wishlist
Post by: C0deH4cker on December 03, 2011, 04:04:06 pm
how does doors cs 7.1 do it? That works very well and jumps instantly to the error.
Title: Re: Features Wishlist
Post by: Darl181 on December 03, 2011, 04:59:25 pm
how does doors cs 7.1 do it? That works very well and jumps instantly to the error.

In the axe docs (the pdf):
Quote from: credits
<IRL name> (Kerm Martian) Thanks for the help with the error scrolling!
One would guess it's likely the same thing in DCS.  If that's buggy then yeah :P
(unless the scrolling in DCS was updated..I remember back when 7 first came out and when I tried it it would crash periodically)
Title: Re: Features Wishlist
Post by: thepenguin77 on December 03, 2011, 10:49:25 pm
Ok, a slight change to my code:

Code: [Select]
ld hl, offsetToError
ld (errOffset), hl

ld a, 3
ld (menuCurrent), a
ld a, 1
ld ($85DF), a
ld a, kEnter
bcall(_pullDownChk)
bcall(_clrTR)

ld hl, op1
ld de, progToEdit-1
ld bc, 9
ldir

ld b, a
ld a, kError
ld (cxCurApp), a
ld a, b
bcall(_newContext0)
bcall(_mon)

The previous one didn't quite do the Goto properly, so this version starts off acting like the edit menu, then switches gears and says it's the error menu doing a goto. In any case, (errOffset) is how far it will jump.
Title: Re: Features Wishlist
Post by: hellninjas on December 04, 2011, 02:36:38 am
I would like the RandInt( command to be added and worked just like Ti-BASIC... :P
Title: Re: Features Wishlist
Post by: C0deH4cker on December 04, 2011, 04:21:23 am
You can already do this with this code:

rand^MAX


That makes a random # between 0 and MAX-1.
Title: Re: Features Wishlist
Post by: thepenguin77 on December 04, 2011, 04:00:23 pm
In any case, 8090h in zStart will edit OP1.

Set (errOffset) to the correct offset (or 0), check to make sure 8090h is $C3 in zStart, then jump there. Simple as that.
Title: Re: Features Wishlist
Post by: Runer112 on December 07, 2011, 01:58:50 pm
I'm going to bump a feature request I've probably mentioned multiple times in the past: preprocessor conditionals. It is something that cannot be done in an Axiom and would be useful to every programmer, whether it's for building your program in a debug mode, testing different blocks of code to see which is better/faster/smaller, or (my personal favorite) making Axe libraries that programmers can very easily customize to their needs by changing a few defines. I'm sorry about bringing up this particular request multiple times, but this is the #1 feature I would like to see in Axe, and I'm sure many others would find it useful as well.
Title: Re: Features Wishlist
Post by: Quigibo on December 07, 2011, 05:58:31 pm
I'll see what I can do about that... I just have to write a mini block parser to make sure everything gets skipped correctly.
Title: Re: Features Wishlist
Post by: calcdude84se on December 07, 2011, 07:07:19 pm
Continuing in that vein, I'd like to bump stack access. Both of the suggestions I've seen (using π as a pseudo-variable to access the stack and having a command Save(VAL1,VAL2) that evals and pushes VAL1, evals VAL2, then pops the stored value of VAL1) sound good.
Title: Re: Features Wishlist
Post by: epic7 on December 07, 2011, 07:08:29 pm
I'm going to bump a feature request I've probably mentioned multiple times in the past: preprocessor conditionals. It is something that cannot be done in an Axiom and would be useful to every programmer, whether it's for building your program in a debug mode, testing different blocks of code to see which is better/faster/smaller, or (my personal favorite) making Axe libraries that programmers can very easily customize to their needs by changing a few defines. I'm sorry about bringing up this particular request multiple times, but this is the #1 feature I would like to see in Axe, and I'm sure many others would find it useful as well.
What's that?
Title: Re: Features Wishlist
Post by: Builderboy on December 07, 2011, 07:20:51 pm
Continuing in that vein, I'd like to bump stack access. Both of the suggestions I've seen (using π as a pseudo-variable to access the stack and having a command Save(VAL1,VAL2) that evals and pushes VAL1, evals VAL2, then pops the stored value of VAL1) sound good.

I believe Quigibo is implementing the Save() command like you suggested
Title: Re: Features Wishlist
Post by: Quigibo on December 07, 2011, 09:25:49 pm
Yup, I already have that working :)  I'm using the Select() token btw so I won't have to make a new token for it.

Also, I decided the best syntax for preprocessor conditionals is to represent them as "conditional comment blocks".  This makes it easy for beginners to understand and easy for me to parse.  It looks like this:

Code: [Select]
:...If <const>
:<code>
:...

So it will only do the stuff in the comment block if the constant is true (non-zero) but otherwise it is treated as a comment.  I will hopefully also add the "!If" and "Else" comment conditionals.  "End" isn't needed because you can just end it like you normally end a block comment.  Also, this will not allow nesting, but I think that's probably okay.  You can technically nest one level deep using external source though.
Title: Re: Features Wishlist
Post by: epic7 on December 07, 2011, 09:29:22 pm
So if its true, it does it, if not, skip it?
Isn't that what a normal If does?
Title: Re: Features Wishlist
Post by: Runer112 on December 07, 2011, 09:30:09 pm
Just throwing this out there, I had a very simple idea for a possible syntax for preprocessor conditionals. Pretty much, there would be no new syntax. It would just boil down to whether or not the condition of an If statement is a constant. And it can't get any simpler for beginners to understand than that.
Title: Re: Features Wishlist
Post by: Quigibo on December 07, 2011, 09:47:18 pm
That's exactly what I wanted to do and I tried that originally, but it was extremely difficult because then I can't just search for an "End" like I could with comments.  But even so, suppose I could count the number of statements that require an end minus the number of ends and only quit when that count is zero.  Unfortunately, this also involves me parsing single line comments, character constants, and quotes all of which can contain those tokens I'm searching for.  I'd basically have to parse the whole thing as though it were normal code, except without writing anything.  But if I do this, I have to add special code in lots of places to ignore non-executable writing things like data, not erroring on undefined constants, defining new constants, etc.  So in either case, it complicates things immensely and I'm bound to get something wrong with all these special cases.

EDIT: @epic7
Sort of, except that when the thing you're checking is constant (doesn't change the entire time in the program) you can remove the entire code block completely rather than just skipping over it.  Now why would you want to do something like "If 1" knowing its always true?  Its because if you have different versions of your game, or different parts of a library to use, you switch from including them to not including them by changing a single number instead of having to remove/reinclude code.
Title: Re: Features Wishlist
Post by: LincolnB on December 07, 2011, 11:20:50 pm
Okay, I've mentioned this before, and I'm not sure if it's in 1.0.5 cause I'm still using 1.0.3, but I would really like to say support for appvar absorption, where the source needs the appvar, but the executable doesn't. So, like when you absorb a Pic from TI-OS into an axe program, you go [Pic1]->POINTER, I'd like to see something like [appvANAPPVAR]->POINTER. Does that make sense?
Title: Re: Features Wishlist
Post by: parserp on December 07, 2011, 11:25:18 pm
Okay, I've mentioned this before, and I'm not sure if it's in 1.0.5 cause I'm still using 1.0.3, but I would really like to say support for appvar absorption, where the source needs the appvar, but the executable doesn't. So, like when you absorb a Pic from TI-OS into an axe program, you go [Pic1]->POINTER, I'd like to see something like [appvANAPPVAR]->POINTER. Does that make sense?
like, when compiling, it takes a copy of the appvar and puts it in the executable?
Title: Re: Features Wishlist
Post by: epic7 on December 07, 2011, 11:27:45 pm
Oh, I get it.
/me thinks of how he could use that...
Title: Re: Features Wishlist
Post by: LincolnB on December 09, 2011, 09:53:12 am
Yeah, Parser, it's the equivalent of going like this:

Data(1ST_BYTE_OF_APPV,2ND_BYTE_OF_APPV,3RD_BYTE_OF_APPV,etc)->GDB1
Title: Re: Features Wishlist
Post by: Happybobjr on December 10, 2011, 10:26:44 pm
Big request.  Hopefully easy.

Would there be any chance for an optimized #/A*A command?
That could be super useful to me, and should speed up many sprite routines.
Title: Re: Features Wishlist
Post by: Runer112 on December 10, 2011, 10:31:28 pm
This can already be done in the form #-(^A).
Title: Re: Features Wishlist
Post by: jacobly on December 10, 2011, 10:32:09 pm
#-(#^A)... optimized! ;D

Edit: Wow... ninja'd with a better response :(
Title: Re: Features Wishlist
Post by: calcdude84se on December 10, 2011, 10:33:22 pm
Jacob, the second occurrence of "#" is unneeded ;)
Title: Re: Features Wishlist
Post by: Happybobjr on December 10, 2011, 10:33:26 pm
i feel stupid :P
Title: Re: Features Wishlist
Post by: ztrumpet on December 10, 2011, 10:50:15 pm
Can SortD() be expanded like it in in TI Basic?  For instance, "SortD(Ptr1,Size,Ptr2)" would sort the data at Ptr1 and also sort the data at Ptr2 by the data in Ptr1.  If that doesn't make any sense, here's an example in Basic:

Code: [Select]
{3,2,4,1}->L1
{4,3,2,1}->L2
SortD(L1,L2)
Then L1 and L2 would equal:
Code: [Select]
L1 = {4,3,2,1}
L2 = {2,4,3,1}

I actually needed this in a program I wrote a while back and had to write it myself in Axe, which was actually really, really hard.

This could be expanded to sort up to four lists by each other or so.  I'm not sure what the upper bound here should be.
Title: Re: Features Wishlist
Post by: Quigibo on December 12, 2011, 03:25:35 am
I am going to suggest a very simple change to one of the least used commands to make it more useful.

Problem:
I suspect very few people are using *^ which returns the upper 16 bits of an unsigned multiplication.  The regular * just returns the lower 16 bits.  Actually, the * command computes both of these quantities at the same time but only returns one of them.  So if you have to get the upper and the lower bits of a multiplication, you end up calling the same multiplication twice!

Solution:
I propose that in addition to *^ returning the high bits, it also stores the low bits in another location, for instance r6.  Even more ideally, I feel like it should do the opposite:  return the low bits (identical to regular multiplication) store the high bits to r6.

Issues:
r6 seems like the best option, but no matter what location I pick it could lead to incompatibility.  If I make it return the low bits and store the high bits this will definitely lead to an incompatibility, but optimizes better and is more useful I think.


Consensus?  Especially if you use or ever have used this operation.
Title: Re: Features Wishlist
Post by: Builderboy on December 12, 2011, 03:44:47 am
I use that command for some of my more advanced physics, it can be quite useful ^^ This does pose an interesting conundrum though, and I feel the best solution would be to introduce some sort of optional syntax to choose a specific storage location.  Something like 8*^(r1)A->B.  Which would compute 8*^A, store the ordinary part into B, and store the extra part into r1.  It does look a bit messy, but it is a fairly advanced operation
Title: Re: Features Wishlist
Post by: Quigibo on December 12, 2011, 04:36:22 am
Alternatively, I could add access to Axe's temporary buffer through some new token and store it there.  The temporary buffer is an 8 byte buffer used in a few commands that create more data than can fit in an Axe variable such as Pt-Get() and RotC().  All commands so far that use this buffer also return it so it's location hasn't needed to be directly accessed yet.
Title: Re: Features Wishlist
Post by: jacobly on December 12, 2011, 09:17:16 pm
Here's an example of how I use it.
Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔r₁:r₂∗r₃➔r₂

So, my idea is to change the syntax to something like.
Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔(r₁,r₂) .Basically store high word (plus r₁∗r₃) to r₁, and the low word (not affected by the add) to r₂.
This has the added advantage that ➔( doesn't seem to mean anything in the current version (also, it causes an invalid token error). To compare with what Quigibo suggested, ➔(A,B) would be equivalent to ➔A(or B):<undecided token>➔B(or A), with the advantage of not using another token, and being more intuitive.

Code: [Select]
:r₁∗r₃+(r₂∗^r₃)➔r₁ .This would also work, storing just the high word (plus r₁∗r₃) to r₁, just like before.
:r₁∗r₃+(r₂∗^r₃)➔(r₁,) .maybe same as the last last line, but returns low the low word of the multiplication, rather than the value of r₁?

Spoiler For Implementation:
Use memory:
   Axe.inc:
      axv_Extra        =;MD5Temp, axv_SpriteBuff+6, axv_Y3t, OP1+0..64, whatever
      ; If you are wondering about the axv_SpriteBuff+6, I was thinking that it would be
      ; cool if there were an alternate ▸Dec that put the 5+1 byte string in axv_SpriteBuff.
      ; The leading zeros could even be removed this way (by the routine or in Axe).
      ; The routine/Axe code would just increment the pointer past the leading zeros...
      ; Anyway, my point is that even this wouldn't interfere with axv_SpriteBuff+6,
      ; only the sprite routines would affect it.
   Compiling:
      exp1∗^exp2 compiles to:
         ; load hl and de
         call sub_MulFull
         ld (axv_Extra),hl ; or better yet, put these in MulFull
         ld h,c ; especially if you take Runer's suggestion to break
         ld l,a ; Mul88's reliance on MulFull.
      ➔(var1,var2) compiles to:
         ld (°var1),hl ; only if var1 present?
         ld hl,(axv_Extra) ; always?
         ld (°var2),hl ; only if var2 present?
A cool thing I just noticed, is that both left to right parsing and the old functionality of sub_MulFull are preserved, and as far as I can tell, compatibility is 100% preserved (even with the few Asm( hacks I can think of!) 8)


Or a more optimized idea – use registers:
   Compiling:
      exp1∗^exp2 compiles to:
         call sub_MulFull
         ex de,hl ; or better yet, put these in MulFull
         ld h,c ; especially if you take Runer's suggestion to break
         ld l,a ; Mul88's reliance on MulFull.
      ➔(var1,var2) compiles to:
         ld (°var1),hl
         ld (°var2),de
But of course this is probably way too volatile to be user friendly. (although with peephole... :))
Oh, especially since my Axe code example above wouldn't work!

In the future, this syntax could definitely be useful for new commands that return more than one value.

Lol, I used Axe syntax in assembly :P

On an unrelated note, I just 2nd+Off on the Axe error screen, and now free mem = 0. Shouldn't B_CALL(_GetKeyRetOff) be used here? Unless zStart had something to do with it...
Title: Re: Features Wishlist
Post by: Builderboy on December 12, 2011, 09:28:38 pm
The problem with that is such lines of code like:

Code: [Select]
A*^B-5+9/42-{L1+B}->C
You can't override the -> operator because by the time the line reaches that point, it is difficult to tell exactly what should be done with the second number.
Title: Re: Features Wishlist
Post by: jacobly on December 12, 2011, 09:50:04 pm
The number is stored it a "safe" place until it is recalled ;)
It doesn't even have to ever be used.
Title: Re: Features Wishlist
Post by: Happybobjr on December 12, 2011, 09:51:46 pm
Big request.

When program is compiling.  Show the size it will be when finished.
And have a key, such as +, that when held down, will continue to show the compiling screen (with program size), until released.
Title: Re: Features Wishlist
Post by: Builderboy on December 12, 2011, 09:57:19 pm
The number is stored it a "safe" place until it is recalled ;)
It doesn't even have to ever be used.

Right, but if you did something as simple as

Code: [Select]
4^*B+2->(r1,r2)
Should it add 2 to both numbers before storing into r1 and r2?  Or should it only affect r1?
Title: Re: Features Wishlist
Post by: jacobly on December 12, 2011, 10:13:12 pm
4*^B returns the same thing it did before, the high word. The ➔(r₁,r₂) does almost the same thing as ➔r₁, except that in addition, the low word of the last *^ is stored to r₂.
However, feel free to make other suggestions. I'm still open to other ideas. :)
Title: Re: Features Wishlist
Post by: Quigibo on December 12, 2011, 10:28:03 pm
I still think just using another token would be easier... it is more flexible since you don't have to use it on the same line, easier to parse, and I personally think it is easier to use and understand since it is easy to confuse exactly what the syntax is supposed to do as Builderboy has already done.  Also, by using another token, I don't mean redefining an existing one, I mean just using one of the OS tokens with its original name.  I was thinking maybe "Seq" from the mode menu?

@Happybobjr
The problem is that it won't know the size until it finishes the entire compile.  If I make it pause the size at the end, it will annoy many users who want to compile as quickly as possible.  But I just had a great idea as I was typing this.  What if I use the homescreen to display the final size of the program?  Axe clears the homescreen anyway when it quits, it might as well do something useful with it.  I like that, I think I'll add that feature.  By the way, the size displayed will not be the same as what you see in the memory management menu because it will not include the symbol table entry.
Title: Re: Features Wishlist
Post by: ztrumpet on December 12, 2011, 10:30:45 pm
@Happybobjr
The problem is that it won't know the size until it finishes the entire compile.  If I make it pause the size at the end, it will annoy many users who want to compile as quickly as possible.  But I just had a great idea as I was typing this.  What if I use the homescreen to display the final size of the program?  Axe clears the homescreen anyway when it quits, it might as well do something useful with it.  I like that, I think I'll add that feature.  By the way, the size displayed will not be the same as what you see in the memory management menu because it will not include the symbol table entry.
Won't it know the final size after Pass 1?  Couldn't it display the size then and have it onscreen while Pass 2 is happening?
I'm not opposed to the size being displayed on exit, I just figure it'll conflict with some other programs so all users won't be able to see it, plus I like having a clear homescreen. :P
Title: Re: Features Wishlist
Post by: Quigibo on December 12, 2011, 10:32:40 pm
It will know the executable size after pass 1, but it won't know the total size including the data until after pass 2.

EDIT: Maybe make a "statistics" option then?  Display executable size, native subroutine size, data size, total size, amount saved by peephole optimization, etc. when it finishes.
Title: Re: Features Wishlist
Post by: ztrumpet on December 12, 2011, 10:33:53 pm
It will know the executable size after pass 1, but it won't know the total size including the data until after pass 2.
Ah, okay.
In that case, I vote for the homescreen method too.
Title: Re: Features Wishlist
Post by: Builderboy on December 12, 2011, 10:39:18 pm
I still think the percent complete option should ignore included programs, and only report how far through the main program has been compiled.  Because with many subprograms, the compile percent is next to useless D:
Title: Re: Features Wishlist
Post by: Quigibo on December 12, 2011, 10:44:45 pm
I can do that... but then the percentage will just stand still every time it parses a subprogram which might appear like freezing.  I don't know if that would be considered better or worse.  I could at the same time display the percentage of the subprogram elsewhere at this moment.  I'll see how it looks.
Title: Re: Features Wishlist
Post by: ztrumpet on December 12, 2011, 10:58:44 pm
I could at the same time display the percentage of the subprogram elsewhere at this moment.
That's a really cool idea, and I like it a lot.
Maybe you could display it in the very bottom row of the screen.
Title: Re: Features Wishlist
Post by: Builderboy on December 12, 2011, 11:18:34 pm
Or maybe something like this O.O
Title: Re: Features Wishlist
Post by: leafy on December 12, 2011, 11:23:09 pm
That would be pretty awesome :D
Title: Re: Features Wishlist
Post by: LincolnB on December 13, 2011, 06:52:58 pm
^^YES. I would love that.
Title: Re: Features Wishlist
Post by: Quigibo on December 13, 2011, 07:43:13 pm
Alright, I'm just going to redesign the compiling progress menu in general.  I think I can include 3 or 4 feature requests into that screen by just readjusting the layout.
Title: Re: Features Wishlist
Post by: epic7 on December 13, 2011, 07:44:04 pm
Ooh, cool!
Title: Re: Features Wishlist
Post by: Builderboy on December 13, 2011, 07:44:53 pm
Yays :D You might as well make the program selection menu graphscreen and small font while you're at it :]
Title: Re: Features Wishlist
Post by: thydowulays on December 14, 2011, 04:42:16 pm
I think it would be amazing if you could have a thing in the options menu that would say something like Auto-Execute. That would execute your program under whichever shell you compiled it under right after compiling it. Its just an idea :)
Title: Re: Features Wishlist
Post by: Hayleia on December 15, 2011, 12:55:56 am
I think it would be amazing if you could have a thing in the options menu that would say something like Auto-Execute. That would execute your program under whichever shell you compiled it under right after compiling it. Its just an idea :)
That would be great for testing. However, there are problems: a lot of pepole don't use shells (so that would be impossible) and another lot of people compile for Ion for compatibility reasons, but I don't think people still use Ion ;) (except that one guy I met at school O.O)
Moreover, that would be a very heavy feature.
Title: Re: Features Wishlist
Post by: aeTIos on December 15, 2011, 03:24:00 am
Request: (I already posted this earlier)
Array support PLEASE!
Arrays would be like this:
Height(2bytes),Width(2bytes),Array
And then call the data with Array(Ptr,X,Y)

Is that feasible?
Title: Re: Features Wishlist
Post by: Quigibo on December 15, 2011, 04:04:58 am
A random access array is too complicated to implement and wouldn't be as efficient as accessing native Axe data so I don't think you will see that soon unless I have some new revelation.  However, an expandable table of fixed size objects that only needs iterative access you will see in the near future because this is both simpler to program and can be made equally or more efficient than current native methods.  I also feel that out of all the data structures, this is used the most by Axe programmers.

EDIT: In the future if I support macros, writing your own array accessing like your example would be pretty simple.
Title: Re: Features Wishlist
Post by: aeTIos on December 15, 2011, 04:40:55 am
Uh, what do you mean with
Quote
an expandable table of fixed size objects that only needs iterative access
?
Please elaborate on that.
Title: Re: Features Wishlist
Post by: Quigibo on December 15, 2011, 05:17:26 am
I can't elaborate much because I don't know the exact specifications for it yet since its still in planning stages.  But basically a table is a data structure with objects.  There will be a special iterator loop structure, probably something similar in syntax to "For([A])".  You can add, remove, access, and modify only the current object from the iteration.  Order cannot matter during the iteration because the positions might change around during these operations.  You can access the Nth data byte of your custom objects, but you cannot access the Nth object because this would be unstable during the above operations and it requires a multiply.

This is all speculation so far.  I might also have to introduce the concept of "binders" to make this nestable.
Title: Re: Features Wishlist
Post by: aeTIos on December 15, 2011, 05:19:53 am
Just like an array you can't change?   <_<
Title: Re: Features Wishlist
Post by: Quigibo on December 15, 2011, 05:29:05 am
You can change it as much as you want.  It just has to be read in order, not arbitrarily.  Enforcing this leads to HUGE optimizations in size and speed, plus it makes coding clean and compact.  If you need to access an X,Y pair you should be using a 2d array structure instead.  What this is more similar to is an object List (java), Table (SQL), or Vector (C++).
Title: Re: Features Wishlist
Post by: aeTIos on December 15, 2011, 05:29:38 am
Aha. Thanks.
Title: Re: Features Wishlist
Post by: LincolnB on December 15, 2011, 09:32:58 am
In the poll, what is meant by "Better UI Features"?
Title: Re: Features Wishlist
Post by: Happybobjr on December 15, 2011, 01:02:45 pm
I always love faster code ;)
Title: Re: Features Wishlist
Post by: Yeong on December 15, 2011, 01:18:52 pm
idk if it's possible or not, but can you add a "hittest" for object-object(sprites)?
Title: Re: Features Wishlist
Post by: Keoni29 on December 15, 2011, 01:24:13 pm
The frequency which Freq() generated is different on each calculator. Is there a way to tune it easily or do we need an updated Freq command for that?
Title: Re: Features Wishlist
Post by: epic7 on December 15, 2011, 07:43:17 pm
Maybe auto-backup for libraries.
Title: Re: Features Wishlist
Post by: Builderboy on December 15, 2011, 07:47:50 pm
idk if it's possible or not, but can you add a "hittest" for object-object(sprites)?

That's already super simple to do with Axe, there really isn't any reason to make a specific function to do the math for you.
Title: Re: Features Wishlist
Post by: Yeong on December 15, 2011, 09:57:54 pm
may I ask how to do so? D:
or is it the one that messes with back buffer?
Title: Re: Features Wishlist
Post by: epic7 on December 15, 2011, 10:17:10 pm
Just collisions??
What I've always done was
If abs(X-A)<8
If abs(Y-B)<8
.when object X,Y and object A,B collide
End
End
Title: Re: Features Wishlist
Post by: Yeong on December 15, 2011, 10:18:56 pm
not that collision. I mean "interaction" between different objects.
Title: Re: Features Wishlist
Post by: epic7 on December 15, 2011, 10:22:02 pm
I knew it would be something more complicated then just collision :P

Like physics and stuff with colliding? In that case, ask the physics guru :p



Title: Re: Features Wishlist
Post by: Freyaday on December 16, 2011, 12:25:45 am
Can there be an option to make pxl-test() return a one instead of zero when it is out of bounds?
Title: Re: Features Wishlist
Post by: leafy on December 16, 2011, 12:40:43 am
Can there be an option to make pxl-test() return a one instead of zero when it is out of bounds?
Frey wouldn't it just be easier to check if the coordinates are outside of the bounds of the screen first?

I'm in favor of a really optimized scrolling tilemapper routine, but I'd like to see some more of these agressive ops :P
Title: Re: Features Wishlist
Post by: Freyaday on December 16, 2011, 01:04:50 am
Can there be an option to make pxl-test() return a one instead of zero when it is out of bounds?
Frey wouldn't it just be easier to check if the coordinates are outside of the bounds of the screen first?

I'm in favor of a really optimized scrolling tilemapper routine, but I'd like to see some more of these agressive ops :P
Bounds checking is built in to the routine, and it'd be a trivial matter to change it from returning a 0 to returning a 1
Title: Re: Features Wishlist
Post by: Keoni29 on December 16, 2011, 02:38:03 am
Maybe auto-backup for libraries.
And includes
Title: Re: Features Wishlist
Post by: ztrumpet on December 16, 2011, 06:55:35 am
Can there be an option to make pxl-test() return a one instead of zero when it is out of bounds?
Frey wouldn't it just be easier to check if the coordinates are outside of the bounds of the screen first?

I'm in favor of a really optimized scrolling tilemapper routine, but I'd like to see some more of these agressive ops :P
Bounds checking is built in to the routine, and it'd be a trivial matter to change it from returning a 0 to returning a 1
Yes, but that would not allow backwards compatibility to everyone who already uses 0 as the value returned by objects out of bounds in their code.
Like leafy said, it'd be easier to check first and then pixel test.
Title: Re: Features Wishlist
Post by: Quigibo on December 16, 2011, 02:40:18 pm
Bounds checking is not built into the routine anyway.  In fact, it uses modular checking meaning that pxl-Test(300,10) will test the same pixel as pxl-Test(44,10).  Technically, behavior outside the screen is considered undefined and could change in future versions.  But due to the way it optimizes, I'm 99% sure it will stay the same as it is now.
Title: Re: Features Wishlist
Post by: Sorunome on December 16, 2011, 02:42:32 pm
Maybe auto-backup of archived programs.
Title: Re: Features Wishlist
Post by: Camdenmil on December 17, 2011, 06:27:36 pm
What about support for the crystal timers?
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 06:29:03 pm
What about support for the crystal timers?
Sounds like an excellent candidate for an Axiom ^^
Title: Re: Features Wishlist
Post by: Freyaday on December 17, 2011, 08:05:59 pm
A  sprite command that would treat black as transparent and white as solid. Perhaps it could be called Pt-Black()?
Title: Re: Features Wishlist
Post by: epic7 on December 17, 2011, 08:08:29 pm
A  sprite command that would treat black as transparent and white as solid. Perhaps it could be called Pt-Black()?
Wat? You mean draw the sprite inverted?
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 08:15:31 pm
Couldn't you just use Pt-Mask() ?
Title: Re: Features Wishlist
Post by: LincolnB on December 17, 2011, 08:15:47 pm
well that's relatively easy to write a subroutine yourself, just Logically XOR every byte of the sprite with 255.
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 08:17:23 pm
well that's relatively easy to write a subroutine yourself, just Logically OR every byte of the sprite with 255.

Wouldn't that return 255 all the time?  O.o What he wants is AND sprite logic.
Title: Re: Features Wishlist
Post by: Freyaday on December 17, 2011, 08:44:00 pm
No, NOR logic.
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 09:16:47 pm
Mmm I believe AND logic is what you want, here is the truth table:

Sprite: Screen: Result:
000
010
100
111

As you can see, when the sprite is white (0) it forces the result to be white.  This emulates a solid white color.  When the sprite is black, the result is equal to the screen, which emulates a transparent color.  NOR logic would look like so:

Sprite: Screen: Result:
001
010
100
110

Where if the sprite was black, the result would be white, and if the sprite was white, the result would be an inverse.
Title: Re: Features Wishlist
Post by: LincolnB on December 17, 2011, 09:25:07 pm
Oops, I meant XOR. My bad, I modified the last post. XOR the sprite with 255 and do a Pt-On with that sprite. Although if you're logically altering L6 directly, AND logic should be good.
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 09:29:29 pm
That won't work either because Pt-On can only turn on pixels, not turn them off.
Title: Re: Features Wishlist
Post by: Quigibo on December 17, 2011, 09:32:07 pm
Yeah, the best option is to work with the "Light" version of the screen and use the standard Pt-Mask()r, but right before the DispGraph, do a DrawInv.  If you don't clear the screen after that and need to continue working with it, just call another DrawInv to convert it back again to the light version.
Title: Re: Features Wishlist
Post by: LincolnB on December 17, 2011, 09:35:07 pm
Oh, I was under the impression Freyaday wanted white pixels in the sprite to show up black on the screen, and black pixels to not show up. Guess not.
Title: Re: Features Wishlist
Post by: Builderboy on December 17, 2011, 09:43:31 pm
Yeah, the best option is to work with the "Light" version of the screen and use the standard Pt-Mask()r, but right before the DispGraph, do a DrawInv.  If you don't clear the screen after that and need to continue working with it, just call another DrawInv to convert it back again to the light version.

Couldn't you work with the Pt-Mask routine normally without resorting to inverting the entire screen? If I remember correctly it does support sprites that are white and transparent. 
Title: Re: Features Wishlist
Post by: Quigibo on December 17, 2011, 09:55:51 pm
Oh wait, you're right.  You just have to change the sprite beforehand to map transparent to 0,0 on the sprite+mask and white to 0,1 which is easy because you don't have to do that at runtime, just import your sprites in this format.
Title: Re: Features Wishlist
Post by: ztrumpet on December 17, 2011, 10:05:25 pm
Quigibo, why don't you add an invert command like the rotC, rotCC, flipV, and flipH commands?  This would make tasks like what Frey wants to do a lot easier and I can see it being just as useful as those other four commands.
Title: Re: Features Wishlist
Post by: leafy on December 17, 2011, 10:06:54 pm
Oh here's something I've always really wanted - a RectOff command.

(Yes that sounds kinda weird)
Title: Re: Features Wishlist
Post by: Freyaday on December 17, 2011, 10:14:01 pm
Oh here's something I've always really wanted - a RectOff command.

(Yes that sounds kinda weird)
That's what I asked for with RectW()
Title: Re: Features Wishlist
Post by: Sorunome on December 18, 2011, 02:25:57 pm
Maybe also a progress bar for defragmenting, if that is possible?
Title: Re: Features Wishlist
Post by: Builderboy on December 18, 2011, 02:30:23 pm
I believe that is an OS routine, and so can't be kept track of by Axe D:
Title: Re: Features Wishlist
Post by: Sorunome on December 18, 2011, 02:31:10 pm
But doors can also have a custome Garbage Collection image.....
Title: Re: Features Wishlist
Post by: Builderboy on December 18, 2011, 02:48:03 pm
Is it a custom image or is it actually a progress bar?
Title: Re: Features Wishlist
Post by: Sorunome on December 18, 2011, 02:50:06 pm
Just a image
EDIT: Maybe it is possible that Axe has then the defragmenting routine built in with the progress bar?
Title: Re: Features Wishlist
Post by: Freyaday on December 18, 2011, 03:00:56 pm
Oh dear. I really despise the attitude that, because it can be done with other commands, there is no reason to make a new command for something, even if the new command would be much faster and lead to smaller code.
Oh look, the z80 doesn't have a multiply instruction! Eh, let's leave it to the Axe prgrammers, surely they won't mind!
Oh, wait, that's exactly what didn't happen. Thanks Quigibo!
Title: Re: Features Wishlist
Post by: leafy on December 18, 2011, 03:37:42 pm
RectOff or RectW would make a white rectangle ? You just need to do
Rect(A,B,C,D)
RectI(A,B,C,D)
and you obtain a white rectangle :)
Yeah, the reason I don't like this is that you have to use two commands, and I'm assuming a command could be made to just do the opposite of Rect( anyways.
Title: Re: Features Wishlist
Post by: JosJuice on December 18, 2011, 03:53:06 pm
But doors can also have a custome Garbage Collection image.....
Doors CS uses some clever hacks involving hooks to just be able to skip the confirmation screen and draw an image. Tracking the progress would require somehow knowing what the GC routine is doing while also redrawing the image, which as far as I know simply isn't possible with hooks.
Title: Re: Features Wishlist
Post by: ben_g on December 18, 2011, 04:15:58 pm
I just noticed there isn't an 8.8 divide yet. Could you add that?

If it already exists, then sorry, i didn't find it.
Title: Re: Features Wishlist
Post by: calcdude84se on December 18, 2011, 04:51:45 pm
You just invert and multiply. So to divide A by B, one simply does B-1**A.
Title: Re: Features Wishlist
Post by: thydowulays on December 18, 2011, 08:27:35 pm
I have the greatest idea in the world. A function that does this:

neg(*insert integer here*)
This would make the number negative. Yes I know you can do // and >> and all that, but this one would put the - thingy behind it and everything. This would be better because then I wouldn't have to keep writing a subroutine to do this for me......
Title: Re: Features Wishlist
Post by: calc84maniac on December 18, 2011, 08:28:54 pm
How about -abs()
Title: Re: Features Wishlist
Post by: thydowulays on December 18, 2011, 08:31:25 pm
:O I will love you forever if that works.....

EDIT: I level'd up! FUCK YEAH
Title: Re: Features Wishlist
Post by: ztrumpet on December 18, 2011, 08:35:26 pm
While were's on the subject, how about a command that determines the sign of a number.  I.E., anything over 32218 (I think) would return 65535 (-1), anything between that number and zero would return 1, and zero would return 0.  I remember 86 Basic had it and it was a nice command.
Title: Re: Features Wishlist
Post by: Freyaday on December 18, 2011, 08:46:47 pm
That would be incredibly useful.
Title: Re: Features Wishlist
Post by: Quigibo on December 18, 2011, 09:19:17 pm
That's basically A<<0 which is a highly optimized command to return 1 if its negative and 0 if its positive or zero.  That separates out the negative case.  Then !If A can extract the zero from the remaining case.

But if you need the exact number output, I think this is fairly uncommon so I don't think that a command for it is needed.  But here it is in optimized Axe code: A>=>=0?A?1,,-1

EDIT: The white rectangle thing I guess I can see useful, but each rectangle routine is over 100 bytes, which is much larger than making your own subroutine to do the same thing with the existing commands.  The only time it would be useful from a optimization perspective is if you only use 2 out of the 3 rectangle routines in your entire program at any point, or you are super super pressed for speed because you're drawing hundreds of white rectangles every second.  I will consider adding it though, just be warned it can easily bloat your code more than using the existing commands.
Title: Re: Features Wishlist
Post by: calc84maniac on December 18, 2011, 09:21:25 pm
How about this:
A?>=>=0*2-1

Edit: Since I have been informed that inc hl \ dec hl is peephole-optimized, make it this:
A?>=>=0-1*2+1
Title: Re: Features Wishlist
Post by: jacobly on December 20, 2011, 12:50:23 am
If 32-bit *^ is added, then something like /^ that returns the quotient and remainder would be useful.
Title: Re: Features Wishlist
Post by: Sorunome on December 23, 2011, 08:24:20 am
Maybe you could make it possible that it may write apps larger than one page?
Title: Re: Features Wishlist
Post by: aeTIos on December 23, 2011, 08:57:35 am
not possible oncalc D: Due to RAM limits
Title: Re: Features Wishlist
Post by: Sorunome on December 23, 2011, 08:58:19 am
Maybe it is possible if you pars first the first page and then the second page etc. ?
Title: Re: Features Wishlist
Post by: Hayleia on December 23, 2011, 08:59:16 am
not possible oncalc D: Due to RAM limits
??? This has nothing to do with Ram limit since Apps are run from Archive.
This is more like rewriting all the "Compile for app" option, so I think it is at the bottom of the To Do list :(
Title: Re: Features Wishlist
Post by: aeTIos on December 23, 2011, 09:01:39 am
Its super hard to do since you have to keep track of everything involved with moar-page apps, such as page switching and stuff. It is harder than it seems.
Title: Re: Features Wishlist
Post by: JosJuice on December 23, 2011, 09:02:31 am
Maybe it is possible if you pars first the first page and then the second page etc. ?
The memory that's needed isn't the only problem. Writing multi-page apps in any language requires extra code in the app to deal with page swapping, and the contents of the pages have to be separated by the programmer. The compiler can't do this alone - the programmer has to think about all of this. I believe that changes in how the language works are required, but I'm not sure since I don't have a lot of experience of things like this.
not possible oncalc D: Due to RAM limits
??? This has nothing to do with Ram limit since Apps are run from Archive.
Maybe the RAM limit would be a problem during compilation?
Title: Re: Features Wishlist
Post by: aeTIos on December 23, 2011, 09:03:37 am
Quigibo said it might be possible but he said it was absolutely impossible oncalc (therefore he wansa write a pc compiler)
Title: Re: Features Wishlist
Post by: Hayleia on December 23, 2011, 09:03:39 am
Writing a multiple page app is already a pain to organize so writing a multipage app (Axe) that creates multipage apps (your app) would be very tricky :P

not possible oncalc D: Due to RAM limits
??? This has nothing to do with Ram limit since Apps are run from Archive.
Maybe the RAM limit would be a problem during compilation?
Yeah, I didn't think about that one D:
Title: Re: Features Wishlist
Post by: Sorunome on December 23, 2011, 09:23:07 am
Quigibo said it might be possible but he said it was absolutely impossible oncalc (therefore he wansa write a pc compiler)
That would be cool to have one with multiple pages-apps for pc! :)
Title: Re: Features Wishlist
Post by: calc84maniac on December 23, 2011, 10:35:00 am
Having code on multiple pages is pretty hard to orchestrate without writing the code manually in ASM. On the other hand, having only data, not code, on other pages might be possible if something similar to the archived file reading operations are used (and RAM wouldn't be an incredibly difficult issue there, since the extra-page data could be written directly to archive rather than being stored in RAM)
Title: Re: Features Wishlist
Post by: ztrumpet on December 23, 2011, 11:27:56 am
I think it would be incredibly helpful to have the option to make two or three page Apps, with the pages other than the first one (page 0) having only data on them.  This is something I've dreamed of ever since Axe started.
Title: Re: Features Wishlist
Post by: calc84maniac on December 23, 2011, 11:38:48 am
I think the most effective way to accomplish this would be to have a different static pointer syntax (with a prefix or something) for data on other app pages. That way, the user will be able to control what data is accessed more slowly and what data is accessed more quickly, and Axe will easily know whether to generate a normal memory access or an off-page memory access. If you use a 16-bit pointer for off-page accesses, that's a maximum of 4 pages of data available, and data will be able to cross page boundaries.

Edit: Also, I suppose that when compiling a RAM program, these special pointers could be treated like normal data, as much as RAM allows.

Edit2: Actually, come to think of it, this wouldn't work for specifying anonymous data on other pages. But I guess [HEX]r and Data()r aren't taken, right?

Edit3lol: In fact, if the syntax for archived data is Data()→prefixStr1, the syntax for anonymous data could be Data()→prefix
Title: Re: Features Wishlist
Post by: Freyaday on December 23, 2011, 07:01:37 pm
A version of ClrDraw that fills the screen with black instead of white. For making White-on-black games. :)
Title: Re: Features Wishlist
Post by: saintrunner on December 23, 2011, 07:03:02 pm
oooh, I like that! That would have helped with Pogo Dark/Light....then again, I just used drawinv..
Title: Re: Features Wishlist
Post by: epic7 on December 23, 2011, 07:09:25 pm
Yeah, you could just make the game in black on white, and then used a DrawInv
Title: Re: Features Wishlist
Post by: Runer112 on December 23, 2011, 07:33:56 pm
A version of ClrDraw that fills the screen with black instead of white. For making White-on-black games. :)

This can be done quite easily already with Fill(L₆,768,ᴇFF), which fills 768 bytes (size of graph buffer) of data starting at L₆ (the graph buffer) with ᴇFF (all bits 1 = black). An optimized form of this is Fill(L₆,768,-1).

A large reason ClrDraw exists is because there is a bcall that does just that. However, there is no bcall that clears the buffer to black, so it wouldn't really make sense to have an Axe command just for it, especially since a built-in routine would do pretty much the same exact thing as the code I wrote above.
Title: Re: Features Wishlist
Post by: parserp on December 23, 2011, 08:45:26 pm
A version of ClrDraw that fills the screen with black instead of white. For making White-on-black games. :)
hmmm? I thought that is possible with: Rect(0,0,96,64) ?
Title: Re: Features Wishlist
Post by: Builderboy on December 23, 2011, 09:04:55 pm
There are indeed many routines to quickly fill the screen with black.  Runer's is possibly the fastest and most optimized as well
Title: Re: Features Wishlist
Post by: thydowulays on December 23, 2011, 11:31:37 pm
I really think you should make a Switch command. Like the switch command in C++ you know? You could replace SetUpEditor, since we are using lists for buffer pointers. It would really be nice :)

EDIT:OMGOMGOMGOMGOMG I LEVELED UP!!!!! I can use omnomirc now  :w00t:
Title: Re: Features Wishlist
Post by: Builderboy on December 23, 2011, 11:34:11 pm
You should check out the new features on the newest version, there is already a switch command :D
Title: Re: Features Wishlist
Post by: thydowulays on December 23, 2011, 11:34:53 pm
:O, are you serious?! *orgasm* Lemme find it :D

EDIT: Wait, do you know how to use it? I need it for my SPTEXT thing in the GUI library, so I can switch the getkeys that people press
Title: Re: Features Wishlist
Post by: Builderboy on December 23, 2011, 11:45:07 pm
You can read Quigibo's detailed description in his post here (http://ourl.ca/4050/272146) :)
Title: Re: Features Wishlist
Post by: thydowulays on December 23, 2011, 11:54:20 pm
Thanks!
Title: Re: Features Wishlist
Post by: Runer112 on December 27, 2011, 12:46:13 pm
The addition of preprocessor conditionals was awesome, and I will find it very useful. But could there also be something similar to #ifdef? It would be useful for Axe libraries that allow the user to customize them by including defines in their own source code, and the library can fill in any defines with default values if the user didn't define them. The obvious solution would be a new command that determines whether or not the constant is defined. If you don't want to add a new command, you could also try something like the standard preprocessor conditional, but with the constant being used in a trivial comparison, like this:

...!If °Size≥0
8→°Size
...
Title: Re: Features Wishlist
Post by: Yeong on December 29, 2011, 07:12:46 pm
Able to draw polygonal shapes?
Like Poly(5,10 coordinates draws filled polygon and stuff?
Title: Re: Features Wishlist
Post by: TIfanx1999 on December 30, 2011, 06:25:09 am
^Would probably be a good Axiom.
Title: Re: Features Wishlist
Post by: Hayleia on December 31, 2011, 07:27:01 am
I think the most effective way to accomplish this would be to have a different static pointer syntax (with a prefix or something) for data on other app pages. That way, the user will be able to control what data is accessed more slowly and what data is accessed more quickly, and Axe will easily know whether to generate a normal memory access or an off-page memory access. If you use a 16-bit pointer for off-page accesses, that's a maximum of 4 pages of data available, and data will be able to cross page boundaries.

Edit: Also, I suppose that when compiling a RAM program, these special pointers could be treated like normal data, as much as RAM allows.

Edit2: Actually, come to think of it, this wouldn't work for specifying anonymous data on other pages. But I guess [HEX]r and Data()r aren't taken, right?

Edit3lol: In fact, if the syntax for archived data is Data()→prefixStr1, the syntax for anonymous data could be Data()→prefix

So, with that, would multipage apps with only data on secondary pages be possible ? :D
Title: Re: Features Wishlist
Post by: Freyaday on January 02, 2012, 04:50:18 pm
Would it be possible to check if a constant has been defined in a preprocessor conditional?
Title: Re: Features Wishlist
Post by: Runer112 on January 02, 2012, 05:03:18 pm
/me points to his post on the last page

The addition of preprocessor conditionals was awesome, and I will find it very useful. But could there also be something similar to #ifdef? It would be useful for Axe libraries that allow the user to customize them by including defines in their own source code, and the library can fill in any defines with default values if the user didn't define them. The obvious solution would be a new command that determines whether or not the constant is defined. If you don't want to add a new command, you could also try something like the standard preprocessor conditional, but with the constant being used in a trivial comparison, like this:

...!If °Size≥0
8→°Size
...

Title: Re: Features Wishlist
Post by: Freyaday on January 02, 2012, 06:35:47 pm
Oh! I didn't know that's what you meant.That syntax doesn't make any sense though. The address doesn't exist, it is undefines, it has no value. It's like asking if the color pi is greater than the yellow orange. It makes no sense.
Title: Re: Features Wishlist
Post by: Runer112 on January 02, 2012, 06:57:56 pm
My idea was that any (unsigned) number in Axe is greater than or equal to 0, but NaN is not. But on second thought that syntax suggestion is sort of confusing. I guess a new command may be the best way to go.
Title: Re: Features Wishlist
Post by: Quigibo on January 02, 2012, 07:50:36 pm
I'm not so sure if I want an "IfDef" type command.  What's wrong with just defining a constant as 0 or -1 if its going to be unused?  Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.
Title: Re: Features Wishlist
Post by: parserp on January 02, 2012, 08:26:20 pm
One question: in the poll, what is mode7?
Title: Re: Features Wishlist
Post by: annoyingcalc on January 02, 2012, 08:26:58 pm
kind of like 3d
Title: Re: Features Wishlist
Post by: parserp on January 02, 2012, 08:27:29 pm
kind of like 3d
ahh thanks. That would be really cool :D
Title: Re: Features Wishlist
Post by: annoyingcalc on January 02, 2012, 08:28:02 pm
I think so too
Title: Re: Features Wishlist
Post by: Runer112 on January 02, 2012, 08:44:59 pm
I'm not so sure if I want an "IfDef" type command.  What's wrong with just defining a constant as 0 or -1 if its going to be unused?  Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

The main purpose I can think of is, as I suggested in my original post, Axe libraries. Say you want to write a killer tilemapping library. You may need a bunch of different options to make it really versatile: tile width, tile height, black and white or grayscale, bits per tile, compression scheme, tileset pointer location, map pointer location, read from archive ability, smooth or rough scrolling, custom/variable buffer pointer, animated tile support... the list could go on. Being a true library, it's not proper to edit the library file itself. The user should specify customization settings in their own program.

Without something like an #ifdef, you would have to force the programmer to define a dozen different constants for features they don't need, or don't even know exist. If a new feature was added to the library down the road, their program would instantly be broken because it would need a new constant defined. And including all of these constants in their source would cause unnecessary headaches and source bloat that could be a hundred bytes or more.
Title: Re: Features Wishlist
Post by: Builderboy on January 02, 2012, 09:14:20 pm
Another option would be to have Axe not disallow multiple constant defines.  If two constants were defined, it would chose the first one encountered and ignore the rest.  This would allow the same as what Runer is suggesting, but without any new commands.
Title: Re: Features Wishlist
Post by: Freyaday on January 02, 2012, 09:40:49 pm
But that doesn't work if you want to have several programs with repeated data in them that you don't want duplicated when you compile them into one program.
Title: Re: Features Wishlist
Post by: Builderboy on January 02, 2012, 09:41:59 pm
But that doesn't work if you want to have several programs with repeated data in them that you don't want duplicated when you compile them into one program.
True I suppose, not throwing an error would made for some really annoying bugtesting if you unintentionally created a duplicate filename.
Title: Re: Features Wishlist
Post by: Quigibo on January 03, 2012, 12:09:08 am
I'm not so sure if I want an "IfDef" type command.  What's wrong with just defining a constant as 0 or -1 if its going to be unused?  Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

The main purpose I can think of is, as I suggested in my original post, Axe libraries. Say you want to write a killer tilemapping library. You may need a bunch of different options to make it really versatile: tile width, tile height, black and white or grayscale, bits per tile, compression scheme, tileset pointer location, map pointer location, read from archive ability, smooth or rough scrolling, custom/variable buffer pointer, animated tile support... the list could go on. Being a true library, it's not proper to edit the library file itself. The user should specify customization settings in their own program.

Without something like an #ifdef, you would have to force the programmer to define a dozen different constants for features they don't need, or don't even know exist. If a new feature was added to the library down the road, their program would instantly be broken because it would need a new constant defined. And including all of these constants in their source would cause unnecessary headaches and source bloat that could be a hundred bytes or more.

But these can still be done without ifdef.  You could have a constant defined as 0 for monochrome, 1 for 3-scale and 2 for 4-scale.  If you are using monochrome you need not define the other constants required for 4-scale such as external buffer locations.  Defines can be inserted into conditional comments as well which can be used to chain them and perform the logic you might need.

Another feature coming next version will be to preprocess more operations on constants than just +-*/^.  These will include all signed/unsigned equality and comparisons, bit operations, and bit checking.  This should make it easier for library writers.
Title: Re: Features Wishlist
Post by: Runer112 on January 03, 2012, 12:18:25 am
My suggestion is that you should be to use #ifdef in a library to fill in defines with default values if the user doesn't define them. Say the user just wants a basic tilemapper. You'd probably expect that to default to a black and white 8x8 smoothscroller with 8 bits per tile, no compression, a static buffer (plotSScreen), no animated tile support, no support for reading tiles from archive, and so on. It would be a pain and possibly confusing for someone who just wants to use an easy, basic tilemapper to be forced to define a dozen different constants in their program just to say that he/she doesn't want to deal with the fancy stuff.


EDIT: Also, you said that you didn't want an IfDef type command. I'm not sure if you meant the idea of it being an individual command, or it existing entirely. If it's the former, you can still add this ability without an actual IfDef command by adding a command like Defined(), or as I suggested before, by using a trivial comparison like ≥0 in a preprocessor conditional. If it's the latter, I guess people will manage, it'll just require extra source code for users of customizable libraries.
Title: Re: Features Wishlist
Post by: Quigibo on January 03, 2012, 02:00:17 am
I see, so its mostly default options that this affects.  While I disagree that those settings are intuitive defaults in the example tilemapper, I can definitely see situations where it could be useful to provide default settings for options that rarely need changing.  There are several ways to do this:


I'm guessing the last one would be most convenient for programmers since it's targeted at default values.  One idea for the syntax could be a double store arrow such as 8→→oVar to mean "If Var is not already defined make it 8.  But if it was defined, keep it as it was".
Title: Re: Features Wishlist
Post by: Freyaday on January 03, 2012, 08:42:06 am
I see, so its mostly default options that this affects.  While I disagree that those settings are intuitive defaults in the example tilemapper, I can definitely see situations where it could be useful to provide default settings for options that rarely need changing.  There are several ways to do this:

  • A specific ifdef command
  • A isDefined() command
  • A "Define if undefined" command

I'm guessing the last one would be most convenient for programmers since it's targeted at default values.  One idea for the syntax could be a double store arrow such as 8→→oVar to mean "If Var is not already defined make it 8.  But if it was defined, keep it as it was".
I like the doubled store command syntax. I suppose I can make it work. Although, expect me to abuse this thing as much as I can. It's a game I play.
Title: Re: Features Wishlist
Post by: Runer112 on January 03, 2012, 10:39:12 am
I think that any of those options would be great. I had suggested an ifdef-like command because it seemed easier to just base my suggestion on an existing assermbler directive, but any of those options would serve the purpose. The first two would be more general and flexible, but maybe the third would actually be better with its more specific and smaller syntax.

Now, all Axe libraries need are conditional inclusion of routines based on whether or not they are actually used, like real routines and Axiom commands, and they'll be fully awesome. ;D
Title: Re: Features Wishlist
Post by: Runer112 on January 10, 2012, 09:16:59 pm
How about the ability to use Pt-Mask()r with arbitrary buffers? Unlike Pt-Mask(), it only uses one buffer which is only referenced once, so arbitrary buffer support would be just as easy as with the three basic sprite drawing commands.

Also, the command list description for Pt-Mask()r should probably be changed a bit. The sprite argument isn't a "grayscale sprite" like with Pt-Mask().
Title: Re: Features Wishlist
Post by: Quigibo on January 11, 2012, 06:07:10 pm
Excellent idea!  Also, I need to finalize the list of hijack-able routines soon to make the framework more stable so if you have suggestions for similar features in other routines, now would be a good time :)
Title: Re: Features Wishlist
Post by: Freyaday on January 11, 2012, 09:49:13 pm
Circle()?
Title: Re: Features Wishlist
Post by: C0deH4cker on January 12, 2012, 02:26:05 pm
Token<->string conversion would be nice.
Title: Re: Features Wishlist
Post by: Runer112 on January 20, 2012, 11:31:14 am
A long time ago, the ability to enter inline data was added, so you could do things like Pt-On(X,Y,[FFFFFFFFFFFFFFFF]). This is quite useful. However, inline data cannot be the operand of any math operations, like Text A+[0606060600]. Could this ability be added? I realize that you can perform math on inline data by putting the inline data first or in parentheses, but both of those are less optimized and look a bit less clean.
Title: Re: Features Wishlist
Post by: C0deH4cker on January 23, 2012, 05:29:02 pm
the Pt-On() with the inline data works because whenever you use a data command (such as "", [], or Data() ), the command returns a pointer. The Pt-On() command's third argument accepts a pointer, so that is why it works.  However, when you say A+[XXXX]->A, all youre doing is adding the pointer to the data to A. You could do this: {[06A9]+1}->A, which would store $A9 to A.
Title: Re: Features Wishlist
Post by: Builderboy on January 23, 2012, 05:41:14 pm
Codehacker, Runer knows the difference between pointers and their data, he is remarking upon the fact that A+[XXXX]->A returns an Invalid Token error. ;)
Title: Re: Features Wishlist
Post by: Thundermagnet on January 23, 2012, 06:02:50 pm
I actually do not know if this exists in Axe, but in BASIC, "line(X1,Y1,X2,Y2,0)" turns off a line.  Notice the zero.
This would be most helpful in my newest creation, Dodge2.
Title: Re: Features Wishlist
Post by: C0deH4cker on January 23, 2012, 06:19:13 pm
Codehacker, Runer knows the difference between pointers and their data, he is remarking upon the fact that A+[XXXX]->A returns an Invalid Token error. ;)

Right. I just realized who it was that posted that. And i know that he knows more about Axe than almost anybody else.

/me feels stupid right now.
Title: Re: Features Wishlist
Post by: Hayleia on January 24, 2012, 02:09:45 pm
I actually do not know if this exists in Axe, but in BASIC, "" turns off a line.  Notice the zero.
This would be most helpful in my newest creation, Dodge2.
A slow way to do this is
   DrawInv
   Line(X1,Y1,X2,Y2)
   DrawInv
But it is quite slow :(
Title: Re: Features Wishlist
Post by: parserp on January 24, 2012, 04:44:08 pm
I actually do not know if this exists in Axe, but in BASIC, "" turns off a line.  Notice the zero.
This would be most helpful in my newest creation, Dodge2.
A slow way to do this is
   DrawInv
   Line(X1,Y1,X2,Y2)
   DrawInv
But it is quite slow :(
well, that is a inverted line, not a 'turn off a line'. ;)


EDIT: wait, nope. my bad. :P
Title: Re: Features Wishlist
Post by: thydowulays on January 24, 2012, 04:52:31 pm
I actually do not know if this exists in Axe, but in BASIC, "line(X1,Y1,X2,Y2,0)" turns off a line.  Notice the zero.
This would be most helpful in my newest creation, Dodge2.

Thundermagnet, for what you're doing there is actually a pretty simple way to do it. As you may know, when a line goes off the screen, it disappears. So basically if you wanted a line to "turn off" all you would have to do is this: Line(X,X,X,100). Doing so will make the line disappear, and all you have to do is, to get it back, just change the 100, to a variable or a number below 96. Hope it helped!
Title: Re: Features Wishlist
Post by: C0deH4cker on January 24, 2012, 05:59:20 pm
I think that he just wants to draw a white line, not remove an existing line. Like this:


######
######
######
######


to this:


# ####
## ###
### ##
#### #
Title: Re: Features Wishlist
Post by: thydowulays on January 24, 2012, 08:01:01 pm
Oh I see....
Hmm..... well I can't really help you there.
Title: Re: Features Wishlist
Post by: squidgetx on January 25, 2012, 03:14:46 pm
Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles
Title: Re: Features Wishlist
Post by: C0deH4cker on January 25, 2012, 05:21:44 pm
Request: bit shifting
Title: Re: Features Wishlist
Post by: Builderboy on January 25, 2012, 06:20:28 pm
It can be done by using *2 to shift to the left and /2 to shift to the right.
Title: Re: Features Wishlist
Post by: C0deH4cker on January 25, 2012, 07:29:51 pm
Okay, nevermind. isnt that slower than just using the bit shift instructions though?
Title: Re: Features Wishlist
Post by: Builderboy on January 25, 2012, 07:54:29 pm
It uses the bitshifting instructions as an optimization, so it's exactly the same :D
Title: Re: Features Wishlist
Post by: Quigibo on January 25, 2012, 10:07:22 pm
Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles
Its essentially the same speed, it takes almost the same amount of time to display the percentage bar as it did just displaying the percent.  However, this can be sped up by maybe 15% if I display nothing at all, but that's a bad experience for the end user since they feel like it freezes.  It wouldn't be that much faster anyway, its not like its double the speed or anything.

I am still considering adding a white line command but there is no token for it.  Adding an extra argument is unoptimized and I don't want to invent some obscure syntax for it either.  I would probably end up overwriting the Plot3() token instead.  The routine is large though, just as large as the black line drawing, so only use it if you absolutely have to and need more speed than the DrawInv method.  Of course, if you decide to use the experimental Axe Framework, this is never an issue ;).
Title: Re: Features Wishlist
Post by: Darl181 on January 25, 2012, 10:20:04 pm
Would it be unreasonable to watch for a Xor-ing line command as well? ;)
Title: Re: Features Wishlist
Post by: Quigibo on January 25, 2012, 10:23:05 pm
Well... I could do what I did for the Rect() command in that there are only options for "Black" and "Invert".  You would just have to draw both of them to get white.  That's probably what I'd do.

But even more important than that, what I really REALLY want is line clipping.  I have yet to find an algorithm simple enough to implement efficiently in z80 but I challenge anyone to write a routine for it :)
Title: Re: Features Wishlist
Post by: Runer112 on January 25, 2012, 10:31:13 pm
Just wondering, why is something like Line(X1,Y1,X2,Y2,MODE) not possible? I would imagine that, since you do have complete control to do whatever you want in the parser, you could have special-case parsing like this.
Title: Re: Features Wishlist
Post by: Builderboy on January 25, 2012, 10:59:46 pm
As long as it isn't variable based mode select, I think the 5th argument should be a valid option, but the problems arise when variables are introduced D:
Title: Re: Features Wishlist
Post by: Freyaday on January 25, 2012, 11:19:06 pm
But the variables are what make it fun!
Title: Re: Features Wishlist
Post by: Quigibo on January 26, 2012, 12:21:04 am
There is already an optional buffer argument, I can't use that spot for mode unless you're talking about an optional 6th argument but its a weird syntax since the 0 or 1 is part of the syntax rather than a variable.
Title: Re: Features Wishlist
Post by: Runer112 on January 26, 2012, 12:35:06 am
Hmm I didn't think about the buffer argument... But making it an optional 6th argument would definitely work. However, I think it would also be nice if it were allowed to be an optional 5th argument and let the parser intelligently decide if the 5th argument is a buffer or mode. If it's a constant less than the total number of modes, treat it as a mode argument and direct the parser to the appropriate-colored routine. Otherwise, treat it as a buffer argument, because you shouldn't have a constant buffer argument that's any less than 32768 anyways. If this were possible, it would probably also be nice to apply this to the Bitmap() command, and possibly a new syntax for Rect() that allows for a mode argument. That could also solve the issue of white rectangles being bloated/slow, as you could add a white rectangle routine as a mode for Rect().

And I'm not sure what you mean about the optional 0 or 1 (or a 2 perhaps for xor) argument being a weird syntax, so I can't address that.
Just kidding, I just figured out what you meant. I don't see why it's that weird, the user doesn't need to know that it's really a constant that gets special-cased by the parser. It would probably seem just like the mode argument for Bitmap(), albeit possibly with different codes. And it would be pretty much exactly like how Line() works in TI-BASIC, so it should be very easy to pick up.
Title: Re: Features Wishlist
Post by: Builderboy on January 26, 2012, 12:36:02 am
Ah yes, I forgot that you can include the buffer destination with an additional argument. Hmmmm this would indeed be tricky to get right, I fear some new tokens would be the only way.
Title: Re: Features Wishlist
Post by: Quigibo on January 26, 2012, 01:09:47 am
Weird in that it must be constant rather than variable.  I see this as being confusing to beginners also due to the parser-interpreting which isn't intuitive without explanation.
Title: Re: Features Wishlist
Post by: Runer112 on January 26, 2012, 01:19:25 am
Well you could make it work with a variable as well, it would just have to be the 6th argument and would need a speical handler to feed into the appropriate line routine. Yes it would be fairly bloated having multiple line routines, but I think people wouldn't often be using Line() with a variable mode argument anyways. And with the upcoming Axe framework, the size wouldn't matter. :P
Title: Re: Features Wishlist
Post by: ZippyDee on January 26, 2012, 01:28:48 am
why not have a flag of some sort set that determines what mode to use? Then it wouldn't have to have an entirely new routine, it would just have to check the flag when it gets to the xor/or/cpl-and part...Sure, that may slow it down a bit, but it would cut down on size a lot, I'd think.

And, of course, that would only be included if more than one mode was used in the program.
Title: Re: Features Wishlist
Post by: Freyaday on January 27, 2012, 07:21:52 pm
Hmm...I think there's away to use Zippy's method to allow for a variable as the mode select.
Title: Re: Features Wishlist
Post by: thydowulays on February 06, 2012, 03:51:01 pm
Okay Quigbo, I know you're up to your head with stuff to put in, but this one is worth checking out: An option in the compiling menu, called Mimas, where it will assemble it into a Mimas assembly program, so you can look at the source. This would be great for people who are learning assembly that want to see some of the routines in done.
Title: Re: Features Wishlist
Post by: Runer112 on February 06, 2012, 03:58:58 pm
If you want to look at the disassembly of an Axe executable, I would look at it in wabbitemu's disassembler or run it through a "real" disassembler on a computer. I don't really think it's worth it to add a custom compile option targeted for Mimas, which will probably add at least a few hundred bytes to the Axe application, just for the very small subset of people who use Axe, use Mimas, and are learning z80 assembly.
Title: Re: Features Wishlist
Post by: Freyaday on February 06, 2012, 04:45:32 pm
You could always compile it to No Shell and look at it in CalcSys's Disassembler, using the VAT to find it, remembering the actual program starts two bytes after the VAT entry says it does (size bytes!)
Title: Re: Features Wishlist
Post by: Deep Toaster on February 06, 2012, 05:00:27 pm
I like using this program (http://www.ticalc.org/archives/files/fileinfo/162/16219.html) (Windows, though there are other versions for Mac and Linux) for disassembling programs, because it actually outputs the source with equates and everything in a source file, which you can then assemble.

EDIT: Guess that won't be too easy with Mimas, but you could always convert it using the converter packaged with Mimas.
Title: Re: Features Wishlist
Post by: thydowulays on February 06, 2012, 06:36:41 pm
Okay that sounds good! I think I may be able to understand from CalcSys, and I haven't tried wabbitemu's disassembler yet...
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2012, 06:54:04 pm
I have a fairly easy feature request to implement, and one that has been bugging me for a while but I can never remember to suggest it >.< Currently the Alpha toggle feature merely reads the current flag setting and allows you to change it.  I propose it is treated like a preference and stored in the appvar, that way if we reset our RAM and reload Axe, it actually enables the lowercase instead of just leaving it off.
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2012, 06:56:39 pm
The problem with assembling to "Assembly" is that I would have to keep a list of the names of all the labels in the native subroutines somewhere, including the relative labels within each subroutine.  This will involve thousands of bytes of data to keep a list of all the names, offsets, and code to process the new option somewhere in Axe, and I'm almost out of room as it is.
Title: Re: Features Wishlist
Post by: thydowulays on February 06, 2012, 06:58:25 pm
Oh okay, that's fine! Could it be possible though?
Title: Re: Features Wishlist
Post by: Quigibo on February 06, 2012, 07:04:05 pm
I have a fairly easy feature request to implement, and one that has been bugging me for a while but I can never remember to suggest it >.< Currently the Alpha toggle feature merely reads the current flag setting and allows you to change it.  I propose it is treated like a preference and stored in the appvar, that way if we reset our RAM and reload Axe, it actually enables the lowercase instead of just leaving it off.

I thought programs like Mirage, Doors, and zStart already do that for you?  I could add it though, it wouldn't be that difficult.
Title: Re: Features Wishlist
Post by: Builderboy on February 06, 2012, 07:05:41 pm
I thought programs like Mirage, Doors, and zStart already do that for you?  I could add it though, it wouldn't be that difficult.
I only have MirageOS on my calc (don't really use it tho) and I believe it's appvar is kept in RAM.  It would be much appreciated :D
Title: Re: Features Wishlist
Post by: calc84maniac on February 19, 2012, 10:27:58 pm
I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.
Title: Re: Features Wishlist
Post by: willrandship on February 19, 2012, 10:30:03 pm
I would vote for both 1 and 4, but I voted for 4 since it needs it the most, esp. in the area of on-calc documentation. The best I've seen so far is some FlashBook apps, which are not the best choice for manuals. I'd love to see something like CtlgHelp, that gives a small description (or even a large one) of what the command selected does when you press a key!
Title: Re: Features Wishlist
Post by: Quigibo on February 20, 2012, 02:28:39 am
I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.

I would do that, except what about reading nibbles from appvars etc. from an app?  Those still need the other command and it would be way too complicated to auto-infer that during compile time.
Title: Re: Features Wishlist
Post by: calc84maniac on February 20, 2012, 02:32:00 am
I have a suggestion that would make it a lot easier to make source code that compiles both to RAM and to Flash Apps. I think that nib{}r should be changed from a "read from flashapp" routine to a "read from executable" routine. That is, use the default nibble read routine when compiling to a RAM program, and the flash nibble read routine when compiling to an App.

I would do that, except what about reading nibbles from appvars etc. from an app?  Those still need the other command and it would be way too complicated to auto-infer that during compile time.
Reading from appvars from an app would just use nib{} like usual, no?
Title: Re: Features Wishlist
Post by: Quigibo on February 20, 2012, 04:59:55 am
Oh, I see what you mean... I misunderstood.  Although that could work, I can imagine somebody somewhere might want to read a nibble from the app page from a program and there could even be future uses with the Axe Fusion page.  However, it probably benefits more people right now to change it, and it wouldn't have compatibility issues except in extremely rare cases.  But even with a change like this, programs being ported to apps still need to make fundamental changes due to self-modifying code issues.

But I like the idea.  I will probably make the change unless anyone needs to access a nibble in the $0000 - $7FFF address range from a ram program.  Otherwise it'll be impossible to do without assembly so please let me know if you need to do this and object to the change.
Title: Re: Features Wishlist
Post by: calc84maniac on February 20, 2012, 09:49:46 am
And if you want to, you could make a nib{}rr that forces using the $0000 - $7FFF routine in case somebody really needs to use it that way.
Title: Re: Features Wishlist
Post by: Freyaday on February 20, 2012, 04:56:05 pm
Can we have a signed modulo operator?
Title: Re: Features Wishlist
Post by: Darl181 on February 21, 2012, 02:48:32 pm
Would it be possible to, when axe is compiling/zooming a program and it encounters an error, go in and edit the program then when you quit the editor go back to continue or restart compiling/zooming?
This might not be practical for large bug fixes or whatever, but for things like physics tweaking and the like t would be useful :)
Not sure if it would be a compile option or certain key, tho..
Title: Re: Features Wishlist
Post by: Runer112 on February 21, 2012, 02:54:56 pm
Would it be possible to, when axe is compiling/zooming a program and it encounters an error, go in and edit the program then when you quit the editor go back to continue or restart compiling/zooming?
This might not be practical for large bug fixes or whatever, but for things like physics tweaking and the like t would be useful :)
Not sure if it would be a compile option or certain key, tho..

I'm about 90% sure that this is impossible without Axe installing extra hooks, which Quigibo does not want to do. I know that you originally suggested this idea in the zStart thread, and I believe that was the correct place to request a feature like this. I also believe that thepenguin77 is already planning to implement this feature in zStart. He is just waiting for the next version of Axe, which should handle compile errors better from API calls, and then he can add this.
Title: Re: Features Wishlist
Post by: DRAGONLORD343 on February 22, 2012, 11:12:27 am
It may be a small request but wouldn't it be much easier to be able to directly access matrices using the actual [A] matrix token. and if theres any way to directly access them please someone tell me because i feel like ive tried everything
Title: Re: Features Wishlist
Post by: Torio on February 22, 2012, 11:34:39 am
To access directly to matrixes :

Code: [Select]
GetCalc("var[A]") -> A
{A-1} Number of rows of the matrix
{A-2} Number of columns of the matrix
float{N*X+Y*9+A} To access directly to [A](X,Y), where N is the number of rows

Not much more complicated than TI-Basic, right ?
Title: Re: Features Wishlist
Post by: boot2490 on February 23, 2012, 05:55:16 pm
Line clipping support!
Title: Re: Features Wishlist
Post by: Quigibo on February 25, 2012, 07:13:20 pm
It may be a small request but wouldn't it be much easier to be able to directly access matrices using the actual [A] matrix token. and if theres any way to directly access them please someone tell me because i feel like ive tried everything

I could do that, sort of like how I use "Ans" in Axe to represent the BASIC Ans.  But its a bad idea because then programmers get confused from BASIC and try to use it the same way even though it has a totally different meaning.  I kind of wish I hadn't done that with Ans for the same reason.  Also, I'm considering using the matrix tokens to represent tables eventually.
Title: Re: Features Wishlist
Post by: ZippyDee on February 25, 2012, 07:29:48 pm
Line clipping support!
This is going to be coming in an Axiom that is under development.
Title: Re: Features Wishlist
Post by: Runer112 on February 25, 2012, 07:34:56 pm
Line clipping support!
This is going to be coming in an Axiom that is under development.

Frankly, if you get decent line clipping, I think Quigibo would want to include it in Axe itself. The only reason Axe doesn't have proper line clipping currently is because he hasn't gotten around to making a decently small/fast solution himself.
Title: Re: Features Wishlist
Post by: ZippyDee on February 25, 2012, 07:39:05 pm
Frankly, if you get decent line clipping, I think Quigibo would want to include it in Axe itself. The only reason Axe doesn't have proper line clipping currently is because he hasn't gotten around to making a decently small/fast solution himself.
Jacobly is the one currently working on a clipped line routine. My thought was simply that it would be a good idea to include a line routine that doesn't clip, just for size. If someone doesn't need to clip, then the clipping code would just be too extra useless bytes and cycles.
Title: Re: Features Wishlist
Post by: Runer112 on February 25, 2012, 07:46:10 pm
Well I can tell you that clipped lines is on Quigibo's to-do list (I have it right here :P). So I figure if you/jacobly creates a pretty nice line clipping method, Quigibo would probably be happy to include it in Axe. And the people who have been bugging him for native clipped lines (myself included) would be happy as well. :)

EDIT: One thing you could make in an Axiom is an alternate routine, possibly without clipping, that's optimized to be faster.
Title: Re: Features Wishlist
Post by: Darl181 on February 25, 2012, 08:09:57 pm
Could it be possible for programs compiled for Mirage with a custom icon to have all 16 rows?  I was trying it in wabbit and the bottom row of the icon is visibly cut off in Dcs.

Title: Re: Features Wishlist
Post by: ZippyDee on February 25, 2012, 08:12:05 pm
Well I can tell you that clipped lines is on Quigibo's to-do list (I have it right here :P). So I figure if you/jacobly creates a pretty nice line clipping method, Quigibo would probably be happy to include it in Axe. And the people who have been bugging him for native clipped lines (myself included) would be happy as well. :)

EDIT: One thing you could make in an Axiom is an alternate routine, possibly without clipping, that's optimized to be faster.

Hmm...Good idea. Have an optimized line routine that will never clip, and have the clipped one in Axe. Sounds like a good idea to me.
Title: Re: Features Wishlist
Post by: Freyaday on February 25, 2012, 08:15:11 pm
Or, add the clipped line, and put it under a new token. Or put the clipped under the existing Line() and nonclip under a new token.
Title: Re: Features Wishlist
Post by: LincolnB on February 25, 2012, 09:39:14 pm
maybe clipped lines could a flag, like how Fix 5 draws text to the buffer, maybe have Fix 10 or something make all lines clipped.
Title: Re: Features Wishlist
Post by: JosJuice on February 26, 2012, 03:10:02 am
Could it be possible for programs compiled for Mirage with a custom icon to have all 16 rows?  I was trying it in wabbit and the bottom row of the icon is visibly cut off in Dcs.
I think Mirage's file format doesn't allow for a full 16x16 icon, but I could be wrong.
Title: Re: Features Wishlist
Post by: calc84maniac on February 26, 2012, 02:16:24 pm
Could it be possible for programs compiled for Mirage with a custom icon to have all 16 rows?  I was trying it in wabbit and the bottom row of the icon is visibly cut off in Dcs.
I think Mirage's file format doesn't allow for a full 16x16 icon, but I could be wrong.
That sounds right to me.
Title: Re: Features Wishlist
Post by: kindermoumoute on February 26, 2012, 04:29:10 pm
About this, is it possible to point icons to use them in program ?
Something like :
Code: [Select]
#Icon(HEX)=>Pic1
...
Copy(Pic1,L1,64)
Title: Re: Features Wishlist
Post by: Quigibo on February 26, 2012, 04:45:49 pm
That's not currently possible but its an interesting idea.  The image format is a bitmap minus the size bytes, so to draw it, you would have to copy the icon to another buffer that begins with Data(16,16) for DCS or Data(16,15) for MOS and then draw that new buffer using Bitmap().  However, this process could end up using more memory than just keeping another copy of the sprite in data.
Title: Re: Features Wishlist
Post by: willrandship on March 01, 2012, 12:11:21 am
Could it be possible for programs compiled for Mirage with a custom icon to have all 16 rows?  I was trying it in wabbit and the bottom row of the icon is visibly cut off in Dcs.
I think Mirage's file format doesn't allow for a full 16x16 icon, but I could be wrong.
That sounds right to me.
Yeah, MirageOS's dev info says the header is 15x15. If you want a good looking header for MOS and DCS, then design a 15x15 one with a shadow. The shadow gets clipped in MOS compiling, but stays for DCS compiling.
Title: Re: Features Wishlist
Post by: Runer112 on March 03, 2012, 02:40:37 pm
Not being able to nest preprocessor conditonals is making the development of YAAM (http://ourl.ca/15307) a little difficult. x.x Not having inline preprocessor conditionals adds difficulty as well, but that sounds like more of a stretch. I think that could be solved with regular preprocessor conditionals in macros, but that's probably far down the road.
Title: Re: Features Wishlist
Post by: Yeong on March 03, 2012, 05:31:41 pm
ability to line jump?
Title: Re: Features Wishlist
Post by: Runer112 on March 03, 2012, 05:33:48 pm
ability to line jump?

If you mean the ability to jump to a line while editing the program, that's not really Axe's job. That's much more appropriate for an external app, like zStart, which I believe already has label jumping.
Title: Re: Features Wishlist
Post by: Yeong on March 03, 2012, 05:35:36 pm
I mean something like what Grammer does with ln( .
Title: Re: Features Wishlist
Post by: Runer112 on March 03, 2012, 05:41:19 pm
I think that relative jumps were included in Grammer because jumping to a label requires searching the entire program for the label at run-time, which can take lots of time. However, jumps to labels in Axe will always be filled in at compile-time and will always be very speedy, so relative jumps aren't necessary for speed purposes. I suggest that you put a label where you want to jump to and Goto the label like a normal jump.
Title: Re: Features Wishlist
Post by: parserp on March 07, 2012, 07:43:02 pm
I think that it should have an option to turn on/off the little loading bar at the bottom.
As nice as it is, it just takes a lot more time to compile. :-\
Title: Re: Features Wishlist
Post by: Darl181 on March 07, 2012, 07:48:07 pm
I think that it should have an option to turn on/off the little loading bar at the bottom.
As nice as it is, it just takes a lot more time to compile. :-\
Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles
Its essentially the same speed, it takes almost the same amount of time to display the percentage bar as it did just displaying the percent.  However, this can be sped up by maybe 15% if I display nothing at all, but that's a bad experience for the end user since they feel like it freezes.  It wouldn't be that much faster anyway, its not like its double the speed or anything.
The bar itself shouldn't make that big of a difference, it's probably something in the compiler itself.
Title: Re: Features Wishlist
Post by: Yeong on March 07, 2012, 08:43:16 pm
ability to load only part of the appvar instead of whole appvar.
Title: Re: Features Wishlist
Post by: leafy on March 07, 2012, 09:58:23 pm
TBO_Yeong if you dont't have enough memory to load the entire appvar, an alternative is to read the appvar from archive directly using Y0-Y9 and just copying what you want into free ram.
Title: Re: Features Wishlist
Post by: Runer112 on March 07, 2012, 10:33:20 pm
I believe what he means is including only part of OS files at compile-time.

Edit: I guess I should ask though, can anyone imagine a situation in which this would be useful? Because I'm having trouble doing so, and taking up application space for a feature that's not going to be useful to most people isn't the best idea.
Title: Re: Features Wishlist
Post by: geekygenius on March 08, 2012, 01:15:38 am
This is more for the parser, but it would be nice if it had an "auto-run" option for streamlined testing/development.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 08, 2012, 01:31:57 am
Heya geekygenius and welcome to the forums. :D
Title: Re: Features Wishlist
Post by: C0deH4cker on March 08, 2012, 10:41:07 am
zStart recently added this. Just edit the program and press ON+Trace for normal compile, run, and return to program editor, or ON+Zoom to zoom compile, run, and return to program editor.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on March 13, 2012, 10:52:28 pm
Sorry for being off-topic, but  I just noticed that this topic has reached 3000 replies. O.O (almost half of the infamous number thread in the spam section)

Congrats Quigibo for giving the 8x community another kickstart in the past 2 years. :d
Title: Re: Features Wishlist
Post by: Juju on March 14, 2012, 12:04:47 am
What? 3000? There's no way that can be right!

Congrats Quigibo!
Title: Re: Features Wishlist
Post by: Deep Toaster on March 14, 2012, 12:31:45 am
It's over 9000! Over three.

Still, that definitely makes it the most popular topic here (except that ridiculous "Count to 8000 (http://www.omnimaga.org/index.php?topic=-1425.0)" thread from the old forum). Axe has done so much for us :D
Title: Re: Features Wishlist
Post by: Quigibo on March 14, 2012, 03:57:59 am
Thanks guys!  I know my activity here has been pretty low over the last few weeks, I've been really busy with interviews and job search related tasks for after graduation.  But despite this, I've slowly added about 10 new bug fixes and features over the last month so I'm almost ready for another release.  I'll be more active once I decide on a job offer in a few days :)  Boy, this is such a difficult and important decision, more so than colleges.
Title: Re: Features Wishlist
Post by: Darl181 on March 16, 2012, 06:22:13 pm
Request: ability to not show warning about program size exceeding the limit.
Or have it show on the second pass?
Title: Re: Features Wishlist
Post by: Quigibo on March 17, 2012, 06:06:04 pm
It should only display the warning after the 2nd pass has finished.  Are you saying that its been showing on a different pass?
Title: Re: Features Wishlist
Post by: Darl181 on March 18, 2012, 01:34:58 am
No, I was wondering if it could so the coder doesn't need to press the extra button each time.  Tho I can see how it can be helpful.. hence the request for an option :)

Or, maybe don't display it if Fullrene/Crabcake is being used?
Title: Re: Features Wishlist
Post by: Hayleia on March 18, 2012, 05:06:21 am
I know it has been requested many times and you answered "It is not any slower than the old method" but could you add an option to disable the progress bar while compiling ? I compiled Pokemon with 1.0.5 and with 1.1.2 and it takes longer with 1.1.2 (or maybe I counted faster :P).

(I recorded gifs but they have to start at the same time if you want to compare speed).

(http://www.omnimaga.org/index.php?action=dlattach;topic=9844.0;attach=12200;image) (http://www.omnimaga.org/index.php?action=dlattach;topic=9844.0;attach=12201;image)
Title: Re: Features Wishlist
Post by: Darl181 on March 18, 2012, 12:15:11 pm
It might help to keep in mind that there's other changes in the parser too that could cause the slowdown, not just the progress bar. ;)
Title: Re: Features Wishlist
Post by: Quigibo on March 18, 2012, 05:20:08 pm
Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was.  However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts.  It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.

And Darl, I see what you mean now.  Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after.  That's a good idea, I'll add this in the next update.
Title: Re: Features Wishlist
Post by: Freyaday on March 18, 2012, 06:14:28 pm
Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was.  However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts.  It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.

And Darl, I see what you mean now.  Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after.  That's a good idea, I'll add this in the next update.
I wouldn't remove the Zoom option. It's useful for checking to see if the bug was caused by the peephole ops.
Title: Re: Features Wishlist
Post by: Runer112 on March 18, 2012, 06:23:37 pm
Hmm... I guess I did have it update twice as often to make it smoother, so I can reduce the updating a little more to be like how it was.  However, I was actually thinking of optimizing the peephole opts into a lookup-table so that it performs significantly faster than the current linear search through all the opts.  It might even be possible to compile at nearly the same speed as the zoom option, in which case I could remove that feature, but that's optimistic, we'll see.

And Darl, I see what you mean now.  Since the size is now computeable during the first pass, I can show the message during the 2nd pass rather than after.  That's a good idea, I'll add this in the next update.
I wouldn't remove the Zoom option. It's useful for checking to see if the bug was caused by the peephole ops.

Ideally, there will eventually be no bugs caused by the peephole optimizer system. Not having to handle both compilation types would save size as well, allowing for new features. :)
Title: Re: Features Wishlist
Post by: Runer112 on March 18, 2012, 11:09:03 pm
Why can't custom constant names start with a lowercase letter? I feel like the reason for not allowing this was only to deal with binary numbers being represented as starting with b, but they aren't any more.


EDIT: Oops, didn't even notice the double post. x.x
Title: Re: Features Wishlist
Post by: Quigibo on March 18, 2012, 11:52:27 pm
Why can't custom constant names start with a lowercase letter? I feel like the reason for not allowing this was only to deal with binary numbers being represented as starting with b, but they aren't any more.

There isn't a syntax reason.  Mostly, it allows me to use them for other purposes in the future if I ever decide on a use them (such as low level register access, low or high byte access for variables, tables, etc.

To bring back another issue, I am basically going to have to write my own assembler or part of an assembler to build binary trees and hash tables because otherwise it would take forever to code it by hand and have to change every time I add new things to the lists.  But it should be fun.  I'll probably use python since it can do that kind of stuff with just a day or two of coding.  Ignore this statement if you have no idea what I'm talking about, but the biggest part of the compiling time is searching through lists, and this should make that faster.
Title: Re: Features Wishlist
Post by: Runer112 on March 19, 2012, 04:59:08 pm
A Fix command to allow writing text to the 96th column could be nice. [set 4,(iy+$24)] Unfortunately, we're out of 1-digit Fix codes. D:
Title: Re: Features Wishlist
Post by: calcdude84se on March 19, 2012, 05:06:24 pm
Is there any reason against using letters or other characters for Fix codes?
Title: Re: Features Wishlist
Post by: Runer112 on March 19, 2012, 05:10:18 pm
Quigibo could really make whatever Fix codes he so desired. So letters or 2-digit fix codes are both possible. The question is if he wants to add them, and if so, will users be able to remember them?
Title: Re: Features Wishlist
Post by: calc84maniac on March 19, 2012, 05:17:02 pm
Wouldn't 2-digit Fix codes break the syntax that sets multiple Fix settings at once? Or was that syntax removed at some point?
Title: Re: Features Wishlist
Post by: Runer112 on March 19, 2012, 05:20:08 pm
It appears to still exist... I guess it would have to be removed. Honestly there's no real point to it, all it does is save a few bytes in the source.
Title: Re: Features Wishlist
Post by: Freyaday on March 19, 2012, 07:10:29 pm
It's a pain to type it out. I'd go with letting Fix [letter], myself.
Title: Re: Features Wishlist
Post by: calc84maniac on March 19, 2012, 07:14:18 pm
In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #r turn the option off. But that would definitely break compatibility now :P
Title: Re: Features Wishlist
Post by: Freyaday on March 19, 2012, 07:17:41 pm
In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #r turn the option off. But that would definitely break compatibility now :P
Now that you mention it, yeah. GAH compatibility. :P
Title: Re: Features Wishlist
Post by: Runer112 on March 19, 2012, 07:18:43 pm
In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #r turn the option off. But that would definitely break compatibility now :P

What if the old syntax was left in for compatibility, but a new syntax of Fix LETTER / Fix LETTERr was added? Letters might be easier to remember than numbers anyways.
Title: Re: Features Wishlist
Post by: Freyaday on March 19, 2012, 07:37:02 pm
In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #r turn the option off. But that would definitely break compatibility now :P

What if the old syntax was left in for compatibility, but a new syntax of Fix LETTER / Fix LETTERr was added? Letters might be easier to remember than numbers anyways.
I like that!
Title: Re: Features Wishlist
Post by: calc84maniac on March 26, 2012, 10:55:17 pm
It would be nice if a negation followed by an addition was auto-optimized as a subtraction.

For example, ⁻(expr1)+(expr2) should be compiled as
Code: [Select]
 ;expr1 evaluate here
  push hl
  ;expr2 evaluate here
  pop de
  or a
  sbc hl,de

A more optimized example would be something like ⁻(expr)+A, like so:
Code: [Select]
 ;expr evaluate here
  ex de,hl
  ld hl,(axv_A)
  or a
  sbc hl,de

And of course, the classic subtract-HL-from-constant, like ⁻+96
Code: [Select]
 ex de,hl
  ld hl,96
  or a
  sbc hl,de
Title: Re: Features Wishlist
Post by: jacobly on March 26, 2012, 11:10:04 pm
Select( is useful for saving values around an expression, but it does not allow saving values around a block of code.  It would be nice if there were a block statement that saved variables on the stack.

For example:
Code: [Select]
:Save A,B,C
:
:End
would save A, B, and C and restore their values at the End.

It would also be useful to have:
Code: [Select]
:Save A,B,C
:
:End C,A,B
which would store whatever the value of A is at the beginning of the block, to C at the end of the block, etc.

Hopefully, making it a block statement allows you to disallow jumps and make Return work correctly, like with For(EXPR).

Also, some optimization-related requests:

For(Xʳ) or For(X)ʳ which would loop X^256 times (More optimized than For(X^256)).

[alternative to calc84maniac's post]
A operator that performs "reverse-subtract".  For example A-ʳB is the same as B-A.  This is useful when you want something like A-(B*2) which can be replaced with the more optimized B*2-ʳA.  This might also be useful for the other order-dependent operators.
Title: Re: Features Wishlist
Post by: Runer112 on March 28, 2012, 04:56:41 pm
Variables can move around in RAM, so I believe that Axe should have built-in access to asm_data_ptr1 and asm_data_ptr2 for pointer storage. Eiyeron had big problems with this here (http://ourl.ca/15195/294159), but the solution is as simple as having variables that point to these address to hold OS variable pointers. However, I would not expect the average Axe user to figure this out and know to add something like ?84EB?°V1 to their program and then use that custom variable.

So the solution should be as simple as having two default Axe variables that point to asm_data_ptr1 and asm_data_ptr2. I would suggest Y1T and Y2T; they're literally perfect. They're in a menu right next to their closest relatives, the archived variable pointers. And they share similar names, except with an added T for "Tracker." You could even have X1T and X2T point to asm_sym_ptr1 and asm_sym_ptr2. The only Axiom I know of that uses these as Axiom variables (MemKit) would not only still work, but it would work better.


EDIT: Fixed the second copy of the suggested variables (the sym pointers) to be X variables as they're supposed to be. I hope this didn't cause too much confusion.
Title: Re: Features Wishlist
Post by: Quigibo on March 28, 2012, 08:50:49 pm
Hmm... I'm not familiar with asm_data_ptr1 or asm_data_ptr2, I've never used them.  Can you explain a bit more how they work?  I can't find them on WikiTI.
Title: Re: Features Wishlist
Post by: Runer112 on March 28, 2012, 08:53:00 pm
Whenever variables are rearranged in RAM (for instance, deleting any variable that's not the last variable in RAM), the pointers at these two locations are adjusted according to where the variable they point to/into has moved. asm_sym_ptr1 and asm_sym_ptr2 act similarly, except they track VAT entries.
Title: Re: Features Wishlist
Post by: BlakPilar on March 31, 2012, 12:40:25 pm
Would it be possible to have something like a dictionary in Axe? That is, unless something like that already exists.
Title: Re: Features Wishlist
Post by: Builderboy on March 31, 2012, 01:43:41 pm
What do you mean by dictionary?  Like a list of all Axe commands?
Title: Re: Features Wishlist
Post by: BlakPilar on March 31, 2012, 01:50:47 pm
No, I mean like in C#/.NET you can do something like Dictionary<string, int> d; and you can add values where every string entered has a corresponding integer value. Like if you did d.Add("hi", 7); every time you tried to get the value of "hi" from the dictionary (by doing d["hi"]) you would get 7.
Title: Re: Features Wishlist
Post by: Runer112 on March 31, 2012, 02:16:52 pm
Honestly I'm not sure this (probably large) feature is worth adding... It's a pretty high-level feature, and Axe is a pretty low-level language. A big issue I see is that it would require dynamic memory allocation for adding entries, and dynamic memory allocation does not work terribly well on our platform. Another issue I see is that Axe is a type-less language, so it would be challenging to properly handle the different types the dictionary could contain (it doesn't have to be <string, int>). Also, I'm not really sure what applications it would have to most users. Axe's main design purpose was to make games, whereas this sounds more like a feature that complex utilities would use.

The final reason why I don't believe it would be worth the size/difficulty of adding: if you really need a dictionary, you could actually implement it yourself in Axe. Since you're making it yourself and know what data types it will contain, that passes the hurdle of a type-less language keeping track of types. If you know it won't pass a size of 768 bytes, you could even skip the dynamic memory allocation and throw the dictionary into L₁ or L₃. But if you do need the dynamic memory allocation, you could still do it by putting the dictionary into an appvar and using MemKit to resize it as necessary when adding/removing entries.
Title: Re: Features Wishlist
Post by: BlakPilar on March 31, 2012, 07:09:35 pm
Alright. I was thinking about it for a bit today and I could really only think of one instance where I could use a dictionary, but I could just as easily done something else.
Title: Re: Features Wishlist
Post by: Darl181 on April 06, 2012, 05:25:34 pm
How about Pt-Mask(X,Y,PicF,PicB[,Buff]) ?
This could allow for some flexibility, ie with small variations you can re-use one part to save space.


Also bump for non-8*8 sprite drawing (read: 4*4) <_<
Title: Re: Features Wishlist
Post by: Deep Toaster on April 07, 2012, 10:52:35 am
Aren't they bitmaps then?
Title: Re: Features Wishlist
Post by: Darl181 on April 07, 2012, 02:55:21 pm
What I mean is instead of Pt-Mask only looking 8 bytes forward, you would be able to tell it where the second sprite is.
Title: Re: Features Wishlist
Post by: Runer112 on April 07, 2012, 03:16:09 pm
The Pt-Mask() routine is already really tight on register usage. Keeping track of another 16-bit value would be difficult and would require a pretty fair amount of restructuring and added size/slowness to the routine. And I feel that using non-sequential front and back sprites is not a common occurrence, so doesn't warrant this restructuring.

If you really need functionality like this, you could implement it yourself with a subroutine that copies the two 8-byte sprites to a sequential 16-byte section of RAM and then calls Pt-Mask() routine.
Title: Re: Features Wishlist
Post by: Darl181 on April 15, 2012, 01:50:44 am
Ok, how about this...
Two (sort of, more like 4) requests :P

1) a signed Disp, so numbers >32768 would display the respective negative number.  Ie instead of 65472 it would print  -   64 , prolly requiring six spaces to work in instead of the normal five.  Or maybe even have the negative sign next to the topmost digit, if it's smaller code-wise ;D
1a) something similar for Text()
1b) support for one-byte numbers, maybe check the syntax at compile-time?

2) a Disp that advances only as many digits as the number needs

They would all be optional, so the existing commands aren't changed.

E: changed "bit" to "byte" >.<
Title: Re: Features Wishlist
Post by: Hayleia on May 06, 2012, 09:30:22 am
Why not adding in the Commands.html the size of each routine and the size of each routine call ? :D
Title: Re: Features Wishlist
Post by: Runer112 on May 06, 2012, 11:51:44 am
Why not adding in the Commands.html the size of each routine and the size of each routine call ? :D

That actually might be a pretty good idea, since people always ask about this information and it's nowhere to be found. Perhaps speed data could be added as well? My only concern is that theses would complicate the otherwise fairly clean and simple command list.
Title: Re: Features Wishlist
Post by: Hayleia on May 06, 2012, 11:57:55 am
Perhaps speed data could be added as well?
Yes, I thought about it but forgot to post it >.<

My only concern is that theses would complicate the otherwise fairly clean and simple command list.
For now there are two columns: "Command" and "Description". Maybe three little columns could be added, like "routine size", "call size" and "cycles" ?
Title: Re: Features Wishlist
Post by: MGOS on June 19, 2012, 09:20:18 am
Maybe add that programs compiled to Axe Fusion won't crash when axe isn't installed. E. g. let it return to homescreen when the axe app can't be found.
Title: Re: Features Wishlist
Post by: Runer112 on June 19, 2012, 04:39:28 pm
Maybe add that programs compiled to Axe Fusion won't crash when axe isn't installed. E. g. let it return to homescreen when the axe app can't be found.

This is semi-supported. If Axe is not found, the program should display a message that Axe was not found and exit cleanly. However, programs compiled as Axe Fusion currently don't check that the version of Axe found actually supports Axe Fusion, which will result in a crash when the program tries to reference nonexistent command vectors in Axe.

If the program crashes and Axe 1.1.2 exists on the calculator, then you should mosey on over to the Bug Reports (http://ourl.ca/4072) thread. :P
Title: Re: Features Wishlist
Post by: MGOS on June 20, 2012, 12:24:46 am
No, it only wasn't the latest version of axe on that calc and he accidentally ran an axe fusion program.
Title: Re: Features Wishlist
Post by: Runer112 on June 20, 2012, 10:31:41 am
Okay, that's a known issue. Hopefully that will be fixed in the next version of Axe. :)
Title: Re: Features Wishlist
Post by: Hayleia on July 09, 2012, 01:07:31 pm
I am quoting what I asked in the wrong topic so my feature request is actually in the Features Wishlist.

Would it be possible to have equates ?
I mean that for example if I write this
   test equ {V+17}
each time the parser hits the word "test", it replaces it with "{V+17}" before translating it into asm.

(note that here, V+17→°test would not work since V+17 is not constant)
EDIT: Oh, I see, that way if FOO translated to {V+17}, you could do something like 23→FOO and FOO→X and both would be valid statements.

It would still be no different than using {V+17} everywhere though, since FOO wouldn't actually exist. It'd be more like a macro than anything.
Yes that's it. It would not save space in any way. It is just so I can easily see who is who in my appvar. Because I have wood, stone and apples (among others) and having this
   {V+17}^^r equ wood
   {V+19}^^r equ stone
   {V+21}^^r equ apple
would be of a great help for me to understand my code easier. So would it be possible ?
Title: Re: Features Wishlist
Post by: Hayleia on July 16, 2012, 02:59:29 pm
Double posting, with another feature request:
Could the possibility to declare constants as follow be added ?
  18→°Var1+1→°Var2+5→°Var3
Title: Re: Features Wishlist
Post by: Freyaday on August 10, 2012, 12:19:16 am
Could the UnArchive command be modified to return the address of the unarchived var if it was successful, and 0 if unsuccessful?
Title: Re: Features Wishlist
Post by: Freyaday on September 10, 2012, 12:49:31 am
Ability to display a string of tokens?
Title: Re: Features Wishlist
Post by: pimathbrainiac on October 31, 2012, 09:53:44 am
How about a larger app max compile size
Title: Re: Features Wishlist
Post by: Darl181 on October 31, 2012, 10:13:12 am
Apps are fixed at 16384 bytes unfortunately :/
Have you tried crabcake or fullrene? With those you can make programs upwards of 20000 bytes.
Title: Re: Features Wishlist
Post by: Hayleia on October 31, 2012, 12:42:51 pm
Apps are fixed at 16384 bytes unfortunately :/
Except if multiple page apps are supported :D
Even if other pages only have data, that would be great especially for my games in which I have a lot of data :P

How about a larger app max compile size
As Darl181 said, if your program still fits in the RAM, you can use CrabCake and Fullrene.
If you need a lot of space though (read, more than 24 000 bytes), you can use Matref's Axiom (http://ourl.ca/17182/319163) which will allow you to virtually have multiple page apps by putting all your code in separate apps and just compile a calling program that will take care of page swapping :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 31, 2012, 03:22:15 pm
Question: With Quigibo gone, has somebody taken over Axe development or is it done with, aside from optimizations and maintenance by Runer112?
Title: Re: Features Wishlist
Post by: Sorunome on October 31, 2012, 04:10:12 pm
Question: With Quigibo gone, has somebody taken over Axe development or is it done with, aside from optimizations and maintenance by Runer112?
As far as I know runer wanted to add a little bit of stuff
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2012, 02:00:00 pm
Also for the app size, I think multiple pages apps was incredibly hard to implement, but in the meantime you can simply keep all your data external and try to work around a 16 KB limit for code. It is possible to optimize your code in every way possible to have everything be controlled through data or close. However I think there was a way to have up to 40 KB of code, although I'm unsure where I read about it anymore.
Title: Re: Features Wishlist
Post by: Hayleia on November 04, 2012, 02:04:48 pm
in the meantime you can simply keep all your data external and try to work around a 16 KB limit for code
This is very hard to do with text data. You must calculate how much bytes you have in your text (knowing that uppercases take 1 byte and lowercases take 2 bytes) and you can't easily access the nth string without copying all the data to RAM :(
But for every other kind of data, it is very possible :)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2012, 02:10:30 pm
That sucks. I wish text data was as easy to deal with in Axe/ASM as it was in TI-BASIC x.x (where you simply needed to get the string lenght with one command)
Title: Re: Features Wishlist
Post by: squidgetx on November 04, 2012, 02:14:06 pm
Yeah, I think it's pretty much unavoidable though. Strings by nature are really funky entities, and a lot of cs/education professionals think that higher level languages like java shouldn't be termed as intro languages because they try to make an abstraction of strings like TI-BASIC, and so kids learning about them don't realize how complicated they can be. It's really easy to write a O(n^2) algorithm for strings when they could be linear just because of how annoying it is to find the length of a string (for example)
Title: Re: Features Wishlist
Post by: Hayleia on November 04, 2012, 02:14:27 pm
That sucks. I wish text data was as easy to deal with in Axe/ASM as it was in TI-BASIC x.x (where you simply needed to get the string lenght with one command)
Well there is a command for that... as long as the text data is in RAM -.-°
But if you try to put your data outside (for example in an archived appvar), you have to deal with those difficulties :(
It is not hard, it is just too much brain work :P
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 04, 2012, 02:25:06 pm
Ouch that sucks then X.x. At least in BASIC you just used XCOPY to copy the program in RAM then set the variable to a certain value so it scans the program and store the corresponding string into Str1 or ans and then  you were set.
Title: Re: Features Wishlist
Post by: Builderboy on November 04, 2012, 02:30:57 pm
in the meantime you can simply keep all your data external and try to work around a 16 KB limit for code
This is very hard to do with text data. You must calculate how much bytes you have in your text (knowing that uppercases take 1 byte and lowercases take 2 bytes) and you can't easily access the nth string without copying all the data to RAM :(
But for every other kind of data, it is very possible :)
I just wanted to point out that if we are working with character data like Axe strings, uppercase and lowercase both take a single byte.
Title: Re: Features Wishlist
Post by: Hayleia on November 05, 2012, 03:03:37 am
I just wanted to point out that if we are working with character data like Axe strings, uppercase and lowercase both take a single byte.
*.*
Well then, I think I'll start putting my text data outside of my programs :D
(yeah, I was being stupid, the thing that takes 2 bytes is the lowercase token, not the lowercase character)
Title: Re: Features Wishlist
Post by: aeTIos on November 05, 2012, 09:41:05 am
I didn't notice that Quigibo was gone? D:
Title: Re: Features Wishlist
Post by: squidgetx on November 11, 2012, 05:49:23 pm
Feature Request: ReAlloc of the r1-r6 variables?
Title: Re: Features Wishlist
Post by: Builderboy on November 24, 2012, 04:18:42 pm
AND-ed sprites, white lines, invert lines, and white rectangles would all be awesome!
Title: Re: Features Wishlist
Post by: Deep Toaster on November 29, 2012, 01:39:42 am
Compiler feature request: having a "variable scanner" baked into Axe Parser (preferably with a toggle so it doesn't take time when you don't want it to) that keeps track of and shows the variables used in the project being compiled.
Title: Re: Features Wishlist
Post by: Freyaday on November 29, 2012, 02:45:40 am
#ifdef and #!ifdef
Title: Re: Features Wishlist
Post by: Runer112 on November 29, 2012, 09:02:03 am
#ifdef and #!ifdef

I asked for these a while ago, and Quigibo's response was the →→ operator. Is was much simpler code-wise to implement and has a simpler syntax, and we agreed that most of the time you need to know whether a constant has been defined or not, it's so you can define it if it isn't.

Although I think it would be nice to have these more general constructs eventually, hopefully the current solution will work for now. I don't think I have the familiarity with the Axe project to pull off feature as rooted in the compiler as this yet, unfortunately.
Title: Re: Features Wishlist
Post by: Freyaday on November 29, 2012, 04:44:15 pm
What's →→ ?
Title: Re: Features Wishlist
Post by: leafy on November 29, 2012, 04:49:55 pm
If you haven't defined a static variable earlier, you can use →→ to store a constant into that static variable. It's ignored if the static variable does already have a value, so you can use it as kind of #ifdef sort of thing
Title: Re: Features Wishlist
Post by: Freyaday on November 29, 2012, 07:24:52 pm
What about subroutines?
Title: Re: Features Wishlist
Post by: Builderboy on December 02, 2012, 06:14:45 pm
My request is to move the interrupt table to 0x9200 (tableStuff) and out of L2.
Title: Re: Features Wishlist
Post by: Matrefeytontias on December 07, 2012, 05:43:33 am
My request is someway to do like in Asm :
Code: [Select]
.db labelBecause the only way to put a byte at a precise location is Asm(byte), and this syntax doesn't support Llabel.
Title: Re: Features Wishlist
Post by: Runer112 on December 07, 2012, 10:40:00 am
Matrefeytontias, what would be the purpose of that? Adding a syntax for including label address as inline data seems like an extremely specific thing (one that I'm not even sure I can think of a use for).

Eventually I would like to allow for including any constant expression in the middle of an Asm() block, so you could do something like Asm((LLabel)). But until such a feature is added, is there perhaps a way that you can do what you're trying to do without it?
Title: Re: Features Wishlist
Post by: Matrefeytontias on December 07, 2012, 10:57:45 am
I actually have a specific use for that : make an AP-enabled header for my AxeDCS axiom. See http://dcs.cemetech.net for what's an AP program.

It needs a specific DCS header, different to the one provided by Axe - and it includes a label address, the start of the AP section.

I tries to figure all the possible ways, and that's the only one that works.
Title: Re: Features Wishlist
Post by: Sorunome on December 08, 2012, 02:24:07 am
Feature request: Somehow make it able to use more than 2 byte variables :D
Title: Re: Features Wishlist
Post by: Hayleia on December 08, 2012, 07:11:07 am
Feature request: Somehow make it able to use more than 2 byte variables :D
There is already a lib for adding, substracting and displaying 3 and 4 bytes numbers (http://ourl.ca/4129/155369) but I agree that native support for all operations in 3 or 4 bytes would be great :D
Title: Re: Features Wishlist
Post by: Runer112 on December 08, 2012, 11:05:03 am
That would be very hard to do, I would imagine. Axe is pretty much entirely built to work with 16-bit values. But just wondering, what kind of things would you want to do with 32-bit values?
Title: Re: Features Wishlist
Post by: Sorunome on December 08, 2012, 01:03:11 pm
add, subtract(, multiply, devide), display, compare
Title: Re: Features Wishlist
Post by: Hayleia on December 08, 2012, 01:08:12 pm
add, subtract(, multiply, devide), display, compare
Substract and display are already present ;)
But multiply, divide and compare are still missing :P

That would be very hard to do, I would imagine. Axe is pretty much entirely built to work with 16-bit values.
Don't try to tell me something is impossible for you, I won't believe you :P

But just wondering, what kind of things would you want to do with 32-bit values?
I can't even imagine all the physics Builderboy could do if he had the precision offered by 3 and 4 bytes.
Title: Re: Features Wishlist
Post by: Builderboy on December 08, 2012, 04:29:59 pm
The problem is, is that the z80 is a 16bit processor by nature, and consequently doing anything with a bit length greater than 16 require a lot more custom code. 
Title: Re: Features Wishlist
Post by: Freyaday on December 10, 2012, 11:01:04 am
I know jacobly made some pretty fast floats.
You can get the Axiom here. (http://ourl.ca/13650)
Title: Re: Features Wishlist
Post by: squidgetx on December 10, 2012, 11:26:51 pm
Feature request: ouput symbol table? It's a little obscure, but I don't think it'd be too hard to implement; right? (One use could be for calling app routines from an external program.) As an option, the compiler could (after compilation) output as axe source named constants/variables all the label address offsets and static pointer locations. I know there's not a lot of room left in the app but...
Title: Re: Features Wishlist
Post by: Freyaday on December 11, 2012, 10:57:33 am
What's an output symbol table?
Title: Re: Features Wishlist
Post by: squidgetx on December 11, 2012, 11:23:33 am
It's more of a compiler feature than a programming feature. Basically, I'm asking for the option to be able to see the addresses of all the symbols in the source (that is, labels and static pointers like GDB1). The compiler already has to keep track of them all, so I'm hoping it's not too hard to finagle an output file somehow (or even display in the compilation screen).
Title: Re: Features Wishlist
Post by: Runer112 on December 11, 2012, 11:49:04 am
iIs there any particular reason this would really be needed? The main reason I can think of is if you want an application to have routines that can be called from an external program, but in that case you should really be using a jump table anyways, and I think it's simple enough to figure out where that would start in an application.
Title: Re: Features Wishlist
Post by: Hayleia on December 11, 2012, 12:22:25 pm
The main reason I can think of is if you want an application to have routines that can be called from an external program, but in that case you should really be using a jump table anyways, and I think it's simple enough to figure out where that would start in an application.
Or he can use this (http://ourl.ca/17182/319163) :P
Title: Re: Features Wishlist
Post by: squidgetx on December 11, 2012, 12:41:19 pm
Yeah, those would also work. They're just less direct, and I feel like it'd be useful for all kinds of interfacing with asm code, although I guess if you're adding the ability to inline constants in Asm() then it's not really needed.
Title: Re: Features Wishlist
Post by: Sorunome on December 13, 2012, 07:03:47 pm
i know, this is bumping a old feature wish, but i'm doing it as it is now back into development (axe)
so
Multi-page apps!
Everything is stored into page one
exept
[DATA]->nGDB1 is stored in page n, if n is not specified it stores on page 1, so the other pages are only data, do you get what i mean? :D
Title: Re: Features Wishlist
Post by: jo-thijs on December 19, 2012, 09:16:50 am
I'm new here and I've got 3 feature requests:
1) a compile mode (some sort of debug mode) in which axe adds before every possible function that can result in a loop, like goto, while, repeat, for, sub, ... a code that terminates the program if a specific button is pressed. I know this is something I can build in my program myself very easily, but it is annoying to remove it afterwards in my finished version.
2) someway to test multiplayer games with 1 grm and optional a computer. I've got no idea how this could be realised, mayby by making a small program on the pc that sends a byte predefined byte when you press a key on the keyboard? The thing is, my friends don't want to play my games until I've tested them and so I can never play multiplayer games.
3) making the function-name-changing thing that axe does optional, it is a great feature, but I've noticed that it slows down scrolling through a program a lot, so I clear my ram always after compiling a game to spead it up again.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on December 20, 2012, 12:33:22 am
Heya and welcome here :D

And yeah about 2 this can be difficult to test multiplayer games. I myself am lucky because I know one person IRL that was into calc stuff at one point and actually frequents the forums here, but otherwise that can be hard. However this might be kinda hard to implement D:

I have one suggestion for future Axe versions too by the way (even though I don't code anymore): An option to disable progress bars when compiling. Since they were added, Axe seems to take an incredibly long while to compile anything (like 5 times longer).

Supersonic Ball:
Axe 1.1.0: 6 seconds (final version with no progress bar)
Axe 1.1.2: 9 seconds
Axe 1.2.1a: 8 seconds (Note that I tried this version after writing this post and noticed the slight speed improvement)


EDIT: It turns out that the speed was improved by 1 seconds at least in the latest version and that most of the speed decrease was due to Axe compiling being more and more complex. Because Axe 0.2.6 compiles Supersonic Ball in 1 second. O.O
Title: Re: Features Wishlist
Post by: Runer112 on December 20, 2012, 01:12:14 am
I'm new here and I've got 3 feature requests:
1) a compile mode (some sort of debug mode) in which axe adds before every possible function that can result in a loop, like goto, while, repeat, for, sub, ... a code that terminates the program if a specific button is pressed. I know this is something I can build in my program myself very easily, but it is annoying to remove it afterwards in my finished version.
2) someway to test multiplayer games with 1 grm and optional a computer. I've got no idea how this could be realised, mayby by making a small program on the pc that sends a byte predefined byte when you press a key on the keyboard? The thing is, my friends don't want to play my games until I've tested them and so I can never play multiplayer games.
3) making the function-name-changing thing that axe does optional, it is a great feature, but I've noticed that it slows down scrolling through a program a lot, so I clear my ram always after compiling a game to spead it up again.

Hello, new person! I hope Axe has been useful for you, but let's see if we can't make it better:

1) I have plans to eventually add some sort of safety mode in which pressing ON during execution of an Axe program will immediately exit it. I think this should cover what you wanted.

2) Performing arbitrary linking between a computer and a calculator is extremely difficult. Also Axe uses the serial port for linking, and I'm not even sure it's possible to reprogram a silverlink cable to work with that. So unfortunately I don't think this feature will ever be added. If you want to test linking, I suggest loading up more than one virtual calculator in an emulator that supports virtual linking.

3) I agree that it should be optional, although I would disagree that it slows down scrolling by *a lot*. I'll add both an on/off toggle and speed improvement to my to-do list.
Title: Re: Features Wishlist
Post by: 133794m3r on December 20, 2012, 10:57:03 pm
I'm probably a crazy person. so please ignore this if I am one of those. The first pass I guess is where it converts it into assembler, and then the second is optimizations? Something I'd like is for it do another pass of peephole optimizations, but make it non-default so that if someone's crazy/really needs whatever additional  little things it can do, it'd be added, by holding some button, like Mode when compiling to make it do another round of optimizing/shrinking. Other than that, that's all that I can think of right now as far as my "would like to see" list. Also, I imagine that Axe is already using the "full" 15mhz on the ti-84s, but if it isn't, I'd love for it to start using it. I imagine it is(as the compile times are rather quick, for everything I've tested/wrote), but if not I'd love for it to be there.

One other thing that I'd love to have is for it to have the subroutines be able to return a value as the built in functions of the calculator/axe ones do. As this'd help make my code a tad bit more clean, there's already the option of giving subroutines variables, but being able to return one would be uber-awesome. I'm not even talking about passing around ptrs with mass amounts of memory, just some way to return a 2byte value would be uber-awesome/useful for people like me who are used to c.
Title: Re: Features Wishlist
Post by: Sorunome on December 20, 2012, 11:06:11 pm
For using full use the token 'Full' to enable full speed mode
and to return a value for a subroutine, just have the last line of it be like A+B and then you can do MYFUNC()+3->VARIABLE

And IIRC there is already such a thing - for without peephole-optimizations hit ZOOM instead of ENTER when compiling
Title: Re: Features Wishlist
Post by: Hayleia on December 21, 2012, 01:23:03 am
I'm probably a crazy person. so please ignore this if I am one of those. The first pass I guess is where it converts it into assembler, and then the second is optimizations? Something I'd like is for it do another pass of peephole optimizations, but make it non-default so that if someone's crazy/really needs whatever additional  little things it can do, it'd be added, by holding some button, like Mode when compiling to make it do another round of optimizing/shrinking. Other than that, that's all that I can think of right now as far as my "would like to see" list. Also, I imagine that Axe is already using the "full" 15mhz on the ti-84s, but if it isn't, I'd love for it to start using it. I imagine it is(as the compile times are rather quick, for everything I've tested/wrote), but if not I'd love for it to be there.
As Sorunome said, there is already a peephole optimizer. There is also the function #ExprOn if you really want to save space.
Axe uses 15 MHz when compiling on capable models, and if you want to use it in your progs, use Full.

One other thing that I'd love to have is for it to have the subroutines be able to return a value as the built in functions of the calculator/axe ones do. As this'd help make my code a tad bit more clean, there's already the option of giving subroutines variables, but being able to return one would be uber-awesome. I'm not even talking about passing around ptrs with mass amounts of memory, just some way to return a 2byte value would be uber-awesome/useful for people like me who are used to c.
Your routines always return a value but you don't know that. In short, they return the value of the last calculus.
Example, try writing this:
1
+2
→A
*2
→B

Then, you have 1+2 in A and A*2 in B, because this is in fact like this:
1
Ans+2
Ans→A
Ans*2
Ans→B

where "Ans" is the 16 bit register hl (and you can compress your code to 1+2→A*2→B).

So if you want your routine to return a value, just do something like that:

.code here
Routine()
→A
.code here

Lbl Routine
.code here
B
Return


Then your routine will return the value of B. Of course, instead of B, you can put r1*2+4 or 8, and instead of →A after the routine, you can put *4→F or i don't know, but what you asked for is already possible.
Title: Re: Features Wishlist
Post by: 133794m3r on December 21, 2012, 06:31:48 pm
Ah OK, well that's good to know then. I was talking about additional options, IE an option to make it do _even more_ optimizations. Instead of teh "faster" mode, I was talking about a slower mode, wherein it does _even more_ optimizations another pass or something. Also about the subroutines returning variables that's workable. Since I needed a way to do the InData that was actually working with data, not just strings. But since it seems to be workable, I'll be using it then. Thanks for the info everyone who's already said things here.


Edit:

Something else that I'd like to see as the main parser, is a Binanry string converter. It'd be the same as the >Hex command.


Something like

Exp>Bin

Then it'd convert it into a binary string. It'd be useful for the program I'm working on, I'm planning on writing a routine to do it, but I have no doubt that if it was in the main parser it'd be way faster. Anyway that's all I can think of right now.
Title: Re: Features Wishlist
Post by: squidgetx on December 21, 2012, 09:04:16 pm
The main compiler has only the two speed modes, slow and optimized or fast and unoptimized. The two passes aren't for optimization, so it's not like a third pass could be easily added for "extra optimization." (Well, maybe it could but it's just not how it's set up now. FYI the two passes are like this: first for the bulk of the code, second to fill in the symbol addresses (labels, pointers, etc.)
Title: Features Wishlist
Post by: Le solutionneur on December 22, 2012, 10:03:56 pm
I would personally add as a suggestion port Axe to allow to compile it for TI-83 calculators: as more and more projects are using it, it would be great to be able to use them on a TI-83 calculator!

It won't be easy though. For example, you'll need to emulate the safe ram areas by allocating them somehow, fix the rom calls and other stuff.

Would be great though :)

A Axe PC application would also be appreciated :)
Writing a program on a PC is faster than on a calculator (and less fear of loss of data).
Title: Features Wishlist
Post by: Sorunome on December 22, 2012, 10:28:36 pm
Maybe you could add to the list as feature request multi-pages app and as optimization suggestion lazy if-conditions
Title: Features Wishlist
Post by: Runer112 on December 22, 2012, 11:21:34 pm
I would personally add as a suggestion port Axe to allow to compile it for TI-83 calculators: as more and more projects are using it, it would be great to be able to use them on a TI-83 calculator!

This is a fairly large undertaking, so it's not exactly at the top of my priority list. It is on it, though.



A Axe PC application would also be appreciated :)
Writing a program on a PC is faster than on a calculator (and less fear of loss of data).

Just write programs in a program/web application that allows editing/saving 8xp files; for example, TI Program Editor, TokenIDE (http://www.ticalc.org/archives/files/fileinfo/433/43315.html), SourceCoder (http://www.cemetech.net/projects/basicelite/sourcecoder2.php), or IES (http://clrhome.org/ies/). Then you can either send them to an emulator or a physical calculator to compile and test them.



Maybe you could add to the list as feature request multi-pages app and as optimization suggestion lazy if-conditions

I haven't updated this list in forever, I have a personal list that I keep track of all of this stuff on now. The best place to suggest features will always be the Features Wishlist (http://ourl.ca/4057), which I regularly check and add any good ideas to my to-do list.

And short-circuit logic operators already exist as ? and ??.

*edit AOC* This post and a few other were in another topic. That's why Runer refers to the feature Wishlist topic in this post. He isn't crazy or anything (as far as I know :P)
Title: Re: Features Wishlist
Post by: Sorunome on December 23, 2012, 02:14:31 am
How about make the if-conditions lazy for extra speed?
Title: Re: Features Wishlist
Post by: Builderboy on December 23, 2012, 02:37:14 am
Really the only way to do that is to code it in yourself with multiple If Statements, as the AND and OR operators are bit-wise and not boolean
Title: Features Wishlist
Post by: TIfanx1999 on December 23, 2012, 11:56:37 am
I would personally add as a suggestion port Axe to allow to compile it for TI-83 calculators: as more and more projects are using it, it would be great to be able to use them on a TI-83 calculator!

It won't be easy though. For example, you'll need to emulate the safe ram areas by allocating them somehow, fix the rom calls and other stuff.

Would be great though :)

A Axe PC application would also be appreciated :)
Writing a program on a PC is faster than on a calculator (and less fear of loss of data).
I think if normal 83 support were to be added, (at some point) a pc side utility would be a must. You would be severely limited by size otherwise. In all honesty it would probably need to be a complete reworking more than a port... there are so many differences between the platforms. Many things that work in the current axe would not work on the 83 version at all or need a major overhaul to work properly.

*edit* Wow, didn't realize that this post was in the wrong topic (it should be in feature requests). XD gonna move this and a few other posts.
*Edit* Done. ;)
Title: Re: Features Wishlist
Post by: DJ Omnimaga on January 05, 2013, 12:57:08 pm
Yeah a 83/82 Stats version would need to be separate from the 83+ one. It would definitively be possible, though. Just with fewer features and more limited in memory for games (no archive). When people compile their games, some source code and data is often archived first.

The TI-83 regular edition is still quite popular in Europe, especially in France, because it was re-released in 2004 as the TI-82 Stats then updated in 2006 as the TI-82 Stats.Fr and later the TI-76.Fr which fully supports TI-83  ASM programs.
Title: Re: Features Wishlist
Post by: jo-thijs on January 20, 2013, 09:05:44 am
I've got 2 new feature requets:
1) automatically unarchive the source code if there was found an error in it while compiling
2) making an automatic optimlisation for anything of the form {L1+CONSTANT}, I use that whole the time and I think it would comprimise tons.

Also, it would be nice to implement in the zip file, some links to handy sites, like this community and all kinds of export sites. I've found some, but it took me some time.
And just in case it hasn't been reported yet, in the commands HTML, there is a part of the site that will always be covered by the used header, so it is best to insert some new lines at the beginning.
Title: Re: Features Wishlist
Post by: Runer112 on January 20, 2013, 10:18:13 am
I've got 2 new feature requets:
1) automatically unarchive the source code if there was found an error in it while compiling
2) making an automatic optimlisation for anything of the form {L1+CONSTANT}, I use that whole the time and I think it would comprimise tons.

Also, it would be nice to implement in the zip file, some links to handy sites, like this community and all kinds of export sites. I've found some, but it took me some time.
And just in case it hasn't been reported yet, in the commands HTML, there is a part of the site that will always be covered by the used header, so it is best to insert some new lines at the beginning.

1) I've been bothered by errors in archived programs a few times, so I see how this could be useful. I've added it to my to-do list.
2) The optimizer in general is a mysterious beast. I would love to add optimizations like that, I'm just not sure how easy it would be.

As for helpful links, agreed. And in regards to the commands file, what is being covered up? I see the header overlay, followed by a small amount of white space, followed by the first piece of actual content on the page (the System commands table).
Title: Re: Features Wishlist
Post by: Keoni29 on January 20, 2013, 10:57:54 am
How about ++EXP? How many times has this been requested?
Title: Re: Features Wishlist
Post by: Runer112 on January 20, 2013, 11:59:22 am
How about ++EXP? How many times has this been requested?

By EXP, I'm assuming you really mean {EXP}r? In which case, that's basically what {EXP}r++ is. The only difference is the return value, as this doesn't return either the old or new value of {EXP}r because it isn't optimal to do so.
Title: Re: Features Wishlist
Post by: jo-thijs on January 20, 2013, 01:24:51 pm
Thanks!
And for the commands html,
it seems to be internet explorer (9, not sure about this) specific, the problem isn't there in firefox or chroom.

EDIT: ie10 doesn't do it good as well.
Title: Re: Features Wishlist
Post by: Freyaday on January 20, 2013, 01:48:16 pm
jo-thijs, if you have zStart, or, I suppose, any app that will let you edit programs in Archive, Axe was recently modified to allow that hook to work, so pressing [PRGM] with an app like that installed will work now.
(Also, I recommend zStart in particular if you don't already have it. It's awesome ^^ )
Title: Re: Features Wishlist
Post by: jo-thijs on January 20, 2013, 01:56:04 pm
ok, thanks for the info!
but I still think that it would be usefull to add.
Title: Re: Features Wishlist
Post by: Freyaday on January 20, 2013, 04:22:33 pm
ok, thanks for the info!
but I still think that it would be usefull to add.
Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?
Title: Re: Features Wishlist
Post by: Runer112 on January 20, 2013, 04:34:07 pm
ok, thanks for the info!
but I still think that it would be usefull to add.
Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?

If zStart exists on the calculator, that would still be used to edit the program from archive.
Title: Re: Features Wishlist
Post by: pimathbrainiac on January 20, 2013, 04:38:20 pm
ok, thanks for the info!
but I still think that it would be usefull to add.

Hey, you should introduce yourself in the introduce yourself section of the forum! http://www.omnimaga.org/index.php?board=10.0
Title: Re: Features Wishlist
Post by: Freyaday on January 20, 2013, 04:45:11 pm
ok, thanks for the info!
but I still think that it would be usefull to add.
Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?

If zStart exists on the calculator, that would still be used to edit the program from archive.
Alright. Cool.
Title: Re: Features Wishlist
Post by: pimathbrainiac on January 20, 2013, 05:01:23 pm
How about the ability to update one pixel instead of the whole screen? (Ex. To make a fast Langton's Ant program)
Title: Re: Features Wishlist
Post by: Matrefeytontias on January 20, 2013, 05:55:08 pm
One byte (a group of 8 horizontal pixels) is far simpler to update than a pixel, so maybe it's possible.
Title: Re: Features Wishlist
Post by: Freyaday on January 20, 2013, 06:02:26 pm
One byte (a group of 8 horizontal pixels) is far simpler to update than a pixel, so maybe it's possible.
Maybe we could do Update(X,Y,dX,dY)?
Title: Re: Features Wishlist
Post by: pimathbrainiac on January 20, 2013, 06:04:55 pm
Maybe there should be a one byte option and a one sprite option.
Title: Re: Features Wishlist
Post by: willrandship on January 20, 2013, 06:35:23 pm
those are equivalent in axe, unless you mean bitmaps.

Partial updates would be awesome. It saves a lot of cpu time in not-so-fancy games.
Title: Re: Features Wishlist
Post by: Roboman on January 23, 2013, 03:03:46 pm
Even tiBASIC can update one byte at a time!!!
I will post screenie when i get home :3

basically create an axe program.
.derpy
:drawInv

then compile it and in a basic program
dispGraph
clrDraw
asm(derpy)
circle(0,0,5)

then u see that tiBASIC can update one byte at a time O.o


*EDIT
50th post!!!!!!!!!!! :love: *.* *.* *.* :angel: *.* *.* *.* :love:
Title: Re: Features Wishlist
Post by: GamerMX1248 on February 02, 2013, 03:07:11 pm
What I'd like to see is a way to put null characters (the same as [00]) into a string more easily than doing
Code: [Select]
"First"->Str1
"Second":[00]
"Third":[00]
You know, for using the fancy strDev( function. Maybe
Code: [Select]
"First*Second*Third"->Str1 where * is the imaginary 'i', Eulers 'E', pi, the degree symbol, or r. If it was used twice in a row, the symbol would show up normally like an escape character from any C like language
Or possibly:
Code: [Select]
"First"->Str1
"Second"[sup]r[/sup]
"Third"[sup]r[/sup]
where r simply adds a null character after a string.
Any of these would work for me
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 02, 2013, 03:31:20 pm
Well, your first code is wrong. You don't need these semicolons between each string and each [00]. Just do :
Code: [Select]
:"blah"→Str1
:"blah"[00]"blah"[00]"blah"[00]
.

Also, drawing triangles like rectangles would be awesome. I'm thinking about commands such as Triangle(x1,y1,x2,y2,x3,y3), XTriangle..., WTriangle....
Title: Re: Features Wishlist
Post by: shmibs on February 02, 2013, 09:57:47 pm
his code isn't wrong; it's just unnecessary. this suggestion seems a bit pointless, though. putting aside any easily typable character would confuse people as well as making it necessary to have THAT be inserted as a number value, and using a non-easily typed character wouldn't be helpful.

as for triangles, what would you want that for?
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 03, 2013, 03:33:00 am
I want to improve the 3D engine I made (a lib called VERTEX3D) by adding the support for solid surfaces. And for that, triangles are needed.
Title: Re: Features Wishlist
Post by: jo-thijs on February 03, 2013, 02:11:23 pm
I've got another 2 requests:
- making an option so that you can easily make screenshots of your game, I can't find any other way besides using emulators.
- the syntax +→ and -→ to add/substract an expression to/from a variable or position in memmory pointed to.
Title: Re: Features Wishlist
Post by: shmibs on February 03, 2013, 02:41:05 pm
if you want to take single frame screenshots, then an easy method would be to copy the contents of the screen buffer into a Pic variable (or into two, if you want greyscale). if you want animated screenshots on calc, then both limitations of storage and the amount of processing power required would make it not feasible.

for the +→ idea, that might actually be nice =)/me throws in a backing vote
Title: Re: Features Wishlist
Post by: Runer112 on February 03, 2013, 02:53:37 pm
I've got another 2 requests:
- making an option so that you can easily make screenshots of your game, I can't find any other way besides using emulators.
- the syntax +→ and -→ to add/substract an expression to/from a variable or position in memmory pointed to.

For making screenshots, an emulator will always be by far the best and easiest way to go. If you really wanted to make screenshots on the calculator itself, shmibs took the words right out of my mouth. You'd then just have to transfer any picture variables to a computer and convert them from 8xi format to a standard image format, like gif; SoureCoder (http://www.cemetech.net/projects/basicelite/sourcecoder2.php) would be an easy way to do this.

I've sort of had the idea of augmented assignment operators in the back of my head, but never put serious thought into implementing it. Partially because I'm not sure I feel comfortable trying to add operators like this, and partially because Axe is already really tight on space. However I have to say that I really like your syntax suggestion for it, so if I ever get around to figuring out how to implement it, I'll probably use that. :)
Title: Re: Features Wishlist
Post by: TheMachine02 on February 11, 2013, 01:34:02 pm
two request :

-a Zadd() command, for change the z-adress (I know axiom can do it, but I prefer an axe command)

-an rect command who can draw in buffer and back buffer in same time (if possible  :P )
Title: Re: Features Wishlist
Post by: Runer112 on February 11, 2013, 01:40:18 pm
two request :

-a Zadd() command, for change the z-adress (I know axiom can do it, but I prefer an axe command)

-an rect command who can draw in buffer and back buffer in same time (if possible  :P )

Hmm, perhaps I'll add the z-addressing command. It certainly isn't difficult to implement. As for drawing shapes to multiple buffers... I'll think about it. :P
Title: Re: Features Wishlist
Post by: Freyaday on February 11, 2013, 06:41:45 pm
A sign(foo) command that returns -1 if foo is less than 0, 1 if greater, and 0 if equal. And perhaps sign(foo,bar), which would compare it to bar instead of 0. And while I'm on the topic, perhaps sign()r could be the 8bit version?
Also, I know it'd have to be named something other than sign(), because there's already a sign{}, but I don't know what to call it.
Title: Re: Features Wishlist
Post by: jo-thijs on February 12, 2013, 05:16:46 am
so, that'd be an assembly version of this?
foo-bar?ee0?65535,1

EDIT:
about axe being thight on space, I understand that it can give problems for some people if axe would exceed the size of about 16kb,
but it wouldn't be a problem to me and I would find it a bit sad if axe couldn't expand only for that reason,
so would it be practically possible to add 2 axe versions in the zip file, a lite and a pro version of axe,
where one has a low size and the other has all kind of possible features?
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 12, 2013, 05:43:00 am
I think more something like foo-bar?(ee0?-1,1),0
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 12, 2013, 06:33:12 am
so, that'd be an assembly version of this?
foo-bar?ee0?65535,1

EDIT:
about axe being thight on space, I understand that it can give problems for some people if axe would exceed the size of about 16kb,
but it wouldn't be a problem to me and I would find it a bit sad if axe couldn't expand only for that reason,
so would it be practically possible to add 2 axe versions in the zip file, a lite and a pro version of axe,
where one has a low size and the other has all kind of possible features?

Another thing to keep in mind is that ASM programmers can write Axioms (similar to libraries) that can add additional functionality to axe. If you have something specific that you'd like, you can always make a request <a href=http://ourl.ca/9970>here</a>
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 12, 2013, 07:28:25 am
I wonder what's the use of Z-addressing ...
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 12, 2013, 07:39:05 am
It's useful for visual effect. If you wanted to do an "earth quake" like effect where the screen was shaking back and forth, Z-addressing would be an easy way to do it.
Title: Re: Features Wishlist
Post by: Runer112 on February 12, 2013, 11:06:11 am
A sign(foo) command that returns -1 if foo is less than 0, 1 if greater, and 0 if equal. And perhaps sign(foo,bar), which would compare it to bar instead of 0. And while I'm on the topic, perhaps sign()r could be the 8bit version?
Also, I know it'd have to be named something other than sign(), because there's already a sign{}, but I don't know what to call it.

You know, you can build a pretty optimized sign routine in pure Axe. In fact... I don't think it's even think it's possible to produce a more optimized sign routine for Axe using assembly. :P

Code: [Select]
Lbl Sign
Return!If
Return //32768*2+1

As for the other variations, the compare seems that it's a little specific and could easily just be thrown into the sign routine above like Sign(foo-bar) anyways. As for the 8-bit sign function, you should really always be working with 16-bit signed values in Axe because every signed operator expects them. There are a few operators for which you can get away with not sign-extending 8-bit signed values, such as +, -, and *. But for using other operations, it's a good idea to sign-extend any 8-bit signed numbers using sign{} when loading them from memory.




about axe being thight on space, I understand that it can give problems for some people if axe would exceed the size of about 16kb,
but it wouldn't be a problem to me and I would find it a bit sad if axe couldn't expand only for that reason,
so would it be practically possible to add 2 axe versions in the zip file, a lite and a pro version of axe,
where one has a low size and the other has all kind of possible features?

Axe has already exceeded 16kb (1 flash page); it's currently just about filling 32kb (2 pages). Right now the first page is more or less entirely code and the second page is more or less entirely data. The next step up would be 48kb (3 pages), but really the size increase itself isn't the issue. More of an issue is that there would then be code split across pages. Producing and maintaining assembly code that spans multiple pages introduces a lot more complexity over code that fits on one page. And Axe is already fairly complicated, so for now I'd like to keep it restricted to 32kb so my head doesn't explode. I think I can still add a fair amount of code/features, I just need to optimize existing code to the max as I add new code.




I wonder what's the use of Z-addressing ...

I used z-addressing with a bit of assembly in this Axe program (http://ourl.ca/9322/177233) I made for a mini competition a while ago. The screenshot demonstrates that this game quickly becomes a bit of an insane use of z-addressing, but it definitely showcases the potential power of it by "shifting" what would otherwise be a simple tunnel game at nauseating speeds with no program speed loss.
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 12, 2013, 12:38:48 pm
Oh waw. I didn't think Z-addressing could be of that use. To be honest, I wasn't sure on how it worked ;D

So basically (I've seen it's related to port 10), it make a row of the LCD driver's RAM the one displayed at the top of the LCD, and then the rows that are above the LCD are displayed after the last row, at the bottom ?
Title: Re: Features Wishlist
Post by: jo-thijs on February 13, 2013, 02:31:24 pm
Oh, so that's what the multi page feature means? being able to make apps larger than 16kb with axe.
I don't really understand what the complications are that come with multiple pages,
I tried to search, but found few information about it.
I would love to have the multi page feature, since I'm working on a big project,
not knowing I can't exceed 16kb and I've almost reached the limits (about 15.5kb).
also, could it be that there comes problems if I try to upload big axe made applications to my pc through ti connect?
for some reason he wouldn't download it, no matter what I did, while everything else was being uploaded perfectly.
it always throws up the error: packet length not valid
Title: Re: Features Wishlist
Post by: Hayleia on February 13, 2013, 02:38:01 pm
I would love to have the multi page feature, since I'm working on a big project,
not knowing I can't exceed 16kb and I've almost reached the limits (about 15.5kb).
You can put all your data in archived appvar an access them via GetCalc("appvBlah",Y0). That would save space in the executable (the app).

also, could it be that there comes problems if I try to upload big axe made applications to my pc through ti connect?
for some reason he wouldn't download it, no matter what I did, while everything else was being uploaded perfectly.
it always throws up the error: packet length not valid
Did you sign your apps with RabbitSign before transferring them ?
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 13, 2013, 03:09:49 pm
You can still build programs larger than 16Kb (up to 24Kb in fact) but you can't build them as apps.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 13, 2013, 04:19:05 pm
I wonder what's the use of Z-addressing ...

An example of z-address earthquakes (and scrolling) can be seen here:

Title: Re: Features Wishlist
Post by: Matrefeytontias on February 13, 2013, 04:36:04 pm
Illusiat used Z-addressing !? O.O wasn't it in pure Basic ?
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 13, 2013, 04:54:23 pm
Nah, it used an ASM lib that did the Z-address manipulation. :P
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 13, 2013, 05:07:17 pm
Oh, I didn't knew that.

Anyway, I looked a bit on Wikiti's page about port $10 and found the screen mirroring interesting ($0C to $0F : bit 0 is vertical mirroring and bit 1 horizontal one). But how does it work ? I can't make it work the way I want <_<
Title: Re: Features Wishlist
Post by: ben_g on February 13, 2013, 05:56:36 pm
$0C is normal mode, I think $0D is vertical mirror and $0E is horizontal mirror, but $0D and $0E might be the other way around. $0F is mirrored both horizontally and vertically or rotated 180°).
It simply works by sending those instructions to the display driver (out ($10), $0F)
But those instructions only work on calcs with the new LCD driver. That might be a reason why it wouldn't be added to AXE.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on February 13, 2013, 06:17:07 pm
Illusiat used Z-addressing !? O.O wasn't it in pure Basic ?
It used about 4-5 small ASM libs by Michael Vincent, each being about 60 bytes large. One was for this, the other for inverted text, the other for contrast changing and there was a buggy lib by Joe Pemberton as well for archiving/unarchiving programs inside programs.

I have no clue is Z-Addressing works on newer calcs, though. All I know is that it doesn't on the TI-Nspire 84+ emulator and WabbitEmu didn't support it completely until last year.
Title: Re: Features Wishlist
Post by: Matrefeytontias on February 13, 2013, 07:07:32 pm
Z-addressing does work on my calc, but not screen mirroring. I assume that I've the old LCD.

Anyway, now I got a feature request : some way to mirror a screen buffer ;D
Title: Re: Features Wishlist
Post by: jo-thijs on February 15, 2013, 08:27:58 am
@Hayleia, I can't use rabbitsign on it, since I was trying to get the application from my calculator to my computer
using a static appvar to save space is a good idea, but I would like it more if my application isn't dependant on whatever some appvar exists and contains the right information.
@Matrefeytontias, I really want them to be in app form, it is the only convenient way to play my games for my friends.

Also, ignore the thing about my calculator don't want to transfer my game to my pc, some wierd things just happened on my calculator and after that it worked again after 2 tries.
Title: Re: Features Wishlist
Post by: Streetwalrus on February 18, 2013, 01:45:48 pm
It would be nice if you could import a binary file as inline assembly. This would allow easier use of Mimas.
Title: Re: Features Wishlist
Post by: Runer112 on February 18, 2013, 01:52:27 pm
It would be nice if you could import a binary file as inline assembly. This would allow easier use of Mimas.

Really the proper thing to do would be to make an Axiom. :P But I'll look into it.
Title: Re: Features Wishlist
Post by: jo-thijs on February 20, 2013, 03:53:11 pm
I've got 3 more things to ask.
1. I think I've found an optimisation for comparing an expression with a constant, to check whatever it is bigger or equal to it, or whatever it is smaller. This should be a start of it:
≥≥B should be the same (but larger) as -B<(32768-B) where I use 2 times a minus simple to substract, not to invert, and where 32768-B is being calculated at compile time, since b is a constant.
now, since <<B is the opposite, it should be the same as -B≥(32768-B)
This comprimises a few bytes, however, check whatever this may indeed be done first.
2. I'd like a function that makes a signed 2 byte value out of a 1 byte signed value.
I know this can be easily done by, for example, the following structure:
→Ae0?A+65380→A
and then A holds the value, but I'd like a more compact version of it that can be written in 1 function and only costs 4 bytes of space.
The assembly would look like this:
ld a,l
add a,a
sbc a,a
ld h,a
This would be a feature I would use all the time, because I save a lot of data, like speed, in a single byte, but need to add it to a double byte value, the position
3. It seems that the Disp command doesn't work very well if you have MATHPRINT turned on.
When trying to draw a number, it draws it kind of diagonally and it only draws the first character of strings.
This is at least what I've made up out of some tests.
Title: Re: Features Wishlist
Post by: TIfanx1999 on February 20, 2013, 04:04:10 pm
3. Is likely Mathprints fault. It causes some wonky display issues when turned on. I'd wait for an official answer to be sure, but that's likely the case.
Title: Re: Features Wishlist
Post by: jacobly on February 20, 2013, 04:04:37 pm
1. I'm quite certain Axe already does this.
2. If you want to sign extend Aʳ just do sign{°A}.
Title: Re: Features Wishlist
Post by: jo-thijs on February 20, 2013, 04:25:38 pm
3. Is likely Mathprints fault. It causes some wonky display issues when turned on. I'd wait for an official answer to be sure, but that's likely the case.
I know, but I just reported some specific issues with it.

1. I'm quite certain Axe already does this.
Nope, it doesn't, because I tested both methods for a couple of values and it returned a different size.

2. If you want to sign extend Aʳ just do sign{°A}.
If this takes only 4 bytes, I don't need that feature request anymore.
This seems good to me, I should really search more before asking such requests...
Title: Re: Features Wishlist
Post by: Streetwalrus on February 21, 2013, 03:21:06 pm
It would be nice if you could import a binary file as inline assembly. This would allow easier use of Mimas.

Really the proper thing to do would be to make an Axiom. :P But I'll look into it.
I'm too lazy for that and I want crazy freaking subroutineless speed. :P
Title: Re: Features Wishlist
Post by: Runer112 on February 21, 2013, 03:58:14 pm
Commands in Axioms can be marked to be inserted inline. Anyways there isn't really a reason why you should want to include a raw assembly program directly into an Axe program, because a proper assembly program should have things like a header and could have absolute jumps and calls and such.
Title: Re: Features Wishlist
Post by: Freyaday on February 23, 2013, 07:57:53 pm
Could the check for a too-large app happen after the first pass, instead of after the second pass and defragmentation?
And could it say, "ERR: App Too Big" or something like that?
Title: Re: Features Wishlist
Post by: Streetwalrus on February 24, 2013, 01:27:23 am
Commands in Axioms can be marked to be inserted inline. Anyways there isn't really a reason why you should want to include a raw assembly program directly into an Axe program, because a proper assembly program should have things like a header and could have absolute jumps and calls and such.
Actually, I'm writing small routines and assembling them without a header. Currently, I'm importing them as data and using an address call. Which is probably not the way to do it.
Title: Re: Features Wishlist
Post by: Freyaday on February 26, 2013, 04:18:09 pm
RectCopy(X1,Y1,dX,dY,X2,Y2[Buf1[,Buf2]])
This would take a rectangle with the top left corner at (X1,Y1), dX wide, dY tall, and copy it to X2,Y2.
No buffer arguments would copy from L6 to L6, and r from L3 to L3. One buffer argument would be from Buf1 to Buf1, and two would be from Buf1 to Buf2.
Title: Re: Features Wishlist
Post by: shmibs on February 26, 2013, 06:44:51 pm
^that would actually be very very useful, if it could be managed at a decent speed.
Title: Re: Features Wishlist
Post by: Runer112 on February 26, 2013, 06:56:46 pm
That would be insanely hard to code. Basically it's like drawing an arbitrarily sized sprite, which is hard enough, but on top of that the source data for the sprite doesn't have to be aligned to byte boundaries, you have to clip off any garbage in the leftmost and rightmost bytes, you have to draw the new sprite either from top to bottom and either from left to right according to the relative positions of the rectangles... It's a big mess.
Title: Re: Features Wishlist
Post by: shmibs on February 26, 2013, 07:37:38 pm
what about just drawing sprites from byte-aligned positions on a buffer (so reading every twelfth byte rather than all in one contiguous chunk)? that would give, basically, the same functionality.
Title: Re: Features Wishlist
Post by: Runer112 on February 26, 2013, 07:44:38 pm
I'm not sure I know what you mean by that.

Also I should probably ask, in what situations would you use a command like this? That might give me slightly better insight to the value of something like it.
Title: Re: Features Wishlist
Post by: shmibs on February 26, 2013, 07:54:11 pm
it would be useful for copying chunks of the back buffer to the front buffer, rather than recalling the whole thing.
what i'm talking about could be accomplished with:
For(L,0,7
copy(L*12+<buffer one offset>, L*12+<buffer two offset>,1
End
, for example.
Title: Re: Features Wishlist
Post by: Freyaday on February 26, 2013, 10:31:06 pm
I'm trying to "roll" parts of the screen, make them behave as if they were a toroid.
Title: Re: Features Wishlist
Post by: Runer112 on February 26, 2013, 10:35:09 pm
Since I don't even know what a toroid is... I think you're on your own for this one lol.



EDIT: Didn't see shmibs' post, here's my response to that: Doing the same thing with a custom assembly routine wouldn't be substantially smaller or faster, so I don't see a reason to implement such a command.
Title: Re: Features Wishlist
Post by: Freyaday on February 26, 2013, 11:15:41 pm
You know how the ship behaves when it goes off the edge of the screen in Asteroids?
I'm trying to do that, but with a smaller portion of the screen.
And it's not a ship. It's just that kind of behavior.
Title: Re: Features Wishlist
Post by: Builderboy on February 27, 2013, 12:02:50 am
You probably would be better off just displaying 2 or more sprites at the proper offsets at the edges of the area, and then masking off the unwanted parts with rect commands or copy commands or something.
Title: Re: Features Wishlist
Post by: calc84maniac on February 27, 2013, 08:02:58 am
Did everybody forget about Pt-Get? D:
Title: Re: Features Wishlist
Post by: Spyro543 on February 27, 2013, 09:18:10 am
Pt-Get? What's that?
Title: Re: Features Wishlist
Post by: Streetwalrus on February 27, 2013, 09:52:04 am
A command that gets a sprite off a buffer.
Title: Re: Features Wishlist
Post by: Runer112 on March 03, 2013, 07:26:38 pm
In regard to MathPrint causing weird display issues, I was recently in the process of trying to make a command to disable MathPrint for the duration of the program to combat this issue. But after I had mostly finished it, it appears that it may not even have been necessary. It seems that a simple ClrHome once in the program makes all homescreen text operations following it work just fine with MathPrint enabled. Can someone confirm that I'm not just crazy and that this actually works? In this case I can just cut out what I was working on and advice people to make sure they use ClrHome before any homescreen text operations if they're worried about compatibility with MathPrint.
Title: Re: Features Wishlist
Post by: Dapianokid on April 27, 2013, 01:59:39 pm
I honestly don't think this will be included... Because it's not really about Axe.. But you already have an amazing compiler right here. I think it may take an entire extra App Page, but...
Do you think one type of compile could be made for Axe code (traditional) and then have another feature to compile pure Ti-Basic or library'd Basic into pure ASM, so it runs faster (not interpreted) and it can still be.. ya know.. Basic..?
Title: Re: Features Wishlist
Post by: Hayleia on April 27, 2013, 02:52:27 pm
I honestly don't think this will be included... Because it's not really about Axe.. But you already have an amazing compiler right here. I think it may take an entire extra App Page, but...
Do you think one type of compile could be made for Axe code (traditional) and then have another feature to compile pure Ti-Basic or library'd Basic into pure ASM, so it runs faster (not interpreted) and it can still be.. ya know.. Basic..?
As you said, this has nothing to do with Axe, and that entire app page you are talking about will most likely be a separate app, rather than part of the Axe Parser.

Also, that is not the fact that it is interpreted that makes TI Basic slow. Look at Grammer, it is interpreted and still very fast.
Title: Re: Features Wishlist
Post by: Dapianokid on April 27, 2013, 03:57:16 pm
I honestly don't think this will be included... Because it's not really about Axe.. But you already have an amazing compiler right here. I think it may take an entire extra App Page, but...
Do you think one type of compile could be made for Axe code (traditional) and then have another feature to compile pure Ti-Basic or library'd Basic into pure ASM, so it runs faster (not interpreted) and it can still be.. ya know.. Basic..?
As you said, this has nothing to do with Axe, and that entire app page you are talking about will most likely be a separate app, rather than part of the Axe Parser.

Also, that is not the fact that it is interpreted that makes TI Basic slow. Look at Grammer, it is interpreted and still very fast.

I just thought Basic could be faster. I'm just nowhere near skilled enough to do it, and those that work on Axe are exactly the people who could.
Meh, it was a request none the less.
Title: Re: Features Wishlist
Post by: Builderboy on April 27, 2013, 10:38:50 pm
The problem with making Basic fast, is that you would have to actually change the way the language works in order to get any good amount of speed.  Basic is slow for 2 main reasons, the first being that every single graphics command updates the screen.  Even asm games are slow if they are forced to update the screen after every drawing command.  The second reason is that all the math is in floating point, which is inherently slow.  That is why all attempts to make a fast version of basic have gone on to design their own languages like Axe or Grammar
Title: Re: Features Wishlist
Post by: Piguy-3.14 on June 18, 2013, 03:07:07 pm
A menu command!!!! So you can quickly create a menu without going through all the hassle; this would be extremely useful!!!! Please do consider this Runer112!!!
Also some other features that are not as neccesary, but would make this language even better are:
-a tutorial!!!! Axe REALLY, REALLY needs a tutorial that is made for beginners, as there are not to many GOOD tutorials for axe at the moment, which is pretty rediculous considering what a popular language it's become...
-a command for sprites such as Gif(X,Y,[],[],[],[],[] it would allow you to have up to maybe around ten sprites(of which you write in hexadecimal in the brackets and the command annimates the sprites from left to right at the X Y coordinates specified. Along with this there should be a command like GifRepeat(X,Y,[],[],[],[],[] that will do exactly the same as Gif( but instead of stoping after the animation is over it should loop around and repeat the animation forever. You could also have ones that repeat it a certain amount of times, execute it until its False and one until its true. Do consider this as it would be pretty cool in my opinion.
-an easier alternative to tilemapping(tilemapps are extremely hard)
-an on-calc bitmap creator; they are not worth the time to make manually
-there are plenty more features, but ill start with these; please do consider these Runer112 and whoever else is working on axe!!!
Title: Re: Features Wishlist
Post by: Hayleia on June 18, 2013, 03:59:54 pm
A menu command!!!! So you can quickly create a menu without going through all the hassle; this would be extremely useful!!!! Please do consider this Runer112!!!
A menu is not a hassle to do, on the contrary, it is a great training for beginners to try designing their own menus of course simple at the beginning. And when they become expereinced enough to actually be able to do beautiful menus, the Menu command would become useless again. So not a good idea in my opinion.

-a tutorial!!!! Axe REALLY, REALLY needs a tutorial that is made for beginners, as there are not to many GOOD tutorials for axe at the moment, which is pretty rediculous considering what a popular language it's become...
There was a tutorial in French on the Site du zéro but since the website went crazy, I don't know if it is still available. Anyways, that surely doesn't interest you since it is in French.
Now, there are "not any" general tutorial for Axe, but there are a lot of specific tutorial out there, especially on Omnimaga, like FinaleTI's "External Vars Tutorial" for example.
But yeah, a tutorial for starters would be great too I guess.

-a command for sprites such as Gif(X,Y,[],[],[],[],[] it would allow you to have up to maybe around ten sprites(of which you write in hexadecimal in the brackets and the command annimates the sprites from left to right at the X Y coordinates specified. Along with this there should be a command like GifRepeat(X,Y,[],[],[],[],[] that will do exactly the same as Gif( but instead of stoping after the animation is over it should loop around and repeat the animation forever. You could also have ones that repeat it a certain amount of times, execute it until its False and one until its true. Do consider this as it would be pretty cool in my opinion.
Would eat too much RAM if one counter should be kept for every "gif". Or if you have a counter for everyone, then just do it manually with a Pt-On(X,Y,C++*8+Pointer). As for looping, just do Pt-On(X,Y,C+1^10→C*8+Pointer) if you have 10 frames.

-an easier alternative to tilemapping(tilemapps are extremely hard)
Same as with menus, tilemaps are a good training for beginners. I started Pokemon with no experience and spent one afternoon writing a non-smooth-scrolling tilemapper. Now I just do them in 5 minutes.
Basically, you know how to draw one sprite ? You know how to make a loop ? Then you know how to draw a tilemap with two loops and a sprite drawing command. And if you don't know it, then write down how to draw the first sprite, then how to draw the second, etc, then you should see the formula appear on your paper.

-an on-calc bitmap creator; they are not worth the time to make manually
I don't know what you mean with "BitMap" but there are sprite editors out there, like AxePaint or other editor that are less outdated (I still use that one because I am used to it though).

As a general thought to your post, I would say that, in opposition with the thought people have, Axe is closer to ASM than to Basic because it gives you more freedom. For now, you saw it as "less features", but when you get used to it, it is really a good language as it is in my opinion. Some would say "meh it still gives a lot of routines, so you don't code everything like ins ASM", but yeah, don't tell me the sprite drawing routine a beginner uses is not "recycled" from someone else's code. So there, Axe is like ASM, gives you "basic" commands but the rest is up to you.

(And of course, this is only my opinion, you are free to disagree and to add your aguments).
Title: Re: Features Wishlist
Post by: Runer112 on June 18, 2013, 04:01:42 pm
A menu command!!!! So you can quickly create a menu without going through all the hassle; this would be extremely useful!!!! Please do consider this Runer112!!!

I will likely eventually want to create a command that creates OS-style menus. I've added this to my todo list for Axe, which is unfortunately very massive already, though. But for any different or more graphical menus, you'll have to write the code for them yourself. There is no one universal code that could render and control any menu a programmer could want.

-a tutorial!!!! Axe REALLY, REALLY needs a tutorial that is made for beginners, as there are not to many GOOD tutorials for axe at the moment, which is pretty rediculous considering what a popular language it's become...

Have you fully read through the Documentation.pdf file included with Axe? It's a little outdated and only covers the basics, but it does so fairly well. To help with the outdated-ness, I'd also recommend reading the attached Changes.pdf, which details some of the big changes that were introduced in Axe 1.0.0 and haven't found their way into the main documentation yet. After that, you should have enough basic knowledge of Axe to begin reading through the Commands.html file and learning/trying any commands which seem useful for you and your projects. And if you have any questions about how perform specific tasks or how commands work, just ask!

As for an actual tutorial, I'm not sure if it's really possible to make a complete "tutorial" that will teach you how to do everything with a whole programming language. I think the closest approximation would be learning the dictionary and grammar of the language and learning how many regular tasks and algorithms would be handled with the language.

By far the most complete tutorial I know of for Axe, by kindermoumoute (where'd you go? :(), can be found here (http://www.siteduzero.com/informatique/tutoriels/l-axe-parser). It goes very in depth on an amazing breadth of topics, has tons of examples, and even has quizzes. I am extremely pleased with the work he put into it, and I think it's far better than I could ever do. There's a catch, though: it's written in French. For now, the best solution is to use something like google to translate each page (Chrome should offer to translate it automatically when you visit pages). The translation is mediocre, so take it with a grain of salt. And I've found it can mess with example code, so I usually keep an untranslated view of the page in another tab for looking at code.

-a command for sprites such as Gif(X,Y,[],[],[],[],[] it would allow you to have up to maybe around ten sprites(of which you write in hexadecimal in the brackets and the command annimates the sprites from left to right at the X Y coordinates specified. Along with this there should be a command like GifRepeat(X,Y,[],[],[],[],[] that will do exactly the same as Gif( but instead of stoping after the animation is over it should loop around and repeat the animation forever. You could also have ones that repeat it a certain amount of times, execute it until its False and one until its true. Do consider this as it would be pretty cool in my opinion.

It sounds like you believe that the calculator/Axe has some sort of underlying rendering engine, but unfortunately there isn't one. Every ounce of rendering logic has to be provided by the programmer/user. Drawing commands simply draw the one thing you tell them to draw, and that's it. They don't have memory areas that can keep track of animation progress for arbitrary sprites; they're stupid. The programmer is what makes programs smart, providing logic about how to act and what different things to display. :P

-an easier alternative to tilemapping(tilemapps are extremely hard)

For drawing 2D maps of tiles, there really is no other way than tilemapping. Tilemapping is, by definition, the method of rendering a map composed of tiles.

-an on-calc bitmap creator; they are not worth the time to make manually

This is the kind of thing that would be a completely separate program/application for image editing, or perhaps integrated into an IDE. It wouldn't be part of the Axe compiler, and the Axe bitmap format is publicly available so such a tool doesn't have to be made by an Axe developer (me). Anyone can make such a tool, even you! :)

-there are plenty more features, but ill start with these; please do consider these Runer112 and whoever else is working on axe!!!

Feel free to keep suggesting!



EDIT: Why didn't anybody tell me I forgot to attach Changes.pdf? x.x
Title: Re: Features Wishlist
Post by: Keoni29 on June 18, 2013, 04:07:18 pm
Tables, structures and other object oriented stuff would come in really handy. As of right now making the data structures for enemies, bullets etc. are pretty much hardcoded. If I want to add an extra variable to an object I'd have to change around a lot of code just to be able to do that. For my game HeroCore I simply forgot to increase the amount of bullets that can be drawn on screen and now I'm stuck with 6. If I want to increase it I have to increase 6 to x every time it occurs in the code.
Title: Re: Features Wishlist
Post by: Runer112 on June 18, 2013, 04:10:54 pm
Tables, structures and other object oriented stuff would come in really handy. As of right now making the data structures for enemies, bullets etc. are pretty much hardcoded. If I want to add an extra variable to an object I'd have to change around a lot of code just to be able to do that. For my game HeroCore I simply forgot to increase the amount of bullets that can be drawn on screen and now I'm stuck with 6. If I want to increase it I have to increase 6 to x every time it occurs in the code.

Tables and structures are big asks. However, I completely agree that they would be very useful. I'll certainly be investigating the possibility of implementing such language features for the next major revision of Axe. But that may be (read: is) a long way off!
Title: Re: Features Wishlist
Post by: Matrefeytontias on June 18, 2013, 04:16:56 pm
In fact, a non-smooth tilemapper is such a simple thing that it can be expressed in one line of code. Assuming that each image is 8*8 (thus 8 bytes long) and that x and y go from 0 to tilemap_width-1 and tilemap_height-1 respectively (in number of sprites, not pixels) and X and Y go from 0 to 11 and 7 respectively :

Pt-On(X*8,Y*8,{y*tilemap_width+x+tilemap_pointer}*8+tiles_images_pointer)

Of course, I just did all the work for you, but it's just to show that tilemappers are not "extremely hard" as you said :)
Title: Re: Features Wishlist
Post by: Keoni29 on June 18, 2013, 04:31:51 pm
Example for possible implementation of very basic structures:
Code: [Select]
[A,B,C,D]->structureToken1    // preprocessor returns the pointer to the first element in the structure (structureToken1.A)
10->{structureToken1.A}          // store 10 in memory location structureToken1.A (same as pointer structureToken1)
{structureToken.A}++           // increase value at memory location structureToken1.A
disp >dec                   // display result: 11

Title: Re: Features Wishlist
Post by: Hayleia on June 18, 2013, 04:42:29 pm
In fact, a non-smooth tilemapper is such a simple thing that it can be expressed in one line of code. Assuming that each image is 8*8 (thus 8 bytes long) and that x and y go from 0 to tilemap_width-1 and tilemap_height-1 respectively (in number of sprites, not pixels) and X and Y go from 0 to 11 and 7 respectively :

Pt-On(X*8,Y*8,{y*tilemap_width+x+tilemap_pointer}*8+tiles_images_pointer)

Of course, I just did all the work for you, but it's just to show that tilemappers are not "extremely hard" as you said :)
You forgot about the "For" command(s) but yeah, the core of it is quite simple, hence why I could write one without any experience in Axe. Maybe ahving already written a tilemapper in ASM helped me write one in Axe, but eh, how did I write one in ASM then ? Because it still was easy to deal with as long as you try. As I said, if you don't know the formula, try drawing the first sprite, then try drawing the second one, then etc, then see the formula to get all those drawing commands in a loop or two.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on June 18, 2013, 05:10:36 pm
Yeah a BASIC style menu command would be nice actually, since some games focus on small size and gameplay rather than the general interface. I hope that this wouldn't cause an invasion of terrible Axe games and menu-based RPGs, though, like what happened with TI-BASIC, but again most Axe games out there are good (although very large) so maybe people will refrain from posting as much crap on ticalc.org.
Title: Re: Features Wishlist
Post by: Matrefeytontias on June 19, 2013, 01:08:05 am
Hayleia :
Assuming that each image is 8*8 (thus 8 bytes long) and that x and y go from 0 to tilemap_width-1 and tilemap_height-1 respectively (in number of sprites, not pixels) and X and Y go from 0 to 11 and 7 respectively
Here are your For loops.
And I don't think a Menu( command really is a good idea. I'm afraid that it could make beginners lazy, since they would have a command to do everything.
Title: Re: Features Wishlist
Post by: Freyaday on July 12, 2013, 11:58:29 am
A prefix version of ++ and -- that returns the in/decremented value instead of the previous one.
Title: Re: Features Wishlist
Post by: jo-thijs on July 12, 2013, 12:24:14 pm
Can the fill( function be auto opted when the byte it should fill with is a predetermined constant?
And can it be optimised even further if the size is less than 256?
I think it would look like this:
0<size<256:
bytesize: 7
ld b,*
ld(hl),*
inc hl
djnz -5

size>=256
bytesize: 15
xor a
ld bc,**
ld(hl),*
inc hl
djnz -5
ld b,255
dec c
cp c
jr z,-11

and I think the current code has a size of 18 bytes.
I don't know if the code I gave is as optimised as it can be (nor have I tested it yet), but it is smaller.
Title: Re: Features Wishlist
Post by: Streetwalrus on July 12, 2013, 12:28:01 pm
Actually this would belong in the optimization thread but it's a good idea indeed.
Title: Re: Features Wishlist
Post by: Runer112 on July 12, 2013, 12:57:50 pm
A prefix version of ++ and -- that returns the in/decremented value instead of the previous one.

As of now, the ++ and -- operators don't actually have defined return values. Technically, any code that does currently use their return values is a hack, and would no longer work if ++ and -- were properly implemented. There are numerous programs that take advantage of the current implementation, and I don't want to break them, at least not for the moment.

I believe the main reason ++ and -- were never set up to properly return the new/old value exactly is for optimization reasons. If they were all fully implemented, VAR++ would be 1 byte larger, VARr++ and {EXPR}++ would be 4 bytes larger, and {EXPR}r++ would be 3 bytes larger. And it's not uncommon that the return value isn't actually needed, so those would be wasted bytes. It was kept in mind that programmers could use the "undefined" return values to get the real return values if they wanted them. For the first two cases, which I believe are the most common, it actually costs the programmer nothing to do this; the assembly implementations would be the same as VAR++-1 for the first and {VARr++}-1 and {{EXPR}++}-1 for the second (pre-increment would be the same as well, just without the -1's). It does get a little hairy with the two-byte pointed increment/decrement, though.

Don't get me wrong, I do eventually want real ++ and -- implementation. However, I would like to save it for when Axe has a more powerful optimizer and can intelligently see if the return value is actually used, and then decide whether to use the smaller undefined return value code or the larger defined return value code.


Can the fill( function be auto opted when the byte it should fill with is a predetermined constant?
And can it be optimised even further if the size is less than 256?
I think it would look like this:
0<size<256:
bytesize: 7
ld b,*
ld(hl),*
inc hl
djnz -5

size>=256
bytesize: 15
xor a
ld bc,**
ld(hl),*
inc hl
djnz -5
ld b,255
dec c
cp c
jr z,-11

and I think the current code has a size of 18 bytes.
I don't know if the code I gave is as optimised as it can be (nor have I tested it yet), but it is smaller.

Fill is absolutely a command I'd like to optimize, and I like your ideas. But on a note related to my response to Freyaday above, Axe's optimizer is unfortunately too simple at the moment to allow for such optimizations. It doesn't provide for any way to supply optimized versions of multiple-input functions for which some set of the inputs are constants.

When Axe gets a more powerful optimization engine, I certainly would like to see things like this added.





I think I'm seeing a theme here... x.x
Title: Re: Features Wishlist
Post by: jo-thijs on July 26, 2013, 01:12:44 pm
I don't know whatever this is possible, but I was thinking about an option where you can precompile a file, so that if it is called by another file that is being compiled, it compiles faster.
so you can precompile everything, except the level design part and then only recompile that for faster testing.
Title: Re: Features Wishlist
Post by: jo-thijs on July 26, 2013, 05:18:16 pm
also, i think I've found a smaller code for ee14 (if it isn't changed already).
now it takes 7 bytes, but it can be done with 6 bytes only too with as code:
xor a
add hl,hl
add hl,hl
ld h,a
rla
ld l,a

I thought I found a better way for ee15 too, but it seems the auto opts file was wrong about that.
Title: Re: Features Wishlist
Post by: Runer112 on July 26, 2013, 06:38:36 pm
I don't know whatever this is possible, but I was thinking about an option where you can precompile a file, so that if it is called by another file that is being compiled, it compiles faster.
so you can precompile everything, except the level design part and then only recompile that for faster testing.

This sounds like a very tricky thing to do. Hopefully it won't really be necessary to consider such aggressive and complicated speed improvements if the base compiling process itself can be made faster.


also, i think I've found a smaller code for ee14 (if it isn't changed already).
now it takes 7 bytes, but it can be done with 6 bytes only too with as code:
xor a
add hl,hl
add hl,hl
ld h,a
rla
ld l,a

I thought I found a better way for ee15 too, but it seems the auto opts file was wrong about that.

That optimization was actually already made a long time ago... I really need to just remove that auto opts file from Axe releases. In fact, I just did it now. It's so old and outdated, and all the information in there and much more can now be found in the Commands.html file.

If you do want to try optimizing Axe routines, the best place to look is probably at the Commands.inc file. There you can see the exact code for each routine and it's always up to date. And if you do spot any optimizations, there's this thread (http://ourl.ca/4175) specifically for such posts. :)
Title: Re: Features Wishlist
Post by: Streetwalrus on July 27, 2013, 07:41:18 am
I don't know whatever this is possible, but I was thinking about an option where you can precompile a file, so that if it is called by another file that is being compiled, it compiles faster.
so you can precompile everything, except the level design part and then only recompile that for faster testing.
Using external data and DrDnar's excellent RunPRGM are the best solution for that IMO. ;)
Title: Re: Features Wishlist
Post by: Hayleia on July 27, 2013, 08:31:48 am
I don't know whatever this is possible, but I was thinking about an option where you can precompile a file, so that if it is called by another file that is being compiled, it compiles faster.
so you can precompile everything, except the level design part and then only recompile that for faster testing.

This sounds like a very tricky thing to do. Hopefully it won't really be necessary to consider such aggressive and complicated speed improvements if the base compiling process itself can be made faster.
I guess that you could have "Compile as Ion,Noshell,...,Include", and the Include (or call it something else if you want) mode would "compile" the source into a program that would only be Asm(<hex>). This way, compiling it again would be faster I guess (no need to think again about optimizations and such, just need to translate directly from alphabetical tokens into true hex). The problem with that is that the code in the include has to be independant.
Title: Re: Features Wishlist
Post by: Streetwalrus on July 28, 2013, 04:27:27 am
I wonder if there could be a command to force a program to be compiled for a certain shell and also constants that give info on the build (machine model, extra RAM or not, shell it's being compiled for...). That would make things a little easier to manage in certain cases (i. e. 15MHz only code or app only code).
Title: Re: Features Wishlist
Post by: Sorunome on July 28, 2013, 07:41:48 am
wait, i just got a good idea....maybe adding like a optional 2nd line header which tells axe for which shell to compile, that way you don't always have to switch from app to noshell when you want to make an appvar.
Title: Re: Features Wishlist
Post by: Streetwalrus on July 28, 2013, 09:02:40 am
wait, i just got a good idea....maybe adding like a optional 2nd line header which tells axe for which shell to compile, that way you don't always have to switch from app to noshell when you want to make an appvar.
Exactly what I suggested. x.x
Also an appvar "shell" could be nice.
Title: Re: Features Wishlist
Post by: Sorunome on July 28, 2013, 11:25:28 am
wait, i just got a good idea....maybe adding like a optional 2nd line header which tells axe for which shell to compile, that way you don't always have to switch from app to noshell when you want to make an appvar.
Exactly what I suggested. x.x
I didn't quite catch that x.x
Quote
Also an appvar "shell" could be nice.
Agreed, that way I don't need that few bytes prog on my calc to convert :P
Title: Re: Features Wishlist
Post by: Runer112 on July 28, 2013, 02:52:49 pm
That idea has crossed my mind before, but I never really thought about how it could be implemented. Now that I think about it, it's definitely a useful feature, one that I've wanted myself sometimes. After a bit of pondering, I came up with a syntax that I believe should work well from both the appearance and underlying implementation standpoints. To specify a target, you would put a store arrow immediately after the name in the header, followed by a letter, like this:


How do you guys feel about that syntax? Also, note the additional Appvar shell. I thought that was a good idea as well. It's another thing I've wanted in the past but for some reason never thought about actually adding.
Title: Re: Features Wishlist
Post by: Hayleia on July 28, 2013, 02:55:29 pm
How do you guys feel about that syntax?
I like the idea of having one token for everyone and using letters to see who is who, but the → is a bit confusing according to me. Why not parentheses instead, like .THING() for default, .THING(I) for Ion, etc ? Or if you want to use the →, why not .M→THING instead of .THING→M ?
Title: Re: Features Wishlist
Post by: Streetwalrus on July 28, 2013, 03:30:00 pm
I was hoping for something like on line 2 :
Code: [Select]
.Shell <whatever>
Also what about the other features I suggested (build constants) ?
Title: Re: Features Wishlist
Post by: Runer112 on July 28, 2013, 04:24:07 pm
How do you guys feel about that syntax?
I like the idea of having one token for everyone and using letters to see who is who, but the → is a bit confusing according to me. Why not parentheses instead, like .THING() for default, .THING(I) for Ion, etc ? Or if you want to use the →, why not .M→THING instead of .THING→M ?

The idea was that you're "storing" the compiled data into the target variable type. Does that win you over at all? :P I find the parentheses method confusing myself because it suggests to me that the file is some massive routine with input arguments, and I mentioned why I like the store approach in the order first suggested.

If you still aren't a big fan of the original syntax suggestion, it can certainly be changed. It would be good to hear input from a few others before any kind of decisions are made.


I was hoping for something like on line 2 :
Code: [Select]
.Shell <whatever>
Also what about the other features I suggested (build constants) ?

I was steering away from a syntax like this because the target variable type needs to be known before compilation even starts, and having it in the header means no need for lookahead parsing. I'm not sure if you intended this, but this syntax does have the advantage of being backwards compatible (older versions of Axe would ignore the target and use the default target). Whether or not this behavior or good, I'm not sure.

And I'm not sure what the purpose of the "build constants" would be. The calculator model and related hardware information aren't constant, they depend on whatever calculator runs the program. Unless you meant including the specs of the actual calculator building the program, but I can't think of how that would be useful. The compiled code should be the same regardless of which model calculator compiled it.
Title: Re: Features Wishlist
Post by: Streetwalrus on July 28, 2013, 04:53:51 pm
And I'm not sure what the purpose of the "build constants" would be. The calculator model and related hardware information aren't constant, they depend on whatever calculator runs the program. Unless you meant including the specs of the actual calculator building the program, but I can't think of how that would be useful. The compiled code should be the same regardless of which model calculator compiled it.
This could be useful in some rare cases but I think the most useful one would be to know what shell you're compiling for. This way you could make shell specific code. ;)
Title: Re: Features Wishlist
Post by: Hayleia on July 29, 2013, 02:08:29 am
How do you guys feel about that syntax?
I like the idea of having one token for everyone and using letters to see who is who, but the → is a bit confusing according to me. Why not parentheses instead, like .THING() for default, .THING(I) for Ion, etc ? Or if you want to use the →, why not .M→THING instead of .THING→M ?

The idea was that you're "storing" the compiled data into the target variable type. Does that win you over at all? :P I find the parentheses method confusing myself because it suggests to me that the file is some massive routine with input arguments, and I mentioned why I like the store approach in the order first suggested.

If you still aren't a big fan of the original syntax suggestion, it can certainly be changed. It would be good to hear input from a few others before any kind of decisions are made.
In fact, reading your post again makes me think that your syntax is the best. It stores the THING program into a M(irageOS) program, so it is basically THING→M.
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 29, 2013, 03:42:32 am
I think the original suggested syntax is fine. It seems very clear to me.
Title: Re: Features Wishlist
Post by: Sorunome on July 29, 2013, 05:03:43 am
The syntax also is fine for me :) It IS pretty clear :)
Title: Re: Features Wishlist
Post by: Hayleia on July 29, 2013, 06:19:33 am
Yeah, same for me. I don't know why I didn't find it clear at first but now I like it.
And if we need a MirageOS description, that would be ".NAME→M Description" ?
Title: Re: Features Wishlist
Post by: Streetwalrus on July 29, 2013, 06:26:06 am
I guess so. ;)
Title: Re: Features Wishlist
Post by: ISSOtm on August 02, 2013, 09:16:57 am
Something nice would be an option to get the hexa code created by Axe after compilation ; I already created a program (using Axe ;D) to "decompile", but if Axe could do this it would be REALLY cool... Thanks...

I'm thinking to this because sometimes we can try to optimise the hexa by ourselves, and if Axe lets us edit the compiled code, we could do...  :o
Title: Re: Features Wishlist
Post by: Streetwalrus on August 02, 2013, 09:20:49 am
Just use the Asm( command, it's here for a reason. ;)
Title: Re: Features Wishlist
Post by: ISSOtm on August 02, 2013, 11:51:05 am
No, I meant that it would be nice to EDIT the code generated by Axe
Title: Re: Features Wishlist
Post by: Sorunome on August 02, 2013, 11:52:40 am
you could use a hex-editor like calcsys
Title: Re: Features Wishlist
Post by: ISSOtm on August 02, 2013, 12:00:05 pm
Ok, another app on my calculator ; but my archive is *nearly* full...
I mean, something included into Axe, because CalcSys does much more and then takes much more ARC than what my calculator can save...

Anyway, thanks for your suggestion, I'll try to download it (if not enough ARC I'll delete my new bank program :-[)
Title: Re: Features Wishlist
Post by: ISSOtm on August 02, 2013, 12:24:59 pm
Ok, to install CalcSys I have to upgrade my calc OS, but it ALWAYS says "error ! please reboot calc". Then it re-tries to install the OS, and some time after, I get this error back ; I cannot anymore use my calc !!! :banghead:
Title: Re: Re: Features Wishlist
Post by: DJ Omnimaga on August 02, 2013, 12:32:10 pm
If included in Axe it's entirely possible that Axe might take as much space as CalcSys would take if you installed it. If Runer is running out of app pages space to add new features, then that's entirely possible. :P
Title: Re: Features Wishlist
Post by: ISSOtm on August 02, 2013, 12:39:47 pm
Ok if it's not possible, then I'll find something else
(but first, I'll try to update a working OS on my calc, at the moment I cannot, even the one that was already installed !!!! :mad:)

I think I got a reason to hate TI.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 02, 2013, 03:17:05 pm
Do you happen to have OS 2.53/55MP installed? :P Those are not as stable as 2.43, although they have more features. Axe is supposed to work fine under any of these OSes, though. What else do you have installed?
Title: Re: Features Wishlist
Post by: jo-thijs on August 02, 2013, 04:09:34 pm
I think I've had a similar problem a while ago.
It happened to me when I wanted to download an OS on my calculator (TI84+ SE) with TI Connect.
It always kept failing and I couldn't get any OS on it.
eventually, I tried to do it through another pc (a 32-bit laptop instead of a 64-bit desktop, though that has nothing do with it I think) and then suddenly it did work.
So, I'd recommend trying to get the OS on your calculator through another pc, or by reinstalling the linking program you use and stuff like that, eventually I think it will work again.
also check the status of your cable and the usb port.
Title: Re: Features Wishlist
Post by: Sorunome on August 02, 2013, 05:44:48 pm
Did you try tilp yet?
Title: Re: Features Wishlist
Post by: ISSOtm on August 03, 2013, 10:43:15 am
Do you happen to have OS 2.53/55MP installed? :P Those are not as stable as 2.43, although they have more features. Axe is supposed to work fine under any of these OSes, though. What else do you have installed?
No, I had the 1.18 OS, and tried to update 1.19 then I had this...
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 03, 2013, 01:41:29 pm
Oh I see you don't have a 84+. It is also possible that your calc is partially busted, though. (as in, defective or broken)
Title: Re: Features Wishlist
Post by: ISSOtm on August 03, 2013, 01:54:37 pm
I think I've had a similar problem a while ago.
It happened to me when I wanted to download an OS on my calculator (TI84+ SE) with TI Connect.
It always kept failing and I couldn't get any OS on it.
eventually, I tried to do it through another pc (a 32-bit laptop instead of a 64-bit desktop, though that has nothing do with it I think) and then suddenly it did work.
So, I'd recommend trying to get the OS on your calculator through another pc, or by reinstalling the linking program you use and stuff like that, eventually I think it will work again.
also check the status of your cable and the usb port.
I re-installed the linking software (version 4.0, English ; notice : before I was on the French one), and tried to update to 1.18 (the one I already had). I did it ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif) !!! Then now, I'm using the 1.19 OS, and thank you very much jo-thijs for this suggestion.

I didn't try to re-install CalcSys, because I don't anymore want this... >:(

End of the "topic" about my problems and CalcSys, I think there's nothing more to say about it, and if anybody wants to say something more, I think this topic isn't the good one...
Title: Re: Features Wishlist
Post by: Sorunome on August 03, 2013, 05:09:58 pm
Um, IDK if this has been asked in here yet, but will it gain color support?
Title: Re: Features Wishlist
Post by: Runer112 on August 03, 2013, 06:19:12 pm
Um, IDK if this has been asked in here yet, but will it gain color support?

Will Axe? I certainly hope so.
Title: Re: Features Wishlist
Post by: ISSOtm on August 13, 2013, 11:21:19 pm
Idea, that would be REALLY great :
Nested libs. I had an idea, it's : 1st pass, compile and replace all prgmLIBSNAME by its commands, and if, at the 2nd pass, you find another prgmNESTLIB, then repeat 2nd pass ; end program compilation when there's no more lib to add.
But if someone creates a lib that includes itself ?
Title: Re: Features Wishlist
Post by: Runer112 on August 14, 2013, 12:02:45 am
Idea, that would be REALLY great :
Nested libs. I had an idea, it's : 1st pass, compile and replace all prgmLIBSNAME by its commands, and if, at the 2nd pass, you find another prgmNESTLIB, then repeat 2nd pass ; end program compilation when there's no more lib to add.
But if someone creates a lib that includes itself ?

I do agree that fully supporting nested includes/libraries would be nice. Support for at least a few more nesting levels could possibly be added. Approximately what maximum level of nesting do you believe would be reasonable?

And if a library included itself, it would just keep including itself until an error occurs, whether it be due to the maximum nesting level being reached, RAM having been filled by the compiled program, or just duplicate definitions.
Title: Re: Features Wishlist
Post by: Eiyeron on August 14, 2013, 04:41:50 pm
Do Axe Fusion support Axioms? Axiom based static libraries!
Title: Re: Features Wishlist
Post by: Runer112 on August 14, 2013, 04:49:06 pm
Do Axe Fusion support Axioms? Axiom based static libraries!

For now, Axe Fusion does not support external static libraries. It would be too difficult to implement in Axe's current state, but expect this to be possible in the next major revision of Axe.
Title: Re: Features Wishlist
Post by: ben_g on August 25, 2013, 06:51:43 pm
I'd like to suggest a feature:

Axe libraries are fully recompiled everytime you compile a program that uses them. It can often take over half the time needed to compile the program. Therefore, it would be nice if there was a way to precompile axe libraries (maybe into axioms?), to decrease the time needed for compilation.
Title: Re: Features Wishlist
Post by: tr1p1ea on August 25, 2013, 06:57:50 pm
How about ... 84C integration?!
Title: Re: Features Wishlist
Post by: Sorunome on August 25, 2013, 06:59:29 pm
How about ... 84C integration?!
that was already suggested many times and i think will be done :P
Title: Re: Features Wishlist
Post by: tr1p1ea on August 25, 2013, 07:09:02 pm
Oops sorry, my bad i really should have checked the other pages :S.

One of the items that i received the most feedback on regarding the xLIB project is the lack of oncalc documentation.
Title: Re: Features Wishlist
Post by: Runer112 on August 25, 2013, 10:01:32 pm
I'd like to suggest a feature:

Axe libraries are fully recompiled everytime you compile a program that uses them. It can often take over half the time needed to compile the program. Therefore, it would be nice if there was a way to precompile axe libraries (maybe into axioms?), to decrease the time needed for compilation.

How about ... 84C integration?!

Both of these are goals for Axe 2.0.
Title: Re: Features Wishlist
Post by: Freyaday on September 02, 2013, 04:37:27 am
How many releases are planned before 2.0?
Title: Re: Re: Features Wishlist
Post by: DJ Omnimaga on September 02, 2013, 02:36:37 pm
Hopefully it's out before Sam Heald starts working on his Zelda clone again. :P
Title: Re: Features Wishlist
Post by: Streetwalrus on September 02, 2013, 02:41:27 pm
Hopefully it's out before Sam Heald starts working on his Zelda clone again. :P
Lol at that one. :P
Title: Re: Features Wishlist
Post by: Runer112 on September 02, 2013, 02:45:14 pm
How many releases are planned before 2.0?

Only one, and possibly a quick follow-up second if there are any huge bugs.
Title: Re: Features Wishlist
Post by: willrandship on September 12, 2013, 04:32:58 pm
Can we get a specification showing what commands compile into? That would allow for many spinoff projects, like compilers for the PC. (PC compiler for z80 binaries)
Title: Re: Features Wishlist
Post by: Matrefeytontias on September 12, 2013, 04:44:42 pm
The commands.inc file is exactly that.
Title: Re: Features Wishlist
Post by: jo-thijs on September 21, 2013, 03:00:33 pm
Perhaps a command that draws a triangle with coordinates: (x1,y1),(x1,y2),(x2,y2)
And perhaps a command that creates a bit map of a random triangle,
which might be done by filling it completely and then erasing the edges by the previous proposed command.
I think this would be a great base for jobs like drawing skewed sprites (defined by 4 random points and a sprite).
Title: Re: Features Wishlist
Post by: willrandship on September 21, 2013, 06:59:54 pm
Just having the first triangle command you mentioned would be enough, considering Axe already has a random number generator. It wouldn't help with skewed sprites, though, since you would still have to do the whole "stretch sprite" bit.

If you want skewed sprites, try convincing them to allow the single-byte draws. Then you can at least do horizontal/vertical skews. (whichever direction the LCD stores, I think vertical thus 6-byte text.)
Title: Re: Features Wishlist
Post by: Runer112 on September 21, 2013, 07:24:39 pm
Drawing triangles (and other arbitrary shapes) is pretty tough. I think such a routine would be cool too, but I can't see it fitting (literally) into Axe for now.

Perhaps this Axiom (http://ourl.ca/18452) by Matrefeytontias could help? The triangle drawing command is only intended for use in 3D rendering as far as I can tell, but perhaps that's what you wanted it for anyways and it's an extra bonus? :P
Title: Re: Features Wishlist
Post by: Matrefeytontias on September 25, 2013, 12:28:06 pm
The triangle thing is not particularly intended for 3D rendering, it's just a triangle filler.
Title: Re: Features Wishlist
Post by: Freyaday on October 07, 2013, 10:22:56 am
I just realized that bitshifting a var down one is equivalent to var>1. Is there a way this optimization could find its way into Axe?
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2013, 01:26:31 pm
Can you clarify what you mean, perhaps showing it in code and how it should be optimized?
Title: Re: Features Wishlist
Post by: Streetwalrus on October 07, 2013, 03:52:38 pm
Well, that's basically var/2. And it only works on unsigned values so it can't be an auto opt.
Title: Re: Features Wishlist
Post by: Freyaday on October 07, 2013, 10:09:35 pm
Instead of doing
Code: [Select]
I>1 or
Code: [Select]
I>=2, you can do
Code: [Select]
I/2 which is already auto-opted to a bitshift; could the other two functions be added to the auto-opts? It also works for other powers of two.
Title: Re: Features Wishlist
Post by: Runer112 on October 07, 2013, 10:15:23 pm
But those return completely different things..?

I realize that in the context of a conditional like If I>1, dividing by 2 will result in the same conditional branch being followed, but people can use it in computations as well. If you want the optimization in the context of conditionals and understand the different return value, you can always do it manually. :P Axe doesn't really have great capability to perform context-sensitive optimizations that only trigger in certain scenarios. I don't think the peephole optimizer's current state (the system that seems like would be responsible for such an optimization) could even support making this optimization only in if statements.
Title: Re: Features Wishlist
Post by: Builderboy on October 08, 2013, 05:18:42 am
A good example of why this would break down is that you could no longer do things like If (I>1) and (A=2), since the 'and' operator is bitwise instead of boolean the conditional would never pass if I is 4 for instance.
Title: Re: Features Wishlist
Post by: Streetwalrus on October 08, 2013, 11:45:18 am
Well, ? and ?? should be used for conditionals anyway.
By the way, nice to see you here Builderboy ! :D
Title: Re: Features Wishlist
Post by: Hayleia on October 08, 2013, 01:22:28 pm
Well, ? and ?? should be used for conditionals anyway.
That doesn't mean you can't put optimizations within this kind of "blocks". For example, if you want to store 1 in D when B>1 and don't touch it otherwise, you can do B>1?→D.
Title: Re: Features Wishlist
Post by: Streetwalrus on October 08, 2013, 01:29:20 pm
I was just telling BB that ?? and ? were better than or and and. ;) I know about this kind of HL abuse, it's pretty awesome. :D
And I personally believe that it just shouldn't auto opt >1 to /2 because of what Hayleia said.
Title: Re: Features Wishlist
Post by: TIfanx1999 on October 08, 2013, 02:06:10 pm
A good example of why this would break down is that you could no longer do things like If (I>1) and (A=2), since the 'and' operator is bitwise instead of boolean the conditional would never pass if I is 4 for instance.

A Wild Builderboy appeared! Heya, BB! If you can makes some time, you should try to submit an entry for the BASIC version of the <a href=http://ourl.ca/19647>contest</a> going on, ya know, for old times sake. ;)
Title: Re: Features Wishlist
Post by: Freyaday on October 19, 2013, 01:20:56 pm
Is signed for loop comparisons a possibility?
Title: Re: Features Wishlist
Post by: Runer112 on October 19, 2013, 01:22:49 pm
Possible: yes. Easy to implement: I'm not so sure... I'll look into it, though.
Title: Re: Features Wishlist
Post by: ClrDraw on October 19, 2013, 01:30:35 pm
It would be awesome if Axe also had more commands for utility type programs in addition to all the game stuff.
It would be great if it could:

RunPRGM(programNAME)
easily run achived/unarchived basic and assembly programs without an axiom

RunAPP(appNAME)
run Apps from within the program
Title: Re: Features Wishlist
Post by: Runer112 on October 19, 2013, 01:37:17 pm
Running external apps and programs is tricky and should really involve stuff like error handlers when done properly. Considering DrDnar's axiom exists and does most of that already, and that the Axe application's 2 pages are pretty much completely full, I don't think this is something I'd consider adding to Axe at the moment.
Title: Re: Features Wishlist
Post by: jo-thijs on October 30, 2013, 05:48:42 pm
I've just noticed the use of rp_Ans and rp_Byte in the Commands.inc file, it's brillant!
when I saw, it, a question arose however: what if it would be possible to find another start code
that is followed by a label, where axe will go to the label and copy the code that is there in the final code
and then return? could this free some space in axe, without slowing axe too much down?
an example would be:
p_ShiftLeftFast:         ;16982 cycles, 44 bytes
   .db __ShiftLeftFast_SubEnd-1-$
   ld   hl,plotSScreen+768
x_ShiftLeftFastEntry:
   ld   b,64
__ShiftLeftFast_Loop:
   dec   hl
   sla   (hl)
__ShiftLeftFast_SubEnd:
   .db copy_subfunc
   .dw _ShiftLeftFast_End
   .db 0,copy_subfunc
   .dw _ShiftLeftFast_End
   .db 6
   dec   hl
   rl   (hl)
   djnz   __ShiftLeftFast_Loop
   ret
__ShiftLeftFast_End:
   .db 15
   dec   hl
   rl   (hl)
   dec   hl
   rl   (hl)
   dec   hl
   rl   (hl)
   dec   hl
   rl   (hl)
   dec   hl
   rl   (hl)

which would be 6 bytes smaller if I'm correct.
another example:
p_NEN2:
   .db 1
   inc   l
   .db copy_subfunc
   .dw p_NEN1
        .db 0

which would save 3 bytes.
another example:
p_NE2:
   .db 1
   dec   l
   .db copy_subfunc
   .dw p_NE1
   .db 0

which would save 4 bytes.
and so on.

this is probably just a crazy idea I got, but I wanted to post it anyway.
Title: Re: Features Wishlist
Post by: Runer112 on October 30, 2013, 05:55:02 pm
Considering that nitty gritty compiler features like that were implemented by Quigibo and I frankly am still not entirely sure how his code for them works, I think I'd have to pass on implementing that. :P

I think the Axe 1.x version line is coming to an end anyways, so putting work into adding features to the actual compiler, which I hope to largely rewrite, would be a fair amount of work for code that would probably only ever exist in one or two versions of Axe. I hope to redo the general library system to be a more robust in the next major version of Axe, so I'll probably implement something that provides the same functionality as your suggestion, just in the different library format.

At this point, I'm looking to collect ideas for the future of Axe, but it'll be a ways off until I can implement them.
Title: Re: Features Wishlist
Post by: Streetwalrus on November 01, 2013, 01:45:21 pm
Maybe you could make Axe fully modular by having the compiler in a one page app and then libs as appvars (including the base library). That would be pretty awesome and allow you to push compiler and lib updates separately. ;) Not to mention that the more you'd fraction the lib, the more people would be able to save flash by not sending rarely used parts.
Title: Re: Features Wishlist
Post by: Runer112 on November 01, 2013, 01:48:12 pm
That is very much the ideal for the future of Axe.
Title: Re: Features Wishlist
Post by: shmibs on November 01, 2013, 02:30:46 pm
um, i thought that was how it works already (compiler + axioms) :P
Title: Re: Features Wishlist
Post by: willrandship on November 01, 2013, 02:33:06 pm
shmibs, with the changes they're discussing, things like dispgraph, zeros(), and, depending on how extreme they want to get, + and -, would be axioms.
Title: Re: Features Wishlist
Post by: Streetwalrus on November 01, 2013, 02:39:10 pm
Yeah, kind of like C has standard libs and the compiler is completely independent of these. So you could code your own libs like Linux does. Pure Axe OS anyone ?
Of course, stuff like +/- and compiler side features like zeros() have to remain in the app for it to be at all usable.
Title: Re: Features Wishlist
Post by: willrandship on November 01, 2013, 02:53:36 pm
I don't know, having every word but axiom includes available would be handy if you wanted to use Axe's compiler as the base for a different language. You could completely change how every part of it works.
Title: Re: Features Wishlist
Post by: Streetwalrus on November 01, 2013, 03:07:27 pm
Yeah but then it'd be quite hard to handle. A new language calls for a new compiler but if Axe goes open source then this is a better way to redesign stuff. And it kinda defeats the purpose of a calc c-style language.
Title: Re: Features Wishlist
Post by: willrandship on November 01, 2013, 04:10:16 pm
Axe is not a C-style language as it currently stands. C style languages support more features, and tend to have more bloat. It doesn't even use similar syntax.
Title: Re: Features Wishlist
Post by: Streetwalrus on November 01, 2013, 06:13:57 pm
I'm not saying Axe=C, I'm a firm believer they are quite different. But the general concepts of a high level compiled language with a bunch of low level features is here.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on November 02, 2013, 03:07:30 am
By the way, are there still possibilities of a color Axe in the future?
Title: Re: Features Wishlist
Post by: Streetwalrus on November 02, 2013, 04:00:15 am
I think it's a planned feature for Axe 2.0.
Title: Re: Re: Features Wishlist
Post by: DJ Omnimaga on November 02, 2013, 12:13:34 pm
Will Axe 2.0 still be programmable on-calc though? Since DCS 8.0 RC2 came out, I have been mostly programming on calc rather than Source Coder, since I can test my stuff faster (jsTIfied doesn't run xLIBC well).
Title: Re: Features Wishlist
Post by: Runer112 on November 02, 2013, 01:15:32 pm
Axe has and will always support coding on-calc through the standard BASIC editor. And yes, 84+CSE support is planned for Axe 2.0. But please keep in mind that Axe is a huge project that has taken 3.5 years to get where it is, so redesigning it to support all these new things combined with all the old things is likely going to take a significant amount of time.
Title: Re: Features Wishlist
Post by: Sorunome on November 02, 2013, 01:38:35 pm
But that'll still be awesome :P
Also, it might be easier to use if you had a custom editor with all-custom tokens, one that comes with the axe app, that way you are not stuck with stupid TIOS stuff <_<
Title: Re: Features Wishlist
Post by: Runer112 on November 02, 2013, 01:47:11 pm
I do agree that a customized editor would be nice. But is it necessary to actually build a custom editor program/application? I think the easiest way to implement a fairly simple but good Axe editor would be to keep using the built-in BASIC editor, but on top of the token hook, add a menu hook that adds menus specifically for the Axe commands.

If you start entering the realm of custom editor programs, you start moving away from the Axe project itself and into Axe IDE's, which can be made by a third party with about the same ease as I could. A custom-made Axe IDE would be awesome, but I should first and foremost be concerned with implementing the compiler and language features, and just adding the BASIC editor hooks as mentioned above because they're quick to implement.
Title: Re: Features Wishlist
Post by: josh landers on November 04, 2013, 10:38:28 pm
I totally agree.  Perphaps a succesfull asm programmer could start an IDE for axe parser. I have always wanted one on calculator as an app. One could make it really simple and have it all under the prgm button. BTW I was not offering my self up for the asm holocaust.  :-\
Title: Re: Features Wishlist
Post by: willrandship on November 04, 2013, 10:49:51 pm
Many people have started such projects, and some are still in progress.
Title: Re: Features Wishlist
Post by: ClrDraw on November 14, 2013, 10:58:14 am
I think I will start an editor in a little while, I really want one too mostly just for the tiny font.

Runner112, is there any way you could make Axe so that I could make an app greater than 16384 bytes? My current program has gotten so large I have had to cut some features that I didn't want to cut just so it could compile.
Title: Re: Features Wishlist
Post by: Matrefeytontias on November 14, 2013, 12:07:27 pm
Do like I did with IkarugaX, make a program that is larger than 16384 bytes by usingFullrene and a shell. It works.

Automatically generating apps that takes more than one page is a logistical nightmare, as Runer112 said before.
Title: Re: Features Wishlist
Post by: Runer112 on November 14, 2013, 12:10:48 pm
I think I will start an editor in a little while, I really want one too mostly just for the tiny font.

Runner112, is there any way you could make Axe so that I could make an app greater than 16384 bytes? My current program has gotten so large I have had to cut some features that I didn't want to cut just so it could compile.

This is something that will require a compiler redesign and should hopefully come with Axe 2.0. But that's still a long ways off, I feel. For now, your options are to optimize your code (you can post the source or parts of it and request optimization help on the forums, if you'd like), and/or follow Matrefeytontias' suggestion to compile it as a program with Fullrene (http://ourl.ca/13513), which would realistically let you have programs up to about 20-24KB.
Title: Re: Features Wishlist
Post by: ClrDraw on November 14, 2013, 04:45:23 pm
Hmm, it has to be an app sadly not a program :(
Title: Re: Features Wishlist
Post by: Hayleia on November 14, 2013, 05:06:06 pm
Then optimize, there is not much to do for the moment. Or if you don't manage to, you can also get all your data in external appvars and keep only the code in the app.
Title: Re: Features Wishlist
Post by: Freyaday on November 20, 2013, 11:53:57 pm
Or you can do what I did and put your extra functionality in an external program and use DrDnar's RUNPRGM Axiom to swap between your app and the external program.
Title: Re: Features Wishlist
Post by: ClrDraw on November 21, 2013, 10:36:27 am
That's a good idea, I could store the data in an appv and run the appv.
Title: Re: Features Wishlist
Post by: Matrefeytontias on November 22, 2013, 12:03:54 pm
This question has been asked once or twice per page since the 84+CSE came out. Runer112 wants to make Axe color-compatible with Axe 2.0.
Title: Re: Features Wishlist
Post by: ClrDraw on November 22, 2013, 04:57:25 pm
Sorry, I should have checked first.
That would be so cool, good luck Runner112  ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
Title: Re: Features Wishlist
Post by: josh landers on February 21, 2014, 09:53:27 pm
I have a request...
Could we have all the commands rearranged on the catalog so that the axe commands appear first?
I don't know if this will be possible but...
*josh wonders if a TI-wizard could do this
Title: Re: Features Wishlist
Post by: Runer112 on February 21, 2014, 09:57:58 pm
It would definitely be neat to have a feature like that. Fitting such a feature into the already-overflowing Axe though... that's another story. Also, I have absolutely no clue how the catalog hook works so would't really know how to do it myself.

I believe that, partly for this reason, Quigibo tried to assign most commands to tokens that are found in menus so they could be quickly reached once you learn their location.
Title: Re: Features Wishlist
Post by: ti-freak on February 26, 2014, 08:14:07 am
The Axe Parser  is cool :D und very usefull.

You can change the syntax from the "For(Variable,Start,End)" command to "For(Variable,Start,End,Increment)"

"English isn't my first language, so please understand me if something isnt correct.
Title: Re: Features Wishlist
Post by: Streetwalrus on February 26, 2014, 10:05:25 am
You can make a placebo effect by putting variable+increment-1->variable in your loop.
Title: Re: Features Wishlist
Post by: Hayleia on February 26, 2014, 11:36:49 am
I usually write my loops with a While anyway, to be able to put the condition at the End, and only use For() loops as For(const).

Anyway, welcome to the forums ti-freak :)
You can introduce yourself here (http://www.omnimaga.org/index.php?board=10.0).

(also, I hope we won't confuse you with tifreak (http://www.omnimaga.org/index.php?action=profile;u=43) -.-)
Title: Re: Features Wishlist
Post by: Streetwalrus on February 26, 2014, 11:54:43 am
LOL yeah Hayleia I thought the exact same thing. XD
Title: Re: Features Wishlist
Post by: Aspiring on April 01, 2014, 01:46:25 pm
This may already have been suggested but I really don't want to search through 200+ pages.  :P It would be really cool if axe supported compiling axe code into axioms.  When selecting which shell you want to compile for you would simply just need to select axiom.  A #AxiomSub(name, token-that-is-being-replaced, number-of-args) token could be added so that different functions could be added.  This would make so many more axioms show up for axe and also some libs like TheMachine002's glib and many others.  There is also the added bonus that any time you want to use a lib that is written in axe you don't have to wait as long when compiling the code because it is already precompiled.  ;D  By compiling in axioms in axe it means that code that is made for an old version of axe will still work (assuming the required structure of an axiom doesn't change).  I don't know how difficult it would be to implement so maybe it is not possible. (Runner?)


If we had this it may be very helpful to those who are new to axe because could just use tilemapping lib for example instead of having to learn a lot all at once.  Any thoughts anyone?
Title: Re: Features Wishlist
Post by: Runer112 on April 01, 2014, 07:45:04 pm
Reworking how libraries work is a big goal of mine for the theoretical Axe 2.0. For now, Axe libraries will have to suffice, because even if I wanted to improve them, there's basically no space left in the application for it. I'm pretty sure that if I started trying to super optimize things and shuffle code around, the number of bugs and general headaches introduced by the process be too much to handle.

Axe libraries aren't too terrible, anyways. Yeah, they take time to compile, don't let you define your functions as tokens, don't intelligently include only what is used, and don't enforce the number of arguments... but they do work. And they actually have a leg or two up on Axioms in their current state, like being able to define and read constant values. I made very heavy use of them to add customization to GrayLib, which I think is a much better library due to it and wouldn't be as useful as an Axiom.
Title: Re: Features Wishlist
Post by: Aspiring on April 01, 2014, 11:02:18 pm
Sounds like you have a lot you're planning on.  I cannot wait for the next update!   :thumbsup:  (and maybe even axe 2.0)
Title: Re: Features Wishlist
Post by: Streetwalrus on April 02, 2014, 03:32:18 pm
Will Axe 1.x even have an update ?
Title: Re: Features Wishlist
Post by: Digital on April 07, 2014, 07:03:59 am
This may already have been suggested but I really don't want to search through 200+ pages.  :P It would be really cool if axe supported compiling axe code into axioms.  When selecting which shell you want to compile for you would simply just need to select axiom.

Thats what i wanted to say too ;D .

Title: Re: Features Wishlist
Post by: Runer112 on April 07, 2014, 07:23:44 am
This may already have been suggested but I really don't want to search through 200+ pages.  :P It would be really cool if axe supported compiling axe code into axioms.  When selecting which shell you want to compile for you would simply just need to select axiom.

Thats what i wanted to say too ;D .


As my initial response suggested, just use Axe libraries for now. They offer to fill the same need, albeit with different capabilities. Some things about them are a bit more tedious, but functionally they should be okay.
Title: Re: Features Wishlist
Post by: Digital on April 07, 2014, 07:53:23 am
You can add an Menue token like basic, may with different tabs like ti os.
The command can look like this:
Code: [Select]
Menue( ("Title Tab 1","1:...",label,"2:...",label),("Title tab 2","1:...",label,"2:...",label)...
             '-------------------v---------------------'  '-------------------v---------------------'
                                     tab 1                                                       tab 2
Title: Re: Features Wishlist
Post by: Runer112 on April 07, 2014, 12:15:11 pm
You can add an Menü token like basic, may with different tabs like ti os.
The command can look like this:
Code: [Select]
Menue( ("Title Tab 1","1:...",label,"2:...",label),("Title tab 2","1:...",label,"2:...",label)...
             '-------------------v---------------------'  '-------------------v---------------------'
                                     tab 1                                                       tab 2


The OS does not expose a very simple way to generate menus, which is why the feature does not exist. I think this is somewhere on the to do list, but it's a pretty low priority since its ratio of usefulness (medium-low, since it might be nice for quick prototyping, but you can and probably should make nicer looking menus yourself anyways) to difficulty of implementation (medium-high, from what I gather of how menu hooks work) is overall quite low. But if any assembly wizards want to provide the majority of a solution, whether it's as hard as I think it is or if it's really simple, I'll happily include it! That is, if I can fit it. :P
Title: Re: Features Wishlist
Post by: Streetwalrus on April 07, 2014, 12:46:56 pm
This feature has already been suggested and denied anyway IIRC.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on April 08, 2014, 03:34:17 pm
If Axe 2.0 lets you code on the computer, will it allow you to do like in TIGCC and Nspire dev utilities and develop for multiple calcs simultaneously? (eg both the 84+ and 84+CSE) Of course, screen size would be an issue for the 84+CSE, but if in general Axe 84+CSE code is similar to monochrome models, it would make it easier to develop.
Title: Re: Features Wishlist
Post by: Hayleia on April 08, 2014, 04:01:21 pm
That would probably need a lot of conditional comments (to change constants, for example due to screen resolution) but that's better than writing twice the whole code, so I agree that it would be nice :)
Title: Re: Features Wishlist
Post by: Streetwalrus on April 08, 2014, 05:08:18 pm
Yeah, that would be cool. Only graphics related stuff would need to be changed anyway. But some of the tricks we use on monochrome calcs are not possible on the cse due to the slower screen. :/ That would make it challenging for sure.
Title: Re: Features Wishlist
Post by: Digital on April 13, 2014, 08:16:12 am
What about more graphing commands?

A filled circle or an outline box?
And using Fix5, you can define the buffer the text is drawn to.
Title: Re: Features Wishlist
Post by: Runer112 on April 13, 2014, 08:26:49 am
What about more graphing commands?

A filled circle or an outline box?
And if using Fix5, you can define the buffer the text is drawn to.

Those all sound like useful additions. If I can find a way to fit them all into the application, which is slightly bursting at the seams currently, they could happen.
Title: Re: Features Wishlist
Post by: Streetwalrus on April 13, 2014, 08:37:40 am
For an outline box there is already IRect (combine two of these, one to the outer size and one to the inner size centered in the first).
Or if you need speed, HLine/VLine
Title: Re: Features Wishlist
Post by: Runer112 on April 13, 2014, 08:44:41 am
For an outline box there is already IRect (combine two of these, one to the outer size and one to the inner size centered in the first).
Or if you need speed, HLine/VLine

Yeah, if I were to add that command, I'd probably just call the HLine and VLine commands. But the main benefits of a native command would be that I could make the handling a fair amount smaller and faster, and possibly even reuse some clipping information between calls for added speed.
Title: Re: Features Wishlist
Post by: Streetwalrus on April 13, 2014, 10:40:56 am
Oh that sounds cool. Don't forget rounded corners then. ;)
Title: Re: Features Wishlist
Post by: GinDiamond on April 29, 2014, 09:29:39 am
Slight necropost:

Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?
Title: Re: Features Wishlist
Post by: Eeems on April 29, 2014, 10:25:05 am
Slight necropost:

Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?
The last update was on 2013-10-25 and I'm sure when there are some other big bugs out there Runer112 will update it again. Axioms are meant to be released by third parties for the most part. So release of Axioms would depend on people actually making one.
Title: Re: Features Wishlist
Post by: Runer112 on April 29, 2014, 12:31:07 pm
Slight necropost:

Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?

I'm working 45 hours per week in an internship right now, so that takes up most of my time. And when I am free at home, I'm usually not in the mindset to deal with big, complicated coding projects like Axe when that's what I did at work each day for 9 hours. So that's largely why not much progress has been made on Axe lately. This internship ends in June, but I'll immediately be back in classes, so whether or not that'll free up my mind enough to seriously work on Axe is uncertain.

Regarding Axioms/libraries, Eeems is right in suggesting that they can me made by anyone, not just myself. I've certainly had ideas of making a tilemapping Axe library, but there's no reason it has to come from me. It could come from you. :P

Tying that idea back into Axe, if any capable assembly coder offers to write a routine of some sort and I think it would be good to include that in Axe, I would certainly accept their offer and add in their routine. So even Axe development isn't necessarily frozen by my lack of time to devote to it.
Title: Re: Features Wishlist
Post by: Sorunome on April 29, 2014, 12:32:20 pm
/me prods multi-page app support :P
Like when defining a static pointer you say on which page it is :P
Title: Re: Features Wishlist
Post by: Streetwalrus on April 29, 2014, 12:41:30 pm
Yeah at least for data multi page apps would be awesome.
Just make it so that we can add a new page with a token and all the data following will be on that page. And a function to swap the first memory bank of course.
Title: Re: Features Wishlist
Post by: Runer112 on April 29, 2014, 01:03:58 pm
/me prods multi-page app support :P
Like when defining a static pointer you say on which page it is :P

As I've said in the past, multi-page apps would require a lot of internal redesign. Although it would be a very worthwhile feature, I dread the idea of trying to force that capability into Axe in its current state; it would be more trouble than it's worth. That's why this is a feature I've deferred to the hypothetical Axe 2.0.

If you really want to get crazy, it would be possible to build some system which appends the data onto the end of Axe-compiled applications computer-side. If you can assure that no data crosses a page boundary, you can then hackily read/copy it with files.

Yeah at least for data multi page apps would be awesome.
Just make it so that we can add a new page with a token and all the data following will be on that page. And a function to swap the first memory bank of course.

Although Axe is pretty low level, I don't want it to be so low level as to making users manually swap memory banks to access data in multi-page applications. So I don't think I'd add such a command to native Axe. There's also still the problem of simply generating the multi-page application in the first place, which Axe's internals really can't handle.
Title: Re: Features Wishlist
Post by: Streetwalrus on April 29, 2014, 02:33:52 pm
Hmm okay. The page swap function would have been limited to the extra app pages with my suggestion but w/e. :P
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 09:17:40 am

Hi ! I've been using Axe for one year now (since version 1.0.0), and I love it !
It's way much faster than TI-Basic, and it's even easier to use ! Thanks for making Axe Parser !
I have some little ideas to improve it... Here's my contribution !


First of all, Axe Parser should check if there's any backup kept in RAM and either 1] show it in the "Compile" list or 2] ask to archive it. Because one day, just after compiling, it asked me for "Garbage Collect" like it does sometimes, and I answered "no" by mistake. I then thought my source was lost, because the source program was removed and its backup wasn't shown in the compile list (as it wasn't archived). I spent one hour to write the full source code again from memory, beause I didn't know the backup was kept in RAM !


I have an idea to improve the drawing functions... I think that games made with Axe Parser are sometimes slow, especially when they use grayscale graphics on a TI-83+, without the "Full" mode. So why not adding new drawing functions like "Pt-On(", "Pt-Off(", etc. but wich draws sprites only on full bytes of the buffer, each 8 pixels, for 0<=X<=11 ? These functions could be accessed by adding a letter to the other drawing functions' name, "C" for example (stands for "column" and "clipped"), and could be named "CPt-On(", "CPt-Off(", "CPt-Change(", "CPt-Mask(", "CPt-Get("... Also, you could add "CHorizontal +/-" and "CVertical +/-" to move the screen by 8 pixels. I wrote all these drawing functions in assembly if you want (although they may not be fully optimised).


And to improve the datas, I think it could be great if we were able to make datas with binary values. To differentiate them with hexadecimal values, you could add the prefix "pi" to the data, like "pi[0101101010011001]->GDB1".


I imagined others features and functions, but they will be much more complicated to do...
Title: Re: Features Wishlist
Post by: Hayleia on August 01, 2014, 09:45:59 am
And to improve the datas, I think it could be great if we were able to make datas with binary values. To differentiate them with hexadecimal values, you could add the prefix "pi" to the data, like "pi[0101101010011001]->GDB1".
This is already possible with Data(pi00101001,pi11010011)→GDB1

I have an idea to improve the drawing functions... I think that games made with Axe Parser are sometimes slow, especially when they use grayscale graphics on a TI-83+, without the "Full" mode. So why not adding new drawing functions like "Pt-On(", "Pt-Off(", etc. but wich draws sprites only on full bytes of the buffer, each 8 pixels, for 0<=X<=11 ? These functions could be accessed by adding a letter to the other drawing functions' name, "C" for example (stands for "column" and "clipped"), and could be named "CPt-On(", "CPt-Off(", "CPt-Change(", "CPt-Mask(", "CPt-Get("... Also, you could add "CHorizontal +/-" and "CVertical +/-" to move the screen by 8 pixels. I wrote all these drawing functions in assembly if you want (although they may not be fully optimised).
I am not really convinced that the slowness only comes from the drawing commands. Or more, I am not convinced that changing them to be more specific would improve the speed that much. Watch for example Robbox (http://www.omnimaga.org/ti-z80-calculator-projects/%28axe%29-robbox/msg321238/#msg321238) running, I don't think it is that slow even though it uses 4 lvl greyscale, and runs at 6 MHz (without Full).

Both CVertical commands can be written in Axe with a Copy by the way. One CHorizontal can also be written with a Copy in a loop (see spoiler).

Spoiler For Spoiler:
L6+1
For(64)
 Copy(,-1,11)+1
End
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 10:54:43 am
This is already possible with Data(pi00101001,pi11010011)→GDB1
Indeed, that's right, I didn't think of it... Thanks !

I am not really convinced that the slowness only comes from the drawing commands. Or more, I am not convinced that changing them to be more specific would improve the speed that much. Watch for example Robbox running, I don't think it is that slow even though it uses 4 lvl greyscale, and runs at 6 MHz (without Full).
You're right, I know that slowness hardly ever comes from a lack of optimizations by the programmer, and I didn't want to say "Axe Parser is slow" either - it's definitely not the case ! Nevertheless, it's always better (for the speed and for the program's size) to have the exact function needed. See spoiler :

Spoiler For Spoiler:
Axe Parser compiles your code in assembly into :
Code: [Select]
LD   HL, $9341
LD   B, 64
Loop:
PUSH BC
PUSH HL
LD   HL, -1
LD   BC, 11
EX   DE, HL
POP  HL
LDIR
INC  HL
POP  BC
DJNZ Loop

And this takes 21 bytes and 20k clock cycles. Whereas adding a new CHorizontal function already written in assembly allows it to be much more optimized. The example under takes only 11 bytes, and approximately 14k clock cycles, that is to say a quarter less !

Code: [Select]
PUSH  HL
LD    DE, 96
ADD   HL, DE
POP   DE
LD    BC, 768-96
LDIR

By the way, Robbox seems to be a good game :) I'll try it. EDIT : It is !
Title: Re: Features Wishlist
Post by: Hayleia on August 01, 2014, 11:06:42 am
Nevertheless, it's always better (for the speed and for the program's size) to have the exact function needed. See spoiler.
In my opinion, Axe is some kind of ASM helper. As in you use it to make ASM programs without necessarily always writing ASM. Which means that when you absolutely need speed, you use Asm() (which is what you mentionned in your other post, and what I did in AudaciTI). And as in you make programs in Axe and optimize them until you know how everything works on the ASM side, then you can switch to ASM.

That works the other way round to for the first "As in", as in you use ASM when you can't use Axe. In other words, they are fellow languages that can be used together.

But what you say here it completely true for pure Axe programmers.

By the way, Robbox seems to be a good game :) I'll try it.
Erm, it is not finished yet so you'll probably be disappointed :P
I should get the same horizontal scrolling as the one I used in Flappy Bird btw, without white colums on the sides.

Also, sorry for forgetting my duty.
Welcome to Omnimaga Zemmargorp.
You can introduce yourself here (http://www.omnimaga.org/introduce-yourself!/) if you didn't already :)
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 11:28:44 am


But what you say here it completely true for pure Axe programmers.
That's why I suggested to add these new drawing functions. We're in "Features Wishlist", after all !


Erm, it is not finished yet so you'll probably be disappointed  :P
No, it's really good ! I'm used to starting writing new programs and never finishing them (unfortunately !), and Robbox is a good game, even if it's not finished.


Also, sorry for forgetting my duty.
Welcome to Omnimaga Zemmargorp.
You can introduce yourself here if you didn't already  :)
That's fine :) And thank you, Hayleia !
No, I didn't do it, but I don't intend to do it.


By the way, I apologize to everybody for the two lasts messages I posted, which had nothing to do with this topic  ;D  !
Title: Re: Features Wishlist
Post by: Runer112 on August 01, 2014, 12:03:45 pm
Hi ! I've been using Axe for one year now (since version 1.0.0), and I love it !
It's way much faster than TI-Basic, and it's even easier to use ! Thanks for making Axe Parser !
I have some little ideas to improve it... Here's my contribution !

Thanks for the praise! It's always nice to occasionally be reminded that Axe is appreciated. And it's great to see you have such an interest in it that you're already coming with suggestions backed by assembly knowledge.

First of all, Axe Parser should check if there's any backup kept in RAM and either 1] show it in the "Compile" list or 2] ask to archive it. Because one day, just after compiling, it asked me for "Garbage Collect" like it does sometimes, and I answered "no" by mistake. I then thought my source was lost, because the source program was removed and its backup wasn't shown in the compile list (as it wasn't archived). I spent one hour to write the full source code again from memory, beause I didn't know the backup was kept in RAM !

Weird... backups in RAM indeed aren't displayed in the list. I've made a note to fix that.

I have an idea to improve the drawing functions... I think that games made with Axe Parser are sometimes slow, especially when they use grayscale graphics on a TI-83+, without the "Full" mode. So why not adding new drawing functions like "Pt-On(", "Pt-Off(", etc. but wich draws sprites only on full bytes of the buffer, each 8 pixels, for 0<=X<=11 ? These functions could be accessed by adding a letter to the other drawing functions' name, "C" for example (stands for "column" and "clipped"), and could be named "CPt-On(", "CPt-Off(", "CPt-Change(", "CPt-Mask(", "CPt-Get("... Also, you could add "CHorizontal +/-" and "CVertical +/-" to move the screen by 8 pixels. I wrote all these drawing functions in assembly if you want (although they may not be fully optimised).

I did a quick analysis of the sprite routines, and the amount of extra time they spend compared to aligned routines is actually not that much. The clipping code is pretty good about finishing fast if no work needs to be done, and if the x coordinate is a multiple of 8, the code switches to an aligned output code path with no rotates and such. My quick estimate suggests that the total overhead when drawing aligned sprites is only about 15-20%, which, to me, doesn't warrant adding entirely new versions of all the sprite commands. There are other contributing factors as well; they'd probably only be used by a handful of more advanced coders, and they would take up a lot of extra space in the application, which is already severely lacking.

Functions to shift the screen by more than one pixel at a time have definitely been on my to-do list for a while. But, like with the sprite situation, I think I'd prefer a general unaligned routine that's more capable and appealing to the average coder, but which uses a faster code path for aligned shifts. I should really start working down the to-do list, it's massive...

And to improve the datas, I think it could be great if we were able to make datas with binary values. To differentiate them with hexadecimal values, you could add the prefix "pi" to the data, like "pi[0101101010011001]->GDB1".

Hayleia answered this one pretty well already. Although not quite as compact as a blob of binary digits, Data(π01011010,π10011001) would provide this functionality. If you're entering binary data, you probably already aren't too worried about compactness, anyways.

I imagined others features and functions, but they will be much more complicated to do...

Shoot. :P
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 12:53:21 pm

Thanks, Runer112 ! So here's the complicated stuff I thought about...


First, you should add a command (and maybe associate it with the "Prompt" token) which inputs a number, because it's useful and a lot of people need this ! Probably use the "input" command, and then parse the returned string to convert it into a 2-byte number. You can make it able to convert the number into a float. For example, the command's syntax could be "Prompt A" to get a 2-byte number, and "Prompt float{A}" to get a float number located at the address pointed by A.


Talking about float numbers, here's another idea : it could be great to add the support in Axe of float numbers, by using the OS's bcalls. The tokens could be Axe's regular math tokens, with a dot just after, and the values would be located at the addresses pointed by the variables. For example, "A*.B->.C" would be compiled liked "Copy(A, OP1, 9):Copy(B, OP2, 9):bcall(FPMult):Copy(OP1, C, 9)". But maybe use the bcalls Mov9ToOP1/OP2 instead of Copy(VAR, OP1/OP2, 9).


I've discovered there's an Axiom that allows this kind of manipulation with the OS's float variables, but it would be better to have it the way I described it, without having to use the OS's variables. Because it leads to creating the variables if they do not exists, looking in the VAT for the variable's address, and lose time. It's better if we use adresses of free memory for temporary calculations (in safe RAM areas, for example) and it's even better because it doesn't modify the OS's variables, if the calculator's owners stored important data inside them. It makes me thinking that it would be great to have a way to allocate/deallocate memory to a program, like "GetCalc(" does, but without having to specify a variable name, only the size needed.


And, talking about memory, why not also add a way to save the program's self changes from $9D95 to the compiled program ? It can be usefull for people developping games, instead of using an appvar only for the two bytes of the best score !


And I kept the best for the end : to implement a "Menu(" function, by using the OS's DIALOG bcalls ! I know you probably already thought of it, and it may be very complicated, but it's an important and so useful command ! I saw an amazing use of these bcalls in Brandonw's calcstuff, in the compressed folder "ddemo.zip", described in "dialogNotes.txt"... But it would be great to have at least the equivalent of the TI-Basic "Menu(" command.
Title: Re: Features Wishlist
Post by: Hayleia on August 01, 2014, 01:02:02 pm
And, talking about memory, why not also add a way to save the program's self changes from $9D95 to the compiled program ? It can be usefull for people developping games, instead of using an appvar only for the two bytes of the best score !
If you use a smart shell that supports writeback, which is I guess the case for most people playing ASM games, you don't need to worry about making your program do that writeback itself ;)
A lot of Axe programs use writeback for saving, they don't all use appvars.

And I kept the best for the end : to implement a "Menu(" function, by using the OS's DIALOG bcalls ! I know you probably already thought of it, and it may be very complicated, but it's an important and so useful command ! I saw an amazing use of these bcalls in Brandonw's calcstuff, in the compressed folder "ddemo.zip", described in "dialogNotes.txt"... But it would be great to have at least the equivalent of the TI-Basic "Menu(" command.
I think the problem is not that it is complicated, but more that it is a good learning experience for beginners to make their own menus, and not a good experience for non beginners to have an ugly menu in their program when they can have an awesome wheel such as that in TinyCraft :P
But it's true that for debugging purposes at least, having a "fast" menu command would be great :)
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 01:39:17 pm
If you use a smart shell that supports writeback, which is I guess the case for most people playing ASM games, you don't need to worry about making your program do that writeback itself  ;)
A lot of Axe programs use writeback for saving, they don't all use appvars.
Yes, but the game should always be able to save the score, even for people who don't have a smart shell ! And a shell that automatically saves the program's changes can also save other data that has been modified and shouldn't be saved back !

I think the problem is not that it is complicated, but more that it is a good learning experience for beginners to make their own menus, and not a good experience for non beginners to have an ugly menu in their program when they can have an awesome wheel such as that in TinyCraft  :P
But it's true that for debugging purposes at least, having a "fast" menu command would be great  :)
Well, it depends ! It would be very complicated to implement in Axe a way to add menus (using the OS's bcalls) like Brandown did in assembly : seriously, try his program (http://brandonw.net/calcstuff/ddemo.zip) (or see it working (http://brandonw.net/calcstuff/dialog.gif)), it's amazing ! I agree with you, it's a good experience for beginners to learn how to make a menu, but it would be better to be able to make menus faster in little projects ! And personally, I like the TI default's menu style and his simple design. Obviously, for big games, nice menus are an important point.

And I forgot to talk about another feature I thought about. In some cases, it could be useful to have Axe's variables located in a specified data, to save/load default values easily with the "Copy(" command. I think the syntax "[X Y S ]rGDB0" is great. And it could allow the programmer to add customs variables, with two-letters name : if he writes "[XpYpXeYe]rGDB0", he could then use the additional variables Xp, Yp, Xe, and Ye. (It's not that 27 variables are not enough, it's rather that I prefer to use variables with a name that evokes me something, and sometimes I need several variables to memorize X and Y coordinates !)
EDIT : It is already possible, by doing "ADDR°NAME".
Title: Re: Features Wishlist
Post by: Runer112 on August 01, 2014, 02:42:05 pm
First, you should add a command (and maybe associate it with the "Prompt" token) which inputs a number, because it's useful and a lot of people need this ! Probably use the "input" command, and then parse the returned string to convert it into a 2-byte number. You can make it able to convert the number into a float. For example, the command's syntax could be "Prompt A" to get a 2-byte number, and "Prompt float{A}" to get a float number located at the address pointed by A.

I'm hesitant to add built-in input routines because there are so many formats in which a programmer may expect their input: decimal/hexadecimal, signed/unsigned, integer/float, home/graph screen, maximum number of digits... it goes on. Many of these would require a fair amount of custom code not provided by the OS. I already don't like the existing input command because it's very non-ideal, clearing the entire home screen, reading in tokens rather than characters, and not allowing any sort of keypress-time validation (for instance, only allowing digits to be entered for a number). So input is something I figure is best left to the programmer, who knows exactly what they want and how they want it to be input... Unless you know how to remedy my woes with input, in which case I'd love to include some more powerful default input commands that are mildly robust and programmer- and user-friendly.

Talking about float numbers, here's another idea : it could be great to add the support in Axe of float numbers, by using the OS's bcalls. The tokens could be Axe's regular math tokens, with a dot just after, and the values would be located at the addresses pointed by the variables. For example, "A*.B->.C" would be compiled liked "Copy(A, OP1, 9):Copy(B, OP2, 9):bcall(FPMult):Copy(OP1, C, 9)". But maybe use the bcalls Mov9ToOP1/OP2 instead of Copy(VAR, OP1/OP2, 9).


I've discovered there's an Axiom that allows this kind of manipulation with the OS's float variables, but it would be better to have it the way I described it, without having to use the OS's variables. Because it leads to creating the variables if they do not exists, looking in the VAT for the variable's address, and lose time. It's better if we use adresses of free memory for temporary calculations (in safe RAM areas, for example) and it's even better because it doesn't modify the OS's variables, if the calculator's owners stored important data inside them. It makes me thinking that it would be great to have a way to allocate/deallocate memory to a program, like "GetCalc(" does, but without having to specify a variable name, only the size needed.

I absolutely agree that Axe could use floating point support. But if I'm going to add it, I'm going to do it right. That means growing out of the everything-is-a-16-bit-integer system and providing actual types. So for now, ugly Axioms will have to suffice. But if and when Axe 2.0 comes out, this will be included.

And, talking about memory, why not also add a way to save the program's self changes from $9D95 to the compiled program ? It can be usefull for people developping games, instead of using an appvar only for the two bytes of the best score !

If a program is in RAM when it is executed, it will simply be moved to $9D95, executed, and then moved back. So any changes made to the program during execution will be persisted because they were written directly to the sole copy of the program.

If a program is in archive when it is executed, then it must have been executed by a shell or something similar that either unarchived or copied the program to RAM. If it was unarchived, then just like normally running a program from RAM, writeback is implicit. If it was copied, then writeback must be performed by deleting the original and archiving the copy, which I believe is done by all shells that use this method.

So no matter how you execute a program, writeback should occur. In fact, the only problem should sometimes be preventing writeback rather than providing it. But this is something unavoidable that the programmer has to work around. Generally, the appropriate thing to do with data that you don't want to be written back is to locate it in RAM outside of your program.

And I kept the best for the end : to implement a "Menu(" function, by using the OS's DIALOG bcalls ! I know you probably already thought of it, and it may be very complicated, but it's an important and so useful command ! I saw an amazing use of these bcalls in Brandonw's calcstuff, in the compressed folder "ddemo.zip", described in "dialogNotes.txt"... But it would be great to have at least the equivalent of the TI-Basic "Menu(" command.

I'd love for this to exist as well. I just have absolutely no clue how the OS dialog/menu system works, so have been unable to try to add it myself. If you think you know enough about it to be able to contribute this feature, that would be awesome.

And I forgot to talk about another feature I thought about. In some cases, it could be useful to have Axe's variables located in a specified data, to save/load default values easily with the "Copy(" command. I think the syntax "[X Y S ]r->GDB0" is great. And it could allow the programmer to add customs variables, with two-letters name : if he writes "[XpYpXeYe]r->GDB0", he could then use the additional variables Xp, Yp, Xe, and Ye. (It's not that 27 variables are not enough, it's rather that I prefer to use variables with a name that evokes me something, and sometimes I need several variables to memorize X and Y coordinates !)

Axe's letter variables are stored in contiguous memory in alphabetical order, and you can retrieve the address of any variable with the °A syntax. So reading/storing contiguous variable values in bulk is absolutely possible. Perhaps I could think if there's some easy way to enable the default one-letter variables to be relocated so that variables not in contiguous alphabetical order can occupy contiguous memory, but it doesn't seem like a high priority to me. Especially because you can locate variables with non-contiguous names in contiguous memory by reading on.

Custom named variables were one of the biggest additions in Axe 1.0.0, and have as such been around for quite a while. Just as you use the °VAR syntax to retrieve the address of a variable, you use the addr→°VAR syntax to "store" a constant address of a variable so that VAR is then a variable that exists at the constant address addr. This same syntax is also Axe's mechanism for defining constants; store a constant value as the "address" of a "variable," and just read back the "address" in your code, never using it as an actual variable. However, note that, because of weird internal compiler reasons, the constant address cannot be a reference to a data section inside your program.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 03:57:01 pm
Unless you know how to remedy my woes with input, in which case I'd love to include some more powerful default input commands that are mildly robust and programmer- and user-friendly.
Sorry to get your hopes up, but that's not the case ! However, if one day someone finds easily how to create custom menus, it would be interesting if somebody else could make an input function which accepts these custom menus while the user enter the data. (But there's a lot of conditions in this last sentence...)

I absolutely agree that Axe could use floating point support. But if I'm going to add it, I'm going to do it right. That means growing out of the everything-is-a-16-bit-integer system and providing actual types. So for now, ugly Axioms will have to suffice. But if and when Axe 2.0 comes out, this will be included.

In fact, it raises a big question : should Axe become closer to TI-Basic with floating point maths, or should it stay closer to assembly and 16/8 bits maths ? Both cases are interesting, it depends what kind of program people make. But for beginners, being forced to use 16-bit is a good thing, because otherwise they would keep using floating point maths where they could use 16-bits maths, it wouldn't be optimized, and Axe would become a sort of TI-Basic II.

If a program is in RAM when it is executed, it will simply be moved to $9D95, executed, and then moved back.So no matter how you execute a program, writeback should occur. In fact, the only problem should sometimes be preventing writeback rather than providing it.

No, without any shell, it's not the case ! Even if the program is stored in RAM ! Personnally, I use Noshell on my TI-83+ (OS 1.19), and I tried a little program "{GDB0}++:Disp {GDB0}>Dec,i", and the output is always the same ! But maybe, yeah, as a lot of people are using shells with the write-back option enabled, they face the opposite problem (which is easier to solve, by the way).


I'd love for this to exist as well. I just have absolutely no clue how the OS dialog/menu system works, so have been unable to try to add it myself. If you think you know enough about it to be able to contribute this feature, that would be awesome.

So do I ! I don't know anything about it neither (except I found two interesting documents in Brandown's calcstuff, and I should start trying to decrypt it), but if one day I succeed to understand how it works, I'll tell you.

Custom named variables were one of the biggest additions in Axe 1.0.0, and have as such been around for quite a while. Just as you use the °VAR syntax to retrieve the address of a variable, you use the addr→°VAR syntax to "store" a constant address of a variable so that VAR is then a variable that exists at the constant address addr.

Yes, sorry, just after posting my message I saw that it was possible to declare a variable anywhere using this syntax. But I never heard of it before ! Seems like nobody was informed, as I never saw a source using it.
Title: Re: Features Wishlist
Post by: Matrefeytontias on August 01, 2014, 04:13:07 pm
You should look into more sources then. I didn't do a single program that doesn't use them.

Also for your input request, there is something like that already that has been done by nikitouzz : http://www.omnimaga.org/the-axe-parser-project/input-routine-done-!/
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 04:36:59 pm

You should look into more sources then. I didn't do a single program that doesn't use them.

Really ? *Goes looking into Matrefeytontias first's program found* Uh, yes ! I never noticed it... Perhaps, after all, I haven't opened so much sources and taken care to them. Anyway, that's a good discovery for me !


Also for your input request, there is something like that already that has been done by nikitouzz :
http://www.omnimaga.org/the-axe-parser-project/input-routine-done-!/ (http://www.omnimaga.org/the-axe-parser-project/input-routine-done-!/)
Wow, this routine is really nice ! But I think that Runer112 wanted to find a TI-like input command, which behaves exactly like the input command, but with characters instead of tokens, without the OS's menus, and without the OS's ... Well, maybe which behaves not exactly like the default command, but I think he was looking for a TI-looks-like input command, which uses characters instead of tokens, which uses the big font on the text screen, which is able to scroll, etc. Hum... I don't really know, in fact.
Title: Re: Features Wishlist
Post by: Runer112 on August 01, 2014, 05:08:58 pm
In fact, it raises a big question : should Axe become closer to TI-Basic with floating point maths, or should it stay closer to assembly and 16/8 bits maths ? Both cases are interesting, it depends what kind of program people make. But for beginners, being forced to use 16-bit is a good thing, because otherwise they would keep using floating point maths where they could use 16-bits maths, it wouldn't be optimized, and Axe would become a sort of TI-Basic II.

Integer types would exist in tandem with floating point types, and you would pick what type different variables/values are. It would be very similar to a language like C.

No, without any shell, it's not the case ! Even if the program is stored in RAM ! Personnally, I use Noshell on my TI-83+ (OS 1.19), and I tried a little program "{GDB0}++:Disp {GDB0}>Dec,i", and the output is always the same ! But maybe, yeah, as a lot of people are using shells with the write-back option enabled, they face the opposite problem (which is easier to solve, by the way).

I'm not sure what I was thinking... You're absolutely correct that writeback doesn't occur when executing programs through the OS. TI just copies the program, runs the copy, and then deletes the copy.

Noshell has an option to toggle writeback, so it should support it. Also, I'd highly recommend replacing Noshell with zStart (http://www.ticalc.org/archives/files/fileinfo/456/45694.html). It does everything Noshell does, plus so much more. Notable features for Axe developers are the ability to edit programs without unarchiving them, so you never have to worry about losing your source in a RAM clear, lots of helpful editor hooks like jumping to labels by name, and shortcuts to compile your program without even leaving editor. Also, zStart runs automatically after RAM clears, so all of its hooks and behaviors reinstate themselves without needing to run it every time.

Anyways, back to the topic at hand. Generally, as long as you run the program through any sort of shell/archived program running utility, writeback will be supported. So if you want to make sure writeback occurs, just compile your program with the MirageOS or DoorsCS header (I recommend the former, it's more widely accepted) to prevent it from being run by the OS. Everybody should really have a shell/archived program running utility on their calculator, so imposing this limitation shouldn't be a problem.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 06:13:49 pm

Integer types would exist in tandem with floating point types, and you would pick what type different variables/values are. It would be very similar to a language like C.
Yes, I know that you'd keep 16-bit variables type, but I think that adding full floating number support will encourage beginners (who already used floating numbers in TI-Basic) to use it instead of learning how to use 16-bit numbers, and all its limitations !


Noshell has an option to toggle writeback, so it should support it. Also, I'd highly recommend replacing Noshell with zStart. It does everything Noshell does, plus so much more. Notable features for Axe developers are the ability to edit programs without unarchiving them, so you never have to worry about losing your source in a RAM clear, lots of helpful editor hooks like jumping to labels by name, and shortcuts to compile your program without even leaving editor. Also, zStart runs automatically after RAM clears, so all of its hooks and behaviors reinstate themselves without needing to run it every time.
I'm quite satisfied with Noshell. I've already heard of zStart, but I think it uses more than a single flash page ! And my sources program are always unarchived (with some backups on my computer), in case of RAM cleared (this occurs quite often).


Anyways, back to the topic at hand. Generally, as long as you run the program through any sort of shell/archived program running utility, writeback will be supported. So if you want to make sure writeback occurs, just compile your program with the MirageOS or DoorsCS header (I recommend the former, it's more widely accepted) to prevent it from being run by the OS.
It's a shame to prevent the program from being run by the OS just if you want to make sure writeback occurs ! Instead of preventing the user to execute the program if he hasn't got any shell, it's better to add a writeback routine inside the program ! I wrote a short code, which works when the program is shelled by the OS :
Spoiler For Code:
At the beginning of the program :
Code: [Select]

bcall(_PushRealO1)
And at its end :
Code: [Select]
bcall(_PopRealO1)
bcall(_ChkFindSym)
JR    C, SaveError  ;Not found !
XOR   A
CP    B
JR    NZ, SaveError ;Archived  !
LD    HL, DE
LD    C, (HL)
INC   HL
LD    B, (HL)
LD    HL, $9D95
LDIR
:SaveError
RET


Currently, I'm trying to adapt Brandown's code for menus to use it like menus in TI-Basic. It works great (only with less than 8 options) but I can't get the highlighted option's index, I don't know which choice was chosen !
Title: Re: Features Wishlist
Post by: Runer112 on August 01, 2014, 07:15:12 pm
I'm quite satisfied with Noshell. I've already heard of zStart, but I think it uses more than a single flash page ! And my sources program are always unarchived (with some backups on my computer), in case of RAM cleared (this occurs quite often).

zStart is also only one page. It's basically objectively better than Noshell, and I would once again recommend you grab it. :P

It's a shame to prevent the program from being run by the OS just if you want to make sure writeback occurs ! Instead of preventing the user to execute the program if he hasn't got any shell, it's better to add a writeback routine inside the program ! I wrote a short code, which works when the program is shelled by the OS :
Spoiler For Code:
At the beginning of the program :
Code: [Select]

bcall(_PushRealO1)
And at its end :
Code: [Select]
bcall(_PopRealO1)
bcall(_ChkFindSym)
JR    C, SaveError  ;Not found !
XOR   A
CP    B
JR    NZ, SaveError ;Archived  !
LD    HL, DE
LD    C, (HL)
INC   HL
LD    B, (HL)
LD    HL, $9D95
LDIR
:SaveError
RET

That actually looks relatively appealing. However, the potential problem I see is that, when run by a shell, it may not be the case that OP1 contains the name of the program being executed. Best case scenario, it doesn't contain the name of a variable, and no writeback occurs. Worst case scenario, it contains the name of another variable, perhaps Ans or some shell appvar, and then the writeback clobbers RAM. Maybe I (or you) can round up all the main shells (MirageOS, DoorsCS, CrunchyOS, Noshell, CalcUtil, and zStart) and test this. If OP1 turns out not to be reliable, it would be worth checking progCurrent, progToEdit, and nameBuff.

EDIT: Alternatively, it may be possible to detect if the OS or a shell launched the program.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 01, 2014, 08:07:23 pm

zStart is also only one page.
I see... Thanks for the tip ! *Removes Noshell and installs zStart*


However, the potential problem I see is that, when run by a shell, it may not be the case that OP1 contains the name of the program being executed. Best case scenario, it doesn't contain the name of a variable, and no writeback occurs. Worst case scenario, it contains the name of another variable, perhaps Ans or some shell appvar, and then the writeback clobbers RAM. Maybe I (or you) can round up all the main shells (MirageOS, DoorsCS, CrunchyOS, Noshell, CalcUtil, and zStart) and test this. If OP1 turns out not to be reliable, it would be worth checking progCurrent, progToEdit, and nameBuff.
EDIT: Alternatively, it may be possible to detect if the OS or a shell launched the program.
I know. It's risky. And even if it may be possible to detect if it's a shell which launched the program, it maybe also be possible that the shell hasn't got write-back enabled. And if this shell doesn't set OP1 = program's name...  :banghead:  And there's a lot of shells to try. And we can't assure a complete reliable routine, which will works for future shells ! Rather hope the user uses a shell with write-back enabled, especially if the write-back feature is used to save the game's best score.


Regarding the OS's DIALOG bcalls, I've achieved to find a way to know which item was chosen by the user, in menus like TI-Basic provides. I just need to improve a little the code source... I'll publish it somewhere, but not now.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 02, 2014, 11:38:22 am
Maybe I (or you) can round up all the main shells (MirageOS, DoorsCS, CrunchyOS, Noshell, CalcUtil, and zStart) and test this.

I've tried "Disp e8478" with some of these shells, plus Ion you forgot  ;) , and here are the results : it works without any shell, with Noshell, with Mirage OS (v1.2), with zStart (v.1.3.013_83). I wasn't able to download CrunchyOS (I don't know why). Unluckily, CalcUtil and DoorsCS don't work in the emulator I'm using. It doesn't works with Ion (at least for v1.6), but Ion clears OP1's value, so there's no problem.



Regarding the OS's DIALOG bcalls, I've achieved to find a way to know which item was chosen by the user, in menus like TI-Basic provides. I just need to improve a little the code source... I'll publish it somewhere, but not now.

After two hours of bug-tracking, I've solved a problem I had with the "TI-83+ Flash Debugger". Good to know : sometimes it says some data is located into RAM, whereas it's in Flash ! Nevertheless, I think I've got a stable menu routine ! There's still some little work to do, but I've got a great base (thanks to Brandown and his DIALOG notes and program). Where can I publish it ? Do I make a new topic inside "The Axe Parser project" ? Because if we want to be able to use these bcalls in a reliable way, I'll probably need help from experimented assembly programmers...
Title: Re: Features Wishlist
Post by: Runer112 on August 02, 2014, 12:18:06 pm
I've tried "Disp e8478" with some of these shells, plus Ion you forgot  ;) , and here are the results : it works without any shell, with Noshell, with Mirage OS (v1.2), with zStart (v.1.3.013_83). I wasn't able to download CrunchyOS (I don't know why). Unluckily, CalcUtil and DoorsCS don't work in the emulator I'm using. It doesn't works with Ion (at least for v1.6), but Ion clears OP1's value, so there's no problem.

Using TI's flash debugger, eh? I'd recommend grabbing a much better community-made emulator. My emulator of choice is Wabbitemu (http://wabbit.codeplex.com/). I'll probably run these checks, too.

Regarding the OS's DIALOG bcalls, I've achieved to find a way to know which item was chosen by the user, in menus like TI-Basic provides. I just need to improve a little the code source... I'll publish it somewhere, but not now.
After two hours of bug-tracking, I've solved a problem I had with the "TI-83+ Flash Debugger". Good to know : sometimes it says some data is located into RAM, whereas it's in Flash ! Nevertheless, I think I've got a stable menu routine ! There's still some little work to do, but I've got a great base (thanks to Brandown and his DIALOG notes and program). Where can I publish it ? Do I make a new topic inside "The Axe Parser project" ? Because if we want to be able to use these bcalls in a reliable way, I'll probably need help from experimented assembly programmers...

That's great! Go ahead and make a new topic in this board with your developments so far. I can somewhat figure out how this all works too, we can get it polished up and ready to go into Axe.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 02, 2014, 12:25:38 pm
Using TI's flash debugger, eh? I'd recommend grabbing a much better community-made emulator. My emulator of choice is Wabbitemu (http://wabbit.codeplex.com/). I'll probably run these checks, too.
I've already installed Wabbitemu, but it's not so stable (for me, the latest Axe version doesn't work on it). And TI's flash debugger has a lot of useful features for assembly developers : disassembly, see RAM, etc. No, don't run these checks, it's a bit pointless since there's no ideal way to provide a reliable write-back.

That's great! Go ahead and make a new topic in this board with your developments so far. I can somewhat figure out how this all works too, we can get it polished up and ready to go into Axe.
I'm so excited ! Let's go...
Title: Re: Features Wishlist
Post by: Runer112 on August 02, 2014, 12:37:35 pm
I've already installed Wabbitemu, but it's not so stable (for me, the latest Axe version doesn't work on it). And TI's flash debugger has a lot of useful features for assembly developers : disassembly, see RAM, etc. No, don't run these checks, it's a bit pointless since there's no ideal way to provide a reliable write-back.

I suspect the problem you're having is that Wabbitemu requires a copy of the boot code/certificate from a real calculator to run 100% accurately. As long as you have a link cable, you should be able to get this easily enough by going to Help > Re-run setup wizard...

And I've never used TI's flash debugger, but I suspect that Wabbitemu's debugging capabilities are as good or better.
Title: Re: Features Wishlist
Post by: Runer112 on August 03, 2014, 03:02:03 pm
By the way, I tried launching programs from a bunch of shells, and I'm not sure how reliable writeback would be. I found tricky things like DoorsCS and CalcUtil putting the name of their appvars in OP1, and Ion sometimes leaving the name of the program in OP1 but pointing to something that's all zeroes... it all seems a bit too unreliable to me.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 04, 2014, 12:02:51 pm
I suspect the problem you're having is that Wabbitemu requires a copy of the boot code/certificate from a real calculator to run 100% accurately. As long as you have a link cable, you should be able to get this easily enough by going to Help > Re-run setup wizard...

And I've never used TI's flash debugger, but I suspect that Wabbitemu's debugging capabilities are as good or better.
I've reinstalled Wabbitemu, if one day I want to take an animated screenshot. Oh, I never noticed it had a debugger, which is quite nice, by the way. But I'm used to TI's flash debugger, and it runs faster on my computer (Wabbitemu is a bit laggy).

By the way, I tried launching programs from a bunch of shells, and I'm not sure how reliable writeback would be. I found tricky things like DoorsCS and CalcUtil putting the name of their appvars in OP1, and Ion sometimes leaving the name of the program in OP1 but pointing to something that's all zeroes... it all seems a bit too unreliable to me.
So do I.
There's no ideal way to provide a reliable write-back.
Title: Re: Features Wishlist
Post by: Hayleia on August 04, 2014, 01:15:06 pm
I've reinstalled Wabbitemu, if one day I want to take an animated screenshot. Oh, I never noticed it had a debugger, which is quite nice, by the way. But I'm used to TI's flash debugger, and it runs faster on my computer (Wabbitemu is a bit laggy).
TilEm also has screenshot capabilities and is said to have a debugger (even though I never used that feature). I don't know if it is faster than Wabbitemu but you can give it a try.
(Note, I am not in favor of any of both, I use Wabbitemu on Windows and TilEm on Linux).
Title: Re: Features Wishlist
Post by: Streetwalrus on August 05, 2014, 06:55:04 am
Tilem seems to be less accurate than Wabbitemu, it's unable to run KnightOS while Wabbit can run it.
Title: Re: Features Wishlist
Post by: Hayleia on August 05, 2014, 08:13:21 am
I already heard someone say that on the contrary, TilEm emulates the hardware better than Wabbitemu. And indeed, I had an error in one of my sources, and TilEm was able to jump to error (with zStart) when Wabbitemu couldn't. So I'd say that sometimes one emulates better and sometimes the other one does.
But as I say, I have no bias for any of them, I use both.
Title: Re: Features Wishlist
Post by: Streetwalrus on August 05, 2014, 11:53:19 am
Hence z80e which aims towards 100% accurate emulation. :P
Title: Re: Features Wishlist
Post by: Eeems on August 05, 2014, 04:25:07 pm
Hence z80e which aims towards 100% accurate emulation. :P
Dat plug. z80e is nowhere near ready for general use though.
Title: Re: Features Wishlist
Post by: Streetwalrus on August 05, 2014, 04:53:08 pm
Yeah I know but it's doing some nice progress.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 07, 2014, 10:16:24 am
Other ideas : in the Axioms, add a way to make commands which accept between n and m arguments. It can, for example, put the args count in the register B (B because it's the only register used by the DJZN command). This would be useful for some commands (like "Menu(", of course  ;D ), because if they are used multiple times with different arguments count, the commands' code will only be added once to the program. Also, maybe add a way to push the arguments after the return address, because it's not very practical the way it is for the person who writes the Axiom  :/
Title: Re: Features Wishlist
Post by: Eeems on August 07, 2014, 10:27:33 am
Other ideas : in the Axioms, add a way to make commands which accept between n and m arguments. It can, for example, put the args count in the register B (B because it's the only register used by the DJZN command). This would be useful for some commands (like "Menu(", of course  ;D ), because if they are used multiple times with different arguments count, the commands' code will only be added once to the program. Also, maybe add a way to push the arguments after the return address, because it's not very practical the way it is for the person who writes the Axiom  :/
You could take a pointer as your argument instead and interpret the memory stored at the pointer instead.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 07, 2014, 11:03:20 am
You could take a pointer as your argument instead and interpret the memory stored at the pointer instead.
Yes, but as the AxiomSDK says, "Puts the data pointer in hl (disables auto-replacements)", it disables the auto-replacements, and I need them. I'm wondering why it's linked  ??? .
Title: Re: Features Wishlist
Post by: Runer112 on August 07, 2014, 03:49:36 pm
Other ideas : in the Axioms, add a way to make commands which accept between n and m arguments. It can, for example, put the args count in the register B (B because it's the only register used by the DJZN command). This would be[/font] useful for some commands (like "Menu(", of course  ;D ), because if they are used multiple times with different arguments count, the commands' code will only be added once to the program.

Support for varargs functions doesn't exist at all in Axe, whether for Axioms or built-in commands. And I'm pretty sure that the current internal structure wouldn't be very amenable to its addition.

As Eeems said, the only real solution for now is to have the user pass in a pointer to some structure containing all the "arguments", like how you'd ape varargs functions in a language like C. Doing such a thing should be relatively straightforward with static data, as you can just include each argument (or a pointer to each argument) in a static data block. You'll notice that this becomes a lot harder with variable data, as you have to dynamically create the argument structure. This wouldn't be much easier for Axe either, which is why it isn't available.

Also, you don't want the feature you're referencing about a data pointer for this. That simply makes the "command" carry data, and using the "command" just returns a pointer to the data.

Also, maybe add a way to push the arguments after the return address, because it's not very practical the way it is for the person who writes the Axiom  :/

This isn't really feasible on the calculator, as it only has one stack pointer and there's no way around stacking up all the arguments and only then calling the routine. Architectures get around this by providing multiple stack pointers, one for arguments and one for return vectors, or by providing instructions to fetch indexed stack entries. Z80 provides neither.
Title: Re: Features Wishlist
Post by: Matrefeytontias on August 07, 2014, 04:01:12 pm
Varargs-like doesn't exist in Axe ? What about all the text commands ?
Title: Re: Features Wishlist
Post by: Runer112 on August 07, 2014, 04:05:32 pm
Varargs-like doesn't exist in Axe ? What about all the text commands ?

Not really varargs. Something like Disp A,B,C is parsed like Disp A : Disp B : Disp C. A proper varargs function collects all arguments and then executes one function, to which all arguments are exposed at once.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 09, 2014, 12:53:20 pm
I've finished my Menu( axiom  :thumbsup:
Download it here (http://www.omnimaga.org/the-axe-parser-project/menu(-command-using-os's-bcalls-need-assembly-help/msg391091/#msg391091) !

(http://www.omnimaga.org/the-axe-parser-project/menu(-command-using-os's-bcalls-need-assembly-help/?action=dlattach;attach=17914)

But if any assembly wizards want to provide the majority of a solution, whether it's as hard as I think it is or if it's really simple, I'll happily include it! That is, if I can fit it. :P

It was not so hard, but currently the Axiom only allows to create menus like those in TI-Basic, not like the OS's ones (this will be much harder). Now, it would be great to add this feature in Axe !
Title: Re: Features Wishlist
Post by: Hayleia on August 09, 2014, 12:58:05 pm
Great :D
I am not sure I'll use it in any of my releases, but this could still be very helpful in unfinished projects to have functionnal code faster (and then only have beautiful interfaces).
Title: Re: Features Wishlist
Post by: Runer112 on August 09, 2014, 01:50:14 pm
Thanks for helping to demonstrate for me how this stuff works. I'll try to implement those kind of simple menus into native Axe. I haven't been able to think of an easy/elegant way to allow for inclusion of the mode menu style selections or window menu style numerical inputs, so those may be left out.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 09, 2014, 03:04:34 pm
Great :D
I am not sure I'll use it in any of my releases, but this could still be very helpful in unfinished projects to have functionnal code faster (and then only have beautiful interfaces).
*Yes ! My very first +1 ! I love you !*
Thanks ! Personally, I think I'll use it in some projects which have a TI-design...
I'm happy to have finished this Axiom ! Finished debugging !
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 14, 2014, 02:13:46 am
This is awesome Zemmargorp, but as a future advice I would recommend avoiding reposting the same message multiple times in different topic, as this could be considered spam. The two other messages (in the axiom thread and your new topic should be enough)
Title: Re: Features Wishlist
Post by: Zemmargorp on August 14, 2014, 12:48:01 pm
Thanks for helping to demonstrate for me how this stuff works. I'll try to implement those kind of simple menus into native Axe. I haven't been able to think of an easy/elegant way to allow for inclusion of the mode menu style selections or window menu style numerical inputs, so those may be left out.
I had an idea of syntax (http://www.omnimaga.org/the-axe-parser-project/menu(-command-using-os's-bcalls-need-assembly-help/msg391448/#msg391448) to implement it in Axe Parser. But you can decide to implement it like in TI-Basic (I'll give you the source code), and change it later (in Axe 2.0 ?). Additionally, numerical inputs returns floating point numbers... (it might be possible to change the parsing method, but... it would be some work too).


This is awesome Zemmargorp, but as a future advice I would recommend avoiding reposting the same message multiple times in different topic, as this could be considered spam. The two other messages (in the axiom thread and your new topic should be enough)

Thank you ! I know three messages is a lot, but as I posted earlier information about this axiom in this topic, I wanted to write I finished it, in case somebody here saw the other messages and wondered if the project was made or not. But you're right : the way I posted it looks a bit like an ad !
Title: Re: Features Wishlist
Post by: Hayleia on August 20, 2014, 05:15:49 am
Could there be a way to say "ignore the following token" ? That would be especially useful to ignore "newlines".
Here's a case where I'd see that being very useful (consider that the "ignore" is implemented with the ' token).

Code: [Select]
L5'
→°Var2B+2'
→°Var1B+1'
→°Var4B+4'
→°Var3B+3'

This would actually be equivalent to that
Code: [Select]
L5→°Var2B+2→°Var1B+1→°Var4B+4→°Var3B+3

Or to that
Code: [Select]
L5+00→°Var2B
L5+02→°Var1B
L5+03→°Var4B
L5+07→°Var3B

Why would that be useful ? Well here, I declared a 2-byte variable named Var2B, a 1-byte variable named Var1B, etc.
Writing all in one line is ridiculously unreadable.
Writing as in the last code block is more readable, but very annoying if finally you decide to change the order of your variables (for some obscure reason) or their location because you'd have to change all the left members so that the new declaration still fits the variable sizes.
Writing as in the first code block is very convenient because the size of every variable is written on the same line as the varialbe itself so moving the declarations is really easy.
Title: Re: Features Wishlist
Post by: Runer112 on August 20, 2014, 11:17:12 am
A token to ignore the next token doesn't sound like a good idea from a language design standpoint. However, an escape sequence token does. But I have one issue with this: what token do I use? Axe has already used up all the viable symbol tokens that I can think of.
Title: Re: Features Wishlist
Post by: Hayleia on August 20, 2014, 12:02:28 pm
Is the "3" token used ? Or the "n" one ?
Title: Re: Features Wishlist
Post by: Runer112 on August 20, 2014, 12:11:15 pm
They're not used, but I can't say I particularly like them as escape tokens because they're not really symbols. Unfortunately, there aren't many other choices, apart from some clever idea to do it some other way.


EDIT: One "clever idea" I thought of was changing the primary method of displaying a new line on the homescreen to Disp n and claiming i for this. Disp i can be kept as allowed syntax for backwards compatibility, but I like the switch overall. n makes much more sense as a newline character, as the letter is used in many other instances to denote a newline. And although it's still a letter and not a symbol, I'm more comfortable making i the escape token, because it's normal meaning is sort of like a modifier. I'm still not overly keen on this idea, though, as it still isn't an actual symbol and would muddy things up a bit if a future version of Axe called for complex numbers, which isn't that unfathomable if floats were added.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 20, 2014, 01:02:20 pm

EDIT: One "clever idea" I thought of was changing the primary method of displaying a new line on the homescreen to Disp n and claiming i for this.
Why not, but the i token is easier to reach than the n token, and newlines will be more used than the escape token. Except if you choose that Disp i will always be a valid syntax and won't be deprecated, but this is a bit weird. I thought using n as the escape token was a good idea... Otherwise, it's still possible to find another token like ! which is only used in conditionals, and which could be used (outside conditionals) as the escape token.
Title: Re: Features Wishlist
Post by: Hayleia on August 20, 2014, 01:12:36 pm
Well I never use Disp so I never use i, so I don't really care if it is renamed n :P
Plus the fact you said n is more logical for a newline.

I also like Zemmargorp's idea about the "!", which not only lets Disp untouched but also lets you an open door for your complexes :)
Title: Re: Features Wishlist
Post by: Zemmargorp on August 20, 2014, 01:30:54 pm
Well I never use Disp so I never use i, so I don't really care if it is renamed n :P
Plus the fact you said n is more logical for a newline.

I also like Zemmargorp's idea about the "!", which not only lets Disp untouched but also lets you an open door for your complexes :)

You never use Disp ?  :o

Yes, n is more logical for a newline, but would i be more logical for a token not to be interpreted by the parser ? And people are used to i to insert a new line, to introduce a new line, to *lack of ideas*...  ;D

Using ! as the escape token would also let a new token free : n. We don't really care about the complex numbers yet, as we don't even have access to reals, and when they will be included (if they will be one day) there will probably be major syntax/token changes.
Title: Re: Features Wishlist
Post by: Runer112 on August 20, 2014, 04:16:20 pm
The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
Title: Re: Features Wishlist
Post by: Hayleia on August 20, 2014, 11:47:43 pm
You never use Disp ?  :o
Nope, I most often use Text and sometimes use Output, but never Disp.

Yes, n is more logical for a newline, but would i be more logical for a token not to be interpreted by the parser ? And people are used to i to insert a new line, to introduce a new line, to *lack of ideas*...  ;D
Well I thought that "n" for newline and "i" or "!" to escape was good, not because newline starts with an "n" but because "n" looks like "\n" and "i" and "!" look like "\".

The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 21, 2014, 12:12:36 am
I totally forgot that Disp existed in  Axe. I only ever used the home screen about twice in Axe and it was to display score. Other than that I tried to keep everything graphical (otherwise it kinda defeats the point of using Axe instead of TI-BASIC).
Title: Re: Features Wishlist
Post by: Zemmargorp on August 21, 2014, 07:46:46 am
Well I thought that "n" for newline and "i" or "!" to escape was good, not because newline starts with an "n" but because "n" looks like "\n" and "i" and "!" look like "\".
I slept on it, and now thinks that I could be good to replace progressively the i token by n for newlines. By the way, here's another idea of feature : i could be used before a token to return the key's index the token is on. We could write "!If K-i5" instead of "!If K-27" and having to learn all the key's indexes. Additionally, "ir5" would return the key's index of the getKeyr function.

The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
Yes, but... there aren't so many solutions, are there ?
We could still find tricks like doubling the ! token means to include it once in the string.


Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.
Title: Re: Features Wishlist
Post by: Runer112 on August 21, 2014, 11:33:20 am
By the way, here's another idea of feature : i could be used before a token to return the key's index the token is on. We could write "!If K-i5" instead of "!If K-27" and having to learn all the key's indexes. Additionally, "ir5" would return the key's index of the getKeyr function.

Considering that almost half of the keys don't correspond to actual tokens and couldn't be looked up in this fashion, it doesn't really seem worth doing this to me.

We could still find tricks like doubling the ! token means to include it once in the string.

The issue isn't providing a new way for the ! character to be used in strings. The issue is that this will break backwards compatibility because some or all programs that use ! in string data will fail to compile correctly, and backwards compatibility has always been a big goal.


Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.

I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.
Title: Re: Features Wishlist
Post by: Hayleia on August 21, 2014, 11:48:20 am

Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.
I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.
No need to install a translating app. Just temporarily install one on Wabbitemu for example, create a program with all "special tokens", send that program to your calc and then you just have to recall that program and erase useless tokens ;)
Of course, the catalog hook is a better idea, but with the stupid solution I proposed, the release with the Catalog hook can come after the release supporting "special tokens".
Title: Re: Features Wishlist
Post by: Zemmargorp on August 21, 2014, 11:59:54 am
Considering that almost half of the keys don't correspond to actual tokens and couldn't be looked up in this fashion, it doesn't really seem worth doing this to me.
Well, if we take the letters as the key's token, approximately one third of the keys won't be covered... yes, it's still too much. Or maybe use i followed by a number, which is the keycode in TI-Basic ? because they're easy to remember, and it'll help people who programmed in TI-Basic to get into Axe.

Some other ideas : rename the RecallGDB and StoreGDB tokens RecallLCD and StoreLCD, and parse them as "L6:Asm(EF7B4C)" and "L3:Asm(EF7B4C)". They would respectively copy the LCD in the main buffer and in the back-buffer, which has many applications and I'm pretty sure it isn't currently possible in pure Axe.

Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens). Using the APD could be great. Also, Axe Parser could parse "min(A,B,C)" like "min(A,B):min(,C)" instead of generating the "WRONG # OF ARGS" error (same for other functions like this one).

EDIT : "Asm(EF7B4C)" is "BCALL(_SaveDisp)" in assembly, and destroys all registers. "save" and "load" could be nice names for push and pop. Additionally, the execution of the APD could be enabled and disabled during the code, so why not using two tokens, a bit like #ExprOn and #EprOff. And allowing three arguments for min( obviously means allowing as many args as needed by the user  :P
Title: Re: Features Wishlist
Post by: Runer112 on August 21, 2014, 03:28:57 pm
Well, if we take the letters as the key's token, approximately one third of the keys won't be covered... yes, it's still too much. Or maybe use i followed by a number, which is the keycode in TI-Basic ? because they're easy to remember, and it'll help people who programmed in TI-Basic to get into Axe.

The assembly key codes follow a pattern that's easy enough to learn, so I don't think this is really necessary. If I did eventually add key equates, I'd probably do it in a much more traditional fashion where the equates are normal constants like any user-defined constant.

Some other ideas : rename the RecallGDB and StoreGDB tokens RecallLCD and StoreLCD, and parse them as "L6:Asm(EF7B4C)" and "L3:Asm(EF7B4C)". They would respectively copy the LCD in the main buffer and in the back-buffer, which has many applications and I'm pretty sure it isn't currently possible in pure Axe.

Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it. But instead of using RecallGDB, I think it would make more sense to adopt the syntax used by other screen/buffer commands, like ClrDraw and DrawInv, which is to add an r to operate with the back buffer (L3) or to add parentheses to operate with an arbitrary buffer.

Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens).

This already exists in a functional basis as Select(A,B). Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Every language I can think of doesn't provide this functionality for this reason. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.

Using the APD could be great.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.

Also, Axe Parser could parse "min(A,B,C)" like "min(A,B):min(,C)" instead of generating the "WRONG # OF ARGS" error (same for other functions like this one).

I was just about to say that this is easily doable... and then I remembered that the signed minimum and maximum commands, min(A,B)r and max(A,B)r, exist. That instantly makes it much harder, because the compiler wouldn't know if normal or signed comparisons are needed until after it has compiled all but the final comparison. This means that I'd either need to create some kind of lookahead capability or create special varargs versions of the commands. Although both sound tricky to implement, the second sounds less tricky and might be manageable. But since the ability to chain these commands already exists and this would only be syntactical sugar, I'm probably not assigning this too high of a priority.
Title: Re: Features Wishlist
Post by: Hayleia on August 22, 2014, 01:47:27 am
Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens).

This already exists in a functional basis as Select(A,B). Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Every language I can think of doesn't provide this functionality for this reason. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
The problem with Select(EXPR1,EXPR2) is that we can't put commands such as Copy (for example) in EXPR2, which I often wanted to do in my programs (I don't care much about EXPR1, I always put nothing here). We can work around it with a sub that leads to the Copy but it is kind of a waste. Plus, I don't see why refreining people from using commands directly if they can use anyway it by just wasting 4 bytes.
Title: Re: Features Wishlist
Post by: Vsod99 on August 22, 2014, 02:05:03 am
An "active topics" section would be nice, especially when looking for no specific subthread in particular.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on August 22, 2014, 07:13:37 am
Erm that isn't really the place to ask for that. You would need to ask at http://ourl.ca/request and http://www.omnimaga.org/site-feedback-and-questions/ for suggestions. But we already have an active topic feature on the forums anyway: http://www.omnimaga.org/recent
Title: Re: Features Wishlist
Post by: Zemmargorp on August 22, 2014, 09:23:26 am
Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it.
Great ! Now we need to find a use to RecallLCDGDB  :P

Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
Yes, it's a dangerous command, but advanced developers would then be able to optimize their codes where the compiler isn't smart enough...  :/ But this level of optimization isn't probably needed when using Axe.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.
Yes, but then there's the problem of removing the copy of the program (or at least removing its reference inside the VAT, if it's pointed to in the VAT). And there's also another problem : the APD uses the RAM area L1, doesn't it ?

I was just about to say that this is easily doable... and then I remembered that the signed minimum and maximum commands, min(A,B)r and max(A,B)r, exist. That instantly makes it much harder, because the compiler wouldn't know if normal or signed comparisons are needed until after it has compiled all but the final comparison.
Ah, I see ! Neither did I think of it.

Something else : would it be easy (I don't think so, but I still want to write the idea) to add instructions a bit like #ExprOn and #ExprOff, called #1byte and #2bytes, who force Axe Parser to use A instead of HL for calculations ? Because sometimes only 1 byte is needed, for example and E3C becomes (instead of AND $3C) :
Code: [Select]
LD    H, $00
LD    A, L
AND   $3C
LD    L, A


EDIT : I wrote "use A instead of HL", which means that accessing memory with the curvy brackets {} won't be possible, exceptions being if there's something like {...+GDB0}, where "..." is necessarily a one byte value. Also, it would still be possible to use the variables.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 23, 2014, 10:03:18 am
Some other ideas :

The token Clear Entries (found in the MEMORY menu) could remove temporary variables (I think that the result of input is stored in a temporary variables, isn't it ?). Also, ClrAllLists could be used to initalise the free RAM areas, from L1 to L6.  (See the BCALLs CleanAll and BufClr.)

I found two different ideas of use for Then : either it could be used to say that the following tokens of the same line should be interpreted only if debugging (by debugging I mean compiling with Zoom), or it could be used to optimize conditional jumps. In this last case, the Then should be used right after a If condition, and should be followed by a Goto instruction : this is roughly the equivalent of ReturnIf, but for jumps. There are some optimizations in assembly to do when Ifs are used to jump only.

What else... Adding a token (something like FullString) to ignore the split-screen modes, a token to generate custom error messages (I can't rememer the BCALL's name), why not using a token like Param which returns the calculator's type (TI-83+, 83+ SE, 84+, ...), another to check the battery level... I think I haven't forgotten anything  ;D  !

By the way, if one day floating numbers are added to Axe, the tokens associated with the variables could be the matrix tokens (from [A] to [J], that is to say 10 variables, and 90 bytes required).
Title: Re: Features Wishlist
Post by: Runer112 on August 23, 2014, 11:52:14 am
Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
Yes, it's a dangerous command, but advanced developers would then be able to optimize their codes where the compiler isn't smart enough...  :/ But this level of optimization isn't probably needed when using Axe.
If you're advanced enough of a developer that you want manual stack control, inline assembly provides that capability.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.
Yes, but then there's the problem of removing the copy of the program (or at least removing its reference inside the VAT, if it's pointed to in the VAT). And there's also another problem : the APD uses the RAM area L1, doesn't it ?

As far as I can tell, you don't need to do anything special for APD to work properly besides enabling it and having the OS interrupt running. I imagine the hardest part of using APD successfully would be making sure other commands used while it's running don't turn it off, whether by disabling interrupts or actually turning off the APD running flag. And yes, APD does write the contents of the screen to L1 when turning the calculator off. I'm pretty sure that's unavoidable.

Something else : would it be easy (I don't think so, but I still want to write the idea) to add instructions a bit like #ExprOn and #ExprOff, called #1byte and #2bytes, who force Axe Parser to use A instead of HL for calculations ? Because sometimes only 1 byte is needed, for example and E3C becomes (instead of AND $3C) :
Code: [Select]
LD    H, $00
LD    A, L
AND   $3C
LD    L, A

The current iteration of Axe is entirely built around HL doing everything, so no, this wouldn't be very feasible to add right now. It's been suggested at least once before and is on a to-do list, but is waiting for for the theoretical Axe 2.0 with support for actual data types to break the shackles of everything being a 16-bit int.

The token Clear Entries (found in the MEMORY menu) could remove temporary variables (I think that the result of input is stored in a temporary variables, isn't it ?). Also, ClrAllLists could be used to initalise the free RAM areas, from L1 to L6.  (See the BCALLs CleanAll and BufClr.)

Being able to remove all temporary variables is of course very easy to implement because it's just B_CALL(_CleanAll). But to be cautious of feature overload, may I ask in what context you imagine an Axe programmer would use this command? Temporary variables should be cleaned up by the OS when execution of your program starts and ends, so I can't think of any reason a program would want to mass delete its temporary variables... except for a shell program that's cleaning up after executing another program, but since vanilla Axe lacks the ability to do many things a shell programs needs already, this doesn't seem like a good enough reason to add it.

As for initializing all free RAM areas (to zeroes, I'm assuming): why? I can't imagine a case where this would be necessary. I can only think of a few use cases in which you'd need to initialize any single RAM area to zeroes, and I can't imagine them being needed so severely as to use all six free RAM locations. Even if you did need this, you can clear them manually using a few ClrDraw's and Fill()'s, which is basically all a native command would be doing anyways.

I found two different ideas of use for Then : either it could be used to say that the following tokens of the same line should be interpreted only if debugging (by debugging I mean compiling with Zoom), or it could be used to optimize conditional jumps. In this last case, the Then should be used right after a If condition, and should be followed by a Goto instruction : this is roughly the equivalent of ReturnIf, but for jumps. There are some optimizations in assembly to do when Ifs are used to jump only.

Programmers can already use preprocessor conditionals with custom constants to change what code is compiled by simply changing a constant. This can be used in place of knowing the optimization level (which generally doesn't seem like a good idea anyways, as the system for how programs are compiled/optimized is always subject to change).

Optimizing if statements that simply perform jumps has been looked into before, but the compiler currently lacks lookahead parsing and a strong peephole optimizer. If either of these is added (which isn't too likely to happen soon because I'm still quite unfamiliar with how the compiler works), then this optimization will surely be added as well.

What else... Adding a token (something like FullString) to ignore the split-screen modes...

Like Fullrr?

... a token to generate custom error messages (I can't rememer the BCALL's name), why not using a token like Param which returns the calculator's type (TI-83+, 83+ SE, 84+, ...), another to check the battery level... I think I haven't forgotten anything  ;D  !

These all sound very shell-y, which Axe does not aim to natively provide features for. There would be too many features that would need to be added to allow for this very specific type of program to be made in vanilla Axe.

By the way, if one day floating numbers are added to Axe, the tokens associated with the variables could be the matrix tokens (from [A] to [J], that is to say 10 variables, and 90 bytes required).

Like 8-bit ints, floating point data types would be added in the theoretical Axe 2.0. You could then name your floating point variables whatever you wanted, like basically every other language.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 23, 2014, 12:52:55 pm
As far as I can tell, you don't need to do anything special for APD to work properly besides enabling it and having the OS interrupt running. I imagine the hardest part of using APD successfully would be making sure other commands used while it's running don't turn it off, whether by disabling interrupts or actually turning off the APD running flag. And yes, APD does write the contents of the screen to L1 when turning the calculator off. I'm pretty sure that's unavoidable.
So if I want to use it I just need to use the OS's BCALLs EnabledAPD and DisableAPD ? Good to know. As L1 is 768 bytes long, I believe the APD uses it to store a copy of the LCD ? Like StoreLCD(L1) does ? Hmm... it'd be great to find a way to exchange L1 and L6 just before and after the APD runs.


The current iteration of Axe is entirely built around HL doing everything, so no, this wouldn't be very feasible to add right now. It's been suggested at least once before and is on a to-do list, but is waiting for for the theoretical Axe 2.0 with support for actual data types to break the shackles of everything being a 16-bit int.

I'm afraid to imagine how hard it'll be...


Being able to remove all temporary variables is of course very easy to implement because it's just B_CALL(_CleanAll). But to be cautious of feature overload, may I ask in what context you imagine an Axe programmer would use this command?
If the temporary variables are removed before and after the program's execution, then there's no problem.


As for initializing all free RAM areas (to zeroes, I'm assuming): why? I can't imagine a case where this would be necessary. I can only think of a few use cases in which you'd need to initialize any single RAM area to zeroes, and I can't imagine them being needed so severely as to use all six free RAM locations.
I don't know why it'd be needed, but it may be used one day, as it's not completely useless. I had this idea when I saw the token ClrAllLists, as sometimes clearing RAM areas to zeroes is needed, and sometimes programs use several RAM areas.


Optimizing if statements that simply perform jumps has been looked into before, but the compiler currently lacks lookahead parsing and a strong peephole optimizer. If either of these is added (which isn't too likely to happen soon because I'm still quite unfamiliar with how the compiler works), then this optimization will surely be added as well.
In short, achieving adding a lookahead ability would improve the parser a lot  :P


Like Fullrr?
Exaclty ! Sorry, I didn't know it already existed... *Looking for it...* Oh, but it's quite recent !


These all sound very shell-y, which Axe does not aim to natively provide features for. There would be too many features that would need to be added to allow for this very specific type of program to be made in vanilla Axe.
It's a pity...


Like 8-bit ints, floating point data types would be added in the theoretical Axe 2.0. You could then name your floating point variables whatever you wanted, like basically every other language.
Ah... Nevertheless, for code readability, differentiation of types in the variable's name would be better.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 24, 2014, 02:04:29 pm
Here's another feature idea which will be useful, and this time I'm pretty sure it isn't implemented yet  :P . Well, I hope so, because I've spent a quite big part of the afternoon writing the assembly code and debugging it, and if this feature was already available, I would have liked to use it before.

The idea is making a function a bit like GetCalc(, but which allows the developer to insert/remove bytes in a variable. I suggest using the ClrTable token, as it won't have any utility in Axe, and it's just next to GetCalc(. The token could be rename MemManage(, and take the following arguments : Variable,Offset,Size. If size is positive, memory is added, otherwise, it's removed from the offset. Using one token only has a big advantage : if the size is calculated by a formula, the developer doesn't have to test if it's positive or negative and use the corresponding function.

Spoiler For Code and information:
  • Variable is a pointer to the variable's name
  • The two first args must be in the stack, the last one (the size) in HL
  • The code checks if the variable exists, is unarchived, etc.
  • Returns 0 if it didn't worked, or else the offset in the file where bytes where inserted/removed
  • I haven't tried it with size=0. It'll try to add zero bytes to the variable... It might crash, or do nothing.
  • Don't try to use this routine with lists/matrix/numbers/etc, only with programs/appvars/strings/...
Code: [Select]
    BIT  7, H
    JR   Z, MemInsert
   
    ;p_IntNeg
    xor  a
    sub  l
    ld   l, a
    sbc  a, a
    sub  h
    ld   h,a
   
MemDelete:
    POP  DE      ;Offset to remove
    EX   (SP), HL   ;Variable name (SP = size)
    PUSH DE
    RST  rMov9ToOP1
    BCALL(_ChkFindSym)   ;Look in the VAT, DE set to pointer to size bytes of variable)
    JR   C, Error_Pop2   ;ERR: NOT FOUND
    XOR  A
    OR   B
    JR   NZ, Error_Pop2   ;ERR: ARCHIVED
   
    POP  HL      ;Offset to remove memory
    POP  BC      ;Memory needed
    PUSH HL      ;Offset to remove memory
    PUSH BC      ;Memory needed
    PUSH DE      ;Pointer to size bytes
    INC  DE      ;Skip size bytes
    INC  DE
   
    EX   DE, HL      ;HL = pointer, DE = bytes
    ADD  HL, DE
    LD   D, B \ LD E, C   ;Memory needed
   
    BCALL(_DelMem)   ;Delete the memory
   
    POP  HL      ;Pointer to size bytes
    PUSH HL      ;Pointer to size bytes
   
    BCALL(_LdHLInd)   ;HL = size of variable
   
    POP  DE      ;Pointer to size bytes
    POP  BC      ;Memory needed
    XOR  A
    SBC  HL, BC      ;Decrease size bytes
   
    EX   DE, HL
    LD   (HL), E
    INC  HL
    LD   (HL), D
    INC  HL
   
    POP  BC      ;Offset to remove memory
    ADD  HL, BC
    RET
MemInsert:
    BCALL(_EnoughMem)   ;Check if enough memory (stores value in DE)
    JR   C, Error_Pop2   ;ERR: MEMORY
    LD   B, D \ LD C, E   ;Memory needed
   
    POP  DE      ;Offset to insert memory
    POP  HL      ;Variable's name
    PUSH DE      ;Offset to insert memory
    PUSH BC      ;Memory needed
    RST  rMov9ToOP1
    BCALL(_ChkFindSym)   ;Look in the VAT, DE set to pointer to size bytes of variable)
    JR   C, Error_Pop2   ;ERR: NOT FOUND
    XOR  A
    OR   B
    JR   NZ, Error_Pop2   ;ERR: ARCHIVED
   
    POP  HL      ;Memory needed
    EX   DE, HL
    POP  BC      ;Offset to insert memory
    PUSH BC
    PUSH DE      ;Memory needed
    PUSH HL      ;Pointer to size bytes
    INC  HL      ;Skip size bytes
    INC  HL
    ADD  HL, BC
    EX   DE, HL
   
    BCALL(_InsertMem)   ;Insert the memory
   
    POP  HL      ;Pointer to size bytes
    PUSH HL      ;Pointer to size bytes
   
    BCALL(_LdHLInd)   ;HL = size of variable
   
    POP  DE      ;Pointer to size bytes
    POP  BC      ;Memory needed
    ADD  HL,BC      ;Increase size bytes
   
    EX   DE, HL
    LD   (HL), E   ;Write new size
    INC  HL
    LD   (HL), D
    INC  HL      ;Pointer to data
   
    POP  BC      ;Offset to insert memory
    ADD  HL, BC
    PUSH HL      ;Pointer to data
   
BytesInit:
    LD   (HL), $41   ;Write 'A'
    INC  HL
    DEC  BC
    LD   A, B
    OR   C
    JR   NZ, BytesInit
   
    POP  HL      ;Pointer to data
    RET
Error_Pop2:
    POP  HL
    POP  HL
Error:
    LD   HL, 0
    RET


I'll probably make an Axiom with some useful stuff like this code, StoreLCD, #ApdOn and #ApdOff, push and pop, since we can't use all this currently in Axe.
Title: Re: Features Wishlist
Post by: Hayleia on August 24, 2014, 02:07:11 pm
What do you mean by "variable" ? Because Memkit, an Axiom that is included in Axe's zip, can already add or remove bytes in an appvar for example.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 24, 2014, 02:12:16 pm
What do you mean by "variable" ? Because Memkit, an Axiom that is included in Axe's zip, can already add or remove bytes in an appvar for example.
By "variable", I mean any OS variable : it can be an appvar, a program, etc. It was already possible  :(  ? Then this feature should be added to Axe, it's so useful !
Title: Re: Features Wishlist
Post by: Hayleia on August 24, 2014, 02:13:48 pm
I don't know if it works with everything but I am sure it works with appvars (I used that in AudaciTI), I am pretty sure it works with programs (given the difference between appvars and programs -.-) but I don't know for other variables.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 24, 2014, 02:19:45 pm
I don't know if it works with everything but I am sure it works with appvars (I used that in AudaciTI), I am pretty sure it works with programs (given the difference between appvars and programs -.-) but I don't know for other variables.
It'll work with programs, but for the other variables (such as lists and matrix), the size field won't be set correctly. For these two variables, it should contain the quantity of numbers, and not the size of the variable in bytes. Nevertheless, it's still possible to use this routine and update separately this field (or else improve the routine to detect the variable's type).
Title: Re: Features Wishlist
Post by: Runer112 on August 24, 2014, 02:49:18 pm
As Hayleia said, I think MemKit covers this. I do agree that the functionalities of MemKit should be added to native Axe, though.
Title: Re: Features Wishlist
Post by: Hayleia on August 26, 2014, 09:48:29 am
For now, we can do this
[]→°CST
°CST1-°CST2→°CST3

But we can't do this:
[]-°CST1→°CST2

Could this possibility be added ? Basically, I have this file
Spoiler For Spoiler:

[]->°FoxLedge
Data(°LedgeSprR^^r,°LedgeSpr^^r)
Data(0,0)
Data(°AbsX+°AbsY+°Ledge)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(pi00111111).Repeat 31 frames
Data(0)

[]->°FoxAirFront
Data(°AirFront1SprR^^r,°AirFront1Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirFront1^^r) .état suivant par défaut
Data(pi00010011) .set chrono,3
Data(0)

[]->°FoxAirFront1
Data(°AirFront1SprR^^r,°AirFront1Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirFront2^^r) .état suivant par défaut
Data(pi00100010).Repeat 2 frames
Data(0)

[]->°FoxAirFront2
Data(°AirFront2SprR^^r,°AirFront2Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirFront1^^r) .état suivant par défaut
Data(pi00100010).Repeat 2 frames
Data(pi00000011,°FoxAir^^r).djz
Data(0)

[]->°FoxBackAir
Data(°BackAirSprR^^r,°BackAirSpr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(0)        .projdir
    Data(128,256^^r).projspeed
    Data(12,14)    .coords
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°FoxDownAir
Data(°AirDown1SprR^^r,°AirDown1Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirDown1^^r) .état suivant par défaut
Data(pi00010010) .set chrono,2
Data(0)

[]->°FoxAirDown1
Data(°AirDown1SprR^^r,°AirDown1Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirDown2^^r) .état suivant par défaut
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°FoxAirDown2
Data(°AirDown2SprR^^r,°AirDown2Spr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAirDown1^^r) .état suivant par défaut
Data(pi00100011).Repeat 3 frames
Data(pi00000011,°FoxAir^^r).djz
Data(0)

[]->°FoxNeutralAir
Data(°DashAttSprR^^r,°DashAttSpr^^r)
Data(0,0)
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(2)        .projdir
    Data(32,256^^r)    .projspeed
    Data(12,14)    .coords
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°FoxUpSmash .met juste le chrono à 0
Data(°FoxLandSprR^^r,°FoxLandSpr^^r)
Data(0,0) .teleport
Data(°GroundNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°UpCharge^^r) .état suivant par défaut
Data(pi00010000) .set chrono,0
Data(0)

[]->°UpCharge
Data(°FoxLandSprR^^r,°FoxLandSpr^^r)
Data(0,0) .teleport
Data(°GroundNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°UpSmash1^^r) .état suivant par défaut
Data(pi011 11111,°UpSmash1^^r).ijx 31
Data(pi10000100,°UpCharge^^r) .if keyA
Data(0)

[]->°UpSmash1
Data(°UpSmash1SprR^^r,°UpSmash1Spr^^r)
Data(0,0) .teleport
Data(°AirNull)
Data(0^^r,~32^^r) .V
Data(0) .arrowkeys influence
Data(°UpSmash2^^r) .état suivant par défaut
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°UpSmash2
Data(°UpSmash2SprR^^r,°UpSmash2Spr^^r)
Data(0,0) .teleport
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°UpSmash3^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(0)        .projdir
    Data(64,256^^r).projspeed
    Data(12,14)    .coords
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°UpSmash3
Data(°UpSmash3SprR^^r,°UpSmash3Spr^^r)
Data(0,0) .teleport
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°UpSmash4^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(0)        .projdir
    Data(80,256^^r).projspeed
    Data(12,14)    .coords
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°UpSmash4
Data(°UpSmash4SprR^^r,°UpSmash4Spr^^r)
Data(0,0) .teleport
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°UpSmash5^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(0)        .projdir
    Data(96,256^^r).projspeed
    Data(12,14)    .coords
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°UpSmash5
Data(°FoxLandSprR^^r,°FoxLandSpr^^r)
Data(0,0) .teleport
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(pi00100011).Repeat 3 frames
Data(0)

[]->°FoxDashAttack
Data(°DashAttSprR^^r,°DashAttSpr^^r) .sprite
Data(0,0) .teleport
Data(°AbsX+°AbsY+°GroundNull)
Data(170^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxDash2^^r) .état suivant par défaut
Data(pi00000101)
    Data(1)        .flags
    Data(10)    .rad
    Data(0^^r)    .player state
    Data(0^^r)    .adv state
    Data(0,0)    .adv position
    Data(5)        .hitstun
    Data(15)    .damages
    Data(2)        .projdir
    Data(64,256^^r)    .projspeed
    Data(12,14)    .coords
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°AirBlaster
Data(°BigA^^r,°BigA^^r) .sprite
Data(0,0) .téléportation
Data(°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(0)

[]->°GroundBlaster
Data(°BigA^^r,°BigA^^r) .sprite
Data(0,0) .téléportation
Data(°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(0)

[]->°AirIllusion
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AbsX+°AbsY+°AirNull) .WARNING cet état ne sert qu'à être pivoté, il passe sans plus de tests à AirIllusion2
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°AirIllusion2^^r) .état suivant par défaut
Data(0)

[]->°AirIllusion2
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°AirIllusion3^^r) .état suivant par défaut
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°AirIllusion3
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(1024^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°AirIllusion4^^r) .état suivant par défaut
Data(pi10000010,°AirIllusionC^^r).si touche B, changestate AirIllusionC (Illusion Cancel)
Data(pi00100111).Repeat 7 frames
Data(0)

[]->°AirIllusion4
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(0^^r,~1^^r) .V
Data(0) .arrowkeys influence
Data(°Helpless^^r) .état suivant par défaut
Data(pi00101000).Repeat 8 frames
Data(0)

[]->°AirIllusionC
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsY+°AirNull)
Data(~105^^r,~1^^r) .V
Data(0) .arrowkeys influence
Data(°Helpless^^r) .état suivant par défaut
Data(pi00101000).Repeat 8 frames
Data(0)

[]->°Shine .seul état qui a une hitbox active TODO
Data(°GShine2SprR^^r,°GShine2Spr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°AShine1^^r) .état suivant par défaut
Data(pi00010100) .set chrono,4
Data(pi00000100,°GShine1^^r) .OnGround
Data(0)

[]->°GShine1
Data(°GShine1SprR^^r,°GShine1Spr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°GroundOK) .WARNING Pas Null pour le Jump cancel
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°GShineEND^^r) .état suivant par défaut
Data(pi00000011,°GShine2^^r).djz
Data(pi10000010,°GShine1^^r).si touche B
Data(0)

[]->°GShine2
Data(°GShine2SprR^^r,°GShine2Spr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°GroundOK) .WARNING Pas Null pour le Jump cancel
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°GShineEND^^r) .état suivant par défaut
Data(pi01100100,°GShine1^^r).ijx 4
Data(pi10000010,°GShine2^^r).si touche B
Data(0)

[]->°GShineEND
Data(°GShine1SprR^^r,°GShine1Spr^^r) .sprite
Data(0,0) .téléportation
Data(°GroundNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°AShine1
Data(°GShine1SprR^^r,°GShine1Spr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AirOK) .WARNING Pas Null pour le Jump cancel
Data(0^^r,°FoxGravity/4^^r) .V
Data(0) .arrowkeys influence
Data(°AShineEND^^r) .état suivant par défaut
Data(pi00000011,°AShine2^^r).djz
Data(pi10000010,°AShine1^^r).si touche B
Data(0)

[]->°AShine2
Data(°GShine2SprR^^r,°GShine2Spr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AirOK) .WARNING Pas Null pour le Jump cancel
Data(0^^r,°FoxGravity/4^^r) .V
Data(0) .arrowkeys influence
Data(°AShineEND^^r) .état suivant par défaut
Data(pi01100100,°AShine1^^r).ijx 4
Data(pi10000010,°AShine2^^r).si touche B
Data(0)

[]->°AShineEND
Data(°GShine1SprR^^r,°GShine1Spr^^r) .sprite
Data(0,0) .téléportation
Data(°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(pi00101111).Repeat 15 frames
Data(0)

[]->°FireFox
Data(°FireChargeSpR^^r,°FireChargeSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxU^^r) .état suivant par défaut
Data(pi00111111).Repeat 31 frames
Data(pi10110000,°FireFoxDD^^r)
Data(pi11010000,°FireFoxDD^^r)
Data(pi10101000,°FireFoxDU^^r)
Data(pi11001000,°FireFoxDU^^r)
Data(pi10100000,°FireFoxS^^r)
Data(pi11000000,°FireFoxS^^r)
Data(pi10010000,°FireFoxD^^r)
Data(0)

[]->°FireFoxDU .diagonal up
Data(°FireDUSprR^^r,°FireDUSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AbsX+°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxDU2^^r) .état suivant par défaut
Data(0)

[]->°FireFoxDU2 .diagonal up
Data(°FireDUSprR^^r,°FireDUSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(181^^r,~181^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxS3^^r) .sert à ne pas sortir du Fire avec une vitesse X excessive
Data(pi00111111).Repeat 31 frames
Data(0)

[]->°FireFoxDD .diagonal down
Data(°FireDDSprR^^r,°FireDDSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AbsX+°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxDD2^^r) .état suivant par défaut
Data(0)

[]->°FireFoxDD2 .diagonal down
Data(°FireDDSprR^^r,°FireDDSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(181^^r,181^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxS3^^r) .sert à ne pas sortir du Fire avec une vitesse X excessive
Data(pi00111111).Repeat 31 frames
Data(0)

[]->°FireFoxU
Data(°FireUpSpr^^r,°FireUpSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(0^^r,~256^^r) .V
Data(128) .arrowkeys influence
Data(°FireFoxUEND^^r) .état suivant par défaut
Data(pi00111110).Repeat 30 frames
Data(0)

[]->°FireFoxUEND
Data(°FireUpSpr^^r,°FireUpSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(0^^r,~256^^r) .V
Data(0) .arrowkeys influence
Data(°PivotHelpless^^r) .état suivant par défaut
Data(0)

[]->°FireFoxD
Data(°FireDownSpr^^r,°FireDownSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(0^^r,256^^r) .V
Data(0) .arrowkeys influence
Data(°PivotHelpless^^r) .état suivant par défaut
Data(pi00111111).Repeat 31 frames
Data(0)

[]->°FireFoxS
Data(°FireChargeSpR^^r,°FireChargeSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AbsX+°AbsY+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxS2^^r) .état suivant par défaut
Data(0)

[]->°FireFoxS2
Data(°FireSideSprR^^r,°FireSideSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(256^^r,~2^^r) .V
Data(0) .arrowkeys influence
Data(°FireFoxS3^^r) .état suivant par défaut
Data(pi00111111).Repeat 31 frames
Data(0)

[]->°FireFoxS3 .sert à ne pas sortir de FireFox avec une vitesse X excessive
Data(°FireSideSprR^^r,°FireSideSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°AbsY+°AirNull)
Data(128^^r,~2^^r) .V
Data(0) .arrowkeys influence
Data(°Helpless^^r) .état suivant par défaut
Data(0)

[]->°FoxStand .état debout normal
Data(°FoxStandSprR^^r,°FoxStandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°GroundOK)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(0)

[]->°FoxDash
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AbsX+°GroundDash)
Data(200^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxDash2^^r) .état suivant par défaut
Data(pi11000000,°FoxDash^^r) .si touche backward, changestate FoxDash (dashdance)
Data(pi00100111).Repeat 7 frames
Data(pi00011111).set chrono,15
.si touche forward, changestate FoxDash2
Data(0)

[]->°FoxDash2
Data(°FoxDash2SprR^^r,°FoxDash2Spr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°GroundDash)
Data(170^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxDashEND^^r) .état suivant par défaut
Data(pi00000011,°FoxDash3^^r).djz FoxDash3
Data(pi10100000,°FoxDash2^^r).si touche forward, changestate FoxDash2
Data(0)

[]->°FoxDash3
Data(°FoxDash1SprR^^r,°FoxDash1Spr^^r) .sprite
Data(0,0) .téléportation
Data(°AbsX+°GroundDash)
Data(170^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxDashEND^^r) .état suivant par défaut
Data(pi01101111,°FoxDash2^^r).ijx 15,FoxDash2
Data(pi10100000,°FoxDash3^^r).si touche forward, changestate FoxDash3
Data(0)

[]->°FoxDashEND
Data(°FoxBrakeSprR^^r,°FoxBrakeSpr^^r) .sprite
Data(0,0) .téléportation
Data(°GroundOK)
Data(~5^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(pi00101111) .Repeat 15 frames
Data(0)

[]->°FoxJump .état Jump (encore au sol avant de sauter)
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AirOK)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxShortHop^^r) .état suivant par défaut
Data(pi10000100,°FoxUpSmash^^r)
Data(pi00100011) .Repeat 3 frames
Data(pi10001000,°FoxHighHop^^r)
Data(0)

[]->°FoxAirJump
[]->°FoxHighHop .état Jump qui donne l'impulsion
Data(°BigD1^^r,°BigD1^^r) .sprite
Data(0,0) .téléportation
Data(°AirOK+°AbsY)
Data(0^^r,~450^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(0)

[]->°FoxShortHop .état Jump qui donne l'impulsion
Data(°BigD1^^r,°BigD1^^r) .sprite
Data(0,0) .téléportation
Data(°AirOK+°AbsY)
Data(0^^r,~256^^r) .V
Data(0) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(0)

[]->°FoxAir
Data(°FoxFallSprR^^r,°FoxFallSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AirOK)
Data(0^^r,°FoxGravity^^r) .V
Data(6) .arrowkeys influence
Data(°FoxAir^^r) .état suivant par défaut
Data(0)

[]->°PivotHelpless
Data(°HelplessSprR^^r,°HelplessSpr^^r) .sprite
Data(0,0) .téléportation
Data(°Piv+°AirNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°Helpless^^r) .état suivant par défaut
Data(0)

[]->°Helpless
Data(°HelplessSprR^^r,°HelplessSpr^^r) .sprite
Data(0,0) .téléportation
Data(°AirNull)
Data(0^^r,°FoxGravity^^r) .V
Data(6) .arrowkeys influence
Data(°Helpless^^r) .état suivant par défaut
Data(0)

[]->°FoxLand .Landing Lag
Data(°FoxLandSprR^^r,°FoxLandSpr^^r) .sprite
Data(0,0) .téléportation
Data(°GroundNull)
Data(0^^r,0^^r) .V
Data(0) .arrowkeys influence
Data(°FoxStand^^r) .état suivant par défaut
Data(pi00100111) .Repeat 7 frames
Data(0)

And I need to retract a constant to every "[]→", so I don't feel like doing things like
[]→°TEMP
°TEMP-°CST1→°CST2
for each of them :P

edit Alternatively, is there a way to "compile with .org 0" ?
Title: Re: Features Wishlist
Post by: Zemmargorp on August 26, 2014, 12:39:39 pm
For now, we can do this
[]→°CST
°CST1-°CST2→°CST3

But we can't do this:
[]-°CST1→°CST2

Could this possibility be added ? Basically, I have this file
Spoiler For Spoiler:
*See Hayleia's original message*
And I need to retract a constant to every "[]→", so I don't feel like doing things like
[]→°TEMP
°TEMP-°CST1→°CST2
for each of them :P

edit Alternatively, is there a way to "compile with .org 0" ?

For the time being, can't you generate the data in assembly (thus allowing you the use of .org 0) and then include it in Axe with the command Asm( ? Otherwise, the possibility of using constants this way is a good idea. By the way, your game looks nice !
Title: Re: Features Wishlist
Post by: Hayleia on August 26, 2014, 01:09:04 pm
Well yeah, I could theoretically rewrite that in assembly and use spasm... but given the size of the file already, you understand why I ask if there's an "easy" solution ;)
Actually, I could maybe add the "-°CST1" in my code since it is always the same constant for everyone. It would just waste an addition.

And thanks :D
Title: Re: Features Wishlist
Post by: Zemmargorp on August 27, 2014, 05:11:39 am
Well yeah, I could theoretically rewrite that in assembly and use spasm... but given the size of the file already, you understand why I ask if there's an "easy" solution ;) Actually, I could maybe add the "-°CST1" in my code since it is always the same constant for everyone. It would just waste an addition.And thanks :D

Yes, of course, I understand ! If your problem can be solved by only writing -°CST1 from times to times, then it's easier. Even though it'd have been better to generate the data in assembly, because you would have been able to define constants and flags with #define, and the data would have been more readable. (The only problem being then to copy by hand all the data generated in assembly into the Axe source.)

Moreover, it shouldn't waste an addition in the compiled program : doing math with constants is parsed by Axe and only the result is put in the compiled program each time you use the constant.
Title: Re: Features Wishlist
Post by: Hayleia on August 27, 2014, 06:20:36 am
It doesn't waste anything if I add an constant to another constant, but it does waste if I add a constant to a calculation that doesn't end with a constant addition.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 27, 2014, 06:33:44 am
It doesn't waste anything if I add an constant to another constant, but it does waste if I add a constant to a calculation that doesn't end with a constant addition.
Yes, indeed. But in your case (°CST1-°CST2→°CST3), it only wastes some bytes in the source program.



Talking about assembly, Axe Parser could also allow inserting text inside the Asm( command (interpreted as chars, not tokens). Currently, if I want to do this : Asm(..."HELLO!"...), I have to write Asm(...('H')r('e')r('l')r('l')r('o')r('!')r...), which is not very convenient !
Title: Re: Features Wishlist
Post by: Hayleia on August 27, 2014, 01:23:28 pm
It doesn't waste anything if I add an constant to another constant, but it does waste if I add a constant to a calculation that doesn't end with a constant addition.
Yes, indeed. But in your case (°CST1-°CST2→°CST3), it only wastes some bytes in the source program.
The thing is that I won't do "°CST1-°CST2→°CST3" because then this would require one more constant (the °CST1) and one more line for each [] I have (instead of []-°CST1→°CST3 I'd have to do []→°CST2:°CST1-°CST2→°CST3), which would be very annoying. A []-°CST1→°CST2 would be a lot less annoying. A .org would be even less annoying.

Actually, I see a lot of potential for that .org command O.O
That would help me with my data, and this would also allow people to write ramcodes very easily, even ones using absolute jumps.
edit the token used could be the same as #Realloc but with a r.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 27, 2014, 02:58:40 pm
Actually, I see a lot of potential for that .org command O.O
That would help me with my data, and this would also allow people to write ramcodes very easily, even ones using absolute jumps.
edit the token used could be the same as #Realloc but with a r.

So you'd like to see this command added to Axe ? #Reallocr being the equivalent of .org 0 ? Why not, it could be very useful... and it's also getting very low level  ;D  ! But another token should be used, with an opening parenthesis, to allow reallocating at any address (not only 0).
Title: Re: Features Wishlist
Post by: Hayleia on August 28, 2014, 01:17:01 am
No, #Realloc already has an opening parenthesis so #Realloc(0)r would be .org 0 and you could do #Realloc(L3)r if you wanted :)
Title: Re: Features Wishlist
Post by: Zemmargorp on August 28, 2014, 01:32:24 pm
No, #Realloc already has an opening parenthesis so #Realloc(0)r would be .org 0 and you could do #Realloc(L3)r if you wanted :)
Then it's fine, #Realloc( is a good token for your idea. And the syntax #Realloc()r could be added to restore the previous origin (before changing to 0 or L3), which should be done automatically at the end of any library/subprogram.
Title: Re: Features Wishlist
Post by: Matrefeytontias on August 28, 2014, 02:54:00 pm
We're saying #Realloc() already serves another purpose. It's used to relocate the A-θ vars to another address. For instance, #Realloc()r and #Realloc()rr would probably work.

I've talked to Runer112 about it some time ago, and he said the PC was very hackish in the Axe compiler, so adding those features is very unlikely to happen before Axe 2.0.
Title: Re: Features Wishlist
Post by: Zemmargorp on August 29, 2014, 09:02:57 am
We're saying #Realloc() already serves another purpose. It's used to relocate the A-θ vars to another address. For instance, #Realloc()r and #Realloc()rr would probably work.

I've talked to Runer112 about it some time ago, and he said the PC was very hackish in the Axe compiler, so adding those features is very unlikely to happen before Axe 2.0.

Yes, we were talking about using the r modifier, I just said that the token #Realloc( was a good token for this command. Let me guess : PC is calculated from the current position of the data in the compiled program, or at least is linked with it ? Well, it seems that there's a lot of work to do for Axe 2.0...

Something else : as using the r modifier on a variable only use its first byte, we could be able to do For(VARr,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)r). Maybe also do the same for big-endian, with rr.
Title: Re: Features Wishlist
Post by: Runer112 on September 02, 2014, 06:55:10 pm
Sorry for the lack of responding. I was both physically and somewhat mentally ill for a while, so I ceased basically all activities outside of eating, sleeping, and entertainment. Anyways...


In response to changing the code origin, as you guys have correctly figured out, Axe does indeed calculate PC directly from the offset in the compiled program. Making this user-controllable would probably be tricky from an implementation standpoint. There's also the important goal that I'd like to see Axe become higher-level over time rather than lower-level, an adding manual code origin control is quite contrary to this.

That's not to say this capability cannot be added, though. Since the theoretical Axe 2.0 looks a lot like C in my head, it should support functions. Both function and data definitions could support keywords or something similar that specify origin, which I believe would provide the functionality needed for most uses in a pseudo high-level fashion.

Something else : as using the r modifier on a variable only use its first byte, we could be able to do For(VARr,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)r). Maybe also do the same for big-endian, with rr.

I've imagined the code for a for loop with a one-byte variable in my head for a bit now and am of the opinion that the general result would probably be larger than a for loop using a two-byte variable. The problem is that Axe has to evaluate the minimum and maximums as two-byte values in HL because that's the only way it knows how to evaluate arbitrary expressions, so the potential savings of using a one-byte value and arithmetic are killed by the conversions between one- and two-byte values. (Side note: it may seem like the For(EXPR)r command has no reason to exist for similar reasons, but the difference is that once the two-byte value is converted to a one-byte value at the start, all following operations are one-byte only)

If both the minimum and maximum were constants, then all the logic could certainly be coded in smaller one-byte operations. But in the case that the compiler is special-casing for loops with constant bounds anyways, there's little point for the alternate one-byte syntax because it could automatically check if both constants are one-byte values and, if so, use one-byte operations.
Title: Re: Features Wishlist
Post by: Zemmargorp on September 03, 2014, 10:43:57 am
Something else (again) : allow to specify a step in loops, and optimize this when MIN, MAX, and/or STEP are constant. It was maybe not added to Axe because (I suppose) using While correctly instead could be more optimized, but writing For(VAR,MIN,MAX,STEP) is definitely nicer than writing the following code (which can be optimized in some special cases, for instance when (MAX - MIN) is a multiple of STEP  ;)) :

Code: (Quite ugly) [Select]
MIN
While -->VAR < MAX
.INSET CODE HERE
VAR+STEP
End
Title: Re: Features Wishlist
Post by: Runer112 on September 03, 2014, 03:57:33 pm
That should definitely exist, yes. I can't really remember why it doesn't... I guess I can try it at some point.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on September 03, 2014, 05:12:54 pm
Sorry to hear about the health issues Runer112. I hope nothing too bad (socially or physically) happened that caused this. D:
Title: Re: Features Wishlist
Post by: Zemmargorp on September 20, 2014, 10:00:10 am
Sorry to hear about the health issues Runer112. I hope nothing too bad (socially or physically) happened that caused this. D:
Oh, I didn't pay attention to the beginning of his message ! Runer112, I hope you're better now.

Here's another idea of feature to add to Axe Parser : when it doesn't find a library, it could search for it in groups. That'd be great for people who have a lot of libraries and don't want them to be shown in the program list, or when they're working on a single program from a big project split in multiple programs. Both are often my case  ;D !
Title: Re: Features Wishlist
Post by: Zemmargorp on October 08, 2014, 10:46:29 am
I was wondering if it would be interesting to do changes in some Axe functions to avoid as much as possible minor problems with the OS. For instance, when I use drawing functions, the graph is not marked dirty, so when after exiting the program I use the graph the curves drawn are mixed with the program's picture.

As, for a lot of reasons, Axe wouldn't be able to determine if the buffer is without fail changed during the program's execution (unless it would add a "mark graph dirty" after each drawing instruction, which is not a good idea), then why not adding a command which would mark the graph dirty ? Maybe rename a token like RecallGDB (which is not used yet) "DirtyGDB".

There might be other small "compatibility issues" like this one with the OS, but I don't have any other example.
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 09, 2014, 01:03:45 am
I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.

I think that making the program require a shell usually helps in certain situations, though.
Title: Re: Features Wishlist
Post by: Zemmargorp on October 09, 2014, 01:23:49 pm
I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.

I think that making the program require a shell usually helps in certain situations, though.

Well, indeed, they aren't Axe issues, almost all assembly programs using graphics mess the PlotSScreen memory area (unless they use another memory location, but that's hardly ever the case). But Axe can include a way to fix it.

As you said, it's the programmer's job to prevent this kind of problems from happening, so in the example I made, he would use the DirtyGDB command in Axe, and Axe Parser would add the compiled instruction "mark graph screen dirty" to the compiled program. So when the user comes back to the OS, the full graph will be redrawn, and there'd be no problem such as the cursor moving on the last picture displayed by the program instead of the curve which was drawn before.
However, if he doesn't want the compiled program to mark the screen dirty (because he used the drawing functions in a sub-program), then he should just not use the DirtyGDB command.

I don't see what the problem is ??? , and I'm not sure to have fully understood what you mean, especially your last sentence. Sorry :/ .
Title: Re: Features Wishlist
Post by: DJ Omnimaga on October 09, 2014, 03:37:01 pm
Oh I meant that DCS and Mirage erases the game graphics  from the screen upon exiting.
Title: Re: Features Wishlist
Post by: Zemmargorp on October 11, 2014, 10:26:19 am
Oh I meant that DCS and Mirage erases the game graphics from the screen upon exiting.

I doubt they really mark the graph screen as dirty... Do you know what they exactly do ?
Clearing the current display and/or the text screen ? Clearing the graph screen ? Mark it dirty ?


EDIT : I tried with MirageOS, and just remembered the app itself uses the PlotSScreen area, so indeed, it marks it dirty, whether the program uses it or not ! The downside or compiling your sources for a shell is that you need it shell the program. And if someone uses your program with a Mirage-compatible shell which does not mark the graph screen dirty, then compiling it for MirageOS was a bit useless !

However, people would better add a DirtyGDB instruction to programs that uses the graph screen instead of compiling it for any shell : adding this instruction will only add a few bytes to the compiled program, which won't require any dependency, whereas compiling it for MirageOS adds 37 bytes for the program header, and the shell is required to shell the program !
Title: Re: Features Wishlist
Post by: Runer112 on October 11, 2014, 11:59:07 am
That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.
Title: Re: Features Wishlist
Post by: Zemmargorp on October 13, 2014, 01:10:23 pm
That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.

Well, I don't have any other idea either, but this one seems fine to me... Using the RecallGDB token would put the DirtyGDB instruction close to StorePic, RecallPic, and StoreLCD ;), so it's good for programs which use graphics commands. (Otherwise it would also be possible to use DispTable which is just next to DispGraph, but this one is less logical.)

By the way, do you know if there are other cases where Axe instructions can cause some minor issues (but easy to fix) with the calculator's OS ? I thought of this one because I often use the graph screen in my programs, but there may be other cases similar to this one.
Title: Re: Features Wishlist
Post by: Hayleia on November 16, 2014, 05:35:31 pm
Would it be possible when there is an error to display the name of the (sub)program and the line the error was found in ?
Like
[--------         ]
Invalid Token
SMASHC2: 79

Might seem useless since we are meant to be able to jump to the error, but
1) we can't with zStart's small font editor
2) I can't with Smash (the main file is already over 25KB)
Title: Re: Features Wishlist
Post by: Runer112 on November 16, 2014, 05:53:31 pm
When an error occurs, the name of the (sub)program currently being compiled should already be on the screen. As for your issue of not being able to jump to the error to see the context... that doesn't really sound like Axe's place. Neither unfinished versions of zStart nor source files larger than RAM sound like things Axe should be expected to deal with. But I'll look into it regardless.

EDIT: How do you currently edit your files? That would probably help me figure out the best way to provide some sort of error context information that you can use.
Title: Re: Features Wishlist
Post by: Hayleia on November 17, 2014, 12:40:06 am
Yeah, the name of the (sub)program is ok, and it's not your fault if there is no jump, but that would still help me if you displayed the line.
For now, I edit my code using vim then tokenize it using tok8x, then send it to TilEm directly to archive to compile it. That's why I can edit it without having memory issues, I don't edit it on calc :P
Title: Re: Features Wishlist
Post by: Runer112 on November 17, 2014, 12:16:54 pm
Axe doesn't currently count lines for any reason, so to add a line number to error messages, I'd have to count explicitly for this. I've never heard anyone else come forward with this problem and it seems you could avoid it by splitting your main program up, which is probably better from a code organization standpoint regardless, and using the official version of zStart, for which the loss of the small font editor shouldn't matter much since it doesn't sound like you code in the emulator. So I'm rather hesitant to try to add such a feature as a combination of defense against feature creep and, well, my own laziness.

If this was a feature that would benefit other coders as well, I would probably be more willing to add it, but I think you might be the only one. :P
Title: Re: Features Wishlist
Post by: c4ooo on March 06, 2015, 07:33:19 pm
I want a line algorithem that does not cull (not render) the line if one of vertices of the line is not within the range of the screen. I don't rly see why it was implemented anyway. But if you dont,  I can write my own line algorithem so don't worry  ;) (but they won't be as optimized as they wood be if they where ActUaly part of the language.)  ::)
Title: Re: Features Wishlist
Post by: Runer112 on March 06, 2015, 08:13:42 pm
That's been on my todo list for a while, but it's a bit tricky to do optimally. And I generally don't like adding a new feature unless it's already well-optimized, which is why it's unfortuantely never made it into Axe. :-\ For now, I'd recommend writing your own clipping code and feeding the clipped coordinates into the line routine.
Title: Re: Features Wishlist
Post by: c4ooo on April 30, 2015, 07:56:45 pm
Can you make it so..
A) program will always be backed up, regardless if they are archived or not, and
B) that all subprograms used by main program will also be backed up.
 Several times already I had my files deleated or lost for some reason or another,(in archive too) and axe backup is sorta shaky to compleatly rely on.
Thanks,
Title: Re: Features Wishlist
Post by: Eeems on May 06, 2015, 04:01:18 pm
Can you make it so..
A) program will always be backed up, regardless if they are archived or not, and
B) that all subprograms used by main program will also be backed up.
 Several times already I had my files deleated or lost for some reason or another,(in archive too) and axe backup is sorta shaky to compleatly rely on.
Thanks,
Why do you want to back up an archived program? It sounds like you have another issue if the one in the archive is being deleted.
Title: Re: Features Wishlist
Post by: c4ooo on May 22, 2015, 10:24:38 pm
Can you make it so..
A) program will always be backed up, regardless if they are archived or not, and
B) that all subprograms used by main program will also be backed up.
 Several times already I had my files deleated or lost for some reason or another,(in archive too) and axe backup is sorta shaky to compleatly rely on.
Thanks,
Why do you want to back up an archived program? It sounds like you have another issue if the one in the archive is being deleted.
Yea, doors shell seems to occasionally delete archived files when i save them after editing them editing them. I dont have a cemteck account so i cant really report the bug. :P
Title: Re: Features Wishlist
Post by: Sorunome on May 23, 2015, 05:46:15 am
Can you make it so..
A) program will always be backed up, regardless if they are archived or not, and
B) that all subprograms used by main program will also be backed up.
 Several times already I had my files deleated or lost for some reason or another,(in archive too) and axe backup is sorta shaky to compleatly rely on.
Thanks,
Why do you want to back up an archived program? It sounds like you have another issue if the one in the archive is being deleted.
Yea, doors shell seems to occasionally delete archived files when i save them after editing them editing them. I dont have a cemteck account so i cant really report the bug. :P
Are you sure this is DoorsCS, though? That is a known issue if you use os 2.53MP
Title: Re: Features Wishlist
Post by: c4ooo on May 23, 2015, 11:46:21 am
Can you make it so..
A) program will always be backed up, regardless if they are archived or not, and
B) that all subprograms used by main program will also be backed up.
 Several times already I had my files deleated or lost for some reason or another,(in archive too) and axe backup is sorta shaky to compleatly rely on.
Thanks,
Why do you want to back up an archived program? It sounds like you have another issue if the one in the archive is being deleted.
Yea, doors shell seems to occasionally delete archived files when i save them after editing them editing them. I dont have a cemteck account so i cant really report the bug. :P
Are you sure this is DoorsCS, though? That is a known issue if you use os 2.53MP
You can make fun of me if you want, but i use 2.55MP   ._.  ;D
Title: Re: Features Wishlist
Post by: Sorunome on May 24, 2015, 05:26:55 am
Still not as stable as OS 2.43 ;)
How large is the program that is deleting itself?
Title: Re: Features Wishlist
Post by: c4ooo on May 24, 2015, 12:04:47 pm
Still not as stable as OS 2.43 ;)
How large is the program that is deleting itself?
Idk, i have like 5 files all of which are less then one KB. As one would expect, I mostly debug/program in/to one file, but sometimes i have to jump to a different file. AFAIK, the current amount of mem has no effect on wether it gets erased or not. It just seems very random. Another thing thou is that there is a pause when i exit the program, as if doors IS archiving the file, but it still disappears. The other weird thing is that altho i cant see the file in any mem menu, when i try to create a new file with the same name as the lost file, the os does not let (but IIRC it does not crash the calc).
Title: Re: Features Wishlist
Post by: Runer112 on June 04, 2015, 03:54:11 pm
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: Features Wishlist
Post by: Eeems on June 24, 2015, 02:11:11 pm
Be awesome option. Surprise us on what it does.
Title: Re: Features Wishlist
Post by: Xeda112358 on July 01, 2015, 11:55:29 am
Okay, since you tackled the parser, I have this feature wish:

Allow a very simple set of variable types.

I imagine you must keep the variable names stored somewhere, so maybe a byte indicating the variable type, too? You wouldn't have to do things like associate correct routines, though. Like just because an var is flagged as 8.8 fixed point, doesn't mean that multiplication of such a var should be automatically the fixed point multiplication routine. The current system for that, where the developer specifies is fine (and I like it that way).

However, here is where it can come in really, really useful. Custom variable types could be allowed and associated with an axiom. So if I wanted to make an axiom for rational numbers, I could have it specify a rational var type of 32-bits (2 16-bit ints) and have specially made math routines for those vars.

This might need to wait for Axe 2.0, though :P
Title: Re: Features Wishlist
Post by: c4ooo on July 01, 2015, 12:23:07 pm
Okay, since you tackled the parser, I have this feature wish:

Allow a very simple set of variable types.

I imagine you must keep the variable names stored somewhere, so maybe a byte indicating the variable type, too? You wouldn't have to do things like associate correct routines, though. Like just because an var is flagged as 8.8 fixed point, doesn't mean that multiplication of such a var should be automatically the fixed point multiplication routine. The current system for that, where the developer specifies is fine (and I like it that way).

However, here is where it can come in really, really useful. Custom variable types could be allowed and associated with an axiom. So if I wanted to make an axiom for rational numbers, I could have it specify a rational var type of 32-bits (2 16-bit ints) and have specially made math routines for those vars.

This might need to wait for Axe 2.0, though :P
I think @Runer112 thought of doing something like that, but hey, you have bean here longer then me so idk.
But the difficulty i see, is what will happen when you have a pointer, and the parser does not know where that pointer points, how will it ever figure out if it points to a float or a string? (It will only know if you have manually set the var like "Some string"->A, then it can figure out if A is a string or not)
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2015, 12:40:38 pm
Types are definitely something I want eventually, but I think it's going to have to be an Axe 2.0 thing. Even if I could flag variables as different types in the compiler, values being 16 bits large and stored in the hl register is ingrained throughout the compiler.
Title: Re: Features Wishlist
Post by: c4ooo on July 07, 2015, 06:12:09 pm
Can you add a return(x) command that will return x places up the stack? I know you can just do that with Asm(E1) (x times), but it might be something you might want to consider.
Edit: would it be possible to make it so that it returns up till a certain lbl in the stack, no matter how deep you are? (ex: main->engineStart->render, i call return(main) in the render method, it return to the point where main() called engineStart() )
Title: Re: Features Wishlist
Post by: Runer112 on July 07, 2015, 06:31:46 pm
It's impossible to safely return by multiple levels at once because anything can be on the stack, not just return pointers. So the nth return pointer could be n stack entries deep, n+1 stack entries deep, or n+100 stack entries deep. It's also just pretty gross from a language design standpoint.

In cases like this, I think you should consider using return codes as signals, or a code reorganization to avoid the "need" for multi-level returns in the first place.
Title: Re: Features Wishlist
Post by: Hayleia on July 11, 2015, 01:45:07 pm
So, did you "only" optimize or did you change the way the compiler works ? And in any case, with your changes, does that make the addition of .org easier or not ?

And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.
Title: Re: Features Wishlist
Post by: pimathbrainiac on July 11, 2015, 01:47:50 pm
And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.

I second this request. I always have to make programs that take my program with the data and convert into an appvar when I'm working with raw data appvars.
Title: Re: Features Wishlist
Post by: c4ooo on July 11, 2015, 02:17:45 pm
And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.

I second this request. I always have to make programs that take my program with the data and convert into an appvar when I'm working with raw data appvars.
+1 I usually just have another program to genarate the appvar. A possibility i see is that if a file has a special header (..NAME for example) that file file be genarate an appvar. So basicly you can do prgmDATA in your main program, and if DATA has a "..MYGAMEDATA" header, axe will genarate an appvar from the data in prgmDATA, while still compiling the other files normally.
Title: Re: Features Wishlist
Post by: E37 on October 27, 2015, 07:11:21 pm
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)
Title: Re: Features Wishlist
Post by: Runer112 on October 27, 2015, 08:22:24 pm
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)

I've abstained from providing hook functionality for a few reasons. But the main reason is that hooks are simply too low level and too closely tied to the OS.

To operate meaningfully, most hooks need OS RAM and call equates, and there are far too many of these to add as built-ins to Axe. In a similar vein, there are many useful hooks. If one was added, then it would only feel right to add the others, and this would also clog up built-ins. And if only some things existed as built-ins to avoid clogging them up, then you'd probably end up turning to assembly to fill some gaps. In which case, you could reasonably just use assembly for all of it. And you can already implement hooks with a minimal amount of assembly that run Axe code for their main functionality.
Title: Re: Features Wishlist
Post by: Geekboy1011 on October 30, 2015, 05:58:06 pm
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)

I've abstained from providing hook functionality for a few reasons. But the main reason is that hooks are simply too low level and too closely tied to the OS.

To operate meaningfully, most hooks need OS RAM and call equates, and there are far too many of these to add as built-ins to Axe. In a similar vein, there are many useful hooks. If one was added, then it would only feel right to add the others, and this would also clog up built-ins. And if only some things existed as built-ins to avoid clogging them up, then you'd probably end up turning to assembly to fill some gaps. In which case, you could reasonably just use assembly for all of it. And you can already implement hooks with a minimal amount of assembly that run Axe code for their main functionality.

Just to add a note to this. From my limited experiane with axe this is really what axioms accelerate at. Adding functionality that is out of scope for axe but would be really nice to have. Sadly yes you need to know asm for it, But it serves the purpose of setting/managing hooks far better then an internal setup.
Title: Re: Features Wishlist
Post by: E37 on November 03, 2015, 05:58:03 pm
After ten minutes of searching (probably in all the wrong places) I can't seem to find a keyhook axiom.
Do you know of any good ones?
Title: Re: Features Wishlist
Post by: Runer112 on November 03, 2015, 07:13:42 pm
After ten minutes of searching (probably in all the wrong places) I can't seem to find a keyhook axiom.
Do you know of any good ones?

If such an Axiom existed, I would've suggested it in my earlier response. So if you wanted to create any hooks, you'd have to provide your own assembly backing for it.
Title: Re: Features Wishlist
Post by: c4ooo on December 08, 2015, 08:37:43 am
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]
Title: Re: Features Wishlist
Post by: E37 on December 08, 2015, 03:14:23 pm
For the 2nd options page one option should to have zoom compile as default.
(Although 1.3.0's compile time is awesome anyways)
Also compile to archive would be cool also.
(so I don't have to archive a program after I compile it)
The ability to see hidden programs' names correctly would also be nice.
(Having my program's name start with some random character can make it sort of hard to tell them apart)
Title: Re: Features Wishlist
Post by: Runer112 on December 09, 2015, 10:17:45 am
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]

It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for?

However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance.

For the 2nd options page one option should to have zoom compile as default.
(Although 1.3.0's compile time is awesome anyways)
Also compile to archive would be cool also.
(so I don't have to archive a program after I compile it)
The ability to see hidden programs' names correctly would also be nice.
(Having my program's name start with some random character can make it sort of hard to tell them apart)

Although I am certainly looking for useful options to fill out the options menu in Axe 1.3.0, I'm not sure how I stand on a default zoom compile option. It doesn't save you any keypresses when compiling, you just have to press a different button to start compilation.

I do somewhat like the idea of an option to archive compiled programs. But I say "somewhat" because having your programs always archived does naturally feel more secure, but then I realize that if your program is buggy and crashes, do you really care about preserving it? Presumably, your next step will be to modify the source, either to attempt to fix the bug or add debug statements, and recompile anyways.

Regarding hidden programs, they're not a feature of the OS, just a hack of modifying the name to start with a strange character. And why would you want to hide an Axe source program, anyways? I can't see much benefit to having hidden Axe source programs, and without that, I don't see any reason to bother properly handling them.

Please feel free to try to add extra information to any of these ideas to sway me more towards supporting them. Despite how I may sound, I am open to additions, but I'd like to be fairly convinced that they will be worth it.
Title: Re: Features Wishlist
Post by: c4ooo on December 09, 2015, 03:48:15 pm
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]

It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for?

However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance.
This would be helpfull for modular programs. What i would do is disallow data creation in rel(1) mode (so no inline data and stuff); and error if the jump is over the 127 byte limit.
Title: Re: Features Wishlist
Post by: Runer112 on December 09, 2015, 04:51:59 pm
In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.
Title: Re: Features Wishlist
Post by: c4ooo on December 28, 2015, 10:19:53 am
In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.
My idea was to load the code into ram by sections, so that the program could be bigger. (But have some of its data in appvars) ;)
Title: Re: Features Wishlist
Post by: E37 on January 17, 2016, 12:41:00 pm
The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.
The option to run the program right after compile whithout having to go back to the home screen would be nice.
Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.
Axe could check if the program is the same before backing it up.
If you attempt to run a source code file it could compile then run.
A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2
The ability to write bytes directly to archive would be neat.
Add Memkit!!!
Pause until something happens, like pause until the enter key is pressed.
A command like Stop that makes the program quit rather than overflow an array.
A command to make a black hole!
The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)
Maybe more areas of free RAM?
Larger apps?
Draw text to different buffers.
Make the Line( command show up even when one end is off the screen.
A feature for a 2-dimensional list (matrix) would also be useful.


These are just some ideas I don't know how may are possible or feasable.
Title: Re: Features Wishlist
Post by: Runer112 on January 17, 2016, 03:27:59 pm
The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.

The Bitmap() command does this.

The option to run the program right after compile whithout having to go back to the home screen would be nice.

Sounds like a good idea.

Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.

Also a good idea, although it turns out to be a bit tricky to implement this. But I can look into it.

Axe could check if the program is the same before backing it up.

Another good idea.

If you attempt to run a source code file it could compile then run.

This would require a parser hook, which would clash with any other parser hook used to implement running programs from the home screen or hybrid BASIC libraries, and would make all BASIC programs slightly slower. So this isn't worth it. However, this functionality would fit well into any apps that already provide such hooks, like zStart or DoorsCS.

A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2

This shouldn't really be the job of a drawing comamnd, and it wouldn't really be any more optimal to include the functionality built-in. The user's code should make such adjustments.

The ability to write bytes directly to archive would be neat.

This is, for mostly all intents and purposes, not possible. Additionally, I'm not comfortable giving user code the ability to, whether intentionally or accidentally, destroy archived data or the OS— or if something went horribly wrong, the boot code, which would brick the calculator.

Add Memkit!!!

Yes, this should really be done. It could never fit before, but with all the optimizations that 1.3.0 brought, it might fit now.

Pause until something happens, like pause until the enter key is pressed.

Adding a built-in just for this would be entering the realm of feature creep (https://en.wikipedia.org/wiki/Feature_creep). This can be done very easily in user code: Repeat <something> : End.

A command like Stop that makes the program quit rather than overflow an array.

I don't understand what the "overflow an array" bit has to do with this, but if I'm understanding correctly otherwise, the Returnr command does this.

The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)

Libraries coded in Axe should be just that: coded in Axe. This provides many benefits, including the ability to easily see/modify the source if necessary and receiving the benefit of future compiler optimizations. If you're interested in particular features of the axiom system that are unavailable to Axe programs, you should request those directly.

As for compiling as an appvar, I can probably make an appvar compile target.

Maybe more areas of free RAM?

There aren't really many sizable areas of "free" RAM remaining. The fact that there were 6 decent sections and that there are 6 numbered list variables was a rather happy outcome that will probably remain that way.

If you want to search for more RAM to use, consider checking out thepenguin77's list (http://www.omnimaga.org/asm-language/8384-free-ram-areas/msg306283/#msg306283).

Larger apps?

Multi-page app development is hard enough in assembly when you have full control of paging. Coming up with a relatively painless way to provide multi-page app development to Axe code is even harder. I've brainstormed approaches in the past, but never came up with a satisfactory approach.

Draw text to different buffers.

The fact that text can only be drawn to the main buffer is a limitation of the OS's text drawing routines. Trying to replicate said routines would involve a number of obstacles that (from my perspective) simply aren't worth dealing with.

Make the Line( command show up even when one end is off the screen.

This request has been around for a long time, and it's definitely one that deserves to be implemented. But implementing it in a complete and relatively optimal manner is rather daunting and I haven't (nor has anyone else) been able to do so.

A feature for a 2-dimensional list (matrix) would also be useful.

Considering 1-dimensional lists don't even exist in Axe, this is a bit of a stretch. Implementing such constructs (properly) would really require a type system, which Axe doesn't have. Such features are the kind of things I'd imagine in an Axe 2.0, but I don't see that becoming reality right now.

These are just some ideas I don't know how may are possible or feasable.

I'm grateful for all your suggestions. It's nice to see that some people are still interested in making Axe better. :)
Title: Re: Features Wishlist
Post by: E37 on January 18, 2016, 11:03:31 am
As for making axe better, Is there anything else I can do?
Title: Re: Features Wishlist
Post by: Haobo on January 22, 2016, 03:31:17 pm
Some more things that might help with dealing with these.
The option to run the program right after compile whithout having to go back to the home screen would be nice.
Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.
If you attempt to run a source code file it could compile then run.
These were already implemented by zstart (http://www.ticalc.org/archives/files/fileinfo/429/42907.html). It has a bunch of shortcut keys to archive every program, edit programs from archive and exit without saving, and running the program right after compiling. It will also auto archive files that you compile in axe so that data isn't lost. Backing up files isn't really necessary if you can edit from archive, and axe already supports compiling from archive.


Pause until something happens, like pause until the enter key is pressed.

Not sure if this helps, but the getKey^^r function works pretty well for a temporary pause, until a button is pushed. For more specific inputs, you should probably make a function yourself for that.

Really recommend zstart if you are into programming on the actual calculator. It also allows you to jump to Lbl's throughout the program quickly in case the program is huge and the shortcut keys help a lot.
Title: Re: Features Wishlist
Post by: E37 on January 22, 2016, 04:05:27 pm
I already have zStart, I don't like the auto archive function though.
Title: Re: Features Wishlist
Post by: Haobo on January 24, 2016, 03:28:19 am
Don't really know why you would not archive it. Saving programs might be a bit longer, but it's still a lot better than duplicating the program in memory, which is what the backup does. Archiving just gives it a double failsafe. Plus, you can use it as a temporary version control (though with only 2 versions) since axe doesn't backup archived programs.
Title: Re: Features Wishlist
Post by: E37 on January 24, 2016, 11:23:05 am
I make lots of test programs and like to use the on + trace/zoom to run them. I don't need to them to be archived.
I guess I am probably overly worried about long-term damage on my archive.
Title: Re: Features Wishlist
Post by: E37 on April 18, 2016, 06:06:09 pm
I have a couple more ideas!
The a function like the += command in Java would be really cool! (5 +-> x instead of x+5->x)
Setting to zoom compile by default
The ability to treat lists like matrices (like # -> {L1}{row}{col} instead of # -> {rows # col + row + L1}) would save SO many headaches
Again, I don't know how easy to add any of these are. (but the matrices one would be really nice)
Title: Re: Features Wishlist
Post by: neuronix on June 30, 2016, 12:04:54 pm
Add a line per line debug function :D
Title: Re: Features Wishlist
Post by: E37 on June 30, 2016, 07:00:58 pm
Add a line per line debug function :D
While that would be awesome, I don't think that would be very practical on calc.
If you want a debugger your best shot is wabbitemu.
Title: Re: Features Wishlist
Post by: neuronix on July 01, 2016, 09:18:51 am
When I say a debugger line per line, I would say when I compile, I try to compile line per line and disp the error message for the line ;)
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2016, 09:23:41 am
When I say a debugger line per line, I would say when I compile, I try to compile line per line and disp the error message for the line ;)

The compile error screen doesn't present the context for the error, but pressing just about any key except CLEAR will go to the exact location of the error in the program editor. Does this not serve the purpose you're requesting?
Title: Re: Features Wishlist
Post by: neuronix on July 01, 2016, 10:04:49 am
Yes, but if the program is archived, this function don't work :-\
Title: Re: Features Wishlist
Post by: Runer112 on July 01, 2016, 11:15:21 am
Yes, but if the program is archived, this function don't work :-\

Yes, that's generally true. But I'd recommend trying zStart (http://www.ticalc.org/archives/files/fileinfo/429/42907.html). It's a utility program that does many things, including editing archived programs, which works with Axe's error goto feature. It also provides lots of helpful editor hooks like jumping to labels by name and shortcuts to compile your program without even leaving editor. Also, zStart can be configured to run automatically after RAM clears, so all of its hooks and behaviors can reinstate themselves without needing to run it every time.
Title: Re: Features Wishlist
Post by: neuronix on July 04, 2016, 10:00:10 am
I currently use zStart, but it isn't very stable :-\
Title: Re: Features Wishlist
Post by: Eeems on July 05, 2016, 01:07:25 pm
I currently use zStart, but it dosen't isn't very stable :-\
What version of it are you running? What are the stability issues you are facing? What version of TI-OS are you running?
Title: Re: Features Wishlist
Post by: neuronix on July 06, 2016, 05:27:07 am
I currently use zStart, but it dosen't isn't very stable :-\
Sorry, I have modified my post :-\
What version of it are you running? What are the stability issues you are facing? What version of TI-OS are you running?
I use zStart 1.3.013 : http://www.ticalc.org/archives/files/fileinfo/429/42907.html
Title: Re: Features Wishlist
Post by: Eeems on July 06, 2016, 01:01:25 pm
What version of it are you running? What are the stability issues you are facing? What version of TI-OS are you running?
I use zStart 1.3.013 : http://www.ticalc.org/archives/files/fileinfo/429/42907.html
And what version of TI-OS?
Title: Re: Features Wishlist
Post by: neuronix on July 07, 2016, 08:10:30 am
I have a TI 84+ SE with OS 2.55MP
DoorsCS7 is installed.
Title: Re: Features Wishlist
Post by: Eeems on July 07, 2016, 01:42:19 pm
I have a TI 84+ SE with OS 2.55MP
DoorsCS7 is installed.
2.55MP might be the source of the stability issues.
Title: Re: Features Wishlist
Post by: Runer112 on July 07, 2016, 01:56:49 pm
I have a TI 84+ SE with OS 2.55MP
DoorsCS7 is installed.
2.55MP might be the source of the stability issues.

I run zStart with 2.55MP with no issues.
Title: Re: Features Wishlist
Post by: neuronix on July 07, 2016, 02:07:04 pm
I kill all hook.
After, I uninstall zStart then I reinstall zStart ;)
Title: Re: Features Wishlist
Post by: TIfanx1999 on July 07, 2016, 02:22:21 pm
There were issues with doorscs7 and Zstart in the past. Thepenguin(creator of Zstart) let Kerm(DoorsCS7) know about them so they could be fixed. I'm not sure if that ever happened though.
Title: Re: Features Wishlist
Post by: Eeems on July 07, 2016, 02:49:47 pm
/me  pokes @KermMartian
Title: Re: Features Wishlist
Post by: neuronix on July 08, 2016, 09:53:19 am
Ok,
Thanks for all response ;)
Title: Re: Features Wishlist
Post by: E37 on August 12, 2016, 06:41:59 pm
So, I've been thinking. About Axe. I have a couple ideas on changes.
1. Push over into a 3rd app page. Since you are optimizing heavily and can barely fit memkit in, it seems inevitable that the parser will push over into the 3rd page. It seems like a matter of time, and 1.3.0 would be a good time to implement it. This would allow more room for new features and possibly the implementation of other axioms.
2. Add a way for axioms to be implemented in the parser. Perhaps a series of questions or some kind of application process would work.
Title: Re: Features Wishlist
Post by: Runer112 on August 12, 2016, 06:51:51 pm
So, I've been thinking. About Axe. I have a couple ideas on changes.
1. Push over into a 3rd app page. Since you are optimizing heavily and can barely fit memkit in, it seems inevitable that the parser will push over into the 3rd page. It seems like a matter of time, and 1.3.0 would be a good time to implement it. This would allow more room for new features and possibly the implementation of other axioms.

If I wanted to add more than one or two features, this would probably be necessary. Throughout my heavy optimization process, I became more familiar with the layout of the Axe application and how it's split across two pages, so extending that to three may not be as challenging now. The one thing I'd be worried about is the one extra page being too much to ask of users with very limited archive space, especially basic 83+ users.

2. Add a way for axioms to be implemented in the parser. Perhaps a series of questions or some kind of application process would work.

It's not an official, but the way exists: just ask me. This of course depends on me actually adding them and making a new release, which I've been rather sluggish about lately.
Title: Re: Features Wishlist
Post by: E37 on December 24, 2016, 05:58:01 pm
Well... I have a couple more thoughts.

A function that adds/subtracts and expression to a variable. It is like ++ and -- but with an amount defined by an expression. I was thinking EXPRESSION+ -> VARIABLE and EXPRESSION+ +> VARIABLE. While this wouldn't save any space on uses like: 5+ -> A, It would save the need to re-evaluate in cases like this: {A+4}+5 -> {A+4}

I know that some of the math functions on 1.3.0 are broken. Would it be possible to replace those with the working functions from 1.2.2a and still keep the speedy compile time?

Perhaps Axiom like parsing of assembly hex code inside the program? The command AxmAsm(HEX) could allow for the same replacing of labels with their correct address and the calling of axe functions (If that wasn't already avaiable)

Redoing the boxplot tokens to andr orr and xorr would be really nice so that it is easier to tell their function.

An improved text routine would be awesome! Displaying Text with Axe's Pt-on is faster than the Os's version (I tested) and I am sure that faster text would be handy in games. (I don't know about numbers)

Better constant support! Adding built in constants like the location of the pen and cursor would be handy. (but not really needed)

The ability to have a more general Select( that works on all commands would be nice. It would be nice if all commands returned a value. Even if that returned value is garbage, it should be up to the programmer not the parser to know what to use. That would fix the Select problem of course!

I don't know how to implement this, but allow a subroutine to know how many arguments were used to call it would be nice for using default values and overriding if no input is given. This would be really handy in libraries.

Like I mentioned before, "Run after compile" would be really nice. I think the reason is pretty obvious.

While it isn't a feature, I would like to know how Axe decides to do custom token replacements. Does it simply check if the os is in program edit mode and check the first bytes of the edit buffer? Or something more in depth? I would like to know so I can trigger the custom tokens in my programs without having to check each token.

Please tell me if any of my ideas don't make sense! I can supply assembly code for most of the ideas if you want.
Thanks!
Title: Re: Features Wishlist
Post by: neuronix on March 05, 2018, 11:36:41 am
It could be a good thing to back up the libraries used in a program.
Because if I lost those one, I haven't any save of them, only the main program ;)
Title: Re: Features Wishlist
Post by: Streetwalrus on March 08, 2018, 04:41:23 pm
I'm not sure what you're talking about, but the compiler is able to read archived files, so just keep libraries archived and it'll be fine.