YMF71x has a special key as do Crystal chips, which allows them to get a Card Select Number without rest of the PnP dance, but you still need working PnP Data port ($A79) to actually write all the PnP registers to set up the IO ranges etc.

Tiido wrote on 2025-06-08, 17:25:

YMF71x has a special key as do Crystal chips, which allows them to get a Card Select Number without rest of the PnP dance, but you still need working PnP Data port ($A79) to actually write all the PnP registers to set up the IO ranges etc.

So in our case with Asus 7-8-9 series boards where A79 io port blocked there's no chance to init YMF719 then ?
May you please take a look to the ESS1868/69 datasheet ?
The bypass key must be followed immediately by two I/O writes
to the PnP address register to set the low and high bytes of
the address register of the configuration device. The
configuration device is also activated by the bypass key.
The address of the configuration device must be in the
range 100h-FF8h and be aligned on a multiple of 8. An
“alias” of the audio device address can be used. For
example, use E20h for the configuration device if the audio
is at 220h.
Is it sufficient for ESS to have only 279 writeable for successful pseudo-pnp init ?

vsharun wrote on 2025-06-08, 17:08:

The ES1868 must be in the “wait-
for-key” Plug and Play state.

Just for curiosity, how the soundcard is switched to this state? Is it default state after power on/reset until PnP enumerator do some configuration?
You wrote that port A79 is blocked and 279 is OK, is it enough for writing config?
Isn't possible to program EEPROM in external programmer with some defined configuration and then use with this LPC2ISA bridge? Maybe write-protect it to block unwanted changes then?

Am I correct in guessing that any address above 7FF, ie 800 and up, will be unavailable?
Can that be tested

Just out of curiosity.

as for the eeprom & configuration. I recall it's possible to write the eeprom so it only has one possible configuration, but it wil be up to the soundcard to use it directly or wait until the pnp software routines set it up.

weedeewee wrote on 2025-06-09, 18:37:

Am I correct in guessing that any address above 7FF, ie 800 and up, will be unavailable? Can that be tested […]
Show full quote

Am I correct in guessing that any address above 7FF, ie 800 and up, will be unavailable?
Can that be tested

Just out of curiosity.

as for the eeprom & configuration. I recall it's possible to write the eeprom so it only has one possible configuration, but it wil be up to the soundcard to use it directly or wait until the pnp software routines set it up.

Can't be 100% sure about ports above 7FF, but even so, that's an ASUS problem. ISA PnP works perfectly on my ASRock board.

To test higher ports one would need a POST card capable of decoding at least 12 bits. The one I've assembled and used only supports 10 bits.

IIRC ES1868/1869 seems to put a control port at 800h region by default when I tried to init one with UNISOUND on another system. If what you're suspecting is really the case, and this control port is indeed involved in some further configurations, then the problem with initializing the ESS card would be more than just A79 being inaccessible.

PS: I just did some tests on my AMD (B450) board again... Still can't detect PicoGUS even though I've confirmed I could write to 1D0-1D2.

It seems writing to I/O ports works, but reading from I/O ports is problematic. Ports that have been enabled for forwarding to LPC can be written, but reading always returns FF regardless.

Maybe this is also the reason why I couldn't "access" 4E/4F, because reading never worked.

EDIT: The output from "pgusinit" is odd, actually. It seems initial accesses to the PicoGUS control port worked, but subsequent accesses to query protocol versions failed so it instead complained about protocol version being 255 (FF), rather than failing outright (not detecting the card).

EDIT 2: Nope. "pgusinit" was working as expected for not detecting the card per the version released with FW v2.2.0. The preemptive abort was introduced after that. Before that, it will eventually error at protocol check phase.

LSS10999 wrote on 2025-06-10, 01:57:

To test higher ports one would need a POST card capable of decoding at least 12 bits. The one I've assembled and used only supports 10 bits.

To test any ISA port, oscilloscope capable 8MHz required and B13 (IOW#) + B14 (IOR#) pins probes soldered.
They're high by default and sending spam (thousands of) via msdos debug "O $port_number 0" you'll see signal low - mean signal here, the same for B14 (reads) - spam "I $port_number".
By default behind LPC/ISA bridge there's no traffic at all except generated (spammed) one, and will barely work on congested bus. This is the method used by our "team" to test what ports are decoded, and which aren't.

LSS10999 wrote on 2025-06-10, 01:57:

It seems writing to I/O ports works, but reading from I/O ports is problematic. Ports that have been enabled for forwarding to LPC can be written, but reading always returns FF regardless.

Do you have an option in BIOS enable/disable external/internal TPM is it work ?
Tomorrow Gigabyte cable for Z87/B85 (the same) will be there and I eventually will check basic functionality with B450 Aorus M and R3-1200.

RayeR wrote on 2025-06-09, 18:03:

vsharun wrote on 2025-06-08, 17:08:

The ES1868 must be in the “wait-
for-key” Plug and Play state.

Just for curiosity, how the soundcard is switched to this state? Is it default state after power on/reset until PnP enumerator do some configuration?

Yes, this is default state of PnP cards after reboot - "wait-for-key” .

RayeR wrote on 2025-06-09, 18:03:

You wrote that port A79 is blocked and 279 is OK, is it enough for writing config?

I suppose so for ESS, not sure about Yamaha. In case of ESS there's clean indication of that you'll send to the port 279 the sequence consisting of "bypass key" and (any you like!) configuration port (high and low bytes) four times (coz unknown stored configuration register bits 5:6, this is why four times key XOR'ed by 00..11). In case of Yamaha there's also "bypass key" exists and clearly stated in datasheet (YMF715E.PDF, I suppose the same for 718/719). ChatGPT then said that after sending magic key to the YMF via port 279 you may unlock configuration "as usual" at port 203. <=- BS, the procedure of init YMF 71x (even manual, using bypass key, as stated earlier by Tiido) requires mandatory access to the A79, while ESS1868/69 can be programmed to switch to the manual configuration mode port on any 16bit address.

RayeR wrote on 2025-06-09, 18:03:

Isn't possible to program EEPROM in external programmer with some defined configuration and then use with this LPC2ISA bridge? Maybe write-protect it to block unwanted changes then?

This was the first question I asked myself: is there any other methods where we may convert those cards to the non PnP ones. Both datasheets didn't say so.
Also Fintek bridge can only be configured, but cannot issue ISA cycles by themselves - this was clearly stated by ChatGPT and then after examining the datasheet.
In case of 1+ ISA slots board ISA PnP sequence can be done via second card which may issue any ISA operations we like or need within ISA domain.

vsharun wrote on 2025-06-10, 11:55:

Do you have an option in BIOS enable/disable external/internal TPM is it work ?

It seems on that B450M board with the latest BIOS the option for external/internal TPM will automatically switch to internal if no *real* external TPM device is detected. This was probably done for Win11 support.

Though I don't think that has anything to do with the issues on reading data from LPC bus.

I also tried the adapter with a FM2 board (ASUS F2A85-M) and it behaved the same way with stock BIOS, and that board's BIOS predates Win10/11.

F2A85-M was supported by coreboot, but unfortunately I haven't managed to get it to boot so I cannot verify whether the behavior was a BIOS thing...

I don't want to speak too soon, but spoiler: On the IT8888 front; I've ordered a few pcbs from oshpark. Exciting times.

I also created a BGA to QFP adapter so it's possible to use the IT8888F (QFP footprint) PCI card with the IT8888G (BGA chip)

Supply question...
Why not double footprint the main board?
Layers?

myne wrote on 2025-06-13, 09:00:

Supply question...
Why not double footprint the main board?
Layers?

Yeah, the adapter is a 4 layer and the card is only 2 layers. Unless I'm doing something wrong, the PCI card with 4 layers is varying from double to triple cost for the size depending on vendor.

Can't wait to see the result.
If that works, It will be interesting to see if a pcie adapter works

myne wrote on 2025-06-14, 02:12:

Can't wait to see the result.
If that works, It will be interesting to see if a pcie adapter works

Yep, that's the plan. Specifically I got the ASM1083 based PCIe 1x to PCI adapters that support bus mastering, this one should theoretically work.

I think a custom card with PEX8114 chip will work too, but those chips are like 75dollars alone. Very expensive.

The StarTech one using PI7C9X111SL I'm unsure will work as it's stated DMA doesn't work on their site. Though the StarTech one might be configured incorrectly for our use case with the PI7C9X111SL's Bus Master Enable bit unset, so it might be possible to hack those provided someone does it.

Without spoiling too much, there is good reason I ordered PCBs 😉

I also ordered my PC104 version.

rasteri wrote on 2025-06-14, 10:10:

I also ordered my PC104 version.

That's awesome. Great job routing. Mine has a lot to be desired 🤣.

rasteri wrote on 2025-06-14, 10:10:

I also ordered my PC104 version.

Is this card may bring ISA support to the 775i65g and P5PE-VM ? They both ICH5, 800MHz (up to 1066) FSB Core2 CPUs (don't expect serious overclocking capabilities though) = SB Live in DOS working.
I have several ICH4 Pentium-M platforms with native ISA slots (FS97-A for example), ICH5 looks almost the same from (still) ISA support perspective.

vsharun wrote on 2025-06-16, 08:58:

Is this card may bring ISA support to the 775i65g and P5PE-VM ? They both ICH5, 800MHz (up to 1066) FSB Core2 CPUs (don't expect serious overclocking capabilities though) = SB Live in DOS working.
I have several ICH4 Pentium-M platforms with native ISA slots (FS97-A for example), ICH5 looks almost the same from (still) ISA support perspective.

Yeah I hope so. My main goal for these IT8888 boards is to experiment with ISA support on pre-ICH6 motherboards. Should be good for stuff like graphics cards that don't work over an LPC bridge.

I'm curious, tinkering with those A79 port problem on Asus motherboards.
Correct me if I wrong:
The goal is: connect hardware 0x0A79 on the card to the 0x0679 in software:
0x0A is b1010 and 0x06 is b0110.
under A10/A11 I mean not left right pinout Axx Bxx, but Address pin 10 as A10.
if I isolate line A10 on card from bus and connect bus A10 to card A11 while isolating A11 on the card from the bus and ->
reprogram pnp init software to use port 679 instead of A79 (this ineed simple: UNISOUND has configuration registers hardcoded at C0B0:0A both 279 and A79 )
... then everything sent from CPU to the port 679 will land on A79 on the card.
Making this permanent (isolate A10/A11 on the card from bus and connect bus A10 to A11 on the card) will loose access for ports over 3FF on the card which isn't a big deal for ESS/Yamaha's in SB Pro mode.
BTW ESS1868/69 doesn't require ports outside of 2xx/3xx to init/functions except A79 (DATA WRITE PnP)
Technically we'll loose memory mapped access address bit also, as it not used by SB Pro.
upd: doesn't work for now
upd2: PicoGUS in SB mode works flawlessly in Duke3d (no init required) on Asus Gryphon Z87 (after lpcexp toolkit init, which swtiches GPIO23 -> LDRQ1)
upd3: saga with Asus Gryphon Z87 seems ended, lpc-exp toolkit instead sapphisa (GPIO23->LDRQ1 mandatory for most of Asus boards), ES1688 card (1868 without PnP, quite hard to get, ES688 cards has no MPU-401 support in hardware), init only via essinit, setting only MPU port and no IRQ MPU401 mode, avoid unisound /nopnp - you'll have IRQ issues.

rasteri wrote on 2025-06-16, 10:32:

Yeah I hope so. My main goal for these IT8888 boards is to experiment with ISA support on pre-ICH6 motherboards. Should be good for stuff like graphics cards that don't work over an LPC bridge.

I meant to ask you what eeprom were you going to use for IT8888 config.

If you need a programmer for AT24C02, I think mine works now, in my repo in sig. Uses pico with VSCode and the Official Pico SDK Plugin. Dead simple wiring.

• 4.7kΩ resistor between SDA and 3.3V
• 4.7kΩ resistor between SCL and 3.3V
• A0,A1,A2(EEPROM Pins 1,2,3)->All GND for 0x50 Address
• VSS(EEPROM Pin4)->GND
• SDA(EEPROM Pin5)->GPIO2(Physical Pin 4)
• SCL(EEPROM Pin6)->GPIO3(Physical Pin 5)
• WP(Write Protect, EEPROM Pin7)->GND
• VCC(EEPROM Pin8)->3v3OUT(Physical Pin 36)

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.

• Read and Run the python config tool (IT8888F_ConfigTool.py) to get a bin file.
• Open bin with online tool (hexed.it) made by IT8888F_ConfigTool.py.
• Select entire hex section. Use CTRL-C to export selection as code snippet.
• Export as: "C", "unsigned char", "ucDataBlock", "Hexadecimal", "Tab" or use the bin in the repo, it's also pre-converted in the intel_hex_config.h
• Both .bin and unsigned char ucDataBlock[256] was created using (python it8888f_ConfigTool.py --enable-subtractive --enable-delayed-tx --claim-io "0x3F8,8,fast" --claim-io "0x2E8,8,medium" --claim-memory "0xD0000,64kb,medium" --claim-memory "0xF0000,64kb,fast" --bios-segments all --verbose).
• I will also update the IT8888F_ConfigTool.py soon to produce this format myself so no online tool needed.
• Ignore [AT24C02_Programmer.md/AT24C02_Programmer.py/serialmonitor_main.c] Deprecated.

main.c output from serial monitor.

AT24C02 EEPROM Automatic Programmer wrote:

================================================== AT24C02 EEPROM Automatic Programmer Programming 256 bytes from ucDataBlock ar […]
Show full quote

==================================================
AT24C02 EEPROM Automatic Programmer
Programming 256 bytes from ucDataBlock array
==================================================
Scanning I2C devices...
I2C device found at address 0x50
AT24C02 found at address 0x50!

Data to be written (first 32 bytes):
0x0000: 50 0B 00 00 1F 54 00 00 00 8C 58 F8 03 00 E3 5C
0x0010: E8 02 00 C3 70 00 0D 00 C2 74 00 0F 00 E2 AA FF

Programming EEPROM...
Writing 256 bytes to EEPROM...
Writing page at address 0x00: 0x50 0x0B 0x00 0x00 0x1F 0x54 0x00 0x00
Writing page at address 0x08: 0x00 0x8C 0x58 0xF8 0x03 0x00 0xE3 0x5C
Writing page at address 0x10: 0xE8 0x02 0x00 0xC3 0x70 0x00 0x0D 0x00
Writing page at address 0x18: 0xC2 0x74 0x00 0x0F 0x00 0xE2 0xAA 0xFF
Writing page at address 0x20: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x28: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x30: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x38: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x40: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x48: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x50: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x58: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x60: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x68: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x70: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x78: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x80: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x88: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x90: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0x98: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xA0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xA8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xB0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xB8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xC0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xC8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xD0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xD8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xE0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xE8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xF0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Writing page at address 0xF8: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
EEPROM write complete!

Verifying EEPROM...
Verifying 256 bytes in EEPROM...
EEPROM verification successful!

==================================================
SUCCESS: EEPROM programmed and verified!
==================================================

Final EEPROM contents (first 64 bytes):
EEPROM contents from 0x00 to 0x3F:
0x0000: 50 0B 00 00 1F 54 00 00 00 8C 58 F8 03 00 E3 5C |P....T....X....\|
0x0010: E8 02 00 C3 70 00 0D 00 C2 74 00 0F 00 E2 AA FF |....p....t......|
0x0020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
0x0030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|

Programming complete. Safe to disconnect.
---- Closed the serial port COM4 ----

Hope this helps

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