X-Apparently-From: Message-ID: <002301c05b80$52cc8310$fc881004@dbcooper> From: "Patrick Moran" To: References: <8D746E83339 AT reze-1 DOT rz DOT rwth-aachen DOT de> Subject: Re: Re: Optimizing CONFIG.SYS... Date: Fri, 1 Dec 2000 03:11:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Reply-To: opendos AT delorie DOT com ----- Original Message ----- From: "Matthias Paul" To: Sent: Thursday, November 30, 2000 6:45 AM Subject: Re: Optimizing CONFIG.SYS... > On Wed, 29 Nov 2000 Patrick Moran wrote: > > > Actually it loads in two chucks. With QEMM I found it can load with 65000 > > bytes (probably less if I experimented more but was satified with that > > amount.) > > It could be that the low level portion (including the buffering) > and the higher level file system stuff are loaded in different > segments. Maybe it was consuming more memory on my system because > I have set the buffers to max? > They way I found this out was by forcing NWCDEX to load low and see how much memory it actually used there. I don't recall how I figured out that it loads in more than one chunk. I may have read about it or just assumed it when playing around with loading it. I know that QEMM would allow 128K for loading it. I also found that QEMM also allowed more memory than what is needed to load the DRMOUSE driver. I played with that and found it will load with 9 or 10K of memroy instead of something like 12K. Thus I could force it to load into the B000 range. By using a lot of different techniques and using both MFT and MEM, I dicoverd a lot about how things load with DRDOS. You might try using different buffer sizes and forcing it to load low and see what the results are. If you have QEMM, you might want to see how much memory it needs to load it with different amounts of buffer. That may give some clues. Why do you need those buffers? There are caching programs available for CD. I only have a 4X CD and it is also a SCSI CD which may also make a big difference. I never could see any practical use for those high speed CDs anyway, because all I use mine for is to install programs and listen to audio CDs. My next one will be a DVD RAM drive anyway and those are not high speed CDs either. Those so-called high-speed CDs are nothing more than about a 6X or 8X CD with a large RAM buffer. If those things actually spun at 24X or 36X they would probably fly right out of the drive! That brings up a question I have had and have done some research but have not found the answer. The DVD RAM drive I want to get will also be able to read and write PCDs. Can PCDs be use just like R/W CDs. They also have 650MB capacity. i.e. do the use ISO 9660? Or can they be forced to? If so, then I could DL ISO images. Sure I can do that anyway as there are programs that can force a HD to look like a R/W CD, but I could actually save it permanately on a PCD if that is possible. > > I downloaded the program and will check it out sometime, but if it takes 900 > > bytes of conventional memory, I won't need it until I use QEMM or something > > else that does not let it all load into UMB and extended memory. I can get > > by with 112 bytes in an area I can't use anyway. (At least at this time I > > cannot.) > > Hm, my INSTCDEX has nothing to do with the 112 byte environment not > being freed by NWCDEX, if you mean that. (I mentioned that my > personally enhanced issue of NWCDEX as well as other drivers do free > the environment, and if Lineo would at some time open up DR-DOS, > I will make this available to everyone. I still haven't lost hope...) > INSTCDEX allows to load NWCDEX in CONFIG.SYS (which normally does > *not* work for various reasons) and thereby the chance that it can be > completely loaded into UMB will be increased. INSTCDEX is not a > resident tool, it is an utility that patches around in internal data > structures, and allows to temporarily save state data on disk, while > the Current Directory Structure (CDS) is relocated into UMBs after > CONFIG.SYS processing has finished. What environment are you talking about then? The 7K? That program might be useful with QEMM. I do have over 64k of contigous memory left in UMB for a page frame, but I cannot get everyting loaded high when I use an EMS page frame. Too bad I can't establish the page frame last after verything else is loaded. According to the LIM 4.0 specifications, those 4 16K blocks DO NOT have to be contiguous. They can reside in different areas, but I have yet to see an EMM386 do that. Also you are not restricted to just 64K frame, you can use as many 16K chunks as you want. It is possible to have as large as a 256K frame located in conventional memory. I don't know why that is a limit, but according to the book "DOS Above 640K" it is. AST actually made a computer that had no conventional memory and used EEMS. I don't know how they did it, I would like to see the theory and docs on how they did this. It seems that you would need at least 64K conventional to start with. My old 286MB was a 99.99% clone of an IBM AT. It's BIOS ROM was located in two memory locations. At the top of 1MB and at the top of 16MB. Why no one ever used this feature other than AST, beats the crap out of me. It seemed like the most logical way to do things. You just forget about conventional memory completely and run everything in extended memory. All that would need to be done is to boot thew system, load the system area of low RAM into the bottom of the extended memory area and operate everything in the 1MB to 15MB range, then of course with the 386 it would be 1MB to 4GB area. ROMs are generaly porgrammed to be relocatable. i.e. they could care less if they are loaded at C0000-C7FFF or C8000-CFFFF or D0000-D7FFF or FFFFC0000-FFFFC7FFFF. The first significant hex number is merely relative and is assigned by a jumper or whatever as in C000 or D000 or C8000 or E800. Any address beginning with more significant didgits is irrelative. So it could be FC000, FFC000, FFFC000, FFFEC000 or what ever you want. The only restriction would be a particular boarder of 8K, 16K, 32K 64K or whatever it happens to require. I don't know if current mother boards still follow this, but if they do, all someone needs to do, is write a loader to do this and forget about conventional memory altogether and EMS completely. But because many programs do use EMS (only) you could put as large of a page frame as you want in extended memory, probably with the 256K limit. Then you would have however much memory in your system minus the 1MB of conventional memory. This would probably require that DOS be rewritten so that it CAN operate in protected mode. I would not think that it would be that difficult to do, as instead of using segmented addressing you could use absolute addressing. As far as DOS or any other application is concerned, the beginning of memory at 100000 would actually be 00000. This is essential what APPLE did with it's DOS, you could load it at the top of any 4K page boundry. There were loaders that would shove it up into the Language card. I did this as I had Applesoft in ROM on th MB and Integer BASIC in a ROM card in one of the APPLE MB slots. The loader would merely change the Most Significant hex address accordingly for all absolute jumps. This could also be applied to an APPLE ][e with 128K RAM, you could have shoved it to the top of 128K. APPLE had a high and low memory marker and no program gould be loaded above/below those markers. A very similar thing was done with my OSI. There were 4 unused data lines of it's bus, and these could be used in comjuction with the PIA port that was also on the CPU card to manipulate 64K pages above the 64K CPU limit and thuse allow you to use up to 1MB or RAM. OSI actually had systems that could utilize up to 256K or 512K RAM doing this. They did this in thier multiuser, multi-processor systems. We are talking about a measly 8 bit 3MHz CPU system that could run circles around an IBM system with 16 bit processors. In fact you had to have at least a 286 to even use multi-processing in the Intel family of chips, yet OSI did it with 6502, Z-80 and that 1600 chip they used to emulate a PDP-8! And you could install as many 6502 CPU cards as you wanted into a single system and connect up to 256 such systems together. The Backplane of each system could be expanded up to 256 slots per system! This was way back in the late 70's!!!! > I'm not sure, Patrick, if you can make good use of INSTCDEX in > your configuration, because you said you already *can* load high > all the stuff, and even if not, you said, you *can* load NWCDEX > in CONFIG.SYS (the only reason I currently see, why this works for If I use QEMM or any kind of page frame, I may need it. I do not currently use EMS at all. > you even without INSTCDEX, is that your system sees only one or two > DOS partitions, because otherwise the pre-set of the LASTDRIVE value > (the reported count of slots in the pre-CDS) would be used up > already (and you can expand this only by loading block device > drivers, or - under DR-DOS - by patching around in the kernel's > internal data structures (INSTCDEX /LASTDRIVE does that)). This may be true as I only have a single IDE drive and it only has two partitions on it. Everything else in the system is SCSI and the IDE will be history before long, when I upgrade this system to a much better MB and memory and a 80 or 160MBs ultrawide SCSI. > The LASTDRIVE setting only takes effect after CONFIG.SYS has > finished, in the same moment when the pre-CDS (in low memory) > is freed and the actual CDS is build (in UMB memory when DOS > goes up). I take it then that 7K area is used for that and if you can load that high, you are in the groove. > NWCDEX takes 928 bytes of conventional memory, when it uses EMS. > So far I was not able to load this portion high. Anyone? Did you try loading it first and using INSTALLHIGH? What about with your SETENV? > However, many people are still using EMS *and* let NWCDEX use > DPMS *and* have problem to load the 7 Kb real-mode portion into > UMBs. Those people are probably better off forcing NWCDEX to use > EMS instead of DPMS. I have always had that problem, until recently when I was playing around with it and discovered if I loaded it very early in the AUTOEXEC, before any additional environment was used and using the LOADHIGH with it, it would load everything into DPMS and UMB. But, it will not do so if I use EMS, because that stupid memory hogging page frame takes 64K of UMB away before you can load your drivers and TSRs. If that damnn thing could be load last but before anything requiring EMS was loaded, then everyone could probably do it. That is just one more reason I hate EMS. Maybe we should take a step backwards and use EEMS. i.e. Use AST's much more capable memory manager that LIM 4.0 was based on but hacked because of stupid company egos!!! That is the same reason I sometimes have problems connecting at 28800 with my modem. It has the Rockwell chipset in it and was designed before the v.32bis was implemented, BECAUSE NO OTHER COMPANY WANTED ROCKWELL TO HAVE A HEADSTART, so they hacked it and Rockwell had to redesign their chipset, just because they might be a little ahead of everyone else. I can sum it up into one single word-> GREED! > (BTW: NWCDEX has a bug, and will hang if you force it to > use EMS when EMS is not present.) That figures! Maybeeck for the precence of EMS before it loads > is ignored. So, if your ROM-BIOS has faulty date support, > you would need to load a 3rd party Y2K-fix after loading > QEMM. This should work. Such TSRs are freely available > from many places, including ASUS (ASUS2000.COM) or > Heise Verlag, Germany (c't magazine, www.heise.de). Most diagonstics I have run ssys it is Y2K compliant. I have had a couple that say it is not, but on decenber 31, 1999 at mednight it rolled over. I think I also checked it for leap year and it is obvious that that worked because we are now past that point. I haven't checked it for leap year 2004, but don't intend to be using it then, unless it is for a DOS box. > 2. QEMM's DOSUP has problems because of the changed layout > of handles since DR-OpenDOS 7.02+. Previous issues > had 5 handles in one chunk in low memory during CONFIG.SYS > and 8 or more handles in two chunks (8+x) afterwards. I was always currious, why DOS UP had problems with DR DOS, seems like it should have been a simple fix for Qauterdeck to fix it in later versions of QEMM, but QEMM 8 still has that problem. The FCBs are probably handled in this manner for CP/M compatibilty, which of course Gates immediately allienated when MS wrote it's first actual version of MS DOS (V2.0.) BECAUSE CP/M COULD COMPETE WITH MS CRAP FOR DOS!!!!! GREED! > Due to the introduction of the FILESHIGH/FCBSHIGH > directives, this has changed a little, and it now > has 5+3 handles in two chunks in low memory and > optionally x handles in a third chunk either in > low memory or upper memory, depending on FILESHIGH/ > FCBSHIGH. This is completely valid in terms of > DOS standards, but QEMM's DOS-UP objects (probably > just because it does not expect this layout under > an OS or the DR-DOS family). They stick with the stupid buggy MS CRAP APIs probably, because who knows what Gates may have done if they did not stay completely within his circle of complete dominance. If Gates had found out that QEMM would work perfectly with DRDOS he would have changed a stupid API to make QEMM not work with MS CRAP for SOFTWARE. Which by the way is illegal! But since it is Gates doing it, the law is just for other people, Gates don't you know is above the law. (let's get some very messy pies ready!!!) > The other QEMM features still work, though. > If you really want to make this work, back in > 1997 I developed a simple patch for the IBMBIO.COM > file which forces the old layout. This was posted > several times in this forum (I think I called it > IBMBIO85.SCR), but I could locate it in my archives > if anybody still needs it. I have one of those that you wrote. Not the .SCR, but the binary. I don't recall the date on the file or where or when I got it. It is in my vast collection of DRI related files. I'll have to dig it out and look at it. Did that version fix the problem with DOS loading into HMA or was it based on the 7.02 updated kernel files which had already fixed that problem? Can you send me the code that you used and I can disassemble the 7.03 version and edit it in and reassemble it with the patch. I can use Sourcer to diassemble and MASM 5.0 or 5.1, which ever version of MASM I bought as that version of Sourcer is compatible with my MASM. Pat __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com