Date: Wed, 09 Jun 1999 17:45:22 +0100 From: Matthias Paul Subject: Re: DRDOS 7.03 loading XMS-driver now wastes memory To: opendos AT delorie DOT com Message-id: <825E27215A@reze-1.rz.rwth-aachen.de> Organization: Rechenzentrum RWTH Aachen X-Mailer: Pegasus Mail v3.22 Reply-To: opendos AT delorie DOT com On Mon, 07 Jun 1999 Utz Zarwell wrote: IMHO parts of your configuration are rather unusual. Anyway, running a quick test I too could reproduce the phenomenon on an AMD486DX40 (SIS 461 chipset, VESA-Local bus, AMI-BIOS 1993 I5 R1.3, 20 Mb RAM) running DR-DOS 7.03 and temporarily loading MS-DOS 6.22 HIMEM.SYS... So, it appears not to be CPU or chipset specific at all. Still, a number of comments and questions might help to better clarify your setup in general: >ok, at first for DR-OpenDOS 7.02 with PC DOS 7 HIMEM.SYS >[...] >DEVICE=C:\START\DOA20.EXE /C /D /Q >DEVICE=C:\START\UEBDA.SYS /S=4C /F Are these self-written drivers for A20 control and moving the Extended BIOS data area? Selfwritten? >DEVICE=C:\START\HIMEM.SYS /V /FASTA20 >DEVICE=C:\DOS\DPMS.EXE Is this the PC DOS DPMS driver? It has an unusual memory footprint of 1568 bytes quite similar to very old Novell DPMS drivers, which also found their way into PC DOS due to Stacker. Use the DR-DOS 7.02+ DPMS driver instead, it should have a smaller footprint of only 944 byte on your machine. Since you can't use VLADIVAR multitasking without EMM386, you could also try to use Helix's/Network Associates' CLOAKING driver instead of DPMS, also provides a "Cloaked DPMS server" (this is undocumented) at a (high loadable) memory footprint of ca. 1 Kb. CLOAKING 2.01 (1994) shipped for example with Logitech MouseWare 6.50 and 6.60, and even current issues of MouseWare 8.2x utilize it to run the mouse driver in Protected Mode, thereby reducing the visible mouse driver footprint downto ca. 1 Kb (instead of 27 Kb otherwise). This even outperforms CTMOUSE/DRMOUSE... >DEVICE=C:\START\UKEY.SYS /DATEI=C:\START\LEBOOK.BIN Vobis LeBook? Is this a laptop keyboard driver, or a key stuffing tool? It has an invalid device driver name "aeoeueAEOEUE(" (maybe to save some bytes), but on the other hand this should not cause any problems. >DEVICE=C:\START\UM8673.SYS >DEVICE C:\START\SRDXMSS.SYS I guess, UM8673.SYS (IDE bus master driver) correlates with 322:0000 UMPCIIDE 1F40h, 8.000 DEVICE = installed device and SRDXMSS.SYS (Marko Kohtala's resizable small XMS RAM disk) with 773:0000 F: 2E0h, 736 DEVICE = installed device But where does the other block driver come from? 24B:0000 E: B0h, 176 DEVICE = installed device I can't find a line loading something like DRIVER.SYS or another RAM disk... Or is this a result of DOA20.EXE?!? Since your memory configuration is rather modular, it might be interesting to see what happens after removing the bus master driver and XBDA relocator. Even if they worked, they could cause some fuzz... >[...] > experimenting a little using my old dummy device driver, >insert DEVICE=DUMMYDRV.SYS /SIZE=1000 before HIMEM.SYS >and got: 249:0000 DUMDRV & 1000h, 4.096 DEVICE = installed device 34A:0000 XMSXXXX0 74F0h, 29.936 DEVICE = installed device A9A:0000 aeoeueAEOEUE(' 190h, 400 DEVICE = installed device + ====== 34.432 bytes @ 249 - A9A > with DUMMYDRV.SYS /SIZE=4000 I got 249:0000 DUMDRV & 4000h, 16.384 DEVICE = installed device 64A:0000 XMSXXXX0 44F0h, 17.648 DEVICE = installed device A9A:0000 aeoeueAEOEUE(' 190h, 400 DEVICE = installed device + ====== 34.432 bytes @ 249 - A9A > with DUMMYDRV.SYS /SIZE=8000 I got 249:0000 DUMDRV & 8000h, 32.768 DEVICE = installed device A4A:0000 XMSXXXX0 C60h, 3.168 DEVICE = installed device B11:0000 aeoeueAEOEUE(' 190h, 400 DEVICE = installed device + ====== 36.336 bytes @ 249 - B11 >anything strange? I've never seen this before (but, of course, I'm using EMM386 most of the time)... Your dummy driver has proven to be quite useful here. You should try a few more configurations between /SIZE=4000..8000 to see how HIMEM.SYS strikes back when DUMMYDRV.SYS reaches 700:0000..A00:0000. Do similar things also happen when HIMEM.SYS is loaded above 1000:0000 (e.g. by loading multiple DUMMYDRV.SYS), for example placing HIMEM.SYS start in between 13xx:0000..1Axx:0000? Seems like HIMEM.SYS tries to ensure that some part of it is loaded at a fixed offset short before A9A. For what reason I don't know. On my system a DEBUG dump showed that the memory block occupied by HIMEM.SYS still contains most parts of the installer, although there are some large areas of 00h and FFh. Same with yours? Could it be, that for some reason HIMEM.SYS has problems to run within Low Memory (first 64 Kb) due to some obscure A20 or DMA problem??? Although this does not appear to be hardware specific, any changes after fiddling with CMOS SETUP settings for A20 or chipset setup? Does the following reveal anything on your machine: INSTALL=c:\drdos\mem.exe /AP DEVICE=c:\pcdos\himem.sys INSTALL=c:\drdos\mem.exe /AP I know you checked DR-DOS HIMEM.SYS /CHIPSET:xx already, but please also check DEVICE=c:\pcdos\himem.sys /MACHINE:xx /A20CONTROL:ON|OFF Unfortunately I don't have the time to track this down myself, but if this problem does occur with DR-DOS 7.03 (01/1999) and did not occur with DR-OpenDOS 7.02 (12/1997), what about DR-DOS 7.02 (02/1998) and all of its various updates over 1998? After isolating the latest working kernel for this setup, we should step by step replace IBMDOS.COM by newer ones until the problem occurs or we use the 7.03 BDOS. Then same with IBMBIO.COM. With this info, I might be able to isolate the kernel patch that apparently causes this behaviour and look for a fix. >Chipset made by UMC: UM8891N (Notebook), UM8886N EIDE/ISA bridge >If anyone out there could provide me any good info/datasheet/pointer >about that particular chipset (programming) really I would be happy >to spent that time... ;-) That's an offer!!! OK people, let's search for some data sheets (I couldn't find any of the UMC chips in INTER60, but what's the Intel Batman chipset's code number again?)... Anyone checked UMC's server already? Matthias PS: Some off-topic comments: >HISHELL SIZE=2160 C:\COMMAND.COM C:\ /E:512 /P /MH "/P /MH" should be changed to "/MH /P". For maximum compatibility, /P, /K, or /C should always be the last option in the parameter line. >and now DR-DOS 7.03 with >[...] >YESCHAR=J >TIMEOUT=15,J You could also tokenize this for more flexibility. This will ensure that the TIMEOUT default gets auto-aligned whenever you change YESCHAR (with a few exceptions tough): YESCHAR=Ja ; for German language NOCHAR=Nein RESUMECHAR=Fortsetzen TIMEOUT=15,YESCHAR,1 ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------