OSDev.org

Hello, i am about to start writing my OS, completly in ASM. So that you know:
I have alredy done a bootsector-show-message-reboot thing..
After that i did a bootsector that is FAT compatible and loaded osdata.bin from the disk. The osdata.bin file was in realmode and i never got the interrupts/or FS commands (like "dir") working. But it had a simple command-line with command like: about, version, help and reboot

So at this point i feel like i am ready to move on to protected mode and go serious. I have read all the faqs/tutorials that i could get my hands on, but i still have plenty of questions (if u got any, please send links..):

1. I wish that i could use the BIOS interrupts! I heard of something called "unreal-mode" that is like real mode with BIOS int´s enabled but with up to 4gb availible memory. Is this "unreal-mode" something i should consider?
Or does it suck completly? Can someone explain in simple english why the BIOS interrupts don´t work i pmode?

2. If the "unreal" mode sucks, and i still want the BIOS int´s, can i "re-make" them? Is there any free sourcecode (asm) out there that does that?

3. Can i set the A20-gate and protected mode somewhere else then in the bootsector code? Like setting pmode and A20-gate in some kernel-loader or something? This would be a realese, becasue it´s hard fitting it all in 512 bytes.

4. How should i organize everything? It´s pretty obious that the bootsector code come first, but then? Should i have the bootsector to load a kernel loader first, and if so, why? Should the kernel have a build in shell or should it be stand alone (like shell.bin), so you can replace it to be a completly gui-system if you want to? It sure keeps the kernel size down.. What would be the first things to write code for in the kernel (witch order)? Memory handling code first and then things like int´s or what?
Please discribe in witch order you should write things (and where to get info on how to do it).

5. If i find a way of getting (at least) the most common BIOS int services back and emulating some of the DOS interrupts, is it possible to run a DOS real mode program then? Does the realmode program need to have memory below the 1mb border? Can i trick programs to think that they got memory below the 1mb? Like the windows "dos-box"? How do they do it?

6. How should i organize the memory? If it is not possible to trick real-mode programs i should keep space for them below the 1 mb, or? Where should i place things? Like the kernel.. And the FAT table.. And, and..

7. I rippted the FAT code from some free bootsector code that place some FAT-info at some position i memory (i think.. ), how do i use the "fat-info" to do commands like dir, cd, etc..

8. Can i "tweak" FAT to allow at least a few more character in the filenames (maybe not 255 but.. ), like 20 or something? If i remember it right, the w95 (VFAT?) uses extra memory to store the long filname, but still have the 8.3 filename in the orginal fat info. It would be cool to skip this "extra-thing" they did and just "tweak" the orginal FAT to allow just a few more characters (of course as many as possible). Some info, on this?

9. Or should i just skip the FAT-**** (hehe, fat ****.. ) and go for another (better) FS?

10. Doing your own interrupts in pmode, how? Even better, make them exchangable, how? (i am thinking of making it possible to have diffrent compability modes that change the int´s to for example DOS-compability..)

11. May need to be repeated, witch order should i make it in? Like:
1. bootsector code (enter pmode and set A20?)
2. ???kernel loader???  (or could i do it here?)
3. kernel
  3.1 FS things?
  3.2 memory things?
  3.3 int´s?
  3.4 drivers?
  3.5 other thing that i forgot?
4. shell?
Or should it be in a diffrent order????

12. Witch this are absolutly necusary (please forgive my spelling!) to do in the bootsector code?

10. Other things that i should think about? Please inform me..! Please send links, thoughts and stupid comment calling me a n00b...

And last of all, thank you very, very much for getting the time reding all this bull****...

/ Christoffer

i forgot to ask things about task switching and stuff...
please help me out here..

/ Christoffer

I guess this means that nobody knows/whants to help, or???

/ Christoffer

Well first of all, google can answer pretty much all these questions. Look around, there's information out there.

1) You cannot use BIOS interrupts in pmode. Think of it this way: if in your bootloader you are merrily running in pmode and you suddenly do a jmp to some real mode code, the processor will crash and burn. BIOS interrupts are basically just indirect function calls, and the code it calls is compiled in real mode. If you *really* want to, you can keep switching back and forth between protected mode and real mode in order to call them, but that's ugly and slow.

What I do, and what pretty much every other OS out there does, is completely forget about the BIOS. I don't touch it. Period. I interact with the hardware directly.

"unreal mode" is a way of running real mode code in a way that gives them access to the full 4GB of addressing space normally only available to pmode code. I haven't used it before, so I can't comment on it.

2)

