At 12:02 AM 3/11/2004 -0300, Alain wrote:
>>>>>>EMM386 will only allocate VCPI memory from the EMS memory pool. Making it >>>>automatically use the XMS memory pool would require backdoor interaction >>>>>>with HIMEM[64] and generally make things quite a bit more complex. >>>>>>Of course, a DOS extender/extended program can still use XMS in addition to VCPI >>>>>>and many of them do. >>>>>I can see aproblem here (or I can have missunderstood): IMHO what will be used a >>>>>lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI >>>>>does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much >>>>>as possible Low-Memory >>>>>for comon programs (EMS takes 64k of UMB)(very often needed). Will this >>>>>configuration work?? >>>>Depends. Some extenders have absolutely no problem allocating from XMS if no VCPI >>>>memory available. >>>For what I learned here, if the machine is not in real mode, which is needed to get >>>UMB, then VCPI is needed. am I wrong? >>No, it's not necessary. UMB's are mapped at startup by the EMM. VCPI is simply an >>interface (the 'I' part of the acronym) with EMM386 to make it, among other things, >>do what you want from V86, aka virtual 8086, mode. V86 is what DOS runs at under >>EMM386 rather than real mode. The EM monitor itself substantially runs in protected >>mode. > >Some cpu instructions _cannot_ be used in V86 mode in i586 machines. So if the >machine _is_ in V86 someone has to control it, ok? that one is VCPI, ok? >So if I need UMB without umbpci, I need to put the machine in V86 mode. What you are >saying is that _some_ dos extenders (but not dos4gw) can do that even without VCPI, >ok? >Sorry, but it looks like I missunderstood something somewhere, this is why I am >re-phrasing most of what you say so that I can see where is my erros ;-) No, the exceptions generated in V86 due to illegal-for-V86-mode instructions transfer back to the EMM which is running protected mode. The EMM can emulate instructions via the exception handler where it is in protected mode and the instructions are legal, if the support for that instruction has been coded in. If the instruction is supported and is performed, the EMM then returns control to the program running in V86 mode after setting the program's instruction pointer past the failing instruction. EMM386 does this with the instructions HLT, and 8- and 16- bit IN or OUT. I just added support in EMM386 for mov eax,cr3 because Microsoft's EMM386 supports that instruction (via emulation) in V86 mode and at least one program out there blithely uses that illegal instruction when it knows it's in V86 mode. Which I find disturbing, but what can you do? UMB's don't have much to do with DOS extenders. I'm not sure I understand what you're asking there. UMB's are extended memory mapped down into DOS memory via the EMM. You allocate and free UMB's via the XMS API. FreeDOS HIMEM's XMS API doesn't support those UMB functions itself, but EMM386 hooks into the XMS allocator chain and adds support for UMB's within its own code. Not the full spec support, but enough to use them. Perhaps later on EMM386 will support full UMB management. VCPI isn't part of UMB's as there is not a VCPI function which controls or uses them, not as anything other than another chunk of memory. Remember that well before VCPI was added to EMM386 this last test release, EMM386 still created UMB's. >>>What is himem+emm386 footprint in memor(low+umb)? >>Don't know. HIMEM conventional memory footprint is low, around 3K(?) someone said a >>while back. EMM386 is growing and definitely higher than that, although most >>internal tables and structures are in high memory outside of pure DOS. I did >>misstate how the NOEMS allocation for UMB's works. Under NOEMS EMM386 allocates >>enough for the current UMB's, plus 32K for VCPI, meaning lower UMB's allocations >>won't increase the minimum VCPI pool size. Right now, EMM386 shuts off VCPI if >>there isn't a minimum 32K for VCPI after UMB allocation, but I'm probably going to >>change that since some programs will work with a zero-sized VCPI pool. >>I think. > >So EMM386 has a small code in memory, _plus_ 32k for the VCPI pool. The diference >seems to be that this 32k are hidden somewhere in MS-EMM386, ok? No, the 32K is from extended memory, just like the standard EMS memory. It gets swiped from the EMS pool, as needed. VCPI and EMS memory are a shared pool. The 32K doesn't affect the DOS conventional memory footprint. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
