GUS Daily Digest Sat, 22 Jan 94 0:07 Volume 10: Issue 22 Today's Topics: 16-bit recording 768k memory [RFI] OPTI 495SLC Chipset Addition Mega EM info Archon Ultra with GUS support CD-ROM plug incompatibility on GUS Compressed patches DOTT and GUS DRAM upgrade GUS, Windows & Graphics Corruption GUS Daily Digest V10 #21 GUS MOD players help with SB + GUS MegaEm problem MIDI Midi files on Wuarchive MIDI sound: Windows vs. DOS MODs with > 1 Mb samples Mortal Kombat discovery New GUS MIDI driver for Windows. Re**2: MegaEm and the MT-32. Reply to Faster Memory and Memory Prices SBOS v3.7 really does fix FS 5.0 Sound Blaster to GUS input line...is it safe? Submit directory etc. To Gravis re OS/2 drivers Ultrasound Internet Archives News - New policy for EPAS Why Gravis doesn't post here XMID specs Zye Technology 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: Fri, 21 Jan 1994 18:07:43 -0700 (MST) From: "Shawn T. Rutledge" Subject: 16-bit recording > > built onboard. You can't upgrade a GUS to a MAX since you can physically > > only install either a SCSI daughtercard or a 16-bit recording daughtercard > > onto a base GUS but not both. > > > > Phat. > > So the 16-bit recording option really is available, eh? Do you know how > much it costs and where I can get it? I live in the Phoenix AZ area. ------------------------------ Date: Fri, 21 Jan 94 18:16:03 GMT From: nguyen@eerie.fr (NGUYEN Francois ) Subject: 768k memory Hi, I subscribed in december to the list but during the Christmas break, my mail server went down and then I did not had time to resubscribe. I guessed I was removed from the list as no more mail from the list arrived. I only did it today, and saw many posts about memory. Over that time (december), I got a gus, and picked many softwares from epas. I had an old trident video board with 512 k memory (80 ns) and plugged it on the gus upgrading to 768 KB. Is there a reason not to do this? The first bank is 60 ns, the 2 others 80 ns. Moreover, I always see gus 256, 512 or 1024, but never 768. (However, it works fine, the memory passed all the tests ok). By the way, if anyone is looking for a good price on gravis stuff in France, I think I have the right address, ask me if you need it. TTFN Francois ' ------------------------------ Date: Fri, 21 Jan 94 12:15:15 EET From: s106275@ee.tut.fi (Saari Anssi) Subject: Re: [RFI] OPTI 495SLC Chipset > I'm "Really-Soon-Now(TM)" going to upgrade my 386/40 motherboard > to a 486DX2/66 one. One of the boards I've been offered has the > OPTI 495SLC chipset. (I don't know whether or not the 82C206 chip > is on it and the boards haven't arrived to the retailer yet so > I can't check.) > > If there's anyone out there with this chipset, could he/she > mail me or the list with any comments? I definitely won't take > the risk if someone won't tell me it has a fully functional > DMA-controller, NMI etc.. I have an MB with this chipset, currently running a 486SX-33 on it. No problems with the GUS. NMI seems to work even if I disable memory parity checking. The 82C206 is by Samsung. An initial problem was with Doom, it would crash with 'hidden refresh' enabled. Anssi ------------------------------ Date: Fri, 21 Jan 94 18:14:07 CST From: Jim English Subject: Addition Mega EM info since my previous mssg ive tested MegaEM on Xwing and had no similar errors, so it must have something to do with NHL Hockey and not my system. -jim -- ______________________________________________________________________________ Jim English - jenglish@hpc2.keh.utulsa.edu / EJP51823@vax1.utulsa.edu I do not represent the University of Tulsa in any way, but I'm sure if they wanted me too they could easily create another Vice President position and raise tuition. "Oh good heavens baby where's my medicine? Well I must have left it outside with my ettiquette." - Hotel Illness (Black Crowes) ______________________________________________________________________________ ------------------------------ Date: Fri, 21 Jan 94 9:41:52 CST From: umcoyne0@CC.UManitoba.CA Subject: Archon Ultra with GUS support Just thought I'd let all you GUS types know--I saw the new Archon Ultra the other day. Anyone who played Archon on their Apple ][ or C64 and enjoyed it will _love_ this game. It's much like the older version, but with awesome graphics, sound and just about everybody seems to have two different weapons to attack with. And.... it supports GUS! The music seems to be of the .MOD variety, as far as I can tell. The drums sound a little too techno to be MIDI, but it still sounds great. And they seem to have programmed for the GUS properly, too--no slowdown of music or gameplay while music is on. Michael ------------------------------ Date: Fri, 21 Jan 94 14:21:44 PST From: bnielsen@cclink.logicon.com (Nielsen, Bill) Subject: CD-ROM plug incompatibility on GUS I have not been able to plug the internal audio cable from my Mitsumi CD-ROM onto the GUS card, which is installed in a Gateway P5-60. The pins on the GUS card are slightly too big. The Mitsumi has a plastic four-wire connector and, I think, expects a male mate similar to the one on my CD-ROM interface board. Is anybody aware of a conversion plug or cable? Gateway recommended jumpering the audio outputs externally but I'm not sure if this is the right way to do it. I do not want to cut off the plug on the Mitsumi since it is still under warranty. Thanks for your help. Bill Nielsen, 1-800-950-0611 X2687 bnielsen@logicon.com ------------------------------ Date: Fri, 21 Jan 1994 09:57:12 GMT From: Clarke Brunt Subject: Re: Compressed patches >...so that when a patch is uploaded to the GUS >DRAM, it gets squooshed and therefore we could store more patches? > I realize patch files don't compress well to begin with... but what if >some compress/decompress routine was embedded in say, MegaEm, Ultramid, >and other files with a small TSR (if written in assembly, the TSR could >easily be under 10K, right?).. well, how to play the compressed patches.. >well, how about the TSR be a SMALL TSR (<1K) that points to a file on the >hard drive that has extended information about each patch ("extended >information" = important patch info lost during compression)... and the >TSR fills in any gaps in the compressed patch.. This sounds totally impractical to me. For all its advantages, the GUS is fairly simple in operation. You load samples into its RAM, and it plays them, possibly looping and enveloping. If you mangle the sample while loading it into the RAM, then how is the GUS supposed to play it correctly? The decompression would have to be on board the GUS, and it isn't, so it won't! ------------------------------ Date: Fri, 21 Jan 1994 09:32:48 ADT From: "Craig Galbraith" Subject: DOTT and GUS Hello people! I just downloaded upgrade.zip for the Roland and MIDI support for DOTT. I have yet to find a way to get the Roland or MIDI sound out of the game. If anyone has figured out a way to get Roland music and SB sound effects, tell me the secret. You know, the port you gotta use and whatever other settings are involved. I've tried using MegaEm but I get no music and the voices are all garbled. Thanks. Craig Galbraith j5oa@unbsj.ca are you phishsperienced? ------------------------------ Date: Fri, 21 Jan 1994 18:06:35 -0700 (MST) From: "Shawn T. Rutledge" Subject: DRAM upgrade Would anybody happen to have some used DRAM chips for sale? ------------------------------ Date: Fri, 21 Jan 94 12:43:52 From: ay-a@minster.york.ac.uk Subject: GUS, Windows & Graphics Corruption >Date: Thu, 20 Jan 94 12:23:12 GMT >From: C.S.Wood@newcastle.ac.uk >Subject: GUS and windows >Has anyone out there had trouble with the windows software, >in particular, the graphics being corrupted? >On patchman, they keyboard down the bottom is all corrupted, >and sound converter is virually impossible to use - but still >does work if you can work out where the buttons are. I also had this problem while I was running windows in a 'HiColor' mode - 800x600x64k. However, when I switched to 1024x768x256 (to get a bit more of Recording Session onscreen) all the graphics were displayed correctly. A bit of experimentation later and I concluded that for whatever reason, the programs didn't like to run in more than 256 colours. I don't know what your Windows setup is like, but I hope that this helps. Alistair. ------------------------------ Date: 21 Jan 94 09:05:00 PST From: EBULALACAO@CSUPomona.Edu Subject: Re: GUS Daily Digest V10 #21 I developed a universal menu shell program that works for virtually ANY program that you use that doesn't contain a file(s) menu interface so that you can process individual files by just selecting the file(s) to be processed. PLAYMIDI's file selection sucked, so I made my own. I designed it so that it will work for other programs like PLAYMIDI, DMP, DOS's EDIT, VPIC, etc. I'm still considering putting more features...but I want to keep the shell program as small as possible. Right now, I have a file tag, untag, sort, cursor movements, multiple pages of files (10 pages max, 100 files each page), optional program arguments, automatic search of executable file through your PATH environment...all this for just a little over 10k. Any of you guys have any suggestions for this? I'd like to release this to the public...when it's all done. Just send me a note of what you'd like added and I'll consider 'em. ------------------------------ Date: Fri, 21 Jan 94 13:40:57 -0100 From: joshua@phys4.technion.ac.il (Joshua F) Subject: Re: GUS MOD players Recently, many mod players started supporting GUS in it's native mode. The ones worth checking are: a. MDP - This is Future Crew's module player, which has the best sound quality of all mod players I know. You can find it in journey1.zip or journey2.zip, on epas. [supports MOD's and S3M's] b. IPlay - This is the relatively new Inertia Player. It's in beta status right now, but it already works pretty well. on my system I did hear some cracks and noises I didn't hear in MDP, though, but the fact that it has all sorts of screens and scopes makes it real nice, and hopefully the cracks will be nuked in the release. Some other mod players support the GUS, but are not as good as the previous two. These include DMP (which sounds relatively bad on the GUS, and plays S3M wrong), PMP (which is DMP's brother, same thing basically, just with supports bigger mod's), WOW II (which sounds ok, but worse than MDP and IPlay, plays only 4 channel mod's and DEFINITELY needs registration (if you take it as a minus)), and, well, that's about it. You can find MDP, IPlay, DMP and WOWII 2.30 on archive.epas.utoronto.ca, in the /pub/pc/ultrasound/submit dir (MDP is, as noted, in the journey?.zip files). BB. ------------------------------ Date: Fri, 21 Jan 94 14:47:02 EST From: dmcintyr@muselab.ac.runet.edu Subject: help with SB + GUS ------------------------------ Date: Fri, 21 Jan 94 17:49:22 CST From: Jim English Subject: MegaEm problem Im trying to use MegaEM with NHL HOckey. I load it up and set the emulation to MT-32. When I load NHL my system beeps twice relatively close together, and when I try to exit NHL, EMM gives me like memory error #13 or something and halts the system. I do have a Cd-ROM controller, but its on 340hex. I have tried it both with the -P and without. I dont think I have a controller at 330. Isnt SCSI a CD_ROM controller? Any ideas? (I havent tried mega em with any other programs) -jim -- ______________________________________________________________________________ Jim English - jenglish@hpc2.keh.utulsa.edu / EJP51823@vax1.utulsa.edu I do not represent the University of Tulsa in any way, but I'm sure if they wanted me too they could easily create another Vice President position and raise tuition. "Oh good heavens baby where's my medicine? Well I must have left it outside with my ettiquette." - Hotel Illness (Black Crowes) ______________________________________________________________________________ ------------------------------ Date: Fri, 21 Jan 1994 13:52:33 -0500 (EST) From: Doug Nashold Subject: MIDI How do I get channels 11-16 to get sound? I tried setting them to active through the patch map editor, but that didn't seem to work. Doug Nashold nashold@wpi.wpi.edu ------------------------------ Date: Fri, 21 Jan 1994 02:38:42 -0500 (EST) From: BR8878%ALBNYVMS.bitnet@UACSC2.ALBANY.EDU Subject: Midi files on Wuarchive I can't quite advise you all to go looking at wuarchive for your midi files. It is true that they were once in the epas which is mirrored with more disk space at wuarchive, but wuarchive just lost EVERYTHINHG. Major crash and tape drive was faulty.. That place is never stable. So keep on hunting. -joshI reaI ------------------------------ Date: Fri, 21 Jan 94 13:49:55 CST From: Jon Fletcher Subject: MIDI sound: Windows vs. DOS Hello fellow GUSers, I have just recently purchased and installed my first sound card, it's a GUS! :^). So I am still trying to learn the ropes of not only GUS but the evils behind sound cards. I have been a part of this group for quite a while now and because of this group I made the decision to go with a GUS even though, at the time, I didn't really know all the buzz words: FM-synth, wave-table synth, PAT, MOD, MIDI ect. Believe it or not this group sells the product and I think that Gravis should acknowledge that fact and at least participate (more?) in this group. Well, enough soapboxing and on to my original intent. I hope these questions aren't too frequently asked. Has anybody noticed a difference in the way a MIDI sounds when played back in Windows as to that in DOS? For example, I was playing a MIDI file, that came with my GUS, in windows (using either the MIDI player or Juker, same results) and it didn't sound the way I remembered it did when I used PLAYMIDI.EXE in DOS. The sounds under Windows were very "tinny" and not smooth and soft like they were in DOS. Why is this happening? How can I fix it? On a related/non-related subject: I have since installed the new windows drivers/mixer that came in Patch Maker Lite 1.10 (PMAK110.ZIP). Besides being a challenge (I lost all MIDI sound for a while until I figured out where all the drivers,.dll's and ultrasnd.ini files were supposed to be.) and fixing the volume problem what else are these new drivers supposed to do for us? I am still not sure if I put all these new files were they are supposed to be. Does anybody have a list of the new files and their directory they are supposed to be in. There were no directions as to what directory PMAK110.ZIP was supposed to be unzipped in so I created a directory called PMAKER and put everything there. From there I moved the ULTRASND.INI file to the C:\ULTRASND\WINDOWS directory and moved the .DLL files that came with PMAKER110.ZIP into the C:\ULTRASND\WINDOWS directory also. I restarted windows and I had no MIDI sound. After playing with the volume, which I turned all the way up making no difference, I went and tried to play with the patch loading program (sorry, I can't remember it's name) that comes with the card and you can play the patches on a keyboard. It wouldn't let me load any patches and it said I still had over 1000kb available memory. ------------------------------ Date: Fri, 21 Jan 1994 07:52:51 -0800 (PST) From: mikebat@netcom.com (Mike Batchelor) Subject: Re: MODs with > 1 Mb samples Not the GUS Server once wrote... $ $ ------------------------------ $ $ Date: Thu, 20 Jan 1994 17:01:36 -0500 (EST) $ From: Phat H Tran $ Subject: Re: GUS Daily Digest V10 #20 $ $ > Date: Wed, 19 Jan 1994 07:13:50 -0800 (PST) $ > From: mikebat@netcom.com (Mike Batchelor) $ > Subject: Re: MOD Sample sizes $ > $ > So on-board RAM is not all a bed of roses. I've yet to hear if it is even $ > POSSIBLE to play samples in "CPU-intensive" mode straight out of main $ > system memory, let alone seen an app that could do it. $ $ Play a MOD in Windows using WinMod Pro or the like. The MOD will be stored $ in main memory, and be mixed in software. Watch your system come to a crawl $ as this occurs, though. So, it's certainly possible to play MODs the CPU $ intensive way on the GUS, but I would rather not play a MOD at all than play $ it this way. And I would rather play a big MOD in some fashion than not play it all. :) Besides, I use Windows primarily as a shell for the Ultrasound driver, so who cares if it slows the PC to a crawl. :) This evening, I will put up all three of my big MODs on netcom.com:/pub/mikebat/big-mods.zip. You can grab them via anonymous ftp, and let me know if you can get them to play right in Windows. $ ------------------------------ $ $ Date: Thu, 20 Jan 1994 17:52:03 -0600 (CST) $ From: pjohnso2@ua.d.umn.edu $ Subject: Patches $ $ I had a thought... is there any way that perhaps a patch compression $ utility could be written so that when a patch is uploaded to the GUS $ DRAM, it gets squooshed and therefore we could store more patches? $ I realize patch files don't compress well to begin with... but what if $ some compress/decompress routine was embedded in say, MegaEm, Ultramid, $ and other files with a small TSR (if written in assembly, the TSR could $ easily be under 10K, right?).. well, how to play the compressed patches.. $ well, how about the TSR be a SMALL TSR (<1K) that points to a file on the $ hard drive that has extended information about each patch ("extended $ information" = important patch info lost during compression)... and the $ TSR fills in any gaps in the compressed patch.. $ Sounds like a lot of work, but I'm tired of only having one meg of $ DRAM. What was the final word on a more memory-capable GUS? Does it exist? Compression would almost certainly have to be "lossy" as the patches are already pretty durn compacted. Before the BIG HARD DRIVE upgrade, I was using Stacker, and took the patch dir off the compressed volume because I was getting only 1.0:1 compression - i.e., NONE. That's with Stacker's compression turned all the way up. PkZip doesn't make a dent in them either. But a kludge like this is no substitute for more DRAM, just as Stacker is no substitute for a 540 Mb HD. :) Something more practical would be patch caching to main system memory. Such a scheme could be made scalable, so that when a GUS with more than 1Mb comes out, the scheme could be expanded to cache everything over 8Mb to main system memory (or whatever the limit on the hypothetical GUS II would be). I think the overhead shuffling patches back and forth between GUS DRAM and main memory would be far less than any decompression algorithm. -- Mike Batchelor | mikebat@netcom.com | This space for rent mikebat@qdeck.com | ------------------------------ Date: Fri, 21 Jan 1994 10:10:18 -0600 From: ken@austin.ibm.com (Ken Goach IBM) Subject: Mortal Kombat discovery Well, I had seen several posts in comp.sys.ibm.pc.soundcard and a couple of notes in here about using a GUS and a SB in the same machine while playing MK. It seems the only way to get the game to work in this situation is to remove the GUS, or else you get the "CANNOT INITIALISE SOUND CARD!" message and no sound. I haven't tried using SBOS since I have both a SB clone and a GUS. Anyway, the first release of the game didn't support the SB-16, so I got to thinking that maybe it has something to do with the card itself (since my SB clone is "short" and the GUS is a double-length card for 16-bit DMA). So I picked SB and Roland of the sound menu and got digital sound working out of the SB! Of course, there's no music, since the Roland driver will not run the GUS. When I got the MK fix file (via ftp), it was a disaster. I got no sound from the SB (with or without the GUS in the machine) and game performance was worse. So *that's* not the answer, as far as I can tell. Wouldn't it be great if someone wrote a dedicated GUS driver for MK that you could copy over the Roland one and then select SB and Roland? I tried MEGAEM, but MK runs in protected mode, so that's out. Anyone else figured anything else out? Ken ------------------------------ Date: Fri, 21 Jan 94 10:26:20 EST From: Akintunde Omitowoju Subject: New GUS MIDI driver for Windows. Where can I get the new GUS MIDI driver for Windows...? Akintunde Omitowoju zao1@etsu.bitnet (BitNet) zao1@etsu.east-tenn-st.edu (InterNet) "I program, therefore I debug." ------------------------------ Date: Fri, 21 Jan 1994 08:22:04 -0500 From: "Michael Grant Wilson" Subject: Re**2: MegaEm and the MT-32. on Thu, 20 Jan 1994 06:13:27 -0500 wrote: > >Is the MT-32 support from MegaEm supposed to include downloaded sounds? > No. > > If not: is there some reason why this wasn't included? > It's a synth. The downloaded sounds are settings for the synth to create > new sounds. You don't expect Mega-Em to create corresponding digital > samples, I hope. > I agree that the mt32 is a synth, but I'm not sure that's particularly relavent. My model of the way the mt32 is used for game sfx is essentially that the downloaded sounds represent source waveform data (i.e. they are loaded into sample ram) that contain the basic sound. Of course, the capability is there to modify these sounds, but that isn't normally used (if it was, then most games would sound lousy even for the normal instrument patches). Even if they are doing some synth programming, eating the basic waveform and playing it back would be better than playing random instrument noises for sound sfx like most mt32 games do now. Is this totally incorrect? (I certainly don't know! I'll believe anybody whose actually programmed an mt32). Having said that, there isn't anything *inherantly* impossible about having Mega-Em "create corresponding digital samples" for particular patches on *any* synth. Admittedly, it requires a fairly accurate model of the synth engine which is being emulated, and usually some interesting math, but such a program can always be written. Of course, optimizing it to be small/fast enough to be a TSR that runs in real time would probably be difficult. McQ ------------------------------ Date: Fri, 21 Jan 94 09:12:25 EST From: "Burns Fisher, VMS Engineering 21-Jan-1994 0916" Subject: Re: Reply to Faster Memory and Memory Prices >I upgraded by GUS to 1MB as soon as I got it. I went with a local retailer >for memory, and it ran me around $45 to go from 256K to 1MB. That's about what I paid too, though it was a year ago. >The faster memory, the better! Just make sure it's at least as fast as >the memory the card came with, and make sure that each bank has the same >speed of memory (i.e. each row of two chips must be filled with two >identicle chips). Otherwise, the faster the chip, the better the >performance! What in the world would ever make you think that? I don't mind speculation, but please identify it as such. The fact is that memory chips have know way to tell you when they have gotten your data. That means the GUS itself has no clue as to whether you have 100ns chips or 70ns chips. It just puts a request for a particular address on the memory bus, hits a stobe line, and then waits for a fixed amount of time, presumably about 100ns, and then pulls the data of the memory bus. If the data was actually there in 70ns, it does not help a thing. Now there has been speculation and even a few anecdotal incidents to indicate that it may be good to have consistent speed chips throughout. It's not clear why this should be, but you might as well play it safe and try to get the same type. Maybe if you get 70ns chips the incident of failure at 100ns is lower. (The latter is speculation!) But no one has ever claimed better performance for the card with faster chips! Burns ------------------------------ Date: Fri, 21 Jan 1994 08:53:17 -0600 From: Don Eller Subject: SBOS v3.7 really does fix FS 5.0 I've been hearing so many good things about the new Sbos v3.7 that I wanted to try it even before I saw a reference somewhere that FS5 might really work with it. Unfortunately, I must be really dense, I never noticed there was a gravis.bbs subdirectory under epas...../submit, until I found a reference to it in pc.fltsim newsgroup. Or maybe this is a new subdirectory? Anyway, I downloaded Sbos v3.7 and after playing around, found the settings that do work for FS5 and provide true digital sounds, without cutting out. I used the Sbpro with DMA 1 and IRQ5 in FS5 config, and voila. If anyone is interested and wants information on my complete configuration, hardware and software, just ask and I'll post it. I also noticed that the new Sbos includes settings for a variety of things, including Carmen.exe (which I take to be Where in the World is Carmen ...). Unfortunately, maybe because I have the CDrom version, mine still locks up just as I start working on the case, and I have to reboot. The only way I've been successful in completing a case is by using Megaem with Roland music only. If digital effects are enabled, it allways locks up, with every configuration I've tried over the last couple of months. If anyone has been able to get the CDRom version of this game running, please let me know. This is the only Broderbund CDrom game that I have, everything else seems to work great with Megaem. Course now I'll have to go back and compare everything with the new Sbos, I think most things will probably work now, if I can find the right settings for Sbos. ------------------------------ Date: Fri, 21 Jan 94 10:22:47 EST From: Akintunde Omitowoju Subject: Sound Blaster to GUS input line...is it safe? Has anyone hooked a their Sound Blaster into their GUS? I mean that I have a Sound Blaster v1.05 and a GUS in my machine, and I want to route the output of my SB into my GUS's line-in input. But I was wondering whether this was safe or not...Any advice would be greatly appreciated. Thanks... =) Akintunde Omitowoju zao1@etsu.bitnet (BitNet) zao1@etsu.east-tenn-st.edu (InterNet) "I program, therefore I debug." ------------------------------ Date: Fri, 21 Jan 1994 18:05:16 -0700 (MST) From: "Shawn T. Rutledge" Subject: Submit directory etc. > > 1) what is the full path to epas submit directory? I only have email access > > and need to put in a ftp request to Genie sysop for the Master of Orion AIL > > drivers that Jerry Gamache kindly coaxed out. > > /pub/pc/ultrasound/submit > > > 2) When was the faq last updated? Got mine in August '93... > > Just transferred my subscription to a different address, and the FAQ was sent > along with the subscribe notice. It was dated some time this month, I believe > the 14th. ------------------------------ Date: Fri, 21 Jan 94 09:19:13 EST From: Phil Longstaff Subject: To Gravis re OS/2 drivers To Gravis: thank you for the news (and thank you to f.graham) re OS/2 drivers. I think what got many people upset was the silence as much as (or more than) the lack of drivers. A thought: I don't know what your progress is, but you might be able to get drivers more quickly by working with one of the people (e.g. Robert Manley) who seems quite far along (I assume you know of his progress by reading the group comp.sys.ibm.pc.soundcard). If you and he, working together, could produce an MMPM/2 driver which also included SBOS/MegaEM support, so I could get sound from all of my DOS games, it would be a fantastic achievement which would leave me forever in your debt. I know you can't always predict when software will be ready, but I think the idea posted here a while ago about sending out an update every 2 weeks would be a great idea. Phil Longstaff, Motorola Codex, Mississauga Ontario ------------------------------ Date: 21 Jan 94 21:22 -0800 From: Thomas Wong Subject: Ultrasound Internet Archives News - New policy for EPAS GRAVIS ULTRASOUND INTERNET ARCHIVES NEWS ========================================================================== FTP SITE: wuarchive.wustl.edu DIRECTORY: systems/ibmpc/ultrasound archive.orst.edu pub/packages/gravis nctuccca.edu.tw PC/ultrasound EUROPEAN CALLERS ONLY: theoris.rz.uni-konstanz.de pub/sound/gus MIRROR: garbo.uwasa.fi mirror/ultrasound SUBMISSIONS: archive.epas.utoronto.ca pub/pc/ultrasound/submit NEWLY VALIDATED FILES: archive.epas.utoronto.ca pub/pc/ultrasound MAILSERVER FOR ARCHIVE ACCESS: Send email to ------------------------------------------------------------------------- Background: ----------- As most of you have already read, the Ultrasound archive is growing at an incredible rate. So quickly that EPAS can't keep up with the growth. So I'd solicited suggestions from people here on the net and from the digest. And I thank you for the replies. But after MUCH discussions between us, the administrators, we have decided that most of those (and our own as well) suggestions will only be goof on a temporary basis. We have moved things off and add disks to EPAS and so forth before. The growth had always outgrew our predictions. The contibutions themselves per month are doubling every 1/2 year. This may not sound much but we are already getting 20 megs of new files each month. By summer, we should be getting 50 Meg. Now these numbers are not too much of a worry for our other sites which are all full archives of our Ultrasound Archives. But EPAS has limited resources hence we have decided to look towards the long haul... New plan for EPAS: ------------------ EPAS will now be a submission and newly validated files site for our Ultrasound Archive. In other words, submissions still go to the EPAS, under the same directory, pub/pc/ultrasound/submit. But EPAS will no longer carry the Ultrasound Archive itself.... the bulk of it anyways. What this means is EPAS will still carry the directory structure of our archive, but not the files itself. But what I'll do is whenever I finish validating the latest batch of files, I will move them to the corresponding directories under the directory structure in EPAS. Hence EPAS will also hold the new files for the last validation period. And when I do another batch of validation, the old files gets removed and the new ones gets placed into the corresponding directory. This way, not only does it free up tons of space, we will not reach the limits of EPAS again until contributions reaches 200 Meg a month... :) And if we out guess the growth again, we'll see this happening by... tomorrow! And also, if you keep uptodate with the latest happenings of GUS, or at least my announcements for file validations, you can go to EPAS and grab only the latest files (with mget * for example) and not have to weed through 10 screenful of listings with a "dir". EPAS will have the latest files. And hopefully, traffic to EPAS will also die off.... There are exceptions to every rule of course.... the digest will probably remain onboard and updated on EPAS. The full digest archive that is since it doesn't take up that much room. And we'll see if there is anything else we may have to make an exception for. Now remember, this only effects EPAS. All the other archives and mailservers are and always will be full archives. Please access those for our complete list of Ultrasound files. When will this go into effect? ----------------------------- This weekend. I will find some time tomorrow to get the ball rolling, clear out EPAS, and move the files I'd already validated a month ago to the correct directories, so that I can go and validate more files that have already been sitting in the submit directory for another month. So if you want the archive itself, please start accessing the other sites as described at the top of this message. Now what? --------- Nothing much... have to go wash the dishes, catch the latest... or at least get updated on the latest scandals and international calibre trials down in the States.... oh you mean the archives? Well, I'll get started tomorrow, if I can hog the phone line for a couple of hours. :) And I'll let you all know when I'm done, and what I've done, when I'm done, what I've done...... :) Thomas. cat /dev/null > ~/.sig ------------------------------ Date: Fri, 21 Jan 1994 10:49:57 -0700 (MST) From: jknepley@nyx.cs.du.edu (Jim Knepley) Subject: Why Gravis doesn't post here > Date: Thu, 20 Jan 94 07:30:00 BST > From: f.graham@genie.geis.com > Subject: OS2: Gravis SPEAKS! > It's weird how we get such great feedback on Genie and _none_ here lately. > There's obviously a lot more people here than on Genie, though we're also > picking up a lot of converts on Genie. I guess, a lot of GUS has happenned > since no one's stuck with answering the plethora of similar queries this > digest (unavoidably) gets, and except for news, we're doing fine ourselves... I've had a theory about why nobody from Gravis posts here for a while. This seems to be as good a time as any to share it... If memory serves, John Smith et al flew the proverbial coop after a rather intense round of MORONS telling them that they suck. People bitching about support, compatibility, availability, drivers, just about EVERYTHING. _I_ sure wouldn't have stuck around a place where IGNORANT NAESAYERS were bashing not only my company but ME PERSONALLY (yes, many of the attacks were against John Smith personally). It's a shame that we don't get the updates that we once did, and I would have those who RUINED it for all of us TAKEN OUT AND SHOT given the chance. Well, that's my theory about why we must have people forward us GUS news from Geni, it's too bad because I LOVE my UltraSound... Jim ------------------------------ Date: Fri, 21 Jan 1994 13:27:16 -0500 From: jgamache@AIX1.si.usherb.ca (Jerry Gamache) Subject: XMID specs Sorry for the crossposting, my interest is music in a game context. I am trying to make an initialisation file for ultramid that will preload all the patches specific for a game. I have all the XMID of that game and I need a way to know which patches are used. This is my second attempt on this subject, I kept it short. Any help will be welcome Jerry ------------------------------ Date: Fri, 21 Jan 1994 14:50:32 +0000 (GMT) From: Mark Charsley Subject: Zye Technology Does anyone have Zye Technology (UK distributor of the GUS)'s Tech Support no.? Ta. Mark ------------------------------ From: (null) I left the PMAKER.EXE & PMAKER.HLP file in C:\ULTRASND\PMAKER the directory that I unzipped PMAK110.ZIP in. I put the new .DLL files in the C:\ULTRASND\WINDOWS directory. I put new ULTRASND.INI file in BOTH the C:\ULTRASND\WINDOWS directory and the C:\ULTRASND DIRECTORY. Even though the directions in the README file indicated it was supposed to be put in the C:\ULTRASND\WINDOWS directory (why in the world are there 2 ULTRASND.INI files!??). I notice new volume controls that actually retain the volume settings and of course the patch maker program. Is there anything else that should've been upgraded/noticed? Is the above file placement O.K.? On another related/non-related rookie subject: I've noticed that some MIDI files come with .cfg files that contain the paterns they use. Now my question is: who loads these .cfg files to the MIDI player? Is there something embedded in the actual .mid file that tells the MIDI player about the .cfg file? Or is there an option/switch I have to feed the MIDI player along with the .cfg file? -- -------------------------------------- Jon Fletcher | UCI/Unified Communications, Inc. | Bloomington, MN 55425 Software Engineer | email fletcj@tenfwd.uci.com | -------------------------------------- ------------------------------ End of GUS Daily Digest V10 #22 *******************************