delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/2002/03/01/05:42:25

X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f
Message-ID: <000001c1c10d$22595520$c03dfea9@atlantis>
From: "Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
References: <E649484563C4D511828300A0C9EA408A14FA10 AT exchuk02 DOT 3dlabs DOT com>
Subject: Re: Problems with DRDOS 7.03
Date: Thu, 28 Feb 2002 15:07:29 +0100
Organization: University of Technology, RWTH Aachen, Germany
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g21AgJA17635
Reply-To: opendos AT delorie DOT com

On 2002-02-27, Joe Smith wrote:

Thanks for posting your configuration data here. Although
the CONFIG.SYS looks harmless at the first glance, there
are many strange things happening here. Letīs have a look
at the memory listing first:

>    70:016E     ?:-B:                     Built-in device driver

This is unusual, the first drive letter should be A: and the
last one should be the last one of your hard disk, depending
on how many volumes you have.

Thereīs definitely something going seriously wrong here, but
right now, Iīm not sure what it is - weīll have to try out
a few things to track this down.

>   100:006D    DR DOS     200h,     512    1 Disk buffers
>[...]
>  9FFF:0000    DR DOS   28010h, 163,856  System
>
>  A858:AA6C    DR DOS     200h,     512    1 Disk buffers
>[...]
>  FFFF:A430    DR DOS     200h,     512    1 Disk buffers

This is very unusual as well. You specified four buffers in
CONFIG.SYS, but I can only find three in your MEM /A output.

Also, the buffers should be either in the HMA, or in UMBs,
or in conventional memory, depending on where you load
the kernel. One buffer may remain in conventional memory,
but this is not listed as such by MEM. It is very unusual
to have buffers in both, the HMA and this "some strange kind
of" UMB at the same time...
The third strange thing is, that the buffer at A858h:AA6Ch
is in the middle of the video memory range; if this buffer
would be actually used by the system, it would be a direct
trip into the desaster area, probably causing a crash or
corrupted data on the disk. In particular when you fire up
programs which use an EGA or VGA video adapter - and the
Norton Utilities certainly do this.

I can see no reason, how the buffer could be placed there,
your configuration of EMM386.EXE does not give any indication
that you forced some UMB memory to be in the video memory
address range (which /is/ possible when only text only applications
are used, but it requires a special setup, either with /VIDEO
or with /USE depending on if you want to use that memory as
part of an extended TPA (Transient Program Area) with MEMMAX +V
or as UMB memory).

>   35C:0000   COMMAND     810h,   2,064  Environment
> 
>   3DD:0000   COMMAND     140h,     320  Data
> 
>   3F1:0000   COMMAND     150h,     336  Data
> 
>   406:0000   COMMAND      F0h,     240  Data
> 
>   415:0000   COMMAND     1F0h,     496  Program
> 
>   434:0000   COMMAND     810h,   2,064  Environment
>[...]
>  CD17:0000   COMMAND    2090h,   8,336  Data
>[...]
>  FFFF:00E0   COMMAND    2080h,   8,320  Program

Very unusual as well, COMMAND.COM does not normally use a
8 Kb data area. To me this looks as if you had two copies
of COMMAND.COM running, when you took this MEM snapshot...
Have you shelled out from a program to a secondary command
shell when you issued the MEM /A?

>  E800:0000       EMS   10000h,  65,536  ---------- EMS memory
>
>  FD00:0000  --------    1000h,   4,096  ---------- Shadow ROM

The page frame at E800h is a special setup (/FRAME=E800 /USE=F000-
F7FF), which will work in most cases, but you should avoid it,
as long as you still have enough free UMB memory. Also the small
Shadow ROM area in between the remaining F800h-FFFFh ROM BIOS area
is a little bit odd.

Finally, I did not found the BIOS and BDOS kernel areas and some
other DOS structures listed anywhere in the listing, either the
system or MEM must have been totally confused...

Well, having a look at your CONFIG.SYS file I could find a
few oddities there as well, and one of the settings probably
causes this odd behaviour. I already have a few suspicions,
but to address the problem properly, I will need to know more
details about your system first:

