Mini16: 16-bit x86 Operating System for Teaching, Part 0

Backstory

It was not until reading the 1st edition of Andrew S. Tanenbaum's Operating System: Design and Implementation did I realize protected mode was never a requirement for preemptive multitasking. I just need a method to seize full control of the CPU when it's working on something else. The method is using interrupts. Set up the machine timer, hook a handler to the timer interrupt and you can have the CPU run your task scheduler periodically. Replace the keyboard interrupt handler with your own and you can have stuff like Ctrl+C SIGKILL. This confusion, of course, comes from a lack of understanding of computer systems: I never truly understood how interrupts work, and I have learnt a little bit of 16-bit x86 assembly in the past so I've always thought interrupts are like some kind of syscall. It's actually the opposite: syscall (at least MS-DOS syscall) can be implemented as software interrupts. After learning about all this I decided I've learnt enough to develop a very basic OS, and so the Mini16 project was born.

Current status

No multitasking yet.
No file system.
Basic shell for reading & writing data from/to RAM.

I started the project after I figured out how to build a workflow for writing standalone 16-bit program with C. Took me a week to get here after that. My assembly language skill is rather pathetic so it probably would cost me months if I only use assembly…

The source code can be downloaded from here.

How does it look like (for now)?

A screenshot of QEMU:

Why new project?

There's this interesting pattern I noticed. There are a lot of "Write-Your-Own-OS Turtorial" blogpost on a lot of different places, either one's own blog or writing platforms like Medium or Dev.to. More often than not there will only be a "part 1" telling you how to write a bootloader; the "author" would say that a "part 2" is coming soon but this "coming soon" would last for years or (very probably) a whole lifetime. Some of them (who paid a little bit more effort) will have multiple part but it always seems like it's directly taken from OSDev.org's bare bone turtorial and it's just the same thing got copied & pasted again and again and again with absolutely no detailed explanation. It almost feels like they didn't even bother to actually compile & run the code and they're just posting crap for views. This situation is stupid and I want to change that, even at the risk of me becoming a new target for copying.

Why flat binary?

ELF is good: tools are readily available, debugging is easy with QEMU & gdb, etc., but it requires an ELF loader and all the things that are required to come before it, which is too much of a hassle to set up for my purpose. Using ELF like the OSDev.org turtorials did without actually knowing what the heck is going to happen is way worse than to use a flat binary and knowing every single detail about the process. We can always come back to it after learning enough stuff; actually, because it's for teaching, we will resolve the same issue again and again using different approaches.

Will there be Mini32 or even Mini64? Any plan for RISC-V?

There definitely will be Mini32 and Mini64 as long as we're still using IBM PC compatible at that point, but I'm not going to use the same toolchain. No plan for RISC-V currently. RISC-V is a different beast: unlike x86 where everyone's going to make essentially just one type of machine, there are a lot of incompatible RISC-V machines (and people are probably going to make more incompatible RISC-V machines in the future). For ARM the situation is also like that; that's why Android ROMs have to be configured for different devices and you can't just stick a ROM for one device into another one. Well I guess QEMU will probably do…

Will you write a turtorial about this?

I will. It will probably take me ten years to finish, and it definitely won't be a turtorial suitable for anyone. Like for example, even if you have no previous exposure to any CS stuff except that you just self-taught JavaScript or Python by reading stuff from random places a month ago, no one's really gonna hold you back from reading it but you're going to have a LOT of pain.

From OSDev.org's Beginner Mistakes page there's this quote:

No one who isn't already a seasoned developer with years of experience in several languages and environments should even be considering OS Dev yet. A decade of programming, including a few years of low-level coding in assembly language and/or a systems language such as C, is pretty much the minimum necessary to even understand the topic well enough to work in it.

Well the truth is you really don't need literally a decade of programming; the important part is the preparedness, the determination and the whole picture of computer system from the highest level to the lowest level that got built with each project you've worked on. You have to be very prepared and have a fuck ton of determination so that you can still sustain yourself during the painstaking learning process (and you need a good roadmap; that's why I decided to read the first edition of Tanenbaum's book: it's short and simple enough). It's not just OS development; it applies to any CS topic as well. Stuff on OSDev.org can sound very scary; it's actually not that scary if you're willing to take the pain.

Also I was planning to take a serious look on TempleOS made by Terry A. Davis (RIP). That guy is really good. Probably could have learnt a lot from him. A full working OS that allow serious tinkering? That rich-text editor and those 3D graphics? All done by one person? That's no joke.

Can I become a master at OS dev just by going through your stuff?

Of course not, who do you think I am?

Wow I just read your code and your code is bad.

Yeah I guessed so… I started with writing different bits of code so there was never any overall organization. I have never done any "serious" low-level stuff as well, so it's a learning process for both you and me.

You sound all cocky in this blogpost (and I don't like that).

I don't know if I would be able to be cocky when I get to the more serious stuff. Compared to those things, the pain I take from coming up with this is tiny.

So what's the future plan for Mini16?

Preemptive multitasking of course.
File systems.
Proper infrastructures enough for one to write userspace programs with.
Probably replacing BIOS interrupt call with custom hardware drivers.

Back