Well congratulations on keeping the website going. I do not think that phones will overtake calculators.
You see phones will never make it in for serious testing there will always be a market for calculators.
Also I do not own a phone believe it or not, yes I have seen them and they look cool but I like a calculator better for serious math. I have no inclination to touch the screen every time I want to type a number.

Libfxcg is by no means perfect.
I would normally just submit a pull request however there is no guarantee that affect people will be aware that it is a bug in libfxcg and not their code and how to fix it. I have long had these fixed in my fork but never bothered to really document my changes. I think having a topic will get noticed by more people so that they can too make these fixes and point out any other bugs that they may have found.
All bugs listed here affect the most recent version of libfxcg as of the time of writing this post and can be found here: https://github.com/Jonimoose/libfxcg
Of course older versions are affected as well. I know for a fact that the linker script fix affects even the old PrizmSdk 0.3 from 2011 located here http://www.cemetech.net/news.php?id=486 I could not see if other bugs affect this version as the source is not included for it's libc and I have not made tests for it and see no need to as it is obsolete.
Lets not limit ourselves to bugs or terrible code that affect both. If you see a bug that affects only libfxcg it is best reported. Really no-one should be using the old PrizmSdk 0.3 from 2011 however should you find a bug that affects it and you want to post it go ahead it may give people another reason to upgrade.
1. fread is broken.
The way fread should work is that every time it is called the data following the read data is read the next call. However the function will always read from the beginning of the file. As of writting the file located here https://github.com/Jonimoose/libfxcg/blob/master/libc/stdio.c says in fwrite
size_t ret = Bfile_ReadFile_OS(handle_tonative(stream->fileno), buffer, n, 0);
However it should be
    size_t ret = Bfile_ReadFile_OS(handle_tonative(stream->fileno), buffer, n, -1);
The only difference is that I changed the zero to a negative one. What this means is that it continues to read where it left off.
2. Linker script does not correctly handle BSS.
When you have static variables in a library you may be surprised to find that global and static variables are not initialized. Fix this by changing
        .bss : {
                _bbss = . ;
                *(.bss) *(COMMON);
                _ebss = . ;
        } >ram
To
        .bss : {
                _bbss = . ;
                *(.bss)
                *(.bss*)
                *(COMMON)
                _ebss = . ;
        } >ram
The reason why this works is that the linker will insert things such as .bss_variable_name when compiled in a library. This puts it in the proper section and upon start-up it will be cleared just like it should.
3. The memove implementation is terrible.
Actually I had worse insults that I was tempted to put but I am sure whoever wrote it makes better code by now and I do not want to hold this against them but
void* memmove(void* destination, const void* source, size_t num) {
void* d = malloc(num);
memcpy(d, source, num);
memcpy(destination, d, num);
free(d);
return destination;
}
Yes that is right, I did not make this code up for slander purposes. It is really in there in string.c
Lets replace it with something better
void *memmove(void *dst, const void *src, size_t count){
//From dietlibc
char *a = dst;
const char *b = src;
if (src!=dst){
if (src>dst){
while (count--) *a++ = *b++;
}else{
a+=count-1;
b+=count-1;
while (count--) *a-- = *b--;
}
}
return dst;
}
The reason it is considered a bug is because if you need to copy something larger than the small heap the function will fail.
4.The exit function crashes the calculator on purpose.
void exit(int status) {
    fprintf(stderr, "TERMINATED (%i)", status);
    // We don't have a clean way to exit (right now), so just crash it.
    ((void (*)())1)(); // Unaligned instruction
}
Actually we do have a clean way to exit. When this function is called there is usually a problem so the user should be able to see the error code. To do this we print the error message and use the GetKey function, from there the user can press the menu key when they are done reading the error code so just replace it with:
void exit(int status) {
fprintf(stderr, "TERMINATED (%i)\nPress menu key to exit\n", status);
int key;
while(1)
GetKey(&key);
}
Also edit the header stdlib.h change
void exit(int status);
to
void exit(int status) __attribute__ ((noreturn));
Also while you are there fix the abs definition so that it matches the source code.
Change
long abs(long n);
To
int abs(int x);
And now add #include <stdlib.h> to the top of stdlib.c
The reason for doing this is so that when compiling stdlib.c gcc knows that this function does not return in addition to the program you compile with gcc and libfxcg that involves exit. Yes we could just duplicate the __attribute__ ((noreturn)) to also be in stdlib.c but I feel that this is a cleaner solution. Also if stdlib.c fails to compile due to you including it, that means the headers suck and need improvement which is why I fixed the abs definition.
5. You cannot actually see the errors.
I don't really consider this a bug per say, however I believe it is much better to be able to see the error messages on screen instead of sending anything from stderr to the serial port.
So replace both fwrite_term and fwrite with
static size_t fwrite_term(const void *ptr, size_t size, size_t nitems,FILE *stream,int col){
static int termXfxcg,termYfxcg;
    char *buffer = alloca(1 + nitems * size);
if (buffer == NULL) {
IOERR(stream, ENOMEM);
return 0;
}

memcpy(buffer, ptr, nitems * size);
buffer[nitems * size] = '\0';
const char *outp = buffer;
char *eol;

// Loop over all lines in buffer, terminate once we've printed all lines.
do{
eol = strchr(outp, '\n');
if(eol) {
*eol = '\0';
}

// Cast to wider type for correct pointers
PrintMiniMini(&termXfxcg, &termYfxcg, outp, 0, col, 0);

// CR/LF if applicable
if(eol){
termXfxcg = 0;
termYfxcg += 10;
outp = eol + 1;
}
if(termYfxcg>=200)
termYfxcg=0;
}while (eol);
return nitems;
}
// TODO make ptr, stream restrict for optimization
size_t fwrite(const void *ptr,size_t size,size_t nitems,FILE *stream){
if (isstdstream(stream)) {
if(stream->fileno==2){
// stderr: display but red font
//return fwrite_serial(ptr, size, nitems, stream);
return fwrite_term(ptr, size, nitems, stream,TEXT_COLOR_RED);
}else if(stream->fileno==1){
// stdout: display
return fwrite_term(ptr, size, nitems, stream,TEXT_COLOR_BLACK);
}else{
// stdin..?
}
}
// TODO this must be able to fail, but how?
Bfile_WriteFile_OS(handle_tonative(stream->fileno), ptr, size * nitems);
return nitems;
}
Now in stdio.h remove the lines that say
unsigned short termx, termy;
6. fopen is also broken.
It is common knowledge that forgetting to null terminate a string that should be null terminated will cause a bug.
Look for:
Bfile_StrToName_ncpy(chars16, path, plen);
and replace it with
Bfile_StrToName_ncpy(chars16, path, plen+1);
This will null terminate the string.

Well yes you did point out that an old version of mine is fast http://www.omnimaga.org/casio-prizm/(prizm-c)-mandelbrot-set/15/
However this should be even faster. Also if you are wondering it did not take me that long (since the time of the my previous post) to come up with a new version, I just forgot about the project and decided to improve it today thus bringing a better explorer.

That code you propose is very slow. Here is a faster way. I originally posted this at cemetech's useful function topic for the prizm but this code will work for any thing that uses rgb565 data. To port it change:
   unsigned short*v=(unsigned short*)0xA8000000; to wherever the framebuffer is.
/*Note it is up to the caller to ensure that alpha is in range of 1-31
 * For a value of 32 or greater just don't draw the image
 * For a value of 0 use a plain mask function that does not take into account alpha
 * Also make sure width is a multiple of two*/
void CopySpriteMaskedAlpha(unsigned *data,unsigned x,unsigned y,unsigned width,unsigned height,unsigned maskcolor,unsigned alpha){
unsigned short*v=(unsigned short*)0xA8000000;
unsigned* VRAM,w,alphai;
width/=2;
v += 384*y + x;
VRAM=v;
alphai=32-alpha;
maskcolor|=maskcolor<<16;/*Note I have decided to do a minor tradeoff for speed. Make sure your alpha pixels are multiple of two*/
while(height--){
w=width;
while(w--){
unsigned color1=*data++;
if(color1 != maskcolor){
/*Note this is based on the source code of Fblend's function fblend_rect_trans_16*/
unsigned rbg_source, grb_source,temp1;
/* Split up components to allow us to do operations on all of them at the same time */
rbg_source = *VRAM & 0xF81F07E0,
grb_source = *VRAM & 0x07E0F81F;

/* Multiply the source by the factor */
rbg_source = ((rbg_source >> 5) * alpha) & 0xF81F07E0;
grb_source = ((grb_source * alpha) >> 5) & 0x07E0F81F;

/* Split up RGB -> R-B and G */
temp1 = color1 & 0x7E0F81F;
color1 &= 0xF81F07E0;

/* Multiply the source by the factor */
color1 = ((((color1 >> 5) * alphai) & 0xF81F07E0) + rbg_source) & 0xF81F07E0;
temp1  = ((((temp1 * alphai) >> 5)  & 0x07E0F81F) + grb_source) & 0x07E0F81F;

color1 |= temp1;
*VRAM++=color1;
}else
++VRAM;
}
VRAM += (384/2)-width;
}
}
This code will actually handle a range of 0-32. Even though this function is fast it is faster to not draw the image (value of 32). Or just draw the image using mask function that does not worry about alpha (value of 0).
It admit to getting part of this code off from Fblend an open source project as you can see in the comment I put in the code. One good thing about the code is that it does two pixels at a time. However I decided to remove the checks for non multiples of two to further increase speed given the fact that you can just fix your image if needed. Also make sure that the alpha pixels are multiples of two. Also I found an interesting article talking about a few rgb565 tricks you may want to check out http://www.cprogramdevelop.com/4562354/

Alright good to know. I do not have any plans to tamper with exam restrictions.

Where did you hear that? Has a Casio employee said so?
You do realize like many other graphing calculators you can cheat using only pre-installed software.
Why would this matter?

Download here http://www.casiopeia.net/forum/downloads.php?view=detail&df_id=147
Edit sorry to release a new version so soon but I just noticed that in certain instances libpng would output a harmless warning however this is annoying as it overlaps the image so I fixed the cause of the warning.
The source code can be found here https://github.com/ComputerNerd/Casio-ImageView
===========================================
Casio prizm PNG viewer
===========================================
This is a png viewer for the casio prizm.
It uses libpng (which is paired with zlib) to decompress a PNG file.
When you load a png file it is resampled to fill the screen but aspect ratio is preserved.
As of now a simple bilinear filtering is used
but if there is intrest I may replace it with something better.

The version you downloaded is version 1.0
It is likely that there will be versions
so if you notice that I post in the thread
see what I put it may be an update.

============================================
Controls
============================================
You will see a file browser on startup use the arrow pad to select a file.
Then press either F1 or EXE to select the PNG file.
Press any key except menu (which actully takes you to the menu)
to go back to the file browser.

===========================================
Notes and tips
===========================================
Since the casio prizm does not have lots of memory run pngout
on the images before putting them on your calculator.
I have included instructions on how to compile libpng and zlib here:
https://github.com/ComputerNerd/Casio-ImageView/blob/master/Compile%20Libpng
Following these instructions gets you a libraries (libpng and zlib)
that you could link against your add-in.
If you want to use a png in an add-in a good option would be to make a 16bit 1 channel image containg rgb565 data.
I however would not use png instead I would just use zlib directly with a simpler image format.
For example uint32_t width,uint32_t height, deflate compressed sequential rgb565 data created by zlib's deflate(2) function.
But if you feel comfortable with png that is an option.
Also you can store the pngs as a const array it does not need to be a file. I just used files because this is an image viewer.
The purpse of this program is simply to show off how capable the casio prizm is.
The PNG image format is well know and I think some people wrongly precive it as a very ram intensive thing to decode.
Libpng can output a row at a time or N amount of rows. When width!=384 or if height>=216 then the image is scaled
Ony enough ram to hold 2 rows is needed which is 6*width bytes of ram. I use bilinear scaling that is why two rows are needed to be read.
After the code interoplates the pixels the resulting pixel is converted to rgb565 and sent to VRAM.
When the width==384 and height<=216 a buffer is created and the image is read all at once
then simply converted to rgb565 and send to VRAM