Mail Archives: djgpp/1993/01/04/08:57:48
Amazingly enough Robert Morrison said:
>
> At which point I poked around looking for some indication of what an EMS
> emulator does, and where I could turn it on or off. I am trying to run
> this in a DOS window under OS/2. Is this possible?
>
Hmm.... I *thought* this was in the FAQ, but I can't find it mentioned any
where in any of my copies of the docs. Time to put in the FAQ and in the
Unsuported: heading?
Anyway, NO, a dos box under os/2 is not supported. Why? Well... time for
a little history lesson.
> I am relatively new to the 'owning an intel box' scene, and I would like to
> know what VCPI is, what EMS is (expanded memory?), what V86 mode is, and
> an infinite number of other things. Are there any references available that
> could help me out with this stuff? My background is with UNIX boxes at
> university, and an Atari ST for home use. Now I have this lovely 486 thing,
> and I am trying desperately to make it useful. Any helpful comments would
> be appreciated.
When IBM first chose Intel's brain damaged micro controller and build a
microcomputer around it (they realy didn't expect to go over like it did,
I think), the 8086 only had one 'mode.' It had 20 address lines, for a
massive address space of an entire 1 meg, more than anyone would ever need.
Now, when DOS was chosen as the operating system, it only knew how to run
on this mode, and because of the way the hardware addressing scheme works,
all addresses get mapped to 1meg of memory. Applications also only knew
how to work in this way as well.
When memory became tight, some companies developed a method a method of
providing extra memory. Since IBM had chosen everything above the 640k
line to be for memory mapped devices (video card, DMA controllers, etc),
and not all of this 384 k was being in use, a space was chosen to be
used as a buffer (remember, the chip can address this space, but there
usually wasn't much out there). Users would install an Expanded Memory
board, and a device driver. Then software which was written to use
EMS, would use this driver to access this extra memory. Essentially, you
would have some arbitrary amount of memory on the board. If the app
needed to access some memory, it would tell the device driver it needs
access from this area. The driver would then tell the card to transfer
the appropriate memory from the card to the buffer that the computer can
access (this buffer was limited to 64k). It was pretty much up to the app
to keep track of what was in the buffer, and requests updates as necessary.
When the 286 came out, it had two modes: REAL and PROTECTED. Real mode was
essentially the same as the only mode on the 8086 (including only addressing
upto 1meg, even though the 286 had 24 lines for addressing capability up to
16 megs). Protected mode allowed access to more memory, and some amount of
protection between tasks (that is, one program can't write into the memory
of another task, such as the operating system, and muck it up). The problem
is, applications (such as DOS) written to run on 8086 machines would not
run in protected mode and the 286. So, now we have a chance to change
directions. Stick with DOS, and loose much of the capabilities of the 286
and let programs run on all machines, or support only the 286 and later
machines (ie, os/2 1.x). Switching to os/2 (if done correctly) should have
only required recompiling apps (well... some writing of the fancy memory
management stuff for dos, making it much simpler). But, that would requite
companies to produce 2 of everything so they could cover the entire market
(still a lot of 8086/8088 machines out there) and that would be too much
like work. So, the 286 protected mode was never fully utilized. (part
of this, I think, was due to the fact that 286 PM was not really all that
easy to program in, and therefore considered not worth the effort. The
mentality noone (ie joe user) would ever need 16megs was still pretty dominant)
In practice, some use of the extra memory on the 286 was put to use. That
extra memory out there that normal dos couldn't use became known as
Extended Memory. Protocols were develops (int 15h vdisk method, and later
XMS specification) for asking for ways to access this extended memory. EMS
emulators were implemented (it, receive ems request, switch to pm, transfer
the memory to the buffer, back to real mode) but it was slower than accessing
the memory directly with the other protocols. Heck, even EMS drivers were
written that stored the out-of-buffer into on disk, talk about slow bank
switching!!
Some quirks in the 286 were found by various people. There is a command
(undocumented) to access extended memory from real mode, but it was intended
to only be used by people building machines to test memory, I think. Btw,
this same command exists on the 386, though the opcode is different (some
BIOS will trap the illegal instruction fault, though, and then execute the
386 version of the instruction). Quarterdeck, I believe, found a way to
turn on the A20 line (the 21st address line, not normally available to dos)
and discovered that certain address requests get mapped out to the 64k
beyond 1m instead of wrapping around to the beginning of memory like it would
if the a20 line was not turned on (this is the high memory area). From
PM, it was found out you could go into an 8086 emulation mode (I'm not sure
on the details on how this work, only that you could only do it once, and
was how they had the DOS box under os/2 1.x).
Then came out the 386. it's PM was 32-bits (as opposed to the 16 bits
used by all the other chips). 32 address lines (for 4 gigabytes!),
advanced memory management (paging mode, memory mapping, lotsa other
neat gadgets). Again, backwards compatibility was the word of the day.
you had REAL mode which was as brain damaged as the old machines, and
its PM would run 286 PM apps just as well (if not a bit faster) than 286
PM. Also, 386 PM had more functions, so you could write 386 PM apps that
would not run on 286 machines even with out using all the 32 bit
extensions (I think).
One feature that the 386 has is a virtual 8086 mode (v86). This allows
any number of PM tasks to actually pretty well emulate 8086. With fancy
care taken, you can multitask (ala windoze and desqview) dos sessions. The
memory management built into the 386 saves having to do massive memory
copying when switching between task. So, task 1 thinks it has memory
0-1 meg, but it really is using memory 1-2meg, task 2 thinks it has memory
0-1 meg, but it really is using memory 2-3meg, and so on (actually, more to
it than that, but you get the idea). Also, this memory management
capability of the 386 when in v86 mode makes EMS really easy to do. When
a request to transfer memory into the ems buffer is issued, rather than
copying 64k of data, it just changes a few things in the chips memory
management, so when the app tries to access the memory, it is really
accessing this other memory. So, no copying has to take place, much much
quicker. (All of this is part of the paging mechanism the 386 has built in).
So, when you run a EMS manager on a 386, you are running in a v86 task with
paging enabled (ie, qemm386, emm386, 386max, etc).
Now, anothe signifcant difference between the 386 and other machines is the
size of a SEGMENT. All intel chips use a segment:offset addressing scheme.
for real mode memory, you set the segment register to some value, then a
request a memory access with respect to that register value. So, if you
and to access memory at 0x0000000A, you would set the segment pointing to
0x0000, and request 0x000A wrt to that segment. To access 0x00000A00, you
have several choices. Then segment is actually shifted left 8bits and
then added to the offset, so 0x00000A00 can be accessed using
segment:offset
0000:00A0
0001:0090
0002:0080
0003:0070
:
:
000A:0000
Confusing, huh? Each segment can access 64k and they can overlap. Makes
programming confusing sometimes (hence calling the 8086 brain dead). Well,
in 386 PM, the segment can address 4gigs, and the segment register is used
for a different purpose. What a lot of people do is say, 4gig? heck with
segment:offset, I'll just switch to PM, and use just one segment and use
it as a linear address space!!
Problem is, this conflicts with other memory managment techniques (which
segment is qemm using internally? gee, what about dv or windows? what
are they using? problems galore.
Originally, if you wanted to run a PM program (such as autocad 386), you
had to get rid of any v86 drivers (such as memory managers) and reboot,
just to run that program. That's not much fun. So, bunches of people
gotogether, and developed a protocol for doing such with out conflict.
Out came VCPI (virtual control program interface, i think).
While VCPI works fairly well, there are a few problems with it. The
protection mechanism of the 386 is based upon levels (called rings). Ring
0 is most priviledged, and can do most whatever it wants. Ring 3 is least
priviledged. I'm not sure is the different rings actually determine if you
can/cannot execute certain instructions, or just memory access. Anyway, in
VCPI, everything runs in Ring 0.
DPMI (dos protected mode interface) was developed out of resonse to some of
the problems with VCPI (that, and the fact that microslop was upset at not
having been involved in the designing of vcpi and therefore wouldn't use
it for windoze, thus breaking many programs). Unfortunately, DPMI is not
a superset of VCPI, it's completely different. There are also to main
levels of DPMI, 0.9 and 1.0. 1.0 is the published spec (and what is supported
in the dos boxes of os/2, i believe), but windoze only supports 0.9.
Evidently 0.9 doesn't offer all the functionality that is needed to make
go32 work well with it (though I have had discussions with people who say
otherwise, mainly due the the capabilities supported in intel code builder).
Now, dpmi 1.0 is supposed to offer the functionality necessary to make go32
work, but no one has yet had the time to do it. (DJ has often pointed out
that he doesn't own os/2, and I don't know if he uses QEMM so that he can
try out the new QDPMI server (QDMPI does support 1.0, doesn't it QOS guys?)).
Anyway, end of history lesson. If anyone sees any error, please point them
out, I hate passing on incorrect info, but this is correct to the best of my
knowledge.
So, in short, no, djgpp will not work under an os/2 dos box, though I see
no reason why it couldn't be modified to do so (my guess is it would almost
be easier to rewrite the extender from scratch, and then giving the user
the option of running either the vcpi or dpmi version). The problem is
getting someone to do it :->.
There are, I believe, about 3 different ports of gcc to os/2. The most
popular appears to be emx/gcc. emx/gcc can create binaries that will run
under both os/2 and dos (dpmi), but it doesn't offer a lot of the support
for dos that djgpp does (namely graphics, and all the user support). If
you want, I can look up the ftp site for the popular os/2 archive. All
the ports of gcc are there, I believe.
corrections/additions welcomed.
regards,
mrc
--
Mike Castle .-=NEXUS=-. Life is like a clock: You can work constantly
mcastle AT cs DOT umr DOT edu and be right all the time, or not work at all
S087891 AT UMRVMA DOT UMR DOT EDU and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
- Raw text -