Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ll-xn!cit-vax!oberon!poisson.usc.edu!mlinar
From: mlinar@poisson.usc.edu (Mitch Mlinar)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Phoenix BIOS and NMI problem
Message-ID: <4137@oberon.USC.EDU>
Date: Tue, 18-Aug-87 17:21:27 EDT
Article-I.D.: oberon.4137
Posted: Tue Aug 18 17:21:27 1987
Date-Received: Fri, 21-Aug-87 01:05:39 EDT
References: <1342@killer.UUCP> <657@ima.ISC.COM>
Sender: nobody@oberon.USC.EDU
Reply-To: mlinar@poisson.usc.edu (Mitch Mlinar)
Organization: University of Southern California, Los Angeles, CA
Lines: 27
Keywords: Phoenix BBIOS

In article <657@ima.ISC.COM> johnl@ima.UUCP (John R. Levine) writes:
>In article <1342@killer.UUCP> robertl@killer.UUCP (Robert Lord) writes:
>>Also:  When compiling a program in Turbo C, I sometimes get an NMI error,
>>and it asks: (S)hut off NMI, (R)eboot, or any key to continue.  
>>I have been told that this is a non maskable interrupt because the processor
>>is going too fast for the compiler.  This would make sense, because whenever
>
>Somebody is pulling your leg. Compilers don't care how fast processors go,
>just whether they work or not. On PCs, the usual reason that you get an NMI
>interrupt is that a byte was fetched from memory and its parity was wrong.

John is correct.  I have helped several friends put together clones for
extremely few bucks and all of them had the Phoenix ROM.  Two out of the three
had the NMI error - which turned out to be a memory error in both cases.
In fact, I do not think any other "basic" service uses NMI other than parity
error.

As a side note, the error in one of them was a slow DRAM - not
a damaged one; the error was intermittent, but was finally nailed down.
I have also found on the mother boards that allow both 64k/256k chips for the
first 512k (always 64k on motherboard after that), 256k chips are more reliable
than 64k, BUT .....

I am not sure why this is the case, since I don't have access times of the
DRAM chips nor do I know if there is a selection delay on the motherboard.
(Being both hardware and software oriented, I see no valid explanation
offhand; this is just an observation based upon five PC clones.)