Category : Assembly Language Source Code
Archive   : LOADALL.ZIP
Filename : LOADALL.DOC

Output of file : LOADALL.DOC contained in archive : LOADALL.ZIP
To: All Message #: 7666
From: Andy Vaught Submitted: 13 Jul 90 9:41:00
Subject: LOADALL, 1/4 Status: Public
Received: No Group: 80XXX (30)

Article 90 of
Path: bilver!rtmvax!peora!ge-dab!steinmetz!uunet!ccicpg!turnkey!conexch!root
From: [email protected] (Larry Dighera)
Subject: Re: Returning the 80286 to Real Mode
Summary: Have you heard about the LOADALL instruction?
Message-ID: <[email protected]>
Date: 31 Oct 88 14:05:04 GMT
References: <[email protected]>
Reply-To: [email protected] (Larry Dighera)
Organization: The Consultants' Exchange, Orange County, CA. (714) 842-6348

In article <[email protected]> [email protected] (Tom Sanders)
> Rumour has it that it is possible to switch the 80286 back to real mode
> once having gone protected. Can anyone advise me how this is done?

Here is a copy of an article that recently appeared in a periodical magizine.
The informatin it contains and the opinions expressed in it are not mine.
I'm sure you will find it useful and informitive.

------------------------ LOADALL DOCUMENTATION -------------------------

Secret 286 LOADALL instruction allows access to extended memory in real mode.

In last month's article on the P9, we described the method used to access
extended memory (memory beyond the lower 1 megabyte) from real-mode
programs running on a 286. This method requires switching to protected
mode to perform access, and then resetting the processor to return to
real mode. We have since learned that there is another way. An undocumented
286 instruction, LOADALL, allows all of the processor's registers (including
protected mode registers and hidden internal registers) to be loaded, even
when operating in real mode. By changing the value of the descriptor
cache base register, a program can select a segment beyond the lower 1Mbyte.
LOADALL also has other uses, as described later in this article.

Physical Memory Address CPU register
800-805 none
806-807 MSW (Machine Status Word)
808-815 None
816-817 TR (Task Register)
818-819 Flag Word
81A-81B IP (Instruction Pointer)
81C-81D LDT (Local Descriptor Table)
81E-81F DS (Data Segment Selector)
820-821 SS (Stack Segment Selector)
822-823 CS (Code Segment Selector)
824-825 ES (Extra Segment Selector)
826-827 DI (Destination Index)
818-829 SI (Source Index)
82A-82B BP (Base Pointer)
82C-82D SP (Stack Pointer)
82E-82F BX (Data Register B)
830-831 DX (Data Register D)
832-833 CX (Data Register C)
834-835 AX (Accumulator)
836-83B ES Descriptor Cache
83C-841 CS Descriptor Cache
842-847 SS Descriptor Cache
848-84D DS Descriptor Cache
84E-853 GDTR (Global Descriptor Table Register)
854-859 LDT Descriptor Cache
85A-85F IDTR (Interrupt Descriptor Table Register)
860-865 TSS (Task State Segment) Descriptor Cache

Table 1. LOADALL data area format

Originally included by Intel for chip testing, Microsoft is now using this
instruction in their RAM Drive program and in OS/2's compatibility box.
While this instruction is probably appropriate only for use in operating
systems and system-level utilities, it is important because it provides a
set of capabilities that are not otherwise available in a 286-based system.

We have received a copy of a document that describes LOADALL. No company
name is shown, but is almost surely written by Intel. The 15-page
document describes in detail how to use the instruction, so calling it
"undocumented" is not quite correct -- it is documented, but not in the
data sheet. By restricting access to this documentation, Intel gives unfair
advantage to Microsoft and other large customers.

Descriptor Cache Format
Bytes 0-2 24-bit segment base address
Byte 3 Access rights byte. Format is the same as the access
rights byte in a descriptor, except that the "present"
bit becomes a "valid" bit. If a "valid" bit is not
set, any memory reference using the descriptor will
cause exception 13 with error code of 0.
Bytes 4-5 16-bit segment size

GDTR and IDTR Format
Bytes 0-2 24-bit base address
Byte 3 0
Bytes 4-5 16-bit segment limit
Table 2. Descriptor Cache Formats

