From: gah@trc.mew.mei.co.jp (Gary A. Hildebrand) Subject: Re: QUESTION about EMM386.exe for Linux dos emulator Date: 18 Feb 1993 05:06:11 GMT
>>>>> "HB" == Howlin' Bob <gt8134b@prism.gatech.EDU> writes:
HB> I'm working on the Linux DOS box thingy, and I've run across a bit of a
HB> thorn while implementing XMS/EMS memory.
[intro deleted]
HB> I have implemented pretty much the full XMS 3.0 specification under the
HB> DOS box, so I can do things like load SMARTDRV into extended memory; load
HB> DOS with "dos=high,umb"; set up a RAMDRIVE; swap 4DOS/NDOS into
HB> extended memory; load drivers high with DEVICEHIGH and LOADHIGH, etc.
HB> Everything goes smoothly and sweetly, and I have the added bonus of being
HB> able to simulate almost any arbitrary amount of extended memory, as Linux
HB> kindly swaps memory to/from disk as necessary.
Are you sure drivers are actually being loaded high? I ask this because,
even though both the HMA and UMB's are supported by the XMS specification,
most XMS-only (read: no EMS support) memory managers do not actually
implement support for UMB's, just for the HMA, which is used when DOS loads
high. At least I could never get a DOS 5.0 session with just
HIMEM.SYS/HIMEM.EXE loaded to successfully high-load device drivers.
Instead, they would be loaded low. And the source code I have for an old
version of HIMEM.SYS would substantiate this.
HB> Since I'm running DOS from a protected mode operating system, but in
HB> virtual 8086 mode, it's a bit touch-and-go deciding exactly what kind
HB> of processor DOS is running under. Some programs report 386, some 286.
HB> Nortun Utilities calls my 486DX33 a 4.77Mhz 80286. EMM386 seems to think
HB> something like this, also.
Most programs should use a variant of the CPU identification code presented
in the Intel 486DX Programmer's Reference Manual. In your emulator code,
are you setting an IOPL of 3 or less for V86 mode? If the IOPL is less
than 3, how you emulate the case of PUSHF/POPF will determine if the
identification code will work or not. Also, properly supporting
coprocessor identification code seems very nasty. By the way, NU 6.0
determines the "CPU type" by doing a benchmark, rather than running
identification code, so it is easily fooled...
HB> Whenever I try to install EMM386.exe by putting "device=c:\emm386.exe"
HB> and any combination of valid switches, it gives me
HB> EMM386 not installed - incorrect machine type.
HB> press any key when ready...
HB> I had rather hoped that, by implementing the XMS interface, in effect
HB> integrating HIMEM.SYS into my "emulator" (DOS box), I had done all the dirty
HB> work and could simply run EMM386 to simulate the atrocious EMS memory
HB> specification. However, as I said, whenever I boot DOS under my Linux
HB> DOS box, it exits with the "incorrect machine type" error.
Implementing full XMS support in your emulator will not make it support
EMM386, for one crucial reason -- you cannot have two virtual 8086 mode
monitors in the machine at the time! Think about it -- your emulator is a
monitor, and EMM386 must also be a monitor, in order to emulate the EMS
window using protected mode virtual memory.
This is how all EMS memory managers for 386+ must work, since there's no
real EMS hardware in the machine. This is also partly why such protocols
as VCPI and DPMI were created, so as to support programs that wish to
engage protected mode while under the control of a memory manager or
operating environment which has engaged V86 mode. You will no doubt have
to provide EMS as well as XMS support directly inside your emulator.
Is the source for your current version of the Linux DOS emulator available
to the masses yet? I bet many would be interested in looking at it,
including me!
Gary