Walnut Shell
For the Casio Prizm


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.

This sounds great. Is everything mentioned here done, or just speculative?

Not finished yet, but most of it is near completion. There is still a lot of other work to do outside of the main app part when it comes to documentation and the SDK.

What do walnuts have to do with anything?

D'anyway, good luck on this project. ASM shells are important to any calculator

In a nutshell (heh): a walnut has a shell, and now so does the Prizm. Play on words, silly.

But more seriously, sounds awesome

z80man, Doors CS calls that program/file association thing the Associated Program system, FYI. You writing this topic is making me want to get started on Doors CS PSE, but I'm afraid I have some other projects I need to finish first. I hope you'll throw us some screenshots soon!

*bump* Would you mind keeping us abreast of your latest breakthroughs? Anything new to report? I understand if time commitments are forestalling it; I certainly am in such a position.

My latest work now is that I have just about everything I need now to compile a program into a format Walnut will accept. Now I'm going to make a special build of Walnut next weekend that will take that program, load it to virtual memory, and then run it. If all goes well there I should have a rough public build of Walnut a week or two later.

That sounds great, I wish you the best of luck! Are you making a sort of linker, similar to Tari's mkg3a? Perhaps some of his experience might be helpful towards that goal, in fact? Or are you trying to construct a compiler/linker independent of the GNU toolchain?

The linker is similar to mkg3a and is almost done now. What I am still working on is building a gnu toolchain that is Walnut compatible. I'll post the results of that soon.

One idea I've toyed with some was adding g3a as a binutils output format somehow (I haven't looked into what would be necessary to do that, as it's probably more work than I care to expend), so you could not only direcly emit the addon when linking, but objcopy could be used to embed resources in the addon with relative ease, allowing one to skip a preprocessing step for images, etc.

Maybe that's similar to what you're doing, though.

z80man, would you not just be able to use the PrizmSDK with your own linker, since it already has proper headers, library flags, and all those fun things for the Prizm?

Yes I can use PrizmSDK with my own linker but part of the reason why I was toying around with building my own toolchain was so that I could make linux, windows, and mac builds but for the time being its probably fine to stick with windows because it works on linux also. And with regards to the linker I've been finalizing the gxp format into a way that's very similar to the fundamentals of the png packet format. Right now my linker is all command line driven but later I will want to design the Walnut SDK around a gui interface that can simply build makefiles that can be used with make.exe. That should hopefully ease up development when very customized settings are required for building.