Hi can someone help me write some asm or C code that will load the mbr on drive C and start
executing it.
many thans,
root.
please help me witth a small problem
RE:please help me witth a small problem
How 'bout your just push the reset button...? (ie, the bios does that!)
RE:please help me witth a small problem
Get GRUB u dont need to code any Loader, unless u really want to reinvent wheel.
RE:please help me witth a small problem
i am also working on it;the thing matters here is not code bot the true way.
the code is pretty simple
use bios interrupt 13h to load sector 0 (MBR)at some location
than jmp to it using assembly .
try it than you will see then the code of MBR wouldn't run it will hang or give message like Illegal operation or something. WHY?
my personel opinion is that this is due to difference between REAL MODE and PROTECTED MODE.Running over an os that uses more than 16 mb or about means that you are runing in PROTECTED mode and the MBR code is designed to run in REAL mode .I think that makes the difference .See also my question.
Thankyou
the code is pretty simple
use bios interrupt 13h to load sector 0 (MBR)at some location
than jmp to it using assembly .
try it than you will see then the code of MBR wouldn't run it will hang or give message like Illegal operation or something. WHY?
my personel opinion is that this is due to difference between REAL MODE and PROTECTED MODE.Running over an os that uses more than 16 mb or about means that you are runing in PROTECTED mode and the MBR code is designed to run in REAL mode .I think that makes the difference .See also my question.
Thankyou
RE:please help me witth a small problem
This is a kinda confusing answer, yes all boot sectors and MBR are designed to run in realmode, but then if you are using int 13h then you must also be in real mode, so I don't see your issue here.
Note that bios will always load the boot sector/MBR to 0000:7c00h or 07c0:0000h or however you want to define it. If you load it else where it may not run properly (depending on how it was coded). If you always load it to 0000:7c00h then it SHOULD run (anyone know anything to the contrary ?)
Again, back to the original response to this, why not just perform a reset and let bios do it, or use a simulator like bochs
Note that bios will always load the boot sector/MBR to 0000:7c00h or 07c0:0000h or however you want to define it. If you load it else where it may not run properly (depending on how it was coded). If you always load it to 0000:7c00h then it SHOULD run (anyone know anything to the contrary ?)
Again, back to the original response to this, why not just perform a reset and let bios do it, or use a simulator like bochs
RE:please help me witth a small problem
So, am I correct in assuming that you're making a user level program, in an existing OS, to load in a boot sector and execute it?
what OS are you attempting to do this in?
The _only_ OS that this is even remotely possible in, would be DOS. One, because you can still access BIOS int 0x13, and two, because you can just randomly write to memory, such as 07c00.
If you're trying to do this in any other OS, then you _should_ be getting errors, reboots and illegal operations. No OS should allow you to read a sector from disk and write it randomly into memory.
However, while this _is_ possible in DOS, that doesn't mean it's _workable_ First off, you can't be garaunteed that 07c00 is free... no doubt it's in use by a DOS device driver, and overwriting it with anything is never a good idea.
Secondly, having written to 07c00 with your boot sector, what does it do? If it loads in a kernel then, again, you're overwritting potentially used memory, which is also not a good idea.
If you _must_ do this (which I'm quite certain you don't) you'll need a relocateable boot sector, and a relocateable kernel. And your user level boot program is pretty much restricted to plain vanilla DOS (it wont even work in a Win95+ DOS prompt...). This is obviously a pretty huge limitation, unfortunately.
Lastly, an OS that uses more then _1_MB of memory must be running in protected mode (or, more specifically, must switch to protected mode (or unreal mode, or other variants) to read/write to those memory addresses above 1MB).
Memory use above _16_MB (I believe) simply signifies the use of 32-bit protected mode... I seem to recall that the 286's protected mode had an upper limit of 16MB of memory access... but... it's been ages since I've used 286 pmode, so... I could be wrong
Hope that helped...!
Cheers,
Jeff
what OS are you attempting to do this in?
The _only_ OS that this is even remotely possible in, would be DOS. One, because you can still access BIOS int 0x13, and two, because you can just randomly write to memory, such as 07c00.
If you're trying to do this in any other OS, then you _should_ be getting errors, reboots and illegal operations. No OS should allow you to read a sector from disk and write it randomly into memory.
However, while this _is_ possible in DOS, that doesn't mean it's _workable_ First off, you can't be garaunteed that 07c00 is free... no doubt it's in use by a DOS device driver, and overwriting it with anything is never a good idea.
Secondly, having written to 07c00 with your boot sector, what does it do? If it loads in a kernel then, again, you're overwritting potentially used memory, which is also not a good idea.
If you _must_ do this (which I'm quite certain you don't) you'll need a relocateable boot sector, and a relocateable kernel. And your user level boot program is pretty much restricted to plain vanilla DOS (it wont even work in a Win95+ DOS prompt...). This is obviously a pretty huge limitation, unfortunately.
Lastly, an OS that uses more then _1_MB of memory must be running in protected mode (or, more specifically, must switch to protected mode (or unreal mode, or other variants) to read/write to those memory addresses above 1MB).
Memory use above _16_MB (I believe) simply signifies the use of 32-bit protected mode... I seem to recall that the 286's protected mode had an upper limit of 16MB of memory access... but... it's been ages since I've used 286 pmode, so... I could be wrong
Hope that helped...!
Cheers,
Jeff
RE:please help me witth a small problem
Successive use of interrupt 13h doesn't mean you are in REAL mode .Suppose you are in protected mode and you wanna use int 13h's operation(i mean working with individual sectors)than what would you do.You can design a code which directly manipulates the disk controller and diskdriver and loads the required sector for you.REMEMBER that you are in PROTECTED MODE.Then you can setup the IDT(Interrupt Descriptor Table) with entry no. 13h to point to your above mentioned code.Now what interrupt 13h is ready .Now if this code is correct it will work for you same as the BIOS interrupt 13h in REAL mode.
SO think of an OS which does all above mentioned work for you .Now you are using interrupt 13h in Protected mode without knowing that in which mode you are now in.As i know , WINDOWS does the same for BIOS compatibility.
As about location 0000:7c00h .Runnning code from any location accept 0000:7c00h doesnot mean anything useful even in real mode.I always loaded it at 0000:7c00h and i checked, it only runs in real mode and not on protected mode.
Thanks
SO think of an OS which does all above mentioned work for you .Now you are using interrupt 13h in Protected mode without knowing that in which mode you are now in.As i know , WINDOWS does the same for BIOS compatibility.
As about location 0000:7c00h .Runnning code from any location accept 0000:7c00h doesnot mean anything useful even in real mode.I always loaded it at 0000:7c00h and i checked, it only runs in real mode and not on protected mode.
Thanks