CodeWalrus

Development => Calculators => Calculator News, Coding, Help & Talk => Topic started by: Agothro on January 04, 2015, 06:02:17 PM

Title: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Agothro on January 04, 2015, 06:02:17 PM
Axe Parser, for the uninitiated (probably the small minority on this site) is a development tool (compiler kit) and programming language for the TI-8{3|4}+(SE) (henceforth the TI-84). Many games have been written with it. Now, those games are not easily ported to any other calculator (they have to be rewritten.)

I'm particularly interested in making a port that can run decently on an TI84+CSE. I wouldn't make it myself, since I'm not an ASM programmer (yet), but maybe one day...

Upon compilation, you'd choose a graphics mode:

Mode 0 would be the native resolution of the TI-84 (96x64)
Mode 1 could be the native resolution of the TI-84+CSE, HP Prime, nSpire CX, and  (320x240)
Mode 2 could be half resolution for the those calcs (160x120)
Mode 3 could be the native resolution of the Casio FX-CG10 (384x216)

etc.

and zoom mode could be set to 1x, 2x, etc. Lines and pixels would be doubled appropriately.

color modes:

Mode 0 would be Black and White.
Mode 1 would be 4-Gray.
Mode 2 would be 8-color. (set from a palette of colors per program)
Mode 3 would be 16-color (again set from a pallette)
Mode 4 would be 256-color. This would be enough, at least for now.

My first theoretical approach is a port to the 320x240 calcs. Let's do an example of scaling here, if we have a program written for a TI-84 originally (100% of current Axe programs)

So, let's say the mode is Graphics:0/Disp:2x/Color:1.

Let's say there's a centered display.

Pretend this image was centered well, ok?

