Conference noted::ibmpc-95

there was a long discussion in here, or in a previous version of this file.
some shareware was mentioned.  also a short debug script.
perhaps other methods also.

    I have been using this for quite a while:
    
    	smartdrv /c
    	echo g=ffff:0000 | debug >nul:
    
    However, I do not know why it works.  Last night, for the first time, I
    asked Debug to unassemble the instruction at ffff:0000, and it appears
    to be (coincidentally, without design) a jump to an arbitrary location
    in memory.  The destination doesn't contain a valid instruction.  So
    I'm a bit puzzled about what is actually going on.
    
    One of the books I have cautions about improper ways to reset, stating
    that the proper way is to command the keyboard controller to assert the
    reset signal to the processor.  If there's an instruction sequence in
    ROM somewhere that does that, then jumping to it with Debug is fine. 
    Other methods of resets run risks (perhaps slight) of leaving some
    aspect of processor state uninitialized.
    
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

    -u ffff:0000
    FFFF:0000 EA5BE000F0    JMP     F000:E05B
    
    -u f000:e05b
    F000:E05B E954C2        JMP     A2B2
    
    Nothing illegal here.
    
    

    Re .3:
    
    You don't expect ffff:0000 to contain the same thing on different
    machines, do you?  Did you check what's at f000:a2b2 on your machine?
    
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

    
>    You don't expect ffff:0000 to contain the same thing on different
>    machines, do you?

	Maybe not exactly, but pretty much the same. FFFF:0000 is the entry
	point into the BIOS.

Larry

    re: <<< Note 2953.0 by NPSS::PARE >>>
         -< Command to re-boot PC? >-
    
    Point your browser to:
    
    ftp://zvotle.zvo.dec.com/rebootpc/reboot.com
    
    regards,
    
    /Thien
    
    P.S: I didn't write it...I inherited it...
    

The jump to ffff:0000 is supposed to mimic what a x86 processor does when
it INITs.  That's the address it first executes on power-up.  It's
hard-wired into all x86 processors.

There are a couple other debug scripts in one of the earlier versions of
this Notesfile, one for a "warmboot" and the other "coldboot".  One of them
sets a flag (somewhere in the 40:xxxx segment?) before the jump to
ffff:0000.  The BIOS typically checks that location to see whether to run
the POST (power-on self test) and scan memory, or just get on with it and
boot.

If you are running a system with a bus master I/O device such as a DEFPA
or DEFEA FDDI controller then you are likely to hang your system with
a warm reboot.  The adapter thinks that it is running the network 
and that the CPU is honoring the agreed command descriptors and buffers;
the CPU thinks that it is booting or running diags.

YMMV,
Chuck

See note 200.4 in this notesfile for examples in C and ASM.

NOTED::IBMPC-92, note 2164, shows how to create a simple .COM file. 
It also gives an example that mimics a Ctrl-Alt-Del, which may be
better because it gives some other programs a chance to shut
themselves down first.

    In the 4DOS shell there is the REBOOT command...
    
    It even has /C (for Cold) and /V (for Verfiy) switches.
    
    Rien.
    

    You are right the JMP adresses are different.
    Yes, I traced the f000:a2b2 on my machine and it was just fine.
    
    S.