home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / ibm / pc / soundcar / 5854 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.4 KB  |  47 lines
  1. Newsgroups: comp.sys.ibm.pc.soundcard
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!adhir
  3. From: adhir@wam.umd.edu (Al Dhir)
  4. Subject: GUS Memory problem
  5. Message-ID: <1992Dec30.043157.28123@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. Date: Wed, 30 Dec 1992 04:31:57 GMT
  10. Lines: 35
  11.  
  12. I have a GUS with 1 meg on board (70ns original + 768k of 80ns).  Every time
  13. I run the DRAM program I end up with the last bank of 2 chips reported bad.
  14. Everything works OK (well, almost...read on), but this concerns me.
  15.  
  16.  
  17. Today I dled the new Windows drivers from the Gravis BBS along with the
  18. new Patch Manager program (nice!).  Since the Patch Manager has a constant
  19. display of available GUS memory, I decided to fill up GUSes memory with
  20. patches in order to test the memory (to see if everything sounded OK with
  21. the memory filled).  Well, it didn't.  When memory got up into the highest
  22. bank of 256k, one or two of the Drum kit patches started sounding messed
  23. up.  Very upsetting I must say.  I noticed that the non-drum kit sounds
  24. always sounded OK though.  Even if I first load the Drum kit patches, and
  25. then fill up the memory by loading a bunch of the non-drum kit patches, all
  26. sounded OK except for one or two of the DRUMKIT patches.  It makes a wierd
  27. staticky noise during playback of the affected patches.  Upon unloading of
  28. the other patches, the Drumkit patches which wer previously affected sound
  29. OK again.  It seems like the GUS is always moving the patches around in
  30. memory every time they are loaded or unloaded.  Is this true?  If not, 
  31. it could just be a problem with the GUS and not with my memory.
  32.  
  33. I am asking for opinions here, about what I should do.  I don't feel like
  34. opening up my machine until its absolutely necessary (I have this HUGE tower
  35. case neatly tucked under my desk...).  Think I definitely have a ram problem
  36. or can someone tell me whether this happens to them also...?  Is the DRAM
  37. program probably reliable in this case?
  38.  
  39. Thanks for any help/suggestions...
  40.  
  41. (I'll UL the new drivers and program to epas ASAP)
  42. -- 
  43.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  44.  Al Dhir                                     Technical Consulting Staff
  45.  Internet: adhir@cygnus.umd.edu           University of Maryland, College Park
  46.  Bitnet:   adhir%cygnus.umd.edu@Interbit      (301) 405-1500 * (301) 405-3014
  47.