I had a look at the datasheet of the ESS 1868 just as an example and it looks like it allows the driver to setup the device configuration space anywhere between 100h-FF6h so, it may not follow the PnP specs if it doesn't want to.
I guess other sound cards may work in a similar way. It then becomes important to understand what the drivers are doing and/or trying to do.

rasteri wrote on Yesterday, 19:47:

300/310/320/330/340/350/360/370 (+1/2/3) -- MPU-401 MIDI

I've since changed this port range to 30x-37x (x = 0~7) by default with my lpcexp stuffs, because GUS does use ports 3x4-3x7 (where x corresponds to 2x0 base port so if using 240 then 340-347 need to be opened), and that was the reason why I wasn't able to get PicoGUS working in GUS mode before (SB mode works fine).

vsharun wrote on Yesterday, 15:14:

Your PicoGUS works in games, like DOOM/Duke3D ? The only thing I have managed PicoGUS to work in - impulse tracker, both Doom/Duke3D (and Descent) failed to init (setup/game start) on Asus, Asrock and Gigabyte mobos I have, while pgusinit - okay. pgusinit just sends some in/out bytes, nothing more.
I have two H61 MSI's - they both okay and PnP friendly (both have populated LPC/TPM header), and recent acquisition - Z87M Gaming now on LDRQ1 soldering session: I will return back with findings.

Haven't tested in detail. With the aforementioned change to the 3xx port range GUS mode now works correctly to the point that GUSDRAM tests pass and ULTRAMID can be loaded without errors.

I did try testing the PicoGUS in GUS mode against DIGPAK but it froze. Maybe it's because I'm using DMA1 instead of DMA3 (since I do want to use its SB mode). I did set ULTRASND to DMA1 and IRQ7 (corresponding to my jumper settings) but I'm not sure if this needs to be set elsewhere also (such as INI file).

SB mode works perfectly fine in games, just that it being only SB2.0 means some games will not be able to enable some advanced effects.

EduBat wrote on Yesterday, 22:37:

I had a look at the datasheet of the ESS 1868 just as an example and it looks like it allows the driver to setup the device configuration space anywhere between 100h-FF6h so, it may not follow the PnP specs if it doesn't want to.
I guess other sound cards may work in a similar way. It then becomes important to understand what the drivers are doing and/or trying to do.

The question is whether drivers for other OSes than DOS could also try initializing the card via bypass key mode. It should be noted that for ESS audio chips, one may need to use the driver for a different chip if it's operating at a different mode than default.

For instance, if ES1869 is used as a drop-in replacement on a PCB meant for ES1868, then ES1868 drivers must be used instead (ES1869 drivers won't work). This is the case for hkzlab's ES1868 card where I used an ES1869 since I could not source an actual ES1868 at that time, and I'm thinking if it's possible to use ES1868's PnP data on an external ROM to "spoof" the card as ES1868 so the OS will automatically pick the correct driver.

EduBat wrote on Yesterday, 22:37:

I had a look at the datasheet of the ESS 1868 just as an example and it looks like it allows the driver to setup the device configuration space anywhere between 100h-FF6h so, it may not follow the PnP specs if it doesn't want to.
I guess other sound cards may work in a similar way. It then becomes important to understand what the drivers are doing and/or trying to do.

After doing a bit of research, it seems many "PnP" cards exist in a few different flavors. Apparently a card saying it's "PnP" or having a lack of jumpers really tells us nothing about how they are configured.
I guess the good thing about this wild wild west of PnP ISA stuff; is it's unlikely a card by card basis but rather a vendor by vendor basis.

They can be :

• Full PnP ISA Spec Compliant Cards
  • Follow complete PnP ISA specification (initiation key -> isolation -> CSN assignment -> configuration)
  • May also support vendor-specific PnP bypass shortcuts (e.g., ESS 1868 bypass key)
  • May also have proprietary configuration utilities with config files (CONFIG.SYS, AUTOEXEC.BAT, *.INI)
• Partial PnP / Hybrid Cards
  • Do not follow full PnP ISA specification
  • Use vendor-specific PnP bypass only (simpler initialization, fixed addresses)
  • OR use proprietary configuration programs with config files
  • OR support both vendor bypass and proprietary utilities
• Non-PnP / Legacy Cards
  • No PnP ISA support whatsoever
  • Configuration only via jumpers, DIP switches, or proprietary software utilities
  • May require manual resource assignment in CONFIG.SYS, AUTOEXEC.BAT, or *.INI files

~

I've done a a full PnP ISA Spec breakdown and an ESS 1868 bypass breakdown with a key differences for anyone who's interested in it.
The jist is that PnP ISA Spec is 4 states across 11 steps and the ESS bypass is 2 states across only 4 steps. Though the PnP ISA Spec has enumeration of other cards and the bypass doesn't.

Standard PnP ISA Protocol wrote:

Standard PnP ISA Protocol (with explicit states) Initial State: All cards power up in Wait for Key state (CSN=0) […]
Show full quote

Standard PnP ISA Protocol (with explicit states)
Initial State: All cards power up in Wait for Key state (CSN=0)

1. Send 32-byte initiation key to 0x279
   • State transition: Wait for Key -> Sleep (all cards)
2. Send Wake[0] command (ADDRESS=0x03, WRITE_DATA=0x00)
   • State transition: Sleep (CSN=0) -> Isolation (all unconfigured cards)
3. Configure READ_DATA port (ADDRESS=0x00, WRITE_DATA=port>>2)
   • Current state: Isolation (no state change)
4. Run isolation protocol (72 pairs of reads from Serial Isolation register)
   • State transition:
     • One winning card: stays in Isolation
     • All losing cards: Isolation -> Sleep
5. Assign Card Select Number (CSN) (ADDRESS=0x06, WRITE_DATA=1-255)
   • State transition: Isolation -> Config (winning card only)
6. Read resource data (poll Status register, read Resource Data register)
   • Current state: Config (no state change)
7. Configure resources (set I/O ports, IRQ, DMA, Memory base addresses)
   • Current state: Config (no state change)
8. Activate device (ADDRESS=0x30, WRITE_DATA=0x01 per logical device)
   • Current state: Config (no state change)
9. Return card to Sleep (optional: send Wake[0] to start enumerating next card)
   • State transition: Config -> Sleep (with CSN preserved)
10. Repeat steps 2-9 for each additional card (incrementing CSN)
11. Return all cards to Wait for Key when enumeration complete
    • State transition: Any state -> Wait for Key (CSNs preserved)

~

ESS 1868 PnP Bypass Protocol wrote:

ESS 1868 PnP Bypass Protocol (vendor-specific shortcut) Initial State: Card must be in Wait for Key state (CSN=0) […]
Show full quote

ESS 1868 PnP Bypass Protocol (vendor-specific shortcut)
Initial State: Card must be in Wait for Key state (CSN=0)

1. Send 32-byte bypass key to 0x279 (vendor-specific sequence, NOT standard initiation key)
   • State transition: Wait for Key -> Config (card immediately configured!)
   • Note: This bypasses Sleep and Isolation states entirely
2. Write low byte of desired I/O address to PnP address register (0x279)
   • Example: For 0x220, write 0x20
   • Current state: Config (no state change)
3. Write high byte of desired I/O address to PnP address register (0x279)
   • Example: For 0x220, write 0x02
   • Current state: Config (no state change)
   • I/O address must be in range 0x100-0xFF8, aligned on 8-byte boundary
4. Card is now active at specified address
   • Current state: Config (device automatically activated)
   • No isolation needed
   • No CSN assignment needed
   • No separate resource configuration needed
   • Card uses the bypass-specified address immediately

~

Key Differences wrote:

Key Differences Standard Protocol: […]
Show full quote

Key Differences
Standard Protocol:

• Goes through all 4 states: Wait for Key -> Sleep -> Isolation -> Config
• Can enumerate multiple cards systematically
• Universal - works with all PnP ISA cards
• More complex, requires full state machine

ESS Bypass:

• Jumps directly: Wait for Key -> Config (skips Sleep & Isolation)
• Single card only (no enumeration mechanism)
• Vendor-specific - only works with ESS and similar cards
• Much simpler, just send bypass key + address
• Useful when BIOS/OS doesn't support PnP ISA

~
EDIT:

A PnP Enabler Utility will likely work in legacy OSes like DOS/9x for both dISApointment/ITE8888. For modern OSes like Vista onward, it will need a kernel driver for I/O port access AND proper OS integration (or risk confusing the OS). NT/2000/XP falls in between: needs admin rights + I/O port driver, but may still confuse the OS since enumeration happens before the enabler runs.

What Happens When OS Gets "Confused" by Hardware Appearing After Enumeration AND Possible Solutions:

~ […]
Show full quote

• Windows NT/2000/XP/Vista+
  • Device Manager doesn't see the card (no PnP event generated)
  • Drivers won't load automatically
  • Resource conflicts go undetected (OS thinks IRQ/DMA/I/O ports are free, might assign to another device)
  • Manual driver loading might work but could cause BSOD if driver expects PnP enumeration data
  • Power management breaks (card doesn't suspend/resume properly)
  • Yellow exclamation marks in Device Manager, RESOURCE_CONFLICT BSODs
• Linux
  • No /dev/ entries created, lspci/lsusb won't show the device
  • /proc/ioports doesn't show resources in use (OS thinks they're free)
  • Manual module loading (modprobe) might work but udev may not create devices
  • Resource conflicts with other devices (kernel warnings, device probe failures)
  • ALSA/PulseAudio can't find the card even though hardware is active
  • dmesg shows I/O conflicts, intermittent hardware failures, possible kernel oopses
• DOS/Windows 3.1/95/98
  • No confusion! These OSes expect manual hardware configuration
  • Drivers probe hardware directly, no sophisticated enumeration required
  • PnP enabler utility works perfectly
• Core Problem
  • Hardware exists electrically but not in OS software device tree
  • OS resource manager has incomplete information -> assigns same resources to multiple devices
  • Results: driver load failures, hardware conflicts, system crashes/lockups
  • Only fixable by running enabler BEFORE OS enumeration or using proper kernel driver integration

~

Can You Fake/Trigger a PnP Event After Running the Enabler?

• Windows NT/2000/XP
  • Partially possible using Device Manager "Scan for hardware changes"
  • Right-click "Computer" -> "Scan for hardware changes" triggers re-enumeration
  • BUT: Only works if bus driver supports runtime enumeration (PCI does, ISA typically doesn't)
  • ISA bus is considered "legacy" - no dynamic enumeration support in most systems
  • Alternative: Use SetupAPI functions to manually add device node (requires admin + code)
  • Result: Hacky and unreliable, OS still doesn't truly "discover" the device
• Windows Vista+
  • Same as XP but even harder due to stricter driver model
  • Could manually add device via Device Manager -> "Add legacy hardware"
  • Must manually specify all resources (I/O ports, IRQ, DMA)
  • Driver must be loaded manually, no automatic matching
  • Breaks on Windows updates, requires re-configuration
  • Result: Not practical for end-users
• Linux
  • More flexible than Windows - can trigger bus rescans:
    Copy code to clipboard

    1echo 1 > /sys/bus/pci/rescan
    

  • BUT: Only works for buses with rescan support (PCI/USB, not ISA)
  • ISA bus is legacy, no /sys/bus/isa/rescan mechanism in most kernels
  • Alternative: Manually create platform device in kernel module:
    Copy code to clipboard

    1platform_device_register(&my_isa_device);
    

  • Can use udev rules to auto-load drivers when platform device appears
  • Result: Requires kernel module, but more feasible than Windows
• The Real Issue: ISA Bus is Static
  • PCI/USB have hotplug support, ISA doesn't
  • OS expects ISA devices to exist at boot, not appear later
  • Even "faking" the event doesn't solve resource management issues
  • OS resource allocator already made decisions based on incomplete info
• Practical Workarounds
  • Windows: Use SetupDiCallClassInstaller() API to inject device, or manually add via Device Manager legacy hardware wizard
  • Linux: Create platform device in kernel module, udev handles the rest
  • Both: Reserve resources in OS config before running enabler (kernel parameters on Linux, registry on Windows)
  • Best solution: Don't fake it - run enabler at boot time before OS enumeration (BIOS option ROM, UEFI driver, or early kernel module)
• Bottom Line
  • Technically possible to fake PnP events, but complex and fragile
  • Requires admin/root privileges, platform-specific code, and deep OS knowledge
  • Doesn't solve underlying resource conflict issues
  • Only reliable solution: Configure cards BEFORE OS boots (DOS/Win9x) or use proper kernel driver integration (modern OS)

~

I've thought about a dual boot scenario with full reboot but this won't work due to hardware reset, but a boot time configuration stage that chains into Windows via kexec or uefi app without rebooting might be a possible solution for modern OSes.

Using a Dual-Boot Configuration Kernel Approach:

• The Problem with True Dual Boot (Separate Reboots)
  • Config kernel configures PnP cards -> Reboot -> Windows boots
  • Reboot triggers POST and ISA bus reset (RESET_DRV signal)
  • PnP cards return to "Wait for Key" state, lose all configuration
  • Windows sees unconfigured cards again
  • Only IT8888F PCI config persists (PCI survives reboot)
• What Might Work: Single Boot Sequence Configuration
  • Don't reboot between config and Windows
  • Bootloader -> Config stage -> Chainload Windows (no reboot)
  • Cards stay configured throughout (Hopefully)
• Practical Solutions
  • GRUB + kexec: Tiny Linux kernel runs PnP enabler, uses kexec to jump directly to Windows (no reboot)
  • UEFI Shell: UEFI app (.efi) configures cards, chainloads Windows Boot Manager
  • DOS Bootloader: Boot FreeDOS via MEMDISK, run PNPINIT.EXE, chainload Windows (Syslinux/LOADLIN)
  • Option ROM: Flash PnP enabler into ROM on IT8888F card, runs during POST before any OS
• Summary
  • Full reboot = cards lose config (doesn't work)
  • Boot time config stage + chainload = cards keep config (Maybe)
  • Best: Pre-boot tool that configures then launches Windows in one sequence
  • For DOS/Win9x: Just run enabler in AUTOEXEC.BAT (simplest)

EduBat wrote on Yesterday, 22:37:

I had a look at the datasheet of the ESS 1868 just as an example and it looks like it allows the driver to setup the device configuration space anywhere between 100h-FF6h so, it may not follow the PnP specs if it doesn't want to.
I guess other sound cards may work in a similar way. It then becomes important to understand what the drivers are doing and/or trying to do.

I have made essinit utility around this bypass key feature with sources (here on the forum attached some pages back) and that help with init some ess1869 cards on the Asus systems (Z87 Gryphon, Z97M, all of the Asus's Z87/Z97 I have) with PnP upper range not routable to the LPC. The card then visible as 1688 in Impulse Tracker (which is okay, SB Pro 2.0 and ess's 44.1kHz 16bit stereo ), because no PnP id available, but control registers the same for the whole family starting from 1688.
Yamaha and Crystal ISA cards has no bypass key functionality.
Yamaha's 719-s exhibits terrible Adlib hanging notes in Wolfenstein3D (I have tested some five different PCBs I have via dISAppointment 0.2), both 8 and 11MHz ISA - no differences.
Crystal cards has terrible Adlib emulation support.
And only ESS'es so flexible and compatible.

YMF71x definitely have a "bypass key" function, although not same as the ESS ones. Instead of normal PnP key sequence you send it Yamaha specific one and the card automatically assigns a Card Select Number to it and you can use it to conf the card without having to go through the full PnP process. It will still need all the PnP specific IO ports to be available to work however. I believe Crystal cards work the same way.

LSS10999 wrote on Today, 02:57:

Haven't tested in detail. With the aforementioned change to the 3xx port range GUS mode now works correctly to the point that GU […]
Show full quote

vsharun wrote on Yesterday, 15:14:

Your PicoGUS works in games, like DOOM/Duke3D ? The only thing I have managed PicoGUS to work in - impulse tracker, both Doom/Duke3D (and Descent) failed to init (setup/game start) on Asus, Asrock and Gigabyte mobos I have, while pgusinit - okay. pgusinit just sends some in/out bytes, nothing more.
I have two H61 MSI's - they both okay and PnP friendly (both have populated LPC/TPM header), and recent acquisition - Z87M Gaming now on LDRQ1 soldering session: I will return back with findings.

Haven't tested in detail. With the aforementioned change to the 3xx port range GUS mode now works correctly to the point that GUSDRAM tests pass and ULTRAMID can be loaded without errors.

I did try testing the PicoGUS in GUS mode against DIGPAK but it froze. Maybe it's because I'm using DMA1 instead of DMA3 (since I do want to use its SB mode). I did set ULTRASND to DMA1 and IRQ7 (corresponding to my jumper settings) but I'm not sure if this needs to be set elsewhere also (such as INI file).

SB mode works perfectly fine in games, just that it being only SB2.0 means some games will not be able to enable some advanced effects.

I just did some GUS mode tests. Not too promising, though kind of ruled out possible incompatibilities with DMA1.
- Tetris Pro (by Michiel Ouwehand) works fine with GUS mode. This game does not require ULTRAMID, and most likely won't be able to run with ULTRAMID loaded as it needs a lot of conventional memory.
- Jazz Jackrabbit works with GUS mode provided ULTRASND has correct values. This game also does not require ULTRAMID.
- DIGPAK hangs while testing. The system is not entirely frozen as there are LED activities from the Pico, and if necessary, the system can be rebooted via CTRL-ALT-DEL. An example: when setting music to use GUS, SETM would stuck after starting tests, while Pico's LED blinks slowly.
- Sound tests would finish very quickly without any actual sound output with DUKE3D's setup. Music tests would hang. The system will also hang when actually launching the game.

So with dISAppointment PicoGUS can work in GUS mode but it doesn't work everywhere.

On the other hand, I tested my 82C929 card (not PnP) with this system (MS-7860) and for some reasons, the system refuses to boot (hangs at BIOS screen) with the card plugged. I did a verbose setup (lpcisav) and actually the BIOS set the LPC bus to decode full 800 and A00 ranges, with the other two decoding registers disabled (set to 0x0).

And no, PnP cards still won't get detected. So for now PicoGUS seems to be the best thing to use here, other than non-PnP Creative SBPro/16 cards. ES688 and ES1688 (non-PnP, without ES968) can also be good choices.