No luck for me. I added SET BLASTER=J201 but CheckIt still can't see it.
Or should I add the whole bunch of parameters? UNISOUND seemed to be happy with just that.

Edit: uh, so the joystick works in Prince of Persia. Weird. I'll try other games.
Edit: and so does Loom and SimCity.
And Silpheed, the game that prompted me to ask

I guess it's CheckIt that's broken then.

For the first time I'm trying to get two Sound Blaster compatible cards on the same system. One for SB16 and other for SB pro support. I'm using AWE64 Gold for SB16 support and one of the Yamaha YMF based cards for SB pro and real OPL3. The YMF based card is just like the one on philscomputerlab except mine has IDE included.

Here is a picture after unisound has done its work.

So it does what it is supposed to do and everything works! I would have not tried two SB compatible cards without unisound. But there is one issue. Unisound sets YMF control port to 370h and that might be problematic. It is also used for secondary IDE control block registers (IDE base + 200h). I changed the YMF control port to 270h and it seems to be working.

I'm using Asus VL/I-486SV2GX4 mainboard and as it is VLB-based it might have the reset bug with the YMF. I have not yet experienced it (not much testing so far) but sharing the control port with IDE registers certainly does not help.

aitotat wrote on 2021-08-05, 03:10:

For the first time I'm trying to get two Sound Blaster compatible cards on the same system. One for SB16 and other for SB pro su […]
Show full quote

For the first time I'm trying to get two Sound Blaster compatible cards on the same system. One for SB16 and other for SB pro support. I'm using AWE64 Gold for SB16 support and one of the Yamaha YMF based cards for SB pro and real OPL3. The YMF based card is just like the one on philscomputerlab except mine has IDE included.

Here is a picture after unisound has done its work.

So it does what it is supposed to do and everything works! I would have not tried two SB compatible cards without unisound. But there is one issue. Unisound sets YMF control port to 370h and that might be problematic. It is also used for secondary IDE control block registers (IDE base + 200h). I changed the YMF control port to 270h and it seems to be working.

I'm using Asus VL/I-486SV2GX4 mainboard and as it is VLB-based it might have the reset bug with the YMF. I have not yet experienced it (not much testing so far) but sharing the control port with IDE registers certainly does not help.

The only 37x ports used by the secondary HDC are 376 and 377. The others are used by the secondary floppy controller, if present. I'm not familiar with the yahama port mapping but it's well possible they don't use more than 6 registers starting at 370

I wanted to report an "behavior" Im seeing with an opti 82C931. Im running this card along side an Avance Logic board. Setting up both cards works fine. I can run midi on the opti card and sound blaster on the Avance.
The only issue at this point was conflicting OPL outputs and ive been trying to find the best way to control it. The Opti OPL is garbage and the avance has a yahama chip.
I first tried to turn off the OPL port on the opti either by F0 or F398, which did not work.
I can solve the problem by turning off the Avance Line in volume. Another idea i have is if any of the volumes on Opti can turn it off but without effecting the Midi out.

But the real issue ive encountered doing this is with the Opti card. I think it comes down to too many calls through unisound in a short period of time causes the opti to corrupt its eeprom and bring down both cards. Once it happens neither cards are detected by unisound.
I can fix it by using a opti driver program sndinit.exe to setup the card and then sndtune.exe to write the eeprom again (it might only take sndtune.exe by itself, but i didnt try that yet)
I dont know if this is something unisound might be doing wrong or should it be effecting to wait some between executions.

Pickle wrote:

... But the real issue ive encountered doing this is with the Opti card. I think it comes down to too many calls through unisoun […]
Show full quote

...
But the real issue ive encountered doing this is with the Opti card. I think it comes down to too many calls through unisound in a short period of time causes the opti to corrupt its eeprom and bring down both cards. Once it happens neither cards are detected by unisound.
I can fix it by using a opti driver program sndinit.exe to setup the card and then sndtune.exe to write the eeprom again (it might only take sndtune.exe by itself, but i didnt try that yet)
I dont know if this is something unisound might be doing wrong or should it be effecting to wait some between executions.
.....
I first tried to turn off the OPL port on the opti either by F0 or F398, which did not work.
I can solve the problem by turning off the Avance Line in volume. Another idea i have is if any of the volumes on Opti can turn it off but without effecting the Midi out.

Thank you for reporting.

