VOGONS


First post, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie

Hi everyone.

I'm trying to set up a non-PnP ISA CT2230 board under Solaris 8. All the jumpers are in their default positions (IRQ 5, IO address 0x220, 8-bit DMA channel 1, 16-bit DMA channel 5):

sb16_ct2230.jpg
Filename
sb16_ct2230.jpg
File size
539.17 KiB
Views
578 views
File comment
Creative Sound Blaster 16 (CT2230)
File license
CC-BY-4.0

The sound card proved 100% operational and capable of playing 16-bit PCM samples under a modern Linux as well as Windows 2000 (I had to previously dedicate IRQ5 to Legacy ISA in BIOS, which is Award 6.00PG).

Technically, Solaris 8 supports Sound Blaster 16 and clones using the sbpro driver:

The Device Configuration Assistant (DCA), which is effectively the DOS kernel running in real-mode, mis-detected my board as "ADS Sound Blaster" (Analog Devices ADS7180), most probably because the card is non-PnP, and ADS7180 is just the 1st matching line in /boot/solaris/devicedb/master:

ADS7180 sbpro oth all sbpro.bef "ADS Sound Blaster"

prtconf -p:

        Node 0x194b08
compatible: 'ADS7180'
dma-channels: 00000001.00000005
interrupts: 00000005
model: 'ADS Sound Blaster'
name: 'sbpro'
reg: 00000001.00000220.00000014.00000001.00000388.00000004.00000001.00000330.00000002
unit-address: '1,220'

prtconf -D:

        sbpro, instance #0 (driver name: sbpro)
Driver properties:
name <chosen-interrupt> length <8>
value <0x050000006e660000>.
Register Specifications:
Bus Type=0x1, Address=0x220, Size=0x14
Bus Type=0x1, Address=0x388, Size=0x4
Bus Type=0x1, Address=0x330, Size=0x2
Interrupt Specifications:
Interrupt Priority=0x5 (ipl 5), vector=0x5 (5)

Now, the problem.

Despite /dev/audio and /dev/audioctl devices got created just fine and, judging from the prtconf -D output, the sbpro driver got attached to the device, I'm only able to send an 8-bit PCM data to the card. This means that, for example, XMMS must be told to programmatically "downsample" the data (from 16-bit to 8-bit PCM) before sending it to the hardware, slightly increasing CPU usage and greatly reducing sound quality (rendering the card useless for MP3 playback), while other applications simply produce no sound (they simply block while trying to play anything).

I tried to install the OSS package ([1], [2]), but out of the 3 versions tested (3.9.8b, 3.99.4e, and 4.2-2004), only version 3.99.4e proved to be working (tested with the on-board C-Media CMI8738), and that very OSS version literally crashes my system when trying to set up the SB16 ISA card in question (it warmed my heart when, during the next boot time, Solaris told me it was saving the kernel crash dump under /var/crash).

Besides, OSS and Sun Audio are two separate hardware interfaces and, since CDE and OpenWindows applications only work with Sun Audio, I'd rather stick with this HW interface -- this is the reason I haven't ordered an OSS license yet.

Solaris' mixerctl produces the following output:

mixerctl -i -v
Device /dev/audioctl:
Name = SUNW,sb16
Version = 4.13
Config = SB16

/dev/audioctl doesn't support the audio mixer function
Sample Rate
Play 8000
Record 8000
Channels
Play 1
Record 1
Precision
Play 8
Record 8
Encoding
Play 1 (u-law)
Record 1 (u-law)
Gain
Play 191
Record 191
Balance
Play 32
Record 32
Port
Play 0x00000002 (HDPHONE)
Record 0x00000004 (CD)
Avail Ports
Play 0x00000002 (HDPHONE)
Record 0x00000007 (MIC|LINE|CD)
Mod Ports
Play 0x00000002 (HDPHONE)
Record 0x00000007 (MIC|LINE|CD)
Samples
Play 0
Record 0
Active
Play 0
Record 0
Pause
Play 0
Record 0
Error
Play 0
Record 0
EOF Count
Play 0
Waiting
Play 0
Record 0
Open
Play 0
Record 0
HW Features 0x00000018
PLAY
RECORD
SW Features 0x00000000
SW Features Enabled 0x00000000

I also tried to diagnose my hardware using the javax.sound API, and it looks like the card (from the Solaris perspective) does support 16-bit sound:

Details
/dev/audio (SB16), version 4.13
Name: /dev/audio (SB16)
Description: Direct Audio Device: Solaris Mixer
Vendor: SUNW,sb16
Version: 4.13
Source lines:
interface SourceDataLine supporting 8 audio formats, and buffers of at least 32 bytes
PCM_SIGNED 44100.0 Hz, 16 bit, stereo, 4 bytes/frame, little-endian (default)
PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
interface Clip supporting 8 audio formats, and buffers of at least 32 bytes
PCM_SIGNED 44100.0 Hz, 16 bit, stereo, 4 bytes/frame, little-endian (default)
PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
Target lines:
interface TargetDataLine supporting 8 audio formats, and buffers of at least 32 bytes
PCM_SIGNED 44100.0 Hz, 16 bit, stereo, 4 bytes/frame, little-endian (default)
PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
Port /dev/audio (SB16), version 4.13
Name: Port /dev/audio (SB16)
Description: Solaris Ports
Vendor: SUNW,sb16
Version: 4.13
Source lines:
MICROPHONE source port
LINE_IN source port
COMPACT_DISC source port
Target lines:
HEADPHONE target port

What else can I do in order to make my SB16 card work properly?

Update

I ended up buying an AWE64 (CT4380) card, it got successfully detected by Solaris and turned out capable of playing 16-bit sounds.

