Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!husc6!genrad!genrad.com!jpn
From: jpn@genrad.com (John P. Nelson)
Newsgroups: comp.os.msdos.programmer
Subject: Re: 386-33 and QEMM 5.11
Message-ID: <40451@genrad.UUCP>
Date: 22 Jan 91 12:52:09 GMT
References: <1991Jan21.085949.21@thorin.otago.ac.nz>
Sender: news@genrad.UUCP
Reply-To: jpn@maxwell.genrad.COM (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 26

In article <1991Jan21.085949.21@thorin.otago.ac.nz> klox@thorin.otago.ac.nz writes:
>We have had similar problems running Qemm 5.0 on NEC 386SX machines here.
>Boot the computer and it gets as far as reading config.sys and then reboots.
>It then reads config.sys and reboots, and reboots and reboots.

I tried to send email, but it bounced.

The solution to QEMM's problem is to use the NOSH (NOSHADOWRAM) flag on
the QEMM.SYS command line.  QEMM normally tries to recover all unused
shadow ram by manipulating the C&T or NEAT chip sets, but for some
reason, this fails big time on the NEC 386SX machines.  Simply tell
QEMM not to muck around with Shadow ram, and it works fine.

>We are no longer using Qemm5 on SX machines.

That is rather extreme.  QEMM5 works fine on SX machines.

>It is OK on our "real" 386 boxes. But for the SX's we use v4.2.

The difference is the 4.2 didn't try to recover shadow ram unless you
explcitly asked it to do so.  In 5.0, this is the default.

     john nelson

uucp:	{decvax,mit-eddie}!genrad!jpn
domain:	jpn@genrad.com