From: mcastle AT cs DOT umr DOT edu Subject: Re: djgpp under OS/2 To: morrison AT ee DOT ualberta DOT ca (Robert Morrison) Date: Mon, 4 Jan 93 7:32:23 CST Cc: djgpp AT sun DOT soe DOT clarkson DOT edu 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