myne wrote on 2025-06-20, 11:19:

Could a uefi module do it?
Ie something that could act as an option rom and/or a boot loader?

If my memory serves me I think UEFI modules are mostly serial spi nor flash?

Where the it8888 uses a serial i2c eeprom at address ox50 (1010000b). IT8888 can also be configured through PCI configuration cycles from system chipset.

Ideally, we would have a simple tool exist on user space and initiate PCI Configuration cycles on the it8888 to allow for configuration of the card without a programmer. But I have yet to investigate or make anything for that yet. I've just been programming the chip and using a standard pin header socket with eeprom on breakout board with pin headers to move chip between my programmer and card.

dartfrog wrote on 2025-06-20, 11:04:

If you use your own programmer like a XGecu T48/T56/T76, you can just use the bin file produced by the python config tool, If not let me know and I will investigate.

Awesome! I saw your repo had some IT8888 code but I didn't know what state it was in. I have a universal rom programmer so I'll just use that 😀

Um... No, I mean like any uefi module that can be loaded into the main bios like a lan boot rom can.
I assume the main thing you need to do is initialise the registers.
Software can do that, no?
So a uefi module makes sense to make it os agnostic.

myne wrote on 2025-06-20, 23:41:

Um... No, I mean like any uefi module that can be loaded into the main bios like a lan boot rom can. I assume the main thing you […]
Show full quote

Um... No, I mean like any uefi module that can be loaded into the main bios like a lan boot rom can.
I assume the main thing you need to do is initialise the registers.
Software can do that, no?
So a uefi module makes sense to make it os agnostic.

If it's just to configure the registers, I wonder if it's possible to unload the module/ROM after finishing the work, as leaving the module/ROM resident means less available UMB for DOS memory managers.

That was the experience I had with launching Plop Boot Manager as a LAN boot ROM -- I lost access to about 40KB of UMB as a result.

I don't see why it would need to be a tsr.
I am pretty sure lan boot, and many other oproms are not tsr.

myne wrote on 2025-06-21, 04:45:

I don't see why it would need to be a tsr.
I am pretty sure lan boot, and many other oproms are not tsr.

I think it depends. Some option ROMs, like those for storage controllers to provide INT13H functionalities, be it onboard (RAID/AHCI modes) or discrete, will stay resident in UMB.

As a result, you'll have less upper memory available when using them. Some option ROMs leave a very big memory footprint like more than 20KB, that to the point that there won't even be enough contiguous blocks to enable EMS anymore.

Yes. Which is why I said lan and many others. Not all.
Lan would most likely be tsr when successfully lan booting.
Most uefi modules like chipset config would just run, set, and exit.

rasteri wrote on 2025-06-20, 23:41:

Awesome! I saw your repo had some IT8888 code but I didn't know what state it was in. I have a universal rom programmer so I'll just use that 😀

I had old stuff as a proof of concept including config tool. but yesterday I only uploaded the c based pico programmer part. If there's any problems with the bin or config tool, I'll fix it asap.
(also you might want to take a look at the config stuff in datasheet, and ensure the bin is setup right. since i was the only one working on this, it's likely I messed something up)

myne wrote on 2025-06-20, 23:41:

Um... No, I mean like any uefi module that can be loaded into the main bios like a lan boot rom can. I assume the main thing you […]
Show full quote

Um... No, I mean like any uefi module that can be loaded into the main bios like a lan boot rom can.
I assume the main thing you need to do is initialise the registers.
Software can do that, no?
So a uefi module makes sense to make it os agnostic.

Oh I'm sorry I understand now. When I wrote that I was very tired and not thinking correctly. For some reason i thought you were talking about using the uefi nor flash 🤣. My bad.

Yeah I guess it could. Main problem I see is no uefi signing and lack of secure boot because of it. Some systems don't even allow self signed modules. Also testing uefi stuff is a nightmare since you can brick the test machine easily, not to mention toolchain (edk2) imo is a plague on humanity. Some systems behave differently too so you might need multiple modules. which just complicates things further. If someone wants to build that they absolutely can. personally i don't see the reason for that level of complexity since there's actually only a few ways the it8888 needs to be configured for our use case. (basically it8888 needs to configured a certain way or dma will never work) And since you can configure it8888 via PCI configuration cycles, why bother with uefi?

idk just my two cents, if anyone has a valid reason for uefi over pci configuration or external programmer, I'm all ears.

Fair.
Does it use SRAM or DRAM?
If SRAM, in theory you can set it once and forget.

"Small" update for those of you challenging Asus boards (Z87/Z97 and so on) with blocked ISA PnP registers.
I have made it to relocate ESS1869F (PnP card) config port successfully to the port 240h, using bypass key sequence (okay, not me, but claude.ai).
Impulse Tracker detected Sound Blaster Pro okay, then I have tried ES1869.mmx driver - no luck, but: essmixer detects the card as ES1688 (and get/sets volume okay).
Then I have tried Impulse Tracker with ES1688.MMX driver - success.
What does that mean:
1. little more programming skills required to program the card
2. concept is proven: ESS PnP cards (one of the best ones) can be initialized successfully on Asus Z87/Z97 (Gryphon Z87, Maximus VII Gene) using slightly different path.
Source code and exe attached, in wsl2 session:

1../djgpp/bin/i586-pc-msdosdjgpp-gcc -Os -o  ess_en2.exe ess_en2.c && ../djgpp/bin/i586-pc-msdosdjgpp-strip ess_en2.exe

upd: just realized es1688 cfg works partially, at least I have SFX in duke3d setup. No FM or MPU-401 (yet).
Full unlocking ESS enabler here:
Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards

vsharun wrote on 2025-06-26, 14:47:

Impulse Tracker detected Sound Blaster Pro okay, then I have tried ES1869.mmx driver - no luck, but: essmixer detects the card as ES1688 (and get/sets volume okay).
Then I have tried Impulse Tracker with ES1688.MMX driver - success.

Perhaps your configuration tool kind of made the card behave like ES1688 thus you'll need the ES1688 driver instead of ES1869 if configured this way.

Whether this really is the case can be further validated by trying to use the card with Win3.x/9x and see which driver actually works under this circumstance.

Actually, when I assembled this ES1868 card, I used an ES1869 instead as that's what I could acquire. The card works without issues just I have to use ES1868 driver instead of ES1869 for proper operation under Windows (tested with NT 3.51 and 98SE).

LSS10999 wrote on 2025-06-26, 17:12:

Perhaps your configuration tool kind of made the card behave like ES1688 thus you'll need the ES1688 driver instead of ES1869 if configured this way.
Whether this really is the case can be further validated by trying to use the card with Win3.x/9x and see which driver actually works under this circumstance.

Hi,
"Underconfigured" 1869 card behaves like 1688 for unknown reason for me, thus detected like that. Actually es1688cfg can't do anything with this card, while (essmix/essvol) mixer works.

Attached ess "Bypass key" enabler v.3 sets ES1869 card to the following:
A220 I7 D1
MPU-401 enabled on port 330
FM enabled at port 388
You need to set essvol /A:8 (or some volume you like) to hear Wavetable.
Right now I'm enjoying DOOM II on 1869F with WP32 McCake and Arachno soundfont on Asus Gryphon Z87 using Zowie EC2 and Hator mechanical keyboard (all USB, there's no PS/2 ports on this mobo).

vsharun wrote on 2025-06-26, 18:13:

Hi,
"Underconfigured" 1869 card behaves like 1688 for unknown reason for me, thus detected like that. Actually es1688cfg can't do anything with this card, while (essmix/essvol) mixer works.

So ES1688's ESSCFG cannot handle ES1868/ES1869 in this case, but ESSMIX/ESSVOL can be used to configure volumes.

The question would be whether (non-PnP) ES1688 drivers for other OSes like Windows 3.x/9x/NT will work for this card if configured this way as I think there's a good chance actual ES1868/1869 drivers (depending on the mode the chip is strapped to operate) cannot be used due to broken ISA PnP which the drivers might attempt to do (and will notice the failure).