3) You can put it anywhere you want. Just remember though, that if you load your kernel image above the 1MB mark, you need to be able to access that, so you might want to use unreal mode.

4) Likewise, you can organize your kernel image any way you like. I use an ELF image, and I put the GDT, IDT, etc. in their own sections, but other than that all the kernel code is smooshed together in one section. I don't really care what order they end up in; if I need to know the address of a function or variable, I use nm (prints symbols and load addresses) to find out.

5) Yes, you write them.

6) Once you enable paging (assuming you do), you can trick programs into thinking they're on the moon if you want. If you map the lower 1MB to their codepage and put the system in unreal mode, then no one's the wiser.

7) Not sure, you'll have to look at the code and find out. I'm not familiar with the details of FAT.

Not sure.

9) If you want to, sure. FAT is pretty restrictive. I recommend using ext2 or something.

My OS has very unique demands on a file system. So much so, that it's going to be non-hierarchical. As such, I'm going to store entities in a flat binary tree on disk (kind of like ReiserFS does, but far simpler)

10) There are very good tutorials out there on this. Suffice it to say, this is most definately possible. That's how OSes catch traps, faults, and exceptions when they occur. Some use them for communication between user-space and kernel-space.

11) That's largely up to you as well. You'll probably want to write a console driver first so you can see what's going on, and some library functions to make coding easier, but other than that. Your order seems logical.

12) All your bootsector *has* to do is load your kernel image off a disc and jump into it. Everything else is optional.

10 aka 13) How about proper spelling/punctuation/diction?

Gnome.

hi
Frist the flat real mode ,in this mode you can run real mode code and use upto 4gb of memory ,and you can use bios int's. you still use 16 bit instructions ( or a 32bit perfix to use 32bit instructions).
To get in to this mode you go in to pmode set memory to 4 gb and go back down in to real mode with out reseting memory, you can not do this if you are alredy in pmode like win98 etc.

Yes you can set the a20 in loader.
yes you can make your own interrupts in pmode,a interrupt is like a procedure in asm,that does some thing, but at the end is iret.
in pmode you use ports to do things eg:

mov  ax,0  ; nterval time
out   43h,al   ; via port 43h
in     al,40h   ; make 2 accesses
in    al,40h    ; port 40h

