I have been working on porting nSDL to the prizm so people can write one program to run on both prizm and both nspires. It now even compiles for on calc Very Happy so it should be ready for anyone who wants to to test it. Until it gets to version 1 and I get most bugs out I will not be distributing binaries so you will have to build it. To compile it run make -f Makefile.prizm and it should compile. to install it assumes you built it in the /projects directory of the prizm sdk then run make -f Makefile.prizm install to install it to your prizm sdk

I need people to help me find any errors I might have made and to test the library. If someone could please help me the code is at https://github.com/ruler501/pSDL It now compiles fine and will run if you use a 8 bit surface. malloc seems to fail if it tries to use a 16bpp surface the size of the screen. If someone could please find a way to get malloc working with large values that could allow much more usability

I could not have done this without hoffa's wonderful nSDL. I have copied most of his code and only changed the parts that are platform specific(mainly).


This is a demo of a program called explosion I cannot currently remember where I got it from. Other than removing functions the prizm doesnt support very little work was needed to port it

http://www.omnimaga.org/index.php?action=dlattach;topic=13820.0;attach=13109 is the binaries for version 1.0.0 which I will be updating soon since the current version does not support anywhere near the whole keyboard like it should.
pSDL has also moved so that it is now called pSDL on my github instead of still being called nSDL

EDIT:Touched up the entire post to be more concise and organized
Get me a list of functions that are missing. I'm not about to go implementing the entire stdlib, but knowing what's needed (probably not much) allows me to do something-- anything.
I have not looked close enough to say what functions but all the errors so far have come from SDL_malloc.c in stdlib folder when I get time later right now I can't though

EDIT: I tested one thing real quick and all you ahve to do to make it compile is add -D HAVE_MALLOC and it compiles I'm getting my calc back later today so I'll run some test programs and see if there are any other problems

EDIT2: When trying to use the library produced from compiling with HAVE_MALLOC I get lots of undefined errors. I need to find what functions in src/stdlib/SDL_malloc.c need to be implemented then I will tell you.
I had forgotten to include the define that actually made it compile for prizm so once I added it it no longer compiles. I will be gone for a while so I will not be able to update this at all until I get back. Currently it will not build for the prizm and fails with a lot of errors which i hae to go through and find a source for
I'm slowly working through the errors but I am finding things that are missing that need to be added to the SDK for it to compile.
The things I've found so far that need implementation are:
stdint.h (Though i think I got this working acceptably you can see my slightly modified version of it in the include folder of the most recent commit)
stdarg.h(for va_list)
and probably more but until I get past one I can't see the next problems
I'm pretty sure these missing headers are Jonimus' fault. The toolchain I compiled from source has all of these, so your current problem is something in how Jonimus packaged everything.
Tari I think the problem there is from how the wiki says to build the toolchain for nonArch linuxes it says to build with the option --without-headers. My guess for this is that the headers/libraries will not work on the prizm without some platform specific fiddling.
Though if you could try compiling the most recent version from my github and test it that would be great. If it works I know that the problem is in the build instruction for the prizm sdk
This is a screencap of the first video program to run under pSDL on the prizm

EDIT: the img tags seem to not like my image link so I'll just leave the link here

Congratulations! The issue there is that bitmaps (BMP) are a huge and unwieldy format, and may not be used for embedded images here. Almost any image editor can turn that into a PNG for you.
Ok thanks for the info I'll fix it in a little bit
I forgot to post this last night before i went to sleep but here is a video demo of what pSDL can do

and i even remembered to use preview this time Razz
Wow, VERY impressive! Now take a few stills of that nifty demo and I think we have ourselves that news article I was looking for. Wink
I now have a working game and if you want the source/program for the demo I can send it to you but its not very good looking code and it has some errors in event handling(has locked up my calc a couple times)

I need help in image loading my current code leaves a blue shift in the resulting image.

SDL_Color rgb16to24(Uint16 x)
   SDL_Color newcolor;
   newcolor.b= (x & 0x1F) * 8;
        newcolor.g = ((x >> 5) & 0x2F)* 4;
    newcolor.r = ((x >> 11) & 0x1F)* 8;
   return newcolor;

SDL_Surface* LoadSCImage(Uint16* pallete, int paletteSize, unsigned char* image, int x, int y)
   int i, j;
   SDL_Color newColors[paletteSize];
   for (i = 0; i < paletteSize; i++)
      newColors[i] = rgb16to24(pallete[i]);
   SDL_Surface  *tempsurf = SDL_CreateRGBSurface( SDL_SWSURFACE, x, y, 8, 0,0,0,0);
   for (i = 0; i < y; i++)
      for (j=0; j < x; j++)
         *(Uint8 *)(tempsurf->pixels + i*tempsurf->pitch + j) = image[i*x + j];
   SDL_SetColors(tempsurf, newColors, 0, paletteSize);
   return tempsurf;
That looks fine to me; you have the proper *8 (== <<3) on the blue and red, and the *4 (== <<2) on the green. Is it possible the issue is in your rendering code?
I had a few problems with rendering but it seems to have rendering ok but all the colors are messed up so there has to be a problem somewhere.

EDIT: couldnt get 8 bit working but heres the function that correctly loads 16 bit
SDL_Surface* LoadSCImage(Uint16* image, int x, int y)
   SDL_Surface  *rimage, *tempsurf =  SDL_CreateRGBSurfaceFrom(image, x, y, 16, 2*x, PZM_RMASK16,PZM_GMASK16,PZM_BMASK16,0);
   rimage = SDL_DisplayFormat(tempsurf);
   return rimage;

I'll compile this and a few things from hoffa's nSDL to a seperate library when i came back to work on this in August
Great, have fun on vacation, and we hope you return with a renewed vigor for this project (and Prizm programming in general). Nice progress!
I'm back now and now I need to decide what I need to do with this project. I think that one of the main things that will need to be done is get the events to recognize all keys. If anyone knows a way to do this please tell me. I also plan on making some demo's and trying to find more efficient ways to implement some of the internal functions.

What I need help with:
Testing what keys are down for the entire prizm keyboard
Getting file i/o for bmp loading
Getting other SDL libraries working(SDL_gfx most importantly)
If I could get these things working I think it would greatly improve this library
Ashbad has posted some decent code for detecting keypresses in the Useful Prizm Routines topic, and I have my text and number input routine. The Prizm Programming Portal on WikiPrizm also has some new tutorials on input and on using files, thanks to AHelper0 and others.
The one thing about those though is that it does not allow me to check for all keys that have been pressed and place those into the event queue. I would like something like the Debouncing Multiple-Keypress PRGM GetKey from the wiki. In fact thats what i currently use but the documentation on it says it only works for the KEY_PRGM_ codes while I need to be able to use all keys on the keyboard.
ruler501 wrote:
The one thing about those though is that it does not allow me to check for all keys that have been pressed and place those into the event queue. I would like something like the Debouncing Multiple-Keypress PRGM GetKey from the wiki. In fact thats what i currently use but the documentation on it says it only works for the KEY_PRGM_ codes while I need to be able to use all keys on the keyboard.

Yeah, so you're going to have to manually keep track of when they were pressed during the run of the SDL_PollEvent(), SDL_WaitEvent(), etc. routines. The routines, if used correctly, can be used/modified to work so that they store all pressed keys into a queue, not just the very last few pressed. Actually shouldn't be very hard to modify for that purpose.

As for the routine, it does work for every key on the keyboard, you're just going to have to define the other KEY_PRGM defines if you want to keep track of names.
so I have to find out what the KEY_PRGM defines are for the rest of the keys to use them or what defines do I use?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum