Welcome back, Omnimaga!

I'm working on a litle project from a long time ago (but as I have to deal with IRL and my personal motivation, the project progress a bit randomly ), but I only released informations about it on Planète Casio forum.
Now, it's enought mature to begin to introduce this project on other communities, I think.

So I will not say here all I said on french Planète Casio topic, but I will try to summarize main informations, and of course to reply to any question if something is not clear.


FiXos is a kernel, writen from scratch to work on fx9860 and similar calculators. I would like to support all the SH3/SH4 models, but for now I prefer to fully support the only test model I have (fx9860G SD).
It's a UNIX-like kernel, which will try to support most important UNIX paradigms (device management, VFS, main syscalls...), but the goal is not to be 100% compatible with any POSIX version, only to be enought close for main usages.
Once the kernel is running, no more part of the Casio's OS is executed, and the kernel is fully independant of any other software.

For now, the kernel is never executed from the EEPROM directly!
It will not replace Casio's OS definitively, and it is copied on RAM before to be executed. So a simple reset of the calculator will allow to return to Casio's OS.
Later, it may be interesting to write it on a part of the EEPROM (to avoid heavy RAM usage before any user code is running), and maybe to redirect the Calculator reset code to the bootloader, to choose on which one to boot after a reset. But for now it's too much dangerous for nothing, so RAM is our best friend!


From few days ago, the project includes an independant bootloader, which take the form of a G1A file. It has its own code to access efficiently to the SMEM filesystem, and use Casio's OS "syscalls" to display a menu. The whole bootloader is configurable using a config file, to change global properties (default selected entry, quiet mode or interactive mode), and individual entries content (kernel file, kernel arguments, type).
This booloader is able to prepare and run any ELF file, so the kernel is an ELF binary (with minimum informations to keep a small binary).

All the kernel, userspace tools and the bootloader are designed to be compiled by GCC toolchain for SuperH processors. It's also why the ELF file format was chosen : it's a very powerful binary format, and is now used on almost all UNIX-like and other OS. Any modern compiler (so, not the Renesas one...) is able to output ELF binary.


The kernel itself is still young, but begins to be interesting and partialy usable.
It takes advantage of the modernity of the SuperH processor, with virtual memory, separation of adress spaces between processes, and all embeded modules like SDHI for controling SD Card, USB device controler...

Main features for now are :

• Virtual File System (VFS), which allow to use a uniform interface for any filesystem, and to mount any existing filesystem on any directory.
• Casio's SMEM filesystem implementation, in read-only (based on reverse engineering, but hundred times faster than the Casio's OS implementation...).
• ProtoFS, a minimal filesystem in RAM used as root filesystem, supporting creation of directory and device nodes.
• Virtual Memory translation, depending to the current process address space.
• Dynamic device management, using UNIX-like concepts (a device is registered dynamicaly to the kernel using a unique "major" number, and is free to implement any number of "minor", each one containing a functionality), which can be accessed in userland using filesystem device node with corresponding combination or major/minor numbers.
• Early log function (wrapped on a printf-like function), targeting the T6K11 display driver, allowing to print some informations during first step of kernel boot, before any VFS and high-level devices are initialized.
• More advanced terminal access with corresponding device, usable through /dev/console file.
• USB device protocol abstraction, enought flexible to allow writing plateform-independant USB class implementation (and of course the implementation for 7705's USB controler)
• Implementation of USB class "CDC/ACM", to use USB as a serial communication (accessed as a COM/ttyS on the host), which is used as a device, linked by /dev/serial. It's so possible to communicate in both way with a computer, without any additionnal driver (as CDC/ACM are reconized by main OSs), and for example to use hyperterminal-like (gtkterm works fine) to have a real VT100 screen and keyboard as calculator's terminal.
• Ability to run userland process (with their own independant address space and kernel stack), directly from any ELF file accessible from VFS.
• Some syscalls already implemented for user->kernel context switch. open(), read(), write(), fork(), exit(), getpid(), getppid() and wait() are working, others are pending
• As fork() syscall indicate, a beginning of multi-process system, allowing many process to run, and a (temporary) basic implementation of a scheduler to select active process and give him some CPU time. The multi process code have only some days, and will change quickly to have a cleaner implementation (and a real scheduler, with timers to change active process)...
• Some work was done on the SD Host Interface , to control directly SD Card, but it's a realy obscure part of the CPU (a 7720 controler used on the 7705 modifed version, and not documented at all even in 7720 documentation because of commercial secret and SD Association stupid rules). So it's a lot of reverse engineering on the Casio's OS code, and it's long to have something working. For now, it's possible to send/receive SD commands, initialize SD card, get meta-informations like size, volatages supported, manufacturer... but I probably missed something for data read/write, which is not working in my implementation. If I have some hour to spend to check everything, I plane to implement SD abstract block device, and ext3/fat32 filesystems.

If you want just to take a look on a user program code, you can read user/first_test_elf.c. Of course, it's a file used for testing purpose, so do not try to look for a concrete goal in this program.


The project is hosted on Gitorious (https://www.gitorious.org/fixos for the project and https://www.gitorious.org/fixos/fixos for the main repository).
Of course, it's an open source project, anybody who would like to take a look to the code, to modify it for educationnal and curiosity purpose, or to contribute to the project is welcome.
(about it, sory for two things :
- my english mistakes in my messages and in my code or comments, I probably do a lot of stupid grammar mistakes, especialy in old comments)
- the quality of the kernel code is not always as clean as I would like to, sometimes I do some black magic usage, or quick implementation of something, before to clean the code later when I have a better idea or I am motivated again. So I try to maintain beautiful and clean code, but it's possible for you to burn your eyes when reading some functions and tricks used )

I probably forgot some things, so if you have any question, I will modify this post if the reply is relevant to take place in this introduction.

Hi everyone!

I'm Kristaba, a french programmer, really interested by the low-level programming (between hardware and software), but, unlike the overwhelming majority of you, I program usually on a... Casio calculator
So, more seriously I programmed a lot for my fx9860 (Graph85 in France), using the horrible Casio SDK at first, and now through the GCC toolchain.
I come here because I like the interest you have for the new Casio Prizm, and I think I can help the community to open it (fx9860 and Prizm are probably very similar : Casio use the same processor, and the OS is probably a lot of dirty improvements on the fx9860 OS).

By the way, I always admired the TI community, I think they are a lot of "real hackers" than on Casio community (due to a lot of reasons but mainly historical reasons I think).

So, I hope I could help, and see you later guys