This bit of code is a RANDOM NUMBER GENERATOR.
You can ues these ports to get the time,date,hdrive,cd,timer etc in pmode
There is a bootloader on the net ,that fits in the 512byte boot scetor
and will load a exe or com file from the disk ues this to start with,(but do not use any dos int's has you have no dos
hope this helps
  ASHLEY4

Of course you could what I do ie, use GRUB as the bootloader and concentrate on the kernel instead. I did write a bootloader but I consider GRUB a better solution because it allows me to have multiple OSes on my machine. If I need to test my OS on real hardware I simply write a GRUB entry that reads my kernel from a floppy with FAT12 and everything works fine without extra tuning.

I think that a kernel doesn't need to have an in-built shell and that it shouldn't have. Simplicity = reliability = maintainability or something like this. The smaller and simpler the kernel is the better of the kernel developers are.

In what order should stuff be in the kernel? Obviously you should do the most critical things first ie, the things which later things depend upon. First create a solid foundation and then build upon it. Memory handling is important but OTOH there are many things in the kernel which are critically important too. I don't think that there is one best solution to this.

I decided long ago that FAT is not the way I want to go. I can live with the fact that at the moment my kernel is on a FAT floppy but I will move to my own disk management system as soon as the necessary code is ready. At that point I will also switch from GRUB to my own bootloader.

Doing interrupts in pmode is AFAIK the same as it is in real mode. The only difference is the pointers you use for jumps and calls.

1. Unreal mode is not protected mode. It is a special form of real mode that lets you MOV data between registers and ANY address anywhere in memory. You can still use BIOS services. Unreal mode runs 16-bit code -- you CAN type in 32-bit instructions like "MOV EAX, [address]", but each such instruction will have a one-byte "override" prefix, just as it would in real mode.

2. It is possible, though difficult, to roll your own code to do the things the BIOS can do. You have to learn to talk to the hardware via the IN and OUT instructions, and learn what ports correspond to which devices, and learn what commands to send.

3. The only things you HAVE to do in the boot sector are (1) set up the segment registers and stack right away, (2) load the other sectors or files that contain your system startup code, and (3) jump to the code loaded. Everything else that won't fit into the boot sector would have to go into the startup code.

4. One way to do things is to put into your startup code everything that does not need to be run at any time EXCEPT when the system is booting (such as find out how much memory is installed), and then the code that needs to be run thereafter (such as task-switching code) goes into your kernel or other components. In this way, once the kernel is loaded, you can free up the memory taken by the startup code and use it for other things.

5. (Not sure about this one...)

6. Someone else will know more than I about this, but I think that if you want to run lots of real-mode programs, then either keep memory below 1MB clear as much as possible, or run them in Virtual-8086 (V86) mode. IIRC, paging works in V86 mode, so you could have several regions of high memory representing the block of conventional memory that real-mode programs require.

7. (???) If I understand your question: To write code to duplicate commands like "dir", you need to write code that can load a directory into memory, step through the directory entries, get the information out of the fields in an entry, and print the information to the screen. To do a command like "cd" you need to keep a current path in memory, so you know what directory "dir" needs to open, read, and display.

8. Microsoft did indeed "tweak" FAT16 to come up with FAT32, where a long filename is stored in a number of consecutive directory entries with "impossible" attributes. (Each entry in a directory has an attribute byte, which says the item is a file or a directory, and says whether the thing is hidden, read-only, a system file, a disk volume, and so on.) I don't remember the specifics, but if a directory entry can be made to contain 20 characters and your long filename is 50 characters long, then you'd use three of these special directory entries. Again, you'd use the attribute byte to distinguish these entries from real entries that point to real files or directories. You'd also need a way to store in the ORIGINAL entry the location of the entry containing the first part of the long name (either that or just store the long-filename entries right after the original entry). Do some research on FAT32.

9. Skip FAT? Maybe. Do you want to share files between Windows and your OS? Then you'll need support for FAT. On the other hand, if you're really ambitious and want fancy stuff like journaling and custom attributes (as in BeFS and ReiserFS), then FAT won't cut it.

10. To do interrupts in protected mode, you'll need to set up an IDT. The entries in an IDT aren't just pointers, so you'll need to do research on this.

11. I can't tell you how to set things up, except that you can't run and test a kernel until you have written the code to load and run it.

12. Answered above.

13. Go slowly. Write a little bit of code at a time and test it before moving on. Have patience. Be willing to write throwaway code just to try things out and see what works and what doesn't.

Thanks to you all for the good answers!
I must say that "unreal" mode seem quite intresting, but i don´t know...
Someone that tested it?
I feel like i am about to get a grip one most of the things now, but GDT´s an (or whatever), what´s that?
I am writing the OS in pure Assembler (nasm), so it would be really nice to get some "public domain" kernel in nasm-code, that does some (or most) of the things i trying to do..
(Some example code of a protected mode memory manager would be more that great!)

Thanks to you all!
/ Christoffer

Hi Christoffer,
The GDT(the global descriptor table) the GDT contains 8byte descripyors for each protected mode segment. Each descriptor contains a 32 bit segment base address, a 20 bit segment limit and 12 bits desribing tne segment type.
That is what GDT's are you have one for code, one for data and you useally one with a linear (data).
You say that you use nasm, i too used to use nasm but now i use fasm which is almost compatalbe with nasm.  The reason that i use fasm is that if you use nasm this compiles with gcc(c compiler) if you made a operaiting system and you wanted to put nasm on it, you would not only have to run nasm but allso gcc wich both are very big and complicated, fasm is only 56k and compiles its self, comes with code, the geniuse that made it made it for his own opperaiting system and thats why it is so good for making OS's, it has its own forum and demo code for doing flat real mode its got compilers for DOS, WINDOWS and linux (the dos one runs in fat real mode) .
If you wanted to test a flat real mode programm in DOS, you could run the compiler, this puts DOS into flat real mode then any real mode DOS programm can use upto 4gb of memory.
As for the code for protected mode get the demo's by Christopher Giese.
I think that it is called pm.zip thease are writen in nasm and are the best tutors and demo's for pmode.
good luck
ASHLEY4

Ok, i think i have heard about fasm before; in MenuetOS.
So i guess that the guy who did MenuetOS also did fasm or compiled it for MenuetOS. Is it easy to re-compile it for your own OS?
It would really be great to have an easy to port Assembler for your own OS.
The size of it sounds nice too..
Exactly how compatible is it? Sounds good anyway..
Now i just have to see if my "public domain" (nasm) bootloader and loader.bin (that enters pmode and enable A20-gate) is working.
I did not trust my own bootsector becasue i cut´n´pased lots of it.
Isn´t pmode tutorials thats not based on os-dev depending on a dos extender?
I will check the pm.zip file that i know that i got in my huge "OS-dev archive". I accually think that i have downloaded most of the OS-dev files on the net..

But i am problably going to be back..

/ Christoffer