delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/02/22/22:01:26

Date: Wed, 23 Feb 2000 07:07:05 +0500 (MVT)
From: Prashant TR <prashant_tr AT yahoo DOT com>
X-Sender: prashant_tr AT midpec DOT com
To: Kalum Somaratna aka Grendel <kalum AT crosswinds DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: real mode & protected mode
In-Reply-To: <Pine.LNX.4.10.10002221111440.677-100000@darkstar.grendel.net>
Message-ID: <Pine.LNX.4.10.10002230608030.821-100000@midpec.com>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 22 Feb 2000, Kalum Somaratna aka Grendel wrote:

> > 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.

Yes. But I thought we're talking about 386s. loadall isn't very fast. It
takes many more clocks than LMSW.

> >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. 

No, not at all. There's an even simpler way. I'll just give a brief idea.

1> Prepare a descriptor that is 4GB (of data type) in the GDT.
2> CLI and disable NMI.
3> Set bit 0 or CR0.
4> Load the 4GB selector in FS, GS or whatever.
5> Get back to real mode (clear bit 0 of CR0).
6> STI and enable NMI.

The program to do this is around 10 lines of assembly!

> 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).

Are you sure. I don't think it can do 32-bit real mode.

> What I wanted to comment about was that the loadall insn is a very
> powerful insn

Yes, it is. You can do lots of things in one shot.

> If nedded I can provide the details on how to do this but it is a bit
> lengthy and complex...

I have those things here. You're right. It is quite lengthy.

> 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??

Of course, the 286 can get back to real mode. It is done through the
MSW. MSW (Machine status word) is the 1st 16-bit of CR0. Setting bit 0 of
MSW enables prot. mode, resetting it gets back to real mode.

> 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.

Have you seen the fields required for this call. It's the GDT, IDT, etc.
It doesn't use loadall. I've debugged many BIOSes.

> 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. 

Not clear. I suppose you meant the 286 in the last line. There's no need
to reset the CPU to get back to real mode on a 286. LMSW is there just to
do this.

> 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.

Oh no. This seems to be wrong information. Where did you get this?

> 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.

I don't believe RAMDRIVE used this. The loadall isn't documented in the
first place and using it is certainly *not* a good idea for any decent
program that requires portability.

- Raw text -


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