GUS Programmer's Digest Thu Jul 22 00:07 Volume 2: Issue 26 Today's Topics: Help w/ umdocs needed NMI stuff Standard Info: - Meta-info about the GUS can be found at the end of the Digest. - Before you ask a question, please READ THE FAQ. ---------------------------------------------------------------------- Date: Wed, 21 Jul 93 9:24:49 PDT From: aktang@sdcc13.UCSD.EDU (Anthony Tang) Subject: Help w/ umdocs needed Message-ID: <9307211624.AA18059@sdcc13.UCSD.EDU> Has anyone successfully compiled and ran ummidi in the umdocs? I can compile it, but when I run it, i get the following: UltraMid is loading the patches Playing the file... (Or something like that), then I get popped back to the DOS prompt, no output from the card. UltraMid, version 1.0. Any ideas? Thanks... -- Anthony Tang Call The AANThill BBS! AANT (619)550-8168 aktang@sdcc13.ucsd.edu ------------------------------ Date: Wed, 21 Jul 1993 16:19:32 -0400 (EDT) From: Sam Mertens Subject: NMI stuff Message-ID: Some more info on the NMI problems: It seems that NMI was set up at a time when RAM was much less reliable than it is now. It is still used today, of course, but some motherboards don't bother to check the memory- they assume its fine (I've never had memory chips go bad on me. Memory CONTROLLERS, yes, but not the actual RAM). These, of course, are newer and designed to be 'fully optimized' (don't stop to check for something you know will work). Now, not checking the RAM at all sounds pretty stupid to me, so I'll give manufacturers the benefit of the doubt and guess that they've probably found better ways to test RAM. The operating principle behind NMI is a parity check - memory is physically addressed by a row and grid method, so the computer adds up all the 1s and 0s in each row, and the parity for that row is set to a number (0 or 1) that when added to the row's sum, will result in either an 'even' number or an 'odd' number... I'm not quite sure how even and odd apply to binary terms, nor exactly what goes on during all that adding (bit by bit? Byte by byte?). The system then, of course, goes back to check everything (this is stuff which normally the CPU doesn't even have to think about), and if it finds something screwy, voila! An NMI error. The parity is always updated with each memory write, of course. Now, with the current PC standard, chips in groups of 8 are each dedicated one memory chip (not addressable by the system in any way) just for storing parities. That's why we have 9-chip simms, and 3-chip simms (do the math on that one). I've read something about 8-chip simms which would be slightly cheaper, but I've never actually seen one in use or for sale. They only work with the non-NMI motherboards, anyway. Fixing the problem: 1) Turn parity on (from the BIOS setup menu), so NMIs can be generated. 2) Leave the RAM refresh rate at its default state, or find a setting that works. On some systems this too can be accessed via the BIOS setup. Also, set anything else that might pertain to memory at its default state (just to be sure). 3) Scream, rant, and rave. I am currently sifting through AMI bios data and may be making contact with their tech support soon to see if this problem can be fixed through BIOS (which may be the true culprit; or, it might not). Hope this helps anybody who is having NMI problems with SBOS... And please post any new information on the subject you might find. Sam Mertens ------------------------------ End of GUS Programmer's Digest V2 #26 ************************************* To post to tomorrow's digest: To (un)subscribe or get help: To contact a human (last resort): FTP sites: archive.epas.utoronto.ca pub/pc/ultrasound wuarchive.wustl.edu systems/msdos/ultrasound Hints: - Get the FAQ from the FTP sites or the request server. - Mail to for info about other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)