Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mephisto!gatech!dcatla!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Caches and Extended Memory
Message-ID: <1990Mar12.005855.1194@holos0.uucp>
Date: 12 Mar 90 00:58:55 GMT
References: <9003091838.AA21834@decwrl.dec.com> <25F9EA26.21884@maccs.dcss.mcmaster.ca>
Reply-To: lbr@holos0.UUCP (Len Reed)
Organization: Holos Software, Inc., Atlanta, GA
Lines: 33

In article <25F9EA26.21884@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes:
>In article <9003091838.AA21834@decwrl.dec.com> stoppani@slough.enet.dec.com (Pete Stoppani) writes:

>   and then, since the 286 has no way to quitely go back into real
>mode, the program has to:

>- get the keyboard controller to reset the CPU
>- restore the status from earlier...

This is not true.  The 286 has an undocumented instruction called LOADALL
that allows use of the protected mode addressing even under real mode.
You don't have to put the chip into protected mode, you merely
change the high, hidden bits of the DS, SS, etc.  from the power-up
zero values.  In fact, it loads, from real address 0x800, every register--
real mode and protected--on the system.

It's rather strange, but it does work.  (Microsoft's ASM doesn't know
about LOADALL, but its CODEVIEW debugger will disassemble it!)

I don't know which products do reset the CPU (as Intel's standard documentation
would leave you to believe is necessary) and which use LOADALL, and I
*sure* don't know why Intel (and for that matter Microsoft, when it comes
to MS-DOS interrupts) puts things in their product that they keep a
secret.

The protected mode bit on the 386 is not sticky.  That is, a task with
the highest level privilege can turn the bit off, causing the processor
to return to real mode.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr