Skip to content

Instantly share code, notes, and snippets.

@luelista

luelista/gist:557dd8f7f5b28cc1f9c28776c88ec347

Created June 11, 2019 09:17
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save luelista/557dd8f7f5b28cc1f9c28776c88ec347 to your computer and use it in GitHub Desktop.
Save luelista/557dd8f7f5b28cc1f9c28776c88ec347 to your computer and use it in GitHub Desktop.
Download ZIP
THE LOW-DOWN ON LOADALL
Raw
gistfile1.txt
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: 76416.553@compuserve.com
Internet: terry%scopes.unm.edu@ariel.unm.edu
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.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment