It's pretty unsurprising, really. Only a few people have the existing knowledge of how to make a good audio engine, Axiom development isn't exactly very popular, and the Axiom system is better suited for simple commands that user code calls when needed rather than orchestrating a whole engine that has to run in parallel with user code.

Are you not supposed to load a file onto an existing file? Like, if I put appvHELLO to [Y2] and then do appvHELLO2 to [Y2], does it break some stuff, because when I tried to read another file in [Y1], it doesn't work anymore, program crashes after having the run indicator turn on and then pressing any button.

I don't believe this should cause any issues. Unless, of course, other parts of your code still expect the old variable to be pointed to by Y₂.

Still, the token hook doesn't work on my setups (both real and emulated). Could you transfer me your compiled program file to see if the problem comes from my calc or the compilator ? Thanks.

Here it is.

The token hook works for me:




As for functions behaving incorrectly, I see two issues in a first look:

• The code you use to signal that the next address should be replaced actually signals not to replace the next address. The correct signal is $7F. I'd also advise using the REP_NEXT macro provided by Axe.inc instead of producing the signals manually, although some tweaking may need to be done for it to work properly in some assemblers.
• All arguments are passed as 16-bit values, but you pop some off the stack into af. This puts the low byte (the one you want) into f, not a. You should pop these arguments into a 16-bit register pair and then move them into a.

1) how many cpu  Cycles does it take to read a byte from a file like {y1}

About 200 cycles. For reference, it only takes 14 cycles to read a byte from RAM. So if you're going to read this data often and are worried about speed, you should consider migrating this data to RAM.

And doing exp》{y1}  automaticallysagves it to the appvar that very instance right?

Is 》 supposed to be →, the store operator? In that case, I hope Axe would throw an error if you tried to compile that, as you cannot (for most intents and purposes) write data directly to archive.

Combining your two questions together, it sounds like you're planning on doing many read/write operations to an appvar. In that case, you should probably UnArchive it to work on it and Archive it when done.

I've successfully torn out the juicy asm codes and put them in my program. Just want to make sure that you will be ok with me doing so? I will credit you for "writing the greyscale interrupt code" in my programs.

I'm still not sure why you wanted to manually pull the library apart to include bits of it in your program instead of simply letting the library and its preprocessor conditionals handle it for you, but I guess that's your prerogative. The point of the library is for people to be able to use the code after all, although you've done so in a strange way.

Also can you pls explain what exactly Gwait() does?

GWait() waits until the frame most recently offered up for display with GDisp() has been "fully" displayed. This means displayed twice for 3-level grayscale and displayed three times for 4-level grayscale, as that's how many grayscale updates it takes to go through all the phases of the dithering mask so all of the pixels have been displayed for the correct ratio of time. Whether or not this actually improves the visual quality, I'm not totally sure. But it's also useful as a timing mechanism to keep your program running at a constant rate.

<sarcastic comment> waiting seems the best thing to do when the interupt  takes up a third of the cpu time!</sarcastic comment>.

One third? I think you might be dreaming. The interrupt takes more like three fourths of the CPU time. I should probably add this information to the first post/readme to clarify for potential users that "perfect" grayscale is a very expensive feature.

Ps, in an earlier post on this thread you said you where writing a more efficient timer interrupt. Was that implemented or is it still coming?

I'm still experimenting with it. Nothing I can put into the library yet, but work is being done.

Alright, so as far as I can tell, the modification was successful. It uses the same tokens and input format as the original Axiom, but each token now starts with an "H." Some weird OS behavior that I can't explain may make the "ZoomFit" token not be replaced with "HScaledClip-On(" in menus, but it should otherwise work correctly.

The Axiom and its source are attached to this post. Let me know how it goes!

I know one of the goals of Axe was to be compatible with the Nspire 84+ emulator. However, I think the compatibility for the app itself may have been lost at some point, and only the compatibility of compiled programs retained. My best guess would be the 1.0.0 release is that point, as that's when Axe started using a flash unlock exploit and writing data to flash, and I wouldn't be surprised if these aren't emulated properly.

Does anyone have experiene with using past versions of Axe on their Nspire 84+ emulator, or would anyone be willing to take some time and pinpoint the version that broke compatibility? If my guess isn't correct and it wasn't in fact the 1.0.0 release, it may be something that's reasonably fixable.