New Post	New Topic
Goto page 1, 2, 3  Next

25 Apr 2012 01:18:36 pm by gbl08ma	PNGview: a PNG viewer for the Prizm [nevermind]	Quote
I'm trying to develop a PNG viewing add-in for the Prizm. I don't usually need to view images on the Prizm, but sometimes it's handy to have some schemes and diagrams in the calc. Since it's a pain to create them in-calc using the Geometry app, and since the g3p format is proprietary and IMO doesn't compress full-color images very well, I thought a PNG viewer would be the way to go. I think I have managed to port http://lodev.org/lodepng/ . I chose to port this because it has no external dependencies, and I found the code to be fairly easy to understand. I found other options to have too bloated for the simpleness of my project and external dependencies like zlib, which would only add more code to port. Also, LodePNG is both a decoder and an encoder, which may be useful for e.g. developing an on-calc BMP to PNG converter (for converting and seeing the BMP screen captures). However, my add-in doesn't work quite right. It is at a very, very basic stage, and my test code is meant to display the width and height of the file test.png located in the storage memory of the Prizm. But, no matter what picture the file test.png has, LodePNG will always say "empty input or file doesn't exist". I have gone through the code over than 20 times and can't understand what's wrong - it's as if the file didn't exit on the calc, period. However, I can see it in the memory menu, so it's definitely there. Trust me, I banged my head on the wall many times: I started this project in March and whenever I have time I debug it, still I haven't managed to make it work. I think I'm probably doing something wrong with the syscalls for reading files. Perhaps I'm not passing the filename to LodePNG correctly. I invite you to download the ZIP file with source code and a pre-compiled g3a from here: http://l.f.nu/dl/casioprizm/PNGview.zip ...and put a (small) PNG file called "test.png" in the root of your calc. Then launch the add-in, press F1 and verify it doesn't work (or otherwise). If you could check the source code for mistakes, it'd be highly appreciated. Compilation issues some warnings I don't know very well how to solve either. Help the noob, please! EDIT: nevermind, the project was cancelled as well as all Prizm development on my behalf until further notice. See http://www.cemetech.net/forum/viewtopic.php?p=182130#182130

25 Apr 2012 01:26:58 pm by KermMartian		Quote
I'm not sure how much this helps, but here's how I check for, create, and modify the Tetrizm high scores file: Code: const unsigned short HSFile[] = {'\\','\\','f','l','s','0','\\','z','T','e','t','H','S','\0'}; //... //Check for existence, create if doesn't exist    //high scores file    int fh = -1;    if (0 > (fh = Bfile_OpenFile_OS(HSFile,0x01))) {         //_OPENMODE_READ       int size = NMODES*(4+4);       if (0 > Bfile_CreateEntry_OS(HSFile,1,&size)) {          PrintXY(4, 5, "XXHS File Error!",0x20,4);          Bdisp_PutDisp_DD();          DebounceAndPause();          return -1;       } else {          const char hsinit[] = "CEM\0\0\0\0\0ETE\0\0\0\0\0CH.\0\0\0\0\0NET\0\0\0\0\0CRM\0\0\0\0";          if (0 <= (fh = Bfile_OpenFile_OS(HSFile,0x02))) {         //_OPENMODE_WRITE             Bfile_WriteFile_OS(fh,hsinit,NMODES*(4+4));          }       }    }    if (fh >= 0)       Bfile_CloseFile_OS(fh); //... // Open and cache the high scores table    if (NULL == hstable && (NULL == (hstable = malloc(NMODES*(4+4))))) {       return -1;    }    if (0 <= (fh = Bfile_OpenFile_OS(HSFile,0x01))) {         //_OPENMODE_READ       Bfile_ReadFile_OS(fh,(void*)hstable,NMODES*(4+4),0);       Bfile_CloseFile_OS(fh);    } //... // Re-saving the high-scores table.       if (0 <= (fh = Bfile_OpenFile_OS(HSFile,0x02))) {         //_OPENMODE_WRITE          Bfile_WriteFile_OS(fh,hstable,NMODES*(4+4));          Bfile_CloseFile_OS(fh);       }

25 Apr 2012 01:39:35 pm by gbl08ma		Quote
That doesn't help much except maybe for the fact it contains the values for the openmodes (I was using 0x03, which I believe is both read and write access). Changing to 0x02 didn't fix it, unfortunately. I think the problem is somewhere in these lines of code: Code: unsigned LodePNG_loadFile(unsigned char** out, unsigned int* outsize, const char* filename) {   /*FILE* file;*/   /*long size;*/   int size;   /*provide some proper output values if error will happen*/   *out = 0;   *outsize = 0;   /*file = fopen(filename, "rb");*/   int file = 0;   unsigned short*fixedfilename = malloc(256); // will hold new name   Bfile_StrToName_ncpy(fixedfilename, filename, 128);   file = Bfile_OpenFile_OS(fixedfilename, 0x01);   if(!file) return 78;   /*get filesize:*/   /*fseek(file , 0 , SEEK_END);   size = ftell(file);   rewind(file);*/   size = Bfile_GetFileSize_OS(file);   /*read contents of the file into the vector*/   *outsize = 0;   *out = (unsigned char*)malloc((unsigned int)size);   /*if(size && (*out)) (*outsize) = fread(*out, 1, (unsigned int)size, file);*/   if(size && (*out)) (*outsize) = Bfile_ReadFile_OS(file, *out, size, -1);   /*fclose(file);*/   Bfile_CloseFile_OS(file);   if(!(*out) && size) return 9900; /*the above malloc failed*/   return 0; } ...or else, the "filename" that gets to this function is not the one I provided when calling LodePNG_loadFile(&buffer, &buffersize, filename);. Basically what I did for porting LodePNG was replacing the fopen, fseek, fwrite... functions with Bfile syscalls (and change the code accordingly, and this is the part I'm unsure I did correctly), as well as add some functions which aren't available in the PrizmSDK.

25 Apr 2012 01:42:30 pm by DJ_O		Quote
By the way would this be only for the cg20 (european) models? Because after someone tried to hack the g3p format to allow custom images on the cg10, some people raised some concerns about the possibility that this could get the calcs banned from schools or tests in United States.

25 Apr 2012 01:46:58 pm by gbl08ma		Quote
I'm not planning on putting any restrictions as to which calcs can run this (I don't even know how to distinguish between a cg10 and a cg20 from an add-in). You're responsible for what software you put on your calculator. I'm not worried as I'm in Europe and own a cg20.

25 Apr 2012 01:48:46 pm by KermMartian		Quote
gbl08ma wrote: I'm not planning on putting any restrictions as to which calcs can run this (I don't even know how to distinguish between a cg10 and a cg20 from an add-in). You're responsible for what software you put on your calculator. I'm not worried as I'm in Europe and own a cg20. I actually was one of the people who voiced concerns about the project that Kevin is referencing. The concern was that the user trying to crack Casio's protected image format would drive them to try to lock down their calculators more, driving us into the unfortunate spiral of the Nspire, where TI and developers constantly play cat-and-mouse. I'm still pondering this project and where I think it falls relative to those concerns.

25 Apr 2012 01:53:04 pm by gbl08ma		Quote
Well I feel a need for PNG viewing. The cg20 can already see custom g3p provided you have a converter. The most that can happen is that I'm going to need to figure the errors in the code myself and release this only for me and select friends. At the same time, since I'm not planning on leaving OS 1.03 so soon, add-in lockdowns won't really affect me until I update the OS. (BTW, can't the cg10 see images created with the Geometry tool? OPTN - Save as image)

25 Apr 2012 01:54:29 pm by DJ_O		Quote
True. I was just saying since a lot of the PRIZM coders are trying hard to make sure the community isn't destroyed by a school ban or something. By the way this was the posts where the issue was discussed (including one by Kerm) http://www.omnimaga.org/index.php?topic=12813.msg241634#msg241634 KermMartian link=topic=12813.msg241683#msg241683 date=1333808233 wrote: I am one of the Prizm hackers who had been expressing concerns on #cemetech. I've been in various contact with Casio marketing and engineering personnel over the past year or so, and they have made it clear that they're currently turning a blind eye to mature, responsible third-party hacking. Officially, they're supposed to both not support it and potentially disallow it, but that hinges on how we behave. A Prizm coder started discussing creating a fake reset Add-In over at Cemetech, and a large number of us Prizm hackers quickly expressed our opinions on why that would be bad for everyone in terms of getting Casio to look more closely at what we were doing with Add-Ins and think seriously about Add-In security. Bottom line: We do not want to drive Casio into the same cat-and-mouse game the Nspire developers have to work around. One of the great advantages of Prizm programming in my view is that our programs and add-ins work on Prizms without jailbreaking, without Ndlessing, without any sort of unlocking tools. If we want to maintain that, we have to code like ethical, mature, grown-up programmers. Undermining the whole reason that there's a different between the CG10 and the CG20, at least with a public tool release, would not be responsible. I can appreciate the ego value of successfully figuring out the format, and even telling people of your technical successes, but just as it wouldn't be ethical to release a tool to the general public that could exploit a glitch in computer systems to steal identities on the assumption that some would use it for good, it's not ethical to release this tool. There's a very good reason that SourceCoder doesn't do such image format conversions, and trust me, it's not technical reasons. I personally would like to have an image viewer on my calc. The issue is if such program starts getting used to cheat on tests or to share porn with other students. I'm sure most of us here would use common sense while using such program, though.

25 Apr 2012 01:59:36 pm by gbl08ma		Quote
One can already store as much information as one wants in eActivity. I don't understand why images are such a big deal... and porn/[other less-safe images] can already be shared using phones/tablets/laptops, heck, sometimes even the school computers! It's like we are going to disallow a text reading plugin because students can store information in it.

25 Apr 2012 02:04:20 pm by KermMartian		Quote
I think the distinction that I see between what Simon was doing and what gbl08ma is doing is cracking Casio's format, which was meant to be secure, versus creating an add-in, which is not blocked in any way. I agree that my justification is a bit shaky there, though.

25 Apr 2012 02:08:30 pm by Ashbad		Quote
Whether we argue that Casio's reasoning is fair or not, they're likely going to keep whatever opinion that they had before on the issue; I can't say exactly if this is "safe" or "unsafe" ground we're treading in, it's not as clean-cut as with the g3p hacking mini-scandal. I personally see it veering over to the "unsafe" side. One thing we can't afford is the locking down of the Prizm. Things they could easily do with an OS update would be adding encryption to add-ins, re-releasing all of their own add-ins to follow this encryption scheme, put add-ins to run in user space, mask off all direct access to memory-mapped ports, the list goes on. It's better we stay clear and keep all the power we currently have, albeit not having a picture viewing add-in, than no add-ins at all. Seems pretty obvious to me. KermMartian wrote: I think the distinction that I see between what Simon was doing and what gbl08ma is doing is cracking Casio's format, which was meant to be secure, versus creating an add-in, which is not blocked in any way. I agree that my justification is a bit shaky there, though. I think that's somewhat weak but fair justification, I just think the point in general was not to have any picture viewing capabilities at all on cg-10 models.

