Hello, All

Since yesterday I have been learning to use Lephe's gint kernel, which works by a different logic to that of the syscall based libfxcg. Along the couse some questions arose regarding the multitasking scheme of the Casio OS, to which the wiki page has somewhat short descriptions.

Here my questions go. Any input will be appreciated.

* When the child/add-in process is running, is the main process definitely stopped, for example there is no some sort of time slicing between the processes?

* Are there any interrupt handlers registered by the main process, which are significant enough that we as add-in developers should keep awareness to not mess up with?

* May I safely say that the add-in takes over the processor & peripherals during its execution, from the point of view of add-in developers? Are there any exceptions? One of them would be the physical memory layout I guess, let's stop at the virtual address space level.

* Is it add-in's responsibility to update the status bar if there is one? For example will the OS automatically update the battery level indicator?

* What about backlight dimming & AC off, should Add-in take care of them too?

Thanks in advance!

I'm not too familiar with the low level functioning of the calculator - but I can definitely answer these questions.
1. You do not need to update the battery indicator. I'm not sure when this happens, but I have found that directly modifying the address where the battery level is stored (0x8c090c1e) yields an instant change in the battery indicator, so it is running pretty often.
2. Again, no. I'm not sure how the OS decides to dim the battery but it does it. With Shift+AC (off), this is handled along with the MENU key in the GetKey() syscall. I'm not sure when gint uses it (I'm sure @Lephe will know), but generally if the calculator is idling or accepting key input, it will handle off (and MENU) automatically.

Thank you, dr-calos! This little beast is much much harder to train then I imagined. So many unknowns, even along the way paved by those brave pioneers!

When using libfxcg, the OS controls all interrupts, and handles everything automatically. When using gint, then your add-in controls all interrupts, and no interrupts are ever delivered to the OS (apart from TLB misses).


Add-ins are not supposed to do that, there are only a couple of kernels like gint that do that. Among the things we don't control is actually (1) the MMU, because of historical precedent by AHelper that a crash while the MMU is in an unusual state could brick a calc (therefore gint uses physical memory but cannot map new memory), (2) the filesystem, because Fugue is so complicated and already somewhat unstable (therefore gint requires a world switch before using filesystem functions), and (3) poweroff.


Note that if you're using gint then the status bar won't show up in your add-in because the kernel is driving the display. You can still access query battery level with a syscall if you need to.


AC/OFF erases some of the memory, making it very painful to deal with. The longest-standing bug I have (and also the only crash I've yet to fix) occurs is you do a world switch to return to the main menu, then power off in the main menu and re-enter the add-in. This problem also showed up in KhiCAS at some point.

I'm not sure but I also believe the later 6 MB of RAM are affected by this problem, which means you might have to choose between hot-menuing/poweroff and access to most RAM resources. I'm mentioning this because I don't imagine you could have a JVM run smoothly on 512 kB so this might end up being one or your concerns.

@Lephe: Very insightfull and internal info. Thank you.



Understood. Add-in as a whole, a running process, with kernel included, that is what I mean. While dealing with gint, I had a feeling that it is working in a very "intrusive" manner, making me ask the question: what is the boundary between what an add-in can do and what it cannot. Therefore this post. You have explained it clearly.



I have encountered this issue. The calc re-configures when AC ON, as if the RESTART button was pressed.



Yes it is challenging. Also the 2MB binary size limit. I've heard there are commercial JVMs targeting MCUs declared to work fine with similar system resources, so I am taking it as a challenge during pandemic lock-downs. Maybe I will need more rounds of them to spend

I might also add that the add-in has the hardware authority to do anything, and the boundary is only remaining stable to deal with the OS. Some people have made kernels that boot away and then never come back to the OS unless you reset the calc. These have more freedom.


You can somewhat work around the 2MB limit by loading into RAM, although that's pretty advanced.

Good luck in any case, if you have any low-level interrogations there is probably documentation somewhere to help.

Nope, I would rather keep away from that. All I need to know is the big picture, as long as I feel confident enough to do my job at the application level. What gint gives is what I get.