[comp.sys.ibm.pc] Caches and Extended Memory

stoppani@slough.enet.dec.com (Pete Stoppani) (03/10/90)

 
My understanding is that memory above 1Meg (except for the first
64k above 1Meg) is accessible only when a 268/386/486 is in protected mode.
How does a hard disk cache driver use extended memory on a system running
MS-DOS?  Does it switch to protected mode?  Do the machines run in
protected mode all the time?  Neither seems right...What am I missing?
 
-- 
| Pete Stoppani                    | stoppani@decwet.dec.com                  |
| DECwest Engineering, Bellevue WA | decwrl!slough.enet!stoppani              |
|                                  | HPDESK: stoppani("decwet.dec.com")/hpunix|
| "The wise learn more from fools than fools learn from the wise."            |
 
 

stever@Octopus.COM (Steve Resnick ) (03/10/90)

In article <9003091838.AA21834@decwrl.dec.com> stoppani@slough.enet.dec.com (Pete Stoppani) writes:
>My understanding is that memory above 1Meg (except for the first
>64k above 1Meg) is accessible only when a 268/386/486 is in protected mode.
>How does a hard disk cache driver use extended memory on a system running
>MS-DOS?  Does it switch to protected mode?  Do the machines run in
>protected mode all the time?  Neither seems right...What am I missing?

To use extended memory beyond FFFF:FFFF you MUST place the machine in protected
mode. I am unsure of the technique used, but it goes something like this. 
You set a flag/IO port/register (dunno which) which flags the BIOS that you've
switched into protected mode intentionally. Load a dummy LDT, IDT and GDT
do your memory work, then write to a IO port which resets the CPU. This is the
only way out of protected mode on a 286 is to force the CPU to do a reset.
The flag that you left when you entered protected mode tells the BIOS during 
POST that it was all a bad dream and the machine is not to be rebooted. It's
sort of kludgy but it works. I believe this is how int 15 func 87H (move 
extended memory block) and the VDISK driver works... Hope this helps...
Steve

> 

cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/11/90)

In article <9003091838.AA21834@decwrl.dec.com> stoppani@slough.enet.dec.com (Pete Stoppani) writes:
$My understanding is that memory above 1Meg (except for the first
$64k above 1Meg) is accessible only when a 268/386/486 is in protected mode.
$How does a hard disk cache driver use extended memory on a system running
$MS-DOS?  Does it switch to protected mode?  Do the machines run in
$protected mode all the time?  Neither seems right...What am I missing?

   The former is correct.  Programs written for real mode operation
(i.e. 8086 programs) will not run in protected mode for several reasons
(the big one being that segment registers are used completely differently
in protected mode).

   What happens when your disk cache (or ramdrive) needs to access extended
memory is as follows:

- it prepares to switch into protected mode and then does the switch
- it copies the data to/from the appropriate memory locations

   and then, since the 286 has no way to quitely go back into real
mode, the program has to:

- get the keyboard controller to reset the CPU
- restore the status from earlier

   The data has now been transferred to/from extended memory, and the
program can continue to run as usual.

   Note that in the process of resetting the processor (which takes
times on the order of 100 microseconds, I believe), interrupts can be
missed, which is why you should never use a disk cache in extended
memory while using a serial port at high speed (since to achieve
reliable high-speed transmission you need to use interrupts, and you
will miss some).  Disk caches in conventional and expanded memory,
as well as those implemented in hardware on the controller board, are
fine.
-- 
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
          <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
    "So sorry, I never meant to break your heart ... but you broke mine."