Just wondering if I should go through with this project...

Does anyone have large files on their calc that they don't use that often, but want to keep on the prizm? If so, I can make a compression program to compress files and decompress them to save space. This process cannot be done automatically, such as decompressing an add-in on-the-fly, but is intended for archiving stuff that might not be used for a while.

Only reason I ask is that I don't know how useful this can be or if it is even needed with 16MB of storage space

I haven't been able to fill my memory with anything yet (unless I try to store PC programs on it, but I have regular USB drives for that...) but it might be useful in the future depending on how well it compresses files, how quickly the user can compress/uncompress files and how many add-ins will be created by others (or maybe someone will create an emulator? That would allow us to fill the storage memory with ROMs pretty quickly).

Well, well, well. I think 16MB memory is quite limited specially once you have many add-ins on the calc (in the future, when more add-ins are developed). Since the Prizm has a high-res color screen, graphics in add-ins take a lot of space if not compressed... not to talk about the giant g3a header.

Ideally, a compressing add-in should have multiple compress modes (less compressed = less time consumed compressing and decompressing). Ideally too, it should also compress in a popular format (ZIP, GZipped TAR, well, everything except RAR ) that a PC could easily read.

But before an advanced file compressor, I keep on looking for an advanced file manager/shell... anyone? Because the Prizm's memory menu, like with older Casios, doesn't even let you move files between folders (something I often need to do and apparently my school mates too, as they keep on asking me how to do it - and I keep on answering that it must be done with a PC).

Gbl08ma, regarding the "giant g3a header," that's another reason why we need to start hammering out some shells as soon as possible. Also, regarding the issue of graphics compression, take a look at Tari's fx-imglib.

FWIW, my plan for phase 2 of fx-imglib is a dynamic linker, since I suspect it will eventually be a non-trivial amount of code when compiled. Extending that to libfxcg should be trivial (although only useful for the routines that aren't actually syscalls).

I don't think compressing code itself will be very useful, since graphics have been the main factor in gigantic addins thus far, so a library (eg, fx-imglib) makes the most sense, putting the burden of storage management on addin authors. As far as actual compression schemes go, I considered a Huffman scheme for fx-imglib, but the time-memory tradeoff is rather substantial so I opted for a faster option (LZF) instead, complemented with some higher-level data formatting which should provide better compression.

For me, I am sticking with my huffman compression routines in my newer prizm projects mainly because speed isn't an issue. It'll be extracted into the ram anyways. However, this is not directly related to this project as this add-in will simply compress files. Anyone can grab the routines here.

Agreed. I used EDIT (a text editor) on my 9860 instead of the default file manager for stuff like moving files, etc.

One thing I have noticed about prizm is the possibility to have folders within folders. Older models never had that.

Yeah, the fact that you can have subfolders is a great thing, however, the fact that the OS still only supports files with 8 chars (except the extension) and all capitals is a PITA and is hard to explain since nowadays most systems already support long filenames (and I'm sure Casio's main goal is not to provide MSDOS compatibility).

I kind of have to disagree. The OS does allow files/folders with lower case letters. The GUI doesn't let you change to lower-case mode, but you can create them with the OS calls. That's just a front-end limitation, not a code limitation. Second, in the good old days of MSDOS 5, FAT16 used 8.3 filenames. Windows 95 also used 8.3 filesnames, but provided an extension to the FS that had the long filenames stored elsewhere. Just to point out what I mean: From this, Casio provided MS-DOS compat, but not the LFN trick. (Although the non-stop errors that the Prizm reports under linux scares me :-X )

Yes, I've noticed that on Linux I can't, for example, copy a file over another (overwriting), it will return a I/O error (I'm using the Nautilus file manager, default in Ubuntu). I have thought about this a bit... perhaps the Prizm allows access to the memory in a way that is 100% compatible with Windows but not with Linux?

And IMO when the Prizm was developed, they could have put a (at least) 256MB memory chip in it and use FAT32/VFAT, without increasing the cost of the device anything noticeable (unless this small flash chip is so special that using pendrive NAND instead of it would be impossible? Power requirements perhaps?)

Just to finish with the LFN support subject (although it doesn't really belong in this thread), I found that the Prizm supports LFN, but not on the file list.
If you create a file with a long file name on the calc using a computer, then check the memory contents using the Memory menu, you'll see the name has been abbreviated the FAT16 way. But if, while selecting that file, you press the arrow right key, to show the file details, you'll see the complete name of the file at the top... so the calculator knows how to read long file names, it just doesn't display them in the file selector due to space constraints.

This is a nifty find! Good work!

Would that mean the Bfile_* functions must use the full name, then?

Perhaps Bfile* accepts both long and short (standard) filenames, I guess? Is there someone who bothers to do some testing?