On Tue, 07 Jul 1998 23:19:54 -0700 
 Paul Wain <pwain@nc.com> wrote:

 > Hey,

hiya...

 > > Note that I also did some playing around with using the ESS chip's
 > > sound blaster compat mode, but I couldn't get sound to come out.  I
 > > suspect this is because the OpenFirmware properties for the audio,
 > > ethernet, etc. are totally wrong on my Sharks, and I'll have to
 > > fix them w/ an nvramrc hack before the `ofisa' drivers can be sanely
 > > used.  Sigh.
 > 
 > Okay, DEC/NCI did get /dev/ossaudio working a while back (the 1.2G based
 > release - the one I still run). Having been out of the loop a bit here
 > w/respect to what people are doing with their Shaks, hang in with me. As I
 > recall, Jay Kistler had to do a lot of nasty hack work on this (there was a
 > song in the source code based on "Row Row Row your boat" entitiled "Hack Hack
 > Hack your kernel" for a while) to basically get an "almost Sound Blaster" mode

Yah... that song was one of the things I nuked :-)  Basically, that code
reserved some chunk of memory for DMA buffers... I do that in a different
way now, like the rest of the ports do.

The issue I'm running into is that the properties in the OpenFirmware that
correspond to the ESS device are _totally wrong_ (you might also notice that
the OpenFirmware properties for the Ethernet are also _totally wrong_).

The reason they work in the 1.2G-based stuff is because the properties
are "hard wired" by a layer in the middle for each device.  This is wrong
in the context of how NetBSD's autoconfiguration works.

There are a couple of ways one might solve this:

	(1) Use "machdep" callbacks for each device to deal with
	    platform-specific patch-ups.  This, unfortunately, doesn't
	    scale well.

	(2) Patch the OpenFirmware properties to what they're _supposed_
	    to be using OpenFirmware's nvramrc.

	(2a) A variant on the previous, perhaps the kernel can make these
	     patches at run-time, however, it seems better to only do
	     this on broken systems, so using nvramrc is better.

 > working to the extent that it looked like a sound blaster/au device but
 > behaved nearer an MS audio device on the back end (libossaudio is almost your
 > friend at user level - almost (*fx* Grins at Neil and Mark)).

I got it to enable the speakers (well, the headphones that were hooked up),
but nothing actually played.  Also, it took a LONG TIME to not play the
short, 5 second soundbite I had (a snippet from _A Fish Called Wanda_ :-),
so I suspect interrupts weren't working right.

In any case, this is what my Shark's boot looks like these days:

NetBSD 1.3F (JAWS) #46: Tue Jul  7 20:45:55 PDT 1998
    thorpej@jaws:/tmp_mnt/dracul/u5/netbsd/src/sys/arch/arm32/compile/JAWS
real mem  = 33554432
avail mem = 28590080
using 128 buffers containing 524288 bytes of memory
mainbus0 (root)
cpu0 at mainbus0: SA-110 rev 3 DC enabled IC enabled WB enabled EABT
ofbus0 (root)
ofbus1 at ofbus0 (vlbus)
ofisa0 at ofbus1 (isa)
dma-controller@i00 at ofisa0 not configured
interrupt-controller@i20 at ofisa0 not configured
timer@i40 at ofisa0 not configured
configuration@i15c at ofisa0 not configured
com0 at ofisa0 (serial@i3f8): ns16550a, working fifo
lpt0 at ofisa0 (parallel@i378)
ofbus2 at ofisa0 (8042@i60)
ofisapc0 at ofbus2 (keyboard@)
kbc command: 0
pc0 at ofisapc0: color
pms0 at pc0 irq 12
mouse@aux at ofbus2 not configured
power@i380 at ofisa0 not configured
ofbus3 at ofisa0 (gpio@i3e0)
eeprom at ofbus3 not configured
ofrtc0 at ofisa0 (rtc@i70): rtc
ofisascr0 at ofisa0 (scr@i24)
scr0 at ofisascr0
com1 at ofisa0 (ir@i2f8): ns16550a, working fifo
ofisacs0 at ofisa0 (ethernet@i300)
cs0 at ofisacs0: CS8900 Ethernet
cs0: address 08:00:2b:81:63:01
game@i201 at ofisa0 not configured
midi@i330 at ofisa0 not configured
sb0 at ofisa0 (sound@i220): dsp v3.01
audio0 at sb0
wdc0 at ofisa0 (ide@i1f0)
atapibus0 at wdc0
pci at ofbus1 not configured
display@it3b0 at ofbus1 not configured
ofrom0 at ofbus0 (flash@7000000): 0x7000000-0x707ffff
ofrom1 at ofbus0 (romcard@10000000): 0x10000000-0x10ffffff
clock: hz=64 stathz = 0 profhz = 0
boot device: <unknown>
nfs_boot: trying DHCP/BOOTP
nfs_boot: DHCP server: 0x81633215
nfs_boot: my_domain=nas.nasa.gov
nfs_boot: my_addr=0x81633240
nfs_boot: my_mask=0xffffff00
nfs_boot: gateway=0x816332fe
root on dracul:/u4/diskless/jaws
uvm_swap: allocated 64 swap buffer headers

I wanna try and get the game port working, too... the Shark should make
an excellent platform on which to run xmame (mmm, 1942!! :-)

PCI support is on my list, too, but I need to build an adapter so I can
plug a normal PCI card into the funky connector the IAG used :-)

(Guess I should dig out the Shark docs and figure out where PCI config
space lives :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942