How does the LOADALL instruction on the 80286 work?

Question

This undocumented instruction existed in the 80286 and, I believe, the 80386. I think it was added while debugging the chip, so the engineers could quickly put the processor into any state and test it from there without having to write tons of code to reach that state. Microsoft used it to accelerate HIMEM.SYS. IBM used it to allow DOS boxes inside OS/2 to access some memory beyond the 1MB barrier, but how did it work?

Answer 1

LOADALL is an undocumented instruction available on the 80286, 80386 and some 486 clones. It provides a means to load all the CPU's registers in one operation, including normally-inaccessible registers (descriptor caches).

Its significance is that it allows extended memory to be accessed on a 286 without switching to protected mode.

On a 8086, memory is accessed using a segment:offset system, where the segment is multiplied by 16 and the offset added to it; both values are 16 bits in length, so using this scheme allows access to the full 1MB address range of the 8086 on the one hand, while still allowing easy access to a "decent" amount of memory within a segment (64KB). On the 286, a level of indirection was added to segments, in order to allow access to the full 16MB address range (24 bits) and to provide memory protection features. This level of indirection is provided by segment descriptors: a segment value loaded in a register such as CS or DS is no longer a direct pointer to the corresponding 64KB block of memory (i.e., the value multiplied by 16), but is a handle pointing into a descriptor table, whose entries specify the segment's 24-bit physical base address, the access permissions, and the segment limit (so segments could be shorter than 64KB). Backwards-compatibility is provided in real-mode by specially handling register loads into the segment registers; these are backed by hidden descriptor caches which contain the segment descriptor values for the current segment descriptor, and in real mode these are simply the segment handle multiplied by 16, and a segment limit of 64KB.

On a 286 though, segment descriptors can officially only be changed in protected mode. Thanks to the 286's (very) poor support for switching back to real mode from protected mode, this effectively means that real mode is stuck with its 1MB limit (plus a little under 64KB using the A20 gate, but that's another topic). Or it would be, were it not for the LOADALL instruction!

With LOADALL, a 286 running in real mode can change the segment descriptors caches independently of the values actually loaded in the segment registers, and thus real-mode processes can access all 16MB of memory. This technique was apparently first used in RAMDRIVE.SYS. LOADALL on the 286 loads all the CPU's registers, including each segment register's descriptor cache (which allows quick changes to the descriptor without setting up a proper descriptor table), from memory starting at 0x000800. DOS 3.3 and 4.01 leave that memory range clear of data so that it can be used for RAMDRIVE.SYS; on other versions (including DOS 5 and later), it's necessary to move data out of the way temporarily.

Accessing memory beyond 1MB using LOADALL is relatively simple (at least, relative to switching to protected mode and somehow switching back). To copy a block of memory from extended memory, you'd copy the current CPU state to memory (after saving the initial contents of 0x000800 if necessary), and update the DS descriptor cache so its base address points at the address in extended memory you want to read from; then LOADALL, copy the memory (from DS:SI to ES:DI commonly), then LOADALL again to restore the DS descriptor cache to its usual real-mode setting. You'd typically do this with interrupts disabled, but since you're limited to copying 64KB at a time it's not much of an issue. Copying to extended memory is similar, using the ES descriptor cache typically.

A different version of LOADALL is available on the 386, with a different opcode, but it's less useful there since switching to and from protected mode is much faster than on a 286 (and for non-protected-mode DOS software, "unreal" mode was much more useful for accessing extended memory). Most 386 BIOSs trap the 286 version of LOADALL and emulate it (either using the 386 version of LOADALL, or equivalent protected-mode operations), so that 286 software can still work on the 386. (Notably, RAMDRIVE.SYS continued using the 286 version of LOADALL for a long time, even on 386s.)

The Intel 80486 dropped support for LOADALL entirely (although it can still be emulated using protected-mode operations). Some IBM and AMD clones implemented their own versions of LOADALL, with extensions to the 386 version to support the added registers on these CPUs.

For lots more on all this, I recommend Geoff Chappell's DOS Internals and Frank Van Gilluwe's The Undocumented PC, in addition to the document preserved in mcleod_ideafix's answers.

Answer 2

There is some information about LOADALL on Wikipedia, and several OS-related sites, but the first time I (and I guess many others) knew about LOADALL is from this documented from Terrance E. Hodgins.

I haven't found any copy to this document online (well, a simple Google search with the words Terrance E. Hodgings or Hyper-Space Navigator's guide doesn't get any relevant results), so I've decided to keep a copy here, for future references, and because the document explains a lot of more than the Wikipedia article.

Besides, I haven't found the referenced book "The Hyper-Spaec Navigator's Guide", nor the publisher "Semi-Inteliigent Systems". It could be worth a reading, if such book actually existed.

So, this is the document where I learned about the "magic" and "secret" LOADALL instruction:

