OSDev.org

I am just getting started w/ os development, and i have a clear idea of what i want to accomplish: a minimal self hosting os, to perform basic tasks (text editing etc.) and MAYBE a small gui in userspace later if it makes it that far. I think i sufficient programming experience; its more of a fun project, not functional.

So, getting the the point. I've started trying to write a small bootsector that will load my kernel, however, i cannot get into protected mode correctly, or jump to the loaded sector

I was wondering if there was some REALLY SIMPLE code, that compiles, and runs that i could take a look at as a starting point. Just a small kernel and bootsector, w/o any features.

Is protected mode needed for something as simple as i am doing? I would like to have some sort of multitasking, and im not sure if this is plausible in real mode. Real mode would let me use BIOS, which would make my job easier, however, im afraid that migrating the code to protected mode when i need to use it for features like multitasking will difficult, and would require a full rewrite.

What are your thoughts?

I suggest you stay with 32-bit. It might be harder, but it has a lot more benefits than real mode. As for the boot code, did you try the wiki?

How is the wiki licensed (the code, + tutorial code)? gpl? free domain?

anon19287473 wrote:How is the wiki licensed (the code, + tutorial code)? gpl? free domain?

I'm pretty sure all source code on the Wiki is Public Domain... unless otherwise noted?

There is no notice about how the documentation is licensed. Officially this means 'all rights reserved' but everybody treats the wiki as being public domain, and as such a lot of people can be sued for copyright infringement

I would go for realmode, as you already saying, if i get that far, i have post some code that may help, MiniDos is a dos clone, i made that can load and run many old dos programs including game, i written it as a realmode OS tut, it less than 2k in size.
Next is nanoos2, a realmode multi-tasking demo that fits into boot sector (512bytes), you can do MT in realmode.
Also it very easy to go from realmode to pmode do anything you want, than go back to your realmode OS's CLI.
Minidos
http://board.flatassembler.net/topic.php?t=5275&start=0
Realmode multi-tasking
http://www.dex4u.com/ASMcompo512b/nanoos2.zip

anon19287473 wrote:I am just getting started w/ os development, and i have a clear idea of what i want to accomplish: a minimal self hosting os, to perform basic tasks (text editing etc.) and MAYBE a small gui in userspace later if it makes it that far. I think i sufficient programming experience; its more of a fun project, not functional.

So, getting the the point. I've started trying to write a small bootsector that will load my kernel, however, i cannot get into protected mode correctly, or jump to the loaded sector

I was wondering if there was some REALLY SIMPLE code, that compiles, and runs that i could take a look at as a starting point. Just a small kernel and bootsector, w/o any features.

Is protected mode needed for something as simple as i am doing? I would like to have some sort of multitasking, and im not sure if this is plausible in real mode. Real mode would let me use BIOS, which would make my job easier, however, im afraid that migrating the code to protected mode when i need to use it for features like multitasking will difficult, and would require a full rewrite.

What are your thoughts?

Just use GRUB, for God's sake. It loads your kernel and jumps to the kernel entry point in protected mode, with flat segmentation and no paging. You'll want to change those early on yourself, depending on what you want to accomplish, but GRUB gets the job done with no fuss.

Real mode can only address 1 MB of memory, and that using segmentation. Use protected mode with flat segmentation; it's far simpler than real mode.

If you are on beginning on OS developing, you have five choices:

1. Real mode. Simplicity. BIOS does all the work for you, you can access the machine ports with IN and OUT just like pmode does. In pure real mode exists a segmentation - each segment is splitted to 64K. Simple. You can use multitasking too, without worries.
They are also the limitations - you can access no more than 1 MB of RAM and BIOS is not good for every action your OS does, like RS232 COM terminal - i have this written by hand, not using BIOS (except basic text I/O routines etc.). In other words, you will have 16-bit operating system, and, dated.

2. Unreal mode, a.k.a. Big Real Mode/Flat mode/Voodoo mode.
This is a modification of real mode - you can access more than 1 MB of RAM, theoretically, to pmode segment limits - 4 GB (!). BIOS, of course, allowed. But unreal mode has some limitations too:
Accessing up to 4GB RAM is accepted only by data segment registers; CS, IP, SS,SP and other seg registers are unaffected. So the code size must be less than 64K or UPXed, just like real mode.
BIOS doesn't like that you are combining unreal mode with it - if you want to use unreal mode properly, just load the data from BIOS onto conventional memory (640K) and THEN move above 1 MB limit. (And clear the used memory in 640K limit). Multitasking is, by the way, allowed.
Using unreal mode you will get a 16-bit operating system but the OS will be not that limited as standard RM is. I use this mode too.

3. Protected mode.
Do you feel the difference between real mode? No 1 MB limit, no 64K code limits anymore, all registers are 32-bit (i think), there is a protection system and many more, like big chaos if you are converting your OS from real mode to pmode. You will need to learn how to live without BIOS present, also, new memory managment. You must do it all with REP MOVS,OUT,IN,MOV,etc. No INT.

4. Virtual 8086 mode, a.k.a. V8086 or vm8086 mode.
This is a sub-mode of protected mode, when you can access BIOS and real mode things. You will do all this by multitasking (task switch seg), and in protected mode. Switching and working V8086 mode isn't that easy so most programmers are here using other modes.

5. Long mode.
I dunno much of information about this mode. But I think this is the native mode of 64-bit processors.

The choice is yours.
inflater

Multitasking can be done in real mode. I had my old 16 bit os which used to run in dosbox as a .com file (it never used any of dos interrupts). It could do multitasking nicely with different time slices for different tasks.

Thanks for the replies. I think I'm going to start w/ real mode, just to get the swing of things, and then rewrite the functions for pmode when i think im ready (or perhaps unreal). Thanks again.

EDIT: As for GrUB, unfortunately I'm running Windows at the moment, becuase Fedora Core crapped out on me, and I wouldn't be able to operate a linker and related tools well in such an unfamilier environment. Hopefully I'll have time to install slackware, but until then, I'm just gonna bootstrap from DOS.

If I use DOSBox for emulation, can i redefine the interrupts?
Do i lidt to load an interrupt table in real mode?

Peace.

anon19287473 wrote:Do i lidt to load an interrupt table in real mode?

You use the IVT. It's pretty simple, but I can't find my old code to remember how exactly....

Oh and as for using DOS for starting a system, this only works if you actually have a real DOS. In old Win9x systems you have one when you exit Windows, since those were built to start from DOS, but what NT gives you when you start a DOS program is nothing more than a VM86 monitor and some emulation to redirect BIOS requests and raw device access to NT drivers.

NTs emulation isn't the best around even if you stayed in "real mode" so don't develop an OS under this environment, because there won't be much of a guarantee it'll actually work on real machines.

So since from a modern Windows you need to use some emulator anyway, you could use something like Bochs or VMWare just as well. And if you do that, there'll be little point loading DOS inside it, instead of just working on the hardware directly (with or without BIOS).

Like i said, hopefully in the next week or so ill have Slackware set up, and i can use qemu, but becuase Windows doesn't have any tools to effectively mount images etc. ill just use the lame Windows emulation for now, periodically testing it on a real machine.

anon19287473 wrote:Like i said, hopefully in the next week or so ill have Slackware set up, and i can use qemu

qemu is on Windows

anon19287473 wrote: but becuase Windows doesn't have any tools to effectively mount images etc

try WinImage for now

VFD is good if you're working with floppy images. The best part is that you can load an image into RAM which exponentially increases access speed.