Thanks for guiding me on this.

From my discussions with gbl08ma I believe he developed it on Linux with no guarantee of it being compilable on Windows... I am keen to compile it on Windows so will give it a few tries especially now that I know about GCC ports for windows.

However if someone with working Cygwin on windows knows for sure this add-in will not compile on windows please let me know so that I do not waste too much time trying this please.

Thanks again for the help with this.

thanks for all your post before. I get
Code:
but trying
Code:
gives me
Code:

It's my first time ever using this interface - would you know what I may be missing (original Makefile is the above folder and everything else untouched as it comes from gbl08ma's archive on github). Sorry I'm such a non-Linux person

Sorry I am not helping much; I'm busy studying for finals.



Windows compilation is not supported (but I don't mind helping, just don't expect me to guide you through all steps because I don't use Windows for Prizm development). In fact, even when on Linux, one will run into problems compiling because my Makefile expects a special version for mkg3a with support for eActivity strips. But that's a matter of removing the unofficial mkg3a options and it should compile.

Also note that for best results (perhaps to get it to compile at all?) you should use my libfxcg fork, at https://github.com/gbl08ma/libfxcg (this also means you'll need to compile this libfxcg yourself). Header files should also come from this libfxcg.

Thanks, gbl08ma, and good luck with the exams. 3 left till next Friday on my side and I'm a free bird after this! I wonder if I will use the calculator so much after the exams but I do love coding so will be happy to especially with your and Lionel's help. I will quite certainly post an update for my Lock add-in and finally submit the message add-in to the archives here.

Sorry I'm a bit hopeless with Linux side of the things still - let's find out if we will be able to compile your add-in after the exams.

Good luck again.

A quick question, gbl08ma, while you are here - how difficult would be reading gif format - i am hoping to develop a serial link communication parsing gif files to be displayed on prizm...

Also would pdf viewing be achieved similarly to your image viewing functionality or is it completely different

Thanks

GIF should be possible, since it's a format of other era and at the time there wasn't as much processing power nor memory as there is now, so it should be doable, I think. It's very different from JPEG and PNG, so I don't think you can reuse any code. You'd need to write your own GIF decoder or find a library that does it in acceptable time and memory usage.

Did i understand correctly that you used libraries for jpeg and png? And if so would the following https://hackage.haskell.org/package/UTFTConverter be able to be ported into your viewer to generate 565rgb values? Thanks

You don't need a library to convert pixels to rgb565. It can be done in one line of code. If you want to decode GIFs first note that PNG is better so use that if possible. If you insist on decoding GIFs you can use a library to decode it. Maybe this: http://giflib.sourceforge.net/gif_lib.html will work.

Thanks, i have just posted on Mateo's pngconv topic before seeing your reply.

I will look at it once I decided how i will proceed on the serial communication side (linking to a mobile app or straight to wifi or something in between).

For image viewer, yours or gbl08ma's one, do you think adding pdf viewing is feasible please? Or will there be something which will cause particular issues perhaps with scaling or fonts or similar - i'm not quite sure how pdf works but frequently it seems like they use something similar to vector graphics.

Thanks again for all the comments

PDF is an entirely different beast than images, it even has its own scripting elements for interactive stuff. I get that you only want a basic viewer that wouldn't support any of that stuff, but I'm not sure even that will fit within the memory and processing power constraints of the Prizm. I'm having a hard time finding any libraries, even commercial ones, tailored for embedded systems so we could have an idea of the minimum memory requirements.

Your best would be http://mupdf.com/ , that's what was used in a viewer for the Nspire series. However, the Nspires have over ten times the RAM we have available on the Prizm, and generally their CPUs are faster, too. You would probably also end up with a giant add-in that takes up a quarter of the Prizm's storage memory. The font rendering libraries alone will be heavy, but if I remember correctly, ProgrammerNerd already ported one, so that part would not be the hardest one.

The only way I could see this being done would be by developing a reader from scratch, with the intricacies of the Prizm's memory model in mind, but usually when you reduce memory usage, you trade it for more computing time (see also: paging is slow/unfeasible, etc.).

Personally I'm willing to write a PDF viewer off as technically impossible - but then again, I'm not too knowledgeable of the format in question, so I may be in the wrong here. Of course, tricks like rendering on a computer and transferring the result over the Prizm would defeat the point and be pretty much useless

Thank you for sharing these insights

I have tried MuPDF myself and it needs more heap.

Also yes freetype2 works very well on the Casio Prizm. Here is the code if anyone is interested in using Freetype2 on the Casio Prizm for high quality anti-aliased font rendering: https://github.com/ComputerNerd/libfxcg-copyleft/blob/master/examples/Freetype2Example/main.c

I did some research and it seems the bare minimum for MuPDF memory usage is over 5 MB for a one-page PDF, so even if the whole RAM could be put the use it would still not be enough.

I highly doubt there's a more memory optimized library than MuPDF (at least one that will render most PDFs), and from what I saw, PDF support requires some assets like default fonts. The add-in would take a great chunk of the storage memory, not leaving much space for PDFs, which by themselves are not that small.

And judging by the speed of the image viewers built for the Prizm, PDF rendering would be even slower, to the point of being unusable.

That's good to know, thank you, gbl08ma

Thanks, ProgrammerNerd, for the font routine as well, did you do it because of the pdf plans, or what type of application you had in mind when doing it, some text renderer? At what circumstances it is most useful - with very small font size? or is it for better scalling of fonts, ie something more granular than existing font sizes on Prizm?...

Thank you all for your answers

It works well for any size. You can have one character fill the screen or extremely small text. I used it for a game for a contest that I never finished. Another advantage of Freetype2 is anti-aliasing. This means the fonts look better. Here is where I used Freetype2 https://www.cemetech.net/forum/viewtopic.php?t=10930

While your attention is directed at that thread note my comment about the LZMA image viewer that is faster than PNG and the files take less memory. Would anyone bother using an utility before they put images on their prizm to view it? Maybe it should be a standalone application.

Thanks - that looked amazing in deed. I have just looked up LZMA and seems connected to 7-zip - this gives me an idea of compressed e-books in such a format entirely - so something like those utilities which exist already to reformat ebooks or pdfs could be possibly made to create a file which prizm could render nicely and quickly using the LZMA compression you mentioned for images and Freetype for font rendering and scaling - I can see it being totally awesome... but I cannot imagine how much work it would involve

Yeah, the LZMA compression settings can be scaled down enough to cope with the RAM limitations of the Prizm, and even at those settings, the LZMA compression ratio handsomely beats the ZIP generation or PuCrunch.
However, even if you have a fairly powerful CPU (for a calculator, that is), watch out for the decompression speed... On the TI-68k series, the C LZMA decompressor was about 20-30x slower and over 3x larger than the fast/larger ASM PuCrunch decompressor, and about 10x slower and over 6x larger than the slow/small ASM PuCrunch decompressor.
Suffice it to say that it never got past the experimental stage, though the decompressor remains part of the GCC4TI program-specific launcher programs, https://github.com/debrouxl/gcc4ti/tree/next/trunk/tigcc/starters .

The main advantage of formats like JPEG and PNG is that they are more or less universal: there are thousands of programs to read and write them, and they are the de-facto standards for lossy and lossless images, respectively. Of course, they aren't the best formats possible, let alone the ones most well-suited for the Prizm.

However, the idea with this image viewer was to free people from the G3P proprietary format, and so it didn't make sense to force them into another proprietary or app-specific format. Of course, people are free to come up with other solutions that read other, better image formats (say, WebP) or app-specific formats that are carefully optimized for the Prizm.

The file compressor in Utilities uses a app-specific format which in fact is no more than a header followed by data compressed with an algorithm based on LZSS, which is a derivative of LZ77 (like DEFLATE and LZMA). It compresses the file using a series of pairs of window and lookahead sizes, decides on the ones that yields the smallest result and finally compresses the file with those settings, saving them in the header. This is the library used: https://github.com/atomicobject/heatshrink

You could LZMA compress a text file. You may need to break the text file up into parts other wise you will run out of ram. Maybe you could even write a simple HTML viewer or find a library for it.

Also in regards to speed of course it is not super fast but it is faster than decompressing a PNG. Note that some people may want a higher compression ratio even if that means that decompression will be slower.

Yes a PNG/JPEG viewer is more convenient but if you have images that need to be used a lot it may be worth it to make the conversion. Also I do like the heatshrink solution. I have used it on real hardware and found the performance to be good.

It's been almost three years since the last release. This add-in had some graphical glitches when running in the latest Prizm models (fx-CG 50 and Graph 90+E); this has been fixed.

The latest version is now available from my server (links in the first post), and it should be accepted into the Cemetech archives at any moment.