Best Choices for the ISA Sound Blasters

[NewRisingSUn]

Sort of. Some things are in stereo, while others, which should be, are not.

Hm. Looking at the MIDI files, the SBP2 recording is actually more correct than the SBP1 one, which for some reasons plays things non-centered when they should be.
I guess it's because one of the two chips runs out of voices, so a centered voice, which on dual OPL2 means it needs to be sent to both chips, will sound only on the other chip.

and (thus-far) it looks like the 2xOPL2 soundtracks can be made to play correctly on an OPL3.

I'm pretty certain that this is not possible.

[Cloudschatze]

and (thus-far) it looks like the 2xOPL2 soundtracks can be made to play correctly on an OPL3.

I'm pretty certain that this is not possible.

Isn't this what you've just done with UW1 though? :smt102

[NewRisingSUn]

No. Let's get some precision into our language.

The XMIDI driver plays the .XMI files by interpreting the MIDI event data contained in them (XMI files are basically format 0 standard MIDI files with some enhancements) and sending appropriate index and data bytes to the OPL registers. The OPL registers do not accept MIDI data, rather, the driver directly controls the generator cells --- to say it simply: what the driver does is translate MIDI bytes to OPL "chiptune bytes".
To play the same music, you have to send different chiptune bytes to 2xOPL2 vs. OPL3.

The new OPL3 driver sends OPL3-specific chiptune bytes. The old 2xOPL2 driver sends 2xOPL2-specific chiptune bytes. They both accept the same MIDI data as their input, but send different chiptune bytes as their output. In that sense, 2xOPL2 "soundtracks", that is, the MIDI files, can be played on the OPL3.

What is not possible is to manipulate the OPL3 to accept 2xOPL2-specific chiptune bytes; in other words, you can't put the OPL3 in a state in which it would work correctly with the 2xOPL2 driver.

(It is possible to manipulate the OPL3 to accept 1xOPL2-specific chiptune bytes; in fact, that is its default state; you need to explicitly switch it to OPL3 mode first to use the enhancements! And of course, once in OPL3 mode, sending 1xOPL2-specific chiptune bytes will not work either anymore; the chip will remain silent.)

Was this intelligible?

[Cloudschatze]

Was this intelligible?

This is an excellent explanation. Thank-you!


Any idea how the PAS and PAS16 are able to share the same SCI 1.1 music driver, providing stereo output for both?

[NewRisingSUn]

Well, it is possible to detect 2xOPL2 vs. OPL3 by looking at certain hardware registers.

SCI 1.1's PROAUDIO.DRV seems to make a lot of calls to some PAS-specific memory-resident program. Does the PAS/PAS16 have one? I guess that's where it knows what playback routine to use.

[Great Hierophant]

It's not the IRQ that you might run into trouble with, but the address. With the IMFC default of 2a20h, during music playback, the SBPro2 will squeal. Since the SB16 retains a similar I/O map, I imagine it will behave the same. You could always just turn the volume completely down for the SB whenever you use the IMFC though.

I don't understand, assuming the Sound Blaster 16 uses the default I/O beginning at 220h (and ends at 233h if I recall correctly), how could that possibly conflict with an address 2800h away?

[Cloudschatze]

SCI 1.1's PROAUDIO.DRV seems to make a lot of calls to some PAS-specific memory-resident program. Does the PAS/PAS16 have one?

There is the MVSOUND.SYS driver, which initializes the card, and provides hotkey volume support if left resident.

It's not the IRQ that you might run into trouble with, but the address. With the IMFC default of 2a20h, during music playback, the SBPro2 will squeal. Since the SB16 retains a similar I/O map, I imagine it will behave the same. You could always just turn the volume completely down for the SB whenever you use the IMFC though.

I don't understand, assuming the Sound Blaster 16 uses the default I/O beginning at 220h (and ends at 233h if I recall correctly), how could that possibly conflict with an address 2800h away?

I'm not sure, to be honest. The blame may be Sierra's IMFC driver though, per this tidbit:

