yoshi13: Why are you allocating your integers with malloc()? You can just declare them as, for example, int i.
malloc() is for arrays and such.
Also, you probably want to draw your characters the same way you'd draw sprites. Make an array of pointers to int, with each element being a pointer to the first element of an array containing data for the character. Then to draw a character ch, simply call sprite_routine(char_data[ch]).

I have seen more than one post talking about writing some basic libraries for the Nspire, so I felt that it would be a good idea to start a thread to post any headers we have.
I will start with a modified utils.h/c that supports drawing pixels to a screen buffer. This should be useful for people doing graphics functions.
Right now we need:
-Program Loader
-Graphics: Triangles, dithering, filled circles, etc.
-Better Text I/O (I wrote some, but they are a bit weak)
-More OS symbols
-An implementation of the standard library (stdlib.h, stdio.h, etc) for easier porting.

EDIT 1: Attached a file skeleton.zip. Edit your Nspire code in this folder, and then type 'make' to build. It provides the minimal portion of Ndless required to write programs.
EDIT 2: Attached willrandship's modified common.h, with all the keycodes in it.
EDIT 3: Found a small bug in common.h.
EDIT 4: Latest skeleton.zip
EDIT 5: Realized that MakeTNS is platform-dependent. skeleton is split into Linux and Windows versions.
EDIT 6: Attached a graphics.h/c, which is a not quite finished, but still useful, collection of graphics routines. Right now it contains fast circle and line routines, and some functional but slow rectangle and sprite routines.

EDIT 7: common-fixed.h and utils.zip are now unnecessary. They have been integrated into the skeleton.zip files, so don't bother downloading them. graphics.h/c are still separate for now, and will be until they are finished.

EDIT 8: Updated graphics.c/h to graphics2.c/h. This one contains a much better sprite routine that uses proper memory-copying methods to draw the sprite. The sprite data format has changed, so if you have any old sprite data pass them to
convsprite(char* sprite, char* result, int w, int h)
Here, result is a buffer that is of size w * h / 2 used to hold the new data.
EDIT 9: apcalc found a small bug in common.h. Fixed!
EDIT 10: Fixed a nasty sprite() bug.
EDIT 11: skeleton-windows.zip and skeleton.zip merged. I added a few text and string routines to it (string.h, screen.h) as well as dirlist.h, which lets you list the files in a given directory. Yes, I know this violates EDIT 1, which states that skeleton.zip is minimal, but being able to draw text is too useful. Also, common-fixed.h and utils.zip have disappeared.
EDIT 12: added a function filesize(char* path) to utils.h. Pass it the path to a file and it returns its size.

Not much reason to do that, since, for example COLORA is just 0xA (or 10 in decimal). The integer values allow you to do arithmetic on them. If you wanted to increase readability, you could give them names like GRAY, LIGHT_GRAY, DARK_GRAY, etc.
If you wanted to start doing some header stuff, you could fill in the rest of the key codes in common.h and post that. They'll come in handy later.

Look at the Ncaster source for a modified version of the non-CAS os.h (in headers) which contains some keycodes. You can add to it by looking at this page: http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900E0000_-_Keypad
You allocate the buffer using something along the lines of
char* scrbuf = (char*) malloc(SCREEN_BYTES_SIZE);
Then you can use getPixelBuf() and setPixelBuf() (in the Ncaster utils.h and utils.c files) to read and write pixels to this buffer.

Nice! I like the splitting, and the new forums that take into consideration recent developments (Ndless and Axe).

No. The Nspire cannot handle a 320 x 240 array if it is declared as int array[320][240]. Writing anything to it will crash the calculator. You will need to use malloc().
Are you using the array as a screen buffer? I have a modified utils.c and utils.h in the Ncaster package that supports writing to a separate buffer.
You can record the screen using the standard screen capture tools.

Ok, good to know. But a library with several graphics functions (sprites, tiles mapper, custom font routine) and other functions could make easier for starting.
I will later get involved in Nspire scene after I am somewhat realized in z80.

I've been thinking about writing a library. I have some useful functions used by the ray caster (draw to a buffer, sort an array, and some math functions) and I might split them off into the beginnings of a separate "Nspire Utility Library" project.