Author Topic: Axe Parser (Read 553187 times)

DJ Omnimaga · « **Reply #1095 on:** August 08, 2010, 03:51:05 pm »

Quote from: Quigibo on August 08, 2010, 03:07:43 am

In case anyone is wondering what's been going on recently with the lack of the promised Axe update last week, the main reason is the time I've been spending to get the automatic backups working. I spent about 5 days writing a ton of extra code since the OS did not support the archiving of invisible programs. After all that testing I finally had it all ready to be uploaded and I sent it to my calculator to do some last minute testing. That's when it gave me an ERR: Undefined when trying to create a backup. It turns out the trick I was using was no longer possible on OS 2.4x and so that really set me back. The only way I saw I could get it done now was writing directly to the flash. So I wrote routines for that. Then I realized that not only do I have to write my own routine for that, I have to write my own symbol table searching, vat entry updater, and program creator routines since I can't use the OS's routines given that they no longer support the format. It just got too crazy and I finally gave up. So I now have to throw away about a weeks worth of code and start fresh.

The main reason I had to make the files invisible was to be 100% sure that important appvars do not get overwritten accidentally. But I've though of a simpler way to do that now by checking if a non-backup file of the same name exists first and then refuse to backup the file until you manually delete it, that way you won't accidentally erase it. But unfortunately, now backups will crowd the memory management list which I really didn't want, but I guess on the plus side you can erase the backups without having to go into the Axe app.

Anyway, the update should be ready now in less than 24 hours I hope. The backup feature, when it was working on the older OS, is like a night-and-day difference in how you program. I feel like I would never program without it now because its such a huge convenience. Its definitely a reason to upgrade if you have an older version. I fixed a lot of other little bugs too to make it more stable.

I'm gonna love this backup feature. Glad you figured out the problem. Sometimes those TI changes are annoying

. I still remember the whole TI-Boy SE saga. I can't wait for the update ^^

EDIT: By the way, for those who can access OmnomIRC, Netham45 logs from Wednesday has some talk about the above, as Quigibo held a small Axe discussion on IRC that night (although for odd reasons, there seemed to be an unusually low amount of people online that night for a wednesday...). He posted a screenshot, too, showing the backup option.

Quigibo · « **Reply #1096 on:** August 08, 2010, 09:55:34 pm »

I updated the doc to include more information about the backups and the new library header if you're curious about those.

I fixed my auto-backups now and much faster than I expected so I decided to use the extra time to see if I could easily implement the external library feature that everybody wants. And that also was surprisingly not too difficult, but the only catch is that you can't nest libraries because each nested library needs 19 bytes of ram and I don't have enough space to have a big array for that.

A cool thing about the libraries is that those of you who hate having to scroll through all that data at the beginning of your program now have a solution! You can create a separate file that contains nothing but your data in a separate file and then include it as a library as the first line of code in your main program. The libraries work as direct insertions so its as if the same data were inserted right at that spot. You can also keep these files archived so that you have even more free ram left to create the rest of your program.

There are a ton of other uses for this as well. If you want to make a universal library like a physics engine for example, you can make the first line of the library file a jump to the last line so that it can be inserted once anywhere in the code and then the client has access to all the subroutines included in the library file. Due to the expansion of available names in labels to 3 characters, you can be fairly sure that your label name isn't already taken with some clever prefixes.

And I didn't even start talking about the backups yet. They are very strait forward so you can probably figure them out without needing any tutorial. Selecting a backup restores it, pressing "del" deletes it, and pressing "B" on the source creates it. In the options, there is a new mode to do it automatically. That's about it, but its extremely useful. Anyway, enjoy!

DJ Omnimaga · « **Reply #1097 on:** August 08, 2010, 11:05:12 pm »

Wow I love the new features, especially include files. My data's going there for sure. Can they be archived like the rest of the source? Also does the total amount of memory the libraries and the root program takes have to be equal or higher to your total amount of RAM or can we compile larger stuff? Regardless, it is great, because scrolling through a lot of data can be annoying when debugging for a long while. It's also easier to find the data now.

Good job again Quigibo!

Raylin · « **Reply #1098 on:** August 08, 2010, 11:13:51 pm »

^This.

EDIT: Tutorial on the EXP1eEXP2 command please?

EDIT 2: Can you put your subroutines in a library too?

_player1537 · « **Reply #1099 on:** August 09, 2010, 12:54:20 am »

@raylin, if you happen to know assembly, this would be ~equivilant to:

Code: [Select]

bit bit#,A
Basically, say that you have 0000100b stored in A. Then you do: "Ae5". This would return 1, "Ae6" or "Ae4" would both return 0. (did I explain it correctly quigibo?)

Quigibo · « **Reply #1100 on:** August 09, 2010, 01:14:00 am »

Almost, Ae4 would be 1 and Ae3 and Ae5 would be 0. You start counting from the 0th bit to the 7th bit. Its an advanced math command and it shouldn't be needed that often so don't worry too much if it seems confusing. That particular command is aimed for assembly programmers although they might also hate me since its the reverse order of actual asm, but this convention actually makes more sense since data is usually read left to right like pixel data for instance.

DJ Omnimaga · « **Reply #1101 on:** August 09, 2010, 02:46:30 am »

To make sure I understand this correctly, Ae0 through Ae2 and Ae6 would be 0 as well, right?

calc84maniac · « **Reply #1102 on:** August 09, 2010, 02:56:36 am »

Sorry, I'm one of those disgruntled asm programmers who thinks counting should start from the right.

The way you have it set up, you can't even extract the upper 8 bits of a value. :O

Quigibo · « **Reply #1103 on:** August 09, 2010, 03:21:15 am »

Right, that's because the bit command e is for 8 bit numbers. ee will be for 16 bit numbers, also counting from the left, I just didn't have time to add that yet. Also, I will add the auto-opts next version to extract specific bits.

Another reason for counting from the left is because its much more optimized using the add hl,hl instruction (for 16 bit numbers) than trying to shift the number to the right or adding overhead to negate the bit number, so its a more optimized routine.

Raylin · « **Reply #1104 on:** August 09, 2010, 10:05:43 am »

Protip

Regardless of what on-calc language you are programming in, you can abuse the backup system in Axe for BASIC programs too.

Code: (BASIC) [Select]

:.<name of program here>
Put that at the beginning of the code and make a backup MANUALLY. Then, erase that line of code from the beginning of the actual program. It probably seems like a big hassle to a lot of people but, if you're chaining hooks from about 3 different APPs, I call it a necessity.

Runer112 · « **Reply #1105 on:** August 10, 2010, 03:17:03 am »

What exactly are the advantages of compiling to an app currently? And what could they be in the future?

Quigibo · « **Reply #1106 on:** August 10, 2010, 04:15:15 am »

Mainly that you get the whole 16KB space for execution instead of the roughly 8KB execution limit with regular programs. It also allows you to allocate much more ram since the program itself is not running from the ram. There is a possibility of allowing apps to be 2 pages in the future with a second page of data only, but I don't know how feasible that is so I can't say for sure. There are disadvantages though, so unless memory is an issue, I would just stick with programs.

Runer112 · « **Reply #1107 on:** August 10, 2010, 09:49:18 pm »

I was just looking at the auto-ops list, and I'm just wondering if all of these entries are correct, because they seem pretty odd. For instance, /10 is not only an auto-opt, but smaller than /2? And //64 is an auto-opt but /64 is not? Not to mention odd things like 16-bit checks being smaller than 8-bit checks.

Quigibo · « **Reply #1108 on:** August 10, 2010, 09:57:23 pm »

They are all correct, yes. /10 is only there because there is a B_CALL for that specific number and I figured that if you're going to be dividing by a constant ten, then you're probably trying to display a decimal number or something like that in which case the micro seconds don't matter and its better to have a smaller size. The division is indeed crazy, but that's correct, it takes more bytes to do a unsigned division by 64 than it does for a signed division (unless someone can come up with a smaller one). The 16 bit check routines are identical to the 8-bit checks, they just have different numbers since it counts from the left. Unless you mean the routine itself? That's due to a speed optimization since an extra byte more than doubles the speed, I took it.

There are a few other cases like that where I take the extra speed instead of a smaller size. My rule is if 1 byte increases speed more than 50% faster then I don't mind adding it. That's why *2048 is 6 bytes instead of 5 for instance.

Builderboy · « **Reply #1109 on:** August 11, 2010, 02:26:20 am »

Tell me, is Bit checking the buffer faster than pixel testing? If so, how much?

Author Topic: Axe Parser (Read 553187 times)

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Raylin

Re: Axe Parser

_player1537

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

calc84maniac

Re: Axe Parser

Quigibo

Re: Axe Parser

Raylin

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Runer112

Re: Axe Parser

Quigibo

Re: Axe Parser

Builderboy

Re: Axe Parser