Hmmm, tried the new tinspire_test.tns and it reboots my CX..
Is it supposed to?

EDIT: Nevermind, just saw it tries to load a bmp image in /Examples. It's working better now, but the pink cursor no more moves continuously when holding a key.

Seems like getting it working on the classical TI-Nspire has been more difficult than I thought. I can feel I'm pretty to close to getting it run, but those palettes, 4-bit pixels and whatnot have been a pain in the ass. This is the sort of thing I've been looking at for the last few hours:

Figuring out the cause of the issue is also always a major buttpain. Even more annoying is to go to sleep and leave it in its current state.

Anyway, on a side note, that whole Ndless-being-blocked-in-3.2 thing gave me quite a blow to the head. I have to admit I'm pretty fucking frustrated; I expected it but didn't think it'd come this quickly. Right now I feel like the work I'm doing is completely useless, and realistically speaking it is. It may take a month (or more) to have a first more or less stable version of SDL, from then on it takes time for people to learn the library/port programs. At that time 3.2 will be out, it'll be the shiny new thing and 3.1 will be outdated. Even I won't feel like staying on an "old" platform developing for a tiny minority. Even if I'd like to, I can't, as I'm getting my ass conscripted for about a year in the Finnish Army (yes I'm Finnish and we have conscription), and after that I'm moving to the UK for my university studies. There I will hardly ever use my TI-Nspire and will most probably develop on other platforms. I will try to finish this thing even for the sake of it (and to be able to add "ported SDL to a calculator" on my CV). Just realized it'll possibly be my last project on a calculator, but we'll see how it eventually turns out.

Oh boy finally I have some code that initializes and runs stably on both calculators. I eventually noticed there was an extremely annoying memory leak that caused completely unpredictable and inconsistent behavior only with non-CX code (in non-graphical parts). Just before I hung myself I magically managed to fix the issue by fixing another issue. It's so goddamn reliving to see this showing up in the console no matter how many times you run the program:


Feels good man.

It also now prevents you from launching any code not compiled for the current calculator:

And last update today: I wrote a first version of the non-CX video code. It works poorly with anything odd (as opposed to even; doesn't handle single nibbles when copying data), but I have some results:



(Oh, and I got to try it on my own TI-Nspire, which is nice; seems to be working well with that primitive example)

Awesome work hoffa

Actually this'll be the last update for today. On the previous screen you can see that gradient, but it only shows 7 colors and it doesn't seem to be consistent. That's because SDL's palette color mapper is crap (or not suited for 4-bit displays), so I decided to get completely rid of the palette and replace the color mapper code by a one-liner. It should be faster, much better, and should simplify and speed things up generally as all the bytes in the screen buffer are already within the 0-15 range. I'm not entirely sure that it won't cause any issues later (not sure how SDL deals with blitting surfaces with different formats etc.), but currently it seems to be working well, and here's the result (compare with the previous one, it's the same code for the gradient) (oh, also notice odd coordinates work well):



Here are the basic things I still need to do before we have a first beta version of SDL for the TI-Nspire:
- Get the BMP blitting to work
- Fix the events (it currently sends loads of them and at inappropriate moments; also some stuff with the joystick I need to fix)
- Implement the timers system fully
(- Add own function to blit images from array data)

Those are the most important things and the first things that come to my mind.

BTW, on my calculator performance-wise it seems quite fast, it's rather snappy and responsive although it's updating the whole screen every time and a lot more than it should (event system that needs working on). It's a very simple program but it's good to see it runs fast.

Nice, keep up the good work!  

Also, will it be possible to port VisualBoyAdvance? It's SDL-based.  

Depends what exactly are the libraries used by VBA, but sure, with some trimming it shouldn't be too big of an issue.
EDIT: Reo, are you sure about it? I honestly don't have an idea, but VBA might be optimized quite a bit as it's already a robust and mature program.