Intel's position is that this instruction is not useful to most users,
and can easily lead to machine crashes if not used properly. Intel says
that they will provide documentation for the instruction on a "need-to-know"
basis, presumably only after a non-disclosure agreement has been signed.
Most developers, of course, would not know to ask. The information we are
presenting here should be enough for you to evaluate the usefulness of the
instruction; if you intend to use it in a product, you should contact
Intel for the full documentation.

The opcode for LOADALL is 0F05 hex. No operands follow the instruction;
LOADALL gets its data from a 102-byte block of memory starting at the
fixed address 800 hex, as shown in Table 1. Table 2 shows the format of
the descriptor cache entries. These are hidden registers that cannot
otherwise be modified by the programmer; they are set automatically when
a descriptor is read from the descriptor table.


The following sequence is required to access high memory from real mode
using LOADALL:
1. Disable interrupts
2. Save the 102 (decimal) bytes starting at 800 hex. (MS-DOS uses this
area for system code. OS/2 presumably leaves it free for LOADALL,
but depends on application programs not to change it.)
3. Set up the 102-byte register image at 800. The base address in the
data segment descriptor cache is set to select the desired high-memory
4. Execute the LOADALL instruction. The data segment now points to the
new, high-memory segment.
5. Move data to or from high memory.
6. Restore the base address in the data segment descriptor cache in the
image at 800, and execute another LOADALL.
7. Enable interrupts.
<<< The next step is not in the article, but conspicuously absent. >>>
8. Restore the original 102 bytes to 800.

Thus while it is appealing not to have to go to protected mode and back to
access high memory from real mode, this isn't much better. LOADALL requires
195 clock cycles on a machine with no wait states, or 19.5 us at 10Mhz.

LOADALL can also be used to allow programs to be executed in high memory,
even though the processor is in real mode. A special paragraph ID (such as
FFFF) is used to indicate when a program is running in extended memory.
Interrupt service routines must check the segment register to see if any
contain the special ID, and if so, they must reload the registers using
LOADALL to restore the segment base addresses before returning from the


LOADALL has other uses as well. It can be used to switch back to a
protected mode task from real mode, serving as a fast intermode context
switch. OS/2 presumably uses it to return to protected mode from a
real-mode task running in the compatibility box.

LOADALL can also be used to emulate real mode from protected mode. By
setting the privilege level of all local and global descriptor table
entries lower than that of the current program, a protection violation
occurs whenever the program attempts to load a segment register. (Actually,
loading the segment register with a value of 0000 to 0003 does not cause
an exception, and this case must be handled specially.) The exception
handler then uses LOADALL to set the base address for the segment.

There are many other complexities to this emulation, as described in the
LOADALL document. The emulation is imperfect, and Microsoft apparently
decided to use the "reset to real mode" technique (as described in our
article last month on the P9), rather than trying to emulate real mode
from within protected mode.


LOADALL performs no checking on the values loaded into the registers, so
no exception will occur even if an illegal value is loaded. Thus, the
processor can potential be put into a strange state. If an illegal
descriptor value is set, no exception occurs from the execution of LOADALL.
An exception will occur, however, when an access using that descriptor
is attempted.

LOADALL can be executed in protected mode, but only at the most privileged
level (level 0). Thus it does not violate the protection. Unfortunately,
LOADALL cannot be used to switch back to real mode from protected mode.

Early versions of 286 (A1 and B1 steppings) have bugs which affect the use
of LOADALL. Thus, the techniques described in this article may not work
properly on older systems.

LOADALL is not implemented on the 80386, so Microsoft has included code in
OS/2 and in the current version of RAM Drive that tests for the processor
type. If it's a 286, LOADALL is used, and if it's a 386, the native 386
mechanisms are used. If you use LOADALL, you should also perform this
check, or your software will not run on 386-based machines.

Using LOADALL is certainly fraught with peril, and requires careful
program design and knowledge of all the implications. We have spoken with
a number of software vendors that were aware of the instruction, and all
had decided not to use it due to the risks and complexity involved. We
don't recommend its use to most people, but we do feel that everyone should
have access to the information so they can make their own choice about
whether or not to use the instruction.

USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712
TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71)
UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp
UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root

  3 Responses to “Category : Assembly Language Source Code
Archive   : LOADALL.ZIP
Filename : LOADALL.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: