1
0
mirror of https://github.com/hsoft/collapseos.git synced 2024-12-25 17:08:07 +11:00
collapseos/apps
Virgil Dupras f3992ed598 basic: begin an implementation from sratch
Let's see where it will lead us...
2019-11-13 15:28:16 -05:00
..
at28w Rename blockdev's API routines to GetB/PutB 2019-10-30 16:59:35 -04:00
basic basic: begin an implementation from sratch 2019-11-13 15:28:16 -05:00
ed Rename blockdev's API routines to GetB/PutB 2019-10-30 16:59:35 -04:00
lib Decimal parse optimisations (#45) 2019-10-24 07:58:32 -04:00
memt zasm: rename #inc to .inc 2019-10-06 14:32:23 -04:00
sdct Rename blockdev's API routines to GetB/PutB 2019-10-30 16:59:35 -04:00
zasm zasm: optimize handleRST a little bit 2019-11-12 19:45:56 -05:00
README.md basic: begin an implementation from sratch 2019-11-13 15:28:16 -05:00

User applications

This folder contains code designed to be "userspace" application. Unlike the kernel, which always stay in memory. Those apps here will more likely be loaded in RAM from storage, ran, then discarded so that another userspace program can be run.

That doesn't mean that you can't include that code in your kernel though, but you will typically not want to do that.

Userspace convention

We execute a userspace application by calling the address it's loaded into. This means: a userspace application is expected to return.

Whatever calls the userspace app (usually, it will be the shell), should set HL to a pointer to unparsed arguments in string form, null terminated.

The userspace application is expected to set A on return. 0 means success, non-zero means error.

A userspace application can expect the SP pointer to be properly set. If it moves it, it should take care of returning it where it was before returning because otherwise, it will break the kernel.

Apps in Collapse OS are design to be ROM-compatible, that is, they don't write to addresses that are part of the code's address space.