Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

80386 Unreal mode?

432 views
Skip to first unread message

David Pyles

unread,
May 16, 1995, 3:00:00 AM5/16/95
to
This is a generally unknown feature of the 386, 486, etc. However, you
will find it partially explained in the programmer's reference manuals
published by Intel. If you shift the CPU to protected mode and alter
the segment limits, then shift back to real mode, the limits left in
protected mode still pertain. Hence, one could shift to protected mode;
set the limit on DS to FFFFFFFFH, then shift back to "real mode" having
unlimited ability to access memory. This can not be done if a memory
manager (other than HIMEM.SYS) is operating; because the manager will
not allow such undisciplined mode switching (the manager must supervise
the mode shifts).
There is an undocumented CPU instruction that can also perform all
this without performing a mode switch. This instruction is commonly
called LOADALL. It is my understanding that HIMEM.SYS uses this
instruction and the approach described above to gain access to extended
memory.
Try running your machine with HIMEM.SYS only. You will probably
find that you automatically have access to extended memory from real
mode. I know that this was the case with older versions of HIMEM. I
will almost bet that it still is. This happens because HIMEM does not
reset segment to real mode values (FFFFH) after performimg extended
memory functions.

barrym

unread,
May 16, 1995, 3:00:00 AM5/16/95
to
I recently downloaded a small program with docs that claims to put the 386
into what it calls unreal mode. You run this from DOS. It will only run
if you boot without a memory manager loaded.

It doesn't seem to interfere with DOS, but it does let you set
segment registers to 0 and act as though you were in the flat memory model,
using offsets beyond 64k. It does work.

The author claimed that he's used it with all sorts of programs and never had
any problems with it, or with DOS or Windows while using it. He doesn't
explain the technique and I haven't disasembled the code yet.
He does say that he's taking advantage of a bug in the 386.

It works fine on my 486. I haven't
tried it on a pentium yet. I don't have a 386 available.

That's all I know about it. I wouldn't have thought it was possible. I'm
not very knowlegable beyond the real mode. Does anyone know how this is done?

I think I got the code from Simtel. The file was unreal10.zip.


Barry


Robert R. Collins

unread,
May 17, 1995, 3:00:00 AM5/17/95
to
In article <pOyf75F.d...@delphi.com>, david...@delphi.com says...

> There is an undocumented CPU instruction that can also perform all
>this without performing a mode switch. This instruction is commonly
>called LOADALL. It is my understanding that HIMEM.SYS uses this
>instruction and the approach described above to gain access to extended
>memory.

80486 and Pentium did not implement the LOADALL instruction. As far
as I know, HIMEM.SYS does not use it. 80286 has LOADALL (opcode 0F 05),
and 80386 has LOADALL (opcode 0F 07). But don't try and execute these
instructions, unless you understand how they work. I wrote a magazine
article on these instructions, many years back. Now they are most
commonly documented (with references to my article), in the Undocumented
PC books.

> Try running your machine with HIMEM.SYS only. You will probably
>find that you automatically have access to extended memory from real
>mode.

Not because of LOADALL, but because you can address up to 64k (minus
16 bytes) of extended memory while still in real mode (FFFF:10 through
FFFF:FFFF).

--
Robert Collins | "Boom, Boom. Ain't it great to be Crazy?"
email: rcol...@daldd.sc.ti.com | -- Barney
work: (214) 997-3923 | (Foot stomp) "Crazy?"
home: (214) 517-1128 | -- My son Daniel (19 months)


barrym

unread,
May 17, 1995, 3:00:00 AM5/17/95
to
Thanks for your explanation. I'll try what you suggest with HIMEM.SYS.
If this is as good as it seems to be, why isn't it in common use?

Barry


Erwann Corvellec

unread,
May 17, 1995, 3:00:00 AM5/17/95
to
In article <3pap59$l...@uuneo.neosoft.com>, bar...@starbase.neosoft.com (barrym) writes:
|> I recently downloaded a small program with docs that claims to put the 386
|> into what it calls unreal mode. You run this from DOS. It will only run
|> if you boot without a memory manager loaded.
|> ...
|> The author claimed that he's used it with all sorts of programs and never had
|> any problems with it, or with DOS or Windows while using it. He doesn't
|> explain the technique and I haven't disasembled the code yet.
|> He does say that he's taking advantage of a bug in the 386.

If you wan't more info on the Flat Real Mode, get:
ftp://ftp.cdrom.com:/pub/demos/code/memory/frmi!150.exe
It's coded by me, and the FULL source code and explanations are included...
Enjoy ! ;-)

--

Erwann Corvellec.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Student & coder on PC (ASM, C, C++) & fond of LINUX V1.3 ;-D
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sean Palmer

unread,
May 18, 1995, 3:00:00 AM5/18/95
to
b >I recently downloaded a small program with docs that claims to put the
b >into what it calls unreal mode. You run this from DOS. It will only r
b >if you boot without a memory manager loaded.

b >It doesn't seem to interfere with DOS, but it does let you set
b >segment registers to 0 and act as though you were in the flat memory mo
b >using offsets beyond 64k. It does work.

b >The author claimed that he's used it with all sorts of programs and nev
b >any problems with it, or with DOS or Windows while using it. He doesn'
b >explain the technique and I haven't disasembled the code yet.
b >He does say that he's taking advantage of a bug in the 386.

b >It works fine on my 486. I haven't
b >tried it on a pentium yet. I don't have a 386 available.

b >That's all I know about it. I wouldn't have thought it was possible.
b >not very knowlegable beyond the real mode. Does anyone know how this i

b >I think I got the code from Simtel. The file was unreal10.zip.

Probably talking about Flat Real mode. You can, from real mode, (NOT V86
mode which is why it can't be done under a memory manager, you don't have
enough privilege from V86 to be able to do it) go into protected mode, set
up your segment registers' hidden fields to give yourself 4gig access
rights, then go back to real mode. Everything works as expected in real
mode, but any segment register you use has access to a 4 gig chunk of
memory, no matter what value you give it. So you can do this, for instance:

mov ax,0
mov es,ax
mov edi,0A0000h
mov byte ptr es:[edi],255

mov ax,100h
mov es,ax
sub edi,1000h
mov byte ptr es:[edi],0


Net effect: pixel at 0,0 on mode 13h screen gets set to use palette entry
0.

Code to set it up isn't very complicated, but then again it's incompatible
with ALL memory managers, so I for one will never use it because it would
cause users too many headaches. You can do almost the same thing using
protected mode.

---
* WR # 380 * In the .EXEs of Life, he had more NOPs than most.

Jonathon Gilliver

unread,
May 20, 1995, 3:00:00 AM5/20/95
to
Ba> Thanks for your explanation. I'll try what you suggest with
Ba> HIMEM.SYS. If this is as good as it seems to be, why isn't it in common
Ba> use?

Because people are stupid, and think this is re-inventing the wheel or some
such pathtic excuse, or they just dont know about it.

There is a program called REALMEM which does this with HIMEM loaded as well
since it provides a patch to HIMEM which leaves the A20 line enabled <or
something like that>...

Eggplant

___ Blue Wave/QWK v2.12

Ingo Warnke

unread,
May 26, 1995, 3:00:00 AM5/26/95
to
barrym (bar...@starbase.neosoft.com) wrote:
: I recently downloaded a small program with docs that claims to put the 386
: into what it calls unreal mode. You run this from DOS. It will only run
: if you boot without a memory manager loaded.

The discussion here shows that it is generally agreed upon that unreal mode
(or flat real mode) is possible to reach from real mode but not from
virtual mode (where any memory manager puts you in). This is due to the fact
that in virtual mode certain instructions (e.g. to enter protected mode) are
handled by a supervisor program (V86 monitor).
But this assumes that the V86 monitor (provided by your memory manager) is
your "enemy".Lets assume that you are allowed to write (or modify) a memory
manager in any way that you want. Would it then be possible to get into a
"flat V86 mode" where you have segment registers with limit greater than 64KB?
It would be possible to get into flat real mode, since an interrupt call, when
intercepted by the V86 monitor, could signal the V86 monitor to switch to real
mode and then perform the normal action to get greater segment limits. But
this doesnt work for virtual mode.
I think that it is generally not possible (with an exception possibly being
the LOADALLD instruction on a 386) to get segment limits greater than 64KB
in virtual mode. Here come my ideas:
There are only 2 ways to get into virtual mode: via a task switch and via
an IRETD where the VM-bit of the memory image of the EFLAGS is set. But in
both cases all segment registers are reloaded from memory (from TSS in the
first case and from the stack in the second). So the switch process is designed
to handle situations where you have larger segment limits on entry of the
mode switch and must handle them.
If anybody thinks there is a method to get into flat V86 mode,I'd like
to here about it.

Ingo Warnke


barrym

unread,
May 31, 1995, 3:00:00 AM5/31/95
to
Thats the same info I got from some others too. Thought you'd like to know
you're correct. Thanks for answering.

Barry


On Wed, 31 May 1995, RUDD KARL LESLIE wrote:

>
> Hi ... about the UNREAL mode thing... Sorry if u've already got heaps of mail
> on this but I thought I'd put in my 2 cents worth...
> According to soomeone I wrote to it probably sets all the segment limits (?!)
> to their max of 4Gb... so everything LOOKS flat...
> Anyhow... there's my 2 cents... bye!
>
> Karl
>

0 new messages