Wow! Thanks!

This would be for shells and things, similar to how TI-OS can't run some assembly programs designed for shells.

This seems to be nice and flexible. There are a few things I noticed, though...

You say that the ID bytes are bytes 1 & 2 of a packet and that the size bytes are bytes 2 & 3. Aren't the size bytes supposed to be 3 & 4?
What is the purpose of the packet of the type 00 00?
Why is the 00 02 packet necessary? Don't we already know the name of the file? Also, limiting files to 8 characters is a bad idea. The Prizm OS can handle more than 8, but it usually only displays 8. (This also applies to the 01 05 package - limiting ourselves to 8 chars might be bad.) And why do you use FF instead of 00 as null?
In the 00 03 packet, why is 55 needed?
Is it necessary to have both 00 01 and 00 04?
For 00 11, I recommend that you use some kind of standard, for example ISO 639-3.
Are shells allowed to run programs even if the 00 12 checksum isn't present? I think it's a good idea to make it possible, but to prevent programs from running if there's an invalid 00 12 packet.
Is it possible to have 16-bit icons in 01 01? And can there be more than one 01 01 package, in case the file includes multiple icons for different viewing modes/shells?

Okay I like some of the changes you made, but I question the need for defining Java and Lua programs in the header as wouldn't those be in .class files and whatever format Lua is compiled to. The shell itself can detect .class files and can pass those onto the virtual machine for interpreting. There are also many features that the shell would have that would remove the need for a complex header. Really I thought this header was just for executable programs and every other file type would be handled just like windows does. In fact the idea was to model the shell around the Windows Explorer and how it handles files. And within the explorer would also be a terminal which would handle all of the operations the user does. This just like any computer would be hidden if the terminal is not open.

Other features which for the most part are not included as of now, but will be featured in later versions are:

Hooks: An example of where this could be used is if a .jpg file appears in the current directory. Instead of using the standard icon for .jpg files a hook could be triggered corresponding to either the shell itself or another program that has registered a .jpg hook with the shell. The .jpg handler could then return a icon that is a scaled down version of the actual image data. Other example could be in java where if the cursor is held over a .class file the .class handler could return information such as author and company to be displayed, this information being found by parsing that particular file. The last example is a right click hook. Now if you have Notepad++ installed on your computer whenever you right click on a file you will see the option "Edit with Notepad++" a similar feature could also be setup with hooks. As you see the possibilities are endless.

Terminal: Also known as a command line on Windows systems. You may not think of it much, but when you click on a cpp file on your computer, hidden from you the text "C:\Program Files (x86)\Notepad++\notepad++.exe C:\users\z80man\documents\myprogram.cpp" is being typed into the terminal (minus the z80man part ) The same thing would be done when opening a file or running a program from the shell. You even have the option to open the terminal yourself and type commands or too run your own batch files.

Libraries: Okay one of my biggest points has been cross-compatibility and backwards compatibility for the Prizm. Along with this has also been location independent code. When using multiple libraries in a program location independent code can pose issues when these are random, often user made libraries, that the shell has no prior knowledge about. To deal with this a set of shell calls are being developed that upon startup of a program, the program will pass the names of libraries and their given ID (this can be any number the programmer wishes and is not defined in the library, but in the program that way two libraries don't end up both having 42 as their ID) Then whenever a library call is made (which is done in the exact same manner as the OS syscalls are done except it is a different address) the stack is read for the ID number and the shell will then call the proper  routine from the proper library.

Compression: Because there is very limited space available in flash it is important that programs use as little space as possible. Part of this is handled through the powerful array of malloc() calls available so that the programmer does not have to have large areas of 0's in code.  this is also handled by the emphasis of runtime libraries which reduce redundant code. The other thing is to encourage compressed files and folders. An example of a compressed file would be jpg's for images as they are often almost a third smaller than their bmp counterparts. Now because handling jpg's can be difficult in code shell calls can be devised to return a pointer to a bmp after being passed a pointer to a jpg as an argument. An example of folders would be zip's tar.gz's tar.xz's and so on. To make things easier for the programmer shell calls to handle these folders would be required. 

Multi Tasking: This feature is still far off from being implemented  anytime soon, but the idea would allow the execution of multiple programs and opening of multiple files. The advantages could also be seen if a windowing system could be setup too.

Wobbly Windows: I make my case clear

Hi,

I am looking for someone who can make the Algebrator program work on the Casio Prizm Calculator.

Algebrator is a .exe file type. The prizm needs a .3ga file type. Here is the link to the program Algebrator http://www.algebrasolver.com. I have the algebrator program I can send to anyone willing to give it a try. The Algebrator program is 6.0 mb and does not need to be installed.

welcome to the forum
however, I think that this is not the right section to be posting this
I would try learning C/C++ or SH3 assembly and make a port, as there is no .exe to .g3a converter.

Holy walls of text batman!

z80man with hooks, would it allow things like xLIB where some BASIC commands functionality are modified to do things like sprite displaying?

The entire interpreter? Or do you just mean certain functions like Locate and math commands that are not useful in games?

And yeah I am curious how many languages will there be. We need one that is easy but fast for sure, because notice how few Nspire developers there were until Lua arrived.