delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/06/19/12:15:58

Message-ID: <394E4548.6A43F26D@cyberoptics.com>
From: Eric Rudd <rudd AT cyberoptics DOT com>
Organization: CyberOptics
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CWSDPMI r5
References: <394A554E1A2 DOT A7A4TIMOTHY DOT ROBINSON AT hide> <394d59f5 DOT sandmann AT clio DOT rice DOT edu>
Lines: 32
Date: Mon, 19 Jun 2000 11:07:36 -0500
NNTP-Posting-Host: 38.196.93.9
X-Trace: client 961430858 38.196.93.9 (Mon, 19 Jun 2000 12:07:38 EDT)
NNTP-Posting-Date: Mon, 19 Jun 2000 12:07:38 EDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Charles Sandmann wrote:

> Unless you have more than 255Mb of virtual memory defined, or 128Mb or more
> of physical memory it won't do much of anything for you, unless you have need
> for one of the obscure enhancements.

There was another reason for me to upgrade from r4 to r5.  I have a 200-MHz
Pentium MMX system with 64 MB of RAM, running IBM PC-DOS 6.3 with HIMEM but not
EMM386, and have found that r5 solved some puzzling lockups that I had been
having with r4.  These lockups seemed to affect only gcc, and then only about
one in every hundred compilations, but it got annoying having to hit the
hard-boot button in the heat of debug/edit cycles.  I had posted the dump on a
couple of occasions (manually transcribed, since the keyboard was wedged at
that point), but I never did figure out what was causing it.  The disk cache
would continue to commit normally after the lockup, so it may have been that
only the keyboard was affected.  The problem would go away if I ran EMM386, but
I had other reasons not to run EMM386.

Anyway, after I switched to the r5 beta, I have yet to have one of these
lockups, with or without EMM386, so some change in r5 seems to have fixed the
mysterious problem, whatever it was.  It's probably not worthwhile tracking it
down at this point, but thanks for fixing it, whatever you did.

I have noticed that the latency from the time-of-day interrupt is longer in r5
than in r4, which caused some problems with a certain piece of FIFO-less custom
hardware I access, but I knew that the timing was marginal even under r4, so I
upgraded the board with a later version of the chip that had a FIFO, and
haven't had a problem with it since.

-Eric Rudd
rudd AT cyberoptics DOT com

- Raw text -


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