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.

Interesting...the nspire has an 8-directional Dpad, so up to 16 directions. Not too shabby!

I was thinking about making a non-specific keypad library, that would detect what keypad you have (anyone know the bit that determines this? It's a hardware thing running to one of the keypads, I'll bet) and then substitute keypad commands and such, so touch, 84+ and regular nspire could all be run with the same header.

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]).

sprite_routine() is a non-existent routine for drawing sprites. Someone needs to write it (not very hard, just loop over the elements of the array and draw pixels).
malloc() will not work the way you are doing it. Integers should not crash the calc; can you post your original code?

I hope you don't give up on calc stuff

Aaah ok good to hear, hoping you continue a bit afterward too (like some of us) even if not as often (I release new stuff like once a year)

Basically, is it to make the Nspire keypad have a key layout similar to the 84+ one? I would like this so I don't have to constantly switch when Calc84maniac releases his emulators

Not quite what I was thinking, more that programs can support either without having to be reassembled. I'm thinking you'd have a few generic keys, like KEY_ENTER and KEY_UP, while if you need more controls you switch over to KEY_NSPIRE_THETA and so on. This would be the most helpful with the touchpad, since many keys are labeled the same. Using KEY_NSPIRE would require the Nspire Keypad, but it could support both the touch and the original, sans sin, cos, tan, and any other changes.

Can the touch's keypad support more than 16-directional input? I'm curious if it's really an upgrade, since the original keypad can only support that much.

I updated the Common+.h in my last post.