* WalrusIRC

You need to have 5 posts and not be part of restricted usergroups in order to use the WalrusIRC embedded shoutbox. However, you can also access our IRC channel called #CodeWalrus via EFnet.

Author Topic: About porting Axe Parser to color calculators  (Read 13299 times)

0 Members and 1 Guest are viewing this topic.

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
About porting Axe Parser to color calculators
« 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?



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.
« Last Edit: October 11, 2015, 08:19:17 am by DJ Omnimaga »


...in America!
– Bandit Keith

Offline matrefeytontias

  • Full User
  • Join Date: Nov 2014
  • Location: France
  • Posts: 200
  • Post Rating Ratio: +5/-1
  • Axe metalhead of vengence
    • @matrefeytontias
    • matrefeytontias
    • matrefeytontias
  • Gender: Male
Re: Reimplementation of Axe
« Reply #1 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 :
  • BCALLs addresses vary between models.
  • RAM areas base addresses too.
  • DispGraph and friends have to be rewritten entirely for the CSE, and a special screen initialization and clean-up code must be put at the beginning and the end of the program. Fortunately, all of this already exists in a 100% usable form in the CSE version of KnightOS (here's what I'm talking about : setLegacyMode, resetLegacyMode and fastCopy respectively).
  • Z-Interval changes behavior and scrolls the screen horizontally. Of course, it needs to be rewritten. Actually, it's probably best left unsupported since the 96*64 virtual screen won't fit in the whole 320*240 physical screen, so it's gonna be ugly if the whole physical screen scrolls.
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.
  • Calculators owned: TI-83+.fr, TI-Nspire CAS prototype, TI-84+ CSE, TI-Nspire CX
My TI games (some got their own article on non-calc websites !) : http://www.ticalc.org/archives/files/authors/112/11202.html

My moozik (100% free metal) : http://www.soundcloud.com/matrefeytontias

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
Re: Reimplementation of Axe
« Reply #2 on: January 04, 2015, 07:35:39 pm »
It's perfectly possible if you completely reimplement from scratch, which is what I suggested.
...in America!
– Bandit Keith

Offline xlibman

  • Omni founder & CW co-founder
  • Super User
  • Original 5
  • CodeWalrus Supporter
  • *
  • Join Date: Nov 2014
  • Location: Quebec, Canada
  • Posts: 18795
  • Post Rating Ratio: +98/-4
    • dj_omnimaga
    • DJOmnimaga.music
    • @DJOmnimaga
    • dj_omnimaga
    • @DJOmnimaga
    • /u/DJ_Omnimaga
    • DJOmnimaga
    • 112/11286
    • @djomnimaga
    • @DJOmnimaga
    • DJ Omnimaga music store
  • Gender: Male
Re: Reimplementation of Axe
« Reply #3 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
  • Calculators owned: TI-57, 73, TI-80 (broken), TI-81, TI-82, TI-83, TI-83+ (broken), TI-83+ (broken), TI-83+SE (broken), TI-84+, TI-84+CSE, TI-84+CE, TI-85, TI-86, TI-89T, TI-92, TI-Nspire, TI-Nspire CX (semi-broken), HP 39gII, HP Prime, Casio fx-7000G, fx-7400G+, fx-7700GE, fx-9750G+, fx-9750GII, fx-9860G, cfx-9850G, FX-1.0+, fx-CG10, fx-CP400
  • Consoles, mobile devices and vintage computers owned: Samsung i5510, Nexus 5, Atari 2600, Lynx, SMS, Game Gear, Genesis, Dreamcast, NES, SNES, N64, GCN, Wii, Wii U, GBA, DS, 3DS, PS2, PS3, PS4, PSP, PSVita, XBox 360, XBOne

Bandcamp|Reverbnation|Facebook|Youtube|Twitter
Retired Omnimaga admin (2001-11) and editor (2012-14)

Online Juju

  • aka Yuki Kagayaki aka J̵̭͕͇ù̞̭̝̯̦j̴̭̙̗͖͡ù͏͓̲̕
  • CodeWalrus Staff
  • Super User
  • Server Maintenance
  • Moderator
  • Forum Maintenance
  • Original 5
  • CodeWalrus Supporter
  • *
  • Join Date: Nov 2014
  • Location: Inside a walrus
  • Posts: 3099
  • Post Rating Ratio: +30/-2
  • Couch potato
    • jul.savard
    • juju2143
    • @juju2143
    • juju2143
    • @julosoft
    • juju-kun
    • /u/juju2143
    • juju2143
    • @juju2143
    • Juju's shed
  • Gender: Female
  • WalriiPoints: 99999
Re: Reimplementation of Axe
« Reply #4 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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
On semi-hiatus until who knows when. CODEWALRUS 2.0 COMING SOON
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
Re: Reimplementation of Axe
« Reply #5 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.
...in America!
– Bandit Keith

Online Juju

  • aka Yuki Kagayaki aka J̵̭͕͇ù̞̭̝̯̦j̴̭̙̗͖͡ù͏͓̲̕
  • CodeWalrus Staff
  • Super User
  • Server Maintenance
  • Moderator
  • Forum Maintenance
  • Original 5
  • CodeWalrus Supporter
  • *
  • Join Date: Nov 2014
  • Location: Inside a walrus
  • Posts: 3099
  • Post Rating Ratio: +30/-2
  • Couch potato
    • jul.savard
    • juju2143
    • @juju2143
    • juju2143
    • @julosoft
    • juju-kun
    • /u/juju2143
    • juju2143
    • @juju2143
    • Juju's shed
  • Gender: Female
  • WalriiPoints: 99999
Re: Reimplementation of Axe
« Reply #6 on: January 04, 2015, 09:25:25 pm »
Yeah, a language should not be bound to one specific platform. Program once, port everywhere.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
On semi-hiatus until who knows when. CODEWALRUS 2.0 COMING SOON
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

Offline Art_of_camelot

  • Full User
  • Safe-haven access
  • Join Date: Jan 2015
  • Location: Dr. Light's Laboratory
  • Posts: 99
  • Post Rating Ratio: +1/-1
    • Omnimaga
Re: Reimplementation of Axe
« Reply #7 on: January 04, 2015, 09:30:22 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?



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.
« Last Edit: January 04, 2015, 10:05:33 pm by Art_of_camelot »

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
Re: Reimplementation of Axe
« Reply #8 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.
...in America!
– Bandit Keith

Online Juju

  • aka Yuki Kagayaki aka J̵̭͕͇ù̞̭̝̯̦j̴̭̙̗͖͡ù͏͓̲̕
  • CodeWalrus Staff
  • Super User
  • Server Maintenance
  • Moderator
  • Forum Maintenance
  • Original 5
  • CodeWalrus Supporter
  • *
  • Join Date: Nov 2014
  • Location: Inside a walrus
  • Posts: 3099
  • Post Rating Ratio: +30/-2
  • Couch potato
    • jul.savard
    • juju2143
    • @juju2143
    • juju2143
    • @julosoft
    • juju-kun
    • /u/juju2143
    • juju2143
    • @juju2143
    • Juju's shed
  • Gender: Female
  • WalriiPoints: 99999
Re: Reimplementation of Axe
« Reply #9 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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
On semi-hiatus until who knows when. CODEWALRUS 2.0 COMING SOON
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

Offline Art_of_camelot

  • Full User
  • Safe-haven access
  • Join Date: Jan 2015
  • Location: Dr. Light's Laboratory
  • Posts: 99
  • Post Rating Ratio: +1/-1
    • Omnimaga
Re: Reimplementation of Axe
« Reply #10 on: January 04, 2015, 10:04:06 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.
« Last Edit: January 04, 2015, 10:05:51 pm by Art_of_camelot »

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
Re: Reimplementation of Axe
« Reply #11 on: January 04, 2015, 10:14:52 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.

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.
...in America!
– Bandit Keith

Offline Dark Storm

  • Full User
  • Join Date: Dec 2014
  • Location: Lyon (France)
  • Posts: 23
  • Post Rating Ratio: +1/-0
    • Planète Casio
  • Gender: Male
Re: Reimplementation of Axe
« Reply #12 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. :)
French young Casio programmer.
If I do some (big) mistakes in english, could you correct me?

Offline Agothro

  • New User
  • Join Date: Jan 2015
  • Location: New York, New York
  • Posts: 15
  • Post Rating Ratio: +0/-0
  • Should probably be working right now
  • Gender: Male
Re: Reimplementation of Axe
« Reply #13 on: January 04, 2015, 10:45:05 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.
...in America!
– Bandit Keith

Offline Art_of_camelot

  • Full User
  • Safe-haven access
  • Join Date: Jan 2015
  • Location: Dr. Light's Laboratory
  • Posts: 99
  • Post Rating Ratio: +1/-1
    • Omnimaga
Re: Reimplementation of Axe
« Reply #14 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.

 


You can also use the following HTML or bulletin board code to share it on your page or forum signature!


Also do not forget to check our affiliates below.
Planet Casio TI-Planet Calc.news BroniesQC BosaikNet Velocity Games