(http://i.imgur.com/JOSwN4Q.png)

Now, the screen BG would be set for all the other pixels before the program starts. Each cycle, the program sends blank data for all these pixels. It stores 96x64 pixels internally with 2bits/pixel, making the screen data that's rendered for each frame 12228bits, or 1536bytes. This will fit into the RAM used for buffer comfortably. Each cycle, the program will do the following for the drawing function:

For each line not in the image, you won't have to store data, so it'll output a set number of blank lines (set by the mode) and then a set number of blank pixels, followed by each pixel of the image (twice per data point), followed by some set amt of blank, new line, blanks, duplicate of last line, blanks, repeat for the other lines. I'm assuming that the pixels are not written synchronously (hopefully), or else you need more RAM. Of course, the colors (preset) will be translated on the fly per pixel (at least for now). Hopefully this sounds like it could run fast enough.

Any tips? This is purely theoretical details of implementation, and not a project per se ... yet.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: matrefeytontias on January 04, 2015, 07:33:17 PM
TI-Nspire, Casio and HP support is absolutely impossible (different CPUs mean different ASM languages). Actually, I'm sorry but nearly 0% of what you proposed is even conceivable. Though, there could be a way to make Axe programs compatible with the CSE without too much work (it's still much work, but you're not rewriting the whole app). Basically, when compiling for the CSE, the following has to be taken care of :
No other change should have to be done unless I forgot something. The areas used through L1-L6 on monochrome calcs still exist on the CSE AFAIK.

The only real difficulty would then to make the app choose between monochrome and CSE versions of certain routines which needs platform-specific code. I say it's a difficulty because the two pages Axe takes are getting pretty full already.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 04, 2015, 07:35:39 PM
It's perfectly possible if you completely reimplement from scratch, which is what I suggested.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 04, 2015, 08:00:07 PM
It would definituvely work differently, due to how much slowe it would be on the CSE. It would have to be redone from scratch. That said, an emulator running at 160x240 skipping every two line of pixels during drawing (or maybe interlacing) would probably not be too hard to do for monochrome games like Portal
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Yuki on January 04, 2015, 09:01:16 PM
As I see, that would actually work, but you'd have to have a compiler for the 83+ models and one for the CSE, so you'd distribute 2 versions of your binaries. The CSE would probably be able to support all the options mentioned, but not the 83+ one.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 04, 2015, 09:19:33 PM
That's correct Juju, the programs would still be separate. And of course programs using unsupported graphics modes would not run on calculators not supporting those modes. The advantage is not meant to be one binary, it's meant to be so that a game can be programmed once and easily ported.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Yuki on January 04, 2015, 09:25:25 PM
Yeah, a language should not be bound to one specific platform. Program once, port everywhere.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: TIfanx1999 on January 04, 2015, 09:30:22 PM
Quote from: Agothro on January 04, 2015, 06:02:17 PM
Axe Parser, for the uninitiated (probably the small minority on this site) is a development tool (compiler kit) and programming language for the TI-8{3|4}+(SE) (henceforth the TI-84). Many games have been written with it. Now, those games are not easily ported to any other calculator (they have to be rewritten.)

I'm particularly interested in making a port that can run decently on an TI84+CSE. I wouldn't make it myself, since I'm not an ASM programmer (yet), but maybe one day...

Upon compilation, you'd choose a graphics mode:

Mode 0 would be the native resolution of the TI-84 (96x64)
Mode 1 could be the native resolution of the TI-84+CSE, HP Prime, nSpire CX, and  (320x240)
Mode 2 could be half resolution for the those calcs (160x120)
Mode 3 could be the native resolution of the Casio FX-CG10 (384x216)

etc.

and zoom mode could be set to 1x, 2x, etc. Lines and pixels would be doubled appropriately.

color modes:

Mode 0 would be Black and White.
Mode 1 would be 4-Gray.
Mode 2 would be 8-color. (set from a palette of colors per program)
Mode 3 would be 16-color (again set from a pallette)
Mode 4 would be 256-color. This would be enough, at least for now.

My first theoretical approach is a port to the 320x240 calcs. Let's do an example of scaling here, if we have a program written for a TI-84 originally (100% of current Axe programs)

So, let's say the mode is Graphics:0/Disp:2x/Color:1.

Let's say there's a centered display.

Pretend this image was centered well, ok?

(http://i.imgur.com/JOSwN4Q.png)

Now, the screen BG would be set for all the other pixels before the program starts. Each cycle, the program sends blank data for all these pixels. It stores 96x64 pixels internally with 2bits/pixel, making the screen data that's rendered for each frame 12228bits, or 1536bytes. This will fit into the RAM used for buffer comfortably. Each cycle, the program will do the following for the drawing function:

For each line not in the image, you won't have to store data, so it'll output a set number of blank lines (set by the mode) and then a set number of blank pixels, followed by each pixel of the image (twice per data point), followed by some set amt of blank, new line, blanks, duplicate of last line, blanks, repeat for the other lines. I'm assuming that the pixels are not written synchronously (hopefully), or else you need more RAM. Of course, the colors (preset) will be translated on the fly per pixel (at least for now). Hopefully this sounds like it could run fast enough.

Any tips? This is purely theoretical details of implementation, and not a project per se ... yet.

The TLDR version of my answer: It'd be a ton of work and will probably never happen. Runer112 has said that a color version (84+CSE)is planned, but no telling when that will be. This would probably be the most feasible and most likely to happen. The bottom line is that all of these calculators are designed very differently. What might be good practice on one model (from a programming standpoint) might be bad practice and hard to implement on another. The 83+/84+ family uses a Z80, the nspire and HP Prime use ARM (but are designed differently and with different clock speeds and graphical handling capabilities), and the CG10 is SH4. That's the least of their differences. It also wouldn't make sense for the higher models to have b/w or grayscale graphics mode as there would be no real benefit. The half res. mode also has no use except on the84+SE to gain some speed when displaying stuff on the screen.

If the thing you're most interested in is a version for the 84+CSE, you might want to head over to Omnimaga and ask Runer112 about it. That be the best person to ask and the most direct answer you could get.


*Edit* There actually was kind of an attempt at this in the past with a language called MLC or MCL(can't remember which it was called) IIRC. It was to be for CASIO models and the TI-Z80 models. The CASIO version got fairly far, and the Z80 version (for the TI-86) was in a somewhat working state. None of the other version ever surfaced, but there was one for the TI-83+ in the works at one time as well.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 04, 2015, 09:40:50 PM
I think that from a portability standpoint, the lesser graphics modes (aka 84 mode) are a benefit because they'd allow easier porting of existing programs. And you'll recall that this is all theoretical anyway.

But, if axe could be written once, it can be written again. Maybe I'll do some work on a C version.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Yuki on January 04, 2015, 10:00:00 PM
Well, yeah, there's probably nothing that prevents you to do your own reimplementation of Axe if you wanted to.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: TIfanx1999 on January 04, 2015, 10:04:06 PM
Quote from: Agothro on January 04, 2015, 09:40:50 PM
I think that from a portability standpoint, the lesser graphics modes (aka 84 mode) are a benefit because they'd allow easier porting of existing programs. And you'll recall that this is all theoretical anyway.

But, if axe could be written once, it can be written again. Maybe I'll do some work on a C version.

This is true, but then you would not be taking advantage of the target platform at all. In that case, the game would likely compare poorly from a graphical standpoint to others that were designed for the said platform.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 04, 2015, 10:14:52 PM
Quote from: Art_of_camelot on January 04, 2015, 10:04:06 PM
Quote from: Agothro on January 04, 2015, 09:40:50 PM
I think that from a portability standpoint, the lesser graphics modes (aka 84 mode) are a benefit because they'd allow easier porting of existing programs. And you'll recall that this is all theoretical anyway.

But, if axe could be written once, it can be written again. Maybe I'll do some work on a C version.

This is true, but then you would not be taking advantage of the target platform at all. In that case, the game would likely compare poorly from a graphical standpoint to others that were designed for the said platform.

I acknowledge this, there would be better ways to design a new game (perhaps with another theoretical graphics mode or with another toolkit), this is mainly concerning porting existing games to a playable format.

Quote from: Juju on January 04, 2015, 10:00:00 PM
Well, yeah, there's probably nothing that prevents you to do your own reimplementation of Axe if you wanted to.

Yep, that's what this is about.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dark Storm on January 04, 2015, 10:17:42 PM
I have some questions about Axe Parser and this possible support for Casio calcs.

Axe is an interpreted language like Basic? Or semi-compilated like Lua? Or full-compilated ?
In case of a FxCG10/20 support, remember that calc has few RAM, so it could be a limitation.
If Axe is an interpreted language, and if members (Lephenixnoir, ...) of PC success to make a grayscale engine for 9860 series, I can try to make support of Axe. As the screen is 128x64, we have enough place to draw all.

I think that Axe support could be great on Casio calculators, there are lot of games written in Axe. :)
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 04, 2015, 10:45:05 PM
Quote from: Dark Storm on January 04, 2015, 10:17:42 PM
I have some questions about Axe Parser and this possible support for Casio calcs.

Axe is an interpreted language like Basic? Or semi-compilated like Lua? Or full-compilated ?
In case of a FxCG10/20 support, remember that calc has few RAM, so it could be a limitation.
If Axe is an interpreted language, and if members (Lephenixnoir, ...) of PC success to make a grayscale engine for 9860 series, I can try to make support of Axe. As the screen is 128x64, we have enough place to draw all.

I think that Axe support could be great on Casio calculators, there are lot of games written in Axe. :)

Axe is a fully-compiled language if I recall correctly, but I could be wrong. Either that or semi-compiled.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: TIfanx1999 on January 05, 2015, 12:14:02 AM
Axe is fully compiled. If someone were to make a version of it they'd need to be very familiar with SH4 assembly for the Casio Prizm and newer 9860's. If they wanted compatibility for the older models they'd need to be familiar with whatever processor those models use as well (SH3?). As I said though, I think it's pretty unlikely.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: aetios on January 05, 2015, 01:03:26 AM
It's probably possible to write Axe for the Nspire/Prime/somecasiocalc. Thing is however that the whole Axe syntax is centered around how things work on the z80 and also around how input works on the 84 series, namely using tokens.
That said I can't do anything but applaud a port/reimplementation of Axe to another platform :D
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 05, 2015, 01:20:49 AM
Quote from: Art_of_camelot on January 05, 2015, 12:14:02 AM
Axe is fully compiled. If someone were to make a version of it they'd need to be very familiar with SH4 assembly for the Casio Prizm and newer 9860's. If they wanted compatibility for the older models they'd need to be familiar with whatever processor those models use as well (SH3?). As I said though, I think it's pretty unlikely.

I could perhaps write a version in C. Do you think that'd work with an nspire?
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: TIfanx1999 on January 05, 2015, 04:46:59 AM
The nspire does support C yes, but asm would be more optimized.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 05, 2015, 05:28:15 AM
I would say that maybe there could be a brand new Axe utilizing an identical syntax and use a computer for compiling to multiple platforms simultaneously, but on the side, someone could write a 83+ Axe to 84+CSE Axe program converter for people who just want to play older games on their color model. Actually, there could even be a converter for other calcs with no speed restrictions and the option to scale graphics up.

This is a mockup of my idea:
(https://img.ourl.ca/ssb-5.gif) (https://img.ourl.ca/ssb-6.gif)

The first would basically be 96x64 spanning across 96x128 on 160x240, while the second one would be 288x64 spanning across 288x192 on 320x240.
However, this example is a 6 MHz game. Even with the Full command I doubt a CSE version would run at 100% speed, which is why I slowed down the modified screenshots above to 12 FPS instead of about 18. Perhaps the first, especially considering it's in half-res mode, would run closer to original game speed.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 05, 2015, 05:52:17 AM
Quote from: DJ Omnimaga on January 05, 2015, 05:28:15 AM
I would say that maybe there could be a brand new Axe utilizing an identical syntax and use a computer for compiling to multiple platforms simultaneously, but on the side, someone could write a 83+ Axe to 84+CSE Axe program converter for people who just want to play older games on their color model. Actually, there could even be a converter for other calcs with no speed restrictions and the option to scale graphics up.

This is a mockup of my idea:
(https://img.ourl.ca/ssb-5.gif) (https://img.ourl.ca/ssb-6.gif)

The first would basically be 96x128 on 160x240, while the second one would be 288x192 on 320x240.
However, this example is a 6 MHz game. Even with the Full command I doubt a CSE version would run at 100% speed, which is why I slowed down the modified screenshots above to 12 FPS instead of about 18. Perhaps the first, especially considering it's in half-res mode, would run closer to original game speed.


Nice mockup, matches my idea. Any reason to keep scanlines?
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 05, 2015, 05:54:08 AM
Because by only drawing every two row of pixels, it doubles rendering speed. Remember that on a CSE, filling the entire 320x240 screen with just 1 single color takes approximately 0.25 seconds, meaning 4 images/seconds. My game runs at 20 FPS on the 6 MHz 83+.

Plus we have to take both rendering and game code speed into account anyway (for example, if this game was 288x192 with no scanlines and ran at 15 MHz on a color model, it would probably run at 8-10 FPS)
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Agothro on January 05, 2015, 06:19:09 AM
Quote from: DJ Omnimaga on January 05, 2015, 05:54:08 AM
Because by only drawing every two row of pixels, it doubles rendering speed. Remember that on a CSE, filling the entire 320x240 screen with just 1 single color takes approximately 0.25 seconds, meaning 4 images/seconds. My game runs at 20 FPS on the 6 MHz 83+.

Plus we have to take both rendering and game code speed into account anyway (for example, if this game was 288x192 with no scanlines and ran at 15 MHz on a color model, it would probably run at 8-10 FPS)

So do you just write differences to screen or the whole image?
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 05, 2015, 06:32:25 AM
Differences to screen. The black rows remains untouched. When you draw a 8x8 sprite, it just spaces its 8 rows out.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Keoni29 on January 05, 2015, 08:02:38 AM
The graphics problem could be tackled by making a graphics layer for every calc. The cpu problem can be solved by using an interpreted language such as Forth.

These solutions will always be slower than native code.

That said: some games do not require speed. An example is a Z-machine which interprets text adventures.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dark Storm on January 05, 2015, 10:11:44 PM
Quote from: Art_of_camelot on January 05, 2015, 12:14:02 AM
Axe is fully compiled. If someone were to make a version of it they'd need to be very familiar with SH4 assembly for the Casio Prizm and newer 9860's. If they wanted compatibility for the older models they'd need to be familiar with whatever processor those models use as well (SH3?). As I said though, I think it's pretty unlikely.
Ok, so I know why it's hard to make support for other calcs. I haven't enough skills in ASM, so Prizm should wait before see Axe games on it. :(

In other hand, I've so many projects to finish, Arcuz, MMGOC, my Web browser (with Lephenixnoir's engine), Calc Center, Serial support for FiXos, the list is very long ^^
I need a new laptop, and quick (my old is dead :( )
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Keoni29 on January 05, 2015, 10:15:22 PM
I also have way too many projects going on, but I don't work on them simultaneously. It's easy to get distracted and never get anything done. It's best to work on a project for a few days and if you get stuck move on to the next project and work on that for a while. Eventually you will bring the amt. of projects back to a reasonable number and you can maybe start learning assembly language on the side.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 05, 2015, 11:40:30 PM
Quote from: Keoni29 on January 05, 2015, 08:02:38 AM
The cpu problem can be solved by using an interpreted language such as Forth.

If such Axe compiler supported the HP Prime or Ndless, I doubt that CPU would be much of a problem, considering those calcs are 400 and 150 MHz respectively (assuming the HP Prime was opened to ASM dev and that the program wasn't HP PPL, but even in HP PPL it might still be fast enough)
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Duke "Tape" Eiyeron on January 06, 2015, 10:44:04 PM
Quote from: Dark Storm on January 05, 2015, 10:11:44 PM
Quote from: Art_of_camelot on January 05, 2015, 12:14:02 AM
Axe is fully compiled. If someone were to make a version of it they'd need to be very familiar with SH4 assembly for the Casio Prizm and newer 9860's. If they wanted compatibility for the older models they'd need to be familiar with whatever processor those models use as well (SH3?). As I said though, I think it's pretty unlikely.
Ok, so I know why it's hard to make support for other calcs. I haven't enough skills in ASM, so Prizm should wait before see Axe games on it. :(

In other hand, I've so many projects to finish, Arcuz, MMGOC, my Web browser (with Lephenixnoir's engine), Calc Center, Serial support for FiXos, the list is very long ^^
I need a new laptop, and quick (my old is dead :( )

Why isn't FiXOS the first of your list? >:|
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 06, 2015, 11:16:47 PM
It could be because it will have fewer users than the official OS since not as many people are aware that it exists. Also, many people might like to switch to a custom OS that is better than the official Casio OS, but still want to use the official OS too in order to run their favorite BASIC and ASM/C games, so until it supports dual-booting, it will probably take a while after being finished that it reaches a significant userbase (a much faster BASIC interpreter or Axe language would be an huge seller, though). I really hope it gets finished, though, same for KnightOS 84+.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Duke "Tape" Eiyeron on January 07, 2015, 07:03:14 AM
(It was just because the project stalled for too much time that I wanted it to get a littlw nudge, not because the user base).
It's a shame that we won't have something like Axe on another platforms. It's holy useful.
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 07, 2015, 07:37:24 AM
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.
Title: Hello, mine turtle.
Post by: Duke "Tape" Eiyeron on January 07, 2015, 10:08:36 AM
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)
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 07, 2015, 04:57:03 PM
Wait wouldn't that slow the rest of the basic code down? ???
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Duke "Tape" Eiyeron on January 07, 2015, 10:32:21 PM
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)
Title: Re: [Purely Theoretical] Reimplementation of Axe
Post by: Dream of Omnimaga on January 08, 2015, 03:03:43 AM
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)
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 11, 2015, 08:01:15 AM
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:

http://chat.eeems.ca/?server=irc.omnimaga.org%206667&channel=omnimaga&date=Wed%20Sep%2030%202015#1443648292033

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.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 11, 2015, 08:17:15 AM
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.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on October 11, 2015, 08:39:01 AM
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...
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Snektron on October 11, 2015, 10:17:27 AM
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 https://en.wikipedia.org/wiki/Shunting-yard_algorithm, that would allow it to have proper precedence too <_<. The benefit of TI is that it automatically has a line delimiter though.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 11, 2015, 10:29:41 AM
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.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on October 11, 2015, 03:25:12 PM
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.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Snektron on October 11, 2015, 03:28:03 PM
Indeed. I suspect axe of resetting its stack after every newline anyway
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: 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?
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: c4ooo on October 11, 2015, 06:12:50 PM
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.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 11, 2015, 06:22:57 PM
@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).
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on October 11, 2015, 06:41:31 PM
Quote from: DJ Omnimaga on October 11, 2015, 06:22:57 PM
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).
MaCE :P
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 11, 2015, 06:47:55 PM
Quote from: DJ Omnimaga on October 11, 2015, 06:22:57 PM
@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.
On the contrary one could argue that Axe looking like TI-BASIC at first sight is confusing for beginners. And in practice it really is, that's why there are endless help threads on Omni with people posting code that works in BASIC but is totally wrong in Axe. When I learned Axe, I was aware it was different and approached it as a totally new language. I had a little bit of ASM experience which helped me a lot understanding some concepts much more than my BASIC knowledge.

For the CSE, relatively few changes are needed to allow Axe to run on them. Mostly OS-related stuff (adapt to the new romcalls) and graphics (new LCD driver, so it needs something like Xlib functions to work).

Axe can be more confusing than C for beginners because C has much stricter syntax, Axe is extremely loose on what it allows as shown by the many hacks that were made. You can write an instruction that is impossible to understand yet it will still do something useful.

I don't think Lua would be interesting on the CE mostly for performance reasons. At best it would be a little faster than hybrid BASIC (not sure how fast the BASIC interpreter is on the CE, but I hope they made it better than the old one). Keep in mind the CE has very limited resources, it's definitely not an Nspire.

Also yes, new name. Completely different thing or not it still won't be Axe, so whatever happens it shouldn't be called Axe. (Ninja-edit: Lol Hayleia, nice name).
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 11, 2015, 07:03:36 PM
Well my reasoning is that for many calculator programmers, TI-83+ BASIC is their first ever venture into programming. My guess is that when they stick with TI-BASIC for so long, they gain bad habits of thinking that every other language will work or look the same way, because the syntax is way smaller, probably due to the screen only showing 16x8 characters.

And while Axe works differently than BASIC, some of the syntax allows you to do the same thing on the surface. For example, if you want to erase the screen content then display a pixel at (27,43) coordinate, then all you need to change in Axe is swapping both coordinates then adding a DispGraph command at the end. It,s more the internal stuff overall that is different, like how in BASIC you store stuff into variables, while in Axe they are pointers.

And while I think that Lua would be much slower than ASM/C on the CE, I doubt it would be as bad as hybrid TI-BASIC. Nspire Lua now rivals HP Prime language in speed, after all, and I doubt that xLIBC-enhanced BASIC on the CE will even come close to that (although it will be much faster than on the CSE).



Quote from: Hayleia on October 11, 2015, 06:41:31 PM
Quote from: DJ Omnimaga on October 11, 2015, 06:22:57 PM
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).
MaCE :P
WalriiCode? :P
Title: Re: About porting Axe Parser to color calculators
Post by: c4ooo on October 11, 2015, 11:15:57 PM
Quote from: DJ Omnimaga on October 11, 2015, 07:03:36 PM
Well my reasoning is that for many calculator programmers, TI-83+ BASIC is their first ever venture into programming. My guess is that when they stick with TI-BASIC for so long, they gain bad habits of thinking that every other language will work or look the same way, because the syntax is way smaller, probably due to the screen only showing 16x8 characters.

And while Axe works differently than BASIC, some of the syntax allows you to do the same thing on the surface. For example, if you want to erase the screen content then display a pixel at (27,43) coordinate, then all you need to change in Axe is swapping both coordinates then adding a DispGraph command at the end. It,s more the internal stuff overall that is different, like how in BASIC you store stuff into variables, while in Axe they are pointers.
Well, as long as you remember that cars are a number from -2^15-1 to 2^15, and that 2^16-1=-1, and that there is no floating point operations, then you could just program as you would in basic. Albeit you will never get far :P

Originally I considered axe as a faster version of basic, but then I changed my mentality to thinking of it as a slower and less optimized version of assembly, and got better results ;)

Quote from: DJ Omnimaga on October 11, 2015, 06:22:57 PM
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).
I don't think so. The CE is still pretty similar to 84 :P

Edit:
Quote from: Streetwalrus on October 11, 2015, 06:47:55 PM
Axe can be more confusing than C for beginners because C has much stricter syntax, Axe is extremely loose on what it allows as shown by the many hacks that were made. You can write an instruction that is impossible to understand yet it will still do something useful.

WHLine(Y/8*8-Y+31->E,X/8*8-X+47->D,+9)
WHLine(E+9,D,+9)
WVLine(D,E,+9)
WVLine(D+9,E,+9)

:trollface:
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 12, 2015, 01:02:03 AM
Wait, what does WVLine do?

Also by differences over the 84+, I meant the color screen and its resolution. The RAM areas also moved and stuff and the hardware is a bit different, so you can't just take Axe then port it straight to the CE without any modification. It just won't work.


Also with the argument about Axe being more slower than ASM but easier rather than a faster version of BASIC, I see it more as both. People who are serious about programming will go farther than just the BASIC-like syntax, but at least people who just don't want to deal with all the technical stuff can still enjoy the beginner's Axe stuff without any problem. That's what made Axe great IMHO: It reached a much larger audience than TI-BASIC, ASM and C's respective audiences. On top of that, games produced with it reached an audience similar to ASM and C, because most games either required no dependency or just required a shell in order to run, while hybrid BASIC and Grammer games requires an extra app (although the xLIB dependencies are solved with DCS7 and DCSE now, which also includes a shell, so the extra app requirement argument was rendered moot)
Title: Re: About porting Axe Parser to color calculators
Post by: Yuki on October 12, 2015, 04:22:43 AM
Someone should just make a brand new language similar to Axe but on the color calcs and with most of the benefits Axe has you mentioned.

Do one of such things and you'll be considered a hero in the community.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 12, 2015, 04:53:39 AM
IMHO, because such project would be too big for anyone without years of experience in programming, I think that the language should be simple at first, but complete enough to allow arcade games. Axe really started taking off around version 0.0.5. It added sprite support but was still simple. Later, more features can be added. It might be nice also to just keep it simple even late into development too, just so it won't become bloated and take several minutes to compile. It would also remain easy for beginners to learn.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Snektron on October 12, 2015, 12:22:49 PM
The fact that there isn't a proper emulator yet doesn't help though <_<
Even an eZ80 emulator would be okay, just SOMETHING to run code on...
I found the simulator in ZDS, but that isn't really great either...
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 12, 2015, 02:57:32 PM
Quote from: DJ Omnimaga on October 12, 2015, 01:02:03 AM
Also by differences over the 84+, I meant the color screen and its resolution. The RAM areas also moved and stuff and the hardware is a bit different, so you can't just take Axe then port it straight to the CE without any modification. It just won't work.
I believe there are more differences than just that. On the CSE it's just a slightly different OS and a new screen, on the CE there is a new CPU so it's probably a very different architecture altogether.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Snektron on October 12, 2015, 03:12:00 PM
Well, it does support z80 mode, and there are rumors its faster in that mode. I don't know if that will be a viable option though. If there will be something for CE it should use the 24 bit capabillities too while its at it.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 12, 2015, 03:18:25 PM
z80 mode might have more IPC but there are obvious advantages in being able to do 24 bit operations instead of 8/16 bit (a lot of 16 bit stuff requires multi precision on the z80 since it's designed as an 8 bit CPU).
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: c4ooo on October 12, 2015, 06:58:30 PM
@DJ Omnimaga VLine(x) draws a vertical line from y=0 to y=63 at x. Vline(x,Y1,Y2) draws a vertical from y1 to y2 at x. Repacing 'V' with 'H' will make it draw a horizontal line, and the 'W' or 'I' prefix tells it to draw a white or inverted line.

@ben_g since you wanted to look at obfuscated axe code, this is the most obfuscated thing i have ever written: (note, to prevent confusion hexadecimals are writen with leading "0x")
[spoiler]

Lbl loadlevel
{strSelected}->A
0->M->X->E
While 1
{X+++Y1}->B
!if M
  if B=0xFF
   !if A--
    {str1Levelptr}^r-1->A
    Select({X++++Y1},/16->W*8+52->N) and 0xF->H*8+36->O
   End
  End
ElseIf M=1
  B->{A++}
  !if {A}
   2->M
  End
ElseIf M=2
  if B=0xFF
   A+1-({A}=0xF)->{StrLazers}^r
   Return
  End
Select(B, and 0xF0/16 Parse()) and 0xF
Parse()
End
End
Lbl Parse
->D->{A++}
If E
For(D)
  0->{A}
  A++
End
A-2->A
0->E
Else
!If D
  1->E
End
End
Return

[/spoiler]
It basicly loads and uncompresses the levels in lazer. Its made comfusing becouse it first has to find a pointer to the reqested level, extract width and height data(and pre calculate some stuff), copy the name with excactly, then finaly uncompress the level, which uses 4-bits per tile, plus if there is a zero in the compressed level data, that means that the  next four bits dictate how many air tiles to insert. So yea :P
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: TheMachine02 on October 13, 2015, 01:51:31 PM
Quote from: Streetwalrus on October 12, 2015, 03:18:25 PM
z80 mode might have more IPC but there are obvious advantages in being able to do 24 bit operations instead of 8/16 bit (a lot of 16 bit stuff requires multi precision on the z80 since it's designed as an 8 bit CPU).

z80 mode have more ipc, mainly due to the same 16bit vs 8bit z80 issue and added RAM wait state.
The z80 is initially a (internally) 4 bit processor, calculating natively in 8 bit by doing two math pass. 16 bit use 4 pass, wich is why it is tremdemlousy slow. The ez80 is a (internally) 8 bit processor, using 2 math pass for 16 bits, 3 for 24 bits. 24 is faster than the 16 bits z80, but it still inherit the added TStates. Furthermore, each RAM acess add 4 wait States ( 2 if the acess is in video ram), and 24 bit stuff need 3 acess vs 2 for 16 bit. So yeah. Kinda creppy. Altough the optimization porcess really need a redefinition.


I was kinda interested in programming in ez80 asm, and maybe I will take this project, but don't count on this too much. I want to finish gLib and I need to buy a 83PCE.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 15, 2015, 05:30:35 AM
I wonder if a new Axe language would suffer speed-wise if it was written in C instead of ASM? And thanks c4ooo
Title: Re: About porting Axe Parser to color calculators
Post by: Lionel Debroux on October 15, 2015, 05:40:03 AM
QuoteI wonder if a new Axe language would suffer speed-wise if it was written in C instead of ASM?
Probably, yes.
While the eZ80's instruction set is somewhat more suitable for C than the original Z80 instruction set, it's far less so than, say, the 68000 and ARM9 instruction sets (let alone newer members of those series), which were designed with C in mind. There's no decent C compiler for the Z80 and eZ80 series, all compilers (including Zilog's) support only old dialects of C and/or generate bad code.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 15, 2015, 05:47:53 AM
Sorry to hear. :( I was sure that ez80 C was at least on-par with TI-Nspire and 68K C when compared to ARM and 68K ASM.

Now that is one other thing that gives a good argument about the need of Axe for the TI-84+CE, though. Axe was created with the Z80 limitations in mind.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 15, 2015, 07:11:41 AM
Quote from: TheMachine02 on October 13, 2015, 01:51:31 PM
z80 mode have more ipc, mainly due to the same 16bit vs 8bit z80 issue and added RAM wait state.
The z80 is initially a (internally) 4 bit processor, calculating natively in 8 bit by doing two math pass. 16 bit use 4 pass, wich is why it is tremdemlousy slow. The ez80 is a (internally) 8 bit processor, using 2 math pass for 16 bits, 3 for 24 bits. 24 is faster than the 16 bits z80, but it still inherit the added TStates. Furthermore, each RAM acess add 4 wait States ( 2 if the acess is in video ram), and 24 bit stuff need 3 acess vs 2 for 16 bit. So yeah. Kinda creppy. Altough the optimization porcess really need a redefinition.


I was kinda interested in programming in ez80 asm, and maybe I will take this project, but don't count on this too much. I want to finish gLib and I need to buy a 83PCE.
Don't forget that the ez80 is a pipelined CPU. Indeed the ALU is 4 or 8 bits but that's not the only thing. :) An instruction that takes more than one cycle (basically every instruction) will allow the next one to start executing while it finishes.

Quote from: Lionel Debroux on October 15, 2015, 05:40:03 AM
Probably, yes.
While the eZ80's instruction set is somewhat more suitable for C than the original Z80 instruction set, it's far less so than, say, the 68000 and ARM9 instruction sets (let alone newer members of those series), which were designed with C in mind. There's no decent C compiler for the Z80 and eZ80 series, all compilers (including Zilog's) support only old dialects of C and/or generate bad code.
That's another good reason to have a custom language. I think that writing the compiler itself in C could be a good idea to allow running it on a PC as well as a calc though. In the end I gave up programming in Axe because it was only editable on-calc, even though that was one of my main reasons to start using it. More flexibility is better. :)
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: TheMachine02 on October 16, 2015, 04:52:34 PM
Quote from: Streetwalrus on October 15, 2015, 07:11:41 AM
Don't forget that the ez80 is a pipelined CPU. Indeed the ALU is 4 or 8 bits but that's not the only thing. :) An instruction that takes more than one cycle (basically every instruction) will allow the next one to start executing while it finishes.

Yes and no, and it doesn't change the fact that z80 mode is faster than ez80 mode. It allow indeed instruction fetch and decode before the previous instruction is finished to be executed, making ipc (theorically) x3 bigger. However, RAM wait state made the pipeline even more trickier and 'hide' it's advantage, as fetching the instruction add wait state,  without loosing the bad call/jump fetch problem (it need to flush the pipeline). And the pipeline IS active in z80 mode. It is just adressing change to have compatibility. ez80 'z80 mode' is far more superior to physical z80 in terms of ipc.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 17, 2015, 06:04:11 AM
Streetwalrus, actually you can edit Axe on the computer too, using SourceCoder or Tokens. But saving in Tokens is not always ideal since CTRL+S doesn't create a 8xp, but rather a text file with the source. Not ideal when editing many programs at once.

Also I didn't know that ez80's Z80 mode had pipelining.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 18, 2015, 01:09:39 PM
Quote from: DJ Omnimaga on October 17, 2015, 06:04:11 AM
Streetwalrus, actually you can edit Axe on the computer too, using SourceCoder or Tokens. But saving in Tokens is not always ideal since CTRL+S doesn't create a 8xp, but rather a text file with the source. Not ideal when editing many programs at once.
Yeah but compiling. You need a calc or an emulator to compile Axe programs. It's possible to automate an emulator to transfer the file and compile the program automatically but that's a pretty hacky setup.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on October 18, 2015, 01:33:33 PM
Quote from: Streetwalrus on October 18, 2015, 01:09:39 PM
Yeah but compiling. You need a calc or an emulator to compile Axe programs. It's possible to automate an emulator to transfer the file and compile the program automatically but that's a pretty hacky setup.
That's hacky if you want, but you have to admit that in the end, it's even really convenient since you can choose your text editor and compile faster than on calc :P
So it almost looks like an IDE where you only have to press a button to compile and run.
Title: Re: About porting Axe Parser to color calculators
Post by: novenary on October 18, 2015, 02:37:34 PM
Yeah but I'm too lazy to set it up. :P
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 27, 2015, 08:14:13 PM
Quote from: Streetwalrus on October 18, 2015, 01:09:39 PM
Quote from: DJ Omnimaga on October 17, 2015, 06:04:11 AM
Streetwalrus, actually you can edit Axe on the computer too, using SourceCoder or Tokens. But saving in Tokens is not always ideal since CTRL+S doesn't create a 8xp, but rather a text file with the source. Not ideal when editing many programs at once.
Yeah but compiling. You need a calc or an emulator to compile Axe programs. It's possible to automate an emulator to transfer the file and compile the program automatically but that's a pretty hacky setup.
Do you mean with KnightOS or TilEm? Because I doubt that Wabbit and jsTIfied supports that.
Title: Re: About porting Axe Parser to color calculators
Post by: Ivoah on October 27, 2015, 08:16:36 PM
Quote from: DJ Omnimaga on October 27, 2015, 08:14:13 PM
Quote from: Streetwalrus on October 18, 2015, 01:09:39 PM
Quote from: DJ Omnimaga on October 17, 2015, 06:04:11 AM
Streetwalrus, actually you can edit Axe on the computer too, using SourceCoder or Tokens. But saving in Tokens is not always ideal since CTRL+S doesn't create a 8xp, but rather a text file with the source. Not ideal when editing many programs at once.
Yeah but compiling. You need a calc or an emulator to compile Axe programs. It's possible to automate an emulator to transfer the file and compile the program automatically but that's a pretty hacky setup.
Do you mean with KnightOS or TilEm? Because I doubt that Wabbit and jsTIfied supports that.

Wabbit has scripting abilities, you can use it like a dll or something. Geekboy was showing it off in HCWP one night, also, what does this have to with KOS?
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 27, 2015, 08:18:03 PM
Oh I didn't know that. It didn't seem to have such feature in the menus. As for KOS I meant the emulator, not the OS. My bad.
Title: Re: About porting Axe Parser to color calculators
Post by: Adriweb on October 27, 2015, 08:18:23 PM
(z80e is the name)
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on October 27, 2015, 08:20:07 PM
Ah right, I always forget it. I once even said ez80 or calcemu lol.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 30, 2016, 07:00:53 PM
Bump:

So lately, there was some discussion again about porting Axe to the TI-84 Plus CE, especially now that @c4ooo has a TI-84 Plus CE, but for unknown reasons, the ones involved seems to insist on keeping that discussion exclusive to IRC, at the expense of forums where all the ideas would remain easy to search, such as this topic or the Axe sub-forum on Omni. So I'm bumping this to encourage people to share ideas they had or if they are interested in porting Axe themselves, and debate about which direction a CE port of Axe should take.

I think Axe CE should be a community project. It can be worked on by 1 person or more, it doesn't matter, but I think it should be open-source, so that everyone can help at will if they wish to, and continue the project easily if the original porter abandons the idea. I also think that regardless of if some people are against Axe CE, the project should happen anyway. It's up to the port author's discretion, though, but I'M giving suggestions here.

I also think that we should take the CW/CEmu/Cesium approach of starting this project without the original author, rather than waiting forever to see if the original author is gonna do it himself.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on March 30, 2016, 08:43:53 PM
I thought about something (not really an idea or anything but whatever).

What do we want Axe on CE for ?
1) port monochrome games to CE
2) on calc language
3) fill the gap between Basic and Asm

Point 3 is defeated by C.
Point 2 can be fulfilled with @PT_'s ICE
So only point 1 matters that much right ?

Well then, this means that Axe for CE doesn't have to be an on-calc compiler. It could be a compiler on PC that could compile for CE, or even cross-compile for CE and monochrome. This way, it fills the main goal without being annoyed with useless burdens, and it even has the potential to satisfy people who wanted an Axe compiler on PC from the beginning.
Plus, maybe some people are more experienced with programming on PC, so they would be more interested in contributing for a compiler on PC than for a compiler on calc ?

And then, maybe in the future it could become a big thing and a "real langage" not only used on calculators, for example compiled to bytecode and running in a VM similarly to Java. Yeah, why not dream and see big ? :P

And it would solve the "hacky setup" problem mentionned by @Streetwalrus earlier in that thread :P
Title: Re: About porting Axe Parser to color calculators
Post by: Ivoah on March 30, 2016, 08:45:24 PM
Quote from: Hayleia on March 30, 2016, 08:43:53 PM
Point 2 can be fulfilled with @PT_'s ICE
I think ICE is compiled on a computer. He said he was going to write it in PHP.
Title: Re: About porting Axe Parser to color calculators
Post by: PT_ on March 30, 2016, 08:46:43 PM
Quote from: Ivoah on March 30, 2016, 08:45:24 PM
Quote from: Hayleia on March 30, 2016, 08:43:53 PM
Point 2 can be fulfilled with @PT_'s ICE
I think ICE is compiled on a computer. He said he was going to write it in PHP.
Version 1 will be in PHP, but I'm working on version 2.0, which will be in ASM :) (and even designing a frontpage + writing a documentation pdf :D)
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on March 30, 2016, 08:53:45 PM
Quote from: Ivoah on March 30, 2016, 08:45:24 PM
Quote from: Hayleia on March 30, 2016, 08:43:53 PM
Point 2 can be fulfilled with @PT_'s ICE
I think ICE is compiled on a computer. He said he was going to write it in PHP.
What the above post said :P
But even if it were computer only, the other points in my suggestion (like the fact people may agree to help more on a PC project than on a calculator project) are to be considered maybe.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 30, 2016, 09:03:50 PM
Quote from: Hayleia on March 30, 2016, 08:43:53 PM

3) fill the gap between Basic and Asm

Point 3 is defeated by C.
Not really @Hayleia . Certain people who liked Axe dislikes C or found it much more difficult to learn (it depends of what they wanted to do with Axe, though). So no, the gap between Basic and ASM isn't filled completely. I believe that even yourself mentionned in the past that you prefered Axe to C by a large margin. Whether C bridges the gap or not is a matter of opinion, and I think that Axe programmers who finds C too hard should be considered.

As for if ICE or a new Axe should be on-calc or not, it depends. Having no on-calc compiler would defeat the point of on-calc programming capabilities, but on the other hand, fewer and fewer people program on-calc, especially considering how slow the CE BASIC editor is compared to monochrome calculators (you can only type 4 characters per second at the top of the screen). A PC compiler would be very handy, because you would just need to export to 8xp with TokenIDE or SourceCoder 3 or save the code, then all you have to do is run your code or the 8xp source through a compiler, and voilĂ .

As for why I brought up this topic again despite the arrival of ICE, it's because certain people said they wanted Axe syntax and nothing else. I think that it would be fine if both languages co-existed, though, but of course getting support would be harder since fewer people would use each of them.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on March 30, 2016, 09:08:20 PM
Quote from: DJ Omnimaga on March 30, 2016, 09:03:50 PM
Not really @Hayleia . Certain people who liked Axe dislikes C or found it much more difficult to learn. So no, the gap between Basic and ASM isn't filled completely. I believe that even yourself mentionned in the past that you prefered Axe to C by a large margin. Whether C bridges the gap or not is a matter of opinion, and I think that Axe programmers who finds C too hard should be considered.
Yes, I did mention I liked Axe better than C, and I still do :P
That's also why if my suggestion was completely done (with the bytecode compiler and interpreter on PC), I would be happy to code in Axe on for PC too, but as I said, maybe I dream too much :P

