AOS - Arduboy Operating System

aos_1_0.hex (78.7 KB)

Hello all!

I proudly present AOS - an attempt to create some kind of operating system for this fantastic piece of arduino hardware.

See more at:

Or see a short video at:



This is so great, I had to watch the video to see how this worked. I really love the font! Nice work, RTOS!

Thank you for building this! How much memory space is left for user applications? :smiley:

Hello Kevin!

Thanks for these nice words (from the grandmaster himself).

I always try to write small, efficient and fast code. And to have the feeling of having all in my hands I am doing this in an “all in one file”, which is sometimes annoying for some people - see my 3d shooter (ARENA).

I also have done a “screenbuffer trick” to reduce the screenbuffer to 256 bytes (instead of 1k). Actually I am using a 64x32 pixel graphic and expand this bitwise to the 128x64 screen. Most fonts seem clumsy and “pixelized” when expanding - so I designed an extremely “edged” font which maybe hard to read for some eyes (ie. see characters v, x, X).

AOS uses (dynamically) nearly the whole EEPROM (2493 bytes) for user programs and text files. The minimal program size is 4 bytes and the maximal size is 255 bytes - so between 623 (theoretically) and 9 programs are storeable in the EEPROM. Two of them (one leading program and one subprogram) can be loaded and executed to/from RAM.

Right now I am working on an 3d VR program (the vector math of ARENA still occupies me) for the Arduboy. And when I look at the work of the guy which rotates the Utah teapot - I have a lot of work to do.

Thanks again and regards

??? The Arduboy only has 1024 bytes of EEPROM total.

Thanks Scott - you are right (I calculated with another arduino).
So the count of user programs/textfiles are between 3 and 256.

1 Like

I hope you’re not clobbering the first 16 EEPROM bytes, reserved for system use. You should only have 1008 bytes available, which would give a maximum of 252 4 byte programs/textfiles.

Hello Scott!
I found many discussions about this first 16 EEPROM bytes.
But is there an official documentation about this convention - which can fill my lack of knowledge?

See the Using EEPROM in a sketch section on the main page.

Aah - unit name, LED/audio settings etc.
Makes sense - inspires me - thanks so far.

One of these days I will make the documentation easier to find.


Once it gets past a few hundred lines, packing all your code into a single file does nothing but make it hard for people to read.

Multiple files are a good way of keeping your code organised.
Instead of scrolling up and down a massive file to find something,
you can navigate to the particular file that code is in.

For example, you could have moved all the calculator functions into one file,
and all the lookup tables into another.

Also some of your code is certainly not “small, efficient and fast”.

For example, having a really long loop function is the antithesis of ‘small, efficient and fast’.
If you want it to be small, efficient and fast,
you should split your states (or ‘modes’) up into separate functions.
The compiler doesn’t like long functions because it can’t optimise them very well,
because of the amount of context it has to try to keep track of.

There’s many other issues I could bring up as well, but I don’t want to go off on a tirade.
There’s no doubt you’ve packed in a lot of features,
but there’s a lot of issues with your code that are letting it down.

Also, this code is violating the Arduboy2 licence terms, the same as your ARENA code.

It’s clear that you’ve taken some of your code from Arduboy2 which is under the MIT licence,
so you need to include the licence and copyright notice,
and indicate which of your functions is affected by that licence and copyright notice.

1 Like

I am guilty of putting everything in one file.


I watched the whole video and didn’t really see anything that was “graphical” (or else I’m forgetting). Given that you could probably accomplish the same with a text grid 4*10. (40 bytes) and perhaps an attribute grid (2 bit * 40) = 10 bytes. The attribute values could be:

  • 00 - Normal
  • 01 - Tall
  • 10 - Wide
  • 11 - Wide and Tall

If you needed more attributes you could get the whole “buffer” into 50-80 bytes easily, freeing up more space for whatever - again so long as you don’t need graphics. And if you did truly need graphics you’d be better off served switching to a paged buffer (draw the screen in 8 or more slices/passes). In that case you’d use 128 or fewer bytes for graphics and still have pixel-perfect precision. (the less memory you use the slower render gets)

Pretty neat though, reminded me a bit of my friends new TI calculator I was playing with get the other day. Complex and obscure but still kind of nifty. :slight_smile: