Hey all, As a follow up to my relatively successful series in x86 Assembly of last year[1], I started making an OS that fits in a boot sector. I am purposefully not doing chain loading or multi-stage to see how much I can squeeze out of 510bytes.
It comes with a file system, a shell, and a simple process management. Enough to write non-trivial guest applications, like a text editor and even some games. It's a lot of fun!
It comes with an SDK and you can play around with it in the browser to see what it looks like.
The aim is, as always, to make Assembly less scary and this time around also OS development.
In 2004, Gavin Barraclough’s mini-OS [0] won the IOCCC, packing a 32-bit multitasking operating system for x86 computers, with GUI and filesystem, support for loading and executing user applications in ELF binary format, with PS/2 mouse and keyboard drivers, VESA graphics, a command shell, and an application into 3.5 KB of highly obfuscated C code.
In 2021, Justine Tunney wrote SectorLISP [1], a Lisp implementation that fits into a bootsector and is able to run McCarthy’s metacircular evaluator.
[0]: https://www.ioccc.org/2004/gavin/index.html [1]: https://github.com/jart/sectorlisp
1. I just saw how str_print is implemented. It's so short even though it's asm. Is this why nul-terminated strings were so popular and became the default in C? Would pascal strings be much longer/uglier/harder in asm?
2. Why is str_print repeated in multiple files? How would you do code sharing in asm? I assume str_print is currently not "static" and you'd have to make it so via linking or something, and then be able to get its address using an asm macro or something?
Printing with Pascal strings is actually shorter (you skip the null test, basically), but constructing Pascal strings to pass as an argument when they are not constants yielded much more code to prepare for that call. Had I had more leeway, I would have used Pascal strings, it much less headache.
2. Files in `/bin` all include from the SDK. You can pretty much do the same for utility functions.
The includes, at least in nasm, are very much like copy-pasted code (or includes in C for that matter), and then you can just jump/call to the label.
I did not do it because I haven't been able to get nasm to optimize away the code that I don't use, and I didn't want to bloat the binaries or make a file for a 5LOC function.
All in all not good reasons in general, but it made sense to me in this context.
Two more questions if you find some spare time:
3. Why does it use tty for interrupts instead of directly calling int 10?
4. How does this even print to the screen or use a tty in the first place? Is it just something inherent in bios api?
If you know how to make it happen and/or want to contribute, hit me up (:
Also: what could be done if the size limit were 8kbyte like the mask-rom bios days?
Thanks for pointing me towards the bosh emulator.
On the former, I have no idea how to estimate BIOS functions size. Maybe I could just peek into an image and get a sense for it...
On the latter, with a 16x increase in available space, I guess I would do a much more thorough work in putting guardrails in place.
The API currently comes with a couple of traps (e.g., file names can be duplicated, processes are cooperative, all file operations perform disk I/O...) and it essentially requires guest applications to know about BIOS services in order to function.
Another sticky point I wish I had the space to address better are calling conventions, which I had to get rid of almost immediately to save on instructions.
> Thanks for pointing me towards the bosh emulator.
You're welcome! Bochs is such a nice tool which I discovered only for this project as well. It was a no-brainer, since I got no way to debug 16-bit assembly from QEMU (unless you go off and fork it[1])
[1]: https://gist.github.com/Theldus/4e1efc07ec13fb84fa10c2f3d054...
Probably a few dozen to over a hundred KB, maybe even over a MB, depending on the era of machine and what it has installed; e.g. the GPU option ROM would be included if you use int 10h, int 13h might be hooked by a disk adapter, and if you use int 16h to read from a USB keyboard, that'll go through the BIOS' USB stack which normally includes some code in SMM too.
I thought about what would be the minimum I have to build in order to run some userland software that does "something". That to me looked like: spawn guest applications, make them persist something.
With slightly more leeway, I would probably do memory management as the next thing (besides what I mentioned in another thread here)
I'm not a native speaker, so maybe somebody else can paint a better picture. I used it just because part of my extended family comes from there (:
EDIT: s/prefix/suffix/
https://en.m.wikipedia.org/wiki/Alsatian_dialect
-ele is used a lot to denote something small, cute, adorable; maybe think of it as kind of like ちび (chibi) or -ちゃん (-chan) in Japanese.
Mann (man) => Mannele https://cookingwithbrendagantt.net/mannele-st-nicholas-bread...
Katz (cat) => katzele (kitty)
The suffix can be liberally (ab)used with any - native or foreign - word or (sur)name to emphatic or comedic effect.
Here I kinda guessed the -le use was such but around here I would have said "OSele" (oh-ess-uh-luh)
-li is a different version of the same ending
if you want an ahci controller to 'see' it, it will need partition table too, which will make it even less bytes (or maybe cleverly encoded)
If one day I'll give in and take the shell out or go multi-stage, I will definitely look at that.
Maybe it's worth blogging about the journey; it's been a few weeks of merciless trade-offs to reach a usable API. It can make for a fun read (:
Thanks for taking a look!
if you do not put partition table, qemu AHCI controller will not recognize disk as bootable and u cant use SATA. with only the magic footer at the end of mbr, it will only work on IDE controller.
try it.
