🚀 go-pugleaf

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

> 

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

In article <25F9EA26.21884@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes:
>In article <9003091838.AA21834@decwrl.dec.com> stoppani@slough.enet.dec.com (Pete Stoppani) writes:

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

This is not true.  The 286 has an undocumented instruction called LOADALL
that allows use of the protected mode addressing even under real mode.
You don't have to put the chip into protected mode, you merely
change the high, hidden bits of the DS, SS, etc.  from the power-up
zero values.  In fact, it loads, from real address 0x800, every register--
real mode and protected--on the system.

It's rather strange, but it does work.  (Microsoft's ASM doesn't know
about LOADALL, but its CODEVIEW debugger will disassemble it!)

I don't know which products do reset the CPU (as Intel's standard documentation
would leave you to believe is necessary) and which use LOADALL, and I
*sure* don't know why Intel (and for that matter Microsoft, when it comes
to MS-DOS interrupts) puts things in their product that they keep a
secret.

The protected mode bit on the 386 is not sticky.  That is, a task with
the highest level privilege can turn the bit off, causing the processor
to return to real mode.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr

I've been doing some C programming on the IBM PC lately have have run into
a snag.  Unsigned longs do not seem to be supported.  I've changed into the
HUGE mode to get 32 bit int's, but any variables of type unsigned long which
have the high bit set (i.e. would be negative if just longs) do not do the
right thing when used with ">>", "/", or "%".  I've reported this problem
to Borland, but have not gotten a patch/work-around yet.  

Has anyone here run into this problem, and found a workaround other that
coding subroutines to do it the right way?

-Paul Petersen


University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    UUCP:    {uunet,convex}!uiucuxc!uicsrd!petersen
    INTERNET: petersen@uicsrd.csrd.uiuc.edu

This is the original poster.  I recieved mail saying that their versions
of TurboC v2.0 worked correctly.  I was baseing my claim on differences
in output from my programs on different platforms,  unfortunately I 
reported the wrong problem (GIGO, damn CR/LF stupidity) compounded by the
fact that the Turbo-Debugger's Inspect function does not work in the same
way of the TurboC Inspect function.  It's the debugger that treats
unsigned longs as signed longs.   Sorry for jumping to the wrong
conclusion, now back into my hole....

-Paul Petersen


University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    UUCP:    {uunet,convex}!uiucuxc!uicsrd!petersen
    INTERNET: petersen@uicsrd.csrd.uiuc.edu