
BootOS: Monolithic operating system in 512 bytes of x86 machine code - nanochess
https://github.com/nanochess/bootOS
======
kragen
For those not aware of the background, the author is a wizard from a secretive
underground society of wizards known as the Familia Toledo; he and his family
(it is a family) have been designing and building their own computers (and
ancillary equipment like reflow ovens) and writing their own operating systems
and web browsers for some 40 years now. Unfortunately, they live on the
outskirts of Mexico City, not Sunnyvale or Boston, so the public accounts of
their achievements have been mostly written by vulgar journalists without even
rudimentary knowledge of programming or electronics.

And they have maintained their achievements mostly private, perhaps because
whenever they've talked about their details publicly, the commentary has
mostly been of the form "This isn't possible" and "This is obviously a fraud"
from the sorts of ignorant people who make a living installing virus scanners
and pirate copies of Windows and thus imagine themselves to be computer
experts. (All of this happened entirely in Spanish, except I think for a small
amount which happened in Zapotec, which I don't speak; the family counts the
authorship of a Zapotec dictionary among their public achievements.) In
particular, they've never published the source or even binary code of their
operating systems and web browsers, as far as I know.

This changed a few years back when Óscar Toledo G., the son of the founder
(Óscar Toledo E.), won the IOCCC with his Nanochess program:
[https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod...](https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Toledo_Nanochess)
and four more times as well. His obvious achievements put to rest — at least
for me — the uncertainty about whether they were underground genius hackers or
merely running some kind of con job. Clearly Óscar Toledo G. is a hacker of
the first rank, and we can take his word about the abilities of the rest of
his family, even if they do not want to publish their code for public
criticism.

I look forward to grokking BootOS in fullness and learning the brilliant
tricks contained within! Getting a full CLI and minimalist filesystem into a
512-byte floppy-disk boot sector is no small achievement.

It's unfortunate that, unlike the IOCCC entries, BootOS is not open source.

~~~
mysterydip
How did you learn so much about them? Asking genuinely

~~~
sanlyx
I wondered the same thing, then I did a quick Google search and it turns out
they're relatively known in Mexico They also have a web page: www.biyubi.com

~~~
kragen
Maybe "underground" was not the best description, but it is the case that much
of their software remains unpublished, and so people still debate whether it
really exists or not. I think it probably does, because 40 years of a family
building extremely optimized software could produce a talent like Óscar Toledo
G., while 40 years of running a con job would not.

------
bArray
I have also developed a very small kernel in 512 bytes, it's a fun exercise
[1] (this is a really old project that was uploaded to BitBucket long after it
initially started). I quite like this BootOS project, you can of course see
the compromises that any OS this size has to make.

I would make a recommendation to the BootOS project which is to squeeze a
function table as I have done in order to allow programs to call functions in
the kernel. If not, you either end up re-writing these functions for each of
your programs, you have to recompile your programs any time you change your
kernel or you end up trying to maintain jump positions.

For those still reading, I'm working on a large overhaul of saxos which
includes very simple multi-tasking (currently working). The intention will be
to have the kernel load a 512 byte GUI on top and then for the programs to
have access to a terminal within the GUI. Once that's working I then want to
move towards also allowing programs to draw to the Window, but that also
brings its own issues.

[1]
[https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...](https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/KERNEL/KERN.ASM)

~~~
kragen
Oh awesome! This one also has a tiny filesystem and prompt, but no UI for
typing machine code in, is that right? But the filesystem supports more than
one sector per file? Saxos _is_ open-source, unlike BootOS, even if maybe that
would be clearer if you used a widely-recognized license.

I don't think BootOS tries to export its filesystem API to user programs.
BootBASIC in particular doesn't seem to have a way to save and load programs.

Brilliant work!

(Apparently I heard about this before and never looked at it? Because I have a
clone of it on my laptop dating from September 14th.)

~~~
bArray
> Oh awesome! This one also has a tiny filesystem and prompt, but no UI for
> typing machine code in, is that right?

Yes, but it offers more to the programs that it loads. There's a trade-off
when you go this low on disk space!

> But the filesystem supports more than one sector per file?

SaxOS supports half the disk, but each file has to be 512 bytes [1]. There are
potentially work arounds for this limitation of one sector per file, but it's
just hacky. (For example, you could name your files txt0, txt1, ... - or you
could leave some header information in your program's file for more data.) I
will fix this in a future version though, the plan is to keep loading sectors
by the same name in the file table.

> Saxos is open-source, unlike BootOS, even if maybe that would be clearer if
> you used a widely-recognized license.

When I wrote this I had no idea about licenses :) I will look to update this,
but the project is mostly just archived for now.

> I don't think BootOS tries to export its filesystem API to user programs.
> BootBASIC in particular doesn't seem to have a way to save and load
> programs.

It takes very little to extend the functionality of your kernel to your
implementing programs, hopefully BootOS will do this in the future. At some
point I want to write a simple self-writing documentation (using the comments
structure) so that I can always produce up-to-date documentation for the OS.

> Brilliant work!

Thanks!

I was trying to build a very small low end compression algorithm for it to,
but unfortunately I came hard up against entropy. The idea worked (as I
envisioned it) but it had the effect of just transforming the dimension the
data was stored in and adding unthinkable amounts of computational power and
memory being required to get it back.

> (Apparently I heard about this before and never looked at it? Because I have
> a clone of it on my laptop dating from September 14th.)

Awesome! My plan for quite a while has been to write a small book and guide
people through building their own very simple OS. I think people building
their own 512 byte boot-able kernel is a nice intro into OSes whilst also
having enough limitations that at some point you can say "this is complete".
Anyway, it's what I wish had existed when I first set out may years ago!

Speaking of which, I must give a shout out to MikeOS which is where I learned
about assembly and OSes [2].

[1]
[https://bitbucket.org/danielbarry/saxoperatingsystem/src/96c...](https://bitbucket.org/danielbarry/saxoperatingsystem/src/96c90c3e867f62700580efb240a3af4054cbbdb8/FUNCTIONS.ASM#lines-39)

[2] [http://mikeos.sourceforge.net/](http://mikeos.sourceforge.net/)

~~~
kragen
That would be amazing! There's a lot of exciting bootstrapping work going on
right now, largely aimed at plugging the Karger–Thompson hole; unfortunately
we don't have a viable kernel to compile things on, so while we are close to
being safe from Karger–Thompson attacks on GCC, we're still somewhat
vulnerable to Linux, and of course Intel. My own interest is largely from
other objectives.

I strongly encourage you to stick an explicit license on it if you want people
to study it! Otherwise there's the risk of a Numerical Recipes or SCO lawsuit
nightmare. (While we were writing this thread, Óscar Toledo G. added a BSD
license to BootOS!)

I wonder—and maybe it's presumptuous to offer suggestions like this without
working code, so feel free to ignore it—if it might be more flexible to go the
BootOS route of including at least some kind of hex or octal† input in the
initial boot monitor, and relegate the filesystem to a loadable device driver
in a second sector? It would be less convenient for running apps that want to
use the firesystem, since you'd need to run two commands instead of one, but
it also means those 512 bytes are sufficient by themselves to bootstrap
anything else you wanted. With enough work.

…holy shit, you have a scrolling full-screen editor in one sector? This is
_amazing_.

† I like octal because (sorry, rdl) the 8086 instruction set is way easier to
read in octal. Also octal input takes less code than hexadecimal input, unless
there's something I'm not seeing, or you're willing to count 0123456789jklmno.

~~~
bArray
> I strongly encourage you to stick an explicit license on it if you want
> people to study it!

I'm not concerned with lawsuits but allowing people to work with it is a good
enough reason to add one.

> (While we were writing this thread, Óscar Toledo G. added a BSD license to
> BootOS!)

Very cool :)

> t might be more flexible to go the BootOS route of including at least some
> kind of hex or octal

I think that really depends on the goal of the OS, if it's to be self
contained then fair enough, but it kind of limits out of the box usability for
a normal user. I think most people would bork at having to type any program
they want to use into the terminal each time they boot/test the system.

> …holy shit, you have a scrolling full-screen editor in one sector? This is
> amazing.

Thanks :) I will at some point improve upon it too, there's definitely some
parts that could be better done.

> Also octal input takes less code than hexadecimal input

In terms of amount of code required, I'm not sure. Maybe there is some way to
utilize AAA, AAS, DAA or DAS for converting hex to a value with minimal
commands. The documentation appears to be quite crappy for these op-codes
though, apparently Intel even managed to confuse themselves (which doesn't
bode well for their reliable implementation) [1].

The other problem is that re-packing octal input back into raw bytes (for
running) will be non-trival, the reason hex is generally used is because it
represents a nibble (4 bits) and you can get away with pairs (i.e. OF 3A B7).
Octal on the other hand is gonna be messy, you either have 3 octal characters
per byte and lose packing density (even more) or you have cases where an octal
character contains information for two neighboring bytes.

[1] [https://stackoverflow.com/questions/51710279/assembly-
instru...](https://stackoverflow.com/questions/51710279/assembly-instructions-
aaa/51713715#51713715)

~~~
kragen
Right, you aren't the one at risk of lawsuits! You shouldn't be concerned!

I didn't mean to leave out firesystem functionality entirely. Clearly you
still need a way to load programs from the disk without typing in a bootstrap
program!

I agree that octal is less dense. But it's a lot more readable, because
operand fields are isolated in a single digit (usually) and not split across
digits and mixed with opcode bits.

~~~
bArray
> I didn't mean to leave out firesystem functionality entirely. Clearly you
> still need a way to load programs from the disk without typing in a
> bootstrap program!

In my mind, if you're going to make assumptions such as having a valid file
table, making the assumption you have some basic programs ready to be loaded
is not too much of a leap?

By the way, once I've got a filesystem up and running that can load in files
greater than 512 bytes, it makes sense then to build a very basic assembly
compiler. There's a bunch of tricks one could pull in order to make compiling
a single parse deal for relatively large files at the sacrifice of efficiency.
I think I could quite easily drop support for half of the 8086 instruction set
and still end up with something very usable.

> I agree that octal is less dense. But it's a lot more readable, because
> operand fields are isolated in a single digit (usually) and not split across
> digits and mixed with opcode bits.

Are you able to give a small example, I'm not sure I follow the thinking? From
what I understand, for each octal character you're representing 3 bits of
binary. With two characters you have 6, but you're still short 2 bits for a
byte.

~~~
kragen
As for the filesystem, probably I should explain what I mean in assembly
rather than English :)

You definitely don't need half of the 8086 instruction set for a usable
programming system. 20 instructions and a few addressing modes is plenty. On
the rare occasion you need DAA or ROL you can just use a DB. RPN syntax may
simplify parsing.

As for octal, yeah, you need three decimal or octal digits to represent a
byte, and the most significant digit can only be 0, 1, 2, or in octal, 3.
Detailed notes are in
[http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt](http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt)

------
userbinator
The significance of 512 bytes is that it is the standard sector size for a PC
storage device (the size seen by software; newer hard drives have 4KB physical
sectors, but can still be addressed as if they had 512B "logical" sectors),
and a traditional BIOS reads the first sector of the boot device into memory
and jumps to it in order to begin the OS part of the boot process. A normal OS
bootsector would then find and load the next part of the OS, which may involve
things like understanding FAT or NTFS filesystems; here's a (rather
enthusiastic) analysis of many boot sectors from different versions of DOS and
Windows:

[https://thestarman.pcministry.com/asm/mbr/index.html](https://thestarman.pcministry.com/asm/mbr/index.html)

Writing a tiny program that lets you modify memory, and more importantly
execute it, is the first step in the "bootstrap pilgrimage" to creating your
own environment and eventually OS, but this one seems deliberately limited;
nonetheless, starting with this, one can use it to create the next stage of
the bootstrap, 512 bytes at a time.

------
ChrisCinelli
It seems that this more than a OS is a minimal file system with a obvious
limited feature set that relay on the
[https://en.wikipedia.org/wiki/INT_13H](https://en.wikipedia.org/wiki/INT_13H)
\- It assumes that a BIOS that contains a lot more machine code is available.

For the new generations this will seem not to have any real applications
beyond code golfing.

But from a nostalgic point of view, it brings me back to the demoscene era. I
still fell a wistful longing for the old days thinking to fr-041:debris (
[https://www.youtube.com/watch?v=tq2llbP52Zo](https://www.youtube.com/watch?v=tq2llbP52Zo)
) 7:20 minutes of awesomeness in less than 199 Kb.

BTW, I just google it and apparently there is plenty of events going on...
Coming very soon:
[https://www.assembly.org/summer19/](https://www.assembly.org/summer19/)

~~~
kragen
A filesystem, a shell, a program loader, and a hex editor! Well, maybe
"editor" is overselling it. But from my point of view, it's as much an "OS" as
MS-DOS was. MS-DOS also depended on the ROM BIOS.

I agree that it's probably not practically useful. But it's a brilliant hack!

~~~
devnulloverflow
Yes, BootOS very much in the same space as MS-DOS, although leaning even
further on the "less-is-more" axis. It does the same basic things (though I
suppose it doesn't do the BASIC thing).

Interestingly, there is modern OS in the same space. That's UEFI. Unti I
played with it a few months ago, I thought it was some mysterious firmware-
adjacent black-box. But actually it's just an OS, very similar to DOS (though
it runs in protected mode).

It has a shell and some basic built-in commands including text editors and
such. And most importantly it lets you run executables that a stored on a FAT
(well, FAT32) filesystem.

The name BootOS could very well describe UEFI. And equally, a slightly more
capable version of BootOS could serve as (very underpowered) UEFI replacement.

~~~
acqq
> though I suppose it doesn't do the BASIC thing

What's this then?

    
    
       bootOS programs: (Oh yes! we have software support)
    
       fbird         https://github.com/nanochess/fbird
       Pillman       https://github.com/nanochess/pillman
       invaders      https://github.com/nanochess/invaders
       bootBASIC     https://github.com/nanochess/bootBASIC
    

And one can test the image:

"find a pre-designed disk image along this Git with the name osall.img"

~~~
devnulloverflow
I meant that UEFI doesn't have a BASIC interpreter (though probably someone
has written one).

I did not know that bootOS had one, but it does not surprise me given
everything else I read on this thread.

~~~
acqq
> I meant that UEFI doesn't have a BASIC interpreter (though probably someone
> has written one).

You wrote something else:

> Yes, BootOS very much in the same space as MS-DOS, although leaning even
> further on the "less-is-more" axis. It does the same basic things (though I
> suppose it doesn't do the BASIC thing).

~~~
devnulloverflow
Yah, sorry about that. I replied before checking my memory of what I had
written.

I thought I caught the error and deleted the erroneous response in time. But I
didn't.

------
Eun
What I am still looking for, is for a boot os that can boot a normal .iso/.img
file from its own device. This will be the perfect usb boot stick.

1\. Flash boot os on the boot sector, place any iso/img file on the stick.

2\. Boot from the stick

3\. select the iso you want to boot

Don't know it this is possible though... (I know that there is a emulation
mode for virtual cd drives in the bios but thats about it...)

~~~
notpeter
I've seen various software that does this with multiple installer/liveCD ISOs
for Linux distributions but none that could actually boot all arbitrary ISOs
(Windows installers, DOS rescue disks) which need to be on a logical device
partition.

I used to have a 2.5 enclosure that supports this in hardware (Zalman ZM-
VE300) but selection of ISO is done on-device before booting. I don't see any
reason you couldn't build a hardware/software combo where selection on-screen
made the USB hardware mount the selected ISO as a new logical device and then
booted it.

[1]:
[http://www.zalman.com/contents/products/view.html?no=212](http://www.zalman.com/contents/products/view.html?no=212)

------
non-entity
Wow this is really cool. I honestly expected this to be just a program that
would boot to some text output and maybe a very simple shell, but it looks
like this more than that.

------
kazz0302
Pretty cool!

------
t3x4c0
BootOS developed by a 10x Rockstar Ninja google dev! Oh no, wait...it's a
mexican who works with his family at "Familia Toledo"... Guys, i think perhaps
we got it all wrong.

