Plans, in the future, could be reality, or left as plans.
At first we planned to leave core1 to the users.
So that the users can use a core as a whole.
However situations changed as we realized that we have to respond faster to computer to make the keyboard recognized faster, without problems.
Thus now the usage of the core is as below.
(below)
+----------+ +-----------------+ | core0 | | core1 | +----------+ +-----------------+ | keyscan | | display (game) | | hid | | led | | cdc | | userscripts | | midi | | | | watchcat | | | | | | | | | | | | fifo -----> | | memqueue -----> | | | | | | <----- fileIO request | +----------+ +-----------------+
Each core runs at 133MHz.
The problem now is that, we cannot make users use the core1 as a whole because if userscript runs 'sleep' or write file on a filesystem - like locking the memory, then the display and led will misbehave because of the time delay.
Now it is inevitable to make userscript request based.
Userscript should now 'request' an action to the cores.
For instance, let's say we're going to display an alert over the screen.
(current implementation) 
This is the case when user sends a command from the shell(cdc).
As the command received, we set [displaycontext.alert_isset] to true.
Then when the display_task checks that it's set to true, display enters into the alert-showing-state so it can start and finish ease-in of the alert panel.
It's a bit sad to not being able to spare a whole core to the users.
However in terms of functionality, we'll still make it as powerful by designing the API as follows.
example1)
display.setBitmap(x, y, duration, filename, bitmapId)
> set a bitmap(in file) on a screen(x,y) for a while(duration)
example2)
display.removeBitmap(x, y, bitmapId)
> remove bitmap previously set.
example3)
keyboard.repeatKey(keycode, interval, count)
> register repeating a key(keycode) for several times(count) every interval.
How is it look? :)
Please leave comments/suggestions on our discord!
(opens at 9,Feb,2023)