From owner-freebsd-hackers Wed Jan 4 00:27:34 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA17267 for hackers-outgoing; Wed, 4 Jan 1995 00:27:34 -0800 Received: from feta.cisco.com (feta.cisco.com [171.69.1.158]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA17261 for ; Wed, 4 Jan 1995 00:27:32 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id AAA05168; Wed, 4 Jan 1995 00:26:01 -0800 Message-Id: <199501040826.AAA05168@feta.cisco.com> X-Authentication-Warning: feta.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Jordan K. Hubbard" Cc: peter@bonkers.taronga.com (Peter da Silva), hackers@freebsd.org Subject: Re: Recommended sound card for 1.1.5.1 In-Reply-To: Your message of "Wed, 04 Jan 1995 00:16:46 PST." <16098.789207406@time.cdrom.com> Date: Wed, 04 Jan 1995 00:26:00 -0800 From: Paul Traina Sender: hackers-owner@freebsd.org Precedence: bulk > To: Paul Traina > Cc: peter@bonkers.taronga.com (Peter da Silva), hackers@freebsd.org > Subject: Re: Recommended sound card for 1.1.5.1 > Date: Wed, 04 Jan 1995 00:16:46 -0800 > From: "Jordan K. Hubbard" > > > Well, I'm going to be different. I say the GUS (Gravis UltraSound) is the > > card of choice for both BSD and DOS. It is -not- SB compatible (in hardware) > , > > but has the advantage of being the only card that I am aware of that can > > The reason I never recommend the GUS is the simple reason that it > often seems to get its knickers in a twist with FreeBSD and needs to > be reset from *DOS*. This is just not a bug I'm willing to overlook > when considering it as a recommendation. If someone can somehow > figure out just what the GUS needs to set it up (run it off a diag > extender while DOS is booting and capture the commands? :-), I might > change my opinion. > > Jordan I'd be happy to bring up my GUS and drop it in your box if you want to do that. Amancio claimed he disassembled the GUS's ultrainit.sys and is programming it the exact same way. He told me he had it working from UNIX and gave me patches that I tried with no joy. I've *finally* found (two days ago) some info on programming the bastard, so in my copious (hah hah hah) free time, I'm going to try again. I'm under the impression that any I/O to a non-gus address between a certain reset command and completion locks out initialization changes to the GUS. I find this difficult to believe, but the first thing to do is change the definition of OUTB during system initialization because someone made it do an outb() to a non-GUS location to slow things down... SIGH. :-(