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.

Wow, I have been wondering what happened to this project.

Do you think it could be easily ported to PRIZM? (Especially since it appears there are hardly any graphics functions yet)

DO you have any explanations for using GCC on Windows? I'm trying to compile GCC for sh3-elf target, but it's not the domain I'm at my best.

Nice to see you still active in the Casio community. This project seems interesting,although I would probably not use it much, since I am not familiar with Linux-like stuff and mainly use my calc for games, but I hope this eventually come to fruition. Linux is now available on the TI-Nspire (although not installable as main OS) and some people managed to browse internet from it (while the calc is connected to an USB dongle)

DO you have any explanations for using GCC on Windows? I'm trying to compile GCC for sh3-elf target, but it's not the domain I'm at my best.

Sorry for the delay, but in my case I am not familiar with MS Windows, so I can't help you a lot.
I think the best idea is to cross-build GCC from Linux (even using a VM only for that), or with a full Cygwin install. If I have some time I'll try to build latest GCC toolchain (binutils and GCC binaries, libraries are not needed, even libc), but I think there are some binaries available somewhere, used for some Prizm toolchain, and should be able to build for SH3 big endian target.

Nice to see you still active in the Casio community. This project seems interesting,although I would probably not use it much, since I am not familiar with Linux-like stuff and mainly use my calc for games, but I hope this eventually come to fruition. Linux is now available on the TI-Nspire (although not installable as main OS) and some people managed to browse internet from it (while the calc is connected to an USB dongle)

Nice to see you still active in both communities too

To make things clear, this project is far far away to be considered as a Linux-like. Even if I finish everything I would like to do, it will probably be closed to the 1990's System V than to a modern Linux or BSD
TI-Nspire has a lot of ressources availables compared to fx9860 (Prizm is more interesting, but still realy light to imagine a Linux running on it).
For example, in TI89-titanium and TI-Nspire, there is a USB "on-the-go" controler, allowing to act as a usual computer with USB devices (Keyboard, WiFi dongle, USB pen or HDD...). On Casio's calculators, it's only the device part of the USB which is available (so the calculator may act as a USB device, but there is no way for it to deal with other devices, and for exemple it's not possible to use WiFi dongle to give internet capabilities).

In the other hand, as everything is written from scratch, it's not impossible to design some part of the kernel to allow games to run at a correct speed.
It's not my main goal, of course, but basicaly what is needed is a near-realtime scheduler (or a "single process" mode to avoid useless context-switches), and some realy specific device drivers to have a fast access to display rendering and keyboard input.
And a good kernel can allow game developpers to have better (and more reliable...) bases to code their software. Imagine at least a good filesystem access, memory swaping to allow to use more memory than available RAM (even if in theory, swaping in EEPROM is either fast nor a good idea for EEPROM lifetime  ).
In addition, something I realy want to do in a near future is shared library support, which can be also realy useful for games (lighter executables and possibility to update/fix libraries without compiling again).

Do you have some tasks I could do Kris?

It's not easy to say you a precise thing to do, mainly because I have no precise plan myself
If you want to do some kernel functionalities, first try to read some piece of existing code to check a bit how the kernel is designed. After that, you can contact me using mail/pm, to find a better way to discuss a bit (irc, skype or something else).
A possible task should be to implement a serial device driver (using the real USART, not the USB emulating a serial device ^^).
It will be useful to both kernel (serial debugging) and user space (calc-to-calc comunication), and is a task which need to use the CPU's documentation, some plateform-specific code, and a device driver. So it's probably a good exercice to begin kernel programming 



Now, about the project advancement, I had not a lot of free time, but I did some important things last days.
In a first time, a realy better keyboard handling. Before there were only some functions inherited from my old projects, like is_key_down(), and was only used for debuging purpose.
Now there is a real implementation of keyboard, with 3 abstraction layers. The first is the 'keymatrix" level, to check the state of physical keys, and interpret state changes as keyboard pressed/released. These informations are used by the logical-keyboard layer, able to handle key modifiers (SHIFT/ALHPA and later a character case modifier), and when I will have the time to implement it, the key repetition parameters. Finaly, the higher layer is implemented in the /dev/console driver, to act as standard input stream (with DEL used as backspace for corrections).
The keyboard state is updated with a 64Hz interrupt, and later will use some pin state detection interrupt to minimize overhead when no key are pressed, but because of hardware configuration there is no "perfect way" to handle each key press/release whithout some timer interrupt usage.
Everything is not finished, but now there is a correct stdin for interractive user process. I will have to add ioctls to be able to change the input properties (at least ICANON and a raw mode, which are realy needed for ncurses-like usage).

In a second time, the first partialy working implementation of exec-like syscall (execve), one of the most important syscall on a UNIX-like system.
So it's now possible to begin to write some useful userland software (a bash-like use mainly fork/exec, as well as a userspace init program).

Thanks for the clarifications. And yeah I could understand why Linux would be hard to run on a Casio calc. I am curious if it would work on the SD models, but I don't even know if they're still in production and even if they are, having Linux only on  the SD models would cause the userbase to be so incredibly small compared to the TI-Nspire.

might be out of topic, but can anyone tell me where I can find the said GCC toolchain to biuld .g1a executables?

Same for me.