About the eeprom issue, It's highly unlikely caused by Unisound. The initialization (PnP and Opti propietary regs) should be safe, only using audio settings or known resources regs. Just in case, I tried an Opti 931 card + ALS100 card on my system, I ran Unisound about 1 hundred times with different combinations, first Opti, First ALS, then reverse, then only Opti, Only ALS, with different BLASTER parameters... All of them without delays as you suggested (I used BAT files to test)... No problems here. Eeprom is OK.

I checked your last post here: Re: Help with trying to fix Opti 82C931 with QDsp QS1000
As you did not update it with more info (you said you'd do more testing), I guess the issue with the eeprom did only happen once? If not, please explain here the details of the tests you've done and the times the issue appeared (if using Unisound). Otherwise, you may check if other things are present in the equation that could cause the issue.

As a side note, Unisound has a special command line option (It's documented in the TXT) to force detection of cards with partially corrupted EEPROM: /XXF
If a card is detected that way, it will be shown as "BAD CHECKSUM".

About the OPL port issue: I checked in my system: First with the Opti card alone (without ALS100 plugged), I see that it works as intended, if I set F398 for example, Adlib does not sound in games which use default 388 port.
Then I tested with both cards plugged and I got mixed results, sometimes it works, sometimes it doesn't.
As I didn't test thoroughfully the combination of these two specific cards in the same system previously, I'll definitely do more tests and will see if it's possible to find some workaround for this.

In any case, please, let me know the precise details of your system, cards and method / order of initialization, to have the maximum amount of info for the investigation of any issue:

- System used
- Cards models if known (photos would be great)
- Unisound version
- Exact sequence of initialization and contents (set blaster for one card, then unisound line, set blaster for next card, unisound line, final set blaster, etc..), output text from Unisound...
- Once initialized, report resource readings with UNISOUND /R (UNISOUND /C2 /R for the 2nd)
- PnP dump / eeprom dump if you have one.

Anyway, my *personal* advice (for anyone) is: try to avoid Opti cards if possible. They are problematic (even with the original drivers) and the sound quality is not very good.

---

1541 wrote:

Thanks, I had the same issue with my ES1868F PNP ISA. Setting it to J201 via the BLASTER variable did the trick.

Btw, is there also a command line switch for setting/changing the joystick port?

Shouldn't the joystick port default to 201 instead of 200?

Thank you for reporting.
I detected a bug with default values for the joystick port on some cards. I take note for the next version.

----

@aitotat

About Yamaha control port, it's safe. The official default base control port is 0x370 and only 0x370 and 0x371 are used. As maxtherabbit said, it does not interfere with the 0x37x used by the secondary IDE controller.

Jazefox thanks for the feedback!
Ive been trying to pin down the card disappearing on a timed sequence but i cant really nail down a pattern that causes it.
It has occurred in freedos and msdos 6.22.

The system im running on is a 486 SX 50 Mhz / 256 kb cach2 / 32 mb . It has the Opti 895 chipset. For expansion cards im running:
Slave VLB: Cirrius Logic GD-5428
Master VLB: Promise IDE Controller Card (Only used for the IDE controller)
ISA Cards: The Opti 931 card, Avance card, Intel Pro 10, SMC Controller Card (Only used for floppy and 1 serial)
Im running my harddrive off a SD card adapter with an 8 gb card. I have 3 partitions, freedos, msdos6, and win95. I have a 1.44 floppy and a gotek. I also have a DVD-ROM drive slave with the SD card.

Init bat file:

1REM The Opti 391 Card
2SET BLASTER=A240 I5 D3 H5 P330 F398 J0
3UNISOUND /C2 /V80 /VF80 /VW00 /VL00
4Rem The Avance 16 card
5SET BLASTER=A220 I7 D1 H6 P320 F388 J200
6UNISOUND /C1 /V99 /VF99 /VW99 /VL80
7SET SOUND16=F:\OPTI931

This is test script I made to repeat some unisound calls:

1CALL MIDIOFF.BAT
2REM | CHOICE /C:AB /T:A,2 > NUL
3CALL MIDION.BAT
4REM | CHOICE /C:AB /T:A,2 > NUL
5CALL MIDIOFF.BAT
6REM | CHOICE /C:AB /T:A,2 > NUL
7CALL MIDION.BAT
8
9UNISOUND /CL

where midion is (off is the same but with /VL00

1UNISOUND /C1 /V99 /VF99 /VW99 /VL80

Ive uploaded images of the cards and the pc. There are 2 monitor images where one is right after bootup and the other is a direct query for the card infos.
https://imgur.com/a/XwqmoyX

I tried running the XXF option and it gave back an error for one of the cards like it was an unknown type.

I have some issue detecting a gus pnp with your latest version. My yamaha based card is detected perfectly. The gus not at all. If set the gus environment unisound does not detect any card anymore. Also tried some general pnp tool and that does seem to detect two audio pnp cards. I’m not sure if the gus is broken and i have already deleted the previous unisound version. Is there maybe a link to an older version to verify my problem?

Sukerbole wrote on 2021-08-31, 19:22:

I have some issue detecting a gus pnp with your latest version. My yamaha based card is detected perfectly. The gus not at all. If set the gus environment unisound does not detect any card anymore. Also tried some general pnp tool and that does seem to detect two audio pnp cards. I’m not sure if the gus is broken and i have already deleted the previous unisound version. Is there maybe a link to an older version to verify my problem?

Here's a copy of 0.76b

https://mega.nz/file/o35QwZBK#OcdZutwSN4q8zBg … DJkgEYeTJI8hT94

@JazeFox

Great tool, thanks! Any chance of future support for Opti 924 soundcards?

I've just installed an ESS Audiodrive 1868F in my 286 PC, and everything is ok except for the MPU port, which doesn't seem to be detected by UNISOUND.
Any ideas??
Thank you!!

Tried it today and works great with my ALS100+ on a 486/66 using Dos 6.22 (with and without blaster environment set). Thanks for your efforts!

AndalusianRG wrote on 2021-09-23, 14:16:

I've just installed an ESS Audiodrive 1868F in my 286 PC, and everything is ok except for the MPU port, which doesn't seem to be detected by UNISOUND.
Any ideas??
Thank you!!

If you can use it with mpu on a pnp machine then put it in 286 with the same configuration but in Autoexec.bat you have to write the direction for unisound first.

GuillermoXT wrote on 2021-09-26, 23:53:

AndalusianRG wrote on 2021-09-23, 14:16:

I've just installed an ESS Audiodrive 1868F in my 286 PC, and everything is ok except for the MPU port, which doesn't seem to be detected by UNISOUND.
Any ideas??
Thank you!!

If you can use it with mpu on a pnp machine then put it in 286 with the same configuration but in Autoexec.bat you have to write the direction for unisound first.

It's actually working with the "/xem" option first. Thank you!

Tried UNISOUND with a Orpheus soundcard with PCMIDI installed (connected to a MP32L). The OPL3/SB part is working great. But when using MIDI (MT32 or soundfont) it sounds weird and also has hanging notes.

When using ORPHINIT I don't have this issue. First question is if this combination is supported and if so do I need any special parameters when starting UNISOUND? At the moment I am only using some volume parameters.

These are the SB setting I am using: SET BLASTER=A220 I5 D1 T4. If I use the /R option I see that it detects the PCMIDI parameters (IRQ2/9, P330).

Yoghoo wrote on 2021-09-28, 13:09:

Tried UNISOUND with a Orpheus soundcard with PCMIDI installed (connected to a MP32L). The OPL3/SB part is working great. But when using MIDI (MT32 or soundfont) it sounds weird and also has hanging notes.

When using ORPHINIT I don't have this issue. First question is if this combination is supported and if so do I need any special parameters when starting UNISOUND? At the moment I am only using some volume parameters.

These are the SB setting I am using: SET BLASTER=A220 I5 D1 T4. If I use the /R option I see that it detects the PCMIDI parameters (IRQ2/9, P330).

this is a classic resource conflict issue, easily fixed:
use this : SET SET BLASTER=A220 I5 D1 T4 P300

P300 tells unisound to activate CSMPU at port 300 -> then all will work: CSMPU@300 and PCMIDI@330

ORPHINIT works because the default setting is CSMPU disabled - you can edit orpheus.ini and assign port 300 to CSMPU - it will also work

keropi wrote on 2021-09-28, 13:58:

this is a classic resource conflict issue, easily fixed: use this : SET SET BLASTER=A220 I5 D1 T4 P300 […]
Show full quote

Yoghoo wrote on 2021-09-28, 13:09:

Tried UNISOUND with a Orpheus soundcard with PCMIDI installed (connected to a MP32L). The OPL3/SB part is working great. But when using MIDI (MT32 or soundfont) it sounds weird and also has hanging notes.

When using ORPHINIT I don't have this issue. First question is if this combination is supported and if so do I need any special parameters when starting UNISOUND? At the moment I am only using some volume parameters.

These are the SB setting I am using: SET BLASTER=A220 I5 D1 T4. If I use the /R option I see that it detects the PCMIDI parameters (IRQ2/9, P330).

this is a classic resource conflict issue, easily fixed:
use this : SET SET BLASTER=A220 I5 D1 T4 P300

P300 tells unisound to activate CSMPU at port 300 -> then all will work: CSMPU@300 and PCMIDI@330

ORPHINIT works because the default setting is CSMPU disabled - you can edit orpheus.ini and assign port 300 to CSMPU - it will also work

Thanks for the quick reply! That works. But... my first test was with dosmid which chooses the default mpu from the blaster env. So no sound until I add other runtime parameters to use port 330 instead of 300. This is something I try to avoid. Is there an option to disable the CSMPU like with ORPHINIT? Or could I make a feature request for it? 😀

Yoghoo wrote on 2021-09-28, 15:43:

Thanks for the quick reply! That works. But... my first test was with dosmid which chooses the default mpu from the blaster env. So no sound until I add other runtime parameters to use port 330 instead of 300. This is something I try to avoid. Is there an option to disable the CSMPU like with ORPHINIT? Or could I make a feature request for it? 😀

If you want to completely disable the CSMPU there is the "EEPROM restore/config tool" way found near the end here: http://orpheus-soundcard.eu/
select option 3 and power-cycle , then AFAIK unisound will not activate the CSMPU again unless you use it's /XOM1 switch along the P300 one in the BLASTER variable

keropi wrote on 2021-09-28, 16:08:

Yoghoo wrote on 2021-09-28, 15:43:

Thanks for the quick reply! That works. But... my first test was with dosmid which chooses the default mpu from the blaster env. So no sound until I add other runtime parameters to use port 330 instead of 300. This is something I try to avoid. Is there an option to disable the CSMPU like with ORPHINIT? Or could I make a feature request for it? 😀

If you want to completely disable the CSMPU there is the "EEPROM restore/config tool" way found near the end here: http://orpheus-soundcard.eu/
select option 3 and power-cycle , then AFAIK unisound will not activate the CSMPU again unless you use it's /XOM1 switch along the P300 one in the BLASTER variable

Thanks. Last question: if I look at the UNISOUND docs I see this:

If these switches are missing, defaults are:
External Yamaha OPL3, Disabled S/PDIF and disabled internal MPU (if your
card has PCMIDI intelligent-MPU components populated)

But the internal MPU is not really disabled by default in my situation (with a PCMIDI). So are the docs not correct or don't I understand it (very probably 😀). And not to nag or something like that (I only want to understand how it works) but why is there only a /XOM1 option and not a /XOM0 option like with S/PDIF output etc?

to my understanding /XOM1 is there in case you have CSMPU disabled in eeprom and you want to force using it
UNISOUND just looks in pnp eeprom and decides what to activate accordingly
so if your card has CSMPU activated in eeprom - unisound will try to use it

so I am 99,9% sure if you de-activate with eeprom tool all your worries will be gone 😀

The situation with Orpheus is likely due to there being different hardware revisions. The original one didn't offer a way to use the Crystal MPU-401; you could enable it, but it wasn't connected anywhere, as far as I remember. Later hardware revisions introduced the ability to use both, and direct them as you wish.

UNISOUND does indeed base its initialisation of Orpheus (at least for the on-chip MPU-401) on the resource map in the on-board EEPROM. Rather than modifying the EEPROM, which may present a few inconveniences if you later use a Plug-and-Play-aware OS, there is an easier solution: tell UNISOUND not to activate the Crystal MPU-401. This can be done in a somewhat round-about way: use P0 in your BLASTER environment variable. With that, it will not be initialised, and the on-board PCMIDI will be the only one active (on Orpheus, at least). This may "confuse" some inflexible software, though, so you may want to set your BLASTER environment variable again, after running UNISOUND, to remove the extra parameters, especially P0, altogether.