Message-ID: <394E4548.6A43F26D@cyberoptics.com> From: Eric Rudd 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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