Nice So this is the event loop? There may be other interesting events to listen to, aren't there?

Very nice Goplat!  Thank you for posting.

EDIT: I have been playing around with the Makefile included with Ndless 1.1 in order to make it compatible with including the headers from the skeleton.  I have successfully made it include the header files in the "./headers" directory, but it dosen't like the "./system" directory, complaining of missing files which are incompatible when replaced.  I have attached 1. An edited copy of the Makefile for Windows, 2. An edited copy of nspire-gcc for including the right headers, and 3. An edited copy of nspire-as for including the right headers. I am working on getting it to include the system files from the skeleton, but for now, it just uses the ones in Ndless (they are included from nspire-ld).  The Makefile should replace the Makefile in the skeleton directory, and nspire-gcc and nspire-as should replace those in the Ndless /bin directory.  All three of the needed files are included in the zip attached.

@apcalc: if you'll post a known working version of the skeleton for Ndless 1.1, I'll attach it to the OP. Thanks in advance!
@fb39ca4: Hmm...can you explain what a masked sprite is? I'm not so good with sprites and such

@bwang: A sprite mask determines which pixels in an image are transparent, so those pixels don't get copied to the screen. There is a more detailed explanation here. There are two ways to do this: create a second buffer with the mask data, or have one color in the image represent transparent.

Well then, here's my masked sprite function:
void masksprite(char* scrbuf, char* sprite, int x, int y, int w, int h)
{
  int i, j;
  for (i = 0; i < w; i++) {
    for (j = 0; j < h; j++) {
      if (sprite[i + w * j] < 16) {
        setPixelBuf(scrbuf, i + x, j + y, sprite[i + w * j]);
      }
    }
  }
}Any value over 15 in the sprite will be treated as transparent.

Thanks bwang. I've been meaning to criticize some of the Nspire C code that's going around, having it all in one place makes that easier

console.c
Has no protection against writing past the end of buf. Also, I think scrbuf is unnecessary; drawing directly to A4000100 should be fine. It shouldn't flicker; flicker comes from drawing to the same part of the screen in multiple passes. For example, if you first draw a background and then draw a sprite on top of that, there's a brief period of time when the sprite isn't there. Since putChar works in a single pass, it's just fine to use it directly on the screen.

dirlist.c
This is a bad function even in concept - the caller has no way to know how big an array to allocate for result unless it has already enumerated the directory itself.

screen.c
Looks ok.

string.c
itoa, strlen, strcpy, strcmp: Looks ok.
atoi: Doesn't conform to the C standard. Should allow initial whitespace characters (i.e. space, tab, line feed, vertical tab, form feed, and carriage return), and should stop at the first non-digit. A standards-conforming implementation of atoi exists in the TI OS at address 1018DC44 (non-CAS) or 1018D94C (CAS).

syscalls.c
What the heck is this?

utils.c
rect_intersect, refresh, clearScreen, clearBuf, setPixel, setPixelBuf, getPixel, getPixelBuf, rand, showSimpleDialogBox: Looks ok.
fade: The loop is one byte too short. Should start with i = 0.
scrollScreen: Works, but there is no reason why such a function should require a temporary buffer. Just use memmove (address 1018606C in the non-CAS OS, 10185D74 in the CAS OS):
memmove(scrbuf, scrbuf + bytesOffset, cpysize);
memset(scrbuf + cpysize, 0xFF, bytesOffset);
scrollScreenDown: Doesn't work, probably will crash. This should be done as:
memmove(scrbuf + bytesOffset, scrbuf, cpysize);
memset(scrbuf, 0xFF, bytesOffset);
scrollScreenUp: Function is identical to scrollScreen. No reason both should exist.
filesize, getch: Looks ok.

I actually think it might be advantageous to make our own optimized memcpy, mommove, and memset routines for the Ndless library, because the versions in the OS can be very slow (it does it byte-by-byte in all cases)