The fxSDK is a development kit for CASIO calculators of the fx-9860G and fx-CG series. It is based on gint, a unikernel that provides a free-standing runtime for add-ins with new APIs, custom drivers and advanced performance tricks. This has been my main project since about 2015 so I'm excited to introduce it!

The SDK works on Linux, Mac OS with some tweaks, and WSL on Windows. It is based on the latest gcc for SH3/SH4, using a custom (slightly incomplete) C99 libc with a ported math library, and the latest libstdc++ supporting C++20. The canonical build system for libs and add-ins is CMake, with a normal-enough setup that dual-targeting calculators and PCs is reasonably easy. All of this is tied with a package-manager-like tool for automating installs.

The unikernel, gint, provides the runtime for add-ins (like libfxcg). It has its own drivers which it runs by taking control of the hardware from the OS, which means it gives add-ins full access to the display, timers, DMA, DSP, and interrupts in general. Add-ins can still programmatically switch between gint and the normal OS runtime, commonly to invoke the main menu or to access the file system, for which there is a Unix/libc interface (open/fopen/opendir).

gint's focal point (and the most exciting part for me) is performance. It comes with a profiling library that can measure instruction sequences down to the cycle, very efficient image rendering, and it uses many assembler optimization techniques that I believe I am the first to use. I've had some impressive results, such as games running at 100 FPS full-screen on simple frames on the fx-CG 50 with no overclock (* when using a pretty crazy rendering pipeline).

Some random highlights of using gint include a streamlined system for converting images, fonts and other assets at compile-time; a USB driver that allows you to take screenshots and video capture of add-ins in real-time (with some slowdown); and access to a ton more memory, both through extra heap arenas in gint's memory allocator and through custom linker sections for on-chip memory.

The main downsides of using it stem from lost interactions with the OS, so it works best for applications that don't try to integrate with the OS' UI or look-and-feel, like games. You also have to carry the library and kernel code in add-ins, making G3A files larger (usually by 50-100 kiB).

-

The fxSDK has long been the system of choice for writing add-ins on Planète Casio. Initially I was hesitant to advertise it here because I didn't want to "compete" with the PrizmSDK, but seeing as there is little activity I'm hoping I can help and inspire some of you to pick up your fx-CG again.

Since I've been at it actively for 7 years I have a ton of cool stories and ideas I want to share, but that would never fit on a single post. I'll stop here for now, let me know if you want to learn more about any of the things I briefly touched upon!

If you want to try out the SDK, start at the fxSDK repository's README which will walk through the install process through all of the relevant repositories.

Are there any performance benefits other than assembly optimisation?
And, could these optimisations be implemented in something like libfxcg, or do they only work with the specific gint way of running things?

For the availability in libfxcg, I'd say it's about 50/50! Many small things depend on controlling the hardware, eg. the TMU for the profiling, the DSP for rendering, or the DMA for memory copies. You can access the hardware in libfxcg, but you don't have interrupts and you can mess up the OS. Some tools only work in gint, like async USB or higher-precision timers. But in the end, most of the assembly/low-level programming techniques like using on-chip memory would easily transpose to libfxcg, and they already carry a lot of power.

There are some performance benefits outside of assembly optimization; examples include the DMA-based dclear() function (Bdisp_AllClr_VRAM) which is about 2.5x faster then using the CPU, a fully asynchronous dupdate() (Bdisp_PutDisp_DD) method, or general benefits of using hardware interrupts in terms of latency.

In my experience, the most useful part is actually having easy/automatic access to these features, so that for example the SDK automatically converts images to a format that has a variety of fast rendering functions and users don't need to worry about it.

As a side note, getting the optimized assembly right is surprisingly hard! I think I spent 20-30 hours on the image renderers for example. There are many things to consider: local superscalar parallelism obviously, but also stalls and delays in the pipeline, branching loops vs. DSP loops, branchless tricks, DSP register abuses, and of course on a higher level memory speed (both read/write), caching, bus structure, etc. I'm sure some of you will have new ideas/insights to improve the performance even further.

is there any short documentation for gint ?
And how i can use gint and fxSDK with C++ ? and use any of cppp libraries like <vector> , <map> ?

Basically the documentation is coming with the header files, but you can also find some interesting stuff in the tutorial here (sorry that's in french) : https://www.planet-casio.com/Fr/forums/topic14914-1-tutoriels-dutilisation-de-gint.html

Feel free to ask questions on Planete Casio forum or shoutbox, or also here in case of need if you have questions, Lephe will be happy to help or myself if I can.

Basically to use C++ with gint, you need to respect several steps:
- specify that you are using C++ language with the directive : project(addin VERSION 1.0.0 LANGUAGES CXX) in CMakeList.txt
- add reference to the langage C++ with the -std option in target compile option : target_compile_options(myaddin PRIVATE -Wall -Wextra -Os -std=c++20) in CMakeList.txt (in that case I target to use C++ 20 specification)
- if you plan to use C++ stuff (STL), dont forget to add the stdc++ library at linking stage : target_link_libraries(myaddin Gint::Gint -lstdc++)


An example is given here : https://gitea.planet-casio.com/Slyvtt/cBox2D_App/src/branch/main/CMakeLists.txt

Then for code you can use <vector>, <list>, <deque> ... as usual

Thanks Sly. Yes the headers are the main source of documentation. I realize it's a bit unappealing but they're written in a documentation style so they should still be relatively clear. For C++ make sure to add -lstdc++ at the end of the list of libraries (more specifically after gint and any other high-level library, before libc and libgcc if they are listed).