robertl@killer.UUCP (08/16/87)
I was just wondering, what is the latest version of the Phoenix BIOS for the
IBM AT clones? I have version 1.51, but I have seen as late as 2.27.
Are there any known bugs in 1.51? Where can I order a newer set?
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 interup because the proccesor
is going too fast for the compieler. This would make sence, because whenever
I get the error it seams like parts of my progam is missing (but it compiles
fine). Any ideas?
Thanks,
Robert
..!ihnp4!killer!robertljohnl@ima.ISC.COM (John R. Levine) (08/17/87)
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 >I get the error it seems like part of my progam is missing (but it compiles >fine). Any ideas? 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. That usually means that one of your memory chips is going bad. IBM PCs and XTs attempt to locate the bad chip and to print out an obscure number that tells which chip is bad. If your BIOS doesn't do that, try running whatever diagnostics came with the computer and tell them to test your memory. Another, less likely possibility is that there is a bug in Turbo that jumps to the NMI code in the BIOS. I say it's less likely because none of the Turbo bugs I've seen discussed resemble that. -- John R. Levine, Cambridge MA, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something The Iran-Contra affair: None of this would have happened if Ronald Reagan were still alive.
mlinar@poisson.usc.edu (Mitch Mlinar) (08/19/87)
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.)