hmm quigbo how much of the total app space have you used up so far??(out of teh whole thing :))
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"?
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.
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.
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 think you should keep the old way, but start counting at 0 instead of 1.
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?
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.
Haha, i would suggest using x,y and starting at 0 :PI'd have to agree here. =)
ACHIIDo you mean ASCII?
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!
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.[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.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).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.xDJ, 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
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.
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.
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
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.
@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
I was thinking something along the lines of this. I whipped it up in about an hour: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
(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
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?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?)
I never heard of tokenized sprite before x.xDJ, this is what the calc stores Asm Programs in as AsmComp( takes them from Hex to Tokenized binary.
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. :DActually, 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 "??"
The next version has already taken care of getting 'illegal' characters into strings using standard tokens.But shouldn't << be shift left or something?
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 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( ?
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.
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?
prgmAA arg1 arg2
and then prgmAA could do something like thisoutput(0,0,%1
Does that cause a mem leak like in Basic?No because it is compiled into assembly. There are leaks in assembly, though... But with different nature of the BASIC ones.
I can't wait to try 0.0.5! ;D
*ZTrumpet hurry's over to download...
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
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.
I was thinking something along the lines of this. I whipped it up in about an hour: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
(http://www.omnimaga.org/index.php?action=dlattach;topic=1460.0;attach=646)
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.
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
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 :PGotcha. I figured that is what was going to be.
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.
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:Awesome!
:!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.
!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.
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:
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? ;DYou 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.
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 :)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.
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?
Couldn't you easily write that yourself though?Yes, but it would be way slower and more bloated. It would translate much more easily to a few ASM opcodes.
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.As i see. Well in that case get right on it Quigibo! :P
I fail at understanding the concept of fill x.xI mean like a pure data fill, which would work a lot like the TI-Basic version (except with any data area and any length)
Do you mean like in Paint when filling an area with a color or just like a rectangle routine?
rectangle routines would be cool
*Port accessThat can be done with inline ASM. Most people who would know how (or even need) to use ports will probably know ASM.
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.
That's actually really freaky that you mentioned Fill() because I just so happened to have written that command last night :oMaybe he lives very close to you and is stalking you in secret? :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.
I also think we need the And, Or, Xor, and Over-write commands when dealing with pictures. :)+1
I CAN HAS EASTER EGGS? :PHow 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 CAN HAS EASTER EGGS? :PHow exactly could easter eggs work for something like this? Pressing some random key sequence in the app lets you play a game of Tetris?
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 MirageOsSince Mirage shows Ion programs, you can use a ion header to make programs show up in both Mirage and Ion. :)
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.xYeah, 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.
#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
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. :) )
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 arrowsThe 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.
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'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.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.
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.
The ability to draw the back-buffer directly to the LCD
The ability to store the LCD content straight to the back-buffer
You would probably have to change them to this to preserve the actual LCD buffer.Is it still safe, though? I guess it might be since:
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?
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
I also would like the ability to use ElseIf:
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.
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.
Hi and welcome here ^^Thanks!
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)thingA) DJ Omnimaga is an admin
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)
yes, I'am sorry, I've chosen the wrong words. :-[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.
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?
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...:-[
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.
can someone please explain how a counter statement will work?Quoted from Quigibo on a chat a few days ago, in BASIC you would do this:
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 ???
A+1->A
If A=20
0->A
<do stuff>
End
In Axe you would be able to this equivalent:IS>(A,20)
<do stuff>
End
Another feature idea, after Quigibo mentionned me might compress his title screen: Compressed sprites routineSprites 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
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...
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?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.
I agree here. I think a longer compiling time would be better than having to compress things by hand.Wouldn't there be a way to make Axe do the compression/decompression for us?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.
I would like text compression, tho, it would be nice for games with loads of it
On that note, Portal X must be finished before Portal 2 comes out.On that note, Portal Gold, X, and 2 should all be worked on! ;D
My soul will be ripped in two otherwise. D:
Find ValueWhy are there different modes?
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.
:"MYVAR->Str1
:"Saved.->Str2
:Select(Str1)
:GetCalc(50)->A
:45->{A+24}
:If inString(Str1,45)
:Disp Str2,i
:End
including Input and Outputted results as examples?
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?
PwrReg HL
orref(HL)
orGet(HL)
perhaps it could be usefull to be able to call the register values from the processor? like 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)
the following code would return the value of ans:Code: [Select]PwrReg HL
orCode: [Select]ref(HL)
orCode: [Select]Get(HL)
I dunno if I said it already but...The Pen token is unusable in programs, FYI
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).
I think Quigibo is already planning to use IS>() and DS<() for increasing and decreasing with a specified "wrap" valueThe 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)
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.
AB->A
Disp A>Dec ; Display the address of AB
Return
Lbl AB
Disp "Hello World"
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"?
I don't belive you can store to <theta> with Axe. At least, I couldn't do it in version 0.1.2.
Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.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.
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.
just one bit, not even byte? Darn, now to send an entire byte...Well, you can only send two bits at a time, and you don't have to recieve at the right second, either.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.
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.
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 :PThe problem here is that bits may be skipped. Not good D:
that was my worry about linking stuff.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 :PThe problem here is that bits may be skipped. Not good D:
2) What do you mean by "Switch statement" in the features wishlist? I think I heard it mentionned before but I totally forgot x.xIt 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)
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
Switch(A)
1:Bla
2:Woooo
3:Grrrr
4:Rickroll
5:Chocolate rain
6:Lobser
End
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 statementsRight, its much more efficient in an assembly program to do switch statements than a bunch of if statements.
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" tagIn 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 statementsRight, 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.
Hmm...It would produce faster and smaller z80 code.
I can't really see the purpose of this command...
What are the benefits of having this over saying If A=0:End, etc... ?
Does the parser support conditional form: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)
While (A=0)(B=0)(C=12)
cuz i use that alot now.
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.
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 ;)
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
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?
================================================
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"
mhmm ok so if for exampleYeah, you've got it right (except we refer to the rightmost bit as bit 0, and the leftmost as bit 7)
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.
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 bitHmm, this is true. Maybe there should be a command to return powers of 2 for quick bitwise operations.
I would love this feature, though, because it would make storing switches/treasure chests/items acquired flags much easier and smaller.
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.
It will work like this:Aaah ok.
[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.
[...] 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.
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)
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.
The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.
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.
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.
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"
DJ, you can substitute your own addresses instead of L1 - L6 if you want. L1 - L6 are just numbers after all. :)
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! ;DDJ, 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.
:Asm(prgmAXE1
:<TI-BASIC code>
:Asm(prgmAXE2
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.Awesome! I'm going to like these new commands. ;D
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.
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.That sounds really cool actually! =D That'll be fun to play with once you get around to implementing it. :D
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 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. ;DNot 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?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. ;DNot 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.
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
Lbl RC
For(F,A,C-1
For(G,B,D-1
Pxl-Change(F,G
End
End
Return
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 muchYou 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.
-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
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.
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?
Coming Soon: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)
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.
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End
If you want to actualy change the sprite data itself, you could run this: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.Code: [Select]For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End
and then the sprite will stay inverted forever after.
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. :)
you cannot actually update the screen itself with the new contrast value
It just directly updated the screen
While (A>100) or (A<10)
rand/1000->A
End
rand^91+10
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
rand^(10-1+1)+1
rand^10+1
rand^(666-333+1)+333
rand^334+333
Good sir, I don't believe all of those commands in above program work.
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
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.You mean Horizontal X1,X2,Y1 or something like that, right?
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.
I hope so too, otherwise it would be kind of like a BSOD/LCD Test Mode without the overload of electricity. O.oI 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.You mean Horizontal X1,X2,Y1 or something like that, right?
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.
/me hopes Quigibo was planning to actually let the user choose where to draw the line x.x
Keep in mind App compiling will take over 10 minutes on-calc, though.
I thought they only had to be signed when transferring them to other calcs.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 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.
@SirCmpwnThat 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.
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.
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.You could always ask Kerm to add Axe support to Sourcecoder :)
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.
A+1->A
Disp A>Dec
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)Code: [Select]Disp A+1->A>Dec
Yes, I also like the syntax after understanding the implications.Gotta love how we can do that ;D . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)Code: [Select]Disp A+1->A>Dec
ld hl,(var_a)
ld a,h
or l
jp z,_
ld hl,(var_b)
_
ld hl,(var_a)
ld a,h
or l
jp nz,_
ld hl,(var_b)
_
sorry for being slow...but what will that allow us to do that the current code won't?
:56→V
:If V
:Disp "V is not zero"
:End
I think it would be nice indeed if it worked like TI-BASIC. I always had trouble with If conditions otherwise x.xMe too. :)
"A and B"
ld hl,(var_a)
ld de,(var_b)
ld a,l
and e
ld l,a
I'm confused why that code is any different than the current code:It is partly a speed optimization, yes. Also, I believe it could be smaller when using expressions, likeCode: [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.
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
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.
1 more thing to the wishlist: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
15Mhz GrayScale
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).1 more thing to the wishlist: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
15Mhz GrayScale
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.
Also, while you're at it, could you unsticky the token poll since that's already been resolved. Thanks! :)Unstickied. :)
Axioms (ASM libraries)
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.
Sadly, yes,
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
Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to MirageWell, 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.Oh ok, I thought custom ones would overwrite Mirage's, causing potential crashes on exiting back to MirageWell, 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.
{O+1*Y+X+L1}+1->{O+1*Y+X+L1}
{O+1*Y+X+L1}++
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).
EDIT:
@DJ
Yes, faster horizontal and vertical lines would be part of geometry drawing.
I made the poll so you can change your vote now
patience is a vitue... :PNo. :P
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
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
-Read and write to more calc variables (like Pics)
-Elseif
-Geometry drawing (circles, squares, etc.)
-Automated tile-mapping
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.
"prgmPROGSRC"→Str0
Archive Str0
UnArchive Str0
Also, Saftey Features should be "Safety Features".Good catch. I got it fixed. :)
... 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.
:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
:[Pic1]->Pic1
:Zeros(12
:.You need to fill in the last row
:Copy(Pic1,L6,768
Edit: some letter cases were incorrect
Is there an efficient way to 'swap' the buffer and back buffer? If not, I'd be nice to have that.I believe you are talking about the Copy() and Exch() commands.
Also, is there a better way to store an OS pic to the buffer besidesCode: [Select]:[Pic1]→Pic1
:Pic1→DispGraph
:StoreGDB
:ClrDraw
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.
Correct. The only way it helps is if you want a tilemapper or something to be able to export to a string.
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?
For(A,8,3,-1
@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.
DrawInv
Line(X1,Y1,X2,Y2
DrawInv
Or you can just do DrawInv once, draw all of your white lines, then use DrawInv again.
the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.Eh, Pxl-Change? ???
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.
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.
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.
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)
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.
Line(0,0,96,64)
Exch(L3,L6,768)
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)
@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.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.
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.
Maybe have a number (not sure if all of them are taken already)
This is more like a feature retainment request than a feature request, but you could you keep the single-argument Output(?I'd like to see the one argument Output( as well. I use it a lot, and it should be easy to keep. Thanks! :)
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 would like all three of these. They all sound useful, and I really want the first one. :)Would anyone be interested in any of these? I would probably use the Plot1() - Plot3() tokens.
- 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
Well the first one for sure I will add...Yay! ;D
I guess I'll keep the single line coordinate method for Output() and Text()...
I've got archive reading completed...
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
@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.
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.
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.
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. This kind of thing would open Axe up to serious programmers, for serious purposes.
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.
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.
Pt-On(X,Y,FlipH(Pic1))
Copy(FlipH(L1),L1,8)
is the following code valid?Code: [Select]Copy(FlipH(L1),L1,8)
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 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
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)
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.
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?
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.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. :)
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.
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. :)
I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.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())
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 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
:
:A*12+(B/8) .The last expression used becomes the switch statement automatically
:Case 0
: .Function1
:Case 83
: .Function2
:Case -1
: .Function3
:End
:
"HELLO"->Str1
Str1+" WORLD"->Str1
See the TI-Basic code below: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]"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)?
.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)
I also have a feature request. A function for _Insertmem and _Delmem (with a warning to use wisely :P)O.o
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"You need to do Disp Str1. :)
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?
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
.AB
"Hello"->Str1
Zeros(6)
" World"->Str2
Copy(str2,length(Str1)+Str1,length(Str2)+1)
Disp Str1
While getkey=/=9
End
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
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.
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.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...
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?
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
...
:While U>4
:U-1→U
:While U>4
...
If GetCalc("Pic1",768)->A
.Modify the picture here
End
GetCalc([0760]Data(#,0))->A
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.
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?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.
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
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.
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 tilemappingExactly. 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
this:
ld b,h
ld c,l
pop hl
can become:
ex (sp),hl
pop bc
Its slightly slower, but its one byte less.
.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
Can't you do that with the Euler's constant 'e'?ow yes, youre right! thanks!
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: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?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.
so I would realy like to see multipage apps with more than one page of code :)
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'm not familiar with how enabling the cursor works, I'll have to look into it.
I'm not familiar with how enabling the cursor works, I'll have to look into it.
Isn't it a b_call?
Also, bumping my request for Alpha+Letter in the compile menu.
I´d like to have a built-in "Menu(" featureIf this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs
would be very useful I think...
what do you think about that?
Also, bumping my request for Alpha+Letter in the compile menu.
I´d like to have a built-in "Menu(" featureIf this is added, I would like if it was not limited to 7 choices like in TI-BASIC and possibly allow multiple tabs
would be very useful I think...
what do you think about that?
.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.
.PRGMNAME SPRITE TARGET DESCRIPTION
Oooor.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.Code: [Select].PRGMNAME SPRITE TARGET DESCRIPTION
You could recognize each space before DESCRIPTION as something else. :D
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.
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?
Program:TESTSRC
.prgmHEADER
DiagnosticsOff
.and the rest of the code...
Program:HEADER
TEST "A little test prog" [8142241818244281]
:.TEST -T MOS -I [123...DEF] -D This is a description
:.TEST -D This is a description -I [123...DEF] -T MOS
Program:TESTSRC
.HEADER prgm
DiagnosticsOff
.and the rest of the code...
Program:HEADER
TEST "A little test prog" [8142241818244281]
:.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: @NemoWhat about arbitrary shifts? That should be as simple as "ld b,shiftamount \ call shift_right", etc.
Yeah, *2 is shift left and /2 is shift right. They automatically optimize to the bit-shift instead of the multiplication.
It will be a set of extra parenthesis:Does this work with sub() too?
Goto A Jumps to label A
Goto (A) Jumps to the address that the Variable A holds
It will be a set of extra parenthesis:My main question was "If I have a label A, how do I get its address?" ;D
Goto A Jumps to label A
Goto (A) Jumps to the address that the Variable A holds
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
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.
Ah, right, my bad. My questions about {L1} and {{L1}} become about (L1) and ({L1}), then :)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
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"?Oh ok.
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.
:If A and Not(B)
:Conditional code
:End
:If A
:!If B
:Conditional code
:End
:End
which would appear to be less efficient.:If A and (B<>EXP2)
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:that could work too
*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.
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.
Code: (Your main program) [Select] .PROGRAM | Code: (prgmINCLUDE) [Select] .. |
@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.
@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?
[table][tr][td]Put one code block in here[/td][td] [/td][td]Put another code block in here[/td][/tr][/table]
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
Disp "Hello"
prgmZCLRHOME
Disp "Goodbye"
ExecprgmTEST
orExecProg("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(
Pt-Command()→BUFF Performs any of the Pt-On(), Pt-Off(), or Pt-change() routines to an arbitrary buffer of your choice.
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:
Why would animated tiles be any slower than regular tiles? Don't you have to display them every frame anyway?
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 959CI 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.
D:
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().
<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
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
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].yes, go to the value stored in X
The switch-statement would be very handy for this in the future, but isn't implemented yet...
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. :)
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. :)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)
SetRet(LBL)
...
Return
...
Lbl LBL
ld de,LBL
push de
...
ret
...
LBL:
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
/\yeah, 8*16 sprites would be absolutely invaluable in the things im working on right now
EDIT: ninja'd? that was referring to ztrumpet
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.
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.
:X+1
would leave the value of X+1 in HL. For the others I guess you'd need Asm( as well...
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(.
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.
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.
There is no bcall for making menus as far as I am aware.
Don't Bcalls location changes from an OS to another too?DJ, not really. Normally they are only added.
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.
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.
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.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.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 ;)
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.
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
[[A,B,C,D,E,F,SUB,etc.]]→GDB0
Goto GDB0,X
.or
sub(GDB0,X)
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. :)
I think an on-calc documentation of all the commands would be most excellent.That would take a lot of space... D:
As I've always said, I want a CtlgHelp style system. The minus button could even be used instead of the plus. ;D
yeah, I'd be fine with a small yet complete doc on calc
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. :)
As I've always said, I want a CtlgHelp style system. The minus button could even be used instead of the plus. ;DNot 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. :)As I've always said, I want a CtlgHelp style system. The minus button could even be used instead of the plus. ;DNot 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. :)As I've always said, I want a CtlgHelp style system. The minus button could even be used instead of the plus. ;DNot really, since 'W' is the letter on the minus key :( '0','.' or '_' are other options, though.
yeah. I'm guessing it's like in Omnicalc, where in the extra prgm commands you press + and it displays the parameters.
EDIT3: Ninjas ninjas everywhere!
EDIT4: Can i ever escape???
EDIT5: Help meeeeee :(
* ZTrumpet eats everyone... :P
Only about 20 of them are used by axe :P
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.
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
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)
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?
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'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.
I agree with moving the variables to L2.Would it cause problem with Mirage, though?
I also second the backbuffer line drawing request, but I want to extend it to allow lines to be safely drawn off screen.
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).I've been thinking of writing a program to do this, I'll get back to you on it later.
Is it possible?
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)
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).I've been thinking of writing a program to do this, I'll get back to you on it later.
Is it possible?
That might be cool, as there are still 82 STATS/83 users (both the same calc) around in Europe.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).I've been thinking of writing a program to do this, I'll get back to you on it later.
Is it possible?
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.
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.
ld hl,(A)
push hl
ld hl,(L?+4)
pop de
add hl,de
Could be optimized to be like normal variable addition: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.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:
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. :)
.PROGRAM Description
.[16*16 hex icon]
[i]program code[/i]
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. :)
Asm(AF474FEDB921FFFFED42)
Just put the pointer value right before that.
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.
.Axe
prgmSUB
..SUB
While 1
Output(0,0,"Ahhhh
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 :(
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.
.MainProg
prgmFOREACH
.Do Stuff to element
prgmENDEACH
..ForEach
.Initialization
For(A,0,N)
.Setup
..EndFor
.Clean Up
End
.Destructor
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
I don't know if this has been requested, but 32 bit math would be awesome.
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.
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!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.
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.)
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
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.
Calculators can't have sound, so guitar hero wouldn't be as cool.Yes they can?
OOOOH MYY GOOOD, I WANT HEADPHONES, WHAT TYPE?Calculators can't have sound, so guitar hero wouldn't be as cool.Yes they can?
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.
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.Yeah, the sound quality was really low, but it still demonstrates that sounds in-game is still possible :)
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.)
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.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).
(I think it's one of those programs that relies on the extra RAM, so it won't work on recently-manufactured 84+es.)
Midi([INSTRUMENT NO],[FREQUENCY])
Hookless mode!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).
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)
I would like to be able to use Apps as Libs, like we have ExecLib and OpenLib in BASIC!That might be nice, but those games would not run on the TI-83+ and TI-83+SE :(
(for use with USB8x)
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...)
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)
Strange, maybe it's an OS/calc-specific issue?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.
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
Yeah, that's the one I was thinking of. The UTI thread is now at http://www.unitedti.org/forum/index.php?showtopic=8917 .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
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.
Oh, andThat can be done using a simple Asm(E9), which will jump to the address of the last result
- Allowing jumping to an arbitrary place in memory
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...
This is why we need a switch statement.
Ah sounds cool, thanks for the info :)
By the way I'll create the sub-forum for it now so you can post :)
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.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.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)?
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.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...
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(.
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.
"Up"->Str1
"Down"->Str1
I really want this to be possible:Code: [Select]"Up"->Str1
"Down"->Str1
I'd love to see that *.*
:"Up"→Str1 .Original value
:[0000] .Two extra zeroes for padding because "Down" is two bytes longer
:"Down"→Str2 .Temporary pointer
:Copy(Str2,Str1,4)
;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
;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. :)
These should not be hard to make and I expect them in next version, so.
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 really want this to be possible:"ERR:DUPLICATE"Code: [Select]"Up"->Str1
"Down"->Str1
I'd love to see that *.*
"Up"->Str1
"Down"->Str2
If CONDITION
Str1->A
Else
Str2->A
End
So A is your variable pointer :)
Repeat getKey->K
End
If K=4
("Up")->P
ElseIf K=1
("Down")->P
Else
("Neither")->P
End
Disp P
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)
;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
;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
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)
Quote from: calc84maniacYou 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...
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
Something like this would be great. (http://ourl.ca/4129/80700)You can already compile for MirageOS. Check out the Options menu :)
I think he meant built-in icon support, like you can define a description.
It's been requested before, I believe.
Matching icons to each program would be too complicated.
.Program [hex for icon image]
or something similar
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 beCode: (for example) [Select].Program [hex for icon image]
or something similar
[19:19:29] <nemo> anyone know how to add a DCS description in an Axe program?
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?
- Allowing For( to take any mem location as a variable. For example, For({L1},0,255) would be really useful.
Nope, no pi. I think Quigibo was thinking of adding it for a different purpose, though (quickly saving as temporary mem).
3.14159265358979323846264338327950288419716939937510->P
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
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.
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B
sin(A)*256//256
Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this: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.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
its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.
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?
Request:Don't you add r to write at the back buffer?
Also, I'm pretty sure this has been requested before, but a way to draw lines and write text to the backbuffer. Please?
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...
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 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.
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.
...?
Has anyone asked for automatic backup of program dependencies?
If I import prgmB into prgmA, then compiling prgmA would backup both prgmA and prgmB.
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.
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.
I think this is a really good idea. :)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
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)I think this is a really good idea. :)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
You can already compile Axe programs as applications by selecting "Application" as the shell from the options menu.
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
EDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.;D
o nohs!!! I lost the game :( ;DEDIT: On a completely unrelated note, I like the new filetype that can be attached to posts.;D
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.
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.
not() is bitwise complement. If you want logical not like in TI-Basic, you can just use =0.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
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?
Just saw you changed your progress change to 70%. Good job.somewhere near zero: look at this post (http://ourl.ca/4057/110229)
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( ?
I really am seeing forward to the next release! good luck!
Me too! but there are so many other things I am looking forward to, I can't mention averything in just one post :P
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!
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))
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...
Feature Request: Double buffer.
Code: DisplayGraph rrr
description. It will display both buffers but as black not as black and gray.
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.
Feature Request: Double buffer.
Code: DisplayGraphrrr
description. It will display both buffers but as black not as black and gray.
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
I thought DispGraphrrr could be more for 8 level grayscale? ??? (L1, L3 and L6)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'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?
And objects, or course ;)
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.
I actually love OOP, but it's not for Axe. Maybe another language altogether.
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.
And objects, or course ;)
Hopefully not. I don't like OOP.
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.
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.
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).
I actually love OOP, but it's not for Axe. Maybe another language altogether.
And objects, or course ;)
Hopefully not. I don't like OOP.
There are languages that can be OOP, but not fully OOP, like Python.
:Zeros(54)->Str1V
:#Realloc(Str1V)
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.
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
If A=5
→B
.Do stuff
Else
.Do stuff
End
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
:A+1->A
:If A=10
:->A
:End
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
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
Disp "Hello"
. THIS IS A COMMENT
Disp "This is not a com."
. THIS IS A NEW COMMENT
...
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."
Instead of ..., why not have it have an opening and closing comment character. That way, you don't get confused too.
/.
comment
./
how about that?
edit: nevermind that's not really accessible on calc..
.< and .> would be cool.Good idea! It would be very sufficient indeed to have multi line comments. :w00t:
I'm glad I did some Axe today, otherwise I wouldn't have reminded of this possible new feature ;)
ow! how stupid am I today! perhaps I'm working too much for the contest, and sleeping too little :(this feature request has been somehow forgotten, but my wish hasn't changed...
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"
but the idea of Function is that this could be done:
Return
Lbl SUB
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
ReturnCode: (Axe++) [Select]Text(1,2,"HELLOL")r
this is some kind of Axiom thing, but than in Axe itself, right?
Return
Function Text(3)r
Exch(L3,L6,768)
Text(r1,r2,r3)
Exch(L3,L6,768)
Return
could this be added in Axe++?
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.
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'
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...
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. :)
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().
: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?
Speaking of optimizing control structures, any chance for Do...While loops?
Speaking of optimizing control structures, any chance for Do...While loops?
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.
While...End loop | Do...While loop | |
Code: [Select] ;While | Code: [Select] ;Do |
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.
6.15MHz and 15.4MHz (which is about how fast my TI-84+SE runs I believe).
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.
I'd like to request de-referencing routines, so I could dereference a label, or (even better) dereference something like DispGraph.
Could there be a 2nd line routine for those who absolutely want clipped ones? Or maybe someone could write an Axiom.
new "EndIf" and "End!If" instructions
@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...
Code: (Current routine) [Select] Start: | Code: (Interrupt-friendly routine) [Select] Start: |
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.
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
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
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?
You just use it like that :)
It will restore the contrast to what it was at the beginning of the program.
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
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 :)
:Asm(ED734B8C)
:Asm(ED7B4B8C)
:Return
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
And I couldn't figure out how to delete the poll... so I just decided to make a goofy question instead :P^.^
Switch(X)
Case 1
1->Y
Case 2
3->Z
Case 5
X-Z->Y
Case Else
Sin(Cos(Sin(Cos(X))))->Y
End
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
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.
Oh yeah, I was planning on adding that functionality. I'll see if I can get it working.
Axe Parser 1.0.0
[=========-] 90%
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?.
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
If getKey(54) and getKey(1)
. CODE
End
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
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. ;DAs do I. I LOVE SWITCH STATEMENTS
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 ;)
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 ;)
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.
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).You mean if QUigibo implements switch statements the source would be easier to read than this but the executable would be less optimized?Code: [Select]rand^9+1
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.
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
!If -1
Do stuff
Return
End
and so forth...
If A=1
Bla
End
If A=2
Bla
End
...
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
Quigibo, if you are implementing Switch statements, can you include support for Strings?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.
In computers, no programming language has switchs with strings, and I'd love them ;D
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
While we're at it.. I also suggest adding optimized string comparison functions :)
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 ?
GetCalc(Str1, 768) -> {L1+700}r
...code...
Pt-Off(2,5,Pic1)->{L1+700}r
Copy(L6, {L1+700}r, 768
becomes this:#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?
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)
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)
First that the Axe-specific entries in the catalog are implemented in the alphabetical order, so that tey're more easy to find.
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.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.
Sounds awesome! I can't wait for switches. ;D
I second the request for the #define command. :)
Defines stuff. No, seriously, it just defines stuff as existing. It's a strange command, to me. It has some interesting uses, though.Sounds awesome! I can't wait for switches. ;D
I second the request for the #define command. :)
What would it do?
Like if you didn't want to remember a number like E848E, you could #define a name for it.
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
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
Syntax like Pt-Change(Line(5,5,20,5))r or something.
That is pretty complex tho...
Edit: That may be "Vertical -". I'm not sure which is which anymore. :P
Nah, as it's easy enough to implement yourself...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.
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
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 implementDrawing to an arbitrary buffer would be really useful IMO.Pixel testing an arbitrary buffer would also be fantastic.
Drawing to an arbitrary buffer would be really useful IMO.Pixel testing an arbitrary buffer would also be fantastic.
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.
It would also be able to read/write to bits instead of just bytes and nibbles.
I believe the cross-like graphscreen cursor is a bitmap.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
It would also be able to read/write to bits instead of just bytes and nibbles.
Bit flipping sounds like a useful feature too. Might be slow, though.
Whoops, I just noticed I replied to ralphdspam on a different page... :D
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.
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?
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?
Itwould 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.
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:179->A
For(B,0,7)
If bit{A*8+B}
.Do Stuff
End
End
Code: [Select]179->A
For(B,0,7)
If bit{A*8+B}
.Do Stuff
End
End
{POINTER}→A
For(B,0,7)
If AeB
.Do Stuff
End
End
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
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.
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.
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.
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?
Doesn't the returned string have size bytes just like any other variable? It's just a temporary string variable.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.
Something that would be nice: run indicator going while it's in the process of "Writing APP..."^^ 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)
Occasionally it seems frozen :P
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.
Request: fixed input command (it sometimes adds extra bytes)What do you mean, "adds extra bytes"?
Request: fixed input command (it sometimes adds extra bytes)
:input→P
:{P-2}r
I have another cool feature request - you don't have to do this if you don't want to.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.
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).
I have another cool feature request - you don't have to do this if you don't want to.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.
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).
:"prgrmBLAH"->Str0
:.NORMAL
:GetCalc(Str0)->A
:.POINTER TO VAT
:GetCalc(Str0)r->A
That r is the angle menu r
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.)
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:
Nested libraries would be nice.Nested libraries? ???
EDIT: Also, because I'm sure I'm not the only one wondering about this, I'll go ahead and ask it: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).Nested libraries would be nice.Nested libraries? ???
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:
For(I,0,767
0→{L3+I}→{L6+I}
End
p_ClearBothBuffers:
ld hl,plotSScreen
ld de,appBackUpScreen
ld bc,768
xor a
__ClearBothBuffersLoop:
ld (hl),a
ldi
jp pe,__ClearBothBuffersLoop
ret
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)
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?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.
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.isn't that the same as Buffer->(l3 or L6 not sure) then display graph?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.
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)Mine's an 'M' and it doesn't have the greyscale or linking problems. ;)
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)
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(.
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'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(.
No, BUFFER->DispGraph doesn't work anymore. Speaking of which:
BUFFER->DispGraph
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.
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?
ClrDrawrr to clear both buffers.
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.
Nested libraries would be nice.
An GetCalc() that returns a pointer to the VAT entry of it.
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.
Normally Axe will save changes, but if you get a compile error and scroll to with prgm, it won't save any setting changes.
run indicator going while it's in the process of "Writing APP..."
Also, lowercase letters usable in static pointers GDB, Str, and Pic would really help
It would also be nice to be able to back up programs even if they are archived :)
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
or Fix 068 could work.
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.
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
becomes this:
...code...
Pt-Off(2,5,Pic1)->{L1+700}r
Copy(L6, {L1+700}r, 768Code: [Select]#Define(BUF,L1+700
ASM programmers can do this, so why can't we?
GetCalc(Str1, 768) -> BUF
...code...
Pt-Off(2,5,Pic1)->BUF
Copy(L6,BUF,768)
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.
Oops, I thought it did AND. Well, you learn something new every day.
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?
woot, I got quoted! Nicely done, DeepThought.
Very.woot, I got quoted! Nicely done, DeepThought.Quoted again. Happy?
Nothing does AND right now, Pt-On does OR ;)* ZTrumpet stabs ZTrumpet. :-[
Ecstatic?Very.woot, I got quoted! Nicely done, DeepThought.Quoted again. Happy?
Of course, now that Ztrumpet quoted me too. :thumbsup:Ecstatic?Very.woot, I got quoted! Nicely done, DeepThought.Quoted again. Happy?
Axe puts its own routines after the data, so things still get run at the very end.
Nothing does AND right now, Pt-On does OR ;)
when would you need it?
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:
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.
is there also a way to use just B_CALL _getKey so that you can detect key combos (I mean, like with 2nd-> Math)
: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.
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
Asm(EF724926006F)
Yes, I know. I dont know how to read register A with Axe, though...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) isCode: (Axe) [Select]Asm(EF724926006F)
It involves a whole other key system though.
Copy(FlipV(Pic1),Pic2,8)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).
Copy(RotC(Pic2),Pic3,8)
Of course, Pic2 and Pic3 have to be defined and 8 bytes large
And Try/Catch
Yes, I know. I dont know how to read register A with Axe, though...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) isCode: (Axe) [Select]Asm(EF724926006F)
It involves a whole other key system though.
It would be that slow? Aww, man!
Oh. Now if only we had multiple processors....
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
:(0-255) -> {L6+(0-767)}
:dispgraph
A way to manipulate individual bits.
And Try/Catch
You can't just make a processor suddenly divide into two or something.
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.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...
Freyaday, there is no processor command to manipulate individual bits. You have to do it with logical operations.
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?
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)
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.
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).
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.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
Ld HL,adress
SET/RES #,(HL)
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.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
Ld HL,adress
SET/RES #,(HL)
Oh i wasn't aware Ld HL, address was 3 bytes D: hah thats why I'm not an asm programmer :P
Change the way the >Char command works so that Output(0,0,[7C5C2F7C5C2F7C3ECC12]>Char
Prints
|\/|\/|><[
instead of a dieresis.
Circle()rCirclerr? What would that do?
And while I'm at it, Circle()rr
paint bucket.
FloodFill(X,Y) //X and Y are the coordinates of the pixel to start filling from
Only two arguments are necessary, because it would always invert the color. Floodfilling the current color on top of itself would do nothing.
Rect(X,Y,W,H)
RectI(X+1,Y+1,W-2,H-2)
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. ;)
I had forgotten about Exch(. This certainly makes my programs smaller.What about a buffer swap command instead of implementing bunch of <command>r's?You could just use Exch(L3,L6,768) for this. ;)
... And did someone really ask for multitasking?
{L1+5}→{L3+2}
should parse as:ld hl,saveScreen+5
sto hl,appBackupScreen+2
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
Doesn\'t it already do that? It also precalculates things like +L1-8 by adding (L1-8) together.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.
If it doesn\'t do this in the new version, it\'s a bug.
Perhaps a command to check a certain block of memory for variable bytes.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)
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
inData can only check for one byte. Im thinking of a function that can search for more than one.Something like
but i do see how that would work.
Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
(returns -1 if failure)
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.
inData can only check for one byte. Im thinking of a function that can search for more than one.Something like
but i do see how that would work.Code: [Select]Lbl SRC
(returns -1 if failure)
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
I think the string equality check command could be used to compare multiple bytes.
inData can only check for one byte. Im thinking of a function that can search for more than one.Something like
but i do see how that would work.Code: [Select]Lbl SRC
(returns -1 if failure)
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return
Calc, where do the variables here come from? Which is the search string and which is the string to search? I may use this.
SirC's flood-filler would probably be easily modifiable to make grayscale.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.
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 :)
It's much easier to just draw two sprites in axe than to write a new set of wrapping sprite display routines in ASM.
A->T B->A T->B
Here is the same code using the stack instead.A->π B->A π->B
Since 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.{A*3}->X {A*3+1}->Y {A*3+2}->Z
Here is a case where you can nest them together:{A*3->π->π}->X {π+1}->Y {π+2}->Z
This saves a HUGE amount of memory.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
^ 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->B
Here is the same code using the stack instead.Code: [Select]A->π B->A π->B
Since 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}->Z
Here is a case where you can nest them together:Code: [Select]{A*3->π->π}->X {π+1}->Y {π+2}->Z
This 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.
Too many consecutive pushes without pops will cause an overflow, even if the pops occur later onIt 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"
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). :)
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.
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.
{A*3->π->π}->X {π+1}->Y {π+2}->Z
Could even be optimized to:{A*3->π}->X {π+1->π}->Y {π+1}->Z
But yeah, you did need an example of nested pushes/pops anyway.
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.
Lbl SR
.CODE
Return
Lbl CP
.CODE
Goto E
Return
.Code
Lbl E
A way to Exit the program from within a subroutine, because both Return and goto end-of-program just end the subroutine.
OS return location
Stuff
...
Subroutine return location
Possibly more subroutine return locations
...
OS return location
Stuff
...
.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
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?
What about Basic's Stop? How does that work?
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.
Ah, gotcha. It makes sense now. :D Thanks! ;DI'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?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.
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.
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 withA 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.
pop hl
ld (returnAddress), hl
and then quit withld 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.Lbl EXT
π -> A
Return
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.
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
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.
Asm(2ADE86 2B 2B F9 C9)
You don't need to place any special code at the start of the program.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?
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:
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.
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.
sub(R)
Lbl R
X-3^27
Return
Is there any way you can add VAR++?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. :)
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 think he is just asking for the A++ syntax for style, just so it looks more like traditional programming languagesAh, okay. :)
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.
ld hl,axv_A
inc (hl)
ld hl,(axv_B)
ld de,axr_L1
add hl,de
dec (hl)
cp 255
call z,VarPlus
VarPlus:
ld a,(VarA)
inc a
But you can just doI 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).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).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.
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:Maybe the ++ and -- operators should work without the memory read brackets, which would simplify parsing and emphasize that the pointer is what is returned.
- 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.
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?
Fix 3
Fix 1
Text(0,0,"HELLO WORLD
Fix 0
Fix 2
Fix 3,1
Text(0,0,"HELLO WORLD
Fix 0,2
That would be awesome!
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.
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.
It's called syntactic sugar.
For loops, Repeats, and Whiles are all syntactic sugar, too.
@Runer: I totally agree, I don't understand how the first option won.
I have a new feature suggestion!
Multiple fixes in one line:
Maybe the ++ and -- operators should work without the memory read brackets, which would simplify parsing and emphasize that the pointer is what is returned.
16 bit bitwise operations.
If (X=0 And (Y>5)) Or (Y=16)
If ((1) And (0)) Or (1)
If A=/=0 and (B=/=0
You 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.If X=0 and (Y>5) or (Y=16)
(You don't need the parentheses around the arguments to " and ")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.
getkey(key1,key2...)What if more than one is pressed?
This would check all of the keys with the corresponding getkey numbers and return the getkey number of the one that was pressed.
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.
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.
calc84manic: It would return the first value in the listThis should work in theory:
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()
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
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.
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.
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.
:D That is great, thanks. Does that optimize the program or just the source size?
.db $C0,$DE ;Header bytes reversed so old Axe applications won't accept the Axiom
.db Axiom_version
;Possibly additional header data
!If A-1
sub(FOO)
End
to this:sub(FOO)!If A-1
Here's a request that shouldn't be hard to implement: adding If conditionals to sub and Goto.
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.
⁻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.
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
I suggested that awhile ago and got shot down hard. =/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.
Why shouldn't Axe be the first, then?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?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.
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.
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().
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.
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?
randInt
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₁
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 :)
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.
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)
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.
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!
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 '('.
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.
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.
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?
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.
DrawInv
Line(x1,y1,x2,y2)
DrawInv
A workaround: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.
Invert the screen, use Line(), then invert the screen again?Code: [Select]DrawInv
Line(x1,y1,x2,y2)
DrawInv
{E86D7}r->X should do Text->XAre those BCALLS, or are they memory locations?
{E86D7}->X and {E86D8}->Y should do Text->X,Y
9000→X
X+9000→X
If X>9000
Disp "Its over 9000!"
End
could be #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.Memory locations.{E86D7}r->X should do Text->XAre those BCALLS, or are they memory locations?
{E86D7}->X and {E86D8}->Y should do Text->X,Y
Oh, and I have a feature request that I think we would all love: Defining tokens as constants. Simply put,I second the request. It's a great idea. :)Code: [Select]9000→X
could be
X+9000→X
If X>9000
Disp "Its over 9000!"
EndCode: [Select]#Define(Xmin, 9000)
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.
Xmin→X
X+Xmin→X
If X>Xmin
Disp "Its over 9000!"
End
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 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).
[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.
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 :-\
Question:Axe will add the parenthesis for you at the end of the line. So if you had:
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?
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.
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.
ERR: BLOCK Either an “End” is missing you you have too many “End”s.
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).QuoteERR: 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?QuoteERR: 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?
Code: (Uses nested conditionals) [Select] If -1 | | Code: (Doesn't use nested conditionals) [Select] If -1 |
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
not(getkey(5))
activates when no key is pressednot(getkey(5)) and (getkey(0))
will not activate when 5 is pressed, even when there are other keys being pressed at the same time
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.
getKey(47) and not(getKey(48) and getKey(40) and getKey(39))
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.
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.Like this? http://ourl.ca/7652 :D
In case you're wondering, I made a program for the explicit purpose of investigating this bug
Why must everything be an Axiom?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.
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. ;)
What about an additional Backup option that enables backing up all used subprograms as well?
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.
I have a feature request.Don't touch the certificate. You'll thank me later. Might as well just have an optional app signer instead.
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 have a feature request.Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
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.
Auto indenting
I have a feature request.I got a good chuckle at this. In all seriousness though this is probably going be more trouble than it's worth.
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.
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.
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.
You can't properly sign it on-calc if you don't modify the certificate.I have a feature request.Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
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.
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.You can't properly sign it on-calc if you don't modify the certificate.I have a feature request.Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
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.
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?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.You can't properly sign it on-calc if you don't modify the certificate.I have a feature request.Yeah, don't touch that certificate. It would be far better to sign the app on-calc, if possible.
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.
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.
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
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.
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
That's already been around since I first added the EndIf, you can always use them in for loops ;)
Oh, speaking of Subroutines, a way to end the program from within a subroutine.
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E
!If GetCalc(iAPV,4096)→M
Disp Str0E
getKeyʳ
Return
End
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E
L₂→iMAP
!If GetCalc(iAPV,4096)→varMAP
Disp Str0E
getKeyʳ
Return
End
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. :)
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.
EDIT: Also, if I use the extra page, I could conceivably do the entire thing in one pass O.O
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.OHow is that possible? Won't you need to have a 2nd pass to insert any previously unknown values?
Super bonus 1.0.0 feature? ;DDoooo it! ;D
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.And fast.
EDIT: Which would be awesome.
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
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.WinWInWInWInWInINWINWINIWNINWINIWNINWINWINIWNIWNINWINWINWINWINWINIWNIWNINWINOInhfzaruiognbvlasgbjlhuihnuiwehn!!!!AAAAAHAHAHAHHAHAHHAHAHAAHAHAHAHHAHAHAHHAHAHAHHAHAHAHHAAAAAQA!/me got too excited
Get excited. >:D
Pt-On(expression→r₁,expression→r₂,expression→r₃)
Pt-On(r₁,r₂,r₃)ʳ
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
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.
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.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. :)
Get excited. >:D
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.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.
A bug: using the on+enter shortcut to compile disables the auto-backup feature, becauseAlso having to do with the backup feature, a fix for ^ ;)Quote from: thepenguin77 on IRC[18:27:38] <thepenguin77> [...] when compiling from the API entry point, the option is changedAfaik, this would need the entry point to be modified to have another input...
In other words, E8000:Asm(9E) jumps to $8000.Oh, andThat can be done using a simple Asm(E9), which will jump to the address of the last result
- Allowing jumping to an arbitrary place in memory
You can do that with Asm(9E):Look closer, it's actually E9. 9E is the SBC A,(HL) instruction.In other words, E8000:Asm(9E) jumps to $8000.Oh, andThat can be done using a simple Asm(E9), which will jump to the address of the last result
- Allowing jumping to an arbitrary place in memory
E9, as calc84maniac said.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.
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.
I was wondering...the ability to use ! just before a var or whatever to check if it's false. ie instead of having to doIt's already optimized, but not as much as if you did
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?
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
:If A
:If B
:...
:Code here
:...
:End
:End
instead of:If A and B
:...
:Code here
:...
:End
Can you add a For() loop that counts down? (Like a 16 bit djnz) Maybe For()r ? That would be very useful. :)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.
EDIT: I know there is DS<(), but that is a little bit different.
Can you add a For() loop that counts down? (Like a 16 bit djnz) Maybe For()r ? That would be very useful. :)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.
EDIT: I know there is DS<(), but that is a little bit different.
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.Can you add a For() loop that counts down? (Like a 16 bit djnz) Maybe For()r ? That would be very useful. :)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.
EDIT: I know there is DS<(), but that is a little bit different.
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?
.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...
Abs([num_of_Loops+1])
While -1 -> [var]
.Code
[var]
End
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.
What are inline if statements?
EndIf A>4
What are inline if statements?An inline if statement returns one of two values depending on whether a condition is true or not.
"True"->Str1
"False"->Str2
Disp IIf(A=B,Str1,Str2)
"True"->Str1
"False"->Str2
Disp ((A=B)->C*(°Str1)+(not(C)*(°Str2)))
.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)
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
"ABC"[1C]""→Str1
You can add hex in strings?
"ABC"[1C00]→Str1
"123"[40]"456"
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
StructDef Kitty
1
2
8
End
Disp Struct(A,Kitty,2) .disp string stored in element two of structure A
Thanx!
Where to find a list of the hexadecimal character codes?
lambda(Pt-on(r1,r2,r3):Pt-on(r1,r2+8,r3+8)) -> A
lambda(Pt-on(r1,r2,r3):
Pt-on(r1,r2+8,r3+8)) ->A
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 :)
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.
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.
Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
∟LBL
...whereas the syntax for returning the address of a variable is... °VAR
...which seems kind of inconsistent to me.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.
Axe 1.0.0 supports named variables ^^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) :/
Zeros(128)→°Map
Lbl Map
Never does for me. Even if there's an existing one in archive it overwrites it with a program in RAM.Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
Yeah, Axe only compiles to RAM. It can, however, read source from archive.Never does for me. Even if there's an existing one in archive it overwrites it with a program in RAM.Yeah, with about 5 subprograms, each from ~2kb to ~6kb, it's nice to keep them archived.Actually, if the program you're compiling to exists in Archive, Axe will compile it to archive.
(esp as the executable gets in the 20000s, constant "ERR:OUT OF MEM" things :P)
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.
make Axe compatable with gCn 1.0
make Axe compatable with gCn 1.0
That's a job for an axiom.
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
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
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.
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.
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
Hi!Heya welcome to the forums. I hope you enjoy your stay (and calc programming) :)
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
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.
Also, in response to this:#If would be awesome. I'd love to be able to use it; it'd make so many things so much simpler.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.
.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
# - Hash
! - Bang
* - Splat
/ - Whack
The #If and #End would be super easy to code, but what would be good symbols for those to replace?
I like your first option a lot better; I think Else, ElseIf, and End should have hashes in front of them.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.
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:I love those terms :D Oddly appropriate too.Code: [Select]# - Hash
! - Bang
* - Splat
/ - Whack
Also, octothorpe? Haven't heard that used.Lol I don't think that's the one usually used, especially in coding.
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.
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).
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.
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.
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?
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.
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!
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)?
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.
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.
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.
Ah, I see. Yeah, that's confusing, though :/
0-127 is no more confusing than -32768-32767 or 0-65535.
It wasn't to make it less confusing, it was for convenience. It can be really annoying to convert decimal to EXXXX format manually.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.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)
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. ;)
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.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. ???
I've wanted this feature for a while: ability to insert constant values into Asm() code.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.
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)
Yeah, or maybe [] so it doesn't imply a memory readI've wanted this feature for a while: ability to insert constant values into Asm() code.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.
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)
:.TEST
:#Realloc(<Pointer>)
:prgmUTIL
:<more code>
:Return
Inside prgmUTIL
:.UTILS
:#Realloc(<Different pointer>)ʳ
:<more code>
:Return
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:
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.
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.xYeah 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.
What would GetSprite return?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.
Also, what's getPixel again?
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
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)
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.
I think noone will be angry if it will backup before - You can tell axe if it should backup or not.THen, if it crashes due to some bug, you still have the nonbuggy version backed up.
What's better if it'll backup after??
Freyaday, yes, that would be great.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.
But it should always backup BEFORE compiling
(sometimes it freezes while compiling apps!)
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!!!
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:And another thing is, that it should be possible to add a new line in a codeI've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting?
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
:"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
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).
:If A
:Stuff
:End
to be written as:A?Stuff
.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:
.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
!= //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)
Logical not is =0.Ah yes.
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)
:circle(5,5,3)
:StorePic
but it still didn't do greyscale. it just stayed the same.
.CIRCLE A Gray Circle
ClrDraw
Circle(5,5,3)
StorePic
ClrDraw
DispGraph{r}
Repeat getkey(15)
End
Idea: Only display/update a square/rectangle part of the screen.
It would make for insanely easy smooth scrolling games.
wait, is that the superscript r, or am i doing something wrong?Code: [Select]DispGraph{r}
It wouldn't. It would help all games.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?
wait, is that the superscript r, or am i doing something wrong?Code: [Select]DispGraph{r}
I did : {r} (open curly brace, superscript r, closed curly brace)
but I get an "error: invalid token"
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.
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?
Hmmm how would updating only part of the screen make smoothscrolling faster?
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?
Really... wow BB. why didn't you just say that first.....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.
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.
Shut up! I am going to make a music tracker. Don't have any more ideas!!!
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.
Would it actually be possible to make midi instruments? If not, I suggest at least having sine, triangle, and square as options.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.
I am on a serious page starting streak.
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 AroundEither way, I'm sure many Axe programmers would be very happy to see line clipping implemented./me raises his hand and nods approvingly
^^^ Good idea!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.
And what is line clipping?
request: Rect(X,Y,#, -#)We must not let that suggestion die!
: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
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)
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.
Multiple notes at the same time!
:A+1→B
can be broken into: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:r1*2+(r2*2)
:Return
and sub(STUFF,1,2)→A would work.
Code: [Select]:r1*2+(r2*2)
:Return
:Return r1*2+(r2*2)
is valid code as well, and will act the same as the above code.
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
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 :)
how about making an option to display the final size of the program after compilation?Good idea, and I think it is doable as it is done for Apps :)
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.
I was going to make the same exact request, with the same suggestion for syntax. O.O
- 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 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.
For(I,0,255)
sin(I)//13+20->Y
cos(I)//13+20->X
Pxl-On(X,Y)
End
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
Freq(WAVE,OFFSET,TIMEWould this even be possible? Is it easy to implement this in the existing freq( routine?
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!
What are the arbitary buffers?Custom buffers defined by the programmer
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:
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 valueare bit commands planned? if not I want to request. (since that will give a HUGE size optimization)
Since which version?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.
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 ?
D: epic failBut 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
Don't forget the 'e' operator. It accesses the Nth bit of a number. Its been around for a long time now...Syntax?
Don't forget the 'e' operator. It accesses the Nth bit of a number. Its been around for a long time now...Syntax?
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 ;)White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.Use drawinv ... drawinv for that
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]->GDB1ooh that would be an AWESOME thing to have... :D
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
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 appvarsthe 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.
I'm just curious, but does axe already have a function to absorb TI-OS Strings?No.
ah. I just had a time when I pressed zoom, it didn't work. D:Or maybe you have a version without ZOOM?
Maybe I pressed it at the wrong time or something.
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?)...
Lol @ the port to 86 :PYES PLEASE!
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.
That would be pretty cool. Would it be based towards making simple comp games?Lol @ the port to 86 :PYES PLEASE!
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.
D:Actually, that would be pretty cool. ;) Not really a feature request so much as an independent project though. :P
It was too much, I guess XPwell, then... feature request: port it to TI-86
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!!!!
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)
Multiply by 2 and it's 8.8 :PMultiply what by two?
Perhaps text()rr could print to L6 and then copy the printed portion to L3That 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).
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.Multiply by 2 and it's 8.8 :PMultiply what by two?
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)
how does doors cs 7.1 do it? That works very well and jumps instantly to the error.
<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
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)
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?
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.
:...If <const>
:<code>
:...
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?
{3,2,4,1}->L1
{4,3,2,1}->L2
SortD(L1,L2)
Then L1 and L2 would equal:L1 = {4,3,2,1}
L2 = {2,4,3,1}
:r₁∗r₃+(r₂∗^r₃)➔r₁:r₂∗r₃➔r₂
: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.: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₁?
A*^B-5+9/42-{L1+B}->C
The number is stored it a "safe" place until it is recalled ;)
It doesn't even have to ever be used.
4^*B+2->(r1,r2)
@HappybobjrWon'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?
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.
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.
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.
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)
an expandable table of fixed size objects that only needs iterative access?
idk if it's possible or not, but can you add a "hittest" for object-object(sprites)?
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?
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 1Can 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
Maybe auto-backup for libraries.And includes
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.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 1Can 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
What about support for the crystal timers?Sounds like an excellent candidate for an Axiom ^^
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?
well that's relatively easy to write a subroutine yourself, just Logically OR every byte of the sprite with 255.
Sprite: | Screen: | Result: |
0 | 0 | 0 |
0 | 1 | 0 |
1 | 0 | 0 |
1 | 1 | 1 |
Sprite: | Screen: | Result: |
0 | 0 | 1 |
0 | 1 | 0 |
1 | 0 | 0 |
1 | 1 | 0 |
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.
Oh here's something I've always really wanted - a RectOff command.That's what I asked for with RectW()
(Yes that sounds kinda weird)
RectOff or RectW would make a white rectangle ? You just need to doYeah, 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.
Rect(A,B,C,D)
RectI(A,B,C,D)
and you obtain a white rectangle :)
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.
not possible oncalc D: Due to RAM limits??? This has nothing to do with Ram limit since Apps are run from Archive.
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.
Maybe the RAM limit would be a problem during compilation?not possible oncalc D: Due to RAM limits??? This has nothing to do with Ram limit since Apps are run from Archive.
Yeah, I didn't think about that one D:Maybe the RAM limit would be a problem during compilation?not possible oncalc D: Due to RAM limits??? This has nothing to do with Ram limit since Apps are run from Archive.
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! :)
A version of ClrDraw that fills the screen with black instead of white. For making White-on-black games. :)
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) ?
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
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
...
kind of like 3dahh thanks. That would be really cool :D
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.
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.
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.
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 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.
- 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".
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. ;)
I actually do not know if this exists in Axe, but in BASIC, "" turns off a line. Notice the zero.A slow way to do this is
This would be most helpful in my newest creation, Dodge2.
well, that is a inverted line, not a 'turn off a line'. ;)I actually do not know if this exists in Axe, but in BASIC, "" turns off a line. Notice the zero.A slow way to do this is
This would be most helpful in my newest creation, Dodge2.
DrawInv
Line(X1,Y1,X2,Y2)
DrawInv
But it is quite slow :(
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.
Request: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.
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
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.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
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.
Reading from appvars from an app would just use nib{} like usual, no?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.
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 :)
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..
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
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
Line clipping support!This is going to be coming in an Axiom that is under development.
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.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.
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.
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.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.
#Icon(HEX)=>Pic1
...
Copy(Pic1,L1,64)
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.That sounds right to me.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.
ability to line jump?
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. :-\
The bar itself shouldn't make that big of a difference, it's probably something in the compiler itself.Request: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.
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
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.I wouldn't remove the Zoom option. It's useful for checking to see if the bug was caused by the peephole ops.
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.
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.I wouldn't remove the Zoom option. It's useful for checking to see if the bug was caused by the peephole ops.
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.
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.
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 :PNow that you mention it, yeah. GAH compatibility. :P
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
I like that!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.
;expr1 evaluate here
push hl
;expr2 evaluate here
pop de
or a
sbc hl,de
;expr evaluate here
ex de,hl
ld hl,(axv_A)
or a
sbc hl,de
ex de,hl
ld hl,96
or a
sbc hl,de
:Save A,B,C
:
:End
would save A, B, and C and restore their values at the End.: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.Why not adding in the Commands.html the size of each routine and the size of each routine call ? :D
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" ?
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.
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 ?
Apps are fixed at 16384 bytes unfortunately :/Except if multiple page apps are supported :D
How about a larger app max compile sizeAs Darl181 said, if your program still fits in the RAM, you can use CrabCake and Fullrene.
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
in the meantime you can simply keep all your data external and try to work around a 16 KB limit for codeThis 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 :(
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 -.-°
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.in the meantime you can simply keep all your data external and try to work around a 16 KB limit for codeThis 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.*.*
#ifdef and #!ifdef
.db label
Because the only way to put a byte at a precise location is Asm(byte), and this syntax doesn't support Llabel.
Feature request: Somehow make it able to use more than 2 byte variables :DThere 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
add, subtract(, multiply, devide), display, compareSubstract and display are already present ;)
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.
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
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.
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.
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.
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!
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).
Maybe you could add to the list as feature request multi-pages app and as optimization suggestion lazy if-conditions
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!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.
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'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.
How about ++EXP? How many times has this been requested?
ok, thanks for the info!Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?
but I still think that it would be usefull to add.
ok, thanks for the info!Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?
but I still think that it would be usefull to add.
ok, thanks for the info!
but I still think that it would be usefull to add.
Alright. Cool.ok, thanks for the info!Perhaps add an option to enable/disable it in the menu, so we can use Archived-editing hooks if we want?
but I still think that it would be usefull to add.
If zStart exists on the calculator, that would still be used to edit the program from archive.
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)?
"First"->Str1
"Second":[00]
"Third":[00]
You know, for using the fancy strDev( function. Maybe"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"First"->Str1
"Second"[sup]r[/sup]
"Third"[sup]r[/sup]
where r simply adds a null character after a string.:"blah"→Str1
:"blah"[00]"blah"[00]"blah"[00]
.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.
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 )
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?
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.
Lbl Sign
Return!If
Return //32768*2+1
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?
I wonder what's the use of Z-addressing ...
I would love to have the multi page feature, since I'm working on a big project,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).
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?Did you sign your apps with RabbitSign before transferring them ?
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
I wonder what's the use of Z-addressing ...
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.
It would be nice if you could import a binary file as inline assembly. This would allow easier use of Mimas.
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}.
I'm too lazy for that and I want crazy freaking subroutineless speed. :PIt 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.
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.
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...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.
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..?
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...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.
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..?
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.
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.
-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.
-an on-calc bitmap creator; they are not worth the time to make manuallyI 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).
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 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!!!
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.
[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
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 :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.
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 :)
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 respectivelyHere are your For loops.
A prefix version of ++ and -- that returns the in/decremented value instead of the previous one.
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.
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.
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.
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.Using external data and DrDnar's excellent RunPRGM are the best solution for that IMO. ;)
so you can precompile everything, except the level design part and then only recompile that for faster testing.
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.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.
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.xwait, 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.Agreed, that way I don't need that few bytes prog on my calc to convert :P
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 ?
.Shell <whatever>
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 ?
I was hoping for something like on line 2 :Code: [Select].Shell <whatever>
Also what about the other features I suggested (build constants) ?
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. ;)
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.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.
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...
I think I've had a similar problem a while ago.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.
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.
Um, IDK if this has been asked in here yet, but will it gain color support?
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 ?
Do Axe Fusion support Axioms? Axiom based static libraries!
How about ... 84C integration?!that was already suggested many times and i think will be done :P
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?!
Hopefully it's out before Sam Heald starts working on his Zelda clone again. :PLol at that one. :P
How many releases are planned before 2.0?
I>1
or I>=2
, you can do 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.
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.
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.
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 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.
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 .
Menue( ("Title Tab 1","1:...",label,"2:...",label),("Title tab 2","1:...",label,"2:...",label)...
'-------------------v---------------------' '-------------------v---------------------'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
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.
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
Slight necropost: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.
Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?
Slight necropost:
Will Axe ever be updated? Or at least some more axioms be released, particularly for tilemapping, especially scrolling maps?
/me prods multi-page app support :P
Like when defining a static pointer you say on which page it is :P
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.
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).
This is already possible with Data(pi00101001,pi11010011)→GDB1Indeed, 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 :
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.
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
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 :PNo, 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.That's fine :) And thank you, Hayleia !
Welcome to Omnimaga Zemmargorp.
You can introduce yourself here if you didn't already :)
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...
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 ;)
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
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 ;)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 !
A lot of Axe programs use writeback for saving, they don't all use appvars.
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 :PWell, 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.
But it's true that for debugging purposes at least, having a "fast" menu command would be great :)
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.
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 !)
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.
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.
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.
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.
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 :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.
http://www.omnimaga.org/the-axe-parser-project/input-routine-done-!/ (http://www.omnimaga.org/the-axe-parser-project/input-routine-done-!/)
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.
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).
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 :
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).
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:
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.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.
EDIT: Alternatively, it may be possible to detect if the OS or a shell launched the program.
Maybe I (or you) can round up all the main shells (MirageOS, DoorsCS, CrunchyOS, Noshell, CalcUtil, and zStart) and test this.
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.
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...
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...
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...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).
And I've never used TI's flash debugger, but I suspect that Wabbitemu's debugging capabilities are as good or better.
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.
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.
Hence z80e which aims towards 100% accurate emulation. :PDat plug. z80e is nowhere near ready for general use though.
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.
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 ??? .
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.
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 :/
Varargs-like doesn't exist in Axe ? What about all the text commands ?
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
Great :D*Yes ! My very first +1 ! I love you !*
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).
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)
L5'
→°Var2B+2'
→°Var1B+1'
→°Var4B+4'
→°Var3B+3'
L5→°Var2B+2→°Var1B+1→°Var4B+4→°Var3B+3
L5+00→°Var2B
L5+02→°Var1B
L5+03→°Var4B
L5+07→°Var3B
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.
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 ? :oNope, 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*... ;DWell 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 ?
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 ?
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.
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 ?
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.
We could still find tricks like doubling the ! token means to include it once in the string.
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.
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 ?
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 ;)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.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.
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 ?
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.
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).
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.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.
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 Recall
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.
LD H, $00
LD A, L
AND $3C
LD L, A
If you're advanced enough of a developer that you want manual stack control, inline assembly provides that capability.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 ?
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 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).
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.
I'm afraid to imagine how hard it'll be...
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.
If the temporary variables are removed before and after the program's execution, then there's no problem.
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?
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.
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.
In short, achieving adding a lookahead ability would improve the parser a lot :P
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.
Exaclty ! Sorry, I didn't know it already existed... *Looking for it...* Oh, but it's quite recent !
Like Fullrr?
It's a pity...
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.
Ah... Nevertheless, for code readability, differentiation of types in the variable's name would be better.
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.
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 !
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).
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 fileAnd I need to retract a constant to every "[]→", so I don't feel like doing things likeSpoiler For Spoiler:
[]→°TEMP
°TEMP-°CST1→°CST2
for each of them :P
edit Alternatively, is there a way to "compile with .org 0" ?
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
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.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.
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.
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.
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.
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.
MIN
While -->VAR < MAX
.INSET CODE HERE
VAR+STEP
End
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.
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.
Oh I meant that DCS and Mirage erases the game graphics from the screen upon exiting.
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.
Can you make it so..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.
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,
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. :PCan you make it so..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.
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,
Are you sure this is DoorsCS, though? That is a known issue if you use os 2.53MPYea, 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. :PCan you make it so..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.
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,
You can make fun of me if you want, but i use 2.55MP ._. ;DAre you sure this is DoorsCS, though? That is a known issue if you use os 2.53MPYea, 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. :PCan you make it so..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.
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,
Still not as stable as OS 2.43 ;)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).
How large is the program that is deleting itself?
Okay, since you tackled the parser, I have this feature wish:I think @Runer112 thought of doing something like that, but hey, you have bean here longer then me so idk.
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
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.
+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.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.
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)
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.
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?
[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]
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]
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)
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.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.
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) ;)
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.
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.
The option to run the program right after compile whithout having to go back to the home screen would be nice.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.
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.
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.
Pause until something happens, like pause until the enter key is pressed.
Add a line per line debug function :DWhile that would be awesome, I don't think that would be very practical on calc.
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 ;)
Yes, but if the program is archived, this function don't work :-\
I currently use zStart, but itWhat version of it are you running? What are the stability issues you are facing? What version of TI-OS are you running?dosen'tisn't very stable :-\
Sorry, I have modified my post :-\I currently use zStart, but itdosen'tisn'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?I use zStart 1.3.013 : http://www.ticalc.org/archives/files/fileinfo/429/42907.html
And what version of TI-OS?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
I have a TI 84+ SE with OS 2.55MP2.55MP might be the source of the stability issues.
DoorsCS7 is installed.
I have a TI 84+ SE with OS 2.55MP2.55MP might be the source of the stability issues.
DoorsCS7 is installed.
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.