Ultrasound Daily Digest Mon, 29 Mar 93 Volume 2 : Issue 84 Today's Topics: FTP SITE ADMIN GMOS Mailing List honesty vs salesmanship IRC discussions Miditest.exe: MIDI port tester on epas More GMOS mt32.zip on epas Ultrasound Daily Digest V... Ultrasound Daily Digest V2 #83 Zone 66 - Parity Errors Information about the UltraSound Daily Digest (such as mail addresses, request servers, ftp sites, etc., etc.) can be found at the end of the Digest. *** HEY!!! *** Before you ask a question, *** READ THE FAQ ***. It's available on the request server and the ftp sites, or check the newsgroup archives. ---------------------------------------------------------------------- Date: Sun, 28 Mar 93 20:03:36 MST From: ddebry@itchy (Dave DeBry) Message-Id: <9303290303.AA05811@itchy> Subject: FTP SITE ADMIN To: Ultrasound Daily Digest The digests up through v02i83 have been uploaded to epas. Remember that we go to v03 on April 1st (no joke! :) . -- Dave ddebry@ debry@ \ "All this has been removed for the last 48 hours DeBry dsd. peruvian. | and I have a doctor prodding the angry swelling es. cs.utah. | on my porch." com edu / ------------------------------ Date: Sun, 28 Mar 93 19:40:08 MST From: ddebry@itchy (Dave DeBry) Message-Id: <9303290240.AA05404@itchy> Subject: GMOS Mailing List To: Ultrasound Daily Digest There has been a lot of volume about the "GMOS" concept lately, with a potential for a lot more. So, I've created a GMOS mailing list. It's a reflector, but like the other reflectors, it may become a digest if the readership and volume go up enough. Mail to: gmos-request%itchy@dsd.es.com to subscribe. -- Dave ddebry@ debry@ \ DeBry dsd. peruvian. | "They sent the chicken bone to the lab. It es. cs.utah. | came back 'chicken bone'." com edu / ------------------------------ Date: 29 Mar 1993 16:01:28 +1000 From: PHTH1@cc.newcastle.edu.au Message-Id: <01GWDWRMO7HU9LYKE9@cc.newcastle.edu.au> Subject: honesty vs salesmanship To: Ultrasound Daily Digest Regarding the line, "being overly critical of a $150 sound card"... Thank you to the Gravis rep for all that information. It is most useful, and also very encouraging to have official representation on the public network. As far as the quoted remark is concerned, I for one am far more impressed by honesty than propaganda. The fact that you guys are prepared to (a) face up to the problems, and (b) do something about them, inspires far more confidence in me than the typical line, "Our product is the absolute best, it has no problems, it will never break, it works with everything" etc. etc. etc. Thanks again for a great sound card, and for the after-sales support. Tony ------------------------------ Date: Sun, 28 Mar 93 09:41:22 +0200 From: Shmuel Gazit Message-Id: <9303280741.AA12464@ccsg.tau.ac.il> Subject: IRC discussions To: Ultrasound Daily Digest Hello GUSers ! I've seen some ppl here talking about a discussion in a Newsgroup. While this can be nice, I want to suggest another idea - since many of us are on internet, why not use IRC (Internet Relay Chat system) for online discussions ? we are on different time zones, thats true, but I'm sure it can help in developing and just chatting.. If u don't know how to get on the system, ask somebody who knows how to connect (your Admin, someone at the CC, etc..) if u do enter, and look for a channel - enter #GUS c u all there :) /Shmulik. ------------------------------ Date: Sun, 28 Mar 93 23:52:02 WET From: dp@hydra.carleton.CA (Dave Perry VE3IFB) Message-Id: <9303290452.AA09055@hydra.carleton.CA> Subject: Miditest.exe: MIDI port tester on epas To: Ultrasound Daily Digest I have put miditest.zip on archive.epas.utoronto.ca. This is a program to monitor the midi input. I know something like this already exists, but I could only find one for Windows, not DOS. This program runs in a DOS session, which is handy when you aren't sure whether your Windows installation is correct. Enjoy. Dave Perry dp@hydra.carleton.ca ------------------------------ Date: 29 Mar 1993 01:17:16 +0800 From: TC Message-Id: <01GWD22SBOG2A9LIX1@NTUVAX.NTU.AC.SG> Subject: More GMOS To: Ultrasound Daily Digest > Actually it doesn't even require the cooperation of the conpanies. I am > sure there are more than a few hackers out there, who could decipher the > GM instructions in games, and make a "patch" for such games to remap the > whole game to 1meg worth of patches. I wonder why no one caught the reference to option (3) which I mentioned should allow GMOS to determine the patch changes during a particular run. For example, you run 'GMOS -cxwing.cfg' and GMOS will collect any MIDI patch change information throughout this particular session and save it to a .cfg file. It can then load this file later to load the required patches. Of course, this is not fail safe. A program might need more than 1MB worth of patches throughout the whole run. Thus, dynamic loading will STILL have to be supported. This way we won't see people posting 'does anyone have a patch map for so-and-so game?'. They can do it themselves. > Also, as far as dynamic patch loading goes, this would take some pretty > smart coding, or else how would the GMOS know which patches to clear to > make room for the new patches. The one used least frequently? The largest You have to trade off something for this dynamic loading method. The simplest way would be in terms of the oldest patch that has not been accessed (this means it assumes that the program no longer needs that patch since it has not used it for a long time). The problems with this is mainly in management of the GUS memory. Allocating and deallocating patches dynamically creates "holes" in the memory map of the GUS, and since a patch has to be sequential, either we have to 1) move the patches around in the GUS's memory, or 2) preallocate certain number of slots (configurable, eg via 'GMOS -b32' for 32K max for each patch) for patches. .tc ------------------------------ Date: 28 Mar 93 0:01 -0800 From: Thomas Wong Message-Id: <3321*twong@civil.ubc.ca> Subject: mt32.zip on epas To: Ultrasound Daily Digest Yup. I made a booboo. I have now moved mt32.zip from ....sound/patches/util to .....sound/midi/files. Thanks for catching that. I haven't made the change on wuarchive yet though. If you find any errors on the ftp sites, please either post it or let me know. Thanks. Thomas. ------------------------------ Date: Sun, 28 Mar 93 13:58:41 EST From: pccmoddan@aol.com Message-Id: <9303281358.tn10481@aol.com> Subject: Ultrasound Daily Digest V... To: Ultrasound Daily Digest John Smith wrote: > I know that a lot of people have said that its OK to put both a > GUS and SB in the same machine. I also know that some people > have had some success doing just that. However, it is really > not a good idea. There are some very solid hardware reasons NOT > to do this. Even though you can move the I/O address and IRQ that > SBOS uses so that it will not conflict with the SB, you cannot > move the DMA channel. SBOS and the SB both use DMA channel > 1. I use both an SB Pro (set to Irq 7, address 220, and DMA channel 1) and a GUS (set to Irqs 5 and 11, address 240 and DMA channel 3) in the same machine (a 486DX-33 (with an >opti< chipset) with absolutely no problems, including when testing software with SBOS. (When SBOS is run software completely ignores the SB Pro and detects SBOS as an SB perfectly). But this would not apply to most people. However, if all that conflicts is SBOS and the SB, what is the problem? Almost anyone with both a GUS and and SB in the same machine would not be using SBOS at all, so it seems they wouldn't have any problems, just as I haven't. I've talked to many more people who are running both in the same machine with no problems than people who tried and had problems. Short of having hardware SB emulation on the GUS, there's no better way to run SB software. - Dan Nicholson ________________________________________________________ Dan Nicholson - PCkS Associates - (908)964-8066 - ModDan 553 Thoreau Terr. Union, NJ 07083 ________________________________________________________ Support RAM based wavetable synthesis. ________________________________________________________ ------------------------------ Date: 28-MAR-1993 13:41:01.41 From: Richard Wyckoff Message-Id: <01GWCEV265IO8Y5QQE@EAGLE.WESLEYAN.EDU> Subject: Ultrasound Daily Digest V2 #83 To: Ultrasound Daily Digest [A word about Xwing, again...] > From: Eric N. Liao > Subject: GMOS > Anyway, next time I run X-Wing, I will try the MPU-401 setting. > Also, I found that John Smith's solution to game slowdown during digitized sfx > works perfectly. I find this a little ironic, considering that I (and others) posted this solution long before John got around to it...well, it's "John Smith's solution" now, I guess :) [actually, I got one supportive email when I posted it, so I'm not *really* complaining.] > You have to shut off music, and then (at least for me) there > is no longer that slowdown associated with firing lasers. I'm not sure why > so many people are blaming Lucasarts...seems more like a problem with > Creative Labs to me. Look, the SB1.5 actually DROPPED the on/board CMS stereo > chips (buy them separately for $30.) Like they really cost that much. This > gives you an idea of Creative Labs' early products. I don't think much of Creative Labs (anymore) but I'm still more than convinced that the slowdown is due to poor programming, not 'slow DAC'- WC II played digitized sound and FM music simultaneously without the HUGE performance hit in Xwing - it's possible, of course, that they had to use a crummy digitized sound output routine in order to get the otherwise incredibly high frame rate, but still... Also, while those CMS chips might not have cost $30, they certainly weren't crap, and it's a real shame that Creative Labs stopped including them, or we might have had stereo music in games years ago. I know that the difference in music in Ultima 6 and Sorcerian with Game Blaster (CMS) vs Adlib was *very* noticeable, but it's the old lowest common denominator again. *sigh* [And now for something completely different - sample noise] > From: "Loking... Searching" > Subject: Gus Notes and 16 bit Daughter Card and NOISE!! > Another question regarding sound quality, I've read some where, I believe from > Phat, that the GUS is one of the most "quietest" sound cards out there. Now, i > f I get the 16 bit record daughterboard, which I would like to very much, will t > he samples come (%5 tolerance at the most! ) to CD quality.. I know this is adv > ertise as so. But the fact is. that There is noise! > I'd like also to know the final answer to the question of why there is > noise when recording a NULL signal... and the solution. I'm quite concerned about this issue, too. I have observed two things about sample noise: 1) 8-bit samples (.WAV format, mostly) have an enourmous amount of noise in them. I have tested this by generating a 16-bit raw sample in the OS/2 beta of Csound which I am testing, and then using Wave for Windows to turn it into both an 8-bit and a 16-bit .WAV file. The 8-bit sample always sounds like there is a noisy fan recorded in the background; the 16-bit sample is as clean as you could hope. I wonder if this is another example of just plain crappy Microsoft code? 8-bit sound naturally can't reproduce the full frequency spectrum of a sample, but it shouldn't induce noise. This may explain the null sample noise problem. Observation 2) When the GUS microphone in is turned ON (as it is by default) there is a TON of noise all the time. Now, I have the worst amplifier in the world, so I can't say for certain if turning OFF the mic will eliminate all the noise, and I haven't bothered making any recordings off of CD through the line in, because of this Windows 8-bit .WAV problem that I've already discussed. I will say that before I started fooling around with gusmixer, I could hear video writes and disk writes (even though my video card is three or four slots away from the GUS) and now I don't. My projected solutions, for the arrival of the 16-bit daughtercard: NEVER use the mic in. If you are sampling for music or multimedia, you won't get acceptable quality through a mic anyway, and you're going to record all the background noise that your computer generates (fan, etc) even if you can isolate the electronic interference. If you need voice, tape it in a quiet room, then run the tape into the line in. Hopefully, all of this will cut the noise down to an unnoticeable minimum. -- Multimedia: You mean I could fill up my hard disk annotating spreadsheets with digitized voice when I'd been foolishly conserving space by using text? Why didn't *I* think of that! Bill Gates, my hero! **Richard Wyckoff**RWYCKOFF@EAGLE.WESLEYAN.EDU** ------------------------------ Date: Sun, 28 Mar 93 00:17 MST From: Message-Id: <9303280718.AA02700@orca.es.com> Subject: Zone 66 - Parity Errors To: Ultrasound Daily Digest Has anyone else had trouble running Zone 66? When I first tried it, it gave me one of the infamous "off board parity errors" and promptly locked up. It was on ly by disabling the parity checking in my CMOS settings that I got it to work. I just want to find out if there's a valid, but harmless, reason for it, or if something's actually wrong with the card. Could this be an example of a 16-bit DMA problem? That'll be the next thing I try. Oh, on the subject of Zone 66, is there any way to shut off the Line In while pl aying? I ended up unplugging mine, as the mixers didn't work. --John (pccjohnb@aol.com) ------------------------------ End of Ultrasound Daily Digest V2 #84 ****************************** Digest Address: ultrasound@dsd.es.com To post to tomorrow's digest Request Server Address: ultrasound-request@dsd.es.com To subscribe, unsubscribe, and request files Owner Address: ultrasound-owner@dsd.es.com To contact a human if the server has troubles FTP Sites: archive.epas.utoronto.ca pub/pc/ultrasound wuarchive.wustl.edu systems/msdos/ultrasound