vsharun wrote on 2025-09-29, 18:53:

Few more adapters. Now with SATA power and -12V converter.

Sick! If that's the 0.2 version remember to install the MASTER# resistor - Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards

rasteri wrote on 2025-09-30, 09:50:

vsharun wrote on 2025-09-29, 18:53:

Few more adapters. Now with SATA power and -12V converter.

Sick! If that's the 0.2 version remember to install the MASTER# resistor - Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards

Alredy done 😀 But thanks

You don 't need to mess with pmode and extenders for just doing IO programming. Even in real mode you can use 32bit registers and instructions. And some pci registers that are 8b/16b you can read by 8/16b input, notr 32b needed.

But in case you need to programm MMIO you will need extender/DPMI host to access memory beyond 1MB - again - djgpp is your friend 😀

LSS10999 wrote on 2025-05-27, 10:05:

A question about the most recent version of dISAppointment on GitHub (v0.4). Has that version been tested functional? Haven't checked the files in detail so I'm not sure about all the changes compared to v0.3 which I could not get working back then.

v0.4 has now been confirmed working. I would recommend people build that instead of bodging v0.2.

Hmmm. DOS isn't working either. I tried a metric ton of stuff too but doing so, I think I figured why the ITE8888 based card is not working. I've also tried testing on a PC Chips M810LR motherboard, AMD Duron 850 CPU, 1GB RAM because I wanted to see if our problem was due to ICHxx and if the problem would occur on a non-ICH system. The problem still exists. Here's where it gets interesting and please do correct me if I'm off base here.

CPU -> Southbridge -> LPC claims it -> Never reaches user PCI bus. In both ICH and non-ICH the hardware on the motherboards are capturing the calls. IT8888 can never see the cycle, even though it's configured to respond. This is exactly what (I think it was RayeR) brought up before. The fact the signal would never make it to our card because of the hierarchy of the motherboard architecture.

Solution:
Hypervisor with I/O routing (Xen?). We intercept at CPU instruction level, before chipset routing and redirect it over to the ITE8888 on PCI bus rather than letting the hardware handle it.

technical nuance:
"redirect it over to the ITE8888 on PCI bus" is slightly simplified. More precisely, the hypervisor would intercept the OUT instructions via VM exit, then somehow generate PCI I/O cycles (rather than CPU I/O instructions) that reach the IT8888 on the PCI bus. The exact mechanism for this is unclear; it might require PCI device passthrough, special hypervisor code, or discovering undocumented IT8888 capabilities. The IT8888 datasheet shows it has PCI config registers but no explicit "I/O forwarding API," so what is likely needed is experiments with how to actually send individual I/O operations through its PCI interface. "PCI device passthrough," that typically means passing through a PCI device's MMIO/config space to a VM. What I think we'd actually need is more exotic; the ability to generate PCI I/O transactions (not memory-mapped, but actual PCI I/O cycles) from the hypervisor to specific addresses. This is uncommon since most modern PCI devices use MMIO, not I/O space.

This hypervisor approach requires significant custom development work; writing hypervisor I/O handlers and potentially reverse engineering how to communicate with the IT8888 via PCI, since ITE's documentation doesn't explicitly describe a forwarding mechanism for individual I/O operations. This is where the PCI/ISA logic analyzer would be useful; I knew it would come in handy, just not in this exact way. This is genuinely complex, potentially months of work. But it's theoretically sound. To me this is really just a roadblock. There is seemingly nothing that would stop us from doing it except a large chunk of work.

Xen (or KVM) would allow intercepting I/O instructions via hardware virtualization (VT-x/AMD-V), but the harder part is generating PCI I/O cycles to the IT8888. This likely requires modifying the hypervisor's device model (QEMU in both Xen and KVM) to write custom code that can issue PCI I/O transactions, something most hypervisors don't natively support since modern devices use MMIO instead.

All this really shows the genius of the original dISApointment, which we all knew of course.

~~~

I think at this point I should go back to messing around with a far more modern system and try the PCIe-PCI bridge? Or maybe there is still hope and someone has an idea that might bypass the need for hypervisor capture?

I think testing your PCIe-PCI-ISA bridge on a modern system without existing LPC or ISA would be a good idea.

dartfrog wrote on Yesterday, 11:01:

Hmmm. DOS isn't working either. I tried a metric ton of stuff too but doing so, I think I figured why the ITE8888 based card is not working. I've also tried testing on a PC Chips M810LR motherboard, AMD Duron 850 CPU, 1GB RAM because I wanted to see if our problem was due to ICHxx and if the problem would occur on a non-ICH system. The problem still exists. Here's where it gets interesting and please do correct me if I'm off base here.

Which LPC/superio?

No way, involving virtualization and hypervisor negates the idea of using a real ISA HW. Simply beacause vmenter / vmexit takes too many cpu cycles for storing/restoring and switching cpu context. Then it doesn't take much more time to emulate soundcard via AC97/HDA modern soundcard...

I think passing IO to PCI would.be doable only by translating IO address of legacy soundcard to some higher address, like 220h -> 8220h that wouldn't be catched by LPC bridge but yhe your PCI bridge will need to translate it back to 220h. As ISA decode only lower IO address bit maybe it will be simply truncated and work - you may try this, e.g. writing to POSTcard at 8080h and set positive decode such range...

As it was told more times, you should try on some new MB without LPC bridge and other legacy devices in chipset, then there would be chance that IO will pass yo the ITE instead PCH...

GEN_CNTL — General Control Register
(LPC I/F — D31:F0)
Offset Address: D0h – D3h Attribute: R/W, R/WO
Default Value: 00000004h Size: 32 bit

Hide ISA Bridge (HIDE_ISA) — R/W.
0 = The Intel® ICH5 will not prevent AD22 from asserting during config cycles to the PCI-to-ISA
bridge.
1 = Software sets this bit to 1 to disable configuration cycles from being claimed by a PCI-to-ISA
bridge. This will prevent the OS PCI PnP from getting confused by seeing two ISA bridges.
It is required for the ICH5 PCI address line AD22 to connect to the PCI-to-ISA bridge’s IDSEL
input. When this bit is set, the ICH5 will not assert AD22 during config cycles to the PCI-to-ISA
bridge.

Positive Decode Enable (POS_DEC_EN) — R/W.
0 = Disable. The ICH5 performs subtractive decode on the PCI bus and forwards the cycles to
LPC I/F if not to an internal register or other known target on LPC I/F. Accesses to internal
registers and to known LPC I/F devices are still positively decoded.
1 = Enables ICH5 to only perform positive decode on the PCI bus.

Barking up the wrong tree?

myne wrote on Today, 01:21:

GEN_CNTL — General Control Register (LPC I/F — D31:F0) Offset Address: D0h – D3h Attribute: R/W, R/WO Default Value: 00000004h […]
Show full quote

GEN_CNTL — General Control Register
(LPC I/F — D31:F0)
Offset Address: D0h – D3h Attribute: R/W, R/WO
Default Value: 00000004h Size: 32 bit

Hide ISA Bridge (HIDE_ISA) — R/W.
0 = The Intel® ICH5 will not prevent AD22 from asserting during config cycles to the PCI-to-ISA
bridge.
1 = Software sets this bit to 1 to disable configuration cycles from being claimed by a PCI-to-ISA
bridge. This will prevent the OS PCI PnP from getting confused by seeing two ISA bridges.
It is required for the ICH5 PCI address line AD22 to connect to the PCI-to-ISA bridge’s IDSEL
input. When this bit is set, the ICH5 will not assert AD22 during config cycles to the PCI-to-ISA
bridge.

Positive Decode Enable (POS_DEC_EN) — R/W.
0 = Disable. The ICH5 performs subtractive decode on the PCI bus and forwards the cycles to
LPC I/F if not to an internal register or other known target on LPC I/F. Accesses to internal
registers and to known LPC I/F devices are still positively decoded.
1 = Enables ICH5 to only perform positive decode on the PCI bus.

Barking up the wrong tree?

Yeah I remembered there being something like that in the LPC registers. When I get a chance I'll see if my PCA-6186 industrial board (ICH4 with IT8888) sets this register differently from my consumer ICH boards

Okay, I booted up my PCA-6186 and it indeed sets bits 0 and 24 of GEN_CNTL to 1. My other boards have them both set to zero.

