OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:47 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: X86:MBR page modification
PostPosted: Fri Aug 04, 2006 11:49 am 
Offline

Joined: Fri Aug 04, 2006 11:30 am
Posts: 1
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 :D


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 06, 2006 2:41 am 
Offline

Joined: Sun Aug 06, 2006 2:19 am
Posts: 6
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. :/


Top
 Profile  
 
 Post subject: Re: X86:MBR page modification
PostPosted: Sun Aug 06, 2006 4:28 am 
Offline
Member
Member

Joined: Sun Jun 18, 2006 7:21 pm
Posts: 260
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 :D


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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 06, 2006 11:09 am 
Offline
Site Admin
User avatar

Joined: Wed Oct 20, 2004 10:46 pm
Posts: 684
Location: Texas
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. :/

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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 08, 2006 4:53 am 
Offline

Joined: Sun Aug 06, 2006 2:19 am
Posts: 6
Quote:
=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.


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


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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 08, 2006 6:41 am 
Offline
Site Admin
User avatar

Joined: Wed Oct 20, 2004 10:46 pm
Posts: 684
Location: Texas
I added you to the wiki group FMota.

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 08, 2006 5:49 pm 
Offline
Member
Member

Joined: Sun Jun 18, 2006 7:21 pm
Posts: 260
Nice work. Fixed the MSB/LSB issue.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 24, 2006 11:31 pm 
Offline

Joined: Fri Nov 24, 2006 10:55 pm
Posts: 20
Location: C eh, N eh, D eh
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 25, 2006 3:43 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

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?


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:
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:
    mov eax,0x00000000
    mov ax,0x0000
    mov al,0x00
    mov ebx,0x000001DE
    mov ecx,0x0000FACE


And not:

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



Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 25, 2006 8:15 pm 
Offline

Joined: Fri Nov 24, 2006 10:55 pm
Posts: 20
Location: C eh, N eh, D eh
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 25, 2006 11:49 pm 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 9:29 pm
Posts: 2426
Location: Canada
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.


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

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

_________________
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 26, 2006 5:42 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

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.


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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 26, 2006 6:18 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 04, 2005 12:00 am
Posts: 381
Location: Serbia
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)?


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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 26, 2006 8:53 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

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


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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 26, 2006 9:51 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 04, 2005 12:00 am
Posts: 381
Location: Serbia
@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)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group