So I can consider my Solaris/x86 build complete.

Attachments

  • solaris.png
    Filename
    solaris.png
    File size
    677.58 KiB
    Views
    407 views
    File comment
    Solaris CDE desktop
    File license
    CC-BY-4.0
Last edited by unix_junkie on 2021-04-25, 15:48. Edited 1 time in total.

Reply 1 of 6, by Tiido

User metadata
Rank l33t
Rank
l33t

This SB16 and all other non-PnP ones have their IRQ and DMA set by software, and your driver must specifically be able to do it.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 2 of 6, by weedeewee

User metadata
Rank l33t
Rank
l33t
unix_junkie wrote on 2021-04-14, 11:42:

I'm trying to set up a non-PnP ISA CT2230 board under Solaris 8. All the jumpers are in their default positions (IRQ 5, IO address 0x220, 8-bit DMA channel 1, 16-bit DMA channel 5):

Ok, so the only thing you can actually set for the sound part side of that card is the base IO, which tends not to be a problem.
https://stason.org/TULARC/pc/sound-cards-mult … R-16-MCD-A.html

reg: 00000001.00000220.00000014.00000001.00000388.00000004.00000001.00000330.00000002
unit-address: '1,220'

This line doesn't inspire confidence about the exact IRQ and DMA being used by the driver.
I read this as it using
one of the IDE IRQ's (14 or 15) and possibly dma 1 for the base IO at 220,
IRQ 4 for the FM synth at IO 388 and
IRQ 2 for the MPU part which is located at IO 330

I got hardly any experience with solaris so can't direct you where to solve it.

Right to repair is fundamental. You own it, you're allowed to fix it.
How To Ask Questions The Smart Way
Do not ask Why !
https://www.vogonswiki.com/index.php/Serial_port

Reply 3 of 6, by megatron-uk

User metadata
Rank Oldbie
Rank
Oldbie

I'm curious about your intended use (and platform) of Solaris 8 x86.

I've used Solaris (and previously SunOS) quite a bit, mainly on Sparc hardware, although a little bit of the later x86_64 kit from around the time Sun invested heavily in Opteron based systems (which were actually really nice machines). But it was never particularly great in terms of multimedia (I did some programming with the Open Sound System back in my University days - I wrote a multi-threaded voice-over-IP application way before Skype or H263 protocols were ever a thing, but this was on on Linux and Unixware as well as the DMedia API on IRIX, iirc] ); just wondering what it is you're doing with it?

My collection database and technical wiki:
https://www.target-earth.net

Reply 4 of 6, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie
Tiido wrote on 2021-04-14, 12:20:

This SB16 and all other non-PnP ones have their IRQ and DMA set by software, and your driver must specifically be able to do it.

Thank you for your response.

In fact, this SB16 has its IRQ initially assigned by BIOS, and I'm about to try and change the value from 5 to 2, 7 or 10, all of which are supported values, according to Sun Microsystems.

I can also change the audio I/O address to 0x240, 0x260, 0x280 using jumpers.

If I'm not lucky with this board -- I have a PnP AWE64 (CT4380) which arrived just today. This latter card should work just fine.

Reply 5 of 6, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie
weedeewee wrote on 2021-04-14, 12:22:

Ok, so the only thing you can actually set for the sound part side of that card is the base IO, which tends not to be a problem.
https://stason.org/TULARC/pc/sound-cards-mult … R-16-MCD-A.html

Thanks, that's what I'm about to do!

weedeewee wrote on 2021-04-14, 12:22:
This line doesn't inspire confidence about the exact IRQ and DMA being used by the driver. I read this as it using one of the I […]
Show full quote

This line doesn't inspire confidence about the exact IRQ and DMA being used by the driver.
I read this as it using
one of the IDE IRQ's (14 or 15) and possibly dma 1 for the base IO at 220,
IRQ 4 for the FM synth at IO 388 and
IRQ 2 for the MPU part which is located at IO 330

I've never thought of deciphering the (raw) output of prtconf -p, but prtconf -D (assuming the right driver is attached) already provides the same information unscrambled =)

Reply 6 of 6, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie
megatron-uk wrote on 2021-04-14, 14:37:

I'm curious about your intended use (and platform) of Solaris 8 x86.

I've used Solaris (and previously SunOS) quite a bit, mainly on Sparc hardware, although a little bit of the later x86_64 kit from around the time Sun invested heavily in Opteron based systems (which were actually really nice machines). But it was never particularly great in terms of multimedia (I did some programming with the Open Sound System back in my University days - I wrote a multi-threaded voice-over-IP application way before Skype or H263 protocols were ever a thing, but this was on on Linux and Unixware as well as the DMedia API on IRIX, iirc] ); just wondering what it is you're doing with it?

  1. This is actually a first-love-like thing =)

    I've used Solaris 8 on SPARC hardware quite a bit -- in my University days, too.
    The only difference I was doing Java programming, not C or C++.

    And I fell in love with CDE, and Motif, and OpenWindows. Yes I know they're ugly, but still...
  2. Apart from that, I have quite a bunch of Sun software to play with, incl. SunNet Manager to do some SNMP monitoring, and various versions of Forte Developer (some of them also include X-Designer).
  3. Next, the Matrox G450 card plugged into my x86 hardware is capable of 1600x1200x32bpp resolution, and none of my SPARC machines can do the same, not even those with hi-end UPA graphics of the time. So this PC machine can serve as a decent terminal, while the noisy SPARC machines can be moved to the basement while being still accessible over the network.
  4. Last but not least, hardware rottens when not in use, and I just have enough hardware to build another retro PC running Solaris/86, so why not?