Ultrasound Daily Digest Wed, 28 Apr 1993 Volume 3 : Issue 28 Today's Topics: Alone In The Dark Problems (I'm being flamed!) Bundled GUS software GUS and MOD... what about the PAS16 ! GUS information wanted! New PUBLIC SDK kit os/2 and ultrasound RAM-failure RAM speeds SBOS w/ games Sound player Star Control II bug fix more info Trying to shed some light on DRAM memory speed. Meta-info about the GUS, this digest, and other GUS resources can be found at the end of the Digest. Before you ask a question, please READ THE FAQ. ---------------------------------------------------------------------- Date: Tue, 27 Apr 1993 12:10:41 -0300 (ADT) From: Shadow Of Fear Subject: Alone In The Dark Problems (I'm being flamed!) Message-ID: People are jumping on my back because I tried to help them. For those who were experiencing problems with SBOS and Alone In The Dark, I suggested to configure the game for SoundBlaster with no DMA. Now, I'm being flamed because it slows down the game and they can't play. I gave the suggestion uppon my own experience. I have AITD with SBOS 2.04 and I have *almost unnoticable* slow downs and you know what? I'm playing this game on a 286-16. When I saw that it worked for me (SB with no DMA), I passed the word. It doesn't work for some, well find something else!! It worked for me and I gave the trick. Now, stop flaming me. I received the same treatment for Space Quest V (where I could trick the SB bug). ____ _ _ _ / \ \ /' )' )' ) | | | / / / | (_|__/ \ / / __. .__ ___ | | __. . . \ . ___ / (__(_/|__) )__/(__ \_/__(_/|__)\_)__/\__)__) <_ Markus on QuartzPARADISE and AfterFive (506)855-4974 - Canada +---------------------------------------------+-----------------------------+ | markus@info.umoncton.ca | "My son, ask for thyself | | For Talk: markus@clement.info.umoncton.ca | another kingdom. For that | |---------------------------------------------+ which I leave is too small | | When all else fails, read the instructions | for thee" - King Philippe | +---------------------------------------------+-----------------------------+ ------------------------------ Date: Tue, 27 Apr 1993 17:02:33 +0100 (BST) From: Simon Watson Subject: Bundled GUS software Message-ID: I've read several posts from GUS owners complaining about not receiving the promised extra software. Obviously the situation is different in the US because here in the UK, Optech (the official UK GUS distributor) has been busy sending out a pack of six disks to owners who registered with them. The pack contains the five v2.04 installation disks, along with an extra HD disk labelled 'GUS bonus software'. This latter disk is installed separately to provide PowerChords, Midisoft Recording Session, Gusmod, some extra MIDs, and a windows utility to convert sound files between the .WAV .VOC & .SND formats. Overall, I'm quite impressed with both PowerChords and Midisoft. Both are labelled as Ultrasound-specific versions, probably implying support for patch cacheing. PowerChords seems more guitar orientated but can still handle standard MIDs and can compose tunes of any style. Midisoft Recording Session is reasonably full-featured sequencer using standard musical notation together with a sort of 'virtual' mixing desk. It's a bit quirky but still one up on Winjammer. I'm currently having some probloms with the patch cacheing in Midisoft so I hope you other GUS owners get your copies soon and can give me a hand! -Simon P.S. My bonus disk was not accompanied by any written documentation. ------------------------------ Date: Wed, 28 Apr 93 02:45:11 GMT From: jknepley@nyx.cs.du.edu (Jim Knepley) Subject: Re: GUS and MOD... what about the PAS16 ! Message-ID: <1993Apr28.024511.8414@mnemosyne.cs.du.edu> ReprintFrom: comp.sys.ibm.pc.soundcard In article <1993Apr27.085421.66814@cc.usu.edu> sl859@cc.usu.edu writes: > > Can it be that we humans are just on a too limited perspective or >reference frame to fully comprehend the grandeur of GUS!? Can we really >hope to attain the level of complete and absolute GUSdom? GUS is not an >object, it is a state of being! A feeling that is fostered by a mother as >she pulls her helpless child against her bossom and nurtures it with her >very own essence! To comprehend the GUS you must open yourself to the >universe! Yea verily! GUS is not an object, it is also a way of life! To not understand GUS is to not understand deep rooted primal desires! To understand GUS is to understand the workings of your own soul. When we finally see the full splendor of GUS, all those who have faith will relish in the second coming of GUS and mock those whose faith was not as deep. Beware the false prophet! Mere words do not a legend make, the savior will have a chorus of voices to sing praise. The antiGUS will merely have a duet. > Now go thy way and be one with GUS... > > wReam... > The Chief Accolyte to the High Realm of GUS Ranseus First Deciple of GUS -- ----- jknepley@nyx.cs.du.edu (formerly knepley@cs.colostate.edu) ----------- Jim "Ranseus" Knepley | Avoid rectal-cranial inversion. Programmer, magician, | "Gun's don't kill, it's those bullet things" computer geek. | ------------------------------ Date: Tue, 27 Apr 1993 06:31:30 GMT From: seah@ee.rochester.edu (David Seah) Subject: Re: GUS information wanted! Message-ID: <1993Apr27.063130.6399@ee.rochester.edu> ReprintFrom: comp.sys.ibm.pc.soundcard In article ptran@sciborg.uwaterloo.ca (Phat H Tran) writes: >In article magnuz@lysator.liu.se (Magnus Rindeberg) writes: >>First: I heard that the GUS has 32!! 16-bit voices, are they hardware-voices? >> i.e. are there 32 DAC's on this board ??? ( I suppose not ) >> If not 32 then just how many hardware-voices are there?? > >It seems fairly certain that the GUS converts all of its 16-bit voices >to analog before mixing them. This suggests that the GUS has 32 DACs, >or some hardware equivalent of that. (In a $130 card? *shrug*) >Anybody have a block diagram of the card's circuitry? Here's some information that might be helpful. This is my interpretation of the material in the Apple IIGS Hardware Reference, so feel free to question its validity. The Ensoniq Digital Oscillator Chip (DOC) on the Apple IIGS multiplexes the output of its oscillators (the "voices"). If the IIGS DOC were capable of spitting out 32 simultaneous 44.1kHz waveforms at once, it could have 32 separate DACs playing all at once (as Phat suggests). This would be rather expensive. The Ensoniq 5503 DOC instead time multiplexes the output of its oscillators. What this means is that there is one DAC that is shared by all 32 oscillators. For each oscillator to be serviced 44100 times per second, this single DAC would have to be capable of performing an D to A conversion 32x44100 = 1,411,200 times per second (one every 0.71 usec. [Whether the 1.4MHz conversion rate for D/A is possible to do cheaply, I'm not sure...comments?] Here's a diagram that illustrates the theoretical operation of the GUS blasted 32 16-bit oscillators at 1,411,200 samples per second... 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -- -- -- -- -- -- -- -- -- ---- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ---- -- -- -- -- -- <------------ 22 usec period ----------------------------------> Each oscillator (more accurately "address generator") points to the current data value that represents the output level. Once you put this output through a good low-pass filter, the high frequency noise is filtered out and you end up with an average output value without all that mucking around with analog mixers. I'm sure this scheme generates some amount of theoretical distortion, but I'll leave the signal analysis to someone else who knows more about it. Qualitatively, if you perform a lowpass filtering operation over the data above (representing one sample at 44100 samples/sec), I believe you get the same result as doing a digital sum & shift. Or something really close :) To get multi-channel sound (stereo), the oscillators have a few control bits that are accessible external to the 5503. Each oscillator can be assigned a channel, and these control bits can be used to drive an analog multiplexer to tap the unfiltered output shown above. --- Now, whether this applies to the GUS at all is debatable. From what I've heard, the GUS's GF1 is a close relative of the Ensoniq 5503, licensed by Forte. I was told this during an informal visit over xmas to Forte when a friend and I wanted to check out the USS10X software. So perhaps this is close...if someone has some kind of guide to the GUS's control registers then we could compare and see if there are any simularities. -- Dave Seah (seah@ee.rochester.edu, AFCDaveS@aol.com) ------------------------------ Date: Tue, 27 Apr 1993 16:43:34 -0700 From: Eric N. Liao Subject: Re: New PUBLIC SDK kit Message-ID: <199304272343.AA16084@aerospace.aero.org> This is a response to John Smith's post that the new SDK is almost done. He mentioned that the new SDK kit will be "PUBLIC." Does this mean no more non- disclosure agreement? Does it mean we can get it for free? Any elaborations? Any idea as to when we'll start seeing GUS-3D in games? ------------------------------ Date: Mon, 26 Apr 93 23:53:06 +0100 From: thomas@blackhl.hacktic.nl (thomas van kuipers) Subject: os/2 and ultrasound Message-ID: <8qym3B1w165w@blackhl.hacktic.nl> To work with the ultrasound and os/2 2.x may seam very difficult, but i have got it working in a DOS-box already with just the normal SET commands it just works in a dos-box. I hadn't get it worked in WINOS/2 3.1 (within os/2 2.1b), but i assume it might work because of the drivers (under windows 3.1 i had it worked) and the dos settings. I'm now wondering if anyone or GRAVIS has a driver for the ultrasound to work with os/2 2.x multi media package. (You can't use a sbos or other emulation, because that runs on dos, not os/2 base level). It don't matter if it's beta, because i just try it out! Thanks, Thomas (reply to:thomas@blackhol.hackit.nl) ------------------------------ Date: Tue, 27 Apr 93 16:33:56 WETDST From: his@hiogron.rhg.nl (Henk Hindriks) Subject: RAM-failure Message-ID: <9304271633.AA03073@hiogron.rhg.nl> Hi Ultrasound-users, Recently someone (sorry I forgot the name) complained about Ram-failure after upgrading the Ultrasound-card from 256Kb. to 1Mb. I experienced the same problem: Ultraram and Setgus telling me that I have a DRAM-failure while swapping the RAM's doesn't help anything. After some research I found out that the failure is in the highest 128K of the memory independent of the IC's, so it's problably a wrong adres-decoding. But what chip is to blame for that? If i try to locate the adres-decoder I find some GAL-chips special made for Gravis. It looks like a wrong production-series.!!!! So please everyone try the Ultraram or the Setgus (advanced-diagnostics) to find out if Your ultrasound functions O.K. Reports here please. If it is a production-series with this failure we should complain at Gravis. I don't like to return my card and having to live without it for a long time because the local dealer never heared about the problem. Things tend to take a long time overhere, because the Ultrasound is marketed by a company called Logitec who sell there own sound-card as well. Henk Hindriks Rijkshogeschool Groningen The Netherlands his@hiogron.rhg.nl ------------------------------ Date: Tue, 27 Apr 93 8:32:55 CDT From: wiegand@void.rtsg.mot.com (Robert Wiegand) Subject: RAM speeds Message-ID: <9304271332@lido16> > From: Joe Cheng > 2) DRAM Problems : I was having some problems before when I upgraded my GUS > to 1 Meg on board with 70ns DRAMS. Using GUSDRAM, DRAM, > GUSMEM, etc. to check the system, it would give really wierd > errors like some times reporting all the memory good, sometimes > telling me that one bank was out, or that I only had 768K. > It turns out that one chip in bank two was loose and giving me > all those headaches. Apparently the repeated cycle of heating > and cooling from the computer loosened that chip and made it > pop out a bit (this is after I really pushed all the chips in > to make sure they were seated). The 80ns drams should be ok > as I couldn't find any real data on discrepancies between > standard 256x4's. Using 70ns drams, I was told to replace > bank one also with 70ns otherwise the board still run's at > 80ns because the data will bottle neck with the slowest > denominator. Personally, I can't tell the difference between > 70ns and 80ns, I guess my brain just can't move quick enough > to pick up that extra 10ns. Anybody notice it different? I have seen a number of people making the same mistake. Putting faster memories on the GUS *does not make it run faster*. The board still runs at the same speed as before. You are just throwing away your money if you buy faster RAMs than the board requires. The memory access speed is set by the DRAM controller logic on the board, not by the RAM chips. The RAM chips just have to be fast enough to keep up with the controller, getting faster RAMs doesn't help anything. Bob Wiegand ------------------------------ Date: Tue, 27 Apr 1993 06:24:38 -0600 (CST) From: "Neil D. Danylczuk" Subject: SBOS w/ games Message-ID: ------- - 1 - GOBLINS ------- How is the game Gobliins _supposed_ to sound with GUS? For me, the sound effects are quite right, except for some of them. Footsteps come through the PC speaker while the music and sound effects come through the GUS. Are the voices supposed to be realistic? Here, they sound distinctly "Goblinny", that is, I can't recognize what is being said at all. This is with many different versions of SBOS. ------- - 2 - HUMANS ------- What is the prefered way to get "Humans" to work? The readme file says 2 things: either use SBOS -o3 (version 1.20) or get a patch from the Gravis BBS. Is anyone aware of this patch, and can we get it on epas? I can't check the SBOS1.20, as 1.21 is the oldest version I have here. ------- - 3 - MONOPOLY (Virgin Games) ------- I receive A LOT of Windows errors with this game. Is it because of the GUS? Has anybody else seen this? I can simply ignore the errors and nothing seems to go wrong, it's just annoying being interrupted every 2nd roll or so. Is it sound drivers or video or Monopoly? ------------------------------ Date: Tue, 27 Apr 1993 05:22:03 -0400 (EDT) From: Greg K Chung Subject: Sound player Message-ID: Ever since I realized how simple it is to play music and sounds on the GUS, I've been hacking away, writing a multi-format sound player for our beloved GUS. It will support the most common sound formats (for playing): .VOC, .SND, .SAM, .WAV, (maybe .AU) as well as music formats like .MOD, .669, .STM This program initially started as just a .MOD player, which I've been trying to load up with useless features that test the GUS's prowess. For example the Satan-detector reverse-sample mode... But seriously, one thing I would like to get working [in the .MOD player] is have greater control over panning and oversampling. The way I understand it, the GUS just controls the volumes of the L,R channels to simulate panning. Expanding on this, it should then be possible to have much greater control over panning, by playing the same sample on two voices, one fully Left, the other fully Right, and then sliding the volumes of each manually. (Is this theory correct?) Otherwise, I can just simulate a 31 position panning by using two voices for each sample, where the mean average of the two would be the 'apparent' panning position? That is, with voice 1 at position 7, and voice 2 at position 8 (or 1 at pos 0, 2 at pos 15), I would get a balance of 7.5, which should be a true center. Additionally, I don't fully grasp how the oversampling works. Ultradox says that the GUS always uses at least 14? voices. Using more voices, even if nothing is played on them, results in a significantly different sound. If someone could explain this to me, I'd be greatly appreciative. As far as my .MOD player goes, I've implemented some rudimentary 'features' which I hope will make it a nice GUS program (since alas, it seems Josh has quit playing with GUSMOD and moved on to other things). I'm playing with the above mentioned panning control and oversampling control, and I put in the reverse sample playback (for kicks). Additionally, since real 'live' performances (eg playing a guitar, or speaking into a mic, etc) normally use echo, I put in an additional voice that plays back the same sample a few milliseconds later (at lesser volume), which, I have found, makes for a richer sound in many cases. One more major change: I allow up to a volume of 128, since for some reason, there are a lot of .MODs that violate the 64 volume maximum. I'm also stealing some ideas from MODPLAY that were left out in GUSMOD, like the .GIF background and speed control. On the other hand, I'm not stealing the playback code, so the playback doesn't quite sound correct in some cases. But -- I suspect GM was based a whole lot on code used by MP, since certain .MODs (most notably a few from SC2) cause the same problems (samples sound incorrect) in both programs but not in mine. Wierd. Anyway -- the point of all this -- this project would be greatly accelerated if Gravis would finally release their developer's kit. The ultradox are nice, but incomplete. I would like to see Gravis include a COMPLETE description of the features and of programming the GUS whenever they send out the 'new disks'. After all, most of the GUS's sold have been thru word-of-mouth on the net, and most of the software is written by individuals, not software companies. Gravis should do as much as it can to foster software written by the public at-large, because that is the key to leading commercial developers into the market and a greater consumer base. Please Gravis, repay your early customers, let them know details about the GUS, let them know how to code something that can RECORD! Forgive me for taking up so much space ... Greg ------------------------------ Date: Tue, 27 Apr 1993 15:42:53 +0501 (EDT) From: Gunnar Swanson Subject: Star Control II bug fix more info Message-ID: To James Hargrave, Hi James I believe that you asked about the StarControl 2 bug fix. I read about the fix in this months (April) Computer Gaming World aka CGW. On the next to last pages there is always a little thing on bug fixes for popular games. It listed Star Control 2 as having a fix out 1.03 or other. If you cannot find a copy of the magazine write me and I will check at the local mall and get back to you. But it is ka rather popular magazine and any large newsstand should have a copy. Good luck finding the patch. My address is gunnar@gibbs.oit.unc.edu Bye Gunnar P.S. I finished the whole Star Control 2 saga. IT IS EXCELLENT. I still hate the arcade stuff though. If you want hints E-mail me a question and I will help you. end. ------------------------------ Date: Tue, 27 Apr 93 11:36:54 CDT From: eason@ncrnd3.StPaul.NCR.COM (Dale Eason) Subject: Trying to shed some light on DRAM memory speed. Message-ID: <9304271636.AA26359@ncrnd3.StPaul.NCR.COM> I am an electrical engineer and logic designer. Some people have wandered about the DRAM speed issue and if it was ok to use faster DRAMs than the 100ns type and if it would have an effect on the performance of the GUS. Most computer memory access logic is timed by some sort of clock circuit. This clock is used to tell the logic how long to wait for data to become valid after sending DRAMS the address. Once designed this wait period is constant unless special provisions are made to change it. The GUS does not have any user option to control its wait time for DRAM. Therefore it is designed to wait for a time appropiate for 100 ns accesses DRAMS. Putting faster DRAMS in the GUS will not hurt it but will not speed it up either. It will simply give the DRAM the address it wants to access, wait , and then use the data presented by the DRAM. It cannot tell that the DRAM gave it the data faster than expected. Why did they use 100 ns DRAMS when now all you can find are 70s or better? It takes time to bring something to market. 100s were probably what was available at the time so that was what the timing called for. Or perhapes the chip that uses the drams cannot use the data any faster than that. So they wrote the spec to be conservative and use the least expensive chip availble at the time. To access memory at a sample rate of 44100hz * 32 voices only requires one access every 708 ns. The DRAM speed is put to use during DMA transfers from the mother board to the GUS. Dale Eason ------------------------------ End of Ultrasound Daily Digest V3 #28 *************************************