OSDev.org

mugen_kanosei wrote:Hi, ive been interested in OS programming for awhile now and the wiki looks like it will be great once more information starts getting put up. I noticed on the X86:MBR page that the formula "MemoryPlace = Segment * 10 + Offset" was a little ambigous until I ran through the math. Im just suggesting it be changed to "MemoryPlace = Segment * 0x10 + Offset" so newbs like me dont get confused

FMota wrote:In fact, I think there are other errors on that page. I'd be willing to go over them, but I don't have edit access. :/

=How the MBR is Loaded
First thing for you to understand is where the MBR program is loaded to in memory. Much like the special "0x55AA" pattern, the location in memory for the MBR is just a means to create a standard. All x86 based processors load the 512 Byte MBR program to memory at 0000:7C00. That address format (0000:7C00) is nothing more than the adaptation of the old 16-bit "segment:offset" format back when memory could only be addressed 64 Kilobytes at a time. The true format of that memory location would have been 07C0:0000, which basically states that the 64 Kilobyte region starts at 0000:7C00 and stops after 64 K (1000:7C00 or 0x17C00). The trick was for a program to change the contents of the segment registers so they would essientally state "I'm accessing this 64 Kilobyte segment of the total memory". With the 32-bit processor series (Intel 80386 and above), this memory addressing limitation was expanded to a total of 4 Gigabytes when using 32-bit Protected Mode, so we do not have to worry about changing segment registers to access different parts of memory.

=Memory Address Basics
If you already know the basics of the memory address format and the hexidecimal number system, skip this next paragraph. If you do not, let's quickly break down the memory address format so it can be understood better. Think of the format like you do the decimal number system, each digit is a place holder. The only difference is that each place holder is in hexidecimal format, which means as we move place holders from right to left they become significantly larger and represent a much larger value. For example, 0x00000001 is at one byte, 0x00000010 is at 16 bytes, 0x00000100 is at 256 bytes, 0x00001000 is at 4 Kilobytes, 0x00010000 is at 64 Kilobytes, 0x00100000 is at one Megabyte, 0x01000000 is at 16 Megabytes and 0x10000000 is at 256 Megabytes. The maximum address value is FFFFFFFF, which is at the 4 Gigabyte limit. If you noticed, the place holders from right to left grow by a factor of 16, and hexidecimal is a 16-base number system... yes... number systems are that easy.

=Assumptions: Stack
For the next assumption we will introduce you to the stack. Think of the stack as one giant variable in memory used for the quick storage and loading of data. The stack segment (SS) and stack pointer (SP) are 16-bit registers that combine to specify a 20-bit memory address in real mode, which is the "top" of the stack. When the stack is used to store data, the amount of data stored is subtracted from SP and then is stored into memory using the SS and SP registers as a memory location (SS:SP). When the stack grows, it will grow downwards in memory, not up. Since you are required to set up the SS and SP registers, it is probably a good idea to set SS to 0x0000 and SP to 0x7C00 because we know everything between the beginning of memory and up to 0000:7C00 is pretty much unused since we are in an uninitialized state (we will expand on this later), and should be big enough for our needs.

Mr.Confuzed wrote:About adding the 0x to all the hex values: Is there any reason for using the 0x prefix instead of the h suffix? I personally prefer the h. It is easier to use and makes sence to me. By the way, where did the 0x notation come from?

OH:   db 'Oh, how confusing!",0

   mov eax,0H
   mov esi,OH
   call print

    mov eax,0x00000000
    mov ax,0x0000
    mov al,0x00
    mov ebx,0x000001DE
    mov ecx,0x0000FACE

    mov eax,0x0
    mov ebx,0X1DE
    mov ecx,0xFace

Mr.Confuzed wrote:Alright, that makes sense now. I'll be moving my pathetic excuse for an operating system over from NASM to VC++ Express soon, so it's good to know which format is likely to work. Thanks for the tip.

Mr.Confuzed wrote:Alright, that makes sense now. I'll be moving my pathetic excuse for an operating system over from NASM to VC++ Express soon, so it's good to know which format is likely to work. Thanks for the tip.

Brendan wrote: How hard will it be to shift your OS from NASM to VC++ in the near future (step A), how much time will developing in VC++ save you (step B), and how much time will it take you to port VC++ to your OS in the distant future (step C)?

kataklinger wrote:And last one, you cannot port VS/VC++ to your OS, the only thing you can do is to fit OS so it could be able to support VS/VC++ (developers of ReactOS say that they are able to run VS2k5 on that OS).

• a) you're using VC++ as an IDE for NASM (in which case you're using NASM, not VC++, for code generation)
  b) you're willing to accept the intefaces Microsoft uses and plan on running an unmodified version of VC++ on your OS (I doubt there's many people here that are willing to accept the limitations this places on your OS design or have the time necessary to actually make it work - makes more sense to join ReactOS)
  c) you're not planning on being able to compile your project on your OS (possible, especially if the OS is being done for educational purposes only)
  d) you're planning on shifting to a different compiler later on (which doesn't make much sense if you can shift to the other compiler now)
  e) you're writing code that is extremely portable, and the specific compiler doesn't make much difference (unlikely for an OS, considering that it's hard to write any non-trivial code in C/C++ without using non-standard compiler extensions, and that the standard libraries that usually hide architectural differences aren't too useful)