Alternatively, join us on Discord.
You can help CodeWalrus stay online by donating here.

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Agothro

1
Site Discussion & Bug Reports / What is Black Sunday?
January 05, 2015, 04:39:43 AM
Sorry, can somebody fill me in?
2
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.
Powered by EzPortal