Mail Archives: opendos/1999/06/10/03:45:48
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -