How to write a simple operating system
mikeos.berlios.de
mikeos.berlios.de
Instead, I suggest using GRUB to boot your kernel image. It leaves you in 32-bit mode and a relatively sane state. It's not hard to write a loader file (in assembly) which contains the multiboot header and an entry point. Presumably you'll want to set up a basic C runtime environment and call your C "main" function.
NIH applies like always, but if you plan on taking control of the machine you might as well begin at the beginning. Rolling your own BIOS would be a step too far I think :)
That's why the micros are an interesting option, they're running on real hardware but can be flashed in seconds and debugged in realtime with a JTAG cable. Very convenient. But on the other hand they tend not to have much storage or network connectivity, so it depends on what you're interested in if they're the right choice. Blinking LEDs and controlling step motors is always fun, though!
The Intel 8086 could only access 1MB of memory (using 20 bits). While this was great for the early 80s, it started to become a problem later on. This was fixed in the Intel 286 (which could address up to 16 MB of memory) but needed to be compatible with the 8086 at the time.
The 8086 had 20 individual gates or address lines numbers A0 - A19. This meant that there were different ways of referencing the same addresses in different numbering systems, most notably in hex. When you went over FFFFF, you'd actually wrap around. Some software relied on this (it was the 80s after all. For further examples of wrongness in the 80s see big hair and shoulder-padded suits).
For the 286 to access 16MB while enabling compatibility with the 8086 a kludge was invented. An extra logic gate (A20) was added to the keyboard controller that would enable or disable access to memory above 1MB. The bios enables it when it checks memory, then disables it when transferring it to the OS. The boot loader (normally) runs through a series of checks, reads the keyboard, makes sure the keyboard buffer is empty and sets the gate as part of switching into 32-bit mode on x86.
This still happens, even on your top of the range 64-bit quad core behemoth if you're running a 32-bit Operating System. I'm not sure whether this still applies to 64-bit Operating Systems as they were after my time, but if anyone here can tell me I'd love to know.
Personally I've always felt that the A20 part wasn't that hard - perhaps it's the wrong term but the hardest thing for me was all the checks for the right hardware, I kept finding stuff that works fine in bochs or qemu then barfs on real kit.
An extra logic gate (A20) was added to the keyboard controller that would enable or disable access to memory above 1MB.
Yes, the fact that it's on the keyboard controller is the single biggest WTF about the whole thing.
This still happens, even on your top of the range 64-bit quad core behemoth if you're running a 32-bit Operating System. I'm not sure whether this still applies to 64-bit Operating Systems as they were after my time, but if anyone here can tell me I'd love to know.
As far as I know, yes it's still part of the boot process even for operating systems that run in long mode (i.e, x86-64).
Personally I've always felt that the A20 part wasn't that hard - perhaps it's the wrong term but the hardest thing for me was all the checks for the right hardware, I kept finding stuff that works fine in bochs or qemu then barfs on real kit.
It's not so much that it's hard... if you're like me, you spend a good half an hour trying to make sense of what it is, then copy-paste some code to do it. I was just using it as an example of a seriously weird 'feature' of the architecture.
https://github.com/xomboverlord/xomb-bare-bones
It's a bit of a niche inside a niche: it explains how to set things up to write an OS in D. This was extracted from the OS that my friends and I started a while ago, that's now two of theirs' PhD research:
I used my diploma thesis as an excuse to build a toy OS on top of a L4 (L4Ka::Pistachio) microkernel. It provides the basics, incl. IPC and VM building blocks, and a straightforward C/C++ API, and you can do the rest (there's also a number of things built on top of it that you could mix'n'match - i just implemented most of my userspace stuff because that was what I was interested in).
Some links (haven't been in touch for a few years, I don't know how up to date they are):
L4Ka project: http://os.ibds.kit.edu/1953.php OKL3 (successor to Pistachio, as far as I can tell): http://wiki.ok-labs.com/ Iguana, a set of components to be (re)used on top of L4: http://www.ertos.nicta.com.au/software/kenge/iguana-project/... Misc L4 resources: http://www.l4hq.org/projects/os/
If anyone's interested, I could try to find my old code and put it on GitHub (it's a combination of MIT and GPL licenced things).
http://www.jamesmolloy.co.uk/tutorial_html/index.html
He includes a lot of details, and seems to try to do things "The Right Way" as much as possible. (Not that I am a good person to judge that)
http://www.cs.utah.edu/flux/oskit/
OSKit aims to be a set of libraries that dramatically lower the barrier to entry on OS development.
What you should do instead is write the kernel and just load it with GRUB. It allows you to immediately jump into the interesting stuff that makes your kernel unique, makes it easy to test on real hardware without getting a second machine, and makes it possible to dual-boot with it if/when you get that far.
I haven't tried this, but it might be fun to write a kernel for some other system- some ARM device, maybe. Any kind of bootloader would be infinitely less encumbered with x86's layer upon layer of compatibility stuff.