While I was there, I dumped the IT8888 configuration using the (now working brilliantly!) ITE8888.EXE. It seems to be set by the BIOS rather than by an EEPROM (I don't see any EEPROM, anyway). (Thanks Paul_V for the tip about unhiding the ISA bridge!)

1ITE8888 Configuration Utility v1.1
2==================================
3
4Testing PCI configuration access...
5  Host Bridge ID: 0x25608086
6  PCI access OK
7
8Scanning PCI buses for ITE8888 bridge...
9Found ITE8888 at Bus 1, Device 6, Function 0
10
11
12Current ITE8888 Configuration:
13==============================
14Location: Bus 1, Device 6, Function 0
15Device/Vendor ID: 8888:1283
16Command: 0x0007 [I/O] [Mem] [Master]
17Misc Control: 0xCC003F3F [DDMA-Concurrent] [PCI-Clk] [ISA-Refresh] [Subtractive] [Delayed-Tx]
18
19I/O Spaces:
20
21Memory Spaces:
22

In my PCA-6186, if I disable POS_DEC_EN it stops my ISA SB16 PNP from detecting in unisound. So that bit definitely IS necessary.

If I enable POS_DEC_EN on my other ICH boards that doesn't magically make the SB16 work, however.

I'll do some more fiddling. I suppose next thing is to set all the registers in my IT8888 to be exactly the same as the IT8888 on my PCA-6186.

I used pcicfg to do a dump of each.

PCA's IT8888 :

1PCI bus 01 device 06 function 00:  Header Type 'non-bridge' (single-func)
2Vendor:	1283	Integrated Technology Express, Inc.               
3Device:	8888	???                                               
4Class:	  06	bridge              	Revision:	03
5SubClass: 01	PCI/ISA             	ProgramI/F:	00
6CommandReg:	 0007 = I/O-on mem-on busmstr
7Status Reg:	 0280 = fast-trns (med)
8CacheLine:	   00	Latency:	00	BIST:	     00
9SubsysVendor:    0000	SubsysDevice: 0000
10No base addresses
11CardBus:     00000000	ExpansionROM: 00000000 (no ROM)
12INTline:	   00	INTpin:       00
13MinGrant:	   00	MaxLatency:   00
14Device-Specific Data:
15 40: 00000000  00000000  000200FF  00020002  01FFF021  CC003F3F 
16 58: 00000000  00000000  00000000  00000000  00000000  00000000 
17 70: 00000000  00000000  00000000  00000000  00000000  00000000 
18 88: 00000000  00000000  00000000  00000000  00000000  00000000 
19 A0: 00000000  00000000  00000000  00000000  00000000  00000000 
20 B8: 00000000  00000000  00000000  00000000  00000000  00000000 
21 D0: 00000000  00000000  00000000  00000000  00000000  00000000 
22 E8: 00000000  00000000  00000000  00000000  00000000  00000000 

My IT8888 (with EEPROM disabled, and having not run ITE8888.exe yet) :

1PCI bus 01 device 04 function 00:  Header Type 'non-bridge' (single-func)
2Vendor:	1283	Integrated Technology Express, Inc.               
3Device:	8888	???                                               
4Class:	  06	bridge              	Revision:	03
5SubClass: 80	other               	ProgramI/F:	00
6CommandReg:	 0107 = I/O-on mem-on busmstr sys-err
7Status Reg:	 0280 = fast-trns (med)
8CacheLine:	   00	Latency:	00	BIST:	     00
9SubsysVendor:    0000	SubsysDevice: 0000
10No base addresses
11CardBus:     00000000	ExpansionROM: 00000000 (no ROM)
12INTline:	   00	INTpin:       00
13MinGrant:	   00	MaxLatency:   00
14Device-Specific Data:
15 40: 00000000  00000000  000200FF  00020002  01FFF020  8C003F3F 
16 58: 00000000  00000000  00000000  00000000  00000000  00000000 
17 70: 00000000  00000000  00000000  00000000  00000000  00000000 
18 88: 00000000  00000000  00000000  00000000  00000000  00000000 
19 A0: 00000000  00000000  00000000  00000000  00000000  00000000 
20 B8: 00000000  00000000  00000000  00000000  00000000  00000000 
21 D0: 00000000  00000000  00000000  00000000  00000000  00000000 
22 E8: 00000000  00000000  00000000  00000000  00000000  00000000 

Incidentally, factory BIOS on my motherboard similarly sets bridge Command Register to 07h, while a ported one (where I cannot get onboard IT8888 to work) shifts it to 107h
I don't know, if it affects anything, just my observation.