From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: CWSDPMI r5 Date: Thu, 22 Jun 2000 22:54:10 Organization: Aspen Technology, Inc. Lines: 83 Message-ID: <39529912.sandmann@clio.rice.edu> References: <394A554E1A2 DOT A7A4TIMOTHY DOT ROBINSON AT hide> <394d59f5 DOT sandmann AT clio DOT rice DOT edu> <394E4548 DOT 6A43F26D AT cyberoptics DOT com> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 961732607 15893 10.32.115.107 (23 Jun 2000 03:56:47 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 23 Jun 2000 03:56:47 GMT X-NewsEditor: ED-1.5.8 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 At the bottom of this note, I've included a list of changes from r4 to r5. One of these might directly fix what you've described. In r4, the A20 gate was set once in raw/XMS mode and assumed to stay put. I found in testing some systems in some environments that it didn't. I added an extra A20 call, but found this hurt performance. What you poor souls have been testing is not the absolute most recent version from my machine (which is 12 days later) and includes some changes in the A20 stuff that I think improves the latency issues you observed from what I can best guess. There are a few test systems out there that behave poorly with the new release and it could be related to many of the changes below. Short of building several test versions with a mixture of changes I'm not sure how to get r5 from beta to general release. ehdrfix.c: Make build support program EHDRFIX more portable makefile: Build with BCC 5.0 with 32-bit arithmetic support instead of BCC 3.1 cwsparam: Fixed cwsparam bug in display of unsigned values as signed cwsparam: Cwsparam support big swapfile sizes (word32 instead of word16 pages) control.c: Forced internal disk bitmap allocation to zero when ring 0 Changed release number start.asm: Code cleanups (unused registers) in startup assembly exphdlr.c: Define for Borland compiler support of port functions in C Allow real mode reboot interrupt 19 from dpmi call Added 0x0401 Get DPMI Capabilities support Fixed unlocking bug in ring 0 Added ifdef for DOS memory locking mswitch.asm: Add get of CPU feature bits (to support 4Mb pages) Change segment usage in A20 state detection to work around chip bug Support raw mode A20 line control for PC98 architecture Add call to set A20 line (fixes bugs that should never happen) Add check if A20 already active, if so skip enable vcpi.*: Change vcpi_* routines to support > 256Mb memory (word16 to word32) paging.*: Added bit definitions for 4Mb pages Made paging support > 256Mb memory (word16 to word32) Code cleanups (unneeded masking values) in paging.c Fixed signed/unsigned bugs in paging.c (128Mb max memory) Changed types to support 2Gb memory (word16 to word32) Fixed paging diagnostics Added ifdef to support PFM686 custom code valloc.*: Defines to remove hardcoded constants (word16/word32 support) Change valloc_* to support > 256Mb memory (word16 to word32) Detection of more than 64Mb of memory when in raw mode Detection of extended memory size for PC98 in raw mode Fix allocation size of bitmaps to not overflow in 16-bits Updated copyrights In addition, I have a code branch directory which contains working 4Mb page support - but there are lots of features which it breaks that are not tested for internally and would explode badly if released (anything that assumes a page size is 4K!). Since this is 1/2 done I'm not sure what to do with it either. But it would allow fast, small memory footprint DPMI access to a full 2Gb of physical memory.