Coming back here from another thread, AHelper pointed out that we have two kinds of storage available to programs, though the BFILE_* and MCS_* syscalls.

Our stdio implementation currently assumes BFILE_*, but it would be good to be able to handle either. I proposed adding another flag which fopen may accept (AHelper says 'i' would be reasonable), but there's also the option of URIs such as 'ram://foo.txt', although I really hate that concept.
There are probably other ways to handle it too, but I'm liking the idea of a flag to indicate which storage should be used (defaulting to flash).

Remember that one day, SD cards or other types of external memory may be supported, if not before, in newer Casio fx-CG models. So make sure the implementation allows for different types of storage.

Yes, ram:// sucks. I only put it in because, well, unix directories use /mnt/* or /media/* for other partitions and windows does C:\* D:\*, etc.. It isn't always platform independent. The 'i' flag is probably the best option as it will do what you expect. If you don't use the i flag, then it saves it to flash storage like you normally would.

My question is: What about the file size being required at the file creation? How does the current fopen handle it? What would be nice is to find out why that is required. From GlassOS: my best bet is that the OS doesn't watch file pointers. GlassOS requires an fopen and an fclose so that it can properly mark the size of the file. Is the prizm just making sure that you cannot corrupt it? If so, is there any way that we can manually create files by raw IO? Does the prizm even have a way to handle a corrupt fat (or whatever it uses)?

It has an "Optimize" function in the Memory menu, which, based in my experience, cleans leftovers in order to free the disk space you lost by working with files, and also speed things up a bit.

From the CG20 manual:
"Storage memory can become fragmented after many store and load operations, causing
entire blocks of memory to become unavailable for data storage. Because of this, you should
periodically perform the storage memory optimization procedure, which rearranges the data in
the storage memory and makes memory usage more economical.
• Note that the calculator performs storage memory optimization automatically whenever you
perform a save operation and the calculator discovers storage memory is running low."

I'm sure this doesn't handle a highly damaged filesystem, but it may help a bit and solve less serious problems (in order to avoid serious problems later).

That's fragmentation, not error checking. TIOS lets you garbage collection, but it doesn't handle a corrupt archive. Can anyone confirm that corruption is fixed? (I don't know how it will be corrupted in the first place :-X)

Good point. It's not hard to add additional flags upon adding support for new backing stores, but it may also be a good idea to have some sort of 'fsetdefault' function to specify the default location for file operations to use.

It doesn't. I'll probably treat files like dynamic arrays with reasonably large initial values, recreating the file with a larger size when necessary. For now, you can't create new files.

What is the max filesize allowed? Don't forget that you have a 512KB stack space. (Your program uses some of that, since it is the stack, by the SDK doesn't give you the entire space.) I don't know how you would allocate that space, since it doesn't have a heap...

#define MAX_FILESIZE 400000
#include <stdio.h>

(inside stdio.h)
unsigned char FILE_BUF[MAX_FILESIZE];

?

More like _impl_file_buffer in stdio.c. In any case, file buffering should be handled on a per-file basis, not with a fixed global buffer like that.

If tests indicate that it will be useful (very likely), I'll implement support in crt0 for using a chunk of the stack as heap, and tweak malloc to support using both the system heap and the one on the stack. For now, it's not necessary, but I know there have already been projects that could have benefited from more heap space, so that's on my list of possible improvements.

Can you have it dynamic? For ex, I have a game that loads a lot of resources to the stack, so it would need to be dynamic. If you can make the stack formatted as a heap (optional), then that will solve problems. Otherwise, if the max filesize is small enough that you can fit it using a regular malloc (if there even is a max file size).

If there is no max file size and someone wants to save a 2mb file, then fopen and such will not work at making the file.

That's the logic behind putting stack reservation in crt0 (or I suppose crt1..) rather than libc itself, as that allows you to specify the amount of space to reserve (if any) at link time.

It'll work, just inefficiently. I never said we'd store the whole file in memory, just that the file could be transparently resized as needed by recreating it (then closing the handle commits the file and drops any remaining unused space).

I mucked about with headers so disp_tools.hpp should work now. You should really use <fxcg/display.h> at this point, though.

Haven't gotten to keyboard.hpp just yet, but that's an easy temporary fix for you. Same case as display, you should plan to use <fxcg/keyboard.h> once it's implemented.

I wasn't able to replicate the conflicting types error via tweaks to the example project, so I'll have to see your code to figure it out (assuming the latest build doesn't mysteriously fix it).

Your CFLAGS are all wrong though. These should be reasonable:
Code:
The one you really don't want is -nostdlib.

A bump here, I came up with a reasonable way of handling file resizing and writing.
Writing to storage memory (Bfile_*) is slow and limited in that files can't be resized, so using storage memory directly is a no-go. It could be mitigated by having dynamically-resized buffers for each open file, but managing buffers is a non-trivial amount of code and could easily exhaust the heap.

What I think is the way to proceed: put all open (and writable) files in main memory (MCS_*), which has many fewer restrictions since it's backed in RAM rather than flash. On closing a file, it will be moved to storage memory.

This solution addresses how to handle the distinction between storage and main memories (by not exposing main memory), the previous solution for which was reasonable, but required a lot of code and would have been a bit unusual in cases where one wanted to move a file between the two regions.

I haven't done anything with this yet mainly because I haven't grokked the MCS functions, but I'm currently planning hand off much of the MCS handling to Merth, as he says he already knows how to use it.

Do you plan to give programmers any control over that process, and if so, in what way and to what extent? On behalf of the Prizm programming community, my continued gratitude for the effort that you're putting into this!

No definite plan for such, but it's a possibility.

Opening a file for reading only shouldn't involve any movement of data (it'll just wrap the Bfile syscalls), but I could make it possible to inhibit writeback to storage memory on close, which could be useful in some situations. A flag to force opening a file in MCS may be similarly useful.

So, changes for the pycompat branch of libfxcg... Changes for stddef.h:
Code:

In Bfile_SeekFile_OS, change line 3 to
Code:

Make a new file Bfile_TellFile_OS and put in
Code:

Here's the patch for the headers:
Code:


-------

For anyone not looking at github, I created a cmake build system that can make addins in a simpler way:
Code:
That will compile all source files and produce a .g3a. I can post the Platform files once issues are resolved (when to projects are specified at once).

Just a note, the Jenkins builder for libfxcg was down for a bit because I moved to a new server and I didn't have the time/inclination to configure a cross-compiler on Debian. I ended up configuring another machine that already has the compiler installed (happens to be on Arch, where my AUR packages work fine) as a builder for libfxcg (Jenkins' support for remote builders makes me happy, since it was very easy to configure).

If you weren't aware of this: http://jenkins.taricorp.net/
Configured to automatically build libfxcg when changes are pushed to git, so you can stay on the cutting edge with relative ease.

Can someone release a new sdk package with libfxcg installed? Thanks in advance.

Since this topic is sticky and filled with libc, posting this here:

µClibc, µClibc++, and glibc all use LGPL, GCC uses GPL. libgcc has a GCC Runtime Exception, so not a lot of worries there

For LGPL, as I have found, you may statically link and distribute the final linked binary so long that the recipient is able to do linking on their own. This requires the .o object files to be distributed with the add-in (or any other object code that is not linked to the lgpl libraries)

Can we just distribute the C source code for uclibc along with the software that uses it, instead of the object files? Since I don't like having those on git repos.

You could, but it would be a lot of extra code. Might make the most sense to use a git submodule or such.