Mail Archives: djgpp/2000/06/23/00:18:14
> 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.
- Raw text -