jeffs@ka.excelan.com (Jeff Seideman) (01/06/90)
I'm running an AST 386 w/ DOS 3.3, but I need to boot it under 2 different configurations (with different TSR's). I have written a batch file which creates the correct config.sys and autoexec.bat file (depending on which configuration I want), then runs boot.exe which simply calls DOS interrupt 0x19. This works about 50% of the time, and hangs up somewhere in the booting sequence 50% of the time. Does anyone out there know what magic step I'm missing to make this work more consistently? or A better method? __________________________________________________________________________ | ...these clouds stick to the sky | | | like a floating question why. | | | and they linger there to die. | Jeff Seideman | | They don't know where they're going | | | and my friend neither do I... | | --------------------------------------------------------------------------
pipkins@qmsseq.imagen.com (Jeff Pipkins) (01/09/90)
The int 19h vector is supposed to do a warm boot. Like you, I have experienced frequent hang-ups instead of boots when calling it. I'm not sure why, either. To synthesize a cold boot, just jump to location FFFF:0000. The 8086 initializes its CS to FFFF and its IP to 0. This might work:> echo g =FFFF:0000 | debug
zech@leadsv.UUCP (Bill Zech) (01/10/90)
In article <77@qmsseq.imagen.com>, pipkins@qmsseq.imagen.com (Jeff Pipkins) writes: > The int 19h vector is supposed to do a warm boot. Like you, I have > experienced frequent hang-ups instead of boots when calling it. I'm > not sure why, either. > There are really three types of boot operations on the PC. COLD BOOT = power on /reset This runs system diagnostics, executes the BIOS initialization, including setup of interrupt vectors, then boots DOS. WARM BOOT = CTL_ALT_DEL This is just like a cold boot, except the diagnostics are skipped or abreviated. INT 19 This is a DOS boot ONLY. The BIOS interrupts are *NOT* reset. Note that INT 19 is a DOS interrupt, not a BIOS int. Any TSR or driver which chains onto an interrupt vector must intercept int 19, and reload the interrupt vectors with their original values, before allowing DOS to handle the int 19. If these resident programs don't do this, then when DOS reloads (blowing away all your TSRs, etc.) the vectors will continue to point at those no longer existing programs. Not all TSRs and drivers are friendly enough to do this, and that is why the system will often crash when you execute an INT 19. You might try removing all this stuff from your system and try out the INT 19 with only one of them at a time to find out which is the bad guy (or bad guys). INT 19 is mainly used during startup after some initialization program runs to extened or modify the BIOS, allowing DOS to reboot with a different BIOS configuration. Some TSR's intercept INT 19 and then jump to the BIOS WARM start routines. Hope this helps. - Bill
zech@leadsv.UUCP (Bill Zech) (01/10/90)
In article <9312@leadsv.UUCP>, zech@leadsv.UUCP (Bill Zech) writes: > > INT 19 > This is a DOS boot ONLY. The BIOS interrupts are *NOT* > reset. Note that INT 19 is a DOS interrupt, not a BIOS int. > ^^^ Actually, DOS takes over this interrupt after it boots up. I believe the BIOS does honor int 19, which will either boot up DOS or BASIC, on a PC. Sorry! -Bill
Ralf.Brown@B.GP.CS.CMU.EDU (01/10/90)
In article <9312@leadsv.UUCP>, zech@leadsv.UUCP (Bill Zech) wrote: }INT 19 } This is a DOS boot ONLY. The BIOS interrupts are *NOT* } reset. Note that INT 19 is a DOS interrupt, not a BIOS int. It is *not* a DOS interrupt. INT 19h is a BIOS interrupt, but points right at the code with loads and then executes the boot sector. DOS does not know or care about INT 19h (except insofar as VDISK.SYS uses a stub INT 19 handler to locate the data from previous invocations). }Any TSR or driver which chains onto an interrupt vector must }intercept int 19, and reload the interrupt vectors with their }original values, before allowing DOS to handle the int 19. }Not all TSRs and drivers are friendly enough to do this, and that Essentially none, in fact. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 14. proof by importance: A large body of useful consequences all follow from the proposition in question.
jeffs@ka.excelan.com (Jeff Seideman) (01/11/90)
Thanks to all you nettees out there who responded to my question about booting a PC from software. To those who sent code samples that jump to 0xFFFF0000, that was the ticket! To those who said first write 0x1234 to location 0:472 for a soft boot, that was also the ticket! thanks all the way from my boots. __________________________________________________________________________ | ...these clouds stick to the sky | | | like a floating question why. | | | and they linger there to die. | Jeff Seideman | | They don't know where they're going | | | and my friend neither do I... | | --------------------------------------------------------------------------
gerten@uklirb.UUCP (Rainer Gerten) (01/11/90)
In article <77@qmsseq.imagen.com> pipkins@qmsseq.UUCP (Jeff Pipkins) writes: >The int 19h vector is supposed to do a warm boot. Like you, I have >experienced frequent hang-ups instead of boots when calling it. I'm >not sure why, either. > >To synthesize a cold boot, just jump to location FFFF:0000. The 8086 >initializes its CS to FFFF and its IP to 0. > >This might work:> echo g =FFFF:0000 | debug The solution with debug is ok, but on your harddisk remain two files for the piping. Try this solution (it does a warm boot): ------------------------------ debug < BOOT.DTA > NUL ------------------------------ The contents of the file BOOT.DTA is: ------------------------------ e 40:72 34 12 g=ffff:0 ------------------------------ This set a warm-boot-flag into the bios-area and then starts the boot-process without a memory-test (it's faster). +------------------------------------------------+ | Rainer Gerten | | University of Kaiserslautern | | West-Germany | | Mail: gerten@uklirb.informatik.uni-kl.de | | Phone: 49(631)205-2510 | +------------------------------------------------+
jeffs@ka.excelan.com (Jeff Seideman) (01/12/90)
For all you who requested the magic code for warm/cold booting your PC
from software, here it be:
int (far *reboot)() = (int(far *)())0xFFFF0000;
void main()
{
unsigned far *warm;
warm = 0x472;
*warm = 0x1234;
(*reboot)();
}
Note that if you set *warm to any other value it should do a cold boot.
__________________________________________________________________________
| ...these clouds stick to the sky | |
| like a floating question why. | |
| and they linger there to die. | Jeff Seideman |
| They don't know where they're going | |
| and my friend neither do I... | |
--------------------------------------------------------------------------zech@leadsv.UUCP (Bill Zech) (01/13/90)
In article <25ab3ab5@ralf>, Ralf.Brown@B.GP.CS.CMU.EDU writes: > In article <9312@leadsv.UUCP>, zech@leadsv.UUCP (Bill Zech) wrote: > }INT 19 > } This is a DOS boot ONLY. The BIOS interrupts are *NOT* > } reset. Note that INT 19 is a DOS interrupt, not a BIOS int. > > It is *not* a DOS interrupt. INT 19h is a BIOS interrupt, > but points right at > the code with loads and then executes the boot sector. > DOS does not know or > care about INT 19h (except insofar as VDISK.SYS uses a stub INT 19 handler to > locate the data from previous invocations). > Yes, my memory failed me partly, but DOS DOES care about int 19H. DOS intercepts it and has lots of code which it performs to reset various interrupts it was using, then reprograms the int 19H vector, and fires int 19H to reboot. Dump out location 0:64 and you will see it points to code at 70:xxxx inside DOS. BTW, the BIOS cold and warm start code fires int 19H internally to boot the system. All in all, jumping to the machine's restart location is best. P.S. I've never seen your interrupt list. Does it have anything new in it, not covered by the various books out there now? Most of the secrets of yesteryear are now pretty common. - Bill