I would advise fully reading through the Documentation.pdf file included in Axe releases, for starters. It's far from a total guidebook, but it covers a lot of the basics and walks through code examples for common tasks.

Axe includes data in programs in the same order you enter it. What this means is that if you enter the data for 19 sprites contiguously, they will end up in the compiled program in that same order with no gaps between their data. Knowing that each monochrome 8x8 sprite is 8 bytes large, each consecutive sprite must then be exactly 8 bytes in memory after the one before it. So you can access the Ith sprite (0-indexed) with I*8+Pic00.

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.

Hooks cannot be made with pure Axe. You'd need to mix in a fair amount of assembly for the hook management.

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

http://www.omnimaga.org/index.php?topic=16162.msg291540#msg291540


EDIT: If you don't plan to allow editing of archived programs just yet, that awkward hacky line can be done away with. Just skip any archived programs, for which dim()^rr will be nonzero, and then simply get the pointer to the start of the program's data in RAM with dim()^r.

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:

I'm confused; how does this stand-alone, low-level calculator management utility relate to a shared programming/graphics library like Ion? To me, they seem to serve different purposes, and one can't really be molded to serve the purpose of the other.

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.

Are you asking what those tokens are? The ʳ and ° are both found in the ANGLE menu, accessible from 2nd + APPS. And you probably knew these already, but just to be complete, dim( is accessible from 2nd + STAT + right, and Y₀ is accessible from VARS + right + 1/enter. Everything else on that line can be found directly on the keypad.

But what does the comment from the line below it have to do with it? That comment is a placeholder saying that you want to replace it with the actual logic of testing if programs match your pattern and processing them accordingly.

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.

Do Basic Builder applications call B_CALL(_ReloadAppEntryVecs) before exiting? If not, I don't think it's an OS bug as much of a Basic Builder bug for not following TI's application exit protocol. I think it was recently noticed in a thread on Cemetech that one of the effects of not calling this (at least on MP OSes) is that the appRunning flag is left set when the application exits and small issues arise, so whether or not you mess around with context vectors and you think you actually need the call, it seems that this call may be important.

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:

It is true: archived files cannot cross sector boundaries.

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: