Thanks for the information! I think the freezes and clock icon appearing might be caused by some issues with the input code that sends a gazillion events (and needs fixing), or then by the main loop that runs too fast (or, in the worst case, too slow). Seems like I'll have to slowly start writing the non-CX graphics code so I can myself try it on my Touchpad so as to see how it runs.

Anyway, I added "classical" SDL events (those SDLK_* things for instance) which took quite a bit of time for the keymaps and whatnot, but again it behaves a bit weird with SDL_PollEvent.

EDIT: SDL doesn't seem to handle 4-bit color at all, which is a bit trickier. I think I'll have to pretend it's an 8 BPP display and just before copying to the framebuffer pack it in 4 bits or something.

It shouldn't, no. Weird, works very well on the emulator.
It's still some early code though, I haven't thoroughly tested it (and more generally, the tinspire_test.tns on github doesn't necessarily have to work; I just push the changes when I feel like it). I think I'll write the video driver for non-CX first so that I have a better idea of the behavior on both machines.
Thanks again anyway, I'll look into it more tomorrow.

EDIT: It does try to load a BMP, but I don't think it should stop it from running, as it just returns NULL and moves on. It's normal that it doesn't work when holding the key, that's how events work in SDL. SDL_EnableKeyRepeat() should enable that behavior though, but I'm not entirely sure if it works currently as I haven't fully implemented the timers system (in fact there's only SDL_Delay()).

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). It's so 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.

Yeah, and gpsp uses SDL so this would be a good first step to porting it