SGI: Hardware

Testing unknown audio hardware CL TP0033

Dear All,

I am in the process of getting an SB0090 card for my sound-lacking Fuel. As it happens I have a rather simple
audio card (Creative ECTIVA TP0033, Vendor ID 0x1102 and device 0x0006) lying around and was aching to find out
whether the associated driver can be tweaked to accept this cheapie. Following the ideas of substituting these PCI vendor/device
keys which are used to register the card at the system with substitutes (as for the tg1 Copper cards) I changed the emu_dd.o driver
accordingly and waited what would happen. Just a quick autoconfig -vf and then it was time to boot...

Well the system didn't crash and went normal until the screen turned black and I was expecting a hardware reset.
But eventually (after 10 nail-biting seconds) it recovered with some PCI related complaints (what else would you expect at that stage..)
and continued booting as nothing ever happened. Well then I tried the hard inventory and to my absolute surprise I got a reported
audio card:

Iris Audio Processor: version EMU revision A0, number 1

All audio panels and applications worked, BUT of course NO sound was emitted from the speakers, except a click when I muted the sound
on the apanel.

What have I learned: By modification of PCI card drivers you get them at least to boot on this system - whether it'll work is whole different story.
So, I am thinking of getting at least one Terratec Aureon Cards (sky or space, not Fun and all the others) which have exactly the same
audio chip (Envy24HT ICE1724) as the M-Audio revolution 7.1 series. They all go for around 10-20 Euros on eBay if you'd find one, while
the latter is hardly ever for sale (at least in the non-US world).

Attached: stock picture of the audio card I played around with.

Creative_Ectiva.jpg
Creative_Ectiva.jpg (55.54 KiB) Viewed 331 times


So best of luck in case you guys like to test an unknown card on your SGI system and maybe an unexpected jewel can be discovered.

Regards
Stefan
0x8b5812b4|0x393d9bd5|0x40c945ac|0x46d36521|0x612fd0f5
welcome ssch1034 and thanks for the insight. reports like this are always welcome :-)
r-a-c.de
Thanks ssch1034, and let me echo foetz' welcome to nekochan.

On the odd chance you haven't already seen them or might find them useful, there are links to a few SoundBlaster/EMU related posts in the
The IP35 (Fuel, Tezro, O300, O350) Hardware Aggregator ; there was a brief disucussion on discovering compatible EMU10k1 boards a few years back; and there's some background info on audio devices (including EMU-based variants) in the audio library resources man page.

Is the TP0033 an EMU-based device? Be interesting to know what's hiding under the ECTIVA label on your board.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
What editor did you use to change emu_dd.o? If I may be so bold as to enquire... :shock:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:
vishnu wrote: What editor did you use to change emu_dd.o? If I may be so bold as to enquire... :shock:


Dear Vishnu,

I just used hexedit, which is probably part of the nekochan's freeware. Hope that helps.

Regards
Stefan
0x8b5812b4|0x393d9bd5|0x40c945ac|0x46d36521|0x612fd0f5
recondas wrote: Thanks ssch1034, and let me echo foetz' welcome to nekochan.

On the odd chance you haven't already seen them or might find them useful, there are links to a few SoundBlaster/EMU related posts in the
The IP35 (Fuel, Tezro, O300, O350) Hardware Aggregator ; there was a brief disucussion on discovering compatible EMU10k1 boards a few years back; and there's some background info on audio devices (including EMU-based variants) in the audio library resources man page.

Is the TP0033 an EMU-based device? Be interesting to know what's hiding under the ECTIVA label on your board.


Thanks for the advice. I'll check the card and let you know. I wonder however, why would IRIX look it up in the patched emu_dd.o rather than
mad_dd.o or rad_dd.o if it wasn't a EMU card? As I only modified this object and got IRIX to accept it I am sure it must have been the correct
object file. After all the entries in emu_dd.o were already close to the IDs of this card (If I remember correctly I changed the device
from 0x0004 to 0x0006 or vice versa as the vendor id was the same). The thing is that the hardware might be different, but you're right - it
is worth checking.

I am currently bidding on ICE1724HT Cards and see how I go with these M-Audio equivalents (at least from a chip-wise perspective they should be compatible).

Another big endeavour would be to write your own PCI driver. But that is probably way out of reach unless you have a great deal of experience.

Cheers
Stefan
0x8b5812b4|0x393d9bd5|0x40c945ac|0x46d36521|0x612fd0f5
recondas wrote: Thanks ssch1034, and let me echo foetz' welcome to nekochan.

Is the TP0033 an EMU-based device? Be interesting to know what's hiding under the ECTIVA label on your board.


There is absolutely nothing printed/etched onto the chips surface! That's odd.
Other sources identify it as a OPTi 82C929A with 20x30x2 pins
ectiva-tp0033-driver.jpg
ectiva-tp0033-driver.jpg (5.21 KiB) Viewed 198 times

which can also be found on a legacy ISA (16-bit) sound card


Regards
Stefan
0x8b5812b4|0x393d9bd5|0x40c945ac|0x46d36521|0x612fd0f5
ssch1034 wrote: I wonder however, why would IRIX look it up in the patched emu_dd.o rather than mad_dd.o or rad_dd.o if it wasn't a EMU card?

All that matters is which file has the correct vendor/device ID pair. Rather than thinking that IRIX looked up the card in emu_dd.o, you should think of it as IRIX looked in all the driver files until it found the matching vendor/device ID. Basically, you told IRIX to use emu_dd.o, and IRIX trusted you.

ssch1034 wrote: As I only modified this object and got IRIX to accept it I am sure it must have been the correct object file.

Don't be so sure. I suspect you could modify any driver file to have your card's vendor/device ID and get IRIX to recognize the hardware as whatever corresponded to that driver. Of course the hardware wouldn't actually work, but IRIX would try to use any driver you told it to.

ssch1034 wrote: After all the entries in emu_dd.o were already close to the IDs of this card (If I remember correctly I changed the device from 0x0004 to 0x0006 or vice versa as the vendor id was the same).

That doesn't necessarily mean much. It's normal for different products from the same vendor to require very different drivers, regardless of their device IDs.

In fact, looking at device IDs from the Linux driver for the EMU 10K series soundcards, device IDs 0x0002, 0x0004, 0x0008 all use the same emu10k1 driver, while device ID 0x0006 uses the completely different emu10k1 x driver. Note that Creative and Ectiva both use vendor ID 0x1102. So what you have there is a clone of a similar, but different sound card that the IRIX driver won't be able to use. The fact that the device IDs are close is meaningless.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500
HP C8000