Axe is not assembly, just like C is not assembly. And Axe doesn't natively support things like hooks for a couple of reasons. Hooks don't really interface with languages other than assembly well, because it's common for inputs/outputs to be in specific CPU registers, or even flags. And different hooks have different inputs/outputs, so it's not really easy to handle them all. Also, because most hooks deal with core OS functionalities, it's common that the hook needs to use OS constant definitions, which are readily available to assembly programmers, but not Axe programmers. And this one isn't a deal-breaker, but generally hooks should be fast; a slow hook can really bog down a calculator. Assembly code can be made to be far faster than Axe, and I don't want to encourage the production of bulky and slow hooks.


tl;dr Hooks are best left to assembly, in my opinion.

Stuff I intend on fixing later:

Quote from: MGOS on February 21, 2013, 10:03:09 am

I found another bug with Axe compilation. Unlike Axe, zStart doesn't check whether a program is compilable or not, so you can accidentally compile another source file (e. g. a file with subroutines etc.) which is not meant to be compiled as the main program by Axe. It causes Axe to crash or compile another program (like the one directly above or below (?) in the program list). Of course you can avoid this by not doing the On + Sto-> in the wrong place but it happened multiple times when I didn't watch out.

I believe I've fixed this problem from the Axe end for Axe 1.2.2.

The first issue I see is the omitted closing parenthesis after GetCalc( on the first line. Unlike in TI-BASIC, a store operation in Axe does not automatically close all unmatched parentheses before it, so that code would really be storing the pointer to the raw string data "Str1" rather than the result of calling GetCalc("Str1"). Close your parenthesis in Axe!

The other issue is that the length() command is for finding the length of null-terminated strings of data. But OS variables that can have a variable size, including OS strings, don't use null termination to mark their size, but instead have the size stored as a 2-byte header immediately before the data. So if you have a pointer to an OS program, appvar, picture, equation, or string in the variable A, then the size of the data (not including the 2-byte size header) can be accessed with {A-2}^r.'

With those two changes applied to your code, hopefully this should work:

:GetCalc("Str1")→A
:{A-2}ʳ→L
:If GetCalc("prgmASDF",L)→B
:Copy(A,B,L)
:Else
:Disp "Creation error"
:End


In the code I gave, you'd replace that comment with your code to check for the pattern you want. How you check for the pattern is up to you, and depends on the pattern you want to match. For whatever pattern you're checking, you'll probably end up using multiple instances {n+Y₀} to read the nth byte (0-indexed) of the program and compare the value to the expected byte/range.

Why do people keep saying that 2.55 is buggy? In my experience, 2.55 is no buggier than 2.43, bugs are just caused by a few old programs that made bad assumptions. With MathPrint turned off, I have found extremely few things that don't work fine in OS 2.55. The only thing I can think of off the top of my head is that Omnicalc's entries menu doesn't work, but you don't need that anyways because of the built-in command history scrollability on the home screen.

If you know of any bad OS 2.53/2.55 bugs, feel free to share, though. They may be there, I just haven't found them in my experience, so I'm quite happy with the new MP OSes.

I believe you want to search for all programs on the calculator that start with some certain pattern? Once you've located a program, checking for a certain pattern should be fairly straightforward: just compare the first few bytes read from the program to values/ranges you want them to be in. But the key to being able to do what you want is being able to search through the VAT, a list of all variables on the calculator, to find programs. Probably the easiest way to do this is with MemKit, an Axiom included in the Tools folder in the Axe release. How to include the Axiom and use the individual commands is explained fairly well in the readme, so I'll get right to generally how you want to use MemKit. You generally want to loop through all items in the VAT in a style like this:

Load()         .Start at beginning of VAT
While 1        .Start loop
If dim()=5     .If this VAT entry is a program
.The next line is a little hacky and will not work in versions lower than 1.2.1
.This manually sets up Y₀ to be used to access this variable
(dim()ʳʳ→{°Y₀+2}??dim()ʳ,dim()ʳ-16384)→{°Y₀}ʳ
.Here you perform whatever checks to see if the variable fits your pattern and act accordingly
End
End!If Next()  .Continue loop if there are more VAT entries to process


There's a pretty ingenious (at least I thought so when I learned it years ago) way to handle this. Keep track of the total number of bullets with some variable. When you add a bullet, increase the bullet total and put the new bullet at the end of the list of bullets, which should be at the memory location old_total*6+list_start. This all probably seems pretty standard. But the trick is in bullet removal: decrease the bullet total and move the data for the last bullet in the list into the position of the bullet that was just removed. In Axe, the code for that might look something like this:

.Deletes the bullet at index r₁ (0-indexed)
.Updates bullet total N
Lbl Del
Copy(N--*6+<list_start>,r₁*6+<list_start>,6)
Return