First post, by 640K!enough
In a recent discussion, Marmes asked me to look into the reason that Impulse Tracker refuses to work with Orpheus boards (other than the InterWave on Orpheus II). The result of that is a revised WSS driver that takes a different approach to detecting the hardware.
The "problem" with the original drivers is that they either probe a limited set of I/O addresses (that are not appropriate for the cards in question), or expect to find the configuration interface of the original Microsoft design. All of these approaches fail on Orpheus. The simplest solution was to start with the original GUS Max driver (which uses the on-board CS4231 CODEC), and replace most of the detection routine. The resulting driver is attached.
The original port probing is (mostly) gone, and we instead rely on the ULTRA16 environment variable set by ORPHINIT (when invoked via ORPHEUS.BAT) and the installation routines for the original GUS 16-bit daughterboard and GUS Max. If it doesn't find it, or it's obviously invalid, "detection" will fail. Any IRQ line or DMA channel supported by the hardware should work. I/O addresses are currently limited to 12-bit (FFFH or less), which should be workable for most current hardware.
To use the driver, simply de-compress and copy it into your IT directory, then IT will have to be invoked with IT /sITCS.DRV.
This has been tested and confirmed functional on Orpheus and Orpheus II LT. Additionally, it should work on any card bearing an AD1848 or CS423x or compatible (Ensoniq Soundscape series, GUS PnP, GUS Max, GUS with 16-bit daughterboard, Audiotrix Pro, original Windows Sound System board and many more). For those whose installations don't define it, it should be as simple as setting an environment variable before running IT, as follows:
SET ULTRA16=base_address,playback_DMA,IRQ,0
The base address is the actual CODEC address, not the control/configuration port; this is often 534H by default. As an example, for Orpheus one would typically use SET ULTRA16=534,1,5,0 (or similar).
Depending on the sources you read, there is some disagreement about the format of the last part, but this will nonetheless work most of the time.
In my testing, playback quality was generally very good, and any problems appear to be related to IT playback bugs. In all honesty, I haven't (yet) changed anything other than the detection routine, driver name and mixing rate, so I don't expect to have introduced any new problems. Of course, I'm open to feedback and discussion, if anyone has problems.