You can still get a conflict even when addresses appear to be different, because the cards may think in hexadecimal, when their drivers don't! They may resolve them in binary format, and from right to left (we read hex from left to right). Sound cards suffer from this in particular. In addition, most I/O cards only decode the lower 10 address lines; few use all 16, which is why some S3 video cards get confused with COM4; as far as the lower 10 address lines are concerned, they're in the same place! For example, 220h (standard Sound Blaster setting) converts to 10 0010 0000 in binary. If you have a card set at 2A20, the first 10 binary digits are the same as 220 (10 1010 0010 0000 right to left, remember), so it won't work.

Why the conflict doesn't occur with the PAS16 is, likewise, unknown to me.

[Great Hierophant]

You can still get a conflict even when addresses appear to be different, because the cards may think in hexadecimal, when their drivers don't! They may resolve them in binary format, and from right to left (we read hex from left to right). Sound cards suffer from this in particular. In addition, most I/O cards only decode the lower 10 address lines; few use all 16, which is why some S3 video cards get confused with COM4; as far as the lower 10 address lines are concerned, they're in the same place! For example, 220h (standard Sound Blaster setting) converts to 10 0010 0000 in binary. If you have a card set at 2A20, the first 10 binary digits are the same as 220 (10 1010 0010 0000 right to left, remember), so it won't work.

Oh the humanity!  The stupidity never ceases.  Why did programmers assume that that no other device uses I/O above FFFh?

[NewRisingSUn]

The original IBM PC only had 10 bits for I/O (0-3FF). That limitation probably was still in the heads of many engineers.

[Great Hierophant]

The original IBM PC only had 10 bits for I/O (0-3FF). That limitation probably was still in the heads of many engineers.

I find it interesting that IBM intended the card to be used in the products available at that time, the IBM PC, IBM PC/XT, IBM PC AT, IBM PC XT/286, IBM PS/2 8525 and IBM PS/2 8530.  Which of those devices implement the full 16-bit I/O addressing space?  I know the 8088 has a 64K I/O address space.  Also, the PC/XT bus has lines for all 20 address lines.  

In short, on legacy systems, the IMFC uses 220h, on more modern systems, the card uses 2A20h.  Assuming the IMFC does decode 16-bit I/O on a system that supports 16-bit I/O, wouldn't that make it refuse to run with a program sending data using only 10-bit I/O?  The program would be sending the data to a place the IMFC wouldn't be expecting.

[NewRisingSUn]

I still don't understand why early PCs only support 10 bit port addresses, not 16 --- on the XT bus, memory and I/O use the exact same pins (A0-A19), it's just another set of pins (IOR/IOW/MEMR/MEMW) that decides whether the address on the address pins is a memory or I/O address. Same case with the 8088 CPU (M/IO pin).

The SCC-1, for example, only decodes 9 bits --- not only is 330 also at 730, 1330 and so on, but also at 338, 738 and so on. Lazy!

[Great Hierophant]

I still don't understand why early PCs only support 10 bit port addresses, not 16 --- on the XT bus, memory and I/O use the exact same pins (A0-A19), it's just another set of pins (IOR/IOW/MEMR/MEMW) that decides whether the address on the address pins is a memory or I/O address. Same case with the 8088 CPU (M/IO pin).

The SCC-1, for example, only decodes 9 bits --- not only is 330 also at 730, 1330 and so on, but also at 338, 738 and so on. Lazy!

I would guess that those lines were not properly decoded on the motherboard for I/O transfer for whatever reason.  The pins must be on an XT bus system, otherwise a whole class of add-in boards (memory expansions), would not work.  

The SCC-1 is not unique in this regard.  No important Roland ISA product or Creative Labs product before the AWE32 decodes the A10-A15.  Many other cards do not decode all sixteen lines.  Would simply grounding the pins do the trick?

[runderwo]

You can tell the difference between dual OPL2 and OPL3 by attempting to program the timer on the second OPL2.  OPL3 will not respond even in OPL2-mode.