Hrmmm, i'm hoping this isn't a redundant post, but my searches didn't come up with anything concrete.
I have been toying around with bootsector code as of late, and well one things leads to another, I suppose it has stirred my interest into more interesting areas, particularly OS development, or probably better worded pre-OS development (i'm realistic to the fact that as with most of my programming, it will never actually see the light of day :tongue: ). Anyhow, after reading numerous pages of documents written by lonely engineers (ahh what the hell, i'm one of them), i've run into a question that I haven't seen any definitive source for answers (could be right in front of my face though).
Anyhow, to make a long story short, i'm trying to find information regarding how first 1MB of physical memory on the x86 is actually broken up. I.E. what is being used, and more particularly what is it being used for? I've read there are certain areas that are *reserved* for something, but nothing so far has explained what the something is, nor do I have a full picture of where all these somethings are... and ultimately, what IS NOT used :grin:
Anyhow, I though I'd give a try here, perhaps someone can point me in the right direction (perhaps Bogdan??). I know he/perhaps others have/are/might be working on OS development, and he/they might have already encountered this question for themselves? (Or perhaps its a silly question, and i'm a little to dense to realize it).
Either way, thanks for any replies in advance,
-----
Domain
I have been toying around with bootsector code as of late, and well one things leads to another, I suppose it has stirred my interest into more interesting areas, particularly OS development, or probably better worded pre-OS development (i'm realistic to the fact that as with most of my programming, it will never actually see the light of day :tongue: ). Anyhow, after reading numerous pages of documents written by lonely engineers (ahh what the hell, i'm one of them), i've run into a question that I haven't seen any definitive source for answers (could be right in front of my face though).
Anyhow, to make a long story short, i'm trying to find information regarding how first 1MB of physical memory on the x86 is actually broken up. I.E. what is being used, and more particularly what is it being used for? I've read there are certain areas that are *reserved* for something, but nothing so far has explained what the something is, nor do I have a full picture of where all these somethings are... and ultimately, what IS NOT used :grin:
Anyhow, I though I'd give a try here, perhaps someone can point me in the right direction (perhaps Bogdan??). I know he/perhaps others have/are/might be working on OS development, and he/they might have already encountered this question for themselves? (Or perhaps its a silly question, and i'm a little to dense to realize it).
Either way, thanks for any replies in advance,
-----
Domain
well i suggest going to intels site and look there also they have great detail on memory usage..
Hrmm...
I haven't found anything in particular on Intels site, but that doesn't mean its there, maybe i'm just not looking in the right place. Just in case I wasn't clear on what i'm looking for: (WARNING!!! badly drawn ascii art)
----------------------
|
| Int Vec Table
|
----------------------
|
| Some Stuff
|
----------------------
|
| Unused (I.E. 7C00H - 7DFFH)
|
----------------------
|
| More Stuff
|
----------------------
|
| High Memory
|
----------------------
LOL, anyhow, its in these "stuff" areas I want to know about. Some things are reserved for BIOS, Video ROM, etc, I just don't know where they begin an end. This is as much a learning experience about these things as it is actually trying to accomplish code :grin: The main thing is I want to know what i'm doing before I even attempt to do it... i've read through numerous code examples about this stuff, but that doesn't mean I understand why they did it exactly that way :confused:
Thanks,
-----
Domain
I haven't found anything in particular on Intels site, but that doesn't mean its there, maybe i'm just not looking in the right place. Just in case I wasn't clear on what i'm looking for: (WARNING!!! badly drawn ascii art)
----------------------
|
| Int Vec Table
|
----------------------
|
| Some Stuff
|
----------------------
|
| Unused (I.E. 7C00H - 7DFFH)
|
----------------------
|
| More Stuff
|
----------------------
|
| High Memory
|
----------------------
LOL, anyhow, its in these "stuff" areas I want to know about. Some things are reserved for BIOS, Video ROM, etc, I just don't know where they begin an end. This is as much a learning experience about these things as it is actually trying to accomplish code :grin: The main thing is I want to know what i'm doing before I even attempt to do it... i've read through numerous code examples about this stuff, but that doesn't mean I understand why they did it exactly that way :confused:
Thanks,
-----
Domain
The fisrt megabyte of memory (0000:0000 to 000F:FFFF)
Conventional (Base) Memory is from 0000:0000 to 0009:FFFF (first 640K).
Upper Memory is from 000A:0000 to 000F:FFFF (last 384K)
Conventional Memory Setup
-The Interrupt Vector Table for x86 Real Mode is from 0000:0000 to 0000:03FF (the first kilo of memory)
-The BIOS Data Area is from 0000:0400 to 0000:04FF
-The bootsector is loaded in 0000:7C00 to 0000:7DFF (512 Bytes)
-Everything else is free game for usage in Conventional Memory, just watch out for the stack.
Upper Memory Setup
-The RAM for Graphics Mode Video Cards is mapped from 000A:0000 to 000A:FFFF
-The RAM for Monochrome Text is mapped from 000B:0000 to 000B:7FFF
-The RAM for Color Text is mapped from 000B:8000 to 000B:FFFF
-Video RAM is mapped from 000C:0000 to 000C:7FFF
-Special Adapter RAM is mapped from 000C:8000 to 000D:FFFF
-The motherboard BIOS is mapped from 000E:0000 to 000F:FFFF
Conventional (Base) Memory is from 0000:0000 to 0009:FFFF (first 640K).
Upper Memory is from 000A:0000 to 000F:FFFF (last 384K)
Conventional Memory Setup
-The Interrupt Vector Table for x86 Real Mode is from 0000:0000 to 0000:03FF (the first kilo of memory)
-The BIOS Data Area is from 0000:0400 to 0000:04FF
-The bootsector is loaded in 0000:7C00 to 0000:7DFF (512 Bytes)
-Everything else is free game for usage in Conventional Memory, just watch out for the stack.
Upper Memory Setup
-The RAM for Graphics Mode Video Cards is mapped from 000A:0000 to 000A:FFFF
-The RAM for Monochrome Text is mapped from 000B:0000 to 000B:7FFF
-The RAM for Color Text is mapped from 000B:8000 to 000B:FFFF
-Video RAM is mapped from 000C:0000 to 000C:7FFF
-Special Adapter RAM is mapped from 000C:8000 to 000D:FFFF
-The motherboard BIOS is mapped from 000E:0000 to 000F:FFFF
SpooK,
Thank you for the information, that was exactly what I was looking for :grin:
Now if I can just get around MASM's quirks (can't do far jump to absolute address directly, i.e. jmp 07C0:0002). :tongue:
-----
Domain
Thank you for the information, that was exactly what I was looking for :grin:
Now if I can just get around MASM's quirks (can't do far jump to absolute address directly, i.e. jmp 07C0:0002). :tongue:
-----
Domain
nasm can do that ;).
Also see this, in the past some(hutch) was trying to do ;).....
http://www.asmcommunity.net/board/index.php?topic=5505
Nice day.
Also see this, in the past some(hutch) was trying to do ;).....
http://www.asmcommunity.net/board/index.php?topic=5505
Nice day.
16-bit or 32-bit far jump?
Thank you all for the replies,
As it stands right now, I currently have the following code in place to generate the proper instruction (I don't like doing it this way however)
----- Snip -----
ORG 0H
BYTE 0EAH ; this is jmp FAR
WORD OFFSET Begin, 07C0H ; 07C0:OOOO
----- Snip -----
Which will essentially provide "jmp 07C0H:OOOO" where OOOO is the correct offset (although the offset should remained fixed the way I have layed out the file). At any rate, according to what I have read in the MASM documentation, not allowing this instruction directly was by design, and can be overcome by writing the following code:
----- Snip -----
Bios SEGMENT AT 07C0H ; Segment 07C0H
ORG 0H ; OFFSET within segment?
Example LABEL FAR ; Dummy Label
Bios ENDS
----- Snip -----
And then by using one of the following instructions:
jmp FAR PTR Example ; YUCK!
jmp Bios:Example ; A little better
jmp Example ; Nice and confusing
----- Snip -----
My understanding is that the "AT" parameter specified for the segment will instruct the assembler not produce any code, however, I find this to be particularly convoluted. This is one of those "things" that for whatever reason MASM has to go and complicate with new and strange ways. I haven't actually tried doing it this way, but it also seems as if there would be an issue of how the actual offset within the segement would be determined (I would assume it would be specifed via the ORG statement, however, I have never tried "ORG OFFSET LABEL", so I have no ideal whether or not it would be a definitive solution).
Anyway, thanks again,
-----
Domain
I played around with the "suggested" method from the MASM documentation, and well its not particularly pretty. Yes, it will generate the proper code, but the OFFSET is determined by the ORG within the segment, which must be initialized by hand... making it roughly equivalent to manually setting up the hex for the proper instruction... <sigh>
As it stands right now, I currently have the following code in place to generate the proper instruction (I don't like doing it this way however)
----- Snip -----
ORG 0H
BYTE 0EAH ; this is jmp FAR
WORD OFFSET Begin, 07C0H ; 07C0:OOOO
----- Snip -----
Which will essentially provide "jmp 07C0H:OOOO" where OOOO is the correct offset (although the offset should remained fixed the way I have layed out the file). At any rate, according to what I have read in the MASM documentation, not allowing this instruction directly was by design, and can be overcome by writing the following code:
----- Snip -----
Bios SEGMENT AT 07C0H ; Segment 07C0H
ORG 0H ; OFFSET within segment?
Example LABEL FAR ; Dummy Label
Bios ENDS
----- Snip -----
And then by using one of the following instructions:
jmp FAR PTR Example ; YUCK!
jmp Bios:Example ; A little better
jmp Example ; Nice and confusing
----- Snip -----
My understanding is that the "AT" parameter specified for the segment will instruct the assembler not produce any code, however, I find this to be particularly convoluted. This is one of those "things" that for whatever reason MASM has to go and complicate with new and strange ways. I haven't actually tried doing it this way, but it also seems as if there would be an issue of how the actual offset within the segement would be determined (I would assume it would be specifed via the ORG statement, however, I have never tried "ORG OFFSET LABEL", so I have no ideal whether or not it would be a definitive solution).
Anyway, thanks again,
-----
Domain
I played around with the "suggested" method from the MASM documentation, and well its not particularly pretty. Yes, it will generate the proper code, but the OFFSET is determined by the ORG within the segment, which must be initialized by hand... making it roughly equivalent to manually setting up the hex for the proper instruction... <sigh>
Okay, and now we return to my ever continuing saga, "As the OS is Coded" (bad soap opera pun).
At any rate, i've been screwing around with some code lately, and ran into another question (mainly about the first 1MB of memory). After the IVT (0-03FF), we run into the BDA (Bios data area), which is located (400-4FF). Delving a little further, if we check within the BDA, we can also ascertain if there is a EBDA (9FC00-9FFFF).
Now the EBDA doesn't exist on every computer, but I would assume the BDA would be pretty assured on most machines that I would be targetting. Now, it is my understanding that the BDA largely contains information about equiped hardware, IO, etc...and I've yet to find a reference to what the EBDA holds, but that being the case, how safe/unsafe are these areas? Are they just reference information for the operating system, or are they read / modified by something else? Going back to the olden days, I know some DOS memory managers will actually relocate the EBDA (and I assume update the BDA).
I appreciate any information that you can provide,
Domain
At any rate, i've been screwing around with some code lately, and ran into another question (mainly about the first 1MB of memory). After the IVT (0-03FF), we run into the BDA (Bios data area), which is located (400-4FF). Delving a little further, if we check within the BDA, we can also ascertain if there is a EBDA (9FC00-9FFFF).
Now the EBDA doesn't exist on every computer, but I would assume the BDA would be pretty assured on most machines that I would be targetting. Now, it is my understanding that the BDA largely contains information about equiped hardware, IO, etc...and I've yet to find a reference to what the EBDA holds, but that being the case, how safe/unsafe are these areas? Are they just reference information for the operating system, or are they read / modified by something else? Going back to the olden days, I know some DOS memory managers will actually relocate the EBDA (and I assume update the BDA).
I appreciate any information that you can provide,
Domain
The keybd buffer resides there as well as mouse pointer and system timer data etc. Most of what you see is reported by the BIOS and hence it's name the BIOS parameter block. There are other very important tables is the first 640K. The GDT resides at real mode address 3000:6000h in W2k sometimes and othertimes where XP puts it at 3000:f000h. Also below that is the page directory and page table for 4K entries. All these have to be loaded there in order to setup protected mode environment. They could moved after setup but they are not. The interrupt vector table seems to be changed radically between real mode and protected mode.
in real-mode, just after x86 machine boots, typically memory area E000:0000h - F000:FFFFh occupied by the "resident" BIOS code. Anyway, a more thorough explanation on memory system state related to BIOS can be found on my article about bios internals . But keep in my mind that the memory map described there is particular for my system, however some of them is general case for the x86 platform.