Cutemouse 2.0 solves an issue where the mouse works but the game freezes if you move the mouse while playing soundblaster audio, it may not help in your situation

I think your issue may be related to the MPU401 port, the game offers port 330, 332, 334 and 336 (using r/r1, r2, r3 and r4 respectively) but most sound cards will only offer 300/310/320/330 as MIDI ports. So if unisound has initialised the MPU401 port to anything other than 330, roland will not work with this game.

Or maybe it was hard to understand, if you launch with "atlantis.exe m r" then the mouse and roland is working?

Sorry but I don't even think it's related to UNISOUND...
You MUST declare

indiana.exe m (mouse) s220/5/8 (addr/int/k bufsize)

and you can concatenate arguments like:

indiana.exe m s220/5/8 r

as I read on the help_me.doc of Indiana Jones:

The product will support a combination of Roland and SoundBlaster
capabilities. Simply select both options.

Thankyou all !!!

Where is the best place to report bugs?

I am using the latest v0.82a with my ESS MK1869 XTREME. According to the readme:

... the remaining resources will be disabled (... MPU address ...

When configuring my Ultrasound after setting up a Sound Blaster 16 PnP with its MPU port on 340, the Sound Blaster port stops working (even after reinitializing it with Unisound). It seems like the Ultrasound is configuring it's MPU port at address 340 and overriding the Sound Blaster.

It works fine on other ports, but I would prefer to use 340 on this particular device.

Kahenraz wrote on 2026-09-13, 08:17:

Where is the best place to report bugs? […]
Show full quote

Where is the best place to report bugs?

I am using the latest v0.82a with my ESS MK1869 XTREME. According to the readme:

... the remaining resources will be disabled (... MPU address ...

When configuring my Ultrasound after setting up a Sound Blaster 16 PnP with its MPU port on 340, the Sound Blaster port stops working (even after reinitializing it with Unisound). It seems like the Ultrasound is configuring it's MPU port at address 340 and overriding the Sound Blaster.

It works fine on other ports, but I would prefer to use 340 on this particular device.

GUS utilizes ports in 3x0 range (where x is the same as 2x0 in the base port) for MIDI and DRAM related functions. If you use 240 for GUS then it will conflict with your SB16 PnP on 340.

If you want SB16 PnP's MPU port on 340 you'll need to move the GUS base port to something like 260. GUS will then use ports in 360 range for those purposes.

That's it, thank you. Moving my Ultrasound to 260 was the solution.

Also, setting up resources for the ES1869 requires allocating two DMA channels, I assume for full-duplex playback and recording. But my MK1869 doesn't even have a microphone jack. Is there a way to configure the device in half-duplex mode so that I only need to assign one DMA channel? DMA channels are a limited and precious resource.

Kahenraz wrote on 2026-09-14, 05:49:

Also, setting up resources for the ES1869 requires allocating two DMA channels, I assume for full-duplex playback and recording. But my MK1869 doesn't even have a microphone jack. Is there a way to configure the device in half-duplex mode so that I only need to assign one DMA channel? DMA channels are a limited and precious resource.

From the example in the UNISOUND manual (using an ES1868 card), it seems you can just put "D1 H1" in the BLASTER environment variable so UNISOUND would set both DMA channels to 1.

This can also be used for SB16 cards to use low DMA channel for 16-bit audio if needed.

Yes, I thought so too. And this works for my SB16. But when I try to do the same with the ES1869, for example, "D1 H1”, Unisound sets it to DMA:1/0.

Some tests on 80286 12 MHz system with two different ISA ESS soundcards and the latest UNISOUND version 0.82a.

ESS ES1688F card: Does not work with "UNISOUND" ,"UNISOUND /NOPNP", "UNISOUND /XAE /XEA" or "UNISOUND /NOPNP /XAE /XEA" - UNISOUND always shows the message "No PnP card detected.":( The original ESS initializer ESSVOL version 2.1 works without any problems every time.

ESS ES1869F card: Does not work with "UNISOUND" or "UNISOUND /NOPNP". With "UNISOUND /XAE /XEA" works once in a million tryouts - UNISOUND mostly shows the message "No PnP card detected." The original ESS initializer ESSVOL version 5.2 works without any problems every time.

EDIT: Copy-pasted typo - not /XAE, but /XEA swith.

analog_programmer wrote on 2026-10-15, 10:59:

Some tests on 80286 12 MHz system with two different ISA ESS soundcards and the latest UNISOUND version 0.82a.

ESS ES1688F card: Does not work with "UNISOUND" ,"UNISOUND /NOPNP", "UNISOUND /XAE" or "UNISOUND /NOPNP /XAE" - UNISOUND always shows the message "No PnP card detected.":( The original ESS initializer ESSVOL version 2.1 works without any problems every time.

ESS ES1869F card: Does not work with "UNISOUND" or "UNISOUND /NOPNP". With "UNISOUND /XAE" works once in a million tryouts - UNISOUND mostly shows the message "No PnP card detected." The original ESS initializer ESSVOL version 5.2 works without any problems every time.

Do you have a card that is known to work with UNISOUND to rule out issue with the system? Also, the same thing happens when the card is inserted in a different ISA slot?

pan069 wrote on 2026-10-15, 19:23:

Do you have a card that is known to work with UNISOUND to rule out issue with the system? Also, the same thing happens when the card is inserted in a different ISA slot?

Yes, I do have SB 16 Pro Value (CT2911), which works perfectly fine on the same 286 system with "UNISOUND" without any command line arguments and no "BLASTER" env. variables.

I tried many combinations of ISA slots for ESS soundcards, VGA card and multi-I/O controller without any success for UNISUOUND, only the native ESS initializers always work. And that's why I'm sharing the results here.

I just noticed in 86box, that all variants of ESS ES1688 don't get detected by UNISOUND. Maybe that datapoint becomes valuable.

(I was recreating my 486 machine in 86box. I wanted to set it up with ESS ES1869F, but 86box doesn't have that card. So i went with ES1688. The ES1869F does work in my 486 with UNISOUND.)

JazeFox hasn't been active on this thread since October 2025 but hopefully they're OK. I was also a bit concerned about the number of issues reported here for such a fantastic tool. I thought I'd run into an ES1898F issue but it turns out the problem was probably a broken card as I saw failures with the real dos drivers too. That one goes on the repair pile for some other day.

I do think I've found a few bugs in unisound after testing with 86box-mcp + 86box. /R showing the wrong value on some ensoniq cards, MPU port being read from the wrong register on ES1868 and some other cards, ULTRASND variable with only 3/4 fields can lead the IRQ and second IRQ to be parsed from unallocated memory (usually zero), same with BLASTER etc. I have some proof of these (including real physical testing for the ES issues) and some proposed binary fixes for unisound but I'm obviously not going to release them without consent from JazeFox. Until then: if you're running into these issues make sure to flesh out all the fields in your ULTRASND and BLASTER variables.

Hi! I have an Labway A151-A00 sound card (with YMF719 chip). I've tested with unisound because with the official drivers I have some problems with my motherboard (a Lucky Star Lm486e Rev 1.00) and it sounds great. But, it sounds too loud (some games fx sound sounds louder than music). Can anyone suggest me a properly parameters in unisound so that it sounds more balanced? Thanks a lot!

I went through the whole thread and tried to reproduce the reports that never seemed to be solved. All testing below was done in 86Box (build dad077e85) with 86box-mcp driving MS-DOS 6.22, using UNISOUND 0.82a from the start of this thread, plus some reading of datasheets. The emulated machines were:

• an ASUS PVI-486SP3C (SiS 496, Award PnP BIOS) and an Olystar LIL1429 (ALi M1429, no PnP BIOS), both with a 486DX2-66 and 16 MB;
• a DataExpert 286 (NEAT) at 6, 8 and 12.5 MHz with 1 MB, for the slow machine reports. I had a test harness set up with slower systems but this is the slowest I could get working;
• a Compaq Presario 224x (on-board ES1888), for the ES1887/ES1888 report;
• a Gateway E-1000 (on-board CS4236B) and an Intel VS440FX (on-board CS4236), for the OEM Crystal reports.

Almost all the issues here haven NOT been confirmed on real hardware yet, so if you own one of these cards, I'd be grateful if you could try the suggestions and report back. I have a Compaq LTE 5000 with a crystal chip that and did reproduce one of the reported issues but unfortunately I couldn't find a workaround so the only way I can get it to work is with the janky old CWDINIT. I plan to test some of these with real hardware when I find time as I have an ES1688 somewhere, I have an ES1898 installed right now in my favorite 486 that should be able to repro some of these, I *just* scored a Turtle Beach Malibu with an CS4237B from a recycler here a few days ago (unsure if it works yet though, PSU on that system was dead so I have low hopes).

I have a few binary patches for a couple of the ones I suggested debug commands for. I am too new here to PM you JazeFox and I don't know if I can respond to PMs either for the same reason.

ESS ES688 / ES1688 not detected with /NOPNP (GigAHerZ)
I stumbled on this and it seems like it's a nasty little landmine. A single UNISOUND /NOPNP after a cold boot detects the ES688/ES1688 fine. But if plain UNISOUND has run first (which is what most of us try first), /NOPNP afterwards says "No card detected". The first run probes for a non-PnP SB16 at 220h and leaves a byte sitting in the ESS DSP's read buffer. /NOPNP then reads that stale byte instead of the chip's answer and gives up.
Workaround: run UNISOUND /NOPNP first thing after booting, before any other UNISOUND command. A cold boot clears it.

ES1688 games only see AdLib / sound loud and distorted (vico, analog_programmer)
In 86Box, the IRQ and DMA requested in BLASTER end up in the ESS registers correctly, and DMA playback with interrupts works. One thing could behave differently on real chips. UNISOUND writes the IRQ/DMA register number to port 2xCh but the value to 2xDh. ESS documents only 2xCh for both bytes, and the Linux and NetBSD drivers use 2xCh. 86Box treats 2xDh the same as 2xCh, which is why it works there. A chip that ignores 2xDh would end up with a different IRQ from the one in BLASTER, and games would fail to find the digital audio. That would fit "only AdLib works". This is unverified. Could one of you tell me which IRQ ESSVOL/ESS's own tools report after UNISOUND /NOPNP, and whether a game's IRQ autodetect finds a different one?
I couldn't reproduce "loud and distorted" from UNISOUND's mixer values. It sets master DDh, voice CCh and FM CCh, which is well below full scale.
Also: /XAE isn't an UNISOUND option. Unknown switches are silently ignored, so it had no effect. You were probably thinking of /XEA.

YMF71x: no stereo in Wolf3D (badmojo, again)
I am not sure but I think this is the same thing as the SETUPSA "SB = 7" problem. On the OPL3-SA3, the SB Pro "Voice" volume (04h) isn't applied independently. The chip combines it with the SB Pro "Master" volume (22h) through a table in the YMF715 register documentation. At a high master, every non-zero voice level comes out at about the same 0 dB, so Wolf3D's left/right voice settings can't pan. UNISOUND sets SB Pro master to DDh (6 of 7 on the chip's scale), where voice 2-7 are all 0 dB.
Something to try after UNISOUND: set SB Pro master low, e.g. with DEBUG:

1o 224 22
2o 225 33
3q

(220h base; use 244/245 for 240h.) That puts the master at 1, where the voice range is fully graded. You may then need to adjust overall volume with the Yamaha master instead of the SB master. 86Box doesn't emulate this table, so I couldn't test it. Please tell me if it brings the stereo back.

YMF719: sound effects louder than music (]--Freeman--[)
The same table is probably why. UNISOUND's /VW goes into that SB Pro "Voice" register, so with the master where UNISOUND leaves it, /VW barely changes the effects. Anything from about /VW19 up comes out at 0 dB, /VW13 to /VW18 gives -3 dB, and lower mutes. The music (FM) is set separately with /VF. The default 80 gives about +3 dB, and /VF99 gives about +12 dB. So the first thing to try is:

1UNISOUND /VF99

That should bring the music up by about 9 dB relative to the effects. If the effects are still too loud, also set SB Pro master low with the DEBUG lines above. Then /VW starts to have an effect (e.g. at the default /VW80, effects drop by about 3 dB, and lower /VW values reduce them further). All of this comes from the YMF715 datasheet rather than testing, so please let us know how it sounds.

ES1869: D1 H1 gives DMA 1/0, and H4 doesn't free the second DMA (Kahenraz)
Reproduced. When D and H are the same, UNISOUND sets the second DMA to 0 on ESS chips. With H4 it doesn't write the second-DMA register at all, so whatever was there before (the BIOS's value, or 0 from an earlier run) stays, even though it prints "DMA:1".
Workaround: run UNISOUND /D first (that clears it), then UNISOUND with H4.

ES1868/ES1869: MPU-401 IRQ can't be changed with U (crvs)
Reproduced as far as the registers go. On ESS cards the "U" value is ignored, and UNISOUND writes the SB IRQ into PnP register 72h. According to the ES1868/ES1869 data sheets, 72h is actually the Audio-2 interrupt. The MPU-401 IRQ is the card-level register 28h, which UNISOUND never sets. So there's currently no way to change or free the MPU IRQ on these cards with UNISOUND.

"Unknown PnP card [...] found. Aborting..." with a network card, modem or game port (1, 2, 3)
Reproduced with a 3C509B, an RTL8019, a PnP game port and unsupported sound cards. If the first PnP card UNISOUND finds isn't one it knows, plain UNISOUND stops right there. It doesn't look at the other cards, and it doesn't fall back to a non-PnP SB16 either. Whether you hit this depends on which card gets PnP number 1, which is why it seems random between machines.
Workarounds: UNISOUND /CL to see the card numbers, then UNISOUND /C2 (or whichever number your sound card has). For a non-PnP SB16, use /CS or /NOPNP. Note that /CS takes the first SB16-type chip it finds from 220h upwards, not the address in BLASTER.

Card not detected next to another PnP sound card (dizzydevil, Sukerbole)
I couldn't reproduce a detection problem with AWE64 + ES968/ES688 or GUS PnP + YMF718/719, in either order. /CL always lists both cards. Without /Cn, UNISOUND only configures the first supported card, so the second one needs /C2. Setting ULTRASND didn't affect detection in 0.82a.

Careful: /R and /D on a non-PnP SB16
When UNISOUND falls back to a non-PnP SB16, /R doesn't just read: it reconfigures the card (in my test a jumperless SB16 went from IRQ 5 / DMA 1 to IRQ 7 / DMA 0). /D reconfigures it too instead of disabling it.

Tyrian: no WSS on CS4237B (vanfanel)
Two things combine here. Tyrian's WSS driver always uses DMA 0, whatever you set. And after UNISOUND, the CS4237B's codec is left in its extended mode ("MODE 3"). Tyrian checks for a standard WSS codec and gives up with "ERROR 142" on every DMA, so "use D0" alone doesn't help. In 86Box, putting the codec back in standard mode after UNISOUND makes Tyrian's WSS play (only on DMA 0):

1debug
2o 534 c
3o 535 a
4q

(WSS at 530, so the codec is at 534.) This only works if your board has DMA 0 wired; on a card that only routes DMA 1, use SB for Tyrian. The same probably applies to Orpheus and Turtle Beach cards. WSS at 534 with W530 is correct, by the way: the codec sits 4 ports above the WSS base.

Open Cubic Player on Crystal cards: no sound or freezing (aigeek)
The SB part of the Crystal chips is SB Pro compatible, not SB16. With T6 in BLASTER, OCP uses SB16 commands the chip ignores, and in my test the UI ran but there was no sound. Use T4 (or T3) on Crystal cards. UNISOUND doesn't read T at all, so it's only for the programs that read BLASTER. I couldn't reproduce the freeze with T4. I couldn't test Lemmings 2 (vanfanel).

Crystal chips on laptops and OEM boards not found (Pickle, MartinausWien, AliceImagina)
I can reproduce this in 86Box by setting the CS423x EEPROM bit that takes the chip out of Plug and Play: UNISOUND /CL then shows nothing, and /CS doesn't accept the chip because its SB part isn't an SB16. The chip still works at the resources the BIOS gave it. Workaround: set BLASTER to the BIOS's values (with T3 or T4) and use Crystal's CWDINIT/CWDMIX for the mixer instead of UNISOUND.

AZT2320 /XWSS (Marco)
W does work in 0.82a (W604 gives WSS 608). "Always 534" with W530 is right: that's the codec address, 4 above the WSS base, so set games to WSS 530. K and Q have no effect because this chip has a single IRQ and DMA pair shared by SB, FM and WSS, so games should use the I and D from BLASTER. WSS playback worked in 86Box with:

1SET BLASTER=A220 I5 D1 H3 W530 T4
2UNISOUND /XWSS

Don't set H to the same value as D on this card: UNISOUND then changes D.

YMF719: K ignored for the WSS DMA (TgamesFR)
On the Yamaha cards, UNISOUND puts WSS on the H DMA, and K isn't used. With D1 H1 it changes H to 3, so WSS ends up on DMA 3. If you want WSS on DMA 1, use e.g.

1SET BLASTER=A220 I5 D3 H1 P330 W530 T4

(or D0 H1).

AWE64 Gold: F389 doesn't move the CQM synth (Mr.Hunt)
The card only accepts an FM address of 388, 38C, 390 or 394 (multiples of 4), so 389 isn't a valid value. UNISOUND passes it on unchanged, and in 86Box that leaves FM working nowhere. Use F0 to switch it off, or F390/F38C to move it.

ESS ES1887/ES1888 (Dell Latitude XPi) (0xDEADBEEF)
These chips aren't ISA Plug and Play, so plain UNISOUND can't see them. UNISOUND /NOPNP treats them as an ES1688 and works in 86Box (Compaq Presario 224x onboard ES1888), as long as something has enabled the chip. Two catches: run /NOPNP first after booting (see the ES1688 item above), and set the I in BLASTER to the IRQ your BIOS assigned. The BIOS can lock these chips to a fixed IRQ, and UNISOUND then prints the BLASTER IRQ while the chip keeps using the BIOS's one.

ES1868/ES1869 on 286 and XT machines (analog_programmer, georgel)
I couldn't reproduce this on an emulated 286 at 6, 8 and 12.5 MHz: detection, /R and /CL all worked repeatedly. UNISOUND's delays come from the timer chip, not from CPU speed, so I suspect the ISA bus instead: many 286 boards run it at the CPU clock (12 MHz or more), which 86Box doesn't model. If your BIOS has an ISA bus clock divider or wait-state setting, try a slower bus and a 16-bit slot. (ES1688F with /NOPNP is a separate case: some ES1688s need an "enable" sequence that UNISOUND doesn't send. If /NOPNP still fails after a cold boot, running ESS's own tool once first should enable the chip.)

ESS chips that don't answer standard PnP detection (vsharun, Oetker)
ESS chips can also be configured through their own "bypass key", without the PnP read port, which is what ESSCFG does. A prototype that does this found and configured an ES1868 and an ES1869 in 86Box, so it would be possible for UNISOUND too. For now, ESSCFG (or vsharun's tool) first is the way.

Couldn't reproduce (need more details)
- AWE RAM detection (theelf): every onboard RAM size on AWE32/AWE64 variants was detected correctly in 86Box, cold and warm boot. 28 MB shows as 28671K, which is cosmetic. The BX-board crash can't be emulated. Which board, CPU speed and RAM size?
- OPTi 82C931: F0 did free 388h in 86Box (Pickle), and SB digital audio played with every IRQ/DMA I tried (troydm). Which BLASTER line and which game?
- AZT2320 reversed stereo in Quake (csal, InterClaw): 86Box uses the same SB Pro stereo model for every card, so I can't test it. One thing I noticed: UNISOUND leaves the SB Pro stereo bit on for Aztech cards, which affects mono playback; it may or may not be related.
- ES1868/ES1869 losing their settings when UNISOUND is run again (1, 2): 86Box keeps the configuration, so this looks like real-chip behaviour I can't emulate. /XEA remains the workaround.

Small one: an ES688 is reported as "ES668" (noted here). It's just the name; the card is handled as an ES688.

Thanks for your suggestions, vintagefugg!

vintagefugg wrote on Today, 05:23:

ESS ES688 / ES1688 not detected with /NOPNP (GigAHerZ) I stumbled on this and it seems like it's a nasty little landmine. A sing […]
Show full quote

ESS ES688 / ES1688 not detected with /NOPNP (GigAHerZ)
I stumbled on this and it seems like it's a nasty little landmine. A single UNISOUND /NOPNP after a cold boot detects the ES688/ES1688 fine. But if plain UNISOUND has run first (which is what most of us try first), /NOPNP afterwards says "No card detected". The first run probes for a non-PnP SB16 at 220h and leaves a byte sitting in the ESS DSP's read buffer. /NOPNP then reads that stale byte instead of the chip's answer and gives up.
Workaround: run UNISOUND /NOPNP first thing after booting, before any other UNISOUND command. A cold boot clears it.

ES1688 games only see AdLib / sound loud and distorted (vico, analog_programmer)
In 86Box, the IRQ and DMA requested in BLASTER end up in the ESS registers correctly, and DMA playback with interrupts works. One thing could behave differently on real chips. UNISOUND writes the IRQ/DMA register number to port 2xCh but the value to 2xDh. ESS documents only 2xCh for both bytes, and the Linux and NetBSD drivers use 2xCh. 86Box treats 2xDh the same as 2xCh, which is why it works there. A chip that ignores 2xDh would end up with a different IRQ from the one in BLASTER, and games would fail to find the digital audio. That would fit "only AdLib works". This is unverified. Could one of you tell me which IRQ ESSVOL/ESS's own tools report after UNISOUND /NOPNP, and whether a game's IRQ autodetect finds a different one?
I couldn't reproduce "loud and distorted" from UNISOUND's mixer values. It sets master DDh, voice CCh and FM CCh, which is well below full scale.
Also: /XAE isn't an UNISOUND option. Unknown switches are silently ignored, so it had no effect. You were probably thinking of /XEA.

Actually my report on ES1688 card matches the one from GigAHerZ, not from vico. I will try your suggestion to use only /NOPNP command line switch in AUTOEXEC.BAT, since I don't remember if I tried this switch after the UNISOUND was first used without any switches in AUTOEXEC.BAT. But the register "garbage" leftover really looks like a bug.

As for /XAE - this is a copy-pasted typo in my post. I mean, I tried with /XEA switch and combination of /NOPNP and /XEA (I'm not sure, if this combination is allowed). I will try to remember the right letters combination from "eXtended switch for Ess card - Alternative init. method".

vintagefugg wrote on Today, 05:23:

ES1868/ES1869 on 286 and XT machines (analog_programmer, georgel)
I couldn't reproduce this on an emulated 286 at 6, 8 and 12.5 MHz: detection, /R and /CL all worked repeatedly. UNISOUND's delays come from the timer chip, not from CPU speed, so I suspect the ISA bus instead: many 286 boards run it at the CPU clock (12 MHz or more), which 86Box doesn't model. If your BIOS has an ISA bus clock divider or wait-state setting, try a slower bus and a 16-bit slot. (ES1688F with /NOPNP is a separate case: some ES1688s need an "enable" sequence that UNISOUND doesn't send. If /NOPNP still fails after a cold boot, running ESS's own tool once first should enable the chip.)

Those old 286 BIOSes have no options for ISA bus frequency dividers or wait states values. I'm not 100% sure, but I think my 286 motherboard has separate clock generator circuit for ISA bus and it should be with a fixed value i.e. CPU turbo/non-turbo clock independent. There's only one switch on the motherboard for RAM wait state setting. The best I could try is initialization with UNISOUND in non-turbo mode of 8 MHz for CPU, instead of 12 MHz.

vintagefugg wrote on Today, 05:23:

YMF71x: no stereo in Wolf3D (badmojo, again) I am not sure but I think this is the same thing as the SETUPSA "SB = 7" problem. O […]
Show full quote

YMF71x: no stereo in Wolf3D (badmojo, again)
I am not sure but I think this is the same thing as the SETUPSA "SB = 7" problem. On the OPL3-SA3, the SB Pro "Voice" volume (04h) isn't applied independently. The chip combines it with the SB Pro "Master" volume (22h) through a table in the YMF715 register documentation. At a high master, every non-zero voice level comes out at about the same 0 dB, so Wolf3D's left/right voice settings can't pan. UNISOUND sets SB Pro master to DDh (6 of 7 on the chip's scale), where voice 2-7 are all 0 dB.
Something to try after UNISOUND: set SB Pro master low, e.g. with DEBUG:

Copy code to clipboard

1o 224 22
2o 225 33
3q

(220h base; use 244/245 for 240h.) That puts the master at 1, where the voice range is fully graded. You may then need to adjust overall volume with the Yamaha master instead of the SB master. 86Box doesn't emulate this table, so I couldn't test it. Please tell me if it brings the stereo back.

It will be easier to use FIXYMF that I made for that exact same purpose.

How did I never know about FIXYMF aitotat! If only we could integrate that directly into unisound so people didn't need to know they had to chain programs together.