When I'm using a CT2950 Sound Blaster 16 (PnP), once the card has been configured using UNISOUND, the card can then be recognized and operated even with non-PnP Sound Blaster drivers that came with Windows (such as Win3.x, NT3.51).

PS: Ideally the code should be designed around building with OpenWatcom v1.9/v2. Code compiled with DJGPP apparently requires CWSDPMI to be present IIRC.

LSS10999 wrote on 2025-06-27, 06:26:

vsharun wrote on 2025-06-26, 18:13:

Hi,
"Underconfigured" 1869 card behaves like 1688 for unknown reason for me, thus detected like that. Actually es1688cfg can't do anything with this card, while (essmix/essvol) mixer works.

So ES1688's ESSCFG cannot handle ES1868/ES1869 in this case, but ESSMIX/ESSVOL can be used to configure volumes.

They have different configuration mechanisms: ES1688 via baseport, while 1868/69 - PnP or Bypass Key. Mixer - the same.

LSS10999 wrote on 2025-06-27, 06:26:

The question would be whether (non-PnP) ES1688 drivers for other OSes like Windows 3.x/9x/NT will work for this card if configured this way as I think there's a good chance actual ES1868/1869 drivers (depending on the mode the chip is strapped to operate) cannot be used due to broken ISA PnP which the drivers might attempt to do (and will notice the failure).

I spend some time digging "why" it is detected as 1688 and the answer is - drivers seems to look at the pnp card id, failed, then asks for some Audiodrive stuff, got it and after that detection phase concluded 1688.
Basically 1688 are the same as 1868/69 from DOS usage perspective.

LSS10999 wrote on 2025-06-27, 06:26:

When I'm using a CT2950 Sound Blaster 16 (PnP), once the card has been configured using UNISOUND, the card can then be recognized and operated even with non-PnP Sound Blaster drivers that came with Windows (such as Win3.x, NT3.51).

This is quite easy to explain: before PnP init the card didn't listen anywhere except port 279 and A79 (ADDRESS PORT and DATA PORT). Once you pass PnP init procedure, the card starts listening on baseport(s) (typically 220 and next 15 ports, up to 22F), starts listening to the IRQ and to the DMA channels set via configuration register, which starts being accessible after 279+A79 "handshake"sequence. From this point it has no differences with nonPnP card, except possibility to change listening resources on the fly via configuration register (like es1688 btw).

LSS10999 wrote on 2025-06-27, 06:26:

PS: Ideally the code should be designed around building with OpenWatcom v1.9/v2. Code compiled with DJGPP apparently requires CWSDPMI to be present IIRC.

This is the code written by free tier claude.ai with my minor tweaks (like MPU/FM activation) and some obvious compiler warnings/errors correction. It does require some more things like real short/long delay functions(not 1k or 100k cycle iterations) as per datasheet, command line parameters, set BLASTER analysis etc. I asked yesterday author of UNISOUND in the thread is it possible to integrate this bypass key path to the UNISOUND for such LPC-ISA limited functionality boards..

BTW I put today three more "in question" cards and they all was reported as "chip detected and activated" by the tool and non functional afterwards(like with Unisound though).
Important update - this bypass key enabler seems not 100% compatible with all the cards 1868/1869, I have at least four cards which it isn't, while UNISOUND on PD440FX w/ P2-233 okay. While utility sets config address correctly it isn't all the time correctly sets other resources.

BTW congrats with your 1000th message )

Some updates on my end with my P8B75-M. Had to take out that board for some repair work as I noticed 5 bulged caps on it, though the board itself doesn't exhibit any anomaly when using in this state.

These bulged caps (6.3V/820uF), which were near USB ports and headers, all belonged to the +5V_USB_PS2 rail according to the boardview. Apparently that rail had footprints for 6 capacitors with one optional and unpopulated, so this means all caps on that rail have failed for whatever reasons before I got it. I've replaced the bulged caps with polymers of the same spec but smaller in size, as well as actually populating the one that were optional before (so 6 in total). Powered on the board again and everything seems to be good so far.

