Introducing the start of the Walnut shell for the Casio Prizm, fx-cg10/20. Walnut is primarily a shell designed to run executable programs written in assembly, C, C++, and any other compatible compiled language. The goal is to make life easier for both the developer and the user.

For the developer:
No longer will you have to deal with the complicated g3a app format which not only limits your application's run time but also imposes heavy security and an over sized header. Instead you now have the gxp format which is far more flexible and smaller. The layout of the header is based off the packet design by Qwerty.55 which allows for changes to be easily made in the future along with allowing the developer to include only what is relevant to their program. The gxp format includes many optional fields that affect the way the program is ran such as physical/virtual execution and flash/ram execution. You can even set the program's origin and the designated cpu, memory, and peripheral clock before running too. With Walnut being heavily based off of popular computer OS's such as Windows, Linux, and Macintosh, commands in the shell are based off a terminal/command line. This terminal is normally invisible for the users sake but allows for many options on data being passed to a program. To allow the efficient development of programs a Walnut SDK is currently being built. It will be paired with the gcc compiler/assembler and will include a program to convert binary files to the gxp format. Later on this will become a gui based program that will easily manage everything from compilation to distribution. To make programs more efficient Walnut will heavily manage the virtual memory for the program. What this will mean is that because of the virtual layout, programs' executable data will lie on a continuous space while the data has its own space which will make the operand and instruction cache faster. Lastly Walnut provides a large number of built in routines that will cover everything from flash to usb and from sound to data compression. There is even a simple syntax for including and calling external libraries which will have the extension of gll.

For the user:
Although Walnut is primarily designed for running programs it also excels at opening many files too. An example is that whenever a picture file is selected, it is automatically sent to the default picture viewer/editor. Or by right clicking you will get a list of programs registered to open that file. If you're used to any major computer platform you will already know how to navigate Walnut and will find that many operations are the same. Selecting files and folders can be done from a simplistic terminal or from a customizable gui. Loading new programs couldn't be easier due to Casio's built in FAT and usb support. Walnut makes use of the FAT format allowing programs and files to be easily stored in folders. Because the Prizm is a calculator and is limited on memory, compression is very important. Over time Walnut will support a variety of mainstream compression techniques to allow the user to keep all their favorite programs at once. Lastly Walnut will help manage organization by storing the proper files in their proper folders. An example would be that a new bmp image would be automatically sent to the pictures folder.

I don't know yet what I'd pick, but whatever it is it would have to play from one of my calcs. Maybe if I make a Prizm music player someday then that will be feasible.

Dumping the flash drive only extracts the upper 16 mb of the flash chip. If the FAT table was reformatted it could be possible though to use the extra 4 mb that the OS doesn't use, but that could cause incompatibility issues in the future. I think the best bet is to either wait for Casio to make an SD card version of the Prizm or we make a usb flash drive application.

I'm still a little concerned about this. I happen to have a quite powerful desktop computer that I use for gaming. Unless Windows 8 proves to show greater performance then Windows 7 I won't upgrade. I find this unlikely as Windows 7 was the first Microsoft OS ever to have greater performance than its predecessor. But there is the possibility with this OS being optimized for lower power PC's that performance might be increased. I really don't care for all the fancy UI features that Vista brought in and were luckily dropped when 7 came out. It appears that Windows 8 will also hopefully lower the UI appearance in order to allow lower end PC's run the OS. My last concern I have with Windows 8 is that there appears to be no big technical advantage. Windows Vista allowed Directx 10.0 which only the most recent games use and Windows 7 allowed Directx 11.0 which even fewer games use. I don't see any Directx 12.0 yet nor any other major advances in the OS.

So the first routine switches the mode from privileged to user it appears. I do have one question, how would you get back to privileged mode then if the instructions to access the SR are disabled?

Don't give your source file and your executable the same name. so do something like

prgmHALLO
.HELLO
Disp ("Hello")
Pause 1000And it sounds like you're compiling to an app. Make sure under options you selected no shell or the shell of your choice.

A mini-Prizm-SDK (version 1.08).

New with version 1.08:
Insight: direct access of the serial I/O-pins (measured a 17 kHz symmetric and sharp edged square wave with my scope, though higher frequencies are possible).
BTW: I went through a world of hurt, hunting this down!

Nice what is the address for direct line access. I had tried port Q earlier, but wasn't getting any feedback. I will though be testing the SIOF later because that can play .wav files.

Cool to hear

That reminds me, has anyone tried 3D polygons on the Prizm yet? A demo would be nice.

I could try in C, but it would take a little while for the code to get running, but if BASIC is good enough I would be more than happy to make a demo of its "speed"