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.
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.)
> 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].
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.
> 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.
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.
> 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.
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
Cool! I didn't knew of your work. I've been working in the service table, just that it isn't ready yet because I want DS to handle filenames and ES the buffer but currently the segment mangling still is destroying the directory. Almost ready ;)
Code size suffered because the need to sanitize the ES register to access the directories (PUSH CS + POP ES) but balanced because I made bootOS to call its own services (3-byte CALL is now 2-byte INT) and fortunately IRET is same size as RET. The most difficult thing was to return the carry flag, but the RCL instruction saved me, I'm glad the 8088 processor auto-uses SS when using BP addressing. At some point I was closer to write in paper the segment dependancies along code paths because it's pretty hard to track. Timing I think isn't so important at this moment.
Haha this is one of the reasons I stuck with the simple jump table :) I will have to check whether I have enough space left to implement interrupts though, hopefully because I already do so many internal calls I will save bytes by reducing from a 3 byte call to a 2 byte interrupt.
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...