Axe Parser and xLIBC. xLIBC first, probably, assuming the PRIZM has parser hooks.

Well, early versions of Axe actually lacked ASM and Axiom support and we could still do pretty interesting games. So basically supporting inline ASM wouldn't be necessary. I guess in the future you could add SH4 ASM support, though. Axe became "mature" around version 0.2.0, so I guess commands from 0.2.x could be the first being supported in general.

I don't know which Axe program use ASM, unfortunately, but an example of Axe program not using a single line of assembly would be this. This game runs at 6 MHz with parallax scrolling, yet it still manages to not lag. The only problem is that Axe code is about 1.5 times larger than its BASIC counterpart, since it's compiled.


EDIT: And yeah I added xLIBC. If the PRIZM supports parser hooks, this could be an alternative until Axe is made, since it could simply be an add-in enhancing Casio BASIC by just 2 or 3 commands (sprites, for example), but on the 83+ there was another xLIB and when Axe arrived it pretty much led to xLIB's demise (most BASIC coders back then decided to move to Axe programming). So xLIBC would be just a temporarily solution in case Axe Prizm took several years to develop.


Another idea I just got, if the PRIZM supports parser hooks, is an add-in that replaces the behavior of existing sketch commands to get rid of the 0.3 second delay when drawing stuff.

Well it depends, because if you take Axe source code then compare its compiled format, the result is much larger. Axe uses TI-BASIC tokens/commands so each of them takes 1 byte of space, but its compiled, machine code form might be larger simply because in machine code clearing the screen isn't done in 1 byte of code like in TI-83+ BASIC. But again, Casio calcs might be different (I think each keystroke character is 2 bytes instead of 1, right?) so I guess it would depend how well the Axe compiler is coded.

And yeah it would be best to keep the Axe language syntax as similar to the TI version as possible. Of course commands like Output() would be replaced with Locate and many others would change, but someone could just write a batch script that converts 83+ Axe source to PRIZM Axe source by renaming commands.

An interpreter could work too, although my concern was speed. Interpreters tend to be slower than compiled programs sometimes, especially on a 58 MHz calculator. Using its own editor might not necessarily be a good idea unless it works almost identically to the BASIC one (although I think using smaller fonts so that you can see more text at once on the screen would be better), though, otherwise the language might suffer the same fate as BBC BASIC 83+ (awesome language, but just because of how the editor worked, nobody used it).


Otherwise, a good idea could be a computer editor, but then we face the issue that is the lack of a public domain PRIZM emulator, so for people who have expired copies of fx-cg10 manager (assuming Axe would even run in it) they would have to constantly transfer computer-edited Axe programs to their calculator to test them.



By the way, a new PRIZM emulator that runs at normal calc speed and has a debugger would be another nice program idea.

YEah I definitively think that an Axe PRIZM interpreter would be much faster than the Axe compiled 84+ programs. Of course some stuff might not be as fast such as a parallax scrolling version of Super Sonic Ball because the PRIZM screen contains much more data to draw than the 84+SE screen, but still, speed would be enough to convince people to use the language.

As for the editor I was just mentionning because I know what happened with BBC Basic 83+, although I doubt you would go to such extreme extent. But just having a standard editor being too different than the official BASIC one is sometimes enough to make some people unable to get used to it (in my case, it took 11 years before I finally get used to programming 84+ BASIC games on a computer instead of on-calc.)

Yeah my main concern was that the 84+CSE only gets about 4 images per second in pure assembly when you fill the entire screen with one color and the calc runs at 15 MHz, and the PRIZM runs at 58 by default. Of course there are other factors too like screen drivers and VRAM I guess, though.