tim@j.cc.purdue.edu.UUCP (02/16/87)
The following is Macro code to make an IBM PC and true compatibles perform a warm reboot. It has been tested on IBM PC, IBM AT, Zenith 148, 158, and 241. If someone desires an uuecoded file of the .COM please send me mail. Of course a few minutes with 'debug' will allow anyone to build the .COM file themselves. The program just makes a far jump to F000:FFF0. warm segment at 0f000h assume cs:warm org 0fff0h boot proc far ret boot endp warm ends ; code segment assume cs:code, ds:code org 100h jmp boot code ends end -- Timothy Lange PC Learning Resource Center Purdue University Computing Center West Lafayette, IN 47907 317-494-1787 tim@j.cc.purdue.edu
perry@omepd.UUCP (02/19/87)
In article <3258@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes: >The following is Macro code to make an IBM PC and true compatibles >perform a warm reboot. > [...showing a simple assembler program to jump to F000:FFF0...] Let us talk about `Cold' and `Warm' boots. In my book, a `cold' boot is one that starts from scratch, ignoring any previous state. That's what happens if you turn on your PC. Part of a Cold Boot is a more or less thorough check of the hardware. The PC BIOS doesn't do exceedingly much, but it puts the processor through some simple checking paces, does a memory check and collects information about peripherals (depending on what type of PC you have). A `warm' boot, on the other hand, is performed on a running machine. Its purpose is to restart the system, reloading the operating system. As we do this from a running machine, there is no need to examine the hardware - people are unlikely to rip out memory chips or extension boards from a running PC. If you think that the difference is insignificant, try a PC where the memory test takes two minutes. This will change your perspective. By this diction, what you propose (a jump to address F000:FFF0) is a COLD BOOT. F000:FFF0 is the place where the processor begins to execute when it is reset (i.e., when the power is turned on). The first thing it does up there is to run test loops and initiate the memory check. Please wait... There is a simple way to perform a real `warm' boot on an IBM PC. Just do an `INT 19H' instruction. This will reload MSDOS and restart the configuration process (reading CONFIG.SYS, executing AUTOEXEC.BAT etc.) without first doing the hardware checks. Believe me, it's faster. The only advantage of a Cold Boot is that you're jumping into ROM, so no-one can intercept you. Programs can intercept interrupt 19H and delay or prevent the boot (which may be a good thing for sensitive programs that have to do cleanup operations). A `JMP F000:FFF0' kills the machine immediately. ------------------------------------------------------------------------ << Perry The Cynic >> ...!tektronix!ogcvax!omepd!inteloa!perry ...!verdix!omepd!inteloa!perry (Peter Kiehtreiber) -or try- perry@inteloa.intel.com
ljz@well.UUCP (02/19/87)
In article <424@omepd> perry@inteloa.intel.com (Perry The Cynic) writes: >There is a simple way to perform a real `warm' boot on an IBM PC. Just do >an `INT 19H' instruction. This will reload MSDOS and restart the configuration >process (reading CONFIG.SYS, executing AUTOEXEC.BAT etc.) without first doing >the hardware checks. Believe me, it's faster. But INT 19h can't be counted on to work in all compatibles. Try it on some of them and you'll see mixed and discouraging results. If your machine happens to be a "well-behaved" compatible, then you're in luck. Otherise, a jump to f000:fff0 is the way to go, as it seems to work on clones as well as IBM products.
bright@dataio.UUCP (02/20/87)
In article <2611@well.UUCP> ljz@well.UUCP (Lloyd Zusman) writes: >Otherise, a jump to f000:fff0 is the way to go, as it seems to work on >clones as well as IBM products. That better work on all clones, since f000:fff0 is defined by the CPU, not something else. If you've got an Intel 8088,8086,80286 etc. then f000:fff0 is the address. Also, a warm boot can be done by poking 0x1234 into location 0x472 prior to jumping to f000:fff0, this will prevent the memory test but will do everything else. This is what happens when Ctrl-Alt-Del is pressed.
tom@vrdxhq.UUCP (02/21/87)
> ... machine happens to be a "well-behaved" compatible, then you're in luck. > Otherise, a jump to f000:fff0 is the way to go, as it seems to work on Just in passing, the reason JMP f000:fff0 works on clones as well as IBM products is that it's the bootstrap location of intel 16-bit CPUs (8086, 80186, 80286, 80386). Clones using these processors (and they're not clones if they don't), will have no problem ... > clones as well as IBM products.
zarifes@bnrmtv.UUCP (02/21/87)
> In article <3258@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes: > >The following is Macro code to make an IBM PC and true compatibles > >perform a warm reboot. > > [...showing a simple assembler program to jump to F000:FFF0...] > > There is a simple way to perform a real `warm' boot on an IBM PC. Just do > an `INT 19H' instruction. This will reload MSDOS and restart the configuration > process (reading CONFIG.SYS, executing AUTOEXEC.BAT etc.) without first doing > the hardware checks. Believe me, it's faster. There is a problem with this. EVERY time I do an int 19h on my True Blue IBM AT, the A: drive is spun and the system hangs completely. I recommend that you do not ever use int 19h. -- {hplabs,amdahl,3comvax}!bnrmtv!zarifes --Ken Zarifes
zarifes@bnrmtv.UUCP (02/21/87)
> > In article <3258@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes: > > >The following is Macro code to make an IBM PC and true compatibles > > >perform a warm reboot. > > > [...showing a simple assembler program to jump to F000:FFF0...] > > There is a problem with this. EVERY time I do an int 19h on my True Blue > IBM AT, the A: drive is spun and the system hangs completely. > > I recommend that you do not ever use int 19h. I almost forgot, the best way to do a warm reboot is to move the value 1234H into the location 0040:0072 and THEN jump to F000:FFF0 You'll find that this works on clones, AT's, PC's and about everything else. -- {hplabs,amdahl,3comvax}!bnrmtv!zarifes --Ken Zarifes
kneller@ucsfcgl.UUCP (02/21/87)
In article <415@omepd> perry@inteloa.intel.com (Perry The Cynic) writes: >In article <3258@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes: >>The following is Macro code to make an IBM PC and true compatibles >>perform a warm reboot. >> [...showing a simple assembler program to jump to F000:FFF0...] > >By this diction, what you propose (a jump to address F000:FFF0) is a >COLD BOOT. F000:FFF0 is the place where the processor begins to execute >when it is reset (i.e., when the power is turned on). The first thing it >does up there is to run test loops and initiate the memory check. Isn't it true that you can control whether the memory check is done or not by placing a particular value in a special memory location? This has been covered previously, but I don't recall the details, so if someone would care to comment ... Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
ballou@brahms.Berkeley.EDU.UUCP (02/21/87)
In article <10075@cgl.ucsf.edu.ucsfcgl.UUCP> kneller@socrates.ucsf.edu.UUCP writes: >Isn't it true that you can control whether the memory check is done or >not by placing a particular value in a special memory location? This >has been covered previously, but I don't recall the details, so if someone >would care to comment ... The (true Blue) BIOS checks for the value hex 1234 (cute, no?) in memory location 0040:0072. If the magic value is found, then the BIOS takes a warm boot. -------- Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720
dan@srs.UUCP (02/21/87)
> >There is a simple way to perform a real `warm' boot on an IBM PC. Just do > >an `INT 19H' instruction. This will reload MSDOS... > But INT 19h can't be counted on to work in all compatibles. I used INT 19H successfully in an early RAMdisk device driver. Note that the bootstrap routine doesn't set up its own stack. Therefore, you must be careful when using int 19h that the stack does not overlap the boot location (512 bytes at 0:7c00). If it does- and this will depend on what devices you have loaded, etc.- INT 19h will simply crash.
jmh@hyper.UUCP (02/22/87)
In article <1442@bnrmtv.UUCP>, zarifes@bnrmtv.UUCP (Kenneth Zarifes) writes: > > I almost forgot, the best way to do a warm reboot is to move the value 1234H > into the location 0040:0072 and THEN jump to F000:FFF0 > > You'll find that this works on clones, AT's, PC's and about everything else. I believe that this machenism is used internally in DOS. Specifically, on the AT, there are DOS routines for manipulating extended memory. These routines switch into protected mode to get to the memory they want. However, the only way out of protected mode is a hardware reset. In order to avoid the memory checks and delays on the reset, the magic number is stored at 0040:0072 to control the restart process. Joel M. Halpern -- Network Systems Corporation ihnp4!umn-cs!hyper!jmh
brianc@cognos.UUCP (Brian Campbell) (02/23/87)
in article <424@omepd>, perry@omepd.UUCP says: > > In article <3258@j.cc.purdue.edu> tim@j.cc.purdue.edu (Timothy Lange) writes: >>The following is Macro code to make an IBM PC and true compatibles >>perform a warm reboot. >> [...showing a simple assembler program to jump to F000:FFF0...] > > By this diction, what you propose (a jump to address F000:FFF0) is a > COLD BOOT. F000:FFF0 is the place where the processor begins to execute > when it is reset (i.e., when the power is turned on). The first thing it > does up there is to run test loops and initiate the memory check. Please > wait... > > There is a simple way to perform a real `warm' boot on an IBM PC. Just do > an `INT 19H' instruction. This will reload MSDOS and restart the configuration > process (reading CONFIG.SYS, executing AUTOEXEC.BAT etc.) without first doing > the hardware checks. Believe me, it's faster. > > The only advantage of a Cold Boot is that you're jumping into ROM, so no-one > can intercept you. Programs can intercept interrupt 19H and delay or prevent > the boot (which may be a good thing for sensitive programs that have to do > cleanup operations). A `JMP F000:FFF0' kills the machine immediately. Small correction: a JMP F000:FFF0 is only a COLD boot if you have done no WARM boots since power-on. There is a useful little flag word at some offset in the BIOS data area. If it is set to 1234h the CPU, memory and other tests will not be performed.
dmt@mtunb.UUCP (02/24/87)
In article <10075@cgl.ucsf.edu.ucsfcgl.UUCP> kneller@socrates.ucsf.edu.UUCP (PUT YOUR NAME HERE) writes: >>>The following is Macro code to make an IBM PC and true compatibles >>>perform a warm reboot. >>> [...showing a simple assembler program to jump to F000:FFF0...] >> >>By this diction, what you propose (a jump to address F000:FFF0) is a >>COLD BOOT. F000:FFF0 is the place where the processor begins to execute >>when it is reset (i.e., when the power is turned on). The first thing it >>does up there is to run test loops and initiate the memory check. > >Isn't it true that you can control whether the memory check is done or >not by placing a particular value in a special memory location? Byte 40:72 H (in the BIOS data area) is the system reset flag. (I first learned of this from Peter Norton's excellent book, "Programmer's Guide to the IBM PC.") It is set to 1234H on a warm boot, and could be anything on a cold boot. The BIOS startup code looks at this flag, and skips things (notably the memory test), if the WORD is hex 1234. I have looked at a few BIOS[es] (what is the plural of BIOS? :-), and those I have checked all test the reset flag. (That's not a guarantee that every clone BIOS will, but it's a pretty strong indicator.) +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T - Lincroft, NJ | | Logical - ...ihnp4!mtuxo!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
zarifes@bnrmtv.UUCP (02/25/87)
> > There is a problem with this. EVERY time I do an int 19h on my True Blue > > IBM AT, the A: drive is spun and the system hangs completely. > > > > I recommend that you do not ever use int 19h. Oops. What I meant to say was "if you want your software to run on all systems" INT 19H will not work on my default system i.e. with all my devices installed. It will work if I remove all of my device drivers except nansi.sys. So I still recommend using the method I previously described: > I almost forgot, the best way to do a warm reboot is to move the value 1234H > into the location 0040:0072 and THEN jump to F000:FFF0 > > You'll find that this works on clones, AT's, PC's and about everything else. Cheers, -- {hplabs,amdahl,3comvax}!bnrmtv!zarifes --Ken Zarifes
connery@bnrmtv.UUCP (02/27/87)
> In article <10075@cgl.ucsf.edu.ucsfcgl.UUCP> kneller@socrates.ucsf.edu.UUCP (PUT YOUR NAME HERE) writes: > >>>The following is Macro code to make an IBM PC and true compatibles > >>>perform a warm reboot. > >>> [...showing a simple assembler program to jump to F000:FFF0...] > >> > Etc. Okay, so I've got a REBOOT.COM file that performs a warm boot on my IBM PC-AT just fine. And I've got a debugger board of one type or another (mine happens to be a periscope) with a breakout switch. Now when I'm not using the debugger, the breakout switch generates an NMI which causes a PARITY CHECK 2 message to appear on the screen. That's because parity checks also use the NMI interrupt. Now lets say I'd like to write a little resident program that traps NMI. Ignoring for the moment that it should also determine whether the NMI is a real parity error or not, it will perform a reboot when I press my breakout switch. Its easy enough to put such a program together and it works just fine, except that the reset isn't total enough. The machine starts to reboot, and then bombs out with a PARITY CHECK 2 shortly after the RAM test completes. It would appear that the minute the processor enables interrupts (or perhaps checks some status word in memory) it notices that there is still a parity error pending. Now this program works just fine on an IBM PC, PC/XT and an AT clone, but not on my PC-AT. I've tried a couple of obvious things, like issuing an EOI, resetting various locations in the BIOS data area, tracing through the reboot code in the Tech. Ref. and got no where. The latter course would presumably solve the problem eventually, but I'm not sure its worth the effort. So anyway, does someone have a clue what is wrong here? Glenn -- Glenn Connery, Bell Northern Research, Mountain View, CA {hplabs,amdahl,3comvax}!bnrmtv!connery