PS: Stack Exchange answers seem to be limited to 30000 characters, so I have had to split this document into two answers.

                           THE LOW-DOWN ON LOADALL:
                            EXCERPTS FROM THE BOOK


                       THE HYPER-SPACE NAVIGATOR'S GUIDE
                                      by
                              Terrance E. Hodgins

                  copyright (C) 1990 by Terrance E. Hodgins,
                             All rights reserved.


                           Semi-Intelligent Systems
                                 PO BOX 4492
                            ALBUQUERQUE, NM 87196

                            Compuserve:  76416,553
                     Internet:  [email protected]
                 Internet: terry%[email protected]


        And now the boring legal stuff:


This document uses the following trademarks:

AST is a registered trademark of AST Research, Inc.

IBM, PC-DOS, PC/XT, and PC/AT are registered trademarks of International Busi-
ness Machines Corporation.

Intel is a registered trademark of Intel Corporation.

Lotus is a registered trademark of Lotus Development Corporation.

Microsoft, MS-DOS, Windows '286, and OS/2 are registered trademarks of  Micro-
soft Corporation.

Semi-Intelligent  Systems,  The Hyper-Space Library,  Get-High,  HI-DOS,  High
Code,  Xcode,  and  Mode Code are registered  trademarks  of  Semi-Intelligent
Systems.

Unix is a registered trademark of AT&T, Inc.




                            Disclaimer of Warranty

        TERRANCE E. HODGINS, AND SEMI-INTELLIGENT SYSTEMS, EXCLUDE ANY AND ALL
IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY AND FITNESS FOR  A
PARTICULAR PURPOSE.

        NEITHER  TERRANCE E. HODGINS, NOR SEMI-INTELLIGENT SYSTEMS,  MAKE  ANY
WARRANTY  OF REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO  THESE
PROGRAMS,  THEIR QUALITY, PERFORMANCE, MERCHANTABILITY, OR FITNESS FOR A  PAR-
TICULAR PURPOSE.

        NEITHER TERRANCE E. HODGINS, NOR SEMI-INTELLIGENT SYSTEMS, SHALL  HAVE
ANY LIABILITY FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
OR RESULTING FROM THE USE OR MODIFICATION OF THESE PROGRAMS.

        THE USE OF THE 80286 LOADALL INSTRUCTION IS INHERENTLY DANGEROUS,  AND
CAN RESULT IN PROGRAM CRASHES, OR RUN-AWAY PROGRAMS, WHICH CAN ALTER,  DAMAGE,
OR  DESTROY COMPUTER DATA, AND WHICH CAN DAMAGE OR DESTROY COMPUTER  HARDWARE.
USE ONLY AT YOUR OWN RISK.





                              Introduction



        Yes,  there really is an unpublicized, almost secret,  instruction  in
the 80286, which has the ability to do several supposedly impossible things.

        It is called Loadall.

        What  Loadall does is completely load all the registers of  the  80286
from  a table starting at 80:0 in low memory.  I do mean ALL registers:  every
register  you ever heard of, and a few you haven't, and also  the  "invisible"
internal registers which are NOT OTHERWISE programmable.  Executing a  Loadall
nearly completely re-defines the CPU's state.

        This  means  that  it is a great warp,  or  hyper-space,  instruction:
executing  a Loadall will jump you to someplace new, and leave you  with  your
choice  of  register contents, status and mode settings,  and  memory  segment
mappings,  allowing  you  to have your segments anywhere  in  the  16-megabyte
address  space  of the 80286.  Those of you who are familiar with Unix  and  C
programming  will be immediately reminded of the "longjump" routine.   Loadall
is the ultimate long-jump.

        This  is possible in REAL mode.  You do NOT have to go into  protected
mode  to get at memory above 1 Megabyte on the AT.  Which also means that  you
don't have to then go through all kinds of odd-ball gyrations to get back  out
of  protected mode.  And better yet, this instruction will work in  both  REAL
and PROTECTED mode.

        Intel  included the Loadall instruction in the 80286 for chip  testing
(they  can  throw the CPU into any state, and see if it then does what  it  is
supposed  to  do),  but there are much better uses for it  than  that  (in  my
not-so-humble opinion).

        The power of being able to re-program ANY and ALL of the registers  of
the  CPU with one single instruction opens up a whole new world of  possibili-
ties.

        Including, but not limited to:

        getting  at  all  the memory in your machine at will, even  if  it  is
addressed above 1 megabyte, from real mode.

        executing real-mode programs in ram above one megabyte.

        installing a second operating-system-like program, or command  proces-

sor,  or shell, in memory above 1 megabyte, and alternating between  that  and
DOS.

        installing most of the guts of custom TSR's, shells, and  device-driv-
ers in ram above 1 megabyte (freeing up precious base memory), leaving in  low
memory only the stubs to call the code upstairs.

        writing  very  large programs, which are "split", and  have  half  the
program  residing  in  the low-down 640K, and the other half  up  in  extended
memory, and running in either real or protected mode.

        installing  large  protected-mode programs in extended  memory,  where
they  will not conflict with, or crowd out DOS, and ping-ponging between  them
and DOS.

        switching to protected mode.

        emulating  real mode from protected mode (tough, and full of  gotchas,
but still worth mentioning).

        this is really off-the-wall, but possible: building automata that  use
Loadall  to  warp from state to state, sort of like a computer game  of  Life,
played in the twilight zone.

        ? use your imagination. The sky's the limit.

        While the Loadall instruction only exists on the 80286 (to the best of
anyone's  knowledge at present -- anyone who will talk, that is...),  the  386
has other instructions which can accomplish much of the same functions.  Thus,
it  is  possible  to write code that detects the  processor  being  used,  and
switches  strategy accordingly, using subroutines with 386 op-codes to  accom-
plish  the same functions on a 386.  Microsoft is already doing that in  their
RamDrive.Sys and HiMem.Sys programs.  Thus you can have code which will run on
both the 286 or 386, and makes the best use of each.

        This  instruction opens up so many possibilities (AND creates so  many
problems)  for things like alternate operating systems, and alternate  shells,
that live above 1 megabyte, in real mode or protected mode, that I foresee the
need  for  a community library of "Hyper-Space" subroutines, which  can  still
work properly even though some segments are in outer space, or the 80286 is in
protected  mode.  I would be happy to collect these, and pass on the  best  of
them with future distributions of this book and software.

        Please forgive all the legalistic warning messages.  If used properly,
and  carefully, the Loadall instruction can be quite safe.  You  haven't  seen
Microsoft  Ramdrive.Sys  destroying any systems lately, have you?   It's  just
that  a  few bothersome people love to sue for anything, so you just  have  to
plaster those stupid warning messages all over everything.




                                   LOADALL


        Okay, so what IS the Loadall instruction?

        Simple:

        *** 0F 05 hex ***

        So how does it work?  Well, I've already told you the gist of it:  all
CPU  registers  are loaded from a 51-word table of data that starts  at  80:0h
(absolute  24-bit  address 800h).  This address is one thing  that  cannot  be
changed or re-programmed. It's hard-wired into the chip, and that's that.  And
that's unfortunate, because all versions of anybody's DOS earlier than version
3.3 use that area for critical system code.

        Loadall takes no operands, and is just a two-byte instruction. All the
"operands" for the instruction are obtained from the table at 80:0h.

        Just put "db 0Fh, 05" in your code stream, and watch the fun. But  you
had better get that table right before you do, or else... (crash).


                ** THE LOAD TABLE **

-----------------------------------------------------------
Address         Size            CPU register
                (words)
-----------------------------------------------------------

800             3       unused  (?? I don't believe it.)
806             1       MSW (Machine Status Word)
808             7       unused  (?? I don't believe it.)
816             1       TR (Task Register)
818             1       Flag Word
81A             1       IP (Instruction Pointer)
81C             1       LDT (Local Descriptor Table)

81E             1       DS (Data Segment, or DS Selector)
820             1       SS (Stack Segment, or SS Selector)
822             1       CS (Code Segment, or CS Selector)
824             1       ES (Extra Segment, or CS Selector)

826             1       DI (Destination Index)
828             1       SI (Source Index)
82A             1       BP (Base Pointer)
82C             1       SP (Stack Pointer)

82E             1       BX (Data Register BX)
830             1       DX (Data Register BX)
832             1       CX (Data Register BX)
834             1       AX (Data Register BX)

836             3       ES Descriptor Cache
83C             3       CS Descriptor Cache
842             3       SS Descriptor Cache
848             3       DS Descriptor Cache

84E             3       GDTR
                        (Global-Descriptor-Table Register)

854             3       LDTDC
                        (Local-Descriptor-Table Descriptor Cache)

85A             3       IDTR
                        (Interrupt-Descriptor-Table Register)

860             3       TSSDC
                        (Task-State-Segment Descriptor Cache)

total =         33h words == 102. bytes






                      THE DESCRIPTOR CACHE ENTRIES

                      (DSDC, SSDC,CSDC, and ESDC)



        Wait a minute, forward-referencing again!  What's a descriptor? You've
already used that word up above, and never defined it.

        Well  okay. A segment descriptor is a four-word structure of  informa-
tion that describes a segment.  A descriptor gives a segment's size and 24-bit
starting  address, and has a byte of encoded information, called  the  "access
byte", that describes the characteristics of the segment (like whether it is a
code segment or a data segment, writable or write-protected, and so on).   And
the  desciptor  also has a dummy zero word for upward compatibility  with  the
80386.  Segment Descriptors are used in protected mode, but not in real mode.

        In  protected  mode,  when you want to use a segment  of  memory,  you
reference  the  segment descriptor.  The 80286 looks into a table  or  two  of
descriptors (which can be quite large, up to 16384 entries), to find the right
entry, and find out what the segment is. If you had to do this every time  you
referenced a memory variable, it would be terribly slow.  In order to  prevent
this  overhead, saving the descriptor information for the current segments  in
quickly-accessible CPU registers is a must.  That's what the descriptor caches
are for.

        But you said they aren't used in real mode, right?  Right.  The  soft-
ware  descriptor tables aren't.  But the hardware descriptor caches are.   The
Intel  book on the 80286 seems mighty thin when it comes to telling  you  pre-
cisely  what the protected-mode hardware does while in real mode, but some  of
it  still works, and is very important (the descriptor caches in  particular).
The  descriptor  caches determine where your segments really are,  whether  in
real or protected mode.

        In  real  mode, your segments are all normally 64 Kbytes in  size,  by
default,  and  are always located in the lowest megabyte of  the  80286's  16-
megabyte  address space.  When you want to access a segment, you just  load  a
number for the start of the segment into the appropriate segment register, and
then read or write that segment of memory.

        The  segment number that you load is the address scaled down  by  four
bits,  so that it really addresses a memory address that is sixteen times  the
number  you  gave  it.  You can address anywhere inside  that  64  Kbyte-sized
window by using an offset.

        Since the segment registers are 16 bits in size, and have been  scaled
by four bits, you have the equivalent of 20-bit addressing, and can address  a
1-megabyte sized area.  That's real mode.

        Did it ever occur to you that that 1-megabyte sized area might  itself
just be appearing somewhere inside of an even larger area?

        And that the 1-megabyte-sized real-mode area is made to start at  zero
when the 80286 chip is reset, but doesn't have to stay there forever?

        I  mean, if in protected mode, the hardware is there to address a  16-
megabyte-sized  address space, well, that hardware doesn't just go  away  when
you are in real mode, does it?  Or all just get turned off?

        No,  it doesn't.  As a matter of fact, it still works just  fine,  but
you  weren't given any instructions for doing anything with that part  of  the
hardware from real mode.  Or were you?

        Oh yes you were.  It's called LOADALL.

        So  how  do the hardware desciptor caches work?  Well, they  hold  the
information  that was read from a (software) descriptor in memory.  The  80286
discards  the unused zero word, and keeps the rest.  When you address  memory,
you  are actually using the segment addresses in the descriptor  cache  regis-
ters, not what is in the segment registers.

        Perhaps you thought you were using the segment registers for  address-
ing:  it sure looks like you do, because if you load something into a  segment
register, you will then address the memory that the segment register is point-
ing to.  What is happening invisibly in the background is that the correspond-
ing  descriptor cache is being updated whenever you load a  segment  register,
and then the descriptor cache is being used for the actual addressing.

        So  the segment descriptor caches, and not the segment registers,  are
what  actually  control what goes out on the address lines,  and  hence,  what
memory  you will really address. And the addresses in the  segment  descriptor
caches are 24-bit addresses.  Now isn't that special?

        So if we can use Loadall to load anything we want to into the  segment
descriptor  caches,  then we can address anywhere in the  16-megabyte  address
space of the 80286, right?  Right.  You got it.


        The contents of the descriptor cache entries in a Loadall table are:

         The  absolute 24-bit address for the start of the  segment,
                 in  the usual Intel  lowest-byte-first  byte-order.
                 That is, the bytes are: lowest, middle, highest.


         An  access byte, customarily set to 92h or 93h.  This  byte
                 is  encoded in the usual way that access bytes  are
                 encoded in Global Descriptor Table entries (see the
                 accompanying  charts).   This  byte  describes  the
                 characteristics of the segment, like whether it  is
                 code or data, and write-protected or not.

         A  16-bit segment limit.  This is the segment  size,  minus
                 one.  FFFFh is equal to a full 64K.


        This  ordering is exactly backwards, word-order-wise, from  the  usual
layout  of the descriptors used in the protected-mode tables like  the  Global
Descriptor Table.  This is because the Loadall instruction is essentially just
a  giant  POP-ALL instruction.  The word order is backwards  (really,  "Stack-
wards"), but the byte order within words is not reversed.

        The addresses loaded into the descriptor caches must be 24-bit  "abso-
lute"  or un-segmented "flat-space" versions of the segment  start  addresses.
IE: a segment address of 3456h becomes an absolute address of 034560h.  Remem-
ber  that segment addresses are ordinarily scaled down by 4 bits.  So we  have
to scale them back up to get the 24-bit flatland equivalent.

        You will notice that there seems to be some duplication of information
here:  you have a CS register slot in the Loadall table, which is loaded  with
the  desired  code  segment start address, and you also have  a  Code  Segment
Descriptor  Cache  entry, with an address slot which is loaded with  much  the
same information.  The same is also true of DS, SS, and ES.

        They can't always be the same, because one is 16 bits, and one 24, and
the 24-bit descriptor cache entry can specify the address down to the byte, in
the full 16-megabyte address space, while the 16-bit segment register can only
address on 16-byte boundaries, and can't address beyond 1 megabyte.

        So  if  they are different, which ones win out?   The answer  is,  the
Descriptor Caches.  They have to, because only the Descriptor Caches have  the
whole  24-bit address necessary for addressing the entire 16-megabyte  address
space of the 80286.  Also because the Descriptor Caches are what are  actually
wired  to the address lines.  In protected mode, the segment  registers  don't
even get close to the address lines.

        But  watch  out: this gets tricky.  For a  simple  rule-of-thumb,  the

proper  programming practice to follow is: in real mode, always keep them  the
same.  That is, where the bits of the two overlap, keep them the same.  The CS
register  really holds the equivalent to bits A3 to A19 of the 24-bit  address
in the CS Descriptor Cache, so there is no way that you can "keep them all the
same".  But you can keep those bits the same, and you will want to.

        Why?  Because, in real mode, certain operations will update a Descrip-
tor Cache using the contents of the paired Segment Register.  Oh yeh?  Yeh.

        Example:

        Even  if the code segment entry "CS" in a Loadall table  is  blatantly
wrong,  but the value in the Code Segment Descriptor Cache "CSDC" is  correct,
and  the Instruction Pointer "IP" value is correct, and you do a Loadall,  the
Loadall will still work, and you WILL run the code that you intended to be run
after  the Loadall, but the program will crash at the first  jump  instruction
after  the  Loadall.  Calls to subroutines will likewise crash if  the  CS  is
wrong.

        The  jump  or call instruction causes updating of  the  CS  Descriptor
Cache  contents, using the contents of the CS register, and the offset in  the
jump  or  call instruction.  So your CS descriptor cache goes  from  right  to
wrong,  without any further help from you.  That's why you have to "keep  them
the same".

        (This  is just a simple rule of thumb.  Like all simple  rules,  there
are exceptions, and the rules can be broken.  Breaking these rules doesn't buy
you  anything, but you might note that this is simply a rule of thumb,  not  a
Commandment From On High.)

        The same is also true of the other Segment Registers, and their match-
ing Descriptor Caches, although the instructions that will cause updating will
differ.   The  commonest operation that causes updating  of  these  descriptor
caches is loading a new segment value into a segment register.

        Now obviously, not all the bits of the address in the Descriptor Cache
will be updated by such operations.  The highest 4 bits cannot be updated from
the  segment register, because there are no corresponding bits.  So what  does
it do with them?  In real mode, the worst.  It clears them.  Try doing a  jump
while  executing real-mode code upstairs, above 1 Megabyte, and you will  come
crashing down out of the sky.  A simple jump in code located way upstairs will
turn  into  a very long jump to the lowest megabyte of memory.   Probably  not
what you had in mind, at all.  Far jumps and far calls are out of the question
for the same reason.

        Curiously,  a  call will not cause you to fall out of the sky  in  the
same  way as a jump will, so we can do reversed jumps, or reversed  calls,  by
shoving  a return address, and then a destination address onto the stack,  and
then executing a return instruction, where a jump to precisely the same  place
will crash us.


        When  you are executing code in real mode, above 1 megabyte  (plus  64
K), your position is as precarious as that of Icarus flying towards the sun on
wings  held  together with wax.  (More on that "plus 64 K" note  later.)   You
must  keep  interrupts turned off because ANY interrupt will  yank  you  down-
stairs,  and you won't return upstairs again.  The interrupt  service  routine
will  change some segments or other, particulary the Code Segment,  and  those
segments'  descriptor  caches will have the highest  four  bits  irretrievably
cleared.

        And  the  updating  of the  lowest four bits is an  open  question.  I
always  set  my segments on 16-byte boundaries so I don't  get  burned  there.
That  is, the four lowest bits of the 24-bit address are always  zero.   Thus,
the  16-bit  segment settings in the segment registers will always  match  the
values of the lowest 20 bits of the descriptor cache settings.

        Here's what these descriptor cache entries look like, in source  code,
with a set of default values plugged in:

newESDC         dw      0,      9200h,  0FFFFh
newCSDC         dw      0,      9200h,  0FFFFh
newSSDC         dw      0,      9200h,  0FFFFh
newDSDC         dw      0,      9200h,  0FFFFh

        The running program will replace those zeroes in the first and  second
words of each entry with real addresses before doing the Loadall.

        The "92"'s are the access bytes, and mean: "this item is a  descriptor
of  a data segment, it is valid, it has the highest possible  privilege  level
(0), writing to it is okay, and it has not been accessed" (really, written to.
A 'dirty' page, in virtual-memory-system parlance).

        Those  "FFFF"'s set up segments 64K in size. There's no point in  set-
ting  them  any smaller, and a lot of grief to be gotten if you  do.  So  just
always set them to "FFFF" in real mode.

Answer 3

Continued from my previous answer. This is the rest of the document about LOADALL, by Terrance E. Hodgings:

                       THOSE OTHER BIG REGISTERS


        GDTR    Global Descriptor Table Register
        LDTDC   Local-Descriptor-Table Descriptor Cache
        IDTR    Interrupt Descriptor Table Register
        TSSDC   Task-State-Segment Descriptor Cache

        These  registers do next to nothing while in real mode.  The  strategy
for dealing with these is: just set them up in an acceptable manner, and  then
forget them.  The Interrupt Descriptor Table Register is the most important of
these,  as  it  really does determine the starting address  of  the  interrupt
vector table.

        The format of the data for these registers is just about identical  to
the  format  of the data in the Descriptor Caches, except for an  unused  byte
(there is no access byte):

        an absolute 24-bit address for table start, in the
                usual Intel byte-order. That is, the bytes
                are: lowest, middle, highest.

        an "extra", or "trash", or "dummy" byte (pick your
                favorite name.)  Set to either FFh or 0.

        a 16-bit limit.  This is the table size, minus one.
                (FFFFh == a full 64K)



       Set up the GDTR (Global Descriptor Table Register) and the IDTR (Inter-
rupt  Descriptor Table Register) using the instructions "sgdt" and  "sidt"  --
"store  global  descriptor table register", and  "store  interrupt  descriptor
table register". These two instructions work in both real and protected mode.

       The  values that we get from them are somewhat goofy (especially  since
we  are getting data about non-existent tables), but we use those values  any-
way, just to keep the 80286 chip happy.  We will just stuff back into the chip
whatever is already in there.

       The  LDTDC (Local-Descriptor-Table Descriptor Cache) is a real  nothing
in real mode.  In real mode, there is no Local-Descriptor-Table Descriptor  to
cache.  We just set the LDTDC with an acceptable size, same as the GDTR (88h),
and let it go at that.

       The  TSSDC  (Task-State-Segment Descriptor Cache) is  likewise  a  null

register in real mode.  There is no Task State Segment to point to. Again,  we
just  set  it up with a size that will keep the 80286 chip from  freaking  out
(thinking that the segment is impossibly small), and let it go at that.



       Set up, just before doing a Loadall, these items will look like:

newGDTR         dw      D8A0h,  0FF00h, 88h
newLDTDC        dw      0,      0FF0Eh, 88h
newIDTR         dw      0,      0FF00h, 0FFFFh
newTSSDC        dw      4000h,  0FF0Eh, 800h


        The addresses in the newLDTDC and the newTSSDC are E0000h and  E4000h,
respectively.   There is nothing at those addresses but stupid phantom  copies
of the BIOS Roms, wasting precious low-memory address space.  So what I do  is
put  the  non-existent tables on top of the non-existant ROMS,  and  let  them
fight  it out.  In truth, those addresses in those descriptor caches'  entries
will  never  really be used for anything, anyway, so they could  be  anywhere.
They just don't matter.  The starting address of the IDTR is the only one that
does matter.



                  AND ALL THOSE OTHER LITTLE REGISTERS


        The  MSW  (Machine Status Word) is normally set to zero. On  the  286,
only  the  4 lowest bits are even used.  The one super-important bit  in  this
register  is  the mode bit.  Set it, and you warp into  protected  mode.   The
other three bits are invalid and irrelevant if you are not in protected  mode.
Zero this word, unless you really intend to go into unreal mode.  Heaven  help
your program if you set it, and have not set up all the descriptor tables, and
all the protected-mode registers, and cross-linked all the pointers to  every-
thing, correctly, first.  We will get into that can of worms later.

        Just for reference, here's what the bits are:

        D0      == PE Protected-Mode Enable  (yeh, this is IT.)
        D1      == MP Monitor Process
        D2      == EM Emulate Processor Extension
        D3      == TS Task Switched


        The  TR  (Task Register) is another register used  only  in  protected
mode. It is used for keeping track of which task is running.  Not our  problem
in real mode.  Zero it.

        The  Flag Word is the same old flag word that we are already  familiar
with  from ordinary real-mode programming.  We just push the flags word  here,
and  we've done it.  Or we can zero it.  None of our programs are going to  do
anything as off-the-wall as a conditional jump right after a Loadall,  anyway,
right?  Uh, right?  Why do I see you grinning?  12-dimensional Life, huh?

        The IP (Instruction Pointer) is critical.  This one really works.  The
address we put here will, in combination with the address in the Code  Segment
Descriptor Cache (CSDC), determine where we will start executing code  immedi-
ately after the Loadall.  So this acts like a jump vector.  We set this up  in
the  our programs, just before doing a Loadall, do determine where we will  go
next.  Better get this one right.

        The  LDT  (Local Descriptor Table) is another null  register  in  real
mode.  Zero it.


        DS (Data Segment, or DS Selector)
        SS (Stack Segment, or SS Selector)
        CS (Code Segment, or CS Selector)
        ES (Extra Segment, or CS Selector)
        Set these up so that they contain the same number as bits A4 to A19 of
the  corresponding Segment Descriptor Cache.  These work in  conjunction  with
those.



        All  of the following registers are very straight-forward:  just  load
them  with whatever you want the registers to have after the Loadall.  If  you
are  not trying to carry values in these registers, you can just default  most
all of them to zeroes.

        The stack pointer requires some care, as the stack is one of the  best
ways to carry data into the beyond.  I generally stuff the stack just before a
Loadall,  and then write the current stack pointer to the SP slot in the  Loa-
dall table, so that I know that I have it right.

        DI (Destination Index)
        SI (Source Index)
        BP (Base Pointer)
        SP (Stack Pointer)

        BX (Data Register BX)
        DX (Data Register DX)
        CX (Data Register CX)
        AX (Accumulator AX)


        And then these little curiosities: the two "dead" spots in the table.

800     3 words         unused   (?? I don't believe it.)
808     7 words         unused   (?? I don't believe it.)

        Obviously, they are there for something.  They must load some  invisi-
ble register or other.  The registers might be some very transient  registers,
just for intermediate products, which may not be useful...

        Then  again,  considering how much we haven't been told so  far,  they
might be good for something.  This is another area for future experimentation.
In the mean time, zero them.


                  AND A PRETTY-TOGETHER DEFAULT TABLE


        So  here's  what  a  default  Loadall  table  looks  like.  Note  that
"new_Reg_Buf" doesn't label any data item that we really use; it's the name of
the whole table.

;    LOADALL Register Load Table for new values to be loaded
;    into registers by a Loadall.

new_Reg_Buf     dw      3 dup (0)       ; unused space
newMSW          dw      0
newDead         dw      7 dup (0)       ; unused space
newTR           dw      0
newFlagWord     dw      0
newIP           dw      offset after_ldall      ; * may chng
newLDT          dw      0

newDS           dw      0       ; *chng
newSS           dw      0       ; *chng
newCS           dw      0       ; *chng
newES           dw      0       ; *chng

newDI           dw      0
newSI           dw      0
newBP           dw      0
newSP           dw      0       ; *chng

newBX           dw      0
newDX           dw      0
newCX           dw      0
newAX           dw      0

newESDC         dw      0,      9300h,  0FFFFh  ; *chng
newCSDC         dw      0,      9300h,  0FFFFh  ; *chng
newSSDC         dw      0,      9300h,  0FFFFh  ; *chng
newDSDC         dw      0,      9300h,  0FFFFh  ; *chng

newGDTR         dw      D8A0h,  0FF00h, 88h     ; @ 0D8A:0 *n
newLDTDC        dw      0,      0FF0Eh, 88h     ; @ E000:0
newIDTR         dw      0,      0FF00h, 0FFFFh  ; @ 0000:0 *n
newTSSDC        dw      4000h,  0FF0Eh, 800h    ; @ E400:0


        Those  "*chng" comments mean that those items MUST be changed  by  the
running program before actually doing the Loadall. We cannot correctly default
them in the sources because the correct values can only be determined at  run-
time.



        The "*n" means that those values are not really in the default  tables
in the sources: the running program uses the sgdt and sidt instructions to get
those values and then plugs them into those two entries.  Just letting you see
what they will look like. You could have anything in the original table there,
because  the running program will over-write those items with  correct  values
anyway.

        The "@ 0D8A:0" comments are just noting the addresses in those  items,
in a more readable form.




                        GATE A20 : Door to the Beyond


        Before  we get heavy into the guts of actually using the  Loadall  in-
struction, we need to touch on this item: Gate A20.  Loadall is almost useless
without control of Gate A20.

        Gate  A20  is the gate on the motherboard of the AT  that  enables  or
disables  the  4  highest  address  lines, A20 to A23.  In  order  to  be  PC-
compatible, they are ordinarily disabled on an AT.  The pathetic PC could only
address 1 megabyte of space, total, remember?  That's 20 bits.  If those lines
are disabled, then addressing wraps to zero above FFFF:0010.  But if they  are
enabled,  then addressing doesn't wrap, and you can address above 1  Megabyte.
This  has nothing to do with protected mode.  Even if the 80286 were  in  pro-
tected mode, it still couldn't address above 1 Megabyte without enabling  Gate
A20.

        In  the part of the Hyper-Space Library freely distributed  with  this
document  and the View-XM program are routines called "A20_on" and  "A20_off".
They  need no arguments.  You just call them, and they will enable or  disable
Gate A20.  Do not make a habit of turning Gate A20 on and just leaving it  on,
as  rumor has it that some barbaric programmers from the bad-old days  made  a
habit  of depending on address-wrapping, addressing something like  FFFF:0345h
to  get at 0:0335h.  Ugh!  These subroutines also check whether Gate  A20  was
already on before the call, and if so, leave it alone.

        This  leads us to a very interesting twist in the game:  what  if  you
turn  on Gate A20, and load FFFFh into a segment register, like the DS  regis-
ter,  and then address something like DS:0300h?  The answer is, you  will  ad-
dress  beyond 1 megabyte, without either going into protected mode,  or  using
Loadall  tricks.  The  PC can only address 1 Megabyte total, but  the  AT  can
address 1 Megabyte, plus 64K, minus 16 bytes, in REAL mode, without Loadall.

        This a big part of the XMS driver specification.  That's the  eXtended
Memory Specification (not to be confused with the "EMS" Expanded Memory Speci-
fication).  The XMS driver accesses memory addressed above 1 Megabyte on AT's.

        You can write programs which use standardized calls to the XMS driver,
and  expect that the program will work with anyone's XMS  driver.   Microsoft,
Intel, Lotus, and AST Research (the authors) have put the XMS specification in
the  public domain (although they retain the copyright), and it  is  currently
supported  by them, and probably by many more companies that I don't know  of,
so we should be seeing plenty of good XMS device-drivers around, and, in turn,
programs using it.

        Furthermore,  Microsoft  will give you a copy of the XMS  driver,  and
standard,  free,  if you write to them and ask for one.   Write  to  Microsoft

Corporation,  16011  NE 36th Way, Box 97017, Redmond WA  98073,  and  politely
request  a  floppy copy of the XMS standard and driver.  The  same  files  are
available from many bulletin board systems, and anonymous FTP sites.

        Since  you  want a nice, clean, non-colliding standard  way  for  your
programs to be able to get at more ram, using the EMS and XMS standards is the
only  good  way to go.  Throughout this book, we are going  to  support  those
standards, and others, too.

        The  recommended  programming practice is to always  support  the  XMS
standard, and use requests to the XMS driver to get at extended memory, rather
than just brute-force doing it yourself, even though you can with Loadall,  so
that your programs will not conflict with others.

        The PC world is already far too filled with gotchas and incompatibili-
ties,  and things that collide with other things, for us to be adding  to  the
misery.

        The one thing that the XMS driver adds, that you will not have if  you
just  take  over and use an area of extended memory yourself, is any  kind  of
collision  prevention  or co-ordination between programs.  You won't  know  if
another  program is already using that area, but the XMS driver will, as  long
as the other program is also using the driver.  So everybody better be  adher-
ing to the standard!

        On  the  other  hand, you would not be reading  this  book  about  the
"secret"  Loadall  instruction if you were all that committed  to  ONLY  using
"normal" standards, would you?  The trick is to support the standards, without
being  constrained  by them.  This requires great care and thought  about  the
consequences  of any use of Loadall for "non-standard" activities.   You  can,
for  instance, allocate some memory, using the XMS driver, and then  go  ahead
and use Loadall to do anything you want to with it, since you now own it.  You
have the best of both worlds.

        And so what do the XMS drivers use to get at the extended memory above
the High-Memory Area?  Either going into protected mode, or Loadall.




                       THE PROCEDURE FOR USING LOADALL
                       (the ultra-safe, long procedure)


1.      Save  the  original machine state, so you have a state to  return  to.
This information can be saved in a Loadall table, which is the most convenient
form for later use.

2.      Disable interrupts.  Just in case.  We want a clean copy of area 80.

3.      Save  the 102-byte (33h words) block of data located at  80:0h.   Ver-
sions  of DOS (both PC- and MS-) earlier than 3.3 use this area  for  critical
system code, and as of DOS 3.3, RamDrive.Sys, and Himem.Sys use this area  for
their own Loadall tables.

4.      Re-enable  interrupts.   Let the clock ticks,  or  whatever,  through,
while we do the following step.

5.      Set  up  the new Loadall table (new_reg_buf), which  defines  the  new
state we want to warp to.

6.      Disable Interrupts.

7.      Copy the new Loadall table to 80:0h.

8.      Execute a Loadall.

9.      Do  something  or other with your new machine state.   Read  or  write
extended memory, run code upstairs, or whatever.

10.     Copy the "old" Loadall table, containing the saved machine state, down
to 80:0.

11.     Do  another Loadall (Un-Loadall.)  This restores the original  machine
state.

12.     Copy the block of saved data back to 80:0h.

13.     Re-enable interrupts.

        And you have done it.


        This is the long, drawn-out method.  There are various short-cuts  and
speedups possible.

        If all you have been doing is reading or writing extended memory,  for
instance,  then  you  don't have to do the second loadall.   Just  changing  a
segment register (loading a new value) will cause the corresponding Descriptor
Cache  to drop its four highest address bits, restoring addressing to the  low
megabyte.

        Read the sources for the program "View-XM" for more details on this.

        See the full text of The Hyper-Space Navigator's Guide for more.




        The  Hyper-Space Navigator's Guide, the book and software library,  is
available   from  Semi-Intelligent  Systems  for  $49.00  (students  get   20%
discount),  and comes with the floppy of source code.  With other  books,  you
have  to pay $10 or $20 more to get the floppy that should have come with  the
book  in  the  first place.  Here you don't.  It is available  on  any  common
floppy  format:  5.25" 360K or 1.2MB, or 3.5" 720K.  If you order  it,  please
state your floppy format preference.

        FULL source code in assembly and C is provided.

        The Hyper-Space Navigator's Guide gives the full low-down on  Loadall,
and other 286- and 386-compatable extended-memory tricks, too:  the good,  the
bad, and the ugly.

        The  book comes with a library of subroutines designed  to  facilitate
the use of extended memory, and includes numberous demo programs which do just
about everything you can do with Loadall (or without), including:

        reading and writing extended memory.

        running code up there, in both real and protected mode.  Yes, you  can
use  Loadall  to  warp directly into protected mode.  Or you  can  do  it  the
"normal"  way, so that the code will be 386-compatable.  Both ways are  imple-
mented in the code.

        going  into,  and running in, and then getting back out  of  protected
mode,  from within your own programs, on both the 286 and 386.   Getting  into
protected mode is relatively easy.  Try getting back out on a 286.  I'll  show
you how.

        writing  "split"  programs,  with a low-memory half, and  a  high-  or
extended-memory  half,  with the second half in real or protected  mode.   The
cat's meow for image-processing programs which eat memory space like popcorn.

        installing  either real- or protected-mode "high code" inside  an  ex-
tended-memory  ram-disk file, where it won't collide with anything or  anybody
else,  and then using a TSR to launch directly into running the code  from  in
there (thus turning a piece of the ram-disk back into ram).

        Again,  full and complete source code, so that the demo programs  also
supply  you  with hackable skeletons for quickly building your  own  programs,
(without  the  many months of day-and-night hacking and  hair-tearing  I  went
through  to  figure out this stuff).  Just throw away the middle of  the  demo
main routine and plug your code in.