But yeah, I didn't mean "it completely fills the gap", more that unlike on the monochrome calcs, there isn't such a huge gap. At least some people, even though not all, can switch to C instead of having the choice between Basic and Asm.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 30, 2016, 09:18:09 PM
Ah ok, because it seemed your post said it completely filled the gap, which many people did in the past, based on their opinions. Sometimes I get the impression that certain community members wants advanced TI-84 Plus CE development to remain exclusive to C and ASM fans and shun out the rest.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on March 30, 2016, 10:18:49 PM
Quote from: DJ Omnimaga on March 30, 2016, 09:18:09 PM
Ah ok, because it seemed your post said it completely filled the gap, which many people did in the past, based on their opinions. Sometimes I get the impression that certain community members wants advanced TI-84 Plus CE development to remain exclusive to C and ASM fans and shun out the rest.
That's not my case, otherwise I would not have considered ICE for my point 2 :P
But then, I don't know what could have been considered there actually.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 31, 2016, 01:06:11 AM
Maybe if someone ever made an on-calc C editor and compiler like Mimas, but not for ASM. But then, you still have the issues I mentioned above, and it would most likely require a custom editor anyway. I remember in 2005 when MLC Beta came out for the TI-86 and it required typing special characters (because commands started with #). It was a nightmare to type anything. >.<
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: c4ooo on March 31, 2016, 01:22:28 AM
@Hayleia although a lang that compiles to PC and CE would be awesome and cool, it seems impractical to me. What could be done is an emulator geared not toward debugging, but towards the cinematic exposure of games.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 31, 2016, 01:24:18 AM
I am not sure what you mean by that c4ooo. Are you saying that Axe CE should be compilable only on-calc like the original and require PC users to use an emulator in order to compile their games? Or are you saying there should be an Axe emulator for the PC? (like Jacobly's monochrome Axe emu)
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: c4ooo on March 31, 2016, 01:32:08 AM
What ime saying is basically develop just for the calc alone, and release them for PC by packaging them with an emulator that will autoboot the game. However the emulator would not look like an emulator, but just like a native PC game. While TIOS is booting and the game being automatically executed, the emu could force the lcd to display like a splash screen or something so you dont actually 'see' the OS.

DR: the emu will emulate the compiled code and not the source.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on March 31, 2016, 01:34:26 AM
Oh I see now. The problem with that is that the user would still need a TI-84+CE ROM in order to run the PC game. That wouldn't be practical if the goal is to allow people to make PC games written in Axe.
Title: Re: About porting Axe Parser to color calculators
Post by: Hayleia on March 31, 2016, 08:02:29 AM
Quote from: c4ooo on March 31, 2016, 01:22:28 AM
@Hayleia although a lang that compiles to PC and CE would be awesome and cool, it seems impractical to me. What could be done is an emulator geared not toward debugging, but towards the cinematic exposure of games.
That's almost what I said. I didn't say the code would have to be completely compiled but that it would be some bytecode that could run from an interpreter or VM or whatever like Java. Integrating the emu into the program directly isn't a bad idea either. It would allow people to play the game without installing extra things. While not including the emulator would allow them to save space by having only one emulator to run all their programs. So maybe the two modes would be supported :P
And the bytecode in question would actually probably be exactly the 8xp file produced for calculators in the case of a setup that matches a calculator (I mean, if the compiler accepts resolutions higher than 320x240 "in PC mode", then we probably can't call that a calculator binary).

Quote from: DJ Omnimaga on March 31, 2016, 01:34:26 AM
Oh I see now. The problem with that is that the user would still need a TI-84+CE ROM in order to run the PC game. That wouldn't be practical if the goal is to allow people to make PC games written in Axe.
Not sure we would need a ROM actually. If the thing is only supposed to run the program so we don't need to run the TI-OS and stuff. Basically we just need a processor, some RAM, a screen and not even sure why we would need ROM memory (if we're running all that on a PC, we're not limited to 150Ko of RAM so we don't need to archive stuff to free RAM). The only problem is that bcalls would have to be rewritten I guess. But in that case, some kind of tweaked ez80 emu with no ROM other than the game could do the job.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: c4ooo on March 31, 2016, 11:01:17 AM
OS calls though. Idk, maybe the emu could detect when a call to the OS has acured, emulate it, and return.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Snektron on March 31, 2016, 12:31:40 PM
If this project is really going somewhere, i recommend using LEG (piumarta.com/software/peg/peg.1.html)
Its a parser generator that generates ANSI C code, so it is even possible to compile it for on-calc usage. I've actually started to experiment in it.
You can make a simple script language in less than a day, so a compiler doesn't take much work. The biggest problem i've had is making a language comfortable with the TI editor, which won't be a problem if you'd compile from PC.

Another thing that would be possible is some sort of unified bytecode language, something like LLVM but perhaps a bit simpeler (no other data type than ints for example),
for which it would be relatively easy to add (Z80-like) backends. The biggest problem with this would probably be some kind of library linker, since you'd ideally want to be able to add libraries for different platforms, though that may be possible through native code.

Maybe i'll try to make a tiny proof of concept language some time soon.

Also im still for @Hayleia's idea of calling it Mace :3
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: Dudeman313 on March 31, 2016, 09:29:38 PM
Quote from: Cumred_Snektron on March 31, 2016, 12:31:40 PM
If this project is really going somewhere, i recommend using LEG (piumarta.com/software/peg/peg.1.html)
Its a parser generator that generates ANSI C code, so it is even possible to compile it for on-calc usage. I've actually started to experiment in it.
You can make a simple script language in less than a day, so a compiler doesn't take much work. The biggest problem i've had is making a language comfortable with the TI editor, which won't be a problem if you'd compile from PC.

Another thing that would be possible is some sort of unified bytecode language, something like LLVM but perhaps a bit simpeler (no other data type than ints for example),
for which it would be relatively easy to add (Z80-like) backends. The biggest problem with this would probably be some kind of library linker, since you'd ideally want to be able to add libraries for different platforms, though that may be possible through native code.

Maybe i'll try to make a tiny proof of concept language some time soon.

Also im still for @Hayleia's idea of calling it Mace :3
"Mace" sounds awesome.  ;D  If you do it, can I make the title screen?
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on April 04, 2016, 06:32:15 PM
Quote from: Hayleia on March 31, 2016, 08:02:29 AM
Quote from: DJ Omnimaga on March 31, 2016, 01:34:26 AM
Oh I see now. The problem with that is that the user would still need a TI-84+CE ROM in order to run the PC game. That wouldn't be practical if the goal is to allow people to make PC games written in Axe.
Not sure we would need a ROM actually. If the thing is only supposed to run the program so we don't need to run the TI-OS and stuff. Basically we just need a processor, some RAM, a screen and not even sure why we would need ROM memory (if we're running all that on a PC, we're not limited to 150Ko of RAM so we don't need to archive stuff to free RAM). The only problem is that bcalls would have to be rewritten I guess. But in that case, some kind of tweaked ez80 emu with no ROM other than the game could do the job.
Many Axe commands rely on bcalls from the TI-OS to run. If Axe CE uses bcalls too, then it requires the TI-OS to run, hence why I brought up ROM requirements. The new Axe would need to not rely on any OS routine in order to be this portable, which could be a considerably larger amount of work.

Else, an emulator specific to Axe could be made, trying to emulate every command and stuff. @jacobly emulator actually used source rather than executables.
Title: Re: [theoretical][debate][TI-84+CE]About porting Axe Parser to color calculators
Post by: MateoConLechuga on April 04, 2016, 10:38:35 PM
I would love to see Axe on the color calculators :) Also, using system calls (I prefer to not refer to them as 'bcalls', because even though they technically are branching calls, it suggests they use the same rst method as the monochrome calculators, which they don't :P), is perfectly fine as long as it makes your life easier. Anywho, good luck!
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on April 04, 2016, 10:46:30 PM
Quote from: MateoConLechuga on April 04, 2016, 10:38:35 PM
Also, using system calls (I prefer to not refer to them as 'bcalls', because even though they technically are branching calls, it suggests they use the same rst method as the monochrome calculators, which they don't :P)
I was wondering about that too, but I couldn't figure out what the official name is. On the 82 Stats and old 83 I think they were ROM Calls and we had to use call instead of bcall.
Title: Re: About porting Axe Parser to color calculators
Post by: MateoConLechuga on April 04, 2016, 11:05:45 PM
Quote from: DJ Omnimaga on April 04, 2016, 10:46:30 PM
Quote from: MateoConLechuga on April 04, 2016, 10:38:35 PM
Also, using system calls (I prefer to not refer to them as 'bcalls', because even though they technically are branching calls, it suggests they use the same rst method as the monochrome calculators, which they don't :P)
I was wondering about that too, but I couldn't figure out what the official name is. On the 82 Stats and old 83 I think they were ROM Calls and we had to use call instead of bcall.
Yep, that's exactly how it is on the CE too :) ROM Calls works fine too.
Title: Re: About porting Axe Parser to color calculators
Post by: Dream of Omnimaga on April 05, 2016, 01:20:18 AM
Wait, do you mean the TI-84 Plus CE switched back to the old TI-83 format for TI routines? Note that in my posts, by TI-83, I am really talking about the TI-83 from 1996, not the TI-83 Plus from 1999. :P