OSDev.org

Posted: **Fri Jan 12, 2007 12:13 pm**

Restart or reboot is very, very simple:

RESTART:

JMP FAR 0FFF0h:0F000h

REBOOT:

Code: Select all

INT 19h

POWER OFF (using older APM 1.2)

Code: Select all

mov ax,5301h
xor bx,bx
int 15h
mov ax,530Eh
mov cx,0102h
int 15h
mov ax,5307h
mov bl,0001h
mov cx,0003h
int 15h

I am not sure that both functions will work under PMode, i use them in my (un)real mode OS and they works perfectly.

But, when you are turning off a PC, who cares in PMode? You can very easily switch to real mode (this is my code, so try it and tell if it works

):

Code: Select all

MOV EAX,CR0
AND AL,0FEh
MOV CR0,EAX

[EDIT: Changed the NOT negator]

This is a very simple example why real mode can be still handy in some situations

Good luck!

inflater

Posted: **Fri Jan 12, 2007 1:32 pm**

inflater wrote:Restart or reboot is very, very simple:

RESTART:
Code: Select all
JMP FAR 0FFF0h:0F000h

i would avoid doing this, as you cant really be sure what the result will be (preferably, it would switche to PMode, and transfers control to the BIOS entry point, however, it might decide to take shortcuts)

REBOOT:
Code: Select all
INT 19h

this is intended for chaining to the next boot device, though its rarely used that way, in many cases it loops back around to the first boot device -- but it might not if you have more than one valid boot device (and, in some cases, it may rely on GDTR being what the BIOS had it set to...)

why use tricks which rely on specific implementation when there is an official standard method which will always work on all computers? when the 286 was first used, it added a alternate operating mode, however, you couldnt switch back without reseting the CPU -- so PC makers added a reset switch tied to the keyboard controller -- by using this, it would hard-reset the CPU, and then the BIOS would look for a special code, if this code is present, it will immediately transfer code back to the program, so that it could continue in RMode -- this is still implemented on newer computers, and iirc this is how win9x deals with programs set to 'force real mode' -- if you dont set the code, this is equivalent to pressing the reset button

unfortunately i dont remember how to use it

POWER OFF (using older APM 1.2)

Code: Select all

mov ax,5301h
xor bx,bx
int 15h
mov ax,530Eh
mov cx,0102h
int 15h
mov ax,5307h
mov bl,0001h
mov cx,0003h
int 15h

i believe this is what win95 uses when it doesnt have chipset drivers, but doesnt always work

Posted: **Fri Jan 12, 2007 2:35 pm**

t would switche to PMode

Wow, really? With the first bit on register CR0 cleared (real mode)? If so, try to make a "triple fault" or something...

If anybody could have a time to test it,...

-.... besides, I don't program in PMode...

inflater

Posted: **Sat Jan 13, 2007 1:47 am**

Hi,

JAAman wrote:why use tricks which rely on specific implementation when there is an official standard method which will always work on all computers? when the 286 was first used, it added a alternate operating mode, however, you couldnt switch back without reseting the CPU -- so PC makers added a reset switch tied to the keyboard controller -- by using this, it would hard-reset the CPU, and then the BIOS would look for a special code, if this code is present, it will immediately transfer code back to the program, so that it could continue in RMode -- this is still implemented on newer computers, and iirc this is how win9x deals with programs set to 'force real mode' -- if you dont set the code, this is equivalent to pressing the reset button

unfortunately i dont remember how to use it

There's a standard CMOS location used by the BIOS to determine the "reboot type". Different values stored in this location cause the BIOS to do different things (cold boot, warm boot, return to some location via. far jump, return to some location via. RETF, return to some location via. IRET, etc). For more information, see "CMOS location 0x0F" in the CMOS list in Ralph Brown's Interrupt List (the original/full version from here, not the "real mode interrupts only" online html version).

BTW it isn't a standard method of resetting the CPU - it's a standard method of telling the BIOS what you want after the CPU is reset....

Exactly how "standard" it is is also debatable - some BIOS's do some things after the CPU is reset but before returning to your code, so that it can be impossible to (for e.g.) use it to reliably get the CPU's model, stepping, etc (left in EDX by the CPU) on older CPUs (that don't support CPUID). I'm not sure how many BIOSs support which reset types either (but I'd assume almost all of them support the most common reboot types).

Cheers,

Brendan

Posted: **Sat Jan 13, 2007 7:54 am**

Try to exit from PMode to real and you will see how that functions will respond...

inflater

Posted: **Sat Jan 13, 2007 12:15 pm**

I use following code for rebooting my PC

Code: Select all

int reboot()
{
 __cli();
 int temp;		// A temporary int for storing keyboard info. The keyboard can be use to
 			//  reboot the PC

 // Get ready for reboot...flush the keyboard controller
 do
 {
  temp = inportb( 0x64 );
  if ( temp & 1 ) inportb( 0x60 );
 }
 
 while ( temp & 2 ); // Reboot the computer...

 outportb(0x64, 0xFE);

 return ERROR;
}

Posted: **Sun Jan 14, 2007 10:24 am**

BTW it isn't a standard method of resetting the CPU - it's a standard method of telling the BIOS what you want after the CPU is reset.... Wink

i didnt mean that particular detail was standard method of reseting, i meant the keyboard reset -- the system reset line is tied to the keyboard controller, and pulsing that line (i dont remember the exact method) will do exactly the same thing as pushing the reset button on the front of the computer (unless you tell it to do something different by placing the appropriate code into the CMOS -- which i only mentioned since the poster made a distinction between rebooting and resetting)

when i said 'standard method' i meant the keyboard controller, not the CMOS entries, sorry if that was a little confusing, but the keyboard controller reset should work on all systems

t would switche to PMode
Wow, really? With the first bit on register CR0 cleared (real mode)? If so, try to make a "triple fault" or something...

If anybody could have a time to test it,... Rolling Eyes Very Happy -.... besides, I don't program in PMode... Very Happy

inflater

it doesnt matter what mode your in (whether in RMode or PMode makes no difference) -- most of the BIOS boot code runs in PMode -- only returning to RMode for loading the bootsector (the CPU 'starts' in UMode, and requires an immediate switch to do anything useful -- generally entering PMode for most of the initialization and setup) but will happen when you jump to the old 8086/8 entry point, is BIOS-specific -- this is not the real entry point for the actual BIOS -- in fact its not even in ROM -- its RAM where a portion of the BIOS has been copied to, and has been marked as read-only by the controller

so basically, in order to cold reset, it will always enter PMode

with my mention of relying on the old GDTR for int19, its actually unlikely, but anything that can use the newer options, can very likely be written in PMode -- and int19 is supposed to be used only by bootcode -- and rarely used there except within the BIOS itself, so there really is no reason it couldnt assume that GDTR has been left alone -- which it may choose to use for USB booting, and will certainly use for CD booting in FDD-emulation mode

OSDev.org

Reseting or Power off the PC