HIMEM.SYS and unreal/flat real mode, EMM386 and UMBs
Haakon Riiser
studying protected mode, someone informed me of the in-between mode
called "unreal" mode, where you basically have real mode with a
4G segment limit, allowing for BIOS calls and access to all memory.
After learning about this, I immediately wondered why there were
some many problems with memory in the old DOS days, so I did some
reading on HIMEM.SYS and EMM386.EXE. From what I've gathered,
they worked like this:
EMM386.EXE: Runs the PC in protected mode, and makes DOS a
virtual-8086 mode task. Uses paging to map memory into the
memory area between 640K and 1M, and emulates EMS by paging
memory from beyond 1M into a fixed 16K area below 1M.
HIMEM.SYS: Enables the A20 line so that the traditional
16-bit SEGMENT:OFFSET addresses can access the HMA, which is
64K - 16 bytes beyond the 1M barrier, and allowing DOS itself
to use this area, freeing almost 64K of conventional memory.
Also, many people say that HIMEM.SYS also enables "unreal"
mode on 80386 and later CPUs.
I only have one question concerning EMM386: Why do we need
paging to access the UMBs? The unused parts in 640K - 1M are
addressable even on an 8086, so I'd expect drivers to be able to
load themselves into this area without EMM386.
What puzzles me the most is HIMEM.SYS's unreal mode. Back in the
old DOS days, I always thought that HIMEM.SYS was rather useless,
because all games (before DOS extenders like DOS4G became common)
that required lots of memory would require EMS. I thought that
HIMEM.SYS provided XMS memory, which was even more cumbersome than
EMS, and that was why nobody used it. But now that I know about
unreal mode, I can't imagine why anyone would even _consider_
using the stupid EMS memory. It couldn't have been backwards
compatibility, because EMM386 obviously requires 80386 or later.
It _certainly_ couldn't have been because EMS was more practical,
it only being able to access memory in pitiful 16K chunks (and
you probably had to use an INT function to swap pages, right?).
The most likely explanation would seem to be that people weren't
aware of unreal mode, but even that seems unlikely if it was
supported by the ubiquitous HIMEM.SYS. Does anyone know what the
reason was?
Thanks in advance for any help in understanding this.
--
Haakon
Alex Russell
or ems gave you access to more memory which while slow compared to
protected mode was a lot faster than the hard-drive.
When protected mode wrappers and dpmi became available a lot of dos
games used that.
Part of it was also a lack of tools - there simply were not many good
protected mode compilers around, and programmer ignorance. I used XMS
for a commrecial project back in 1988 simply because I could get it to
work as a fast disk cache and still use all the DOS code and tools we
already had.
Alex Russell
Herman Dullink
> paging to access the UMBs?
However, to be able to use it as UMB, there has to be actual RAM
at that location. On PC/XTs, it was usually an EMS card that provided
the RAM. On PC/ATs, it was usually the chipset that provided the RAM.
But if your (386) system couldn't provide the RAM, you could use the
Emm386 option to emulate it. Emm386 (and simlars) use paging to map
extended (XMS) memory to the UMB location.
> I thought that HIMEM.SYS provided XMS memory, which was even more
> cumbersome than EMS, and that was why nobody used it.
XMS memory is both UMB and extended memory, and it managed by e.g.
HIMEM.SYS as the standard DOS memory manager only manages the 640KB
of normal PC/XTs.
As extended memory is not available on PC/XT, but EMS is (with additional
hardware), a program that uses EMS will work on any PC that can somehow
provide EMS memory (hardware or emulation).
Extended memory is native for 286 and up, and requires a native 286
(protected
mode) application to use the full potential.
DOS is not a native 286 operating system, but earlier versions of OS/2, Unix
and Windows are. For a DOS application to fully use extended memory,
you need to use protected mode. The DPMI was created to simplify the
use of protected mode for DOS applications, and DOS extenders take care
of all that's required to provide DPMI.
With a few exceptions, all DOS applications on 286 and newer systems that
use extended memory use XMS. RAMDrive and SmartDrive use XMS for
their data store. DPMI use XMS for normal memory allocations. Emm386
use XMS memory to be mapped in the UMB and EMS location(s).
Windows 3.x uses all free XMS memory for its own memory management.
> But now that I know about
> unreal mode, I can't imagine why anyone would even _consider_
> using the stupid EMS memory.
Only if you wanted to be compatible with the PC/XT (DOS versions
of spreadsheats and databases).
Or... wanted to program a non-protected mode application, and needed
a quick mechanism to swap data to/from a data store. Swapping EMS
is often faster than copying from extended memory.
But indeed, if you've set your minimum platform to anything that has
extended memory, then that platform supports protected mode, and
DPMI would be a much more logical choice.
> It couldn't have been backwards
> compatibility, because EMM386 obviously requires 80386 or later.
Emm386, yes. But that's an emulator. EMS can be available on any
system.
> The most likely explanation would seem to be that people weren't
> aware of unreal mode
More likely, people were aware that to be compatible with older
systems, you couldn't use newer features specific to newer hardware.
H
Haakon Riiser
> Haakon Riiser wrote:
>> [...] I thought that HIMEM.SYS provided XMS memory, which was
>> even more cumbersome than EMS, and that was why nobody used it.
>> But now that I know about unreal mode, I can't imagine why anyone
>> would even _consider_ using the stupid EMS memory. [...]
>>
> It was very difficult to make dos calls outside of real mode. Using xms
> or ems gave you access to more memory which while slow compared to
> protected mode was a lot faster than the hard-drive.
OK, just to clarify: XMS memory -- provided by HIMEM.SYS -- is _not_
simply a name for all memory beyond 1M that became available as a
result of entering unreal mode? Was XMS also an emulation of some
older form of memory management that was supposed to be compatible
with pre-386 computers? I ask because addressing memory in the
unreal mode-way should be, as far as I can see, as fast as protected
mode:
; Assume that the DS segment base is 0, and that the limit is 4G,
; thanks to unreal mode.
MOV EAX, 8000000h
MOV EDX, [EAX] ; read dword at memory offset 128M
There are no DOS calls involved to access extended memory in this way.
> When protected mode wrappers and dpmi became available a lot of dos
> games used that.
Yes, and that's why I did't understand why people didn't use the
unreal/flat real mode more often. (I now know of _one_ game that
did -- Ultima 7.) In fact, unreal mode should be even faster
than protected mode, since you don't have to swap in/out of
protected mode to use the BIOS, and memory is flat, just like in
protected mode.
IMO, the only downside to unreal mode is that you can't run the
program under EMM386 or Windows 9x. The former shouldn't matter
much, since EMS was crap compared to flat memory, and Windows 9x
didn't even exist at the time when this mattered.
> Part of it was also a lack of tools - there simply were not many good
> protected mode compilers around, and programmer ignorance. I used XMS
> for a commrecial project back in 1988 simply because I could get it to
> work as a fast disk cache and still use all the DOS code and tools we
> already had.
One more question if XMS, like EMS, was some emulation of legacy
hardware. Exactly how did it work? Did you use software interrupt
functions (INT xxh) to swap pages into the UMA like in EMS?
--
Haakon
Haakon Riiser
>> I only have one question concerning EMM386: Why do we need
>> paging to access the UMBs?
>
> For accessing, you don't. It's addressable. UMB are available on
> any PC. However, to be able to use it as UMB, there has to be
> actual RAM at that location.
But all 386s had more than 1 MB of memory. The parts of the UMA
that wasn't hidden by external hardware or ROMs should still map
into the RAM, right? Shouldn't drivers be able to load themselves
into these "natural" UMBs directly, without needing some program
to page in memory from outside the 1M barrier?
By the way; I think I can see one place where EMM386 would be
able to help with the UMBs: It can use paging to put UMBs in
places that would otherwise be hidden by hardware you don't use.
> But if your (386) system couldn't provide the RAM, you could use the
> Emm386 option to emulate it. Emm386 (and simlars) use paging to map
> extended (XMS) memory to the UMB location.
Ah, so you didn't need EMM386 on all systems? It was there to
provide the UMBs for broken systems that hid _all_ memory in the UMA
range, even though there was no hardware to claim it? Could you use
LOADHIGH and DEVICEHIGH on these systems without running EMM386?
>> I thought that HIMEM.SYS provided XMS memory, which was even more
>> cumbersome than EMS, and that was why nobody used it.
>
> XMS memory is both UMB and extended memory, and it managed by e.g.
> HIMEM.SYS as the standard DOS memory manager only manages the
> 640KB of normal PC/XTs. As extended memory is not available on
> PC/XT, but EMS is (with additional hardware), a program that uses
> EMS will work on any PC that can somehow provide EMS memory
> (hardware or emulation). Extended memory is native for 286 and
> up, and requires a native 286 (protected mode) application to use
> the full potential.
Did the unreal mode trick also work with the 286, or did you have to
use protected mode to get flat memory addressing?
> DOS is not a native 286 operating system, but earlier versions of
> OS/2, Unix and Windows are. For a DOS application to fully use
> extended memory, you need to use protected mode. The DPMI was
> created to simplify the use of protected mode for DOS
> applications, and DOS extenders take care of all that's required
> to provide DPMI.
So DOS extenders used protected mode and handled the pmode/realmode
switch required for BIOS calls. I know that DOS extenders
worked even under EMM386/Windows 9x, giving it a benefit over
unreal mode (but probably with a performance penalty). But do
you know how DOS extenders are able to function in virtual-8086
mode? Do they detect that the CPU is in virtual-8086 mode, and
therefore only sets up the local descriptor table (leaving the
global and interrupt descriptor tables alone), and then uses 386
task switching to be able to work with EMM386/Windows?
> With a few exceptions, all DOS applications on 286 and newer
> systems that use extended memory use XMS. RAMDrive and SmartDrive
> use XMS for their data store.
>
> DPMI use XMS for normal memory allocations. Emm386 use XMS memory
> to be mapped in the UMB and EMS location(s). Windows 3.x uses all
> free XMS memory for its own memory management.
Does XMS, like EMS, refer to a particular way of accessing memory,
as opposed to "extended memory" which simply means "memory beyond 1M"?
I know it's an acronym for Extended Memory Specification, but I
don't know what the specification says.
>> But now that I know about unreal mode, I can't imagine why anyone
>> would even _consider_ using the stupid EMS memory.
>
> Only if you wanted to be compatible with the PC/XT (DOS versions
> of spreadsheats and databases). Or... wanted to program a
> non-protected mode application, and needed a quick mechanism to
> swap data to/from a data store. Swapping EMS is often faster than
> copying from extended memory.
I don't understand the last sentence. With unreal mode, you could
use _all_ memory the same, it wouldn't matter if it was below or
above 1M, right? Why would you need to copy from extended memory
into conventional memory?
> But indeed, if you've set your minimum platform to anything that
> has extended memory, then that platform supports protected mode,
> and DPMI would be a much more logical choice.
Yes, but I accept that DOS extenders such as DPMI didn't happen
right away, since it probably had to deal with task switching
and stuff that was a little messy.
But unreal mode (which is what my question was mostly about) is
so ridiculously simple that it should have been taken advantage
of for all games in the early 90s that would run too slowly on
286s anyway.
>> It couldn't have been backwards compatibility, because EMM386
>> obviously requires 80386 or later.
>
> Emm386, yes. But that's an emulator. EMS can be available on any
> system.
Right, but games like Wing Commander 2 required EMS, and these
games would run slow even on a 386, so who cared if a 286 could
run it. In this case, it had to be ignorance. :-) Especially
since it was Origin that created this game (in 1991), i.e. the
same company that later (1993) created Ultima 7, which is the
only game I know of that runs in unreal mode.
--
Haakon
Alex Russell
> [Herman Dullink]
>
>
>>>I only have one question concerning EMM386: Why do we need
>>>paging to access the UMBs?
>>
>>For accessing, you don't. It's addressable. UMB are available on
>>any PC. However, to be able to use it as UMB, there has to be
>>actual RAM at that location.
>
>
> But all 386s had more than 1 MB of memory. The parts of the UMA
> that wasn't hidden by external hardware or ROMs should still map
> into the RAM, right? Shouldn't drivers be able to load themselves
> into these "natural" UMBs directly, without needing some program
> to page in memory from outside the 1M barrier?
Not true. 386's were indeed sold with !mb or even 640Kb.
The memory from 640Kb to 1Mb is reserved for hardware under DOS. DOS
will only let a program allocate and use RAM under 640Kb. Drivers could
be squeezed in between 1Mb and 640Kb if they were well written.
>
> By the way; I think I can see one place where EMM386 would be
> able to help with the UMBs: It can use paging to put UMBs in
> places that would otherwise be hidden by hardware you don't use.
>
>
>>But if your (386) system couldn't provide the RAM, you could use the
>>Emm386 option to emulate it. Emm386 (and simlars) use paging to map
>>extended (XMS) memory to the UMB location.
>
>
> Ah, so you didn't need EMM386 on all systems? It was there to
> provide the UMBs for broken systems that hid _all_ memory in the UMA
> range, even though there was no hardware to claim it? Could you use
> LOADHIGH and DEVICEHIGH on these systems without running EMM386?
emm386 was to provide emulation for EMS HARDWARE. ems was a hardware
solution when it forst came out. After the 386 wsa released and
computers shipped with more than 640Kb it became possible to emulate ems
with a driver using ram above 1Mb.
loadhigh and devigh high require himem.dos and emm386. If you are
running under DOS the memory above 1Mb is not available at all to any
program or driver. the himem.sys and emm386 driver used protected mode
to handle ram, and emulated real mode (v86 mode) for the dos programs.
Dos extenders run in protected mode, run protected mode code, and use
their own library to emulate int21 call, or drop down to real mode for
int21 calls. the dos extender places the cpu in protected mode when it
loads up the exe. Different extenders used different techniqes.
You had to use a compiler that generated protected mode code to use a
dos extender.
>
>
>>With a few exceptions, all DOS applications on 286 and newer
>>systems that use extended memory use XMS. RAMDrive and SmartDrive
>>use XMS for their data store.
>>
>>DPMI use XMS for normal memory allocations. Emm386 use XMS memory
>>to be mapped in the UMB and EMS location(s). Windows 3.x uses all
>>free XMS memory for its own memory management.
>
>
> Does XMS, like EMS, refer to a particular way of accessing memory,
> as opposed to "extended memory" which simply means "memory beyond 1M"?
> I know it's an acronym for Extended Memory Specification, but I
> don't know what the specification says.
xms uses the himem.sys driver to copy data to/from memory above/below
1Mb by switching to protected mode to copy the data, then going back to
real mode to continue on running the dos program. Theis switching to
protected mode and back to real mode is what makes xms so slow.
>
>
>>>But now that I know about unreal mode, I can't imagine why anyone
>>>would even _consider_ using the stupid EMS memory.
>>
>>Only if you wanted to be compatible with the PC/XT (DOS versions
>>of spreadsheats and databases). Or... wanted to program a
>>non-protected mode application, and needed a quick mechanism to
>>swap data to/from a data store. Swapping EMS is often faster than
>>copying from extended memory.
>
>
> I don't understand the last sentence. With unreal mode, you could
> use _all_ memory the same, it wouldn't matter if it was below or
> above 1M, right? Why would you need to copy from extended memory
> into conventional memory?
He is talking about ems and xms, not unreal mode.
>
>
>>But indeed, if you've set your minimum platform to anything that
>>has extended memory, then that platform supports protected mode,
>>and DPMI would be a much more logical choice.
>
>
> Yes, but I accept that DOS extenders such as DPMI didn't happen
> right away, since it probably had to deal with task switching
> and stuff that was a little messy.
>
> But unreal mode (which is what my question was mostly about) is
> so ridiculously simple that it should have been taken advantage
> of for all games in the early 90s that would run too slowly on
> 286s anyway.
Not all dos services could be safely called (there is some dos code that
assumes pointers will wrap at 64Kb boundries), you had to disable em386
if it was loaded, and it used a hack.
It was a pretty fragile way to get at all memory.
>
>
>>>It couldn't have been backwards compatibility, because EMM386
>>>obviously requires 80386 or later.
>>
>>Emm386, yes. But that's an emulator. EMS can be available on any
>>system.
>
>
> Right, but games like Wing Commander 2 required EMS, and these
> games would run slow even on a 386, so who cared if a 286 could
> run it. In this case, it had to be ignorance. :-) Especially
> since it was Origin that created this game (in 1991), i.e. the
> same company that later (1993) created Ultima 7, which is the
> only game I know of that runs in unreal mode.
>
Some of it was ignorance. It took a while for programmers to learn all
the tricks you could do with a 386. There was no internet. You had to
buy magazines, scour books and articles, join user groups and bbs's to
get some of this information.
Alex Russell
Haakon Riiser
>> But all 386s had more than 1 MB of memory. The parts of the UMA
>> that wasn't hidden by external hardware or ROMs should still map
>> into the RAM, right? Shouldn't drivers be able to load
>> themselves into these "natural" UMBs directly, without needing
>> some program to page in memory from outside the 1M barrier?
>
> Not true. 386's were indeed sold with !mb or even 640Kb. The
> memory from 640Kb to 1Mb is reserved for hardware under DOS. DOS
> will only let a program allocate and use RAM under 640Kb. Drivers
> could be squeezed in between 1Mb and 640Kb if they were well
> written.
But DOS couldn't enforce anything like this by itself, so it would
have to be a hardware problem. I searched for more information
on this subject, and indeed that turned out to be true. There
was a program that enabled access to UMBs without paging and
virtual 8086 mode:
http://www.uwe-sieber.de/umbpci_e.html
Here's an excerpt:
UMBPCI makes UMBs from disabled memory that is intended as
Shadow-RAM. UMBPCI enables this memory and disables its write
protection. It needs only 240 Bytes of low memory, that's all!
EMM386 works on all machines with 386 cpu or higher and provides
usually more UMBs than UMBPCI but it creates the UMBs from
the computer's physical XMS (eXtended Memory Specifications)
by virtually remapping XMS to the upper memory area using the
Memory Management Unit (MMU) of 386 and higher CPUs. It needs
an additional 150 KB of XMS, 4 KB of low memory and 7 KB of UMA
(Upper Memory Area) when loaded, and it also switches the CPU
into "protected mode" (slower) because it's necessary to use the
MMU. DOS then runs in virtual 8086 machine [...]
This makes sense -- the only reason the UMBs couldn't be used
without EMM386 was that the available regions were, by default,
write-protected. Turn that off, and EMM386 is no longer required.
(Unless you need EMS or you want to be able to map UMBs into active
regions such as the monochrome framebuffer at B000:0000h.)
>> Ah, so you didn't need EMM386 on all systems? It was there to
>> provide the UMBs for broken systems that hid _all_ memory in the UMA
>> range, even though there was no hardware to claim it? Could you use
>> LOADHIGH and DEVICEHIGH on these systems without running EMM386?
>
> emm386 was to provide emulation for EMS HARDWARE. ems was a hardware
> solution when it forst came out. After the 386 wsa released and
> computers shipped with more than 640Kb it became possible to emulate ems
> with a driver using ram above 1Mb.
Yes, I know about that; EMS was never the question. I used to
load EMM386 just to get access to the UMBs. By saying
DEVICE=C:\DOS\EMM386.EXE NOEMS
you got UMBs without wasting memory on the EMS page frame.
>> Does XMS, like EMS, refer to a particular way of accessing memory,
>> as opposed to "extended memory" which simply means "memory beyond 1M"?
>> I know it's an acronym for Extended Memory Specification, but I
>> don't know what the specification says.
>
> xms uses the himem.sys driver to copy data to/from memory above/below
> 1Mb by switching to protected mode to copy the data, then going back to
> real mode to continue on running the dos program. Theis switching to
> protected mode and back to real mode is what makes xms so slow.
That explains why EMS was more popular than XMS, at least in games.
Since EMS was emulated with paging, the memory never had to be
moved around, only the page table had to be updated, and thus it
would be faster than XMS which has to copy. (Which was exactly
what the other poster was talking about in that earlier message
I didn't fully understand. :-)
Btw, with XMS, could you copy extended memory into a random
location below 640K, or was there a fixed page like with EMS?
Could you control the amount of memory per copy operation?
>> Right, but games like Wing Commander 2 required EMS, and these
>> games would run slow even on a 386, so who cared if a 286 could
>> run it. In this case, it had to be ignorance. :-) Especially
>> since it was Origin that created this game (in 1991), i.e. the
>> same company that later (1993) created Ultima 7, which is the
>> only game I know of that runs in unreal mode.
>
> Some of it was ignorance. It took a while for programmers to learn
> all the tricks you could do with a 386. There was no internet. You
> had to buy magazines, scour books and articles, join user groups
> and bbs's to get some of this information.
True. I tend to forget how much easier these things have become
thanks to the internet, which I take for granted in the same way
as electricity and water. :-) Thanks for all your help so far.
It's been fun to finally learn the truth about these things
that were completely arcane 15 years ago. :-)
--
Haakon
Heinz-Dietrich Saupe
Some years ago, from 1997/1998 to 1999/2000 I built an emulation of LOADALL
for modern cpus. LOADALL was implemented in the mask of the 80286 and
allowed to use the memory above 2^20+2^16-16 (overadressed 20Bit address
space) for real mode adressing. The meaning is, that RM code could (and can)
be executed in the memory above the (pseudo-)limitation.The reason ist,
that not the segment registers hold the real segment values, but the segment
register caches. You just have to take care not too update the segment
register caches.
In the 80386 and some 80486 plus some 386 derivatives called 80486SL etc.
(Cyrix, IBM) LOADALL was included in the cpu mask.You can find more about
LOADALL in www.x86.org and using some search engines.
LOADALL was the only way to access the memory above the RM limitation,
remember, the 80286 had only 16/20 Bit registers.
Why do I communicate history?
I strongly believe, that INTEL and Microsoft had a masterplan for the
future, which included hardware and software architectures. A lot of
different and other architectures and technologies were possible, but
considered not profitable enough.
Here is the answer to your question: real mode and big real mode (thats your
flat mode) were not considered profitable and development passed to
protected mode. Thats all.
Herman Dullink
> that wasn't hidden by external hardware or ROMs should still map
> into the RAM, right?
> Shouldn't drivers be able to load themselves
> into these "natural" UMBs directly, without needing some program
> to page in memory from outside the 1M barrier?
Yes, and they do (or did, many years ago). Even on PC/XT systems.
Plenty of them on the internet. But beware, these drivers are very
hardware specific. It often requires access to a few chipset registers.
> By the way; I think I can see one place where EMM386 would be
> able to help with the UMBs: It can use paging to put UMBs in
> places that would otherwise be hidden by hardware you don't use.
Yes, like the 64KB address range for EGA/VGA hardware at
address 0A0000h on a server which uses textmodes only.
I know of old systems with 736KB conventional RAM and 224KB
of UMB.
> Ah, so you didn't need EMM386 on all systems?
Correct. UMB were available on PC/XT, and Emm386 doesn't run
on 8088 systems :-)
> It was there to
> provide the UMBs for broken systems that hid _all_ memory in the UMA
> range, even though there was no hardware to claim it?
Or.. no driver to drive the hardware, or.. no experienced user to install
the driver..
> Could you use
> LOADHIGH and DEVICEHIGH on these systems without running EMM386?
Sure, my XT has 768KB RAM, 640KB conventional, 256KB UMB. No
extended memory of course, so DOS isn't loaded high.
I will explain more later.
> Did the unreal mode trick also work with the 286, or did you have to
> use protected mode to get flat memory addressing?
unreal mode trick uses 32-bit addressing. The 286 is a 16-bit CPU
and doesn't has 32-bit addressing.
> So DOS extenders used protected mode and handled the pmode/realmode
> switch required for BIOS calls.
<snip>
> But do
> you know how DOS extenders are able to function in virtual-8086
> mode?
DOS programs which use a DOS extender are basically DPMI
programs. The DOS emulation part of protected mode operating systems
such as Windows and OS/2 (and Linux?) and protected mode drivers
such as Emm386 will provide this interface for those DOS programs.
Using the DPMI interface, a DOS program can switch from a V86 task
to a 'normal' task, and fully use the potential of protected mode.
The DOS extender is the first part of the DPMI program that runs.
If it detects that DPMI is already available it simply starts the rest of
the
program.
Otherwise, it'll install it's own DPMI. To do this, it has to check the
configuration. E.g. memory. If Himem is installed, it will use the XMS
interface for memory allocations. If nothing is installed, it will use
the BIOS. Sometimes, an interface called VCPI has to be used.
> Does XMS, like EMS, refer to a particular way of accessing memory,
XMS is an interface to manage other memory than the conventional.
How you access it is up to you. Of course, the actual location might limit
the posibilities :-)
XMS is an extendible interface. UMB drivers (and Emm386) will add
UMB memory to this interface. Himem.sys only does extended memory
and the HMA.
Because my UMB driver is loaded first, I can DEVICEHIGH Himem.sys
and Emm386.exe (if I need EMS memory).
> > Swapping EMS is often faster than
> > copying from extended memory.
> I don't understand the last sentence.
Many of these programs were designed to run on 286 systems too.
These systems could not do 32-bit addressing. To use extended
memory, you have to use protected mode. The BIOS and the
XMS interface provide functions for normal DOS program to
quickly enter protected mode and copy data to/from extended
memory.
Many of these programs use EMS and XMS memory as
a RAM drive. For EMS to get a certain block, it simply
paged in (hardware or emulation) the block. For XMS,
it had to copy from extended memory to conventional.
> But unreal mode (which is what my question was mostly about) is
> so ridiculously simple that it should have been taken advantage
> of for all games in the early 90s that would run too slowly on
> 286s anyway.
Only on systems which don't run in protected mode (ie. not have
Emm386 loaded and active). The unreal mode is not compatible
with many DOS configurations, but 32-bit DPMI is.
If you want your program to be compatible, DPMI is the way
to go. It's also supported by many HLL compilers.
H
Haakon Riiser
> Some years ago, from 1997/1998 to 1999/2000 I built an emulation of LOADALL
> for modern cpus. LOADALL was implemented in the mask of the 80286 and
> allowed to use the memory above 2^20+2^16-16 (overadressed 20Bit address
> space) for real mode adressing. The meaning is, that RM code could (and can)
> be executed in the memory above the (pseudo-)limitation.The reason ist,
> that not the segment registers hold the real segment values, but the segment
> register caches. You just have to take care not too update the segment
> register caches.
>
> In the 80386 and some 80486 plus some 386 derivatives called 80486SL etc.
> (Cyrix, IBM) LOADALL was included in the cpu mask.You can find more about
> LOADALL in www.x86.org and using some search engines.
I read all about this at x86.org just now -- all of it very
interesting. This section, however, was strange:
"Unlike the 286 LOADALL, the 386 LOADALL is still an Intel top
secret. l do not know of any document that describes its use,
format, or acknowledges its existence. Very few people at
Intel wil1 acknowledge that LOADALL even exists in the 80386
mask. The official Intel line is that, due to U.S. Military
pressure, LOADALL was removed from the 80386 mask over a year
ago. However, running the program in Listing-2 demonstrates
that LOADALL is alive, well, and still available on the latest
stepping of the 80386."
Why should Intel be more secretive about the 386 LOADALL than the
286 one? If I understood the text correctly, LOADALL was only
really useful on the 286 since the 286, unlike the 386, couldn't
leave protected mode without a CPU reset. I didn't see any point
in using LOADALL for the 386 when you could more easily do the same
(that is, enter flat real mode) with documented instructions.
And the part where Intel lies about having removed the 386 LOADALL
because of pressure from the U.S. Military was really strange.
Why would the military care about this?
> Why do I communicate history?
>
> I strongly believe, that INTEL and Microsoft had a masterplan for the
> future, which included hardware and software architectures. A lot of
> different and other architectures and technologies were possible, but
> considered not profitable enough.
>
> Here is the answer to your question: real mode and big real mode (thats your
> flat mode) were not considered profitable and development passed to
> protected mode. Thats all.
Thanks.
--
Haakon
Haakon Riiser
>> Did the unreal mode trick also work with the 286, or did you have
>> to use protected mode to get flat memory addressing?
>
> unreal mode trick uses 32-bit addressing. The 286 is a 16-bit CPU
> and doesn't has 32-bit addressing.
Yes, but now that I've read about the secret LOADALL instruction,
I know that it was possible to do something similar to 386 unreal
mode. The 286's unreal mode, if you will. :-) Correct me if I'm
wrong about any of the following:
The 286 had 24 address lines, i.e. 16 MB of addressable memory,
but still used 16-bit registers, so it could never access all of
it as one flat 16 MB chunk, even in protected mode. Using the
LOADALL instruction, it was possible to load the hidden segment
descriptor registers (in real mode) so that the segment bases
pointed outside the 1M barrier. This is just like 386 unreal
mode, except that you still can't have flat memory because offset
registers are still 16-bit.
>> But do you know how DOS extenders are able to function in
>> virtual-8086 mode?
> DOS programs which use a DOS extender are basically DPMI
> programs. The DOS emulation part of protected mode operating systems
> such as Windows and OS/2 (and Linux?) and protected mode drivers
> such as Emm386 will provide this interface for those DOS programs.
> Using the DPMI interface, a DOS program can switch from a V86 task
> to a 'normal' task, and fully use the potential of protected mode.
>
> The DOS extender is the first part of the DPMI program that runs.
> If it detects that DPMI is already available it simply starts the
> rest of the program. Otherwise, it'll install it's own DPMI. To
> do this, it has to check the configuration. E.g. memory. If Himem
> is installed, it will use the XMS interface for memory
> allocations. If nothing is installed, it will use the BIOS.
Thanks, I think even more pieces of the puzzle fell into place now:
The DOS extended program will allocate memory via the first
available memory interface in this ordered list:
DPMI, VCPI, XMS, and finally BIOS
It allocates memory via one of these interfaces so that the
respective memory manager can give it unused areas of memory,
and thus it will not come into conflict with other applications
in a multitasking system, since they, too, manage their memory
by the same interface. But being in protected mode, the DOS
extended program does not need to _access_ the memory via slow
legacy interfaces such as XMS. All it needed was to _reserve_
memory in a way that other applications could agree with.
> Sometimes, an interface called VCPI has to be used.
Yes, I just read about this as well. IIRC, this was an alternative
to Microsoft's DPMI that was used by Quarterdeck's well known QEMM
program, and the main difference between VCPI and DPMI was that
VCPI programs ran in privilege level 0, which was not acceptable to
Microsoft which required that applications should run in privilege
level 3 so that they are protected from each other.
--
Haakon
Heinz-Dietrich Saupe
National security is more important then some dollars. LOADALL may have been
used für quality check after production. I`ll tell you more in the lines
below (in my next comment.)
"Haakon Riiser" <hak...@fys.uio.no> schrieb im Newsbeitrag
news:slrncjkg3a...@s.hn.org...
Heinz-Dietrich Saupe
the industry at this point: Windows 95 and Windows 98, 98 SE, 98 ME were
DPMIs with GUIs. Even the professional versions can not deny their roots in
DOS. Windows 95 and Windows 98 were even not operating systems, asWindows 2,
2.x, 3, 3.x were not operating systems, Windos NT, 2000 and XP we can
discuss. (I do not pretend, that they are operating systems.)
Linux is not based on dpmi, its a completely new OS with some elements of
DOS, specially for compatibillity reasons. The big difference is, that it is
a real multitasker, which was built from the scratch.
We also should take a close look at memory management. I want to start a
small provocation with my first thesis:
1. No memory access is faster, then direct memory access.
2. No memory access promises easier handling, then linear real memory
addresses.
Consequety protected mode access is always SLOWLIER then real mode access,
because real addresses do not have to be calculated. You dont believe it?
Just write a small program to verify or falsify my thesis. And, because this
is a msdos forum I suggest to check EMS and XMS first, and then the
extenders. I did all of that and I know the data.
Let me tell you, that using some intelligent memory access under LOADALL
allowed me to arrive at streaming 1.1 GByte/sec. on a cheap PC100 board with
SiS 620 chipset plus a PIII-600 Coppermine. I did not use any memory
managers with the exception of my emulation of LOADALL, of course.
Eric
Haakon, I havnt read all the followup posts but in unreal mode there is a
problem: if you do a far jump or anything that modifies the Cs registe the
old 64k segment limit is applied. so that mean you are effectively limited
to only executing code below 1 meg. Gobs of data can still be placed above
1 meg but code is limited. all it takes is an interrupt and CS reverts back
to 64k limit and ip is always going to be following along with CS
unreal mode is an undocumented (read "unsupported") mode and is actually a
result of a bug in Intel cpu's, so you couldnt count on it being in the
next release of CPU's. That meant that maybe you write a giant killer app
that relies on unreal mode for say the P2 and then Intel does away with
unreal mode on P3 (next generation) and now you're in a real bind. Your
entire app needs to be re-written to use standard protected mode.
Thats why it wasnt used very often.
All in all, its extremely useful, but "buyer beware"
Eric
Heinz-Dietrich Saupe
I am sorry to tell you, that you are wrong. You can use more then 1 MB for
code, but (!!!!!) you have to CALL the code above 2^20+2^16-16. - JMPs etc.
adjust the segment CS-cache. (Alternatively you nay try to adjust the
segmentregister-cache after jumping.) Didn't you read my posting dated 4th
of Sept, 2004, 22:33?
Martin Str|mberg
> [Herman Dullink]
>> Sometimes, an interface called VCPI has to be used.
> Yes, I just read about this as well. IIRC, this was an alternative
> to Microsoft's DPMI that was used by Quarterdeck's well known QEMM
> program, and the main difference between VCPI and DPMI was that
> VCPI programs ran in privilege level 0, which was not acceptable to
> Microsoft which required that applications should run in privilege
> level 3 so that they are protected from each other.
VCPI is what EMM386.EXE provides to let extenders switch to protected
mode.
Right,
MartinS
Eric
You know.... i had set a very special reminder to "read Mr Saupe's post of
Sept 2004" but i just never got around to it. You have my deepest and most
sincere apologies. Sometimes I'm just such a fucking failure.
Oh well...
As i said in my post, Anything that changes CS will reset its internal
segment limits. But i'm sure you read that right Mr Saupe?
Thanks so very much
Yours in code,
Eric
Heinz-Dietrich Saupe
by a call, but the segment cache is not.
You better forget Intel`s statements of segments.
"Eric" <notV...@comcast.net> schrieb im Newsbeitrag
news:kJ70d.15388$D%.1025@attbi_s51...