Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing
Hi Michael, 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? Unfortunately, DOS/4GW, now crowned That Annoying Extender Which Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that out and am not sure whether it's due to no memory in VCPI pool, missing EMS page frame, or something else. NOEMS is pretty badly broken in the EMM386 version out there anyway, but I've fixed it up some for next patch release. Now NOEMS allocates up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K for a VCPI pool, more if you have fewer UMB's. What is himem+emm386 footprint in memor(low+umb)? The DOS/4GW problem does need to be addressed since it's most popular extender out there and a lot of legacy applications use it. Agreed ;-) I'm thinking maybe if the residual EMS left-over after UMB allocation is too low, I'll have EMM386 by default grab a hunk of XMS memory at startup to keep for as VCPI pool. Biggest hurdle is that this behavior is not the most friendly use of memory. And if I do that, I'll need to slightly modify HIMEM again to increase default handles, since it's already pretty low without EMM386 grabbing memory. What would you think about an EMM386 that decided to steal some of your XMS memory at startup, just in case a VCPI-using program wanted it later on? I mean, the memory might never be needed if nothing ran which used VCPI, it would just be gone. Proper settings would need some type of command line parameter control, but we really need is a basic default for the general Joe and Joyce User who simply sticks NOEMS in there and still expects their DOS-extended to run with a DOS extender or related protected mode application than can't fallback to XMS allocation. I think that we should consider a bit who is Averege-Joe and what machine he may get. 1) if he has no knwledge of dos at all (just a mouse-clicker) and is just testing, he has a powerfull machine and will not care as long as everything runs. For him a good installer is the most important thing. 2) for an old-time DOS user that is really using FreeDOS to run old programs (like Clipper systems) he has at least 4Mb of memory. In this case it FreeDOS should a) run just out-of-the-box and b) could be optimised later if this is really needed 2) for small enbedded systems, anything will be highly optimised and this Joe has the knwledge to do it. So here default are not a problem. SO: default values should have any value that make the system work smoothly. It just ocurred to me that these values could be dependant on the total amount of memory found in the machine. MS-DOS has this in many places. This way if there is at least 4Mb, a little more in various tables is wellcome. Alain PS What program are usint to write you messages? my Thunderbird is behaving strangely in the answer screen and I have to break lines manually. --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing
At 07:34 PM 3/10/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. Unfortunately, DOS/4GW, now crowned That Annoying Extender Which Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that out and am not sure whether it's due to no memory in VCPI pool, missing EMS page frame, or something else. NOEMS is pretty badly broken in the EMM386 version out there anyway, but I've fixed it up some for next patch release. Now NOEMS allocates up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K for a VCPI pool, more if you have fewer 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. PS What program are usint to write you messages? my Thunderbird is behaving strangely in the answer screen and I have to break lines manually. I'm using Eudora Pro, plain text, to stop Eric from griping in his enthusiastic role as HTML policeman. Hard line breaks in regular text are generally frowned upon in messaging per ancient Usenet rules et al, so I don't use them. A few million people on the Internet like to gripe about hard line breaks. And then there's top-posting, which I still sometimes do and refuse to stop. And cap rules. And style rules. Matter of fact, you'd almost think most people out there in the world like to gripe. Not me, of course, although naturally I offer many unsolicited suggestions and opinions purely for the benefit of others. --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Hi! 10--2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: MD What would you think about an EMM386 that decided to steal some of your XMS MD memory at startup, just in case a VCPI-using program wanted it later on? I As I understand, EMM386 may inserts itself into XMM chain and behave as XMM over HIMEM. Thus, you will one memory available both through EMS and XMS, as in QEMM386. --- 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_id70alloc_id638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
At 03:38 AM 3/11/2004 +0300, Arkady V.Belousov wrote: Hi! 10-íÁÒ-2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: MD What would you think about an EMM386 that decided to steal some of your XMS MD memory at startup, just in case a VCPI-using program wanted it later on? I As I understand, EMM386 may inserts itself into XMM chain and behave as XMM over HIMEM. Thus, you will one memory available both through EMS and XMS, as in QEMM386. No, the memory allocation is quite different. XMS memory is allocated in discrete sizes, with an extremely limited number of handles, and locking a block gives you a starting address which references the whole block. Memory within the block is always assumed linear for access. There is no such thing as an absolute address with EMS other than the 64K page frame in low memory and a single 16K (EMS) or 4K (VCPI) block. As a consequence, you can allocate EMS/VCPI memory in a random spray across a memory range without any side effects -- you need only track what 4K/16K pages goes with what EMS handle. EMS memory can be, and usually is, nonlinear. If you start allocating XMS in a random spray to satisfy a number of VCPI 4K requests, you immediately fragment its memory pool and require more than a simple array of handles to track where things go. XMS is currently tracked as a position in and a length of physical memory per handle, not as a list of varying sized allocations per handle (which wouldn't even work for linearity). The only XMS handle allocation which can potentially grow would be the last one on the chain of allocations into the free area, the other XMS handle allocations are bounded by their neighbors. Currently the EMM could use a single chunk of XMS memory and suballocate it into 4K and 16K memory allocations as requested for EMS/VCPI memory requests only. But that single chunk would have to be allocated at startup and couldn't change size. And if fact, that's how it does work right now. What you'd have to do to share EMS and XMS is dynamically support growing and shrinking of any arbitrary XMS block that the EMM would use. It could be done by virtualization and dynamically remapping physical to linear memory through the page tables with each page change, but it's by no means a simple task and a good bit of the code to do it would have to be written from scratch, not to mention side issues. Doing all that's a lot of work, well beyond anything I'm ready to take on right now. It's much of the reason QEMM used to be able to charge a good price for their memory manager over what Microsoft then supplied for free. There are fairly complex memory allocation issues here, probably beyond the scope of me trying to describe them in one message. --- 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_id70alloc_id638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing
Michael Devore escreveu: At 07:34 PM 3/10/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 ;-) 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? Alain --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Hi! 10--2004 20:00 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: As I understand, EMM386 may inserts itself into XMM chain and behave as XMM over HIMEM. Thus, you will one memory available both through EMS and XMS, as in QEMM386. MD No, the memory allocation is quite different. I know, that XMS and EMS are different specifications, but what prevents XMM and EMM use common memory (alloc, dealloc, lock)? QEMM386 does this easily. MD XMS memory is allocated in MD discrete sizes, with an extremely limited number of handles, and locking a MD block gives you a starting address which references the whole block. Memory MD within the block is always assumed linear for access. And? You fear, that XMM handle table is too short in HIMEM? No problem: EMM (may/should) allocate all memory, insert itself into XMM chain and behaves like XMM and EMM (over common memory). Similarly to DOS in HMA: DOS allocates all HMA and then allows suballocation (though, in old MS-DOS there are no deallocation implemented). MD There is no such thing as an absolute address with EMS other than the 64K MD page frame in low memory and a single 16K (EMS) or 4K (VCPI) block. As a This even better, because EMM may now defragment memory to make one big contiguous memory area for XMS requests [if there is not enough memory in existing free blocks]. MD If you start allocating XMS in a random spray to satisfy a number of VCPI 4K MD requests, you immediately fragment its memory pool and require more than a MD simple array of handles to track where things go. What makes this impossible? MD XMS is currently tracked MD as a position in and a length of physical memory per handle, not as a list MD of varying sized allocations per handle (which wouldn't even work for linearity). I see no troubles: in simplest implemenation you may track EMM pages as XMS blocks (inside list of handles, shown by EMM386) and even not hide them in XMS handles list. This even not requires defragmentation or changing blocks size. MD memory through the page tables with each page change, but it's by no means a MD simple task and a good bit of the code to do it would have to be written MD from scratch, not to mention side issues. Doing all that's a lot of work, MD well beyond anything I'm ready to take on right now. This is bigger reason for me. :( --- 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_id70alloc_id638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
On Tue, 9 Mar 2004, Michael Devore wrote: What we need people to do is try EMM386 with any DOS extended program they may have available and see how well it works, or not, with interactive feedback either way. NOEMS and NOVCPI may be tried for the venturesome. Looks very promising! -- it looks like the programs work. But I see one problem now with both dos4gw 1.97 and causeway. fd kernel 2033, freecom 0.82pl3 config.sys: dos=umb,high lastdrive=z device=himem64.exe device=emm38664.exe shellhigh=command.com /e:2048 /p nothing loaded in autoexec.bat running *any* dos4gw or causeway program I tested I got a dos mem corrupt message. simplest case: d:\watcom\binwcwstub Causeway error 11: DOS reported an error or corrupt file found. dos mem corrupt, first_mcb=02c2 prev cf42:|4d 00 00 3c 10 06 (crap) notMZdf7f:|00 00 00 00 00 00 (all zeros here) no idea why -- perhaps there was an MCB here (possibly freecom as it puts various things at the top of the UMBs) and it was wiped out by something ... I'll try to narrow down and have a look later. The MCB chain corrupted message doesn't occur when using umbpci instead of emm386. And will also have a look at DJGPP programs later (using cwsdpmi). Bart --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
This is very cool! Is it stable enough for me to update my weekly built boot disks with or should I wait a while longer? Thanks, Jeremy --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
At 03:49 PM 3/9/2004 +0100, Erwin Veermans wrote: But on my test-board (440BX) that I use for testing my NwDsk boot disks EMM38664.EXE immediately hangs my machine. My config: Kernel 2033, 0.82pl3, Himem64 3.10 dos=high,umb stacks=0,0 files=99 lastdrive=z buffers=-32 When I add /verbose I see 'EPROM at c800:, size 0 KB' endlessly scrolling by ... Okay, so you're having problems with the EMM386 startup then. I didn't mess with the memory scanning portion of the original code, but looks like it needs to be updated for location of EPROMS. Can you try the /X= parameter of EMM386 to exclude that portion of memory where the EPROM is located? If so, let me know whether it fixes anything or causes different problems. --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
When I add /verbose I see 'EPROM at c800:, size 0 KB' endlessly scrolling by ... try booting without emm386 and then: c:\debug -dc800:0 2 If it says 55 AA 00 then something is very weird. It says 55 AA 01 Is that avarage weird ? So I would have 0x01*512 = 512byte video Bios Wouldn't that be a little low (understatement). yes, indeed. The code is in emm386c.c, easy to see where: it divides 1/2 which becomes 0. This code could be changed to check every 512 bytes for a ROM instead of every 2k, and to avoid this division. The value for a 64k bios should be 0x80. Not sure about 128k (that's a little high) but what is the real size of your BIOS? 256k Please check: c:\debug -dc820:0 2 It reads FF FF FF (i.e. 512 bytes later) Perhaps your BIOS is split. There is an integrated highpoint IDE UDMA controller next to the normal IDE on this 440BX. Could this be referenced at c800 and misunderstood by EMM386 as being 0 ? Erwin -- Erwin Veermans [EMAIL PROTECTED] Psychiatry RuG, PO Box 30001, 9700 RB Groningen, Netherlands --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
little high) but what is the real size of your BIOS? 256k that's very big -- it's probably not all visible then within DOS or everything between C000 and would be occupied with no rooms for UMBs. I should have said VGA BIOS. Please check: c:\debug -dc820:0 2 It reads FF FF FF ok. that'll be the unmapped space then. It looks like Lucho is right and you have a tiny 512 byte sized signature EPROM at c800:. That'll be easy to fix. If you can compile emm386 yourself you should change romsize = pmem[2] / 2; by romsize = (pmem[2] + 1) / 2; in EMM386C.C. Bart --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
When I add /verbose I see 'EPROM at c800:, size 0 KB' endlessly scrolling by ... Okay, so you're having problems with the EMM386 startup then. I didn't mess with the memory scanning portion of the original code, but looks like it needs to be updated for location of EPROMS. Can you try the /X= parameter of EMM386 to exclude that portion of memory where the EPROM is located? If so, let me know whether it fixes anything or causes different problems. X=C800-CFFF and even X=C000- fail. (same message scrolling endlessly) And yes, this always failed on earlier EMM386. I always figured EMM386 unstable and choose UMBPCI. If I read Bart's reply correctly it should be lines 183-190 in EMM386.C where the 1 read at my c800 vanishes as zero (1/2). Erwin -- Erwin Veermans [EMAIL PROTECTED] Psychiatry RuG, PO Box 30001, 9700 RB Groningen, Netherlands --- 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=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
