Hi, vintagefugg,
I think, I tried everything you requested and here are the results:

vintagefugg wrote on 2026-10-27, 19:08:

Could you tell me: - what UNISOUND v0.82a printed (does it say "No card detected", or does it find the ES1688 and print settings […]
Show full quote

Could you tell me:
- what UNISOUND v0.82a printed (does it say "No card detected", or does it find the ES1688 and print settings?),
- your BLASTER line,
- what exactly doesn't work afterwards (no sound at all, only music, game setup can't find the card...)?

With "UNISOUND /NOPNP" in AUTOEXEC.BAT or from command prompt:
- "No PnP card detected." message:

1Universal ISA PnP Sound Card Driver for DOS v0.82a. (c) JazeFox 2019-2025
2─────────────────────────────────────────────────────────────────────────
3No PnP card detected.

- I don't use a BLASTER variable set, since UNISOUND sets its own default values when manage to initialize any SB-compatible soundcard.
- no sound FX, no FM music, no MIDI, etc., the soundcard is undetected and uninitialized.

vintagefugg wrote on 2026-10-27, 19:08:

If you have a moment, this test would show which one it is. From a cold boot *without* ESSCFG in AUTOEXEC.BAT: 1. Run ESSCFG and […]
Show full quote

If you have a moment, this test would show which one it is. From a cold boot *without* ESSCFG in AUTOEXEC.BAT:
1. Run ESSCFG and look at the current settings (option 7). If it can't find the card or says no IRQ/DMA is selected, note that.
2. Run UNISOUND /NOPNP and note what it prints.
3. Run ESSCFG again and look at the settings. If the IRQ is 9 or the DMA didn't change, it's problem 2.
ESSCFG rewrites BLASTER from the card, so SET it again before running games afterwards.

ESSCFG for ES1688, that I use, is an alder version 2.1, so it is option 6. No BLASTER variable is set. These are the results after "cold" reboot with Reset button:
1. First I run "ESSCFG" from command prompt only and option 6 (for report):

1ESSCFG ( Version 2.1 ) found ES1688_PnP at address 220.
2
3Current IRQ channel setting is 5.
4
5Current DMA channel setting is 1.
6
7MPU401 is enabled with no IRQ.
8
9Current MPU401 base address setting is 300.
10
11Joystick is disabled.

2. Next - "UNISOUND /NOPNP" from command prompt:

1Universal ISA PnP Sound Card Driver for DOS v0.82a. (c) JazeFox 2019-2025
2─────────────────────────────────────────────────────────────────────────
3No PnP card detected.

3. Finaly - "ESSCFG" from command prompt and option 6 (for report):

1ESSCFG ( Version 2.1 ) found ES1688_PnP at address 220.
2
3Current IRQ channel setting is 5.
4
5Current DMA channel setting is 1.
6
7MPU401 is enabled with no IRQ.
8
9Current MPU401 base address setting is 300.
10
11Joystick is disabled.

The assigned IRQ is not 9, but 5, and as you can see, no initialization was done from UNISOUND and no Port, IRQ and DMA values were changed after.

vintagefugg wrote on 2026-10-27, 19:08:

I don't really have a great way to share files but I built a little test program ESSINIT that extracts out the bits of ESSCFG that I think are relevant. It's here https://limewire.com/d/g4XTB#7PTdbrSd5K (expires in 3 days). It sets up an ES688/ES1688 the way ESSCFG does: it wakes the chip if needed, writes the IRQ and DMA from BLASTER through 2xCh, reads them back and tests that the IRQ actually fires, printing each step. Run it instead of ESSCFG after a cold boot (ESSINIT > ESSINIT.TXT) and post the output; ESSINIT /OLD writes the values the 0.82a way, for comparison. If ESSINIT works where UNISOUND doesn't then that gives JazeFox something to work with.

As expected your ESSINIT.EXE works just fine with ES1688 card even with no BLASTER variable set after "cold" reboot:
1. When I run "ESSCFG" without any command line switches from command prompt only:

