delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/02/22/11:54:14

Date: Tue, 22 Feb 2000 20:47:40 +0600 (LKT)
From: Kalum Somaratna aka Grendel <kalum AT crosswinds DOT net>
X-Sender: root AT darkstar DOT grendel DOT net
To: djgpp AT delorie DOT com
cc: Prashant TR <prashant_tr AT yahoo DOT com>
Subject: Re: real mode & protected mode
Message-ID: <Pine.LNX.4.10.10002222042070.939-100000@darkstar.grendel.net>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

On Tue, 22 Feb 2000, Prashant TR wrote:

> On Mon, 21 Feb 2000, Kalum Somaratna aka Grendel wrote:
> 
> > On Fri, 18 Feb 2000, Prashant TR wrote:
> > 
> > So by manipulating the descriptor
> > cache base registers it is possible to access the entire address space
> > _wihtout_ switching to protected mode. That means that you can acess
> > memory above 1 MB while in real mode!
> 
> There are much simpler ways tp access 4GB in real mode. The loadall
> instruction has all kinds of crazy fields and it's definitely not worth
> the trouble. 

But this was the only reasonably fast and practical way to access extended
memory in the 286 CPU.

>With a small trick, you *can* get to access 4GB in real mode using a
>16-bit program.

Yes, Using the 386 LOADALL insn to acess extended memory in real mode. 

>But running 32-bit programs with loadall is not
> possible AFAIK. You'll still need to set the CR0 value in the pointer to
> the tables. Accessing 4GB is *one* of the things a 32-bit program can do.
> It's not really a difference b/w a 16-bit and 32-bit programs. It's not
> really a difference.

The 386 loadall can be used to switch the cpu into 32 bit protected and
also 32 bit real mode (a mode that is illegal for the CPU using other
normal insn).

What I wanted to comment about was that the loadall insn is a very
powerful insn and that 32 bit real mode are posiible if loadall is used.
If needed I can provide the details on how to do this but it is a bit
lengthy and complex...


> The 286 and 386 have LMSW that can switch to real or protected mode. The
> switch took place by setting some flags in the CMOS and some
> manipulations which was d amn slow.
                          ^^^^^^ BTW I had to put a space between the
highlighted words since the DJ's email gateway rejected the reply saying
"offensive language not allowed". Thats the second time this hapenned to
me and through no fault of my own too. Sorry for mentioning this but this
mail filter is really annoying.

I am not very familiar with the LMSW insn but I am positive that the 286
doesn't have a instruction to switch it *back to real mode*. Maybe there
is some resident guru who can further enlighten us??

AFAIK programs that had to access extended mem did so by using the BIOS
INT 15h service to switch the 386 cpu in to protected mode and do the data
transfer. And then the BIOS can also be used to switch back in to real
mode, but the lack of a insn to switch the 286 into real mode meant that
the BIOS had to immediately reset the 386. 

The BIOS avoided a cold start after this reset by saving the current
context (ip, flags etc) into the CMOS ram. And since the CMOS ram is *not*
cleared during boot up, the BIOS initilisation code can test the CMOS for
a valid context and if it finds one it can then restart the 286 at the
BIOS location which continues the extended mem transfer.

While this worked, all this messing about with the CMOS etc is very slow
so thats what made programmers use the LOADALL insn for the 286
programming.


> > So to avoid this timeconsuming mode switch 286 programmers used the
> > 286 loadall insn to access >1MB memory.
> 
> Not ordinary programs. The BIOSes manily used this. Since the BIOS has to

Actually the BIOS of 386 and above were designed to emulate the 286
loadall since the large number of programs that used it. AFAIK RAMDRIVE,
OS/2 all use/d loadall.


Grendel

Hi, I'm a signature virus. plz set me as your signature and help me spread
:)



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019