You can help CodeWalrus stay online by donating here. | New CodeWalrus | Old (dark mode) | Old (light) | Discord server
We have an anniversary Game Jam! Click here for more info.
0
b/Calculator Talk publicado por u/Agothro 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
Inicia sesión o crea una cuenta para dejar un comentario
u/matrefeytontias 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.
u/Agothro January 04, 2015, 07:35:39 PM
It's perfectly possible if you completely reimplement from scratch, which is what I suggested.
u/Dream of Omnimaga 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
u/Yuki 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.
u/Agothro 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.
u/Yuki January 04, 2015, 09:25:25 PM
Yeah, a language should not be bound to one specific platform. Program once, port everywhere.
u/TIfanx1999 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?



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
u/Agothro 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.
u/Yuki 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.
u/TIfanx1999 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.
Last Edit: January 04, 2015, 10:05:51 PM by Art_of_camelot
u/Agothro 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.
u/Dark Storm 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. :)
u/Agothro 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.
u/TIfanx1999 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.
Start a Discussion

b/Calculator Talk

Saw a cool TI, HP or Casio program out there? Need help programming or installing a software? This place is for you.

283
Topics
Explore Board
Website statistics


MyCalcs | Ticalc.org | Cemetech | Omnimaga | TI-Basic Developer | MaxCoderz | TI-Story | Casiocalc.org | Casiopeia | The Museum of HP Calculators | HPCalc.org | CnCalc.org | Music 2000 Community | TI Education | Casio Education | HP Calcs | NumWorks | SwissMicros | Sharp Calculators
Powered by EzPortal