1BLASTER not set
2Base 220h, IRQ 5, DMA 1
3Before: 2xEh = 18, 2xAh = AA
4Reset: 2xAh = AA after 1 ms, 0 more byte(s) flushed
5E7h: 68 8B
6Chip: ES1688 or later
7Mixer 40h = 03
8Before: B1h = 15, B2h = 1A
9Write B1h = 55: both bytes to 22Ch, busy wait 0 and 0 ms
10Write B2h = 5A: both bytes to 22Ch, busy wait 0 and 0 ms
11After:  B1h = 55, B2h = 5A
12F2h try 1: IRQ3=0 IRQ5=1 IRQ7=0 IRQ9=0 IRQ10=0
13Interrupt on IRQ 5: OK
14RESULT: OK

2. When I run "ESSCFG /OLD" from command prompt only:

1BLASTER not set
2Base 220h, IRQ 5, DMA 1, old write
3Before: 2xEh = 18, 2xAh = AA
4Reset: 2xAh = AA after 1 ms, 0 more byte(s) flushed
5E7h: 68 8B
6Chip: ES1688 or later
7Mixer 40h = 03
8Before: B1h = 15, B2h = 1A
9Write B1h = 16: B1 to 22Ch, 16 to 22Dh (old way)
10Write B2h = 1A: B2 to 22Ch, 1A to 22Dh (old way)
11After:  B1h = 15, B2h = 1A
12F2h try 1: IRQ3=0 IRQ5=1 IRQ7=0 IRQ9=0 IRQ10=0
13Interrupt on IRQ 5: OK
14RESULT: OK

In both cases ES1688 card is initialized and works perfectly fine.

Please tell me, if I didn't manage to do something the way you wanted.

vintagefugg wrote on 2026-10-27, 19:08:

On fixing unisound: I still can't use PMs on vogons (too new?) and I don't have another way to contact JazeFox but I think we could patch this into unisound without too much drama if they're willing to accept binary diffs or patches.

If I'm not mistaken, you'll get the permission for sending PMs, when you hit 20 posts. But even now you can attach executable (and other type) files in your posts if they are in some archive format like zip, 7z, rar... or if you change their .exe/.com extensions to any acceptable .jpeg, .gif, .txt, .doc, .pdf... extensions, but the latter method is not recommended. There is a limit of five attachments per post.

I also think, that your ESSINIT (for ES1688) program should be permanently attached here or in some other dedicated thread for download, since it works perfectly fine just like ESSCFG does.

I have no idea what happened with JazeFox. It seems like he/she just "disappeared without a trace". I don't have any hope for now UNISOUND version, since it is closed source freeware.

I'm looking forward for your conclusions after the quick tests I made. Thank you very much for your support!

Ok, I am *super* wary of stepping on JazeFox's toes here but as they haven't been active here for about a year I figured I might step in and keep things moving until they return. I have a build with a few fixes that I've been running on some real hardware and on 86box. I will happily delete this file, my comments, my account, or whatever it takes to keep JazeFox happy when they return. All credit for this fantastic tool goes to them. I'll pass all the fixes to JazeFox when they return.

I've linked UNISOUND v0.82a-unofficial-fix-3.zip below. It is not attached to this comment because (a) none of the licenses I can select on vogons apply here and (b) I need to be able to delete this file if JazeFox asks me to and I'm not sure I can delete whole comments / attachments here. It's named fix-3 because I've been through a few rounds of real hardware testing. I'm concerned that the binary is reaching a size where the COM 64Kb segment limit but I've run 86box-mcp regression testing on a pile of simulated hardware + a few physical systems and it's been fine so far. This is an unofficial build. Don't yell at JazeFox if this burns down your house. Check CHANGES.TXT inside the zip for the full list of modifications.

https://mega.nz/file/fCZiHQwI#fAMNKQkWwIUa262 … 3t-GjeQ5O49kQQA

Bug fixes — General

• Options must be spelled in full; unknown ones print "Unknown option" and exit with ERRORLEVEL 2 (/DUMMY used to disable the card). /XOS0 now works. (yeokm1, AndalusianRG, Cryptus, analog_programmer)
• Volumes take one digit as well as two (/VL0 used to be ignored); a bad value prints "Invalid value". It turns out my own autoexec.bat I was using on many real systems was failing to set line in volume because I was passing /VL0 instead of /VL00!
• Unknown PnP cards (NICs, modems, game ports) are skipped instead of stopping with "Aborting"; /Cn with no card n exits with ERRORLEVEL 1. (ajacocks, Retromachines, NightSprinter, AncapDude)
• ULTRASND and BLASTER with fewer fields are read correctly.
• Long card names no longer hang /CL.

ESS

• /NOPNP finds an ES688/ES1688 after other UNISOUND commands. (GigAHerZ, analog_programmer)
• /NOPNP finds chips that start disabled; ES1788 and ES1887/ES1888 are recognised. (analog_programmer, 0xDEADBEEF)
• /NOPNP writes the ES688/ES1688 IRQ and DMA the way ESSCFG does; a real ES1688 ignored v0.82a's writes. (vico, analog_programmer)
• /NOPNP no longer takes another card for an OPTi 82C924/925 and skips the ESS check ("No PnP card detected."). (analog_programmer)
• ES1868/ES1869: H4 and D = H mean no second DMA. (Kahenraz)
• ES1868/ES1869: U sets the MPU-401 IRQ. (crvs)
• ES688 and OPTi 82C930 names corrected. (Pr1ha)

Creative

• Non-PnP SB16/AWE32: /R only reads and /D leaves the card alone.
• An F not a multiple of 4 is rounded down (F389 becomes 388). (Mr.Hunt)
• AWE /VR50 to /VR99 no longer corrupt FM passthrough.
• 28 MB of AWE RAM is shown correctly.

Crystal

• CS4237B, Orpheus, Turtle Beach: codec left in standard WSS mode, so Tyrian accepts it. (vanfanel)

Yamaha OPL3-SAx

• K sets the WSS DMA, and it is shown. (TgamesFR)
• SB Pro master set like aitotat's FIXYMF: SB Pro stereo panning (Wolf3D) works and /VW lowers the effects volume. (badmojo, --Freeman--)
• D = H keeps D and moves only the second DMA.

Others

• OAK OTI601 / OPTi 82C928 with a CS4231/CS4248: codec bits set.
• AZT2320: D = H keeps D, an invalid H is corrected; Aztech and Rockwell leave the SB Pro mixer in mono.
• InterWave ROM names, Ensoniq VIVO and Maxi Sound /R, SAM9407 firmware upload: small fixes.

Known issue, not changed: on the OPTi 82C931 the FM address is written to a register that expects a multiple of 16; real cards seem to answer at 388 anyway.

New features

• BLASTER check: if BLASTER is missing or doesn't match the card UNISOUND just set up, it prints a SET BLASTER line for AUTOEXEC.BAT. Other fields are kept, and a BLASTER that points to another card is left alone. (analog_programmer)
• /LOG prints diagnostic lines for problem reports.
• /XSLAM sets up Crystal CS423x chips that the BIOS has hidden from PnP; a Crystal chip with no resource data (Gateway E-1000) gets the standard layout. (Pickle, MartinausWien, AliceImagina)
• /XESSB finds on-board ES1868/ES1869 chips that the PnP scan misses, through the ESS bypass key. (vsharun, Oetker)
• When no card is found, UNISOUND points to /XSLAM, /XESSB and /LOG.
• The banner shows this version.

Everything was tested in 86Box except the Ensoniq, Maxi Sound, SAM9407 and 82C928 changes. /XSLAM, /XESSB, the OPTi checks and the Yamaha changes haven't been tried on real hardware yet, so reports are welcome. Thanks to everyone in this thread who reported these problems. If something breaks, first check whether the official v0.82a does the same, then post the output of this (with the options you normally use, such as /NOPNP):

1UNISOUND /LOG > LOG.TXT

vintagefugg wrote on Yesterday, 20:58:

Ok, I am *super* wary of stepping on JazeFox's toes here but as they haven't been active here for about a year I figured I might step in and keep things moving until they return. I have a build with a few fixes that I've been running on some real hardware and on 86box.

