Looking for all community contributions for my OS for the PicoCalc

I’m looking for programs made in either C or MMBasic (C is reccomended), of calculators, etc, which will be used in my OS. I am coding most of the OS myself, but if you want to make an external app for the OS (not one of the basic pre loaded ones) please comment your ideas!

My past two threads on this will be deleted, and this will be the main thread for it.

Could you consolidate these threads?

2 Likes

Without a published API all these threads are not going to go beyond vague commitment

why do you need an API?

I am deleting those two threads, and having everything in this one.

I do highly reccomend using C for the apps, as if you use MMBasic I will have to convert the code to C

One thing I should ask is what are your goals for your OS, and what will it have that MMBasic, uLisp, zeptoforth, MicroPython, Fuzix, etc. don’t?

It will be more efficient on ram, while having a whole load of extra commands which the others didn’t have. It will also blend the best functions from all of those and put it in one, for ease of use. etc

if there is no shared API or library that the programs use, what makes it an OS rather than just a compilation of programs? :slight_smile:

What kind of design are you looking at? Single-tasking, cooperative multitasking, preemptive multitasking? Single-user or multi-user? Language REPL or a non-REPL command line shell (à la CP/M or Fuzix)? And if it uses a language REPL, what language? Executing solely out of SRAM, or supporting executing with the Quad SPI flash’s XIP mode? As this is for a PicoCalc how do you plan on interfacing with devices such as the display, the STM32 MCU, the SD card, and PWM sound? How do you plan on supporting filesystems? Graphical framebuffer, text-only character/attribute buffer, or directly writing to the display without any buffering (this is very relevant to your RAM requirements). If you do use a framebuffer, what color depth will you support (a 16-bit 320x320 framebuffer is likely to be prohibitively large, you may want to use an 8-bit framebuffer and upconvert when transferring pixels to the display over SPI, or you may even want to take advantage of the display’s 3-bit color mode)? You give vague, general goals, but you don’t seem to specify what kind of design you will have that will achieve these goals.

It will have a 4bit graphic mode, it will use a FAT32 filesystem, it will have singletasking at the start, single user, and it will have a command line with many custom commands. It will have to run within 64kb of ram.

I haven’t made the library yet.

What do you mean exactly by ‘custom commands’? Do you mean that it will have a command line shell with an assortment of commands hard-coded into it? If you are going down that route I’d personally suggest, instead of hard-coding many commands, implementing something akin to a traditional Unix shell, where the shell provides the core shell language but most commands are implemented as loading executables on the fly.

I’m going to be hard coding the commands, as it is quite enjoyable.

But what about extensibility, for instance? While there may be value in integrating common commands into the shell to save space by sharing code, you probably want to make it so that commands can be added transparently by the user without modifying the shell and so that commands provided by others behave just the same way as command built into the shell.

So, you’re basically saying that I should implement a system that the user can add its own set of commands, above the per-existing commands?

Also, do you want to make any apps for it?