Which exact version of DR-DOS are you booting? Toggle Scrollock
on before the "Starting DR-DOS..." message is shown. The kernel
will then display some additional internal build info at startup.
Just to make it sure, you are not using some patched issues
of the kernel? And you are not mixing kernel files from different
versions, just the normal files from the offical distribution?

I could also need a listing of the system files in the root
of drive C:\ so check the file sizes and date stamps, for example
created by issueing a DIR c:\*.* /S or /AS.

The cause of the problem could also be located in AUTOEXEC.BAT,
could you post this file as well, please?

Finally, can you describe your system in better details?
Do you know the brand and model of the mainboard, the manufacturer
of the chipset on the mainboard? Is this an Intel CPU or
a compatible one? What brand, version, and date is the ROM-BIOS
and the Video BIOS? What kind of video card do you have installed
in your system? Is there anything special with that machine,
say, is it a mobile system, an industry device, or an embedded
PC? Probably not, but if so, this info might be useful to know
as well.

Well, now to your CONFIG.SYS file. There are a several unusual
things in there, but only few actual mistakes.

I would like to track down what exactly caused this strange
MEM output, so we better do not change too many things at the
same time. Otherwise we may solve the problem, but still donīt
know what has actually caused it... ;-)

> DEVICE=C:\DRDOS\EMM386.EXE DPMI=OFF  FRAME=E800 USE=E800-F7FF AUTO
> MULTI=OFF ROM=AUTO

Please remove the FRAME=E800 and USE=E800-F7FF and replace this
simply by FRAME=AUTO for now. Also remove the ROM=AUTO and AUTO
switches for testage:

DEVICE=c:\drdos\emm386.exe /DPMI=OFF /MULTI=OFF /FRAME=AUTO /VERBOSE=DEBUG

> DEVICE=C:\DRDOS\DPMS.EXE
> DEVICEHIGH=C:\DRDOS\NWCACHE.EXE /E 7680 1024 /LEND=ON /DELAY=5000 /FLUSH=ON
> /BE=16 /CHECK

Well, if you want to use DPMS via XMS, you must not force NWCACHE to
use EMS memory. NWCACHE will have a larger DOS memory footprint when
using DPMS, but using DPMS will dramatically increase the performance.
So change this line to:

DEVICEHIGH=c:\drdos\nwcache.exe 7680 1024 /MUX /LEND=ON /DELAY=5000
   /FLUSH=ON /BU=16 /CHECK

> DEVICEHIGH=C:\DRDOS\VDISK.SYS 2000 /X
> SHELL=C:\COMMAND.COM C:\/P:AUTOEXEC.BAT /E:2048 /MH

This is not error, but it is safer to use the COMMAND.COM in
the DR-DOS directory. So copy (not move) the command.com from
the root into c:\drdos\ (if it is not already there) and change
this line to:

SHELL=c:\drdos\command.com c:\drdos\ /E:2048 /MH /P:autoexec.bat

The /P parameter must always be the last parameter for compatibility
with some programs. You probably donīt need 2 Kb of environment
space, /E:512 will be sufficient in most cases, but optimization
comes after trouble-shooting...

> DOS=UMB,HIGH

Change this into 

DOS=HIGH,UMB

> FILES=20
> BUFFERS=4
> FASTOPEN=0
> FCBS=4,4
> FASTOPEN=0

You can remove the second FASTOPEN=0 here.

> BREAK=ON
> HISTORY=ON,256,ON, OFF, OFF
> VERIFY=OFF
> LASTDRIVE=Z
> COUNTRY=044,,C:\DRDOS\COUNTRY.SYS

Change this to:

COUNTRY=44,437,c:\drdos\country.sys

> INSTALLHIGH=c:\drivers\mouse\ctmouse.com

Which version of CTMOUSE are you using?

OK, some of the changes are experimental only, and there are
a few more settings, which I did not change in this round,
because I want to track down the actual cause of the problem.

Can you post your remaining configuration files and a MEM /A
after applying these changes? Thanks.

Greetings,

 Matthias

-- 
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org


- Raw text -


  webmaster     delorie software   privacy  
  Copyright Đ 2019   by DJ Delorie     Updated Jul 2019