X86:MBR page modification

[mugen_kanosei]

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]

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. :/

[SpooK]

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

Changed it to 16 (decimal), even easier for "newbs"

[chase]

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. :/

I give out access to anyone that has posted here a while if they ask. For people with new accounts here I'd like to make sure they aren't people looking to spam the wiki so I ask for a sample of what you'd change/add or just a link to something that I can verfiy you've worked on such as a tutorial somewhere else or your own OS code.

[FMota]

=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.

Anyway, that's all I can be bothered to check out right now. A lot of the information in that article is a bit misleading. The bit on Little Endian isn't very well explained at all. What it should say is something like:

dw 0x55AA
generates the same output as db 0xAA, 0x55
because the least significant byte comes first. The article should avoid saying 0xAA55, it should either say 0x55AA, or 0xAA 0x55

Well, hope this helps mis-mislead people. Cheers.

[chase]

I added you to the wiki group FMota.

I also noticed that we need to add 0x in front of all hex values.

[SpooK]

Nice work. Fixed the MSB/LSB issue.

[Mr.Confuzed]

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?

[Brendan]

Hi,

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?

I'm not sure where the "0x" prefix comes from, but it's the only prefix that's supported by most C compilers (something like "1234h" gives an error on GCC).

To be perfectly honest, using the "h" suffix should be banned, because it looks too much like a label:

Code: Select all

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

   mov eax,0H
   mov esi,OH
   call print

For (almost?) every hexidecimal number I've written in the last 3 years, I've used "0x" as the prefix with a lower case "x", with uppercase digits and zero padded to indicate the intended size.

For example:

Code: Select all

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

And not:

Code: Select all

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

Cheers,

Brendan

[Mr.Confuzed]

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.

[Brynet-Inc]

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.

Moving a pathetic excuse for an operating system over to a pathetic excuse for a compiler? How original

(I've never seen your OS.. it could be great.. but I never turn down a chance to insult software written (apparently..) by Microsoft)

[Brendan]

Hi,

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.

First, ignore Brynet-Inc (he lacks tact), but...

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)?

More precisely, will "step B - step A - step C" add up to an overall time saving, or is there some other tangible benefit that makes it a worthwhile?


Cheers,

Brendan

[kataklinger]

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)?

Switch from Nasm to VC++, what did hw mean by that? After all you can integrate NASM in VS enviroment very easy. In VC++ project you have to change Custom Build Option for ASM files, NASM has a switch to produce VC++ compatible error report, and that's it! All done and ready to roll!

Developing in VS can save you a lot of time if you know how to use it (it is always better using tools you know how to use, then using tools you don't know how to use).

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).

[Brendan]

Hi,

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).

That's the point...

In general, everyone does things differently, but I can only think of a few cases here:

• 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)

The only important thing is to know why you're doing what you're doing (rather than doing something because it sounded easy at the time, for example)...


Cheers,

Brendan

[kataklinger]

@Brendan:
I would add options F and G:

f) you can port some other compiler and modify it to support existing source code of your OS.
g) build layer VC++ and OS, so your OS looks like like Windows to VC++ (something like WINE)