The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

[theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators

Started by Agothro, January 04, 2015, 06:02:17 pm

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

DJ Omnimaga

Oh ok, although lacks of updates for such periods of time can sometimes reduce the userbase of a project, especially older community members and people who have used Internet for years. Most Internet projects die this way so nowadays as soon as a project starts showing signs of tanking, people become skeptical about its future very easily.

As for Axe yeah I wish on Casio calcs we at least had Axe or some form of parser hook-based lib like xLIB or CelticIII that enhances BASIC with extra commands.

Duke "Tape" Eiyeron

It's nt hook based, it's interrupt based. We have to wait until the program reads the value inside a variable to execute the chosen function. So a PRGM2 program will have a lot of While <VAR>:WhileEnd (I forgot which var was used)

DJ Omnimaga

Wait wouldn't that slow the rest of the basic code down? ???

Duke "Tape" Eiyeron

Quote from: DJ Omnimaga on January 07, 2015, 04:57:03 pm
Wait wouldn't that slow the rest of the basic code down? ???

Yes it would. Unfortunately, the BASIC parser isn't made to be as flexible as TI's where Apps can register their own Tokens (it seems so)

DJ Omnimaga

Nah actually TI apps no longer register their own tokens. Illegal tokens caused issues sending files from one calc to another so people stopped doing this. Now they just use existing token modifiers. For example, with Omnicalc installed, the Real() command will behave differently if it has more than 1 argument. That's the parser hooks coming into action.

It causes some slowdowns, though (for example, with Omnicalc enabled, For(Z,0,999:End is almost twice slower, although other stuff is nearly at the same speed and the slowdown isn't as bad with Celtic III, DCS7 and xLIB)

DJ Omnimaga

So this would be the first necropost on CodeWalrus I think, but one comment from Runer112 at #omnimaga catched my attention in the logs a few weeks ago:

Quote[21:24:52]<   tr1p1ea   >   are you going to persue Axe CE?
[21:24:59]<   tr1p1ea   >   or will ZDS C compiler be enough
[21:25:28]<   Runer112   >   C meets the need well enough
[21:26:54]<   Ivoah   >   but but on-calc
[21:27:01]<   Ivoah   >   editing and compiling

In other words, forget about an Axe Parser port by Runer112 for the TI-84 Plus CE and the TI-83 Premium CE. Before 2010, I witnessed many causal TI-83+/84+ programmers who learned TI-BASIC and hybrid TI-BASIC (xLIB, CODEX, ZSprite, etc) who eventually hit a wall with speed problems, so those programmers eventually turned towards Z80 assembly or, if they knew about the existence of SDCC and Z88dk, then they gave C a try. Unfortunately, in many cases, they could never overcome the high difficulty or difference gap between TI-BASIC and ASM/C, so they were left with no option but to quit calculator programming entirely.

Then came Axe Parser, which bridged the gap between TI-BASIC and ASM/C by providing what everyone wanted: Something with graphical commands nearly identical to TI-BASIC, but with the speed of assembly (or at least faster than the code that Z80 C compilers could produce). While Axe was generally low-level overall and some stuff was harder than C, the hi-level stuff looking similar to TI-BASIC syntax was what made it successfull. This revived the Z80 programming community in 2010. Not only that, but Axe even helped some people make the jump into ASM afterwards, due to the smoother transition towards this language. But more importantly, the amount of fun calculator games skyrocketed in 2010, compared to 2008-09.

Grammer was another Axe-like language that helped bridging the gap, but it never took off as much because it came out after Axe and competed head-on with it. But the idea behind it was similar.

However, neither Axe nor Grammer are available on color models and if you notice, not many people seems interested in programming for them compared to black and white ones. But since Axe's current author is not interested in doing a color port of such language, then the group of community users who found BASIC too slow but ASM/C too hard despite efforts has now been singled out from the TI programming scene.

So do you think that there should be something like Axe Parser or Grammer for the TI-84 Plus CE and TI-83 Premium CE or that future language projects for those calcs (*cough* @Cumred_Snektron *cough*) should be designed in similar ways to cater more to TI-84+ BASIC programmers? It would take a lot of time and skills, though, but I personally think from my 14 years of experience with monochrome calculator programming that this would make the 84+CE attract a wider range of programmers.


I think the language should be redesigned from scratch because while Axe is great, it does have problems, also the CE being a superior platform the new language needs to take advantage of it. The current implementation of Axe can't be reused anyway, it would be dumb to run it in z80 mode. :P So yeah, new calc new language. The benefits of Axe can't be denied.

As I said though, C is definitely not ASM, it's much closer to Axe but the syntax and the standard library are different.


I think there's a missed point here.
In my opinion, indeed, C could be to the PCE what Axe was to the monochrome (a fairly low level language but without being Asm).

BUT, that's not why we want to see Axe ported to the PCE line. We want it so that we can port monochrome games to the new calculators.
And also because I'm sure I'm not the only one to like Axe better than C, but that's another story...


So i think the best would be a language that looks like Axe, but is actually a redesign?
I have been looking at antlr so i kow one or two things of compiling. I also made an almost complete language without any third party tools.
Though these have all been on PC, and the compiler should at least be available on calc. Now i don't know the level at which Axe does semantic checking (eg whether a function returns a value or not), but since Axe (on the SE) only has 16 bit integer types it should be OK. The compiler algoritm could be based on, that would allow it to have proper precedence too <_<. The benefit of TI is that it automatically has a line delimiter though.
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Axe has one major difference with C. C is designed for portability, Axe is designed very specifically for the TI-83 Plus family, the CE sounds like it has some big differences. Porting Axe itself to the CSE wouldn't be so hard since it's literally an 84+SE with more flash and a new screen.


Quote from: Cumred_Snektron on October 11, 2015, 10:17:27 am
whether a function returns a value or not
Depending on what point of vue you take, you may say that none return a value or that all of them do.
Basically, it's just you who decide if that function returns a value by putting a value in hl before leaving, or you don't put anything specific in hl and it still kind of returns what's in hl but you don't use that value so you don't care.


Indeed. I suspect axe of resetting its stack after every newline anyway
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Wait, would this mean that you would be able to play TI-84 Plus games on the TI-84 Plus C SE?
I'm just trying to grab some inspiration. :P


Quote from: SiphonicSugar on October 11, 2015, 05:41:46 pm
Wait, would this mean that you would be able to play TI-84 Plus games on the TI-84 Plus C SE?

No, it would mean that someone will be able to, in theory, compile to the SE, SCE, and CE calculators from relatively the same source code.

DJ Omnimaga

@Streetwalrus While Axe is similar to C in some ways, what made Axe successful is how the graphical commands like Pxl-On() were nearly identical to TI-BASIC. Since BASIC programmers wanted a language that starts with a similar syntax, but almost as fast as ASM, they were able to pick up Axe very easily (some would eventually get stuck but at least they could do some nice graphical games fast). I agree that Axe for color calcs would need to be redone from scratch though. But I think the idea should be the same: Similar syntax to TI-BASIC but ASM-like speed. Hence why being able to port monochrome games like @Hayleia mentionned is not the only point about a potential color Axe language. And I personally think that since Axe was made with calculators in mind, then it's more suitable to start with than jumping straight into C.

Another solution would be Lua (or LuaCE?), but its syntax for graphical commands is way different than TI-BASIC too, so while Lua had the same effect on the Nspire as Axe had on the 83+, it might not work as well on the 84+CE. But that's just me.

An Axe language for the 84+CE would definitively need a new name, since some stuff would be different (due to screen differences and perhaps different RAM areas forcing code syntax to change a bit).

Powered by EzPortal