As far as I know, there's no reason why Bitmap() wouldn't work in applications.

Axe Parser
Omega 1.2.2

---

I've been quite busy with school (and generally lazy to boot), sorry it's been so long since the last update. The Axe application is bursting at the seams, so it's difficult for me to fit in new language features, but I fit in a few. The primary focus of this release is to improve stability, so a lot of the new things in this version are application usability improvements and bug fixes.

If there are any outstanding bugs, even if you've reported them before, or if you find any new bugs, please report them in the Bug Reports thread. I'd like to get Axe to be as stable as reasonably possible, and you can help.

New Features:

• New command to call the OS keypad scanning function: getKeys (or getKeyS). A useful application is to put this in your custom interrupt so you can use getKey and getKey^r in your program like normal.
• New command to set the LCD's z-address: ZInterval #.
• New commands that suspend annoying things for the remainder of your program: Full^r and Full^rr. The former suspends any memory delays on non-83+ calculators and the latter suspends Horiz mode (forces a ClrHome upon execution and when your program returns). These commands will not properly restore the suspended settings if you use Return^r!
• Added a new form of calling inData() for which you specify the length of the data to check: inData(BYTE,PTR,SIZE). No issues when searching for zero!
• Axe no longer disables Horiz or G-T modes.
• APD can now activate, so accidentally leaving Axe running won't drain your battery so much.
• Error if application being compiled will be too large after the first pass instead of the second pass.
• Using lowercase letters in the output name header will throw an error when not compiling as an application.
• Generally more robust source file header parsing and validation, including being able to jump to errors in headers.

Changed:

• Renamed sign{} to signed{} and renamed stdDev() to strGet() for clarity.
• Optimized direct key input slightly. ***If your calculator has had key port (delay) problems related to getKey(#), please test that direct key input works.***
• [Jacobly] Greatly optimized the speed of high-order and fixed-point multiplication.
• [Jacobly] Optimized circle drawing slightly.
• Changed the default varaible location again, this time into smallEditRam. The previous location conflicted with MathPrint.
• Reorganized the command list slightly.
• Fixed sometimes getting stuck in an infinite key wait loop after an error.
• Improved the error dumper with more debugging information for me!
• FIXED THE SEEMINGLY RANDOM COMPILING FROM ARCHIVE ERRORS THAT HAVE PLAGUED AXE SINCE 1.0.0! Big thanks to shmibs for helping me debug this!
• Fixed some parsing issues with For()^r.
• Fixed 3-argument HLine() and VLine().
• Fixed inverted circle drawing.
• Fixed ?Hex and archived value reads in programs compiled for Axe Fusion.
• Fixed an error with the use of special OS variable names, like Pic2, in strings.
• Fixed an obscure bug caused by putting r₂-r₆ immediately before a function call.
• Fixed error scrolling with zStart crashing for archived source programs that span multiple archive pages.
• Fixed 8-character names immediately throwing an error when trying to compile applications.
• Fixed multiple bugs with application writing, including not recognizing when there was no space for the application.
• Fixed an error being thrown when compiling a program whose target already exists in archive after a fresh garbage collect. Thanks to thepenguin77 for helping me debug this!
• Fixed other bugs I forgot about.

Foreword: the solution to this issue probably has to deal with something like OS flash modification procedures or the certificate, so expect to need to know about these things.

Here's the issue I'm experiencing with Axe. I'll start with a high-level description. Since at least Axe 1.2.1, I have experienced a very peculiar bug. On the few occasions when I've sent a new development version of Axe to my calculator, the very first compile would result in a seemingly random compilation error occurring almost instantly. This error would never occur again for the same version of Axe, as far as I can tell. I've tried replacing it with the old version of Axe and re-upgrading it, I've tried clearing RAM, and I've tried sending new "dummy" upgraded versions of Axe that have one small thing changed to make the application slightly different. None of these seem to replicate the bug. The bug also doesn't seem to ever occur in wabbitemu.

I'm fairly certain this is not a fluke. This exact scenario of me making a ton of changes and sending the new version of Axe to my calculator months after the last build was sent has happened at least three times so far; once with an older version (perhaps 1.2.1, or an early 1.2.2 build?), and twice with sending the most recent 1.2.2 to two of my calculators. I have one calcultor left still with Axe 1.2.1 on it. I predict that sending Axe 1.2.2 to this calculator will replicate the bug one more time, but I'm saving it to add more debugging tools as necessary to a build of Axe 1.2.2 to hopefully pin down this bug.

Now, for some lower-level details. The error occurs due to a failed B_CALL(_WriteAByteSafe), oddly on what I believe is the second call to that routine with the fresh version of Axe. The write is to the first page of the swap sector, which should have been erased by a B_CALL(_FindSwapSector) \ B_CALL(_EraseFlashPage). In the register dump that follows, the swap sector perhaps unusually starts on page $0C, but I don't think that's part of the issue. From what little I remember of the dump I got from my first calculator, which I didn't save, I believe everything was the same except the swap sector started on page $08.

Anyways, here are the known input and output register values from B_CALL(_WriteAByteSafe) that I got from the existing debug dumper in Axe 1.2.2 when the error occurred on the second of the two calculators I sent it to:

• INPUT: af=$0C80, bc=$4701, de=$4011, hl=$8686    (note: the value of b is not officially known, but that's what it ideally should  have been)
• OUTPUT: af=$1F08, bc=$0000, de=$4011, hl=$8478

If anyone already has any ideas as to what the problem is, or ideas of what to add to a debug version of Axe to hopefully replicate and better debug the issue on my third calculator or your calculator, I would appreciate them. If not and I can't solve the issue myself, I'll just write this off as a minor bug since it only happens once per Axe upgrade anyways.

*snip*

• Regarding the shortcut to enable MathPrint not working unless it has already been enabled once: ... can you do something sneaky to always let MathPrint load up on RAM clears, but after it has been enabled, immediately switch to Classic mode if that default is set?

Also, another thought popped into my mind. You know how a while ago I mentioned that Omnicalc's quick apps menu doesn't register a context change until after any executed app returns to the OS? That may be a hard Omnicalc issue to fix, but I realized there are other issues with Omnicalc that might be (perhaps more easily) fixable. For instance, enforcing that parentheses assistant, the entries menu, and RAM recovery are disabled when MathPrint mode is enabled, and returning them to their original settings when Classic mode is enabled. It also may or may not be feasible to kill the partial line clear functionality when MathPrint mode is enabled. (I got the impression that you try to keep your key hook fast by only having ON+___ shortcuts so you can abort if ON is not pressed, but this check would need to occur before that)

Running external apps and programs is tricky and should really involve stuff like error handlers when done properly. Considering DrDnar's axiom exists and does most of that already, and that the Axe application's 2 pages are pretty much completely full, I don't think this is something I'd consider adding to Axe at the moment.

It's spelled Runer, gosh, why can nobody get it right!

But I'm guessing this project is in Axe. As for what the game actually entails, we'll have to wait to hear more it seems.

Primarily due to the entirely different screen, but also other internal technical reasons, any flash applications or assembly/Axe programs designed for the regular 83+/84+ calculators will not work on the 84+CSE. Unfortunate, I know.

New programs and games are starting to be developed for the 84+CSE, though, and a few have been released. If you're looking for assembly games, perhaps you'll find something you like here or here?