25 Apr 2012 02:10:02 pm by gbl08ma		Quote
If there are regulations on which add-ins a student can have, just have teachers reset the add-ins before exams (there's even a function in the reset menu just for that), or have them specifically check for a disallowed addin. The fact that the cg10 doesn't read g3p files is still true when my add-in is installed. But if the restriction is supposed to be, "cg10 cannot read any images", then putting a PNG/BMP/whatever reading add-in on the cg10 is not a good idea either. Should we ask Casio? EDIT: again, I don't see how this would be much different from e.g. a Pokemon game. A PNG viewer can display content on the screen for which the calc was not designed for - just like any other game. If you hardcode an image into an add-in, like it's been done hundreds of time, then you can display anything on the screen. Of course, this is one point of view - the "optimistic one" if you wish.

25 Apr 2012 02:10:02 pm by Kaslai		Quote
This is not a private forum and, even worse, it's indexed by Google, so any Tom, a and Harry can waltz right in and download it for themselves. If you do succeed, distribute it on a request basis. I never really thought about the implications of an image viewer, but your argument is actually quite sound. If Casio loses traction in the market due to 3rd party applications, they will for sure crack down on third parties. I don't really think that cheating is a large issue with a calculator, as any fair graphing calculator that even a teacher would recommend has the ability to store textual and graphic data anyways which can be used to cheat. The idea of pornographic and other illicit images though is new and novel, due to these great new high resolution color screens. I'm sure that if a single student pulled a stunt like that and got caught, it could definitely set off a chain reaction. Such matters seem like they would be quite irritating. It never once crossed my mind that an image viewer might cause harm to Casio.

25 Apr 2012 02:12:46 pm by Ashbad		Quote
gbl08ma wrote: Should we ask Casio? Feel free to, but unfortunately I doubt they'll have any response that can help us with judgement. We'd likely get a "wait, how the hell are you making add-ins with no official SDK?" instead of a yes or no/explanation. Quote: EDIT: again, I don't see how this would be much different from e.g. a Pokemon game. A PNG viewer can display content on the screen for which the calc was not designed for - just like any other game. If you hardcode an image into an add-in, like it's been done hundreds of time, then you can display anything on the screen. I would argue most of those hardcoded-image viewing add-ins have been made for learning and personal pleasure, and haven't been released; they also wouldn't allow one to pick from a library of images on their calculator to view at whim.

25 Apr 2012 02:14:44 pm by KermMartian		Quote
Ashbad wrote: gbl08ma wrote: Should we ask Casio? Feel free to, but unfortunately I doubt they'll have any response that can help us with judgement. We'd likely get a "wait, how the hell are you making add-ins with no official SDK?" instead of a yes or no/explanation. As I mentioned in that quote that DJ_O took from me, Casio representatives are currently pretending that our add-in development isn't happening to avoid having to take appropriate steps to "deal with it," namely examining what we're doing and deciding whether they should lock out what we're doing. We want to keep it that way. Edit: Essentially, what I'm saying is that bugging Casio will hurt rather than help us. I do indeed still have reservations about the ramifications of this add-in, though, and I'm still listening to the arguments.

25 Apr 2012 02:19:34 pm by gbl08ma		Quote
Just a reminder, from what I know, Casio never tried to lock homebrew development on the previous models of graphic calculators - they even released a SDK for the 9860G. The only real news here is the color, high-def screen the Prizm has. The screen opens up for lots of new possibilities, and I think that's something the world will have to get used to - or else, forbid HD-color-screen calculators from being used in schools. If someone developed a B&W BMP or PNG viewer for the 9860G, if one doesn't exist already, would this discussion come up?

25 Apr 2012 02:20:24 pm by Kaslai		Quote
gbl08ma wrote: If you hardcode an image into an add-in, like it's been done hundreds of time, then you can display anything on the screen. The big difference is just in who has the ability to manipulate the screen: the devs, or the end users. The end users probably don't care if Casio cracks down on third party developers, and they probably wouldn't even know if they did anyway. The consequences of the end users' actions would get saddled on the shoulders of the developers. The solution? Don't give the end user any control.

25 Apr 2012 02:21:57 pm by Ashbad		Quote
gbl08ma wrote: Just a reminder, from what I know, Casio never tried to lock homebrew development on the previous models of graphic calculators - they even released a SDK for the 9860G. The only real news here is the color, high-def screen the Prizm has. The screen opens up for lots of new possibilities, and I think that's something the world will have to get used to - or else, forbid HD-color-screen calculators from being used in schools. If someone developed a B&W BMP or PNG viewer for the 9860G, if one doesn't exist already, would this discussion come up? TI used to be far less restricting back in the good old days when they released an SDK for the 83+ when it was released. As you can see, something like a decade later, the Nspire is a totally different beast. Who knows if Casio might go through the same phase?

25 Apr 2012 02:22:27 pm by gbl08ma		Quote
Kaslai wrote: The big difference is just in who has the ability to manipulate the screen: the devs, or the end users. The end users probably don't care if Casio cracks down on third party developers, and they probably wouldn't even know if they did anyway. The consequences of the end users' actions would get saddled on the shoulders of the developers. The solution? Don't give the end user any control. Oh, now I understand the philosophy of Apple regarding software these days. They have a point, indeed. Thank you so much! (and no, I'm not being sarcastic) OK, I think I'm going to leave my Prizm for now and go back to desktop development and perhaps even Android development now that I already know a bit of C. Because the more we develop custom add-ins, the more likely it is to have Casio lock the system down.

25 Apr 2012 02:37:23 pm by KermMartian		Quote
gbl08ma wrote: OK, I think I'm going to leave my Prizm for now and go back to desktop development and perhaps even Android development now that I already know a bit of C. Because the more we develop custom add-ins, the more likely it is to have Casio lock the system down. Well, I feel like that's a bit of an overreaction, although I understand more or less where you're coming from. I hope that you reconsider at some point in the future. Until then, good luck, and I hope you'll continue to regale us with tales and questions related to your Android and desktop development.

New Post	New Topic
Goto page 1, 2, 3  Next