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 Today, 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...