I do agree that a customized editor would be nice. But is it necessary to actually build a custom editor program/application? I think the easiest way to implement a fairly simple but good Axe editor would be to keep using the built-in BASIC editor, but on top of the token hook, add a menu hook that adds menus specifically for the Axe commands.

If you start entering the realm of custom editor programs, you start moving away from the Axe project itself and into Axe IDE's, which can be made by a third party with about the same ease as I could. A custom-made Axe IDE would be awesome, but I should first and foremost be concerned with implementing the compiler and language features, and just adding the BASIC editor hooks as mentioned above because they're quick to implement.

Just a thought if you want to make a bit more polished. It would add some size, but I don't think a 4KB program getting pushed up to like 4.7KB (estimate) is much to worry about.

Are Mirage OS programs just like regular ASM programs except with the header?

I'm assuming you're talking about MirageOS assembly programs, in which case the answer is both yes and no. But primarily no. Yes because both are assembly programs that run natively on the calculator's z80 processor. No because, as you can see if you look at the MirageOS (or Doors CS) assembly header, they have a ret instruction right at the beginning so if they are run through the normal OS manner, they will return instantly. This is partly due to the other, more important "no" reason, which is that MirageOS and Doors CS provide libraries of useful routines which assembly programs with the shell header may rely on being present to use. For instance, it's quite common for assembly programs targeted at these shells to use the built-in screen update, sprite, and random number routines, among others. BASIC programs with a MirageOS header will not have this problem, as MirageOS provides no BASIC libraries. But Doors CS does, so BASIC programs with a Doors CS header also may rely on Doors CS being present.

Hayleia's idea of combining all four arrow key states into one number is definitely the way to go. However, may I propose a combination function that returns values without the need of a lookup table?

getKey(1)-getKey(4)*3+getKey(3)-getKey(2)

If my logic is correct, this should return the following values:

• -4: Left+Up
• -3: Up / Left+Right+Up
• -2: Right+Up
• -1: Left / Left+Up+Down
• 0: None / Left+Right / Up+Down / Left+Right+Up+Down
• 1: Right / Right+Up+Down
• 2: Left+Down
• 3: Down / Left+Right+Down
• 4: Right+Down

You could then store and access your sprite data like this:

.Sprite data
[FF80808080808080] .Left+Up
[FF00000000000000] .Up
[FF01010101010101] .Right+Up
[8080808080808080] .Left
[0000001818000000]→°DirNone
[0101010101010101] .Right
[80808080808080FF] .Left+Down
[00000000000000FF] .Down
[01010101010101FF] .Right+Down


.Later in the program...

.To get a pointer to a directional sprite
getKey(1)-getKey(4)*3+getKey(3)-getKey(2)*8+°DirNone


---

If you didn't actually want there to be a "no direction" sprite and have the sprite remain facing the way it was from the last keys pressed, I'd try coding in some logic like this:

.Initialize some direction
3→D .Down


.Later in the program...

.If the current arrow key state is an actual direction (≠0)
If getKey(1)-getKey(4)*3+getKey(3)-getKey(2)
.Store the new direction
→D
End

.Somewhere later, the sprite is displayed
Pt-Something(some_x,some_y,D*8+°DirNone)

In this case, the no direction sprite (0) should never be displayed, so the °DirNone sprite is a bit of a waste of space. However, if you want to be a crazy optimizer (I do), you can put some other sprite you need in your program in that spot.

I went a little bit overkill, but I slightly optimized and turned my old free/total archive commands into a mini Axe library. It's fairly straightforward to use, consisting of two commands and one constant definition:

• TotalArc(): Returns a string (no padding) representing the total number of bytes of user archive space for the host calculator model.
• FreeArc(): Returns a string (no padding) representing the free number of bytes of user archive space.
• °Arc: After either of the above calls, this points to a string representing the same number, but padded with spaces on the left to always be 7 characters wide.

The library is attached. Just send it to your calculator (preferable archive so you don't lose it in a RAM clear) and include it in your program anywhere as prgmARCLIB.

Considering that nitty gritty compiler features like that were implemented by Quigibo and I frankly am still not entirely sure how his code for them works, I think I'd have to pass on implementing that.

I think the Axe 1.x version line is coming to an end anyways, so putting work into adding features to the actual compiler, which I hope to largely rewrite, would be a fair amount of work for code that would probably only ever exist in one or two versions of Axe. I hope to redo the general library system to be a more robust in the next major version of Axe, so I'll probably implement something that provides the same functionality as your suggestion, just in the different library format.

At this point, I'm looking to collect ideas for the future of Axe, but it'll be a ways off until I can implement them.

I'm of the opinion that your archive was just a bit messed up and that it wasn't Axe's fault. You should try Axe 1.2.2 again, and if it still doesn't work and you send over Calcsys as well, I can try to help debug it further.

There is no built-in iteration mechanism to update grayscale in Axe. The programmer updates it whenever they choose to. Up to the LCD's refresh rate, which is around 60Hz, more frequent updating usually means better quality.