I'm not sure what you mean by the error appearing in a strange way. It seems fine to me. If you mean none of the progress bar and such have appeared yet, that's because the header of the program is parsed specially and before main parsing begins.
Yes, that's what I mean. Before finding these errors, I was not used with error messages without the progress bar and everything.
If the strange appearance is the same as the strange appearance I described before, that's expected. But I think I may have inadvertently reproduced the freeze you're experiencing. If my suspicion is correct, it's due to the fact that changing any Axe settings (anything in the options menu or the target compiled type) results in the Axe settings appvar needing to be modified and saved back to archive, which is done when Axe exits, whether to the homescreen or to an error in the program editor.
Ok, so the strange appearance is expected. And the bug is maybe due to the settings ? My settings are the following : "No shell", "Lowcase ON", and "Auto Backup".
I can reproduce this bug. I'll try to fix it, although Axe's comment/newline parsing has always been a bit wonky, so it may not be as easy as it would seem.
Yes, but this is not a major bug. I know how complicated it is to interpret a colon, because its behavior may vary : inside a string it's a character, inside a line it can be used between brackets, whereas newlines are always separators of instructions ! So I sympathize
Axe has tried to be friendly to BASIC coders used to newlines and store arrows closing/breaking out of any open parentheses, braces, or quotation marks. As a result of this, like in BASIC, you can't include a store arrow in a string, because it immediately ends the string and is parsed as a normal store arrow.
Excuse me, I made a mistake, I thought that the store arrow didn't close strings. But, unlike TI-Basic, the store arrow doesn't close the parentheses : "1→Y*2+(Y→Z", "Disp Z>Dec" writes 1.
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 :
bcall(_PopRealO1) bcall(_ChkFindSym) JR C, SaveError ;Not found ! XOR A CP B JR NZ, SaveError ;Archived ! LD HL, DE LD C, (HL) INC HL LD B, (HL) LD HL, $9D95 LDIR :SaveError RET
Currently, I'm trying to adapt Brandown's code for menus to use it like menus in TI-Basic. It works great (only with less than 8 options) but I can't get the highlighted option's index, I don't know which choice was chosen !
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 !
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.
Unless you know how to remedy my woes with input, in which case I'd love to include some more powerful default input commands that are mildly robust and programmer- and user-friendly.
Sorry to get your hopes up, but that's not the case ! However, if one day someone finds easily how to create custom menus, it would be interesting if somebody else could make an input function which accepts these custom menus while the user enter the data. (But there's a lot of conditions in this last sentence...)
I absolutely agree that Axe could use floating point support. But if I'm going to add it, I'm going to do it right. That means growing out of the everything-is-a-16-bit-integer system and providing actual types. So for now, ugly Axioms will have to suffice. But if and when Axe 2.0 comes out, this will be included.
In fact, it raises a big question : should Axe become closer to TI-Basic with floating point maths, or should it stay closer to assembly and 16/8 bits maths ? Both cases are interesting, it depends what kind of program people make. But for beginners, being forced to use 16-bit is a good thing, because otherwise they would keep using floating point maths where they could use 16-bits maths, it wouldn't be optimized, and Axe would become a sort of TI-Basic II.
If a program is in RAM when it is executed, it will simply be moved to $9D95, executed, and then moved back.So no matter how you execute a program, writeback should occur. In fact, the only problem should sometimes be preventing writeback rather than providing it.
No, without any shell, it's not the case ! Even if the program is stored in RAM ! Personnally, I use Noshell on my TI-83+ (OS 1.19), and I tried a little program "{GDB0}++:Disp {GDB0}>Dec,i", and the output is always the same ! But maybe, yeah, as a lot of people are using shells with the write-back option enabled, they face the opposite problem (which is easier to solve, by the way).
I'd love for this to exist as well. I just have absolutely no clue how the OS dialog/menu system works, so have been unable to try to add it myself. If you think you know enough about it to be able to contribute this feature, that would be awesome.
So do I ! I don't know anything about it neither (except I found two interesting documents in Brandown's calcstuff, and I should start trying to decrypt it), but if one day I succeed to understand how it works, I'll tell you.
Custom named variables were one of the biggest additions in Axe 1.0.0, and have as such been around for quite a while. Just as you use the °VAR syntax to retrieve the address of a variable, you use the addr→°VAR syntax to "store" a constant address of a variable so that VAR is then a variable that exists at the constant address addr.
Yes, sorry, just after posting my message I saw that it was possible to declare a variable anywhere using this syntax. But I never heard of it before ! Seems like nobody was informed, as I never saw a source using it.
If you use a smart shell that supports writeback, which is I guess the case for most people playing ASM games, you don't need to worry about making your program do that writeback itself A lot of Axe programs use writeback for saving, they don't all use appvars.
Yes, but the game should always be able to save the score, even for people who don't have a smart shell ! And a shell that automatically saves the program's changes can also save other data that has been modified and shouldn't be saved back !
I think the problem is not that it is complicated, but more that it is a good learning experience for beginners to make their own menus, and not a good experience for non beginners to have an ugly menu in their program when they can have an awesome wheel such as that in TinyCraft But it's true that for debugging purposes at least, having a "fast" menu command would be great
Well, it depends ! It would be very complicated to implement in Axe a way to add menus (using the OS's bcalls) like Brandown did in assembly : seriously, try his program (or see it working), it's amazing ! I agree with you, it's a good experience for beginners to learn how to make a menu, but it would be better to be able to make menus faster in little projects ! And personally, I like the TI default's menu style and his simple design. Obviously, for big games, nice menus are an important point.
And I forgot to talk about another feature I thought about. In some cases, it could be useful to have Axe's variables located in a specified data, to save/load default values easily with the "Copy(" command. I think the syntax "[X Y S ]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 !) EDIT : It is already possible, by doing "ADDR→°NAME".
Thanks, Runer112 ! So here's the complicated stuff I thought about...
First, you should add a command (and maybe associate it with the "Prompt" token) which inputs a number, because it's useful and a lot of people need this ! Probably use the "input" command, and then parse the returned string to convert it into a 2-byte number. You can make it able to convert the number into a float. For example, the command's syntax could be "Prompt A" to get a 2-byte number, and "Prompt float{A}" to get a float number located at the address pointed by A.
Talking about float numbers, here's another idea : it could be great to add the support in Axe of float numbers, by using the OS's bcalls. The tokens could be Axe's regular math tokens, with a dot just after, and the values would be located at the addresses pointed by the variables. For example, "A*.B->.C" would be compiled liked "Copy(A, OP1, 9):Copy(B, OP2, 9):bcall(FPMult):Copy(OP1, C, 9)". But maybe use the bcalls Mov9ToOP1/OP2 instead of Copy(VAR, OP1/OP2, 9).
I've discovered there's an Axiom that allows this kind of manipulation with the OS's float variables, but it would be better to have it the way I described it, without having to use the OS's variables. Because it leads to creating the variables if they do not exists, looking in the VAT for the variable's address, and lose time. It's better if we use adresses of free memory for temporary calculations (in safe RAM areas, for example) and it's even better because it doesn't modify the OS's variables, if the calculator's owners stored important data inside them. It makes me thinking that it would be great to have a way to allocate/deallocate memory to a program, like "GetCalc(" does, but without having to specify a variable name, only the size needed.
And, talking about memory, why not also add a way to save the program's self changes from $9D95 to the compiled program ? It can be usefull for people developping games, instead of using an appvar only for the two bytes of the best score !
And I kept the best for the end : to implement a "Menu(" function, by using the OS's DIALOG bcalls ! I know you probably already thought of it, and it may be very complicated, but it's an important and so useful command ! I saw an amazing use of these bcalls in Brandonw's calcstuff, in the compressed folder "ddemo.zip", described in "dialogNotes.txt"... But it would be great to have at least the equivalent of the TI-Basic "Menu(" command.
Erm, it is not finished yet so you'll probably be disappointed
No, it's really good ! I'm used to starting writing new programs and never finishing them (unfortunately !), and Robbox is a good game, even if it's not finished.
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 :
LD HL, $9341 LD B, 64 Loop: PUSH BC PUSH HL LD HL, -1 LD BC, 11 EX DE, HL POP HL LDIR INC HL POP BC DJNZ Loop
And this takes 21 bytes and 20k clock cycles. Whereas adding a new CHorizontal function already written in assembly allows it to be much more optimized. The example under takes only 11 bytes, and approximately 14k clock cycles, that is to say a quarter less !
Here are some errors I found by trying stupid things !
The first one is when you try to compile a program which has the same name as the source : you get an error, and pressing the [prgm] key will freeze the calculator during some seconds. I've also noticed that, when the compiled name takes more than 8 characters, the error "NAME LENGTH" appears in a strange way. And it would be great if, when compiling to a program instead of an application, the lowercase letters of the program name were converted into uppercase, instead of truncating the name.
Like the "NAME LENGTH" error described earlier, when compiling to a program instead of an application, if the name contains more than 8 characters and uses lowercase, the error "INVALID TOKEN" will appear in a strange way, and pressing the [prgm] key will make the calculator freezing during a few seconds. Here's the hex code corresponding to that error, as it appears on the calculator :
In addition to that, after compiling an empty source, when you try to execute the compiled program, you get a "SYNTAX" error, instead of displaying "Done". I know, it's because the compiled program is empty too, but it could at least contains $C9. And by the way, you get the same problem when compiling a source which contains only a "Return". But this isn't the case anymore if you add a label right after the Return ! That's a bit strange. In fact, to solve all this, Axe should automatically add $C9 at the end of the compiled program if there's none, without looking more than that at what's written in the source.
There are also some problems with the multiline comments... If you end the comment the line after you started it, Axe Parser doesn't detect the comment's end, and make the error "MUST END COMMENT". And if, instead of skipping lines inside a multiline comment, you use colons, you get the same error.
An other little bug for the road : trying to display a string ending with the [sto] arrow generates the "INVALID TOKEN" error.
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...
Show Posts
