This is an old revision of the document!
Table of Contents
In the beginning...
So, I got the idea to write a kernel. You know… Just to see if I could do it. Like me, you may have started reading stuff on the Internet to see what to do and what to learn and so on and so forth. I found lots of stuff to learn and to set up. Sifting through the myriad of ways to do it, this is how I progress through it. You may find some answers to your own roadblocks here.
Before you can begin
There will be things you need to know, and things you need to understand, and things you must be able to do, and so on.
Things you must understand:
- Real mode
- Programming
- Computer hardware
Things you must be able to do:
- Find information
- Have patience
- Learn
Things you must have:
- Coffee
- Punching bag
- Beer
(usually in that order)
Where to start
Decide upon your work environment. This will be the basis for your toolchain. I have Windows 10 running the Linux bash environment. This gives me good tools from both these environments. Also, you don't have to kill your Windows gaming computer if you do this.
When can you start
You need assembler basics and an understanding of what the x86 does to it. Also, an understanding of x86 memory aliasing will help in debugging.
The big issue is that you need build tools that does not consider user space. We're writing kernel, after all. User space is based on the kernel - which you will have to create as well.
First code
The assembler NASM will take you far in the beginning. It will create raw binary x86 code regardless of user space.
You can think of kernel as the code that talks to the hardware, and “user space” as the code that talks to the kernel.
At this point in the process, user space hasn't been created yet. We're in “real mode”, and no user space exists.
Boot loader
Many instructional articles on the net will assume existing boot loaders. That means adhering to conventions and so on. You don't need to. Learn by yourself.
If you strip it all down to the absolutely bare minimum, an x86 computer will - upon power-up - run through its BIOS (Basic Input Output System) sequence. When BIOS is done it will give control to your code. From there it's all up to you.
You will see (on the Internet) many references to multiboot and partitions. The ugly truth is that you don't need any of that. Make your own.
When the BIOS is done, it will load the first sector of the boot drive and execute the code it just loaded. That's really all there is to it. From there, you decide what happens.
This means that when your code starts, you have 512 bytes of code loaded at address “0000:7C00”. From there, it's all your design. No multiboot. No drive partitions. No files. Nothing.
Be creative. Make it better.
Some code
