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

I'm not sure how much this helps, but here's how I check for, create, and modify the Tetrizm high scores file:


Code:

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:


...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.

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.

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.

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)

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://ourl.ca/15410/295758



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.

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.

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.

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.



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.

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.

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.

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.



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.

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.

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?

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.

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?

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.

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.