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

X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f
Message-Id: <5.1.0.14.0.20020301080427.009ec730@mail.dfsi.net>
X-Sender: impala AT mail DOT dfsi DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 01 Mar 2002 08:06:00 -0600
To: opendos AT delorie DOT com
From: Dr Who? <impala AT dfsi DOT net>
Subject: Re: Problems with DRDOS 7.03
In-Reply-To: <000001c1c10d$22595520$c03dfea9@atlantis>
References: <E649484563C4D511828300A0C9EA408A14FA10 AT exchuk02 DOT 3dlabs DOT com>
Mime-Version: 1.0
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g21E5fU01689
Reply-To: opendos AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: opendos AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

hmmm vellie strange but vellie inkstrinking
nice move om!
At 03:07 PM 2/28/02 +0100, you wrote:
>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