Newsgroups: comp.os.msdos.desqview
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!harpsichord.cis.ohio-state.edu!mcmillan
From: mcmillan@harpsichord.cis.ohio-state.edu (Hal McMillan)
Subject: Re: QEMM causes reboot
Message-ID: <1991Jun24.212142.11270@cis.ohio-state.edu>
Keywords: qemm
Sender: news@cis.ohio-state.edu (NETnews        )
Organization: The Ohio State University, Department of Computer and Information Science
References: <9106180041.AA26040@chinle.utah.edu> <135605@tut.cis.ohio-state.edu> <7125@bwdls58.bnr.ca>
Date: Mon, 24 Jun 1991 21:21:42 GMT
Lines: 33

In article <7125@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes:
>In article <135605@tut.cis.ohio-state.edu> mcmillan@kayak.cis.ohio-state.edu (Hal McMillan) writes:
><I have a Gateway 386/33MHz w/ 4Mb (Micronics motherboard) and a
><Diamond Speedstar (Tseng ET4000) VGA card.  I have had a serious
><problem with QEMM (v. 5.12) rebooting the machine when it tries to
>...
><Does anyone know why this is happening, and/or how I could get more
><high RAM from qemm?
>
>Turn off the BIOS shadowing functions.. let QEMM do it instead (ROM
parameter)

Well, I finally broke down and made the long-distance call to
Quarterdeck.  And lo and behold, the techie on the other end nailed
it!  I needed to use the NOSH parameter.  The manual indicated that
was for C&T chipsets and I had not tried it before.  Many people had
suggested turning the hardware BIOS shadowing on or off, but that made
no difference in my case.

The techie was not able to help with my other problem: the fact that
DV displays a control-break dialog box when I press ctrl-C in the PD
version of emacs that I have.  We tried all the keyboard interrupt
values.  He said that there are other programs that have this problem.

In any case, I now use "RAM ROM NOSH" and have no problems.  QEMM finds
and uses the 384K of shadow RAM along with all my other RAM.

I have upgraded to DOS5, and using DOS=high in my config I end up with
about 637,000 bytes free.
-- 
Hal McMillan                | "It's an ideal principle, which can be verified
mcmillan@cis.ohio-state.edu |  only under ideal conditions.  Which means never.
72627.642@CompuServe.com    |  But it's still true."