I tested with a non-PnP Sound Blaster 16 (CT2290) and it can be correctly picked up by UNISOUND. The card in overall behaves very similar to the PnP CT2950 that I'm currently running on my X99 system.

However, the card apparently had difficulty getting detected reliably during testing, and I noticed the WavetablePi I'm trying to use on it for MIDI either would not power on, or it keeps rebooting when it does, indicating a possible power issue, so I replaced the regulators on the CT2290 (a 7805 and a 7809). After replacement the card can be reliably detected, but WavetablePi still reboots so I have to use something else... most likely the wavetable header of that card simply couldn't provide enough power for WavetablePi (which itself uses a Raspberry Pi Zero 2W).

Not sure how long the lifespan of those regulators usually are but they are probably the reason why some ISA sound cards don't get reliably detected, that were often dismissed as being not properly seated. Not all ISA cards require the use of regulators, however.

EDIT: When I said the CT2290 behaving similar to CT2950 I'm mostly referring to the differences in behavior I noticed with Wolf3D engine games. With a SB16 card, digitized sounds would occasionally cut off, but it has positional effects. With a PicoGUS in SB mode there are no positional effects (all sounds are played at the same volume), yet sounds always play correctly without cutoff.

On the other hand, it seems for my board (P8B75-M), in order to use IRQ5 the printer port has to be enabled. Disabling the printer port will result in one PIRQ line taking over IRQ5 leaving only IRQ7 usable for sound cards.

LSS10999 wrote on 2025-06-30, 17:05:

With a PicoGUS in SB mode there are no positional effects (all sounds are played at the same volume), yet sounds always play correctly without cutoff.

PicoGUS has SB 2.0 mode (Mono only), not SB Pro 2.0 (Stereo max 8bit up to 22kHz) like ESS and Yamaha's.

After some time spent with Asus Z87 Gryphon +LPC2ISA v 0.2 adapter gaming DOS titles (Doom1/2, Duke3d):
1. compatibility with v 0.2 adapter okay, no PnP init works, but es1688 esscfg or es1868/69 with bypass key enabler (PnP but not PnP) are ok, after init - SB Pro 2.0 compatible better that genuine SB Pro. Excellent ESFM, supports 16 bit 44kHz stereo Impulse Tracker via included ites1688.mmx driver, tracker music quality on par with PicoGUS in GUS mode.
2. Keyboards and mices - big issue. The board has no PS/2 ports and therefore only USB. The board is picky to the devices: all of my "new" mechanical keyboards and gaming mices are prone to phantom mouse left click dozen times per hour. Imagine doom or duke3d with RPG near the wall. The only solution - strict HID devices both, like MS optical wireless mouse model 1000 and simple HP keyboard. I have tried combos like Zowie EC2 + membrane kb, or Ducky Shine + MS 1000 mouse - nope, something confuses bios usb to ps/2 subsytem. BTW USB polling rate (switcher on the mouse) also confuses bios a lot, slowing down music and SFX on anything bigger than 125.

Asrock Z87M-Pro4 OTOH has no issues with USB devices, broken on Asus kb+mouse combo has no issues on Asrock.

You may ask why I'm so sticky with this Asus mobo ? Asus Gryphon Z87/Z97 are the only mobos built with long term endurance and mild overclocking in mind within mATX Z87/Z97, has TPM and exposed LDRQ1. Also I have plenty of B85M boards died just in my hands. The same for entry level Z87 (Like Asrock and Gigabyte). Gigabyte's Sniper mATX has no TPM exposed unfortunately.

Apparently for some reasons my ASUS P8B75-M does not want to work with PicoGUS in GUS mode. Possibly another breakage on top of ISA PnP.

At first I thought the card might have soldering related issues, but when I just tested the card on a board with proper ISA bus (AIMB-865) it was correctly initialized -- GUSDRAM tests also worked. So the card itself was fine.

Should point out that most if not all ASUS boards with PS/2 combo ports only wired keyboard signals leaving mouse signals unconnected to the port. It does work as a combo for either keyboard or mouse (but not both), because the SuperIOs they use support swapping keyboard and mouse functionalities on-the-fly.