Alrighty now SDL_GetTicks() should work on the non-CX models (thanks calc84maniac), and once I get the same done for CX's, it'll be as far as I'll go as far as timers are concerned (that makes a lot of as'). Implementing SDL_AddTimer() and whatnot requires some sort of threads or pseudo-threads, plus they're rarely used. Also the event system does actually work as it should, it was just me who used SDL_PollEvent() wrong.

So basically the things that still need to be written/fixed are the timer things for CX (should be pretty straightforward once I have the courage to read the CX timer documentation), BMP blitting and some issues with non-CX surfaces. If everything goes well those two last things are the real problems I still need to tackle. BMP blitting might not work because of some other thing that does not work as it should (something I have not yet noticed), and the issues on non-CX models seem to be caused by surfaces created with SDL_CreateRGBSurface() (in fact it fails if I try to blit a surface created with that function). Also ExtendeD might soon update Ncubate which should be great; GDB would speed up the debugging process quite a bit.

There's a version of GPSP for the GP2X, which is the most likely thing to port from.

Also Hoffa, how are you handling the fact that the timer is 16-bit? I think the SDL_GetTicks() is supposed to return a 32-bit value.

Hoffa, how did you get the boot 1 for the cx? I don't have a cx, but I've been wanting to use one with nspire_emu. I just have a regular nspire, but it would be nice to have an nspire cx on the nspire_emu.

I got it off someone else. Drop me a PM and I'll send it to you tomorrow.

Also Hoffa, how are you handling the fact that the timer is 16-bit? I think the SDL_GetTicks() is supposed to return a 32-bit value.

Well currently I just convert the timer value to milliseconds and return it. I should indeed return the number of milliseconds since SDL was initialized, and simulating a 32-bit timer is rather painstaking with a 16-bit timer unless I somehow periodically check for overlaps and add that to the overall value. I might do it sometime later, but currently it would unnecessarily complexify the code, it would be too much hassle for something that isn't that big of an issue. Currently the timer precision is only at 10 Hz (i.e. 0.1s precision), but that gives ~1.8 hours without a timer reset. I doubt anyone uses the same program on a calculator that long anyway, so I guess I'll increase the timer to 20 Hz (or more) tomorrow.

Hmm, yeah, it's usually used to measure intervals so it might be a good idea to do that. I'll maybe lower it a bit just to be safe (as in 512 Hz? It would give a precision of ~0.002s and double the better-get-the-tick-value-or-else time).

Quote from: njaddison on March 05, 2012, 06:11:28 pm

Hoffa, how did you get the boot 1 for the cx? I don't have a cx, but I've been wanting to use one with nspire_emu. I just have a regular nspire, but it would be nice to have an nspire cx on the nspire_emu.

I got it off someone else. Drop me a PM and I'll send it to you tomorrow.

Thought it was kinda illegal to distribute roms.
But anyway, it can be done with a real CX using polydumper available on tiplanet.org

After a long time, I finally have some results on the CX when it comes to blitting BMP images. The debugging has been very laborious without proper tools, but it seems to work now. I still need to go through the code as it currently uses a slow blitter, and there's some optimized version available, but I'm skipping the part that chooses the blitter as it's what's causing problems.
Enjoy: (and notice the silly debugging messages)



When I get the checking to work, I need to look at the non-CX model which has similar issues with blitting.

Well, that's pretty awesome