So is this based on original code or reverse engineered/AI decompilation?

No, it's not the original code because only the original author has that. NSA Ghidra is basically required here because the tool is closed source.

I mentioned "86box-mcp regression testing" in the comment. MCP = Model Context Protocol. To me, and I expect to most developers these days, mentioning or using MCP implies AI. I had AI build a test harness to configure, boot, and run unisound fixes, and test sound (FM, midi, digital) for every sound card 86box supports on a few hardware platforms I mentioned in a pervious comment. Doing that manually would have taken *days*. My real hardware testing is not AI driven but I understand it can be done these days if you have fancy gear.

I also used ghidra-MCP to drive disassembly. I don't have super readable code with all the comments from the original author so it's pretty tough to read and understand but it's possible to work on. Still, almost all of the original COM file is still present because most of these are tiny changes. You just have to allow for bytes to be shifted where code was inserted or deleted. For example: the new LOG output insertion shifted a bunch of code. I started by trying to apply a couple of small binary patches but it was an not possible to complete even just the initial ESS issues given the time I have available.

If that somehow still doesn't meet vogons rules I'm fine to delete the file + comments and just hand JazeFox the list of potential fixes when / if they come back.

I think you should delete this out of respect for JazeFox. I find the lack of source code annoying but it is their wish to release as freeware. Eventually it may be necessary to reverse-engineer UNISOUND to continue it if JazeFox abandons it but right now we don't know if that has happened. I don't even know if they approve of their program being messed around with AI.

vintagefugg, your fixed version finally works with ES1688F chip. Thanks a lot! Later today I will test it with ES1869F.

If some users complains about your Ghidra reverse-engineered code and patches in this thread, then just open a new thread about your patched UNISOUND version. I don't know what happened to JazeFox and how many JazeFoxes ("them"?) were out there, but it is obvious, that there will be no more "official" support for the original UNISOUND tool.

EDIT: Unfortunately ES1869F chip still doesn't initialize properly. vintagefugg, I sent you a PM with the test results.

megatog615 wrote on Today, 06:22:

I think you should delete this out of respect for JazeFox. I find the lack of source code annoying but it is their wish to release as freeware. Eventually it may be necessary to reverse-engineer UNISOUND to continue it if JazeFox abandons it but right now we don't know if that has happened. I don't even know if they approve of their program being messed around with AI.

So a project can only be considered abandoned if the developer publicly announces it? That’s a rather high bar, since someone who has abandoned it is unlikely to say so.
Besides, JazeFox’s activity has always been sporadic. His last-seen time is hidden, but his post history shows long gaps between one release and the next.
Out of curiosity, would your objection be the same if the patch had been made by hand with a disassembler? If the issue is consent, the tool shouldn’t matter.

Nemo1985 wrote on Today, 09:11:

So a project can only be considered abandoned if the developer publicly announces it? That’s a rather high bar, since someone who has abandoned it is unlikely to say so.
Besides, JazeFox’s activity has always been sporadic. His last-seen time is hidden, but his post history shows long gaps between one release and the next.
Out of curiosity, would your objection be the same if the patch had been made by hand with a disassembler? If the issue is consent, the tool shouldn’t matter.

My gut feel is the "permission to use AI based tools on their work" is the primary concern there given other posts that have been observed

Nemo1985 wrote on Today, 09:11:

So a project can only be considered abandoned if the developer publicly announces it? That’s a rather high bar, since someone who has abandoned it is unlikely to say so.
Besides, JazeFox’s activity has always been sporadic. His last-seen time is hidden, but his post history shows long gaps between one release and the next.

The creator of the original UNISOUND tool is not under any obligations to publicly declare if he/she has decided to no longer participate in this forum. For the past year JazeFox's activity in the forum is zero. Earlier he/she mentioned something about some real life duties. With all those accumulated bug reports and not a single post from the original author of the tool, to me this is an abandoned project or at least a poorly maintained project. I don't mind, if the creator suddenly shows-up and presents next version of UNISOUND with all the reported bugs fixed, but as I already wrote - I don't have any hopes for this.