What program is this picture?
http://i.imgur.com/ONKjZ.png

As said above.

Here's the post: http://ourl.ca/14975/308110;topicseen#new

When using 8 bpp (when initializing SDL with 8 bpp) it's palettized (every color mapped to a certain RGB value; palette is located in screen->format->palette and can be changed using SDL_SetColors()). It generates some default palette which is the one I used.
When using 16 bpp, colors are just encoded as 16-bit high color.

Can't remember to be honest, it was some key combination to display two pages at once.

Thanks a lot! That's some pretty damn clean code, it's a pleasure to read/mess with.

EDIT:
Purely for viewing pleasure, a CX color version:


And some on-calc footage to see how it runs:

(I edited a few lines to get it working with nSDL and got about 6 FPS extra at the same time)

It runs at a rather constant 28-31 FPS on CX (could certainly be pushed further if it was optimized for 16 bpp) and 45-47 FPS on Touchpad when the whole lower half of the screen is filled.

EDIT2: I added the TNS if somebody wants to play with it.

I added an image to NTI converter: http://hoffa.franceserv.fr/nti/

Awesome!

BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both calculators, everything runs smoothly).

I'm pretty positive you could get a nice speed boost if you used one of the many available fixed-point math libraries in C, especially if the program messes around a lot with floating point data (the ARM doesn't have an FPU).

Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.

In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot.
I'm not saying you should be using statically allocated data for everything (quite the contrary usually), but for string buffers and such, a char buf[BUF